End-to-End Registration Call Flow in 5G NR

1. What Registration Is For, and What Triggers It

A UE that has completed Random Access and RRC setup has a radio connection and a C-RNTI. What it does not have is any right to use the network. The gNB does not know whose device it is, cannot bill it, cannot page it when it goes idle, and has no keys with which to protect its traffic. Registration is the procedure that supplies all four: it authenticates the subscriber against the home network, derives a key hierarchy from a secret that never leaves the USIM and the UDM, assigns a temporary identity the network can page, and returns the list of tracking areas and network slices the subscription is allowed to use.

Registration is a NAS procedure between the UE and the AMF TS 24.501 cl. 5.5.1. The gNB is a relay for it: it wraps NAS messages in RRC dedicatedNAS-Message containers on the air interface and in NGAP NAS-PDU IEs on N2, and it never inspects them. The one exception is AS security activation, where the AMF hands the gNB a key it derived and the gNB runs its own RRC-level procedure with that key -- which is why §9 matters even though it is not, strictly, part of Registration.

The registration type is what distinguishes the five reasons a UE runs this procedure, and it is carried in the very first IE of the message:

initial-registration

mobility-registration-updating

periodic-registration-updating

emergency-registration

Table 1. The five reasons a UE sends a Registration Request TS 24.501 cl. 5.5.1.2 and 5.5.1.3. SNPN-onboarding-registration and disaster-roaming-* types were added later; see §18.

2. The Chain Below NAS: Acquisition to RRC_CONNECTED

Nothing in §1 can happen until the UE has found a cell and got an RRC connection up. That chain is five distinct steps, each of which can fail independently and each of which has its own diagnostic signature.

2.1 PLMN and SSB search

The modem starts from stored information if it has any -- the last camped carrier, a stored PLMN-to-frequency map, a stored SSB position -- and falls back to a band-by-band scan of the GSCN raster otherwise. Within a carrier it correlates for PSS, which gives coarse timing and N_ID2 (one of three values), then SSS, which gives N_ID1 (one of 336). Together they give the Physical Cell ID: PCI = 3 x N_ID1 + N_ID2, 0..1007. PSS/SSS also resolve half-frame and symbol boundaries, which is what makes PBCH demodulation possible.

2.2 MIB, then SIB1

PBCH carries a 24-bit BCCH-BCH-Message -- the MIB plus one CHOICE bit -- and the physical layer adds eight more timing bits to make the 32-bit PBCH payload. From it the UE learns subCarrierSpacingCommon, ssb-SubcarrierOffset, dmrs-TypeA-Position, whether the cell is barred, and pdcch-ConfigSIB1, which decomposes into CORESET#0 and searchSpaceZero indices. Those two indices are the entire recipe for finding SIB1: they say where in frequency the control resource set sits relative to the SSB, how many symbols it occupies, and in which slots to monitor for a DCI with CRC scrambled by the SI-RNTI, 0xFFFF. The companion 18 MIB and SIB1 IEs document works that lookup through field by field.

SIB1 then supplies everything the UE needs to decide about the cell and to access it: cellAccessRelatedInfo (which PLMNs, which TAC, which cell identity), cellSelectionInfo (the S-criterion thresholds), servingCellConfigCommon (including rach-ConfigCommon), ue-TimersAndConstants, uac-BarringInfo, and si-SchedulingInfo for everything else. The companion 17 System Information document covers the scheduling side.

2.3 RACH and RRC setup

With rach-ConfigCommon in hand the UE runs contention-based Random Access. MSG3 carries RRCSetupRequest on CCCH; MSG4 carries the UE Contention Resolution Identity MAC CE plus RRCSetup. The companion 03 Random Access document covers all of it. Two details matter here:

• The ue-Identity in RRCSetupRequest is either ng-5G-S-TMSI-Part1 (the first 39 bits of the 48-bit 5G-S-TMSI, if the UE holds a valid 5G-GUTI for this PLMN) or a 39-bit randomValue. When Part1 is used, RRCSetupComplete supplies ng-5G-S-TMSI-Part2 -- the remaining nine bits -- and the gNB reassembles the full value to put in the NGAP 5G-S-TMSI IE, which is what lets it pick the right AMF instead of any AMF.
• establishmentCause in RRCSetupRequest is the gNB's only admission input at this stage. It is derived from the NAS access category (§3.3), so the mapping from "why the UE wants to talk" to "whether the gNB lets it" runs through two independent tables.

3. What the UE Decides Before It Attempts Access

Four independent gates stand between a decoded SIB1 and a transmitted preamble. All four are evaluated from broadcast information only, so a UE that fails any of them leaves no record whatsoever in a gNB log. When a device "will not attach" and the gNB shows nothing, one of these four is almost always the reason.

3.1 PLMN selection

The UE builds a candidate list from the PLMN identities in plmn-IdentityInfoList and matches them against, in priority order: the registered PLMN, the equivalent-PLMN list from the last Registration Accept, the HPLMN (from the USIM's IMSI or the EHPLMN list), the user-controlled PLMN selector, and the operator-controlled selector. A PLMN on the forbidden-PLMN list is skipped entirely. A cell whose TAC places it in a forbidden tracking area is skipped for normal service but remains usable for emergency service.

3.2 Barring and the S-criterion

cellBarred in the MIB is absolute -- a barred cell is excluded for 300 seconds, and intraFreqReselection decides whether the exclusion spreads to other cells on the same frequency. Then the cell must be suitable, which means both parts of the S-criterion must be satisfied TS 38.304 cl. 5.2.3.2:

Srxlev = Q_rxlevmeas - (q-RxLevMin + q-RxLevMinOffset)
                     - Pcompensation - Qoffset_temp        > 0

Squal  = Q_qualmeas  - (q-QualMin  + q-QualMinOffset)
                     - Qoffset_temp                        > 0

  Q_rxlevmeas    measured SS-RSRP of the cell                   [dBm]
  Q_qualmeas     measured SS-RSRQ of the cell                   [dB]
  q-RxLevMin     SIB1 cellSelectionInfo, INTEGER (-70..-22),
                 UNIT = 2 dBm  ->  actual dBm = 2 x field value
  q-QualMin      SIB1 cellSelectionInfo, INTEGER (-43..-20), 1 dB steps
  Pcompensation  max(P_EMAX - P_PowerClass, 0)                  [dB]
  Qoffset_temp   0, or connEstFailOffset after repeated setup failures

3.3 Unified access control

The last gate is UAC TS 38.331 cl. 5.3.14. NAS maps the reason for this particular access attempt to one of the standardised access categories and supplies the UE's access identities; RRC then checks them against uac-BarringInfo from SIB1. The two dimensions do different jobs: access identity is about who the subscriber is and can exempt them outright, while access category is about what the attempt is for and is subject to a probabilistic barring factor.

Table 2. Standardised access categories TS 24.501 cl. 4.5.2. The categories the UE actually uses depend on what the NAS layer is trying to do, so the same radio conditions produce different barring outcomes for different applications.

4. Registration Types and the 5GMM State Machine

The state machine is small, but two of its properties drive most real-world confusion. First, a failed registration update leaves the UE in 5GMM-DEREGISTERED with whatever forbidden-list side effects the cause code specified (§15) -- so a UE that was working can end up worse than a UE that has just been switched on. Second, the AMF's implicit de-registration is invisible to the UE: the UE believes it is REGISTERED, the AMF has discarded the context, and the mismatch is discovered only when the UE next transmits and gets 5GMM cause #10.

5GMM-NULL

5GMM-DEREGISTERED

5GMM-REGISTERED-INITIATED

5GMM-REGISTERED

5GMM-SERVICE-REQUEST-INITIATED

5GMM-DEREGISTERED-INITIATED

Table 3. UE 5GMM states TS 24.501 cl. 5.1.3.1. The substates of 5GMM-DEREGISTERED and 5GMM-REGISTERED (for example ATTEMPTING-REGISTRATION, NO-CELL-AVAILABLE, LIMITED-SERVICE, UPDATE-NEEDED) carry most of the useful diagnostic information and are worth logging explicitly.

5. Identities: SUPI, SUCI, 5G-GUTI, 5G-S-TMSI

5G deliberately never sends a permanent subscriber identity over the air in the clear -- the single biggest privacy change from LTE, where a plain IMSI in an Attach Request was routine and IMSI catchers exploited it. The cost is a chain of four identities that each exist for a different lifetime and are visible at a different place in the network.

Table 4. Identity inventory TS 23.003 cl. 2.2 and 2.10. Note that no single node sees all of these: the gNB never sees SUPI or SUCI content, and the AMF never sees the C-RNTI.

5.1 SUCI concealment schemes

The SUCI conceals only the subscriber-unique part of the SUPI. MCC and MNC stay in the clear -- they have to, or no visited network could route the authentication request home. So does the routing indicator, one to four decimal digits that tell the AMF which AUSF/UDM instance in the home network holds this subscriber. Everything after that is encrypted under the home operator's public key using ECIES.

null-scheme

Table 5. SUCI protection schemes TS 33.501 Annex C. The scheme is chosen by the home operator and provisioned on the USIM; the visited network has no say and no visibility.

5.2 Why the 48-bit 5G-S-TMSI is split across two messages

RRCSetupRequest has to fit in a 48-bit CCCH SDU, because that is exactly what the UE Contention Resolution Identity MAC CE echoes back in MSG4 TS 38.321 cl. 6.1.3.3. The 48 bits are fully spent:

6. The Registration Request, IE by IE

The Registration Request is a 5GMM message with an unusual property: it is normally sent before NAS security exists, so it is transmitted with no outer security header at all. Once a security context is available the same message is sent inside a security-protected container, and -- this is the part that catches people -- a partially ciphered form exists too, where the mandatory IEs are in the clear and the sensitive optional ones are repeated inside a ciphered NAS message container IE.

5GS registration type

ngKSI

5GS mobile identity

5GMM capability

UE security capability

Requested NSSAI

Last visited registered TAI

UE's usage setting

Requested DRX parameters

NAS message container

Table 6. Registration Request IEs TS 24.501 cl. 8.2.6, abridged to the ones that change behaviour. M = mandatory, O = optional. LV-E = length-value with a two-octet length, needed because a Profile B SUCI does not fit a one-octet length.

7. Primary Authentication: 5G-AKA End to End

5G-AKA is a challenge-response protocol built on a symmetric key K that exists in exactly two places: the USIM and the home network's UDM/ARPF. It never crosses any interface. Everything else in the key hierarchy is derived from it, and the derivations are deliberately arranged so that each network function receives only the keys it needs.

7.1 What the network computes

The UDM/ARPF generates an authentication vector from K and a fresh sequence number:

RAND

AUTN

XRES*

HXRES*

K_AUSF

K_SEAF

Table 7. Authentication vector contents TS 33.501 cl. 6.1.3.2 and Annex A. The serving network name -- of the form 5G:mnc<MNC>.mcc<MCC>.3gppnetwork.org -- is mixed into every derivation, which is what binds the resulting keys to one PLMN.

7.2 What the UE computes

The USIM checks MAC-A first. If MAC-A is wrong the challenge did not come from a network that knows K, and the UE answers with an Authentication Failure carrying 5GMM cause #20 MAC failure and starts T3520. If MAC-A is right but SQN is outside the acceptance window, the challenge is genuine but stale -- a replay, or a home-network sequence-number desynchronisation -- and the UE answers with cause #21 Synch failure plus an AUTS token that lets the UDM resynchronise. The distinction is diagnostically enormous:

Table 8. Authentication failure taxonomy TS 24.501 cl. 5.4.1.3.7. #20 and #21 look the same in a summary counter and have completely different fixes.

7.3 EAP-AKA'

The alternative primary authentication method, EAP-AKA' TS 33.501 cl. 6.1.3.1, carries the same underlying AKA exchange inside EAP, transported in the EAP message IE of the NAS Authentication Request and Response. Structurally the difference that matters when reading logs is that the AUSF becomes the EAP server and the AMF a pure pass-through, so the exchange can take more than one round trip and the AMF never sees a RES* at all. Which method is used is decided by the UDM per subscriber; the UE must support both.

8. The Key Hierarchy and What Each Key Protects

K_AUSF

K_SEAF

K_AMF

K_gNB

K_N3IWF

Table 9. Key roles TS 33.501 cl. 6.2. Note that the gNB holds only K_gNB and its four children; a compromised gNB cannot derive anything above itself, which is the whole point of the two-anchor design.

9. Security Activation: NAS First, Then AS

9.1 NAS Security Mode Command

The Security Mode Command is the first message the AMF sends that is integrity-protected with the new K_NASint, using security header type 3. It carries three things the UE must check:

The selected NAS algorithms -- one integrity algorithm (5G-IA0..IA7) and one ciphering algorithm (5G-EA0..EA7). 5G-IA0 (null integrity) is permitted only for unauthenticated emergency service.

The replayed UE security capabilities -- byte-for-byte what the UE sent in its Registration Request. If they do not match what the UE actually sent, an attacker has modified the unprotected Registration Request to force a weaker algorithm, and the UE must respond with Security Mode Reject, 5GMM cause #23 UE security capabilities mismatch.

The ngKSI naming the key set, and the ABBA parameter, whose value is mixed into K_AMF and exists so that a future release can bind the key to a set of security features without changing the message format.

The UE answers with Security Mode Complete, which is the first NAS message that is both ciphered and integrity-protected. It optionally carries the IMEISV, because the AMF cannot ask for a permanent equipment identity until it has a protected channel on which to receive one.

9.2 Initial Context Setup and AS security

With NAS security up, the AMF derives K_gNB and sends the gNB an NGAP INITIAL CONTEXT SETUP REQUEST TS 38.413 cl. 9.2.2.1. This is the message that creates the UE context at the gNB proper -- before it, the gNB was holding a UE it knew almost nothing about.

Table 10. INITIAL CONTEXT SETUP REQUEST, abridged. Piggybacking the Registration Accept in the NAS-PDU IE saves a full N2 round trip and is what most AMFs do.

10. Registration Accept, Complete, and What the UE Then Holds

Registration Accept is the payoff. Everything before it was proving identity; this message is where the network states the terms of service.

5GS registration result

5G-GUTI

TAI list

Allowed NSSAI

Rejected NSSAI

Configured NSSAI

Equivalent PLMNs

T3512 value

T3502 value

5GS network feature support

Negotiated DRX parameters

Service area list

Operator-defined access category definitions

Table 11. Registration Accept IEs TS 24.501 cl. 8.2.7, abridged. Note how many are optional: an Accept can be as short as four octets of header plus a registration result, and the UE then keeps everything it had before.

The UE returns Registration Complete only if the Accept assigned a new 5G-GUTI (or carried an SOR transparent container that needs acknowledging). A trace with no Registration Complete is therefore not necessarily broken -- check whether a 5G-GUTI was present first.

11. PDU Session Establishment

Registration gives the UE an identity, keys and reachability. It gives it no data path at all. A PDU session is a separate 5GSM procedure TS 24.501 cl. 6.4.1, carried in NAS messages that the AMF forwards to an SMF, and it is the procedure that actually creates a DRB over the air.

Integrity protection maximum data rate

PDU session type

SSC mode

5GSM capability

Table 12. PDU Session Establishment Request, abridged TS 24.501 cl. 8.3.1. The Requested NSSAI from Registration and the S-NSSAI here are different IEs at different layers and can legitimately disagree.

12. Timing Budget and Worked Arithmetic

Table 13. Phase-by-phase budget. All values are approximate and deployment-dependent; the ratios are more informative than the absolutes.

13. Timers, Counters and Retry Behaviour

T3510

T3511

T3502

T3512

T3517

T3519

T3520

T3521

T3346

T3247

T3540

Table 14. NAS timers relevant to registration TS 24.501 Table 10.2.1. Defaults are the specification defaults; a network may override T3502, T3512, T3346 and T3448 by signalling them.

13.1 The RRC timers that bound the same procedure

T300

T301

T302

T310

T311

T319

T390

Table 15. UE-TimersAndConstants from SIB1 TS 38.331. These are cell-wide defaults; a dedicated RRCReconfiguration can override some of them per UE.

14. Failure Modes and What Each One Means

Table 16. Eighteen distinct ways registration fails, ordered roughly by how early in the chain they occur. The five rows above preambleTransMax all leave the gNB log empty.

15. 5GMM Reject Causes and Their Lasting Effects

A Registration Reject is not just a failure -- it is an instruction. Most causes tell the UE to write something to a persistent list, and that list entry survives the reject, often survives cell reselection, and sometimes survives a power cycle. This is why a single mis-provisioned subscriber record can make a device appear permanently broken on a network that is working fine for everyone else.

Table 17. 5GMM cause values for registration TS 24.501 cl. 9.11.3.2 and Annex A. The third column is what makes these causes matter long after the message that carried them.

16. Message Structures: ASN.1 and NAS Encodings

The registration chain crosses three encodings: RRC ASN.1 with unaligned PER on the air interface, NAS with hand-rolled TLV in the dedicatedNAS-Message container, and NGAP ASN.1 with aligned PER on N2. The abridged structures below are the ones worth being able to read directly.

-- TS 38.331, the RRC carriers for NAS ----------------------------------

RRCSetupRequest-IEs ::= SEQUENCE {
    ue-Identity                  InitialUE-Identity,
    establishmentCause           EstablishmentCause,
    spare                        BIT STRING (SIZE (1))
}

InitialUE-Identity ::= CHOICE {
    ng-5G-S-TMSI-Part1           BIT STRING (SIZE (39)),
    randomValue                  BIT STRING (SIZE (39))
}

EstablishmentCause ::= ENUMERATED {
    emergency, highPriorityAccess, mt-Access, mo-Signalling,
    mo-Data, mo-VoiceCall, mo-VideoCall, mo-SMS,
    mps-PriorityAccess, mcs-PriorityAccess,
    spare6, spare5, spare4, spare3, spare2, spare1
}

RRCSetupComplete-IEs ::= SEQUENCE {
    selectedPLMN-Identity        INTEGER (1..maxNrofPLMNs),
    registeredAMF                RegisteredAMF          OPTIONAL,
    guami-Type                   ENUMERATED {native, mapped} OPTIONAL,
    s-NSSAI-List                 SEQUENCE (SIZE (1..maxNrofS-NSSAI))
                                     OF S-NSSAI         OPTIONAL,
    dedicatedNAS-Message         DedicatedNAS-Message,      -- the NAS PDU
    ng-5G-S-TMSI-Value           CHOICE {
        ng-5G-S-TMSI             BIT STRING (SIZE (48)),
        ng-5G-S-TMSI-Part2       BIT STRING (SIZE (9))
    }                                                   OPTIONAL,
    ...
}

RegisteredAMF ::= SEQUENCE {
    plmn-Identity                PLMN-Identity          OPTIONAL,
    amf-Identifier               AMF-Identifier             -- BIT STRING (24)
}

SecurityModeCommand-IEs ::= SEQUENCE {
    securityConfigSMC SEQUENCE {
        securityAlgorithmConfig  SecurityAlgorithmConfig,
        ...
    },
    ...
}

SecurityAlgorithmConfig ::= SEQUENCE {
    cipheringAlgorithm           CipheringAlgorithm,    -- nea0..nea3
    integrityProtAlgorithm       IntegrityProtAlgorithm OPTIONAL,
    ...                                                 -- nia0..nia3
}

Listing 1. Abridged from TS 38.331. ... marks omitted extension markers and members. DedicatedNAS-Message is an OCTET STRING as far as RRC is concerned -- the whole point of the container.

-- TS 38.413, the N2 carriers ------------------------------------------

InitialUEMessage ::= SEQUENCE {
    protocolIEs  ProtocolIE-Container { {InitialUEMessage-IEs} },
    ...
}
  id-RAN-UE-NGAP-ID           RAN-UE-NGAP-ID          -- INTEGER (0..2^32-1)
  id-NAS-PDU                  NAS-PDU                 -- OCTET STRING
  id-UserLocationInformation  UserLocationInformation -- NR-CGI + TAI
  id-RRCEstablishmentCause    RRCEstablishmentCause
  id-FiveG-S-TMSI             FiveG-S-TMSI            -- optional
  id-AMFSetID                 AMFSetID                -- optional
  id-UEContextRequest         UEContextRequest         -- optional
  id-AllowedNSSAI             AllowedNSSAI            -- optional
  id-SelectedPLMNIdentity     PLMNIdentity            -- optional

InitialContextSetupRequest ::= SEQUENCE { ... }
  id-AMF-UE-NGAP-ID           AMF-UE-NGAP-ID
  id-RAN-UE-NGAP-ID           RAN-UE-NGAP-ID
  id-GUAMI                    GUAMI
  id-UEAggregateMaximumBitRate  UEAggregateMaximumBitRate
  id-AllowedNSSAI             AllowedNSSAI
  id-UESecurityCapabilities   UESecurityCapabilities
  id-SecurityKey              SecurityKey             -- BIT STRING (256) = K_gNB
  id-MobilityRestrictionList  MobilityRestrictionList -- optional
  id-MaskedIMEISV             MaskedIMEISV            -- optional
  id-NAS-PDU                  NAS-PDU                 -- optional
  id-PDUSessionResourceSetupListCxtReq  ...           -- optional

Listing 2. NGAP IE inventory for the two messages that matter most here, abridged. The SecurityKey IE is literally K_gNB -- the only key material that ever crosses N2 towards the RAN.

17. Illustrative Message Traces

One scenario runs through §17.1 to §17.5: a UE with no stored context registering on PLMN 310-410, cell PCI 217, C-RNTI 0x4C21, RAN UE NGAP ID 4711. §17.6 and §17.7 are alternative endings to the same beginning.

17.1 RRCSetupComplete carrying the first NAS message

09:41:12.318  [RRC-UL] SRB1 / DCCH  C-RNTI 0x4C21  PCI 217
  UL-DCCH-Message
   c1: rrcSetupComplete
    rrc-TransactionIdentifier ......... 0
    criticalExtensions: rrcSetupComplete
     selectedPLMN-Identity ............ 1      -- 1st entry of
                                               -- plmn-IdentityInfoList
     registeredAMF .................... (absent) -- no prior registration
     guami-Type ....................... (absent)
     s-NSSAI-List ..................... (absent)
     ng-5G-S-TMSI-Value ............... (absent) -- MSG3 used randomValue
     dedicatedNAS-Message ............. 68 bytes
       7e 00 41 79 00 0d 01 05 f0 10 14 f0 ff ff ff ff
       ff 2e 04 f0 f0 f0 f0 2f 05 04 01 00 00 01 ...

  -- The gNB does not parse dedicatedNAS-Message. It copies the octet
  -- string into the NGAP NAS-PDU IE unchanged. Any decode of the NAS
  -- content in a gNB trace comes from the analyser, not the gNB.

Listing 3. RRCSetupComplete. selectedPLMN-Identity is an index into SIB1's list, not a PLMN value -- resolving it requires the SIB1 from the same cell.

17.2 The Registration Request, decoded

09:41:12.318  [NAS-UL] 5GMM, plain (security header type 0)
  Extended protocol discriminator ..... 0x7E  5GS mobility management
  Security header type ................ 0     plain NAS message
  Message type ........................ 0x41  Registration Request
  5GS registration type
    Follow-On Request pending ......... 0     no immediate UL data
    value ............................. 1     initial-registration
  ngKSI
    TSC ............................... 0     native security context
    key set identifier ................ 7     no key is available
  5GS mobile identity  (length 0x000D = 13 octets)
    type of identity .................. 1     SUCI
    SUPI format ....................... 0     IMSI
    MCC / MNC ......................... 310 / 410
    routing indicator ................. 0000  -- not provisioned; AMF
                                              -- selects any AUSF
    protection scheme id .............. 0     null-scheme
    home network public key id ........ 0
    scheme output (MSIN, cleartext) ... <redacted in this document>
  5GMM capability
    S1 mode ........................... 1     EPS interworking supported
    HO attach ......................... 1
    LPP ............................... 1
    5G-CP CIoT / N3 data .............. 0 / 0
  UE security capability
    5G-EA0 5G-EA1 5G-EA2 5G-EA3 ....... 1 1 1 0   -- NEA0/128-NEA1/2
    5G-IA0 5G-IA1 5G-IA2 5G-IA3 ....... 0 1 1 0   -- 128-NIA1/2, no null
    EPS algorithms .................... present
  Requested NSSAI
    S-NSSAI[0]  SST 1                           -- eMBB
    S-NSSAI[1]  SST 2  SD 0x000001              -- URLLC + differentiator
  UE's usage setting .................. data-centric
  Requested DRX parameters ............ 128 frames (1.28 s)
  PDU session status .................. 0x0000  -- nothing established

  -- ngKSI 7 + SUCI + PDU session status all-zero is the signature of a
  -- genuine cold start. Any one of the three being different means the
  -- UE thinks it has history.

Listing 4. A cold-start Registration Request. The null-scheme SUCI here is shown to keep the octet accounting readable; a production USIM would normally use Profile A or B (§5.1).

17.3 NGAP INITIAL UE MESSAGE

09:41:12.322  [NGAP-UL] procedureCode 15 (InitialUEMessage), initiatingMessage
  RAN-UE-NGAP-ID ...................... 4711
  NAS-PDU ............................. 68 bytes (opaque)
  UserLocationInformation: userLocationInformationNR
    nR-CGI
      pLMNIdentity .................... 310-410
      nRCellIdentity .................. 0x01A2B3C40   -- 36 bits
    tAI
      pLMNIdentity .................... 310-410
      tAC ............................. 0x4A2F1       -- 24 bits
    timeStamp ....................... 2026-xx-xx 09:41:12
  RRCEstablishmentCause ............... mo-Signalling
  FiveG-S-TMSI ........................ (absent)
  AMFSetID ............................ (absent)
  UEContextRequest .................... requested
  SelectedPLMNIdentity ................ 310-410

  -- With no FiveG-S-TMSI and no AMFSetID the gNB had no routing hint and
  -- selected an AMF from its own NG Setup state (weight factors per
  -- GUAMI). This is normal for a cold start and abnormal for a UE that
  -- was registered five minutes ago -- see the trap in S5.2.

Listing 5. INITIAL UE MESSAGE. UEContextRequest = requested is the gNB asking the AMF to set up the full UE context immediately rather than only relaying NAS.

17.4 Authentication and NAS security

09:41:12.401  [NAS-DL] Authentication Request  (plain, hdr type 0)
  ngKSI  TSC 0  key set identifier 0    -- new native context, id 0
  ABBA  length 2  value 0x0000
  Authentication parameter RAND ....... 16 octets
  Authentication parameter AUTN ....... 16 octets
    SQN xor AK .......................  6 octets
    AMF field ........................  2 octets  0x8000  -- AMF sep bit
    MAC-A ............................  8 octets

09:41:12.448  [NAS-UL] Authentication Response  (plain)
  Authentication response parameter
    RES* ............................. 16 octets
  -- USIM returned RES after verifying MAC-A and SQN. The ME, not the
  -- USIM, computed RES* from CK||IK, the SN-name and RAND.

09:41:12.472  [NAS-DL] Security Mode Command  (hdr type 3: integrity
                        protected with NEW 5G NAS security context)
  MAC ................................ 4 octets
  Sequence number .................... 0x00
  Selected NAS security algorithms
    ciphering ........................ 128-5G-EA2
    integrity ........................ 128-5G-IA2
  ngKSI  TSC 0  ksi 0
  Replayed UE security capability ..... e0 60 e0 60
  IMEISV request ...................... requested
  ABBA ................................ 0x0000

09:41:12.489  [NAS-UL] Security Mode Complete  (hdr type 4: integrity
                        protected and ciphered with NEW context)
  MAC ................................ 4 octets
  Sequence number .................... 0x00
  IMEISV ............................. <redacted in this document>

  -- Check the replayed capability against S17.2 byte for byte:
  --   sent     e0 60 e0 60
  --   replayed  e0 60 e0 60    match -> no bid-down, proceed

Listing 6. 5G-AKA and NAS security activation. The security header type moves 0 -> 3 -> 4, which is the cleanest single field for locating the security boundary in a NAS trace.

17.5 Registration Accept

09:41:12.601  [NGAP-DL] InitialContextSetupRequest
  AMF-UE-NGAP-ID ...................... 8801
  RAN-UE-NGAP-ID ...................... 4711
  GUAMI  310-410  region 0x02  set 0x001  pointer 0x00
  UEAggregateMaximumBitRate  DL 1000000000  UL 300000000
  AllowedNSSAI  { SST 1 }
  UESecurityCapabilities
    nRencryptionAlgorithms ............ 0xC000  -- 128-NEA1, NEA2
    nRintegrityProtectionAlgorithms ... 0xC000  -- 128-NIA1, NIA2
  SecurityKey ......................... 256 bits  (K_gNB)
  MobilityRestrictionList
    servingPLMN ....................... 310-410
  NAS-PDU ............................. 51 bytes  (Registration Accept)

09:41:12.639  [NAS-DL] Registration Accept  (hdr type 2: integrity
                        protected and ciphered)
  5GS registration result
    value ............................. 1   3GPP access
    SMS over NAS allowed .............. 0
  5G-GUTI
    MCC / MNC ......................... 310 / 410
    AMF Region ID ..................... 0x02
    AMF Set ID ........................ 0x001
    AMF Pointer ....................... 0x00
    5G-TMSI ........................... 0x0C41A97E
  TAI list  (list type: list of TACs belonging to one PLMN)
    PLMN 310-410  TAC 0x4A2F1, 0x4A2F2, 0x4A2F3
  Allowed NSSAI
    S-NSSAI[0]  SST 1
  Rejected NSSAI
    S-NSSAI  SST 2  SD 0x000001
      cause ........................... S-NSSAI not available in the
                                        current registration area
  5GS network feature support
    IMS-VoPS-3GPP ..................... 1
    EMC ............................... 1  emergency over 3GPP supported
    IWK-N26 ........................... 1  interworking with EPS
  T3512 value ......................... 54 min
  Negotiated DRX parameters ........... 128 frames

09:41:12.658  [NAS-UL] Registration Complete   -- sent because a new
                                               -- 5G-GUTI was assigned
09:41:12.658  [5GMM] state -> 5GMM-REGISTERED, T3510 stopped,
                     T3512 started (54 min)

Listing 7. Accept, with a rejected slice. The UE is fully registered and one of its two requested slices is unusable in this registration area -- it may become available after a mobility registration update elsewhere, which is the difference between this cause and "not available in the PLMN".

17.6 Failure path: registration rejected

09:52:03.117  [NGAP-UL] InitialUEMessage  RAN-UE-NGAP-ID 4712
                        tAC 0x4A2F1  RRCEstablishmentCause mo-Signalling
09:52:03.140  [NAS-DL] Registration Reject  (plain -- no security context
                        was ever established, so the reject cannot be
                        protected)
  Message type ........................ 0x44  Registration Reject
  5GMM cause .......................... 0x0C  #12 Tracking area not
                                              allowed
  T3502 value ......................... (absent) -> UE default 12 min
  T3346 value ......................... (absent)

09:52:03.144  [RRC-DL] RRCRelease
  releaseCause ........................ other
  redirectedCarrierInfo ............... (absent)

09:52:03.145  [5GMM] cause #12 handling per TS 24.501 cl. 5.5.1.2.5:
               - store TAI 310-410-4A2F1 in 'forbidden tracking areas
                 for regional provision of service'
               - reset the registration attempt counter
               - state -> 5GMM-DEREGISTERED.LIMITED-SERVICE
               - start T3247 (30..60 min, randomised)
               - search for a cell in a different TA of PLMN 310-410
09:52:03.145  [RRC]  cell PCI 217 is still a *suitable* cell by the
                     S-criterion. It is excluded by NAS, not by RRC.

  -- This is the shape of the problem: RRC keeps telling NAS the cell is
  -- fine, NAS keeps refusing it, and no radio measurement explains it.
  -- The answer is always in the forbidden lists.

Listing 8. A reject on cause #12 and everything it sets in motion. Note that the reject is unprotected: the UE has no way to verify it, which is precisely why T3247 exists.

17.7 Failure path: authentication synch failure

10:07:44.812  [NAS-DL] Authentication Request  ngKSI 1  RAND/AUTN present
10:07:44.851  [NAS-UL] Authentication Failure
  Message type ........................ 0x59  Authentication Failure
  5GMM cause .......................... 0x15  #21 Synch failure
  Authentication failure parameter (AUTS)  14 octets
  -- MAC-A verified correctly. Only SQN was outside the USIM's window,
  -- so K, OPc and the SN-name binding are all correct.
10:07:44.851  [5GMM] T3520 started (15 s)

10:07:44.998  [NAS-DL] Authentication Request  ngKSI 1
  -- new RAND/AUTN, generated after the UDM resynchronised from AUTS
10:07:45.036  [NAS-UL] Authentication Response  RES* present
10:07:45.036  [5GMM] T3520 stopped
10:07:45.061  [NAS-DL] Security Mode Command  ngKSI 1

  -- One #21 followed by success is benign and self-healing. A #21 on
  -- every attempt means the UDM is not consuming AUTS -- check that the
  -- resynchronisation path from AUSF to UDM is actually wired up. A #20
  -- in the same position means something entirely different (S7.2).

Listing 9. A sequence-number desynchronisation resolving itself. The diagnostic value is entirely in the cause code: #21 exonerates the key material, #20 indicts it.

18. Release Deltas: Rel-15 to Rel-18

Table 18. Registration-relevant changes by release. Whether a UE supports any of these is visible in 5GMM capability and in the UE capability exchange -- see the companion 26 UE Capability document.

19. Reading Registration in Logs: A Checklist

1. Establish whether the UE ever transmitted. If there is no preamble in the gNB log, the failure is in §3 -- SIB1 acquisition, the S-criterion, or UAC barring -- and no amount of core-network investigation will find it. Get the UE-side view of the cell before anything else.

2. Read the registration type and `ngKSI` together. initial-registration with ngKSI 7 and a SUCI is a cold start. Anything else -- periodic-registration-updating, or an initial registration with a 5G-GUTI -- means the UE believes it has history, and the interesting question becomes whether the AMF agrees.

3. Check that the identity in the Request matches the routing. A SUCI with no routing indicator, or a 5G-GUTI whose AMF Set ID does not match the AMF that answered, explains a surprising amount of otherwise inexplicable re-authentication.

4. Locate the security boundary. In a NAS trace, follow the security header type: 0 (plain) up to the Security Mode Command, then 3, then 4, then 2 for everything afterwards. A message with the wrong header type for its position is either a decoder artefact or a genuine context mismatch.

5. Compare the replayed UE security capabilities byte for byte against what the Registration Request actually contained. This is a two-second check that detects both bid-down attempts and AMF re-encoding bugs, and nothing else detects either.

6. Distinguish 5GMM causes from 5GSM causes. Same numeric space, different meanings, different owners. #67 from an AMF and #67 from an SMF are unrelated problems.

7. On any reject, write down what the UE was told to store. The reject message is transient; the forbidden-PLMN or forbidden-TAI entry it creates is what you will actually be debugging an hour later (§15).

8. For authentication failures, read the cause before anything else. #20 means the key material is wrong. #21 means the key material is right and only the counter drifted. #26 means the method was wrong. These have three different owners.

9. Check whether Registration Complete was expected. No new 5G-GUTI in the Accept means no Complete, and its absence is not a failure.

10. Separate registration from session establishment. A UE in 5GMM-REGISTERED with no PDU session and no data is behaving correctly. Look for a 5GSM cause, an empty Allowed NSSAI, or a Service area list that grants signalling only.

11. Correlate the RAN UE NGAP ID and AMF UE NGAP ID across both logs. They are the only identifiers common to the gNB and AMF views; the C-RNTI never reaches the AMF and the 5G-GUTI is not present in early messages.

12. Time-stamp the T3510 window. If the Registration Request and the next downlink NAS message are more than 15 seconds apart, the UE has already abandoned the procedure and anything after that point belongs to the next attempt, not this one.

20. Glossary

21. References

• 3GPP TS 24.501 -- Non-Access-Stratum (NAS) protocol for 5G System (5GS). Clause 4.5.2 (access categories), 5.1.3 (5GMM states), 5.3.23 (T3247 and forbidden-list handling), 5.4.1 (authentication), 5.4.2 (identification), 5.4.3 (security mode control), 5.5.1 (registration), 5.5.2 (de-registration), 6.4.1 (UE-requested PDU session establishment), 8.2.6 (Registration Request), 8.2.7 (Registration Accept), 8.2.9 (Registration Reject), 9.1 (NAS message headers), 9.11.3.2 (5GMM cause), 9.11.3.4 (5GS mobile identity), Table 10.2.1 (timers), Annex A (cause value summary).
• 3GPP TS 33.501 -- Security architecture and procedures for 5G System. Clause 6.1.2 (initiation of authentication and method selection), 6.1.3.1 (EAP-AKA'), 6.1.3.2 (5G-AKA), 6.2 (key hierarchy and derivation), 6.4 (NAS security), 6.5 (AS security), 6.7 (security mode command procedures), Annex A (key derivation functions), Annex C (SUCI protection schemes).
• 3GPP TS 23.502 -- Procedures for the 5G System. Clause 4.2.2.2 (registration procedures), 4.3.2 (PDU session establishment), 4.2.3 (service request).
• 3GPP TS 23.003 -- Numbering, addressing and identification. Clause 2.2 (IMSI and SUPI), 2.2B (SUCI), 2.10 (5G-GUTI, 5G-S-TMSI, GUAMI), 19.4 (NAI formats).
• 3GPP TS 38.331 -- RRC protocol specification. Clause 5.2.2 (system information acquisition and the barring-on-SIB1-failure rule), 5.3.3 (RRC connection establishment), 5.3.4 (initial security activation), 5.3.14 (unified access control), RRCSetupRequest, RRCSetupComplete, SecurityModeCommand, UE-TimersAndConstants.
• 3GPP TS 38.304 -- UE procedures in idle mode and RRC inactive state. Clause 5.2.2 (cell selection), 5.2.3.2 (cell selection criteria S).
• 3GPP TS 38.413 -- NG Application Protocol (NGAP). Clause 8.2.1 (Initial Context Setup), 8.6.2 (Initial UE Message), 9.2.5.1 (INITIAL UE MESSAGE IEs), 9.3.1 (IE definitions including Security Key, GUAMI, Allowed NSSAI, Mobility Restriction List).
• 3GPP TS 38.321 -- NR MAC protocol specification. Clause 5.1 (random access), 6.1.3.3 (UE Contention Resolution Identity MAC CE).
• 3GPP TS 22.261 -- Service requirements for the 5G system, for the access identity and access category definitions that UAC implements.

Companion documents in this set

• 02 Radio Frame Structure -- SFN, half-frames and SSB positions, the timing the UE recovers in §2.1.
• 03 Random Access -- MSG1 to MSG4 in full, including the 48-bit CCCH SDU that §5.2 accounts for.
• 13 RRC Overview / 14 RRC States / 15 RRC Procedures -- the RRC side of §2.3 and §9.2, and the state model registration is independent of.
• 16 RLM and RLF -- what T310, T311, N310 and N311 in §13.1 actually do.
• 17 System Information -- how SIB1 and the other SIBs are scheduled and re-acquired, and the SI-window wait that dominates §12.
• 18 MIB and SIB1 IEs -- field-by-field on the two messages §2.2 depends on, including the worked CORESET#0 lookup and the cell-selection arithmetic of §3.2.
• 19 Paging -- how the 5G-GUTI assigned in §10 is used to reach an idle UE, and what the negotiated DRX parameters mean.
• 26 UE Capability -- the capability exchange that usually follows Initial Context Setup, and the RACS alternative noted in §18.
• 27 AS Security Mode -- the RRC-level procedure of §9.2 in detail, including key refresh and the K_gNB / NH chain.