Skip to content

Initial Registration

Difficulty: Intermediate / Estimated study time: 40 min / Scope: Initial Registration only / Related NFs: AMF, AUSF, UDM, PCF / Related Interfaces: N1, N2, N8, N12, N13, N15

Learning objectives

After reading this page, you will be able to:

  • Explain the Why (why a UE must register with the network) as the prerequisite for incoming calls, outgoing calls, and data communication.
  • Explain, in order, the broad steps of Initial Registration (registration request → identity verification → security establishment → subscriber data retrieval → registration accept).
  • Follow the Call Flow of Initial Registration in the order the actors appear: UE / (R)AN / AMF / AUSF / UDM.
  • Explain what the key Messages and key IEs — Registration Request / Authentication / Security Mode / Registration Accept, etc. — are for.
  • Explain the 5GMM state transitions (DEREGISTERED → REGISTERED-INITIATED → REGISTERED) with a diagram.
  • Use Wireshark Display Filters to analyze the registration procedure's packets (the structure of NAS nested inside NGAP).
  • Isolate typical registration failures, such as authentication failure, GUTI mismatch, NG Setup not established, and unprovisioned subscribers.
  • Contrast the differences between the 4G (EPC) Attach procedure and 5G Initial Registration.

Prerequisites

It will go more smoothly if you understand the following first. If you are not there yet, start from the Curriculum.

  • SBA / NF (the ideas of Service Based Architecture and Network Function) → NF Dictionary
  • N1 / N2 (the UE⇔AMF and gNB⇔AMF interfaces) → N1 / N2
  • NAS / NGAP (the control protocol carried over N1, and the radio-node control protocol on N2) → Protocol Dictionary
  • The roles of the main NFsAMF / AUSF / UDM

What you'll learn in this chapter

This chapter is limited to Initial Registration. It is the procedure by which a UE registers with the network for the first time after being powered on.

  • Mobility Registration Update (registration update across serving areas)
  • Periodic Registration Update (periodic registration update)

are out of scope for this chapter. These are separate Registration types; they share much in common but branch differently. They will be covered in future chapters (see Next Step).


Why — why registration is necessary

Let's start from the Why (why it is needed). Merely powering on a UE leaves it a "terminal that does not exist" as far as the network is concerned. In this state, none of the following is possible.

  • Cannot receive calls — the network does not know which area the UE is in, so it cannot tell where to page it.
  • Cannot originate calls — there is no foundation (security, context) on which to send control signaling.
  • Cannot do data communication — the prerequisites for setting up a PDU Session are not in place.

Registration is the procedure by which the UE declares "I am here; please let me use the network," and the network establishes the following.

  1. Grasping the serving area — which area (TA: Tracking Area) the UE is in.
  2. Grasping the state — whether it is registered, and whether it is connected or idle.
  3. Grasping the capabilities — which security algorithms and slices the UE can use.
  4. Identity verification (authentication) — confirming it is not an impersonation.
  5. Security establishment — sharing keys to encrypt and integrity-protect subsequent signaling.

Only when these are in place does the foundation for all subsequent procedures — incoming calls, outgoing calls, and data communication — come into being.

Analogy: checking in at a hotel

Initial Registration is like checking in at a hotel. At the front desk (AMF), you verify your identity (authentication), get assigned a room (context), and are issued a room key (5G-GUTI and security keys). Only after check-in is done can you enter your room or order room service (= data communication and incoming calls). Someone who has not checked in cannot use any of the hotel's (network's) services at all.

Overview

In Initial Registration, the following broad flow takes place.

After power-on, the UE sends a registration request (Registration Request) to the AMF via the gNB (base station) → the AMF coordinates with AUSF/UDM to perform identity verification (authentication)NAS security is establishedsubscriber data is retrieved from the UDM → and finally the AMF returns a registration accept (Registration Accept) to the UE and assigns a 5G-GUTI. The UE returns Registration Complete, and it is done.

flowchart LR
    UE([UE]) -->|1.Registration Request| AMF[AMF]
    AMF -->|2.Authentication| AUTH{AUSF / UDM}
    AMF -->|3.Establish Security| UE
    AMF -->|4.Retrieve subscriber data| UDM[UDM]
    AMF -->|5.Registration Accept| UE

Basic Concept — a beginner-friendly explanation

To understand initial registration, grasp three keywords.

1. 5GMM state (the registration state)

5GMM = 5G Mobility Management (5G's mobility management). Regarding registration, a UE has mainly two states.

  • 5GMM-DEREGISTERED (not registered) — a state where, from the network's viewpoint, it "is not there."
  • 5GMM-REGISTERED (registered) — a state where serving area, state, and keys are established and services can be used.

Initial Registration is the procedure that transitions from DEREGISTERED → REGISTERED (details in State Machine).

2. Identifiers (the names that represent the UE)

Identifier Full name What it is OK to expose?
SUPI Subscription Permanent Identifier The subscriber's permanent real name (equivalent to IMSI) ❌ Must not be put on the air
SUCI Subscription Concealed Identifier The SUPI encrypted and concealed ⭕ May be put on the air
5G-GUTI 5G Globally Unique Temporary Identity A temporary pseudonym assigned by the AMF ⭕ May be reused

Why send it as SUCI (privacy protection)

In 4G (LTE), the IMSI (real name) was sometimes put on the air in cleartext at first, and if intercepted, an IMSI catcher could track an individual. In 5G, the subscriber's real name SUPI is sent as SUCI, encrypted with a public key, so even if the air interface is intercepted the real name cannot be learned. Once registration is done, using the disposable temporary ID 5G-GUTI thereafter makes tracking even harder.

3. NAS and NGAP (the two protocols that carry the registration)

  • NAS (Non-Access Stratum) — control messages exchanged directly between the UE and the AMF (Registration Request, etc.). The gNB does not look inside; it just carries them. → N1
  • NGAP (NG Application Protocol) — the control protocol between the gNB and the AMF. It puts NAS messages into NGAP messages and carries them. → N2

In other words, the registration request has the structure "the gNB delivers the NAS (the letter) to the AMF by putting it into NGAP (the envelope)." This nesting structure becomes important in Packet Analysis.


Architecture

The elements involved in Initial Registration and the interfaces that connect them.

flowchart LR
    UE([UE]) ---|"N1 (NAS)"| AMF
    UE -.RRC.- RAN["(R)AN / gNB"]
    RAN ---|"N2 (NGAP)"| AMF[AMF]
    AMF ---|"N12"| AUSF[AUSF]
    AMF ---|"N8"| UDM[UDM]
    AUSF ---|"N13"| UDM
    AMF ---|"N15"| PCF[PCF]

The role of each element is as follows.

  • UE — the terminal requesting registration. It generates NAS and responds to authentication.
  • (R)AN / gNB — the radio access. It puts the UE's NAS onto NGAP and relays it to the AMF, and performs AMF selection.
  • AMF — the command center of registration. It terminates N1 (NAS) / N2 (NGAP) and orchestrates authentication, security, subscriber data retrieval, and registration accept.
  • AUSF — the authentication server. It executes the 5G-AKA authentication processing (with the AMF via N12, and with the UDM via N13). Based on the HE AV received from the UDM, it derives HXRES* / KSEAF (it is not the entity that generates the AV itself. TS 33.501 §6.1.3.2).
  • UDM — subscriber data management. The UDM/ARPF generates authentication vectors (AV) (TS 33.501 §6.1.3.2), and is also the source of subscriber data (N8/N13).
  • PCF (Policy Control Function, conditional) — provides Access & Mobility policy (N15). An optional step in this chapter.

For the details of the interfaces, see the Interface Dictionary.

Network Function (the NFs that appear)

NF Role in this procedure Information held/retrieved Main APIs used in this procedure Impact on failure
AMF The entity that accepts the registration request, initiates authentication, establishes security, and issues the registration accept UE context, 5G-GUTI, security keys, serving area (TAI) Namf (provided by AMF) / consumes AUSF, UDM, and PCF services Registration itself becomes impossible. Incoming/outgoing/data all fail
AUSF The entity that executes 5G-AKA authentication (intermediary between AMF and UDM). Derives HXRES*/KSEAF from the HE AV received from the UDM KSEAF, KAUSF (derived/held) ※not the entity that generates the AV itself Nausf_UEAuthentication Authentication does not complete and registration cannot proceed
UDM The UDM/ARPF generates authentication vectors (AV: RAND/AUTN/XRES*/KAUSF). Provides subscriber data / subscription information Subscriber data, authentication information (K/OPc), SUPI, AV generation Nudm_UEAuthentication_Get, Nudm_UECM_Registration, Nudm_SDM_Get AV cannot be generated / subscriber data cannot be retrieved, so registration fails
PCF (conditional) Provides AM policy (Access & Mobility) AM policy Npcf_AMPolicyControl_Create AM policy not applied (registration itself can often still proceed = implementation/configuration dependent)

Interface / Protocol

The interfaces and protocols used in this procedure.

Interface Protocol Transport Use in this procedure
N1 NAS (5GMM) (tunneled over NGAP/N2) The registration, authentication, security, and accept messages between UE⇔AMF
N2 NGAP SCTP (port 38412) gNB⇔AMF. Transport of NAS-PDU, UE context establishment
N8 SBI (HTTP/2, TLS, JSON) TCP/TLS AMF⇔UDM (subscriber data retrieval, AM registration)
N12 SBI (HTTP/2, TLS, JSON) TCP/TLS AMF⇔AUSF (authentication initiation/response)
N13 SBI (HTTP/2, TLS, JSON) TCP/TLS AUSF⇔UDM (authentication vector retrieval)
N15 SBI (HTTP/2, TLS, JSON) TCP/TLS AMF⇔PCF (AM policy, conditional)

For the details of protocols, see the Protocol Dictionary; for the list of interfaces, see the Interface Dictionary.


Procedure — Call Flow

This is the heart of this page. The main steps of Initial Registration, conforming to 3GPP TS 23.502 §4.2.2.2.2 (General Registration), are shown in a Mermaid sequenceDiagram.

Prerequisite: NG Setup must be done

Before accepting a UE, the N2 (NG-C) between the gNB and the AMF must be established via NG Setup (TS 38.413). If it is not established, Registration will not proceed (see Trouble Shooting).

sequenceDiagram
    autonumber
    participant UE
    participant RAN as (R)AN / gNB
    participant AMF
    participant AUSF
    participant UDM
    participant PCF

    Note over UE,RAN: RRC connection establishment (radio side, outline)
    UE->>RAN: Carry Registration Request (NAS)
    Note right of RAN: TS 24.501 §5.5.1
    RAN->>AMF: Put NAS onto Initial UE Message (NGAP)
    Note right of RAN: Perform AMF selection

    opt New registration / 5G-GUTI unknown or invalid
        AMF->>UE: Identity Request (NAS)
        UE->>AMF: Identity Response (SUCI)
    end

    AMF->>AUSF: Nausf_UEAuthentication_Authenticate (start authentication)
    AUSF->>UDM: Nudm_UEAuthentication_Get (request AV)
    UDM-->>AUSF: Generate HE AV (UDM/ARPF): RAND, AUTN, XRES*, KAUSF
    Note right of AUSF: AUSF derives HXRES*/KSEAF (TS 33.501 §6.1.3.2)
    AUSF-->>AMF: Authentication challenge (RAND, AUTN)
    AMF->>UE: Authentication Request (RAND, AUTN)
    UE->>AMF: Authentication Response (RES*)
    AMF->>AUSF: Request RES* verification
    AUSF-->>AMF: Authentication success + KSEAF
    Note over UE,AUSF: 5G-AKA / TS 33.501 §6.1

    AMF->>UE: Security Mode Command (NAS)
    UE->>AMF: Security Mode Complete (NAS)
    Note over UE,AMF: NAS security established / TS 24.501 §5.4.2

    AMF->>UDM: Nudm_UECM_Registration (AMF registration)
    AMF->>UDM: Nudm_SDM_Get (retrieve subscriber data)
    UDM-->>AMF: Access & Mobility Subscription Data
    AMF->>UDM: Nudm_SDM_Subscribe (subscribe to change notifications)

    opt Conditional (configuration/situation dependent)
        AMF->>PCF: Npcf_AMPolicyControl_Create (AM policy)
        PCF-->>AMF: AM Policy
    end

    AMF->>RAN: Initial Context Setup Request (NGAP)
    AMF->>UE: Registration Accept (NAS: 5G-GUTI, allowed NSSAI)
    UE->>AMF: Registration Complete (NAS)
    Note over UE,AMF: Registration complete / 5GMM-REGISTERED

Step-by-step explanation (numbers correspond to the diagram above)

  1. UE→(R)AN: establish an RRC connection (radio-side outline) and carry the Registration Request (NAS).
  2. (R)AN→AMF: the gNB puts the NAS onto an Initial UE Message (NGAP) and sends it. At the same time it performs AMF selection (choosing an appropriate AMF).
  3. (Only for new registration / when the GUTI is unknown or invalid) AMF→UE Identity Request / UE→AMF Identity Response (SUCI). When the 5G-GUTI is valid, this identity request may be omitted (it varies with conditions = situation dependent).
  4. Authentication (5G-AKA): retrieve the authentication vector via AMF→AUSF Nausf_UEAuthentication_Authenticate and AUSF→UDM Nudm_UEAuthentication_Get. Perform challenge/response via AMF→UE Authentication Request (RAND, AUTN) and UE→AMF Authentication Response (RES*). When the 5G-GUTI is valid and the security context can be reused, authentication can sometimes be omitted (omission depends on conditions = situation dependent).
  5. Security establishment: AMF→UE Security Mode Command / UE→AMF Security Mode Complete. This encrypts and integrity-protects the subsequent NAS.
  6. UDM coordination: AMF→UDM Nudm_UECM_Registration (records with the UDM which AMF this UE is registered to), Nudm_SDM_Get (retrieves subscriber data), Nudm_SDM_Subscribe (subscribes to notifications of data changes).
  7. (Optional/conditional) AMF→PCF Npcf_AMPolicyControl_Create to retrieve AM policy (configuration/situation dependent).
  8. Accept: AMF→(R)AN Initial Context Setup Request (NGAP) to establish the UE context, and AMF→UE Registration Accept (NAS) to notify of the 5G-GUTI assignment and allowed NSSAI.
  9. Complete: UE→AMF Registration Complete (NAS). This is a confirmation that the procedure has completed; the UE's transition to 5GMM-REGISTERED occurs at the moment the Registration Accept is received (TS 24.501 §5.5.1.2.4).

Conditional branches are situation/implementation dependent

Of the above, the Identity request (step 3), whether authentication can be omitted (step 4), and PCF coordination (step 7) may be omitted or changed depending on the presence of a 5G-GUTI/security context, the configuration, and operator policy. Because 3GPP TS 23.502 §4.2.2.2.2 contains many optional/conditional steps, the specific omission conditions must be checked against the spec individually (some of the detailed branching conditions are to be confirmed).

Reference: TS 23.502 §4.2.2.2.2 (the overall General Registration procedure), TS 24.501 §5.5.1 (the NAS-side Registration procedure).

Signal Flow

The key Messages organized in a table. The IEs are made consistent with the Message Dictionary.

Message Protocol Source→Destination Purpose Key IEs Result
Registration Request NAS (5GMM) UE→AMF Registration request 5GS registration type, 5GS mobile identity (SUCI/5G-GUTI), UE security capability The AMF starts registration processing
Identity Request NAS (5GMM) AMF→UE Identifier request (when the GUTI is unknown) Identity type = SUCI (typical for initial registration. As enumerated values, SUPI/5G-GUTI/PEI(IMEI), etc. may also be requested. TS 24.501 §9.11.3.3) Prompts the UE to submit an identifier
Identity Response NAS (5GMM) UE→AMF Identifier response 5GS mobile identity (SUCI) The AMF obtains the SUCI
Authentication Request NAS (5GMM) AMF→UE Authentication challenge ABBA, RAND, AUTN The UE authenticates the network and computes RES*
Authentication Response NAS (5GMM) UE→AMF Authentication response RES* The AUSF verifies RES*
Security Mode Command NAS (5GMM) AMF→UE Instruction to establish NAS security selected NAS security algorithms The encryption/integrity algorithms are fixed
Security Mode Complete NAS (5GMM) UE→AMF Security establishment complete (IMEISV etc., as needed) Subsequent NAS is protected
Nudm_UECM_Registration SBI (HTTP/2) AMF→UDM AMF registration SUPI, AMF identification information The UDM records the UE↔AMF association
Nudm_SDM_Get SBI (HTTP/2) AMF→UDM Subscriber data retrieval SUPI, Data Set Name The AMF retrieves the Access & Mobility subscription data
Registration Accept NAS (5GMM) AMF→UE Registration accept 5G-GUTI, allowed NSSAI, registration result The UE recognizes registration success
Registration Complete NAS (5GMM) UE→AMF Registration complete (ACK on 5G-GUTI reassignment, etc.) Confirmation of procedure completion (the state transition itself occurs on receipt of the Accept. TS 24.501 §5.5.1.2.4)

For the detailed IEs and reference specs of each Message, see the Message Dictionary.

State Machine

The 5GMM state transitions on the UE side (basis: TS 24.501 §5.1.3).

stateDiagram-v2
    [*] --> DEREGISTERED
    DEREGISTERED --> REGISTERED_INITIATED: Send Registration Request
    REGISTERED_INITIATED --> REGISTERED: Receive Registration Accept
    REGISTERED_INITIATED --> DEREGISTERED: Receive Registration Reject / T3510 expiry
    REGISTERED --> DEREGISTERED: De-registration / registration lapse
    REGISTERED --> [*]
  • 5GMM-DEREGISTERED — not registered. Sending a Registration Request from here starts the transition.
  • 5GMM-REGISTERED-INITIATED — a transient state after sending the registration request, waiting for a response. It succeeds with Registration Accept, or returns to DEREGISTERED on Registration Reject / timer expiry (e.g. T3510).
  • 5GMM-REGISTERED — registration complete. Services are available.

For the details of timers, see the Timer Dictionary.

Packet Analysis (Wireshark)

The key points when analyzing Initial Registration with Wireshark.

Key Display Filters

Filter Meaning
ngap NGAP messages in general
nas-5gs 5GS NAS messages in general
sctp.port == 38412 The SCTP port of N2 (NGAP)
ngap.procedureCode == 15 Initial UE Message (to be confirmed: the procedureCode value may be environment/version dependent)
ngap.procedureCode == 14 Initial Context Setup (the procedure code in TS 38.413. To be confirmed: depends on the dissector implementation)
nas-5gs.mm.message_type == 0x41 Registration Request (to be confirmed: the value depends on the dissector implementation)

Filter values are environment dependent and to be confirmed

The numeric values of ngap.procedureCode and the hexadecimal values of NAS message types are based on the 3GPP spec's assignments, but how they are displayed and matched may differ depending on the Wireshark version and dissector implementation. Treat the numbers above as to be confirmed, and on real equipment it is more reliable to check them in the protocol hierarchy display of the GUI.

Points to note when decoding (key IEs)

  • 5GS registration type — the kind, such as initial / mobility updating. For Initial Registration it is initial registration.
  • 5GS mobile identity — whether it is SUCI or 5G-GUTI. On the first attempt, SUCI is present.
  • UE security capability — the encryption/integrity algorithms the UE supports.
  • RAND / AUTN (inside Authentication Request) — the random value and authentication token of the authentication challenge.
  • 5G-GUTI (inside Registration Accept) — the temporary ID assigned by the AMF.

Security Mode Command is not encrypted (integrity-protected only)

The Security Mode Command (SMC) itself is sent with integrity protection only (without encryption), so even in Wireshark you can check its contents (selected NAS security algorithms, etc.) in cleartext. NAS encryption begins from Security Mode Complete onward in the UL, and from the message immediately after the SMC in the DL (TS 33.501 §6.7.2). Therefore it is normal that the NAS from Registration Accept onward is encrypted and its contents are not visible.

The structure of NAS nested inside NGAP

Inside an NGAP message (e.g. Initial UE Message) there is a NAS-PDU, and inside that is the 5GS NAS (Registration Request). In the packet detail pane it is displayed hierarchically as follows.

NGAP-PDU
 └─ InitialUEMessage
     └─ NAS-PDU
         └─ 5GS NAS Message
             └─ Registration Request

Actual pcaps are environment dependent (implementation dependent)

The filters and IE names on this page are guidelines for analysis. Actual packets depend on the radio and core implementation and configuration. If you build an Open5GS or free5GC testbed, you can actually capture these packets on the N2 segment and study them.

Configuration

The structural-level key points of the configuration for making Initial Registration work. Specific values and vendor-specific details (Cisco, etc.) are implementation dependent, and no fictitious values are written here.

On the AMF side (e.g. Open5GS / free5GC AMF configuration)

  • PLMN ID (MCC/MNC) — identifies which operator's network it is.
  • GUAMI (Globally Unique AMF Identifier) — uniquely identifies the AMF and is the basis for 5G-GUTI assignment.
  • TAI / TAC (Tracking Area) — the area to serve. It must match the TA of the gNB.
  • PLMN Support / S-NSSAI (supported slices) — the basis for determining the allowed NSSAI.

Provisioning subscriber information (UDM/UDR)

  • Registration of the subscriber (SUPI/IMSI) is required on the UDM/UDR side.
  • Provisioning of the authentication information (long-term keys such as K, OPc) is required. Without this, authentication (5G-AKA) will not work.
  • Registration of subscription data (Access & Mobility Subscription Data, allowed slices, etc.).

Specific values and vendor-specific details are implementation dependent

The configuration file's key names, hierarchy, and mandatory items differ across Open5GS / free5GC / commercial vendors (Cisco, etc.). The above are structural-level key points; check the actual key names and values in each implementation's documentation (implementation dependent).

Trouble Shooting

Isolating typical registration failures. For the details of Cause values, see the Cause Dictionary.

Symptom Presumed cause What to check Related logs/Packets Direction of remedy
(a) Authentication failure (MAC failure / Synch failure) Key mismatch on the UE side, SQN synchronization drift UDM authentication info (K/OPc), SQN counter Authentication Failure (NAS), AMF/AUSF/UDM logs Check key provisioning; on Synch failure, check the UE's AUTS resynchronization
(b) Identity requests repeat due to 5G-GUTI mismatch The AMF cannot resolve the UE's 5G-GUTI The GUTI mapping with the previous AMF, AMF re-selection Identity Request/Response (NAS), AMF logs Check re-registration with SUCI, check inter-AMF context transfer
(c) Registration does not proceed because NG Setup is not established The N2 (NG-C) between gNB and AMF is not established Success/failure of NG Setup Request/Response NGAP NG Setup, SCTP (port 38412) connection state Check the SCTP association and PLMN/TAC consistency, re-run NG Setup
(d) Failure to retrieve subscriber data from the UDM / not provisioned Subscriber not registered, UDM/UDR failure, SUPI inconsistency The UDM/UDR subscriber DB, SBI reachability Responses of Nudm_SDM_Get/UECM_Registration, UDM logs Check subscriber provisioning, check UDM/UDR reachability and SUPI notation

Comparison with EPC

A comparison so that those experienced with 4G (EPC) can bridge to 5G.

Aspect 4G / EPC 5G / 5GC
Initial procedure Attach Initial Registration
Managing NF MME AMF (session management is separated into the SMF)
Temporary ID GUTI 5G-GUTI
Permanent ID IMSI (could be carried in cleartext at first) SUPI (concealed on the air as SUCI)
Authentication method EPS-AKA 5G-AKA (or EAP-AKA')
Radio-node control S1AP NGAP
Area update TAU (Tracking Area Update) Mobility Registration Update (out of scope of this chapter)

Release differences

The main topics related to registration. Uncertain items are marked to be confirmed and not asserted.

  • Rel-15 — the basic 5GC procedures were established. The foundations of Initial Registration / 5G-AKA / SUCI / SBA were specified.
  • Rel-16 — the generation in which extensions to network-slice-related registration/selection and security enhancements advanced (the extent to which specific features were woven into the registration procedure is to be confirmed).
  • Rel-17 — functional extensions continued (the specifics of the impact on the registration procedure are to be confirmed).
  • Rel-18 (5G-Advanced) — further extensions (the specific registration-related differences are to be confirmed).

Release differences are to be confirmed

Exactly which features were woven into the "registration procedure itself," and to what extent, in each Release must be checked against the version differences of the relevant TS individually. The above is an overview; the specific items are to be confirmed.

3GPP Specification

Spec Section Content
TS 23.502 §4.2.2.2.2 General Registration procedure (the basis for this chapter's Call Flow)
TS 24.501 §5.5.1 The NAS-side Registration procedure
TS 24.501 §5.1.3 5GMM states (the basis for the state transitions)
TS 23.501 §5.3 Registration Management (RM) / Connection Management (CM) (to be confirmed: section number)
TS 33.501 §6 Security/authentication (5G-AKA, etc.)
TS 38.413 (various NGAP sections) NGAP (Initial UE Message / Initial Context Setup, etc.)
TS 29.518 Namf (the AMF's service API)
TS 29.503 Nudm (the UDM's service API)
TS 29.509 Nausf (the AUSF's service API)

Handling of section numbers

TS 23.502 §4.2.2.2.2 / TS 24.501 §5.5.1 and §5.1.3 / TS 33.501 §6 are referenced as the backbone of this chapter. The fine-grained section number of TS 23.501 §5.3, and the individual section numbers of TS 38.413, may differ by version, and some are marked to be confirmed.

FAQ

Q1. What is the difference between SUCI and SUPI?

SUPI is the subscriber's permanent real name (equivalent to IMSI), and must not be put on the air in cleartext. SUCI is that SUPI encrypted and concealed with a public key. In initial registration, sending SUCI ensures that even if intercepted, the real name cannot be learned (privacy protection).

Q2. When is the 5G-GUTI assigned?

The AMF assigns it in the Registration Accept (step 8) and notifies the UE. Thereafter it is used as a disposable temporary ID in place of SUCI/SUPI, making tracking difficult.

Q3. Is authentication required every time?

In Initial Registration, authentication is basically performed. However, when a valid 5G-GUTI and security context can be reused, authentication can sometimes be omitted (it varies with conditions = situation/implementation dependent). For the detailed conditions on whether it can be omitted, check the relevant conditions in TS 23.502/24.501.

Q4. What is the difference between Registration and PDU Session establishment?

Registration is the procedure to "check in to the network and establish serving area, authentication, and keys." PDU Session establishment is the procedure to "actually set up the pipe (IP, etc.) for data communication," done after Registration is complete. Think of registration = entering the building, and PDU Session = opening a workroom.

Q5. What is the relationship with NG Setup?

NG Setup is a preparation procedure, before the UE appears, that establishes the N2 (NG-C) between the gNB and the AMF. If NG Setup is not done, the gNB cannot deliver the UE's Registration Request to the AMF (see Trouble Shooting item (c)).

Summary

  • Initial Registration is the procedure that transitions the UE from 5GMM-DEREGISTERED → REGISTERED and builds the foundation for incoming calls, outgoing calls, and data communication.
  • The broad flow is registration request → authentication (5G-AKA) → security establishment → subscriber data retrieval → registration accept.
  • The command center is the AMF, authentication is by AUSF/UDM, and subscriber data is from the UDM.
  • The registration request is carried by the gNB to the AMF with NAS put onto NGAP (a nested structure).
  • The real name SUPI is concealed on the air as SUCI, and after registration the 5G-GUTI is used (privacy protection).
  • The basis is TS 23.502 §4.2.2.2.2 / TS 24.501 §5.5.1 and §5.1.3 / TS 33.501 §6.

Practice — comprehension check and exercises

Comprehension check

Q1. What NGAP message carries the Registration Request? (answer)

Initial UE Message. The gNB puts the UE's NAS (Registration Request) onto this NGAP message and sends it to the AMF (step 2).

Q2. In initial registration, which does the UE put into 5GS mobile identity — SUCI or 5G-GUTI? (answer)

SUCI. To conceal the real name (SUPI). The 5G-GUTI has not yet been assigned.

Q3. In which Message is the 5G-GUTI assigned? (answer)

Registration Accept (AMF→UE, step 8).

Q4. When a Registration Reject is received, where does the UE's 5GMM state transition to? (answer)

It returns to 5GMM-DEREGISTERED (from REGISTERED-INITIATED). Basis: TS 24.501 §5.1.3.

Q5. In authentication (5G-AKA), what IEs does the network send to the UE as the challenge? (answer)

RAND and AUTN (inside Authentication Request). The UE responds with RES*.

Exercises

Problem: Reorder the following 9 main Initial Registration steps into the correct order.

A. Security Mode Command / Complete
B. Registration Request (carried in Initial UE Message)
C. Registration Complete
D. Authentication Request / Response (5G-AKA)
E. Registration Accept (5G-GUTI assignment)
F. Identity Request / Response (when the GUTI is unknown)
G. Nudm_UECM_Registration / Nudm_SDM_Get
H. Initial Context Setup Request
I. Npcf_AMPolicyControl_Create (conditional)
Answer

B → F → D → A → G → I → H → E → C

  • B: Registration request (Initial UE Message)
  • F: Identity request (only when the GUTI is unknown)
  • D: Authentication (5G-AKA)
  • A: Security establishment
  • G: UDM coordination (AMF registration, subscriber data retrieval)
  • I: PCF coordination (conditional)
  • H: Initial Context Setup Request (NGAP)
  • E: Registration Accept (5G-GUTI assignment)
  • C: Registration Complete

※ F and I are omitted depending on conditions (situation/implementation dependent).

Next Step

The next steps to deepen your understanding.