MNO

Mobile Network Operator

Definition

MNO (Mobile Network Operator) is a telecom operator that owns spectrum licenses and mobile network infrastructure and can provide cellular connectivity services. ICMP aggregates over 600 MNOs worldwide and achieves unified management through the Multi-Operator architecture, providing customers with global coverage, multi-network redundancy, and flexible choices.

MNO and MVNO

MNO owns physical networks, while MVNO (Mobile Virtual Network Operator) rents MNO networks to provide virtual operator services. ICMP may cooperate directly with MNOs or indirectly access through MVNOs and aggregators. In either model, the platform needs to manage multi-operator resources uniformly to achieve Global SIM Pool, Roaming Partner integration, and CDR and billing integration.

Role in ICMP

MNO is the provider of ICMP connectivity capabilities: it provides SIM cards, eSIM profiles, network access; provides CDR and usage data; conducts Reconciliation and settlement with the platform. As a connectivity management platform, ICMP aggregates multiple MNOs, offering customers a unified entry point, Cross-Border Billing, Multi-Currency Settlement, Card Diagnostics, and other value-added capabilities.

Cooperation Model

The cooperation model between ICMP and MNOs includes: direct contracting, through aggregators, or via Roaming Partner roaming agreements. In cross-border scenarios, it is necessary to integrate with multiple MNOs or roaming partners from different countries, with unified agreements, Rate Card, and settlement processes. The platform needs to maintain MNO master data, coverage, tariffs, and connection status to support operations and customer service.

Where the Licensed Network Sits in the Supply Chain

A mobile network operator holds a spectrum license and runs the radio access network and the core. A connection exists only when such a network accepts the SIM identity, completes authentication, and assigns a user plane. A platform, a reseller, and a roaming partner can all take part in selling or forwarding. That does not make them owners of the spectrum. A SIM’s home network is usually one operator’s public land mobile network. After the device leaves the country, it may attach to another operator. The two sides exchange signaling and CDRs under a roaming agreement.

Register an operator on the management platform only when at least three relationships can be told apart: buying SIMs and CDRs directly from that operator, using its network indirectly through a reseller, or treating the other party as a visited network only while roaming. The master data for the three relationships differ. A direct contract maintains the account, the tariff, and the provisioning API. Resale maintains the upstream contract and the products that may be sold. Roaming maintains the allowed visited networks and the settlement rules. A single “operator name” dropdown cannot later say who should be called for a fault, or who the invoice should be reconciled with.

Mixing Resale, Roaming, and an Owned Network

A common error is to call every name on the list “our network.” Resale access means radio quality, maintenance windows, and some restrictions are still decided by the licensed operator. What the platform can do is package the product and manage the customer side. A roaming partner is even less a home operator. It provides visited service only when the device enters its coverage. Writing “roaming available” as “local operator access” makes the customer think the subscription has moved locally, while tariff and identity are still calculated on the original home network.

Another error is to keep grouping CDRs under an old name after operators merge or network codes change. One commercial brand can have several network codes, and the tariffs and allowed areas are not the same. Master data should store the legal entity, the network code, the type of cooperation, and the interface status. The name is only for display. When the network side refuses service, first confirm whether the refusal came from the home operator or the visited operator, then decide whether to change platform policy or to hand the case to the matching licensed party.

When an operator interface is retired or the account is replaced, freeze provisioning and status queries that depend on that interface, and tell support that what they see is the last successful sample, not the current network fact. A commercial-brand change should not overwrite historical network codes, or old CDRs will lose the contracting party. Split direct contract, resale, and roaming into three sets of contacts and escalation paths, so a fault ticket reaches the party that can actually change the network configuration, not a queue inside the platform.

Register the commercial brand, the legal entity, and the network code separately. The same brand may use different entities in different countries, and one entity may own several network codes. CDRs and rejection reasons carry the network code. Contracts and invoices name the legal entity. What the customer says is usually the brand. Merging only by brand adds two networks with different tariffs together. Showing only the network code leaves support unable to match the name the customer sees. Keep all three in master data, and state which one is used for reconciliation and which one is used on screen.

Cooperation status changes over time. When a network code is retired, an account is replaced, or only a roaming relationship remains, new provisioning should stop, and historical CDRs should still find the entity of that time. Deleting a retired operator from master data leaves old invoices without a contracting party. When an interface address changes, record the effective time as well, so troubleshooting can tell that failures before a given day came from the old address. Split contacts and escalation paths by type of cooperation. Do not send a roaming problem to a contact who only handles local wholesale.

Aggregating many operators on a platform does not confer control of radio parameters. What can usually be changed is the product, the allowed visited networks, and customer-side policy. What cannot be changed is the base station, the band, and the other party’s core-network maintenance window. When explaining a fault to a customer, first say which licensed network the restriction comes from and which kind of cooperation it is, then decide whether to change policy, change identity, or wait for the other party to recover. Recording every failure as a platform fault means the party that can actually handle it never receives the information.

Related Terms

Return to International IoT Cloud Platform Terminology