The question comes up in almost every first conversation with an operator: if we take a 5G core from one supplier, will it work with the radio access network we already have from Nokia, Ericsson or Huawei?
The short answer is yes, and it is done in production networks today. The longer answer — the one that decides whether your programme lands on time — is that standards compliance gets you to the starting line, not across it. What follows is what actually has to be true, and what operators are really asking when they ask this question.
Why it works at all: the interface is defined
In 5G standalone, the boundary between the radio access network and the core is the NG interface, specified by 3GPP. It splits in two:
- NG-C (N2) — the control plane, carrying NGAP signalling between the gNB and the AMF over SCTP.
- NG-U (N3) — the user plane, carrying subscriber traffic between the gNB and the UPF over GTP-U.
Both are open, published interfaces. Any 3GPP-compliant gNB can, in principle, attach to any 3GPP-compliant 5G core. In 4G the equivalent boundary is S1-MME and S1-U between the eNB and the MME and SGW, and it has been multi-vendor in live networks for well over a decade. Mixed-vendor core and RAN is not exotic. It is ordinary.
A cloud-native dual-mode core that implements both the 4G and 5G function sets — MME, SGW and PGW alongside AMF, SMF, SMSF, NRF, NSSF, CHF, PCF and UPF — presents standard S1 and NG interfaces to whatever radio is on the other side. That is the mechanism. It is genuinely that simple at the architectural level.
Where it actually gets difficult
Every experienced operator already knows the interface is open. What they are really asking is: where will this cost me six months? In our experience it is five places.
1. Optional features and vendor-specific behaviour
A 3GPP specification defines mandatory behaviour and a large surface of optional features, information elements and procedures. Two fully compliant implementations can disagree about an optional IE, a timer value, or how a rarely-exercised error path behaves — and both are within specification.
This is not vendor bad faith. It is what happens when a specification leaves room. The consequence is that interoperability has to be proven per combination, in a lab, under load, before volume deployment. A vendor telling you “we are Release 16 compliant” has told you something necessary and insufficient.
2. Release alignment
A Release 16 core and a radio estate running a Release 15 software load will interwork, but only across the feature set they share. Network slicing, some URLLC behaviours and several policy capabilities depend on both ends supporting them. The practical trap is planning a service around a core capability that the installed radio software cannot signal.
The first thing worth doing on any mixed-vendor programme is a straight feature-by-feature matrix: what the core supports, what each RAN vendor’s current load supports, and what the intersection is. Everything outside that intersection is a roadmap dependency on a third party, and needs to be tracked as a programme risk rather than assumed.
3. Voice, and it is always voice
Data over a mixed core and RAN is comparatively straightforward. Voice is where mixed-vendor programmes lose their schedule.
VoNR requires the IMS to interwork with the AMF and SMF, and requires the radio to support the relevant QoS flows and signalling. EPS fallback — moving a device to LTE for the duration of a call — requires correct behaviour across the 5G core, the 5G radio, the 4G radio and the IMS simultaneously, from four potentially different suppliers. Emergency calling with location delivery has to work from every access type, and in most GCC markets that is a regulatory launch condition rather than a nice-to-have.
If you take one thing from this article: on a multi-vendor build, start the voice workstream at the beginning of the programme, not after the core is deployed. It depends on third parties and on device certification, and no amount of resourcing compresses it.
4. Transport and synchronisation underneath
The N2 and N3 interfaces have to be carried. That means the transport layer has to deliver the latency the 5G service targets assume, carry the traffic volume a 5G macro site actually produces, and — critically — deliver accurate timing.
In TDD bands such as n41 and n78, every cell must agree on when it transmits and when it listens. Synchronisation drift does not present as an outage; it presents as rising interference and falling throughput across a cluster, which is far harder to diagnose and can persist for months before anyone attributes it correctly. GPS and IEEE 1588v2 have to be designed in, with holdover behaviour specified, and verified as a named acceptance item.
5. Management, counters and the operations model
This is the one that gets underestimated most consistently. A network where the core reports one set of performance counters and each RAN vendor reports another, with different names and different definitions, cannot be optimised as a single network. Alarms that mean one thing on one vendor’s equipment and something different on another’s are how an operations team learns to ignore alarms.
Counter harmonisation and a single management view are not a post-launch improvement. They belong in the acceptance criteria.
The six concerns operators actually raise
When we sit down with an operator considering a mixed core and RAN, the same six questions come up. They are the right questions.
“When it breaks at 02:00, who do I call?” This is the real concern behind all the others. In a single-vendor network the answer is obvious. In a multi-vendor network, without a named integrator, the answer is that the operator becomes the arbitration forum between its own suppliers — at its own cost, on its own time. The only satisfactory answer is a party that signs against end-to-end KPIs and resolves vendor disagreement without billing you for the argument.
“What happens to my support contracts?” Each vendor supports its own product. Nobody supports the space between them unless somebody is contracted to. That gap is exactly where mixed-vendor faults live.
“Will my existing RAN vendor cooperate?” Usually yes at the interface level, because the interface is standardised and they are obliged to support it. Enthusiasm varies. The practical mitigations are to secure the interoperability testing commitment in writing early, and to have an integrator who has done the campaign before and knows which questions to ask.
“What about upgrades?” A RAN software upgrade can change behaviour at the NG interface. In a single-vendor network the supplier regression-tests that internally. In a multi-vendor network somebody has to run regression testing across the boundary on every significant upgrade. This is an ongoing operational commitment, not a one-off project task, and it should be priced into the operations contract from the start.
“How long does interoperability testing actually take?” For a contained combination with cooperative vendors, weeks. For a full campaign covering voice, fallback, roaming, emergency calling and the device mix, plan in months and start early. Anyone quoting you days has not scoped it.
“Is the saving worth it?” Honestly, sometimes not. If your network is one vendor end to end, performing adequately, and your three-year plan is consumer data, the business case for disaggregating will be thin. The case becomes strong when you are paying single-vendor prices for a core you have outgrown, when your RAN vendor’s core roadmap does not match your enterprise plans, when you need a second source for supply-chain or regulatory reasons, or when you are building greenfield and are not locked in yet.
We would rather tell you the case is thin than sell you a programme that does not pay back.
How Quantum approaches it
Our position is straightforward: the multi-vendor question is not a technology problem, it is an accountability problem. We are vendor-independent, so the recommendation follows the requirement rather than a margin. And we contract against how the network performs end to end, not against whether each component matches its own datasheet.
In practice that means we take on the feature matrix across your existing RAN and the proposed core, the interoperability test campaign against your actual estate, the voice workstream including VoNR and EPS fallback, the transport and synchronisation design, counter and alarm harmonisation into one operations view, acceptance against agreed end-to-end KPIs with defined remedies, and the regression discipline on every subsequent upgrade.
That is the work. The interface was never the hard part.
A sensible way to start
If you are weighing this, the lowest-risk first step is not a procurement exercise. It is a design review: an independent assessment of your existing estate, a feature intersection matrix against a candidate core, an honest view of the voice workstream, and a realistic timeline with the integration risk named. Delivered as a document, with no obligation to build with whoever wrote it.
If the case is not there, you will know in weeks rather than after a purchase order.