MVNO Platform Architecture: Layers, Models and Choices
MVNO platform architecture is the design of everything between the host network and the subscriber: core network access, provisioning, BSS and billing, self-service channels, the data layer that records what happens, and the interfaces that join them. How much of that stack you own decides your cost base, your speed to market and how different your product can be.
Every successful Mobile Virtual Network Operator is built on one foundational element: its platform architecture. MVNO platform architecture defines how all the technical, operational, and business systems inside an MVNO connect, communicate, and function together. It determines what services you can deliver, how fast you can scale, how quickly you can respond to market demands, and ultimately whether your mobile business survives and grows.
Whether you are planning to start an MVNO from scratch, evaluating a technology stack, or trying to modernize an existing operation, understanding MVNO platform architecture is not optional. It is the blueprint of your entire business. This guide walks you through every critical dimension of MVNO platform architecture: what it is, how it works, which model fits your business type, and how emerging technologies are reshaping it today. Check also how an MVNO Platform works.
On this page
History and Evolution of MVNO Platform Architecture
MVNOs emerged in the late 1990s when regulators opened mobile networks to resellers. Early architectures were minimal, often just a branding layer over a host Mobile Network Operator (MNO). Over time, MVNOs demanded more control, driving the development of dedicated BSS and OSS platforms, and eventually full independent core networks. Today, cloud-native and microservices-based architectures represent the current frontier.
Core Concept: The Architecture Defined
What MVNO Platform Architecture Means
MVNO platform architecture refers to the complete structural design of all technology systems that an MVNO operates or relies upon to deliver mobile services. It covers every layer from the radio network access leased from an MNO, through the core network functions, to the customer-facing billing and service management systems.
Think of platform architecture as the engineering blueprint of your MVNO. It defines which components you own, which you outsource, how data flows between systems, and where decisions get made. A well-designed architecture enables your MVNO to launch faster, scale efficiently, and adapt quickly to market changes. A poorly designed one creates bottlenecks, increases costs, and limits the services you can offer.
The architecture also determines your level of independence. A lightweight architecture gives you speed to market but less control. A deeper, more complex architecture gives you differentiation power but demands more investment and expertise. Understanding this trade-off is central to every architectural decision you make.
The Architectural Layers of an MVNO Platform
An MVNO platform consists of several distinct but interconnected layers. Each layer has a specific function, and together they form the complete operating environment of your mobile business.
Radio Access Network (RAN) Layer: This is the physical network layer. MVNOs do not own this layer; they access it through a wholesale agreement with an MNO. The RAN provides the radio spectrum and base station infrastructure that connects subscribers to the network. Your wholesale agreement with the MNO defines the quality, coverage, and cost of this access.
Core Network Layer: This layer handles subscriber authentication, session management, routing, and charging. Depending on your MVNO type, you may share the MNO's core network, use a virtual core provided by an MVNE, or operate your own. Key core network elements include the Home Subscriber Server (HSS), Policy and Charging Rules Function (PCRF), and Online Charging System (OCS).
BSS Layer: The Business Support System handles all commercial operations: billing, customer relationship management (CRM), product catalog management, order management, and revenue assurance. This is the commercial engine of your MVNO.
OSS Layer: The Operational Support System manages the technical operations: network inventory, provisioning, activation, fault management, and performance monitoring. OSS and BSS work in close synergy; read more about the differences between OSS and BSS to understand how they complement each other.
Service and VAS Layer: This layer delivers Value Added Services (VAS) such as voicemail, RCS, roaming services, and subscriber-facing applications. A strong VAS layer differentiates your offer and improves customer retention.
Customer Touchpoint Layer: This is the front-end layer through which subscribers interact with your brand: self-service apps, websites, customer care portals, and IVR systems. The architecture of this layer directly impacts customer experience and satisfaction.
Data and Reporting Layer: This layer runs alongside the others rather than underneath them. Mediation collects usage records from the core network, normalises them and passes them to charging and billing; from there a data warehouse turns them into what you actually manage on: churn, ARPU, bundle take-up, revenue leakage. An MVNO without this layer can invoice, but cannot steer.
Technical Integration and Interface Architecture
How the Layers Connect: Interface Principles
The layers of an MVNO platform do not operate in isolation. They exchange data continuously through defined interfaces and protocols. Getting these interfaces right is as important as selecting the right components.
The most common integration method between BSS/OSS systems and the core network is through standardized APIs. Modern MVNO platforms use RESTful APIs and SOAP-based web services to enable real-time communication between billing systems and network functions. For core network signaling, protocols such as Diameter, SS7, and increasingly HTTP/2-based service-based interfaces (used in 5G) carry the control messages that authenticate subscribers, enforce policies, and trigger charging events.
When you select solution providers for your platform, evaluate their integration capabilities as carefully as you evaluate their features. A BSS vendor that cannot integrate cleanly with your core network creates operational risk and ongoing cost. Demand open APIs and proven integration track records from every vendor you consider.
The Control Plane and Data Plane Architecture
Every mobile network, and by extension every MVNO platform, separates its traffic into two functional planes: the control plane and the data plane.
The control plane carries signaling information: the messages that set up, manage, and tear down sessions. It handles authentication, mobility management, and policy enforcement. In a 4G/LTE environment, components like the Mobility Management Entity (MME) and the PCRF operate in the control plane. In 5G, the Access and Mobility Management Function (AMF) and Session Management Function (SMF) take these roles.
The data plane carries the actual user traffic: voice calls, SMS, and internet data packets. In 4G, the Serving Gateway (S-GW) and Packet Data Network Gateway (P-GW) handle data plane functions. In 5G, the User Plane Function (UPF) takes over this role and can be deployed in a distributed manner to reduce latency.
For MVNOs, understanding this separation matters because it directly influences what you control. Light MVNOs typically have no visibility into either plane. Full MVNOs with their own core gain direct control of both, enabling real-time policy management, advanced charging, and service differentiation.
The Data Layer: Mediation, CDRs and Reporting
Every layer of the platform produces records. The core network produces call and data records, the BSS produces orders, invoices and payments, the channel layer produces sessions and support contacts. Mediation is the component that collects those records, normalises them into one format and removes duplicates before anything is charged or reported on. It is unglamorous and it is where billing disputes are won or lost.
This is an architecture decision, not a reporting feature, and it is one of the few that is genuinely hard to reverse. If mediation belongs to your MVNE, you get the reports the MVNE offers. If you own it, you own the raw records. You cannot reconstruct a history you never kept, so a platform that gives you monthly summaries instead of record-level data quietly decides what questions you will be able to ask in three years.
Specify four things with any vendor: record-level export rather than reports, a retention period you choose, an interface you can query rather than a file you receive, and revenue assurance — a reconciliation between what the host operator bills you and what you billed your subscribers. That reconciliation is how under-charging and double-charging get found.
One constraint belongs here rather than in the security chapter: usage records are personal data. Retention, access and deletion fall under the GDPR and, for traffic data, under national rules implementing the ePrivacy Directive. Design that in at the data layer; bolting it on later means touching every system that copied the data.
Redundancy and High Availability in MVNO Architecture
Mobile subscribers expect their service to work at all times. Designing redundancy and high availability into your MVNO platform architecture is not a luxury; it is a commercial necessity. Downtime costs you revenue, customer trust, and in some markets, regulatory compliance.
At the core network level, you achieve high availability through geographic redundancy: deploying core network functions across multiple data centers or availability zones. Active-active configurations keep both instances processing live traffic, so that if one fails, the other absorbs the load without interruption. Active-passive setups keep a standby instance ready to take over within seconds.
At the BSS and OSS level, database replication, load balancing, and automated failover mechanisms protect your commercial operations. Your billing system going offline is as damaging as your core network failing; real-time charging requires uninterrupted connectivity between the OCS and the network.
When selecting your solution providers, always request documented SLA commitments for availability (targeting 99.99% or better for critical systems), clear failover procedures, and evidence of disaster recovery testing. Never accept verbal assurances on availability guarantees.
Security Architecture in an MVNO Platform
Security must be built into your platform architecture from day one, not added as an afterthought. MVNOs handle highly sensitive personal and financial subscriber data, making them attractive targets for attacks.
Your security architecture must address several domains. Network security protects your core network interfaces from unauthorized access and signaling attacks (SS7 and Diameter protocol vulnerabilities remain active threats). A Session Border Controller (SBC) provides a critical security boundary for voice traffic. Data security covers encryption of subscriber data at rest and in transit, access control, and compliance with data protection regulations such as GDPR in Europe. Application security governs your BSS portals, APIs, and customer-facing applications.
Integrate security testing into your platform development lifecycle. Conduct regular penetration tests on your API interfaces, and ensure every vendor in your platform stack maintains recognized security certifications. Security failures in an MVNO are not just technical incidents; they are business-ending events.
Architecture Models for MVNOs
Choosing the Right Architecture for Your MVNO Type
Not every MVNO requires the same architecture. The right model depends on your target market, investment capacity, required speed to market, and long-term differentiation strategy. Review the different types of MVNOs to understand which business model aligns with each architecture.
Branded Reseller (skinny MVNO): You use the host operator's or MVNE's entire stack, including its BSS and OSS. You control the brand and the distribution, and you sell tariffs and bundles that somebody else has defined. Fastest to launch, least to differentiate with, and the model most operators outgrow.
Thin MVNO: One step up. Core network operations still sit entirely with the host, and most billing runs on the host's systems, but you gain room to define your own services, bundles and tariffs, and you normally take customer service in house. You are shaping the product without yet owning the machinery that runs it.
Light MVNO: You run your own BSS and OSS — rating and billing, product catalogue, customer care — while every core network element stays with the host operator or the MVNE. This is the first model in which you own your subscriber data and define your own tariffs rather than reselling someone else's, and for most new entrants it is the practical starting point. See the different types of MVNOs for the full ladder from reseller to full MVNO.
Enhanced Service Provider (ESP) or Thick MVNO: You operate your own BSS and some OSS functions while relying on the host network for core network elements. This gives you control over billing, product design, and customer data while keeping network investment manageable.
Full MVNO: You operate your own complete core network alongside your own BSS and OSS. You have maximum independence, full data ownership, and the ability to deliver any network-level service. This model suits Business MVNOs, IoT MVNOs, and operators targeting specialist markets that require deep technical customization.
MVNE-hosted Architecture: Many new entrants use an MVNE or MVNA as a platform provider. The MVNE supplies the technical platform and the MNO connectivity, allowing the MVNO to focus entirely on commercial execution.
Advantages and Disadvantages of Each Architecture Model
Choose the model that matches your MVNO business plan and your realistic operational capabilities. Many MVNOs start with an MVNE-hosted or Light model and migrate toward greater independence as they grow.
The architecture models compared
| Model | You Operate | Speed to market | What you give up |
|---|---|---|---|
| Branded reseller (skinny) | Brand and distribution only | Fastest | Product definition, your own data, and most of the margin |
| Thin MVNO | Brand, service and tariff definition, customer service | Very fast | Billing and every core function stay with the host |
| Light MVNO | Your own BSS and OSS; no core elements | Fast | Core-level differentiation; fully dependent on the host network |
| Thick MVNO / ESP | BSS, OSS and some core elements of your own | Moderate | Full network independence, and a simple operating model |
| Full MVNO | Your own core, BSS and OSS | Slowest | Capital and a much larger operational team |
| MVNE-hosted (not a model) | Whatever you choose; the MVNE operates the rest | Fast | Independence, in exchange for someone else carrying the complexity |
Regulatory Components: Lawful Intercept and Number Portability
Two obligations shape an MVNO architecture before any commercial requirement does, because they are conditions of being allowed to operate at all.
Lawful intercept
Lawful intercept is a licence condition in most markets, not a feature request. The architectural question is not whether you have it but who implements it. A light MVNO normally relies on the host operator or the MVNE to provide the interception function, because the traffic never touches the MVNO's own systems. A full MVNO running its own core has to provide it itself, and that is a build with its own hardware, its own secure handover and its own vetted staff.
The specifications are public. ETSI TS 102 232-1 defines the handover interface for IP delivery and ETSI TS 103 120 the electronic interface for warrant information; 3GPP TS 33.126 sets out the requirements and 3GPP TS 33.127 the architecture and functions for 5G. In the United States the obligation runs through CALEA. Settle who does what before you sign the wholesale agreement: retrofitting interception is expensive, and it is not a duty you can negotiate away.
Number portability and number management
Numbers are a national resource. You either hold your own allocated ranges or use ranges sub-allocated by your host, and that choice determines who is accountable to the regulator and what happens to your subscribers if you change host. Architecturally it means the platform needs a number inventory: ranges, states, reservations, and a clean link between a number, a SIM and a subscriber.
Portability then needs two flows, not one. In the EU, Article 106 of the European Electronic Communications Code — "Provider switching and number portability" — gives subscribers the right to keep their number when they switch; Ofcom sets out the equivalent process in the UK. Porting in is the flow everybody designs, because it brings customers. Porting out is the one that gets left until launch minus two weeks, and it is the one with a regulated response window attached to it.
The two porting flows, and what both of them need underneath
What the architecture must also carry, beyond the happy path
| Requirement | Why it belongs in the architecture | Often forgotten |
|---|---|---|
| Lawful intercept | A licence condition, not a feature request | Yes, decide early who implements it |
| Number portability | A regulatory duty in most markets | Yes, porting in and out both need flows |
| Number inventory | Ranges, states and reservations have to live somewhere | Frequently |
| Redundancy and failover | Subscribers notice outages before you do | Usually covered |
| Migration path | Light to thick to full, without re-platforming | Almost always |
| Test and launch environment | You cannot test billing on live subscribers | Frequently |
| Exit and data portability | Getting your own data out of a vendor | Almost always |
Organizational Impact of MVNO Platform Architecture
Your platform architecture does not only affect your technology team. It shapes your entire organization. The architecture you choose determines the skills you need to hire, the vendors you depend on, the data you can access, and the speed at which your business can respond to competitive changes.
A Light MVNO architecture allows a small team to operate the business but limits what that team can change. A Full MVNO architecture empowers your technical teams but requires significant investment in network engineers, security specialists, and operations staff. Consider your financial plan carefully when evaluating these operational cost implications.
Architecture also determines your data ownership. MVNOs that control their own BSS and core network own their subscriber data completely. This enables better analytics, personalized marketing, and AI-driven customer management. For Discount MVNOs, data-driven churn reduction can be the difference between profitability and loss.
Finally, your architecture defines your agility. Cloud-native platforms with microservices allow product teams to launch new offerings in days. Legacy monolithic systems may require weeks of development for the same change. Build your architecture with future product velocity in mind.
The Impact of 5G, eSIM, and Cloud-Native Design on MVNO Architecture
Three technological forces are actively reshaping MVNO platform architecture right now, and every MVNO operator needs to understand their implications.
5G Core Architecture: The 5G Core (5GC) introduces a service-based architecture (SBA) where network functions communicate through APIs rather than fixed point-to-point connections. This makes the core network far more flexible and programmable. For MVNOs, the potential of 5G includes network slicing (the ability to carve out dedicated virtual network slices for specific customer segments), ultra-low latency services for IoT and enterprise, and much richer policy control.
eSIM and Remote SIM Provisioning: The transition to eSIM and iSIM, combined with standards like SGP.32 for remote SIM provisioning, changes how MVNOs provision and manage subscribers. eSIM removes the physical SIM dependency, enabling over-the-air profile management. Your platform architecture must include a capable SM-DP+ (Subscription Manager Data Preparation) server and API integration with device management systems to exploit eSIM fully.
Cloud-Native and Microservices Design: Modern MVNO platforms increasingly adopt containerized, microservices-based architectures deployed on platforms like Kubernetes. This approach enables independent scaling of individual components, continuous deployment of updates, and dramatic reductions in infrastructure cost. A cloud-native BSS can scale its billing engine independently from its CRM during a promotional campaign spike, something monolithic architectures simply cannot do efficiently.
Network APIs and the GSMA Open Gateway: a fourth force is starting to matter. GSMA Open Gateway defines a common set of network APIs so that developers can reach operator capabilities through one interface instead of integrating with every operator separately. For an MVNO this cuts two ways. It is a potential wholesale product you could resell to business customers, and it is a capability your host operator may choose to expose without you. Ask your host and your MVNE what their position is; the answer tells you whether this stays an MNO business or becomes an MVNO one. Between your own layers, the TM Forum Open APIs remain the interfaces to require from every vendor.
Frequently Asked Questions
What is MVNO platform architecture?
MVNO platform architecture is the complete technical design of all systems an MVNO uses to deliver mobile services. It includes the core network (or the portion of it the MVNO controls), the BSS and OSS systems, the service and VAS layers, and all integration interfaces connecting these components.
What is the difference between a Light MVNO and a Full MVNO from an architecture perspective?
A Light MVNO uses the MNO's or MVNE's technology stack entirely and controls only its brand and commercial offerings. A Full MVNO operates its own core network, BSS, and OSS, giving it complete independence over network functions, subscriber data, and service delivery. The architectural depth directly determines the degree of control and differentiation available to the MVNO.
Which architecture model is best for a new MVNO starting up?
For most new MVNOs, an MVNE-hosted or Light MVNO architecture offers the fastest and safest path to launch. It minimizes technical complexity and upfront capital expenditure. As the subscriber base grows and differentiation demands increase, the MVNO can migrate to a thicker architecture model. Review the how to start your own mobile brand guide for a step-by-step overview.
How does 5G change MVNO platform architecture?
The 5G Core introduces a service-based architecture where network functions communicate through open APIs, making the network far more flexible. For MVNOs, this enables network slicing, richer policy control, and programmable services. It also accelerates the shift toward cloud-native platform deployments. MVNOs that modernize their architecture for 5G gain access to new enterprise and IoT market opportunities.
What role does the BSS play in MVNO platform architecture?
The BSS is the commercial heart of the MVNO platform. It manages billing, the product catalog, customer relationships, order management, and revenue assurance. Without a capable and well-integrated BSS, an MVNO cannot manage subscribers effectively, automate charging correctly, or launch new products at competitive speed. Learn more about what a Business Support System is and how to select the right BSS and OSS for your operation.
Summary
MVNO platform architecture is the technical and operational foundation on which your entire mobile business is built. It defines your capabilities, your costs, your agility, and your competitive differentiation. Getting it right from the start saves enormous time, money, and risk as your business grows.
The key decisions you face center on how much of the stack to own versus outsource, which integration standards to adopt, how to design for redundancy and security, and how to position your architecture for 5G and cloud-native evolution. There is no single correct answer. The right architecture is the one that matches your MVNO business model, your investment capacity, your team capability, and your long-term strategic ambitions.
Use MVNO Index to research solution providers that deliver the platform components you need, explore consultancy services to support your architecture decisions, and stay informed through industry events where platform vendors and operators share the latest architectural innovations. Build your architecture with purpose, and your MVNO will be positioned to grow, adapt, and compete effectively in a rapidly evolving mobile market.
Looking to go deeper? Explore the MVNO Glossary for definitions of all technical terms, or browse the full Core Network Elements section to understand every component in detail.
Subjects about how to start your own MVNO
