NAS & RRC Signalling for Voice Support in 5G NR

Introduction

Voice signalling in 5G is the set of NAS, RRC and NGAP exchanges that decide whether and how a subscriber's voice call is carried. Unlike data, which simply flows on whatever bearer the network grants, voice is a real-time, guaranteed service that the network must explicitly commit to before the UE will trust it. That commitment is assembled during registration and re-checked on every mobility event.

This happens at a very specific moment in the UE lifecycle: right after the UE completes 5GMM registration with the AMF (TS 24.501), and again whenever it moves into a new registration area or performs periodic registration. The verdict is delivered as a single indicator — IMS Voice over PS Session (IMS VoPS) — but that one bit is the compressed output of a UE-capability check (RRC), a RAN-configuration check (the gNB), and a core-network policy check (the AMF), reconciled over the N2 interface.

It matters because the wrong verdict has visible consequences. A voice-centric handset that is told "no voice here" will abandon a perfectly good 5G cell and drop back to LTE; a handset wrongly told "voice works" will attempt VoNR and fail with dead air. Because each input to the verdict lives in a different layer and a different node, a voice problem almost always traces back to one specific parameter — which is exactly why walking them in order is the fastest way to root-cause "why won't this phone do VoNR?"

Why voice signalling is needed

Concretely, voice is a guaranteed-bit-rate, delay-bounded service, and the network cannot silently discover mid-call that it cannot deliver it. Three facts must be established before the UE relies on 5G for voice. First, the handset must be capable — it has to support IMS voice over NR at all, advertised in RRC. Second, the serving cell must be provisioned — IMS voice has to be enabled in the gNB's RAN configuration, with a path to the IMS core. Third, core policy must permit it — subscription and registration-area rules in the AMF must allow voice for this subscriber here. Voice signalling is the machinery that gathers those three facts, reconciles them over N2, and hands the UE a single, honest go/no-go answer.

The Question: VoNR or Fallback?

Every time a UE registers, the network answers one practical question: if this subscriber makes a call right now, can it be carried as IMS voice over the 5G System, or must the call be pushed to LTE? The answer is not a single flag set in one place — it is assembled from several independent facts and then delivered to the UE as a go/no-go verdict, after which the UE applies its own policy.

There are broadly three outcomes. VoNR — the call stays on NR end to end — requires every link to hold: a capable UE, a voice-enabled cell, and an AMF that sets IMS VoPS. EPS Fallback (or the rarer RAT fallback) keeps the UE on 5G for data but moves it to LTE the moment a voice bearer is requested. And no voice at all is what a data-centric UE tolerates when neither path is available. The rest of this page follows the parameters that separate these outcomes, in the order the network evaluates them, then chains them back together.

NAS — IMS VoPS in Registration Accept

The decisive NAS message is REGISTRATION ACCEPT, sent by the AMF to the UE at the end of a successful 5GMM registration (TS 24.501). Inside it is the 5GS network feature support IE, and inside that IE lives the voice verdict.

The IMS Voice over PS Session (IMS VoPS) indication is carried per access type: one bit for 3GPP access (IMS-VoPS-3GPP) and one for non-3GPP access (IMS-VoPS-N3GPP, e.g. voice over Wi-Fi through an N3IWF). When IMS-VoPS-3GPP is set, the AMF is telling the UE that IMS voice is supported over 3GPP access throughout the current registration area. When it is not set, the UE learns it cannot rely on IMS voice here and applies its usage-setting policy — typically staying on, or returning to, E-UTRA for voice.

The same 5GS network feature support IE also carries the emergency-services indicators, which are kept deliberately separate from ordinary voice. The EMC field describes emergency-services support over 3GPP access (emergency PDU sessions in 5GS), and the EMF field describes emergency services fallback — whether the UE must fall back to EPS or E-UTRA/5GC to obtain emergency service. A UE can therefore find that normal voice is unavailable on 5G while emergency calling is still handled through a defined fallback, or vice versa.

The UE is not silent in this exchange. In its REGISTRATION REQUEST it declares its own posture through the 5GMM capability IE and, importantly, its UE usage setting together with its voice domain preference for E-UTRA. Those settings are what turn a single VoPS bit into concrete UE behaviour, and they are important enough to warrant their own section.

Representative NAS log (REGISTRATION ACCEPT) — illustrative, values vary by vendor/build:

UE Usage Setting & Voice Domain Preference

The VoPS bit only matters because the UE has a policy that reacts to it. That policy is captured in two UE settings, both reported to the AMF and both defined so the network can anticipate what the UE will do.

The UE usage setting takes one of two values. A voice-centric UE treats a working voice service as essential: if it cannot obtain IMS voice on the current RAT, it will change RAT — disabling NR and reselecting E-UTRA — to keep voice available, even at the cost of the faster 5G data connection. A data-centric UE does the opposite: it optimises for data and tolerates the absence of voice, remaining on NR even when IMS VoPS is not indicated. This single setting is the reason the same VoPS bit produces opposite behaviour on two different handsets.

The voice domain preference for E-UTRA (and the analogous preference the UE holds for 5GS) expresses whether the UE prefers CS voice, IMS PS voice, or a particular ordering of the two. In a pure 5G/IMS context the relevant preference is for IMS PS voice, but the field carries over from LTE where CS Fallback was still a possibility, and it continues to inform how the UE ranks its options when several are technically available.

UE Voice Capabilities (RRC)

Before the network can promise voice, it must know the handset can actually do it. That comes from RRC UE radio capabilities, defined in TS 38.331 and TS 38.306 and reported in UECapabilityInformation (inside the UE-NR-Capability container). The gNB requests them with UECapabilityEnquiry, or reuses a stored copy the core provides.

The key voice-related capability bits are:

If voiceOverNR is absent, no amount of network support will produce a VoNR call for that UE — capability is a hard gate, checked before anything else. This is the first of the facts the AMF reconciles into the VoPS verdict. Note the asymmetry: voiceOverNR only says the UE can do voice on 5G; the network still has to confirm that voice is available on this cell before the UE is told yes.

Representative RRC log (UECapabilityInformation) — illustrative, values vary by vendor/build:

Network Side — NGAP Indicators over N2

So how does the AMF know whether to set the IMS VoPS bit? It asks the RAN over the N2 interface using NGAP (TS 38.413). Two NGAP parameters carry most of the weight.

The first is the IMS Voice Support Indicator. During UE radio capability handling, the AMF needs to establish whether the serving NG-RAN node can actually carry IMS voice for this UE. The gNB evaluates two things — its own RAN configuration (is IMS voice enabled on this cell, is a voice path provisioned?) and the UE radio capabilities it holds (does the UE report voiceOverNR?) — and answers IMS Voice Support Indicator = supported or not supported. That answer is what ultimately drives the VoPS bit the AMF returns to the UE in NAS.

The second is the RAT/Frequency Selection Priority, carried as the Index to RAT/Frequency Selection Priority (RFSP / RFSP Index). The AMF derives this index from subscription data and local policy and sends it to the gNB; the gNB maps it (by RAN configuration) to frequency-priority profiles that influence idle-mode camping, reselection, and connected-mode mobility. Operators use RFSP to keep — or steer — voice-capable subscribers onto RATs and frequencies where voice is supported, so that a voice-centric UE naturally lands where IMS VoPS will come back set. RFSP is thus the steering counterpart to the yes/no VoPS answer: one says whether voice works here, the other biases the UE toward where it works.

Representative NGAP log (N2) — illustrative, values vary by vendor/build:

Voice Fallback Signalling (RRC & NGAP)

Often the honest answer is "voice, but not on NR right now." The dominant early-deployment reality is EPS Fallback: the UE camps on 5G for data, VoPS is even indicated as supported, but when a voice call is actually triggered the network moves the UE to LTE to carry it. Understanding the exact signalling that performs this move is what separates surface knowledge from real understanding.

The trigger sits in the core: IMS requests a voice QoS flow (a dedicated 5QI 1 flow) via a PDU Session Modification. The gNB receives this over NGAP (a PDU Session Resource Modify request) and decides it cannot, or will not, serve the voice flow on NR. It then reports back toward the core — conceptually a "voice fallback triggered" indication toward the AMF/SMF — and executes one of two RRC actions to push the UE onto E-UTRA:

• Redirection. The gNB sends RRCRelease with redirectedCarrierInfo pointing at an E-UTRA (LTE) carrier. The UE releases the NR connection, reselects to LTE, and continues IMS call setup there. Simpler to deploy, but slower — the UE must reselect and re-establish a connection before the call proceeds.
• Inter-RAT handover. The gNB sends RRCReconfiguration carrying mobilityFromNRCommand — a handover to E-UTRA — moving the UE to LTE in a connected-mode inter-RAT handover. Faster and smoother for the end user, but requires prepared neighbour relations and target-cell coordination.

After the UE arrives on E-UTRA, the call is carried either as VoLTE with the core still 5GC (E-UTRA connected to 5GC) or, in classic EPS Fallback, after a further move into EPS with the EPC. Which of these applies depends on deployment and on the UE's voiceOverEUTRA-5GC capability.

Cell-level system information plays a supporting role. SIB1 carries the cell-suitability, cell-barring and IMS-emergency-support indications the UE uses during reselection, and it advertises which neighbours and frequencies exist. It does not carry a per-UE "VoNR supported" flag — that verdict is per-UE and arrives through NAS — but it shapes which cell the UE lands on when it falls back, and whether emergency calling is offered on a given cell.

Representative RRC log (EPS Fallback by redirection) — illustrative, values vary by vendor/build:

How the Decision Combines

Now put the facts in order. VoNR availability is not decided in one place — it is a chain, and every link must hold. The diagram below shows the three decision inputs (UE capability, gNB cell support, and the NGAP indicator carrying both to the AMF) feeding the AMF's single output: the VoNR-vs-fallback outcome delivered as the IMS VoPS bit.

In one sentence: does this UE get VoNR? = the UE reports voiceOverNR AND the serving cell has IMS voice enabled in RAN config AND the AMF receives IMS Voice Support Indicator = supported over NGAP → the AMF sets IMS VoPS in REGISTRATION ACCEPT → the UE knows voice is available on 5G. Break the capability or cell link and the UE is either steered by RFSP toward a voice-capable RAT or, when a call is actually placed, pushed to LTE via EPS Fallback. If VoPS is not set at all, the UE usage setting decides whether the UE abandons NR for voice or stays for data only.

Key parameters at a glance

Summary

The fastest way to answer "why won't this phone do VoNR?" is to walk the chain and find the first broken link. Start at the verdict — IMS-VoPS-3GPP in the REGISTRATION ACCEPT. If it is set but calls still fail, the issue is per-call (the 5QI 1 flow and EPS Fallback signalling). If it is not set, walk backwards: the NGAP IMS Voice Support Indicator the gNB sent, then the gNB's IMS-voice cell config, then the UE's voiceOverNR capability. Each is in a different node, so knowing which link failed tells you which team owns the fix.

Keep the roles straight: the network states the fact (IMS VoPS), the UE's UE usage setting chooses the reaction, and RFSP biases where the UE lands so the fact comes back favourable. Emergency (EMC/EMF) is scoped separately and must not be read as the normal-voice verdict. And when NR cannot carry voice, the two doors to LTE — redirection (RRCRelease+redirectedCarrierInfo) and inter-RAT handover (RRCReconfiguration+mobilityFromNRCommand) — are where a call either continues cleanly or drops.

Used log-in-hand, the order is: NAS accept → NGAP indicator → RAN config → RRC capability → (on a call) the 5QI 1 modify and any fallback command. The first field that does not line up is your root cause.