Service Request¶

Learning objectives¶

After reading this page, you will be able to:

• Explain the Why (why a Service Request is needed) as the mechanism by which a UE that has dropped into low-power standby (CM-IDLE) re-establishes the connection and user plane when it resumes communication.
• Explain, by contrast, the difference between a UE-triggered and a Network-triggered Service Request (the trigger, and whether Paging precedes it).
• Explain, with diagrams, the CM-IDLE → CM-CONNECTED state transition and the reverse-direction AN Release (CM-CONNECTED → CM-IDLE).
• Follow the flow of the user-plane re-activation of the PDU Session (AMF→SMF Nsmf UpdateSMContext → reconfiguration of the UPF's N3 tunnel/FAR over N4 → re-establishment of the N3 path with the gNB).
• Explain, from the core's viewpoint, that the leading roles in a Service Request are the AMF (NAS/N2 control) and the SMF/UPF (U-Plane re-establishment).
• Use Wireshark Display Filters to name the points to focus on when analyzing a NAS Service Request / NGAP Initial Context Setup / PFCP Session Modification.
• Contrast the differences between the 4G (EPC) Service Request (MME-triggered / UE-triggered, S1AP, ECM-IDLE→CONNECTED) and the 5G Service Request.

Prerequisites¶

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

• That the UE is registered — a Service Request targets a registered (5GMM-REGISTERED) UE. For the registration flow, see Initial Registration.
• That a PDU Session is already established (the user plane to be re-activated was set up in the past) → PDU Session Establishment
• Understanding of Paging (a Network-triggered Service Request starts as a response to Paging) → Paging
• N1 / N2 / N3 / N4 (the UE⇔AMF NAS, the gNB⇔AMF NGAP, the gNB⇔UPF U-Plane, the SMF⇔UPF PFCP) → N1 / N2 / N3 / N4
• The roles of the main NFs → AMF / SMF / UPF

What you'll learn in this chapter¶

This chapter focuses on the Service Request procedure. It is the procedure by which a UE in the CM-IDLE (standby) state re-establishes the radio connection and UE context and transitions from CM-IDLE → CM-CONNECTED. It covers the following two triggers.

• UE-triggered Service Request — the UE spontaneously resumes the connection in order to originate, send UL (uplink) data, or respond to network-triggered signaling. The UE sends a NAS Service Request.
• Network-triggered Service Request — a UE that has been woken by Paging upon the arrival of DL (downlink) data starts it as a response. This corresponds to the continuation of paging.md.

This chapter focuses on the involvement of the core (5GC). In particular, it centers on the NAS Service Request received by the AMF (N1/N2) and the subsequent user-plane re-activation of the PDU Session (the AMF→SMF→UPF N3/N4 coordination). The following are out of scope for this chapter (they are mentioned, but not gone into in detail).

• RRC Resume / the detailed radio-side (RRC) procedures — the radio-connection resume steps (RRC Setup/Resume, radio resource allocation) are kept conceptual, focusing on the core's involvement (radio side, implementation-dependent).
• The details of AKA re-authentication — re-authentication may occur during a Service Request, but the details of authentication are directed to a separate chapter (Security/Authentication).
• The details of Handover — connection switching while moving is out of scope for this chapter (see Handover).
• RRC Inactive / Small Data Transmission — the Rel-16-and-later extensions are only outlined in Release differences.

Why — why a Service Request is necessary¶

Let's start from the Why (why it is needed). Even a registered (5GMM-REGISTERED) UE does not keep holding a dedicated radio connection while it is not communicating. Maintaining a radio connection at all times would quickly drain the UE's battery and exhaust the network's radio resources. So, while there is no communication, the UE releases the dedicated radio connection and enters a standby state (CM-IDLE) to save its battery (this reverse-direction procedure of "releasing the connection and dropping into standby" is AN Release).

However, when a standby (CM-IDLE) UE tries to resume communication, there is a problem. In CM-IDLE, the following two are severed.

1. The signaling connection — there is no UE⇔AMF NAS connection and no gNB⇔AMF N2 UE-associated connection. Control messages cannot be sent right away.
2. The user-plane path — the PDU Session is logically maintained, but the N3 (gNB⇔UPF) tunnel through which actual data flows is deactivated. As is, no uplink/downlink data flows.

A Service Request is the procedure by which this standby UE declares "I am going to communicate again; please re-establish the connection and the data path," re-establishes the signaling connection, re-activates the PDU Session's user plane, and returns to CM-CONNECTED.

Overview¶

A Service Request starts from two triggers. Either way the result is the same — the UE transitions to CM-CONNECTED, the PDU Session's user plane (N3) is re-activated, and uplink/downlink data begins to flow.

• UE-triggered — the UE starts it spontaneously. The trigger may be origination, sending UL (uplink) data, responding to network-triggered signaling, and so on. The UE sends a NAS Service Request.
• Network-triggered — the UPF/SMF/AMF detect the arrival of DL data, and the AMF pages the UE via Paging. This is a Service Request that the paged UE starts. In other words, the biggest difference from the UE-triggered case is that in the network-triggered case Paging precedes it.

flowchart LR
    UEtrig["UE-triggered
(origination / UL data)"] --> SR["Service Request
(NAS)"]
    DL[("DL data arrival")] --> PG["Paging
(the network-triggered preceding procedure)"]
    PG --> SR
    SR --> ACT["U-Plane re-activation
(AMF→SMF→N4→UPF, N3 re-establishment)"]
    ACT --> CONN(("CM-CONNECTED
data flowing"))

    classDef pg fill:#eef,stroke:#66a,stroke-width:1px;
    class PG pg;

Basic Concept — a beginner-friendly explanation¶

To understand the Service Request, grasp three keywords.

1. Why a return from CM-IDLE is needed¶

CM = Connection Management. A registered UE has mainly two states, depending on the presence of the UE⇔AMF N1 (NAS) signaling connection and the gNB⇔AMF N2 UE-associated connection (this is kept strictly aligned with Paging).

• CM-IDLE (standby) — a state where there is no signaling connection for that UE between the UE and the network. The UE has released the dedicated radio connection to save its battery. The PDU Session's user plane (N3) is also deactivated.
• CM-CONNECTED (connected) — a state where a signaling connection for that UE is established. Data/signaling can be exchanged right away.

When communication ceases, the network drops the UE from CM-CONNECTED → CM-IDLE via AN Release (the release of the radio connection), to save power. But when it wants to communicate again, it needs to re-establish the severed connection and U-Plane. That return procedure is the Service Request, which brings it back from CM-IDLE → CM-CONNECTED. Note that this is on a different axis from the RM state (Registration Management: REGISTERED / DEREGISTERED); a Service Request targets a UE that is "RM=REGISTERED and CM=IDLE."

2. The difference between UE-triggered and Network-triggered¶

Even for the same Service Request, who moves first differs.

• UE-triggered — the UE itself spontaneously sends a NAS Service Request when "it is about to originate" or "it wants to send uplink data." No Paging is needed (because it notices and moves on its own).
• Network-triggered — when an errand for the UE (DL data) arrives on the network side, the UE is on standby and cannot notice it. So the network calls "please wake up" via Paging, and the paged UE starts a Service Request as a response.

3. PDU Session activation (why the U-Plane must be re-established)¶

During CM-IDLE, the PDU Session itself is logically maintained (the UE's IP address and PDU Session ID do not disappear). However, the N3 (gNB⇔UPF) user-plane tunnel through which actual data flows is deactivated. The reason is that, while the UE is on standby with no radio connection, keeping only the N3 tunnel alive would be pointless because the delivery target (gNB) for downlink data is not fixed.

Therefore, in a Service Request, in addition to re-establishing the signaling connection, the PDU Session's user plane is re-activated. Specifically, the following are re-established.

• The gNB⇔UPF N3 tunnel — the N3 (GTP-U) path through which uplink/downlink data flows. The TEIDs/addresses on the gNB side and UPF side are newly set/updated.
• The UPF's forwarding rules — the SMF updates the UPF's FAR (Forwarding Action Rule) etc. over N4 (PFCP), directing downlink data to the new gNB's N3 TEID.

At this time, which PDU Session the UE re-activates may be indicated by information included in the Service Request (equivalent to the List Of PDU Sessions To Be Activated described later; the IE name is to be confirmed). It does not necessarily wake all PDU Sessions at once; it is designed to wake only the ones needed (details/conditions are to be confirmed).

Architecture¶

The elements involved in a Service Request and the interfaces that connect them. It emphasizes the path where the UE's NAS Service Request reaches the AMF via the gNB, and the AMF re-establishes the UPF's N3 (U-Plane) through the SMF.

flowchart LR
    UE(("UE
(CM-IDLE→CONNECTED)"))
    RAN["(R)AN / gNB"]
    AMF["AMF
(NAS/N2 control)"]
    SMF["SMF
(PDU Session activation)"]
    UPF["UPF
(N3 reconfiguration)"]
    DN[(Data Network)]

    UE -- "N1 (NAS): Service Request" --> AMF
    UE -. "RRC (radio, out of scope)" .- RAN
    RAN -- "N2 (NGAP): Initial UE Message / InitialContextSetup" --> AMF
    AMF -- "N11-equivalent (Nsmf UpdateSMContext)" --> SMF
    SMF -- "N4 (PFCP): Session Modification" --> UPF
    RAN == "N3 (GTP-U re-establishment)" ==> UPF
    UPF == "N6" ==> DN

    classDef core fill:#efe,stroke:#3a3,stroke-width:2px;
    class AMF,SMF,UPF core;

The role of each element is as follows.

• UE — the returning terminal. It sends the NAS Service Request spontaneously in the UE-triggered case, or as a Paging response in the Network-triggered case. The radio-side RRC resume is out of scope.
• (R)AN / gNB — the radio access. It carries the UE's NAS to the AMF in an Initial UE Message (NGAP), sets the UE context / AS security / radio resources via the AMF's InitialContextSetup, and re-establishes N3 (GTP-U) to the UPF.
• AMF — the command center of control. It terminates N1 (NAS) / N2 (NGAP), accepts the Service Request, and instructs the SMF regarding the PDU Session(s) to be re-activated.
• SMF — session management. At the AMF's request, it reconfigures the UPF's U-Plane (N3/FAR) over N4 (PFCP) and re-activates the PDU Session.
• UPF — the user-plane forwarding entity. On the SMF's instruction, it reconfigures the N3 tunnel (gNB-side TEID/address) and FAR, and flows uplink/downlink data.
• DN (Data Network) — the external data network. After re-establishment, it communicates with the UE through the U-Plane.

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

Network Function (the NFs that appear)¶

The roles of the core-side NFs that appear in a Service Request. The gNB is on the radio-access side and is not a core NF (this table is limited to core NFs).

Interface / Protocol¶

The interfaces and protocols used in this procedure.

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 a Service Request are shown in a Mermaid sequenceDiagram. The basis is 3GPP TS 23.502 §4.2.3 series (UE Triggered / Network Triggered Service Request), TS 24.501 §5.6 series (NAS Service Request), and TS 38.413 (NGAP) (the fine details of section numbers are to be confirmed). It is shown with the UE-triggered case as the main axis, and the Network-triggered case is supplemented as the "difference where Paging precedes it."

UE-triggered Service Request (main axis)¶

sequenceDiagram
    autonumber
    participant UE as UE (CM-IDLE)
    participant RAN as (R)AN / gNB
    participant AMF
    participant SMF
    participant UPF

    Note over UE,RAN: The need to originate / send UL data arises
    Note over UE,RAN: RRC connection establishment/resume (radio side, outline/out of scope)
    UE->>RAN: Carry Service Request (NAS)
    Note right of UE: TS 24.501 §5.6.1. Service type (mo-signalling/mo-data, etc.)
    RAN->>AMF: Put NAS onto Initial UE Message (NGAP)
    Note right of RAN: N2 / TS 38.413

    opt Security re-establishment/re-authentication (conditional, situation dependent)
        Note over UE,AMF: Verify the existing security context. Re-authenticate only when needed (details in a separate chapter)
    end

    Note over AMF: Determine which PDU Session(s) to re-activate
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (request U-Plane activation)
    Note right of AMF: N11-equivalent (SBI). To be confirmed: operation name/conditions
    SMF->>UPF: PFCP Session Modification Request (N4)
    Note right of SMF: Reconfigure N3/FAR (reflecting the gNB-side N3 TEID may be finalized later)
    UPF-->>SMF: PFCP Session Modification Response
    SMF-->>AMF: UpdateSMContext Response (U-Plane information)

    AMF->>RAN: Initial Context Setup Request (NGAP)
    Note right of AMF: Set the UE context / AS security / PDU Session N3 information
    RAN->>UE: RRC configuration (AS security/radio resources, outline/out of scope)
    UE-->>RAN: RRC configuration complete (outline/out of scope)
    RAN-->>AMF: Initial Context Setup Response (NGAP)
    Note right of RAN: Notify the gNB-side N3 TEID

    opt Reflect the gNB-side N3 TEID into the UPF (implementation/procedure dependent)
        AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (gNB N3 information)
        SMF->>UPF: PFCP Session Modification (downlink FAR → gNB N3 TEID)
        UPF-->>SMF: PFCP Session Modification Response
    end

    Note over UE,UPF: N3 (GTP-U) re-established → uplink/downlink data flowing
    Note over UE: Transition to CM-CONNECTED

The difference from Network-triggered (Paging precedes it)¶

In the Network-triggered case, the biggest difference is that Paging is inserted before the diagram above. The UPF buffers and notifies of the DL data arrival, this passes through SMF→AMF, the AMF sends NGAP Paging, and the paged UE starts the Service Request of the diagram above.

sequenceDiagram
    autonumber
    participant UE as UE (CM-IDLE)
    participant RAN as (R)AN / gNB
    participant AMF
    participant SMF
    participant UPF

    Note over UPF: DL data for the target UE arrives (N3 not active) → buffer
    UPF->>SMF: PFCP Session Report (Downlink Data Report)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer (DL notification)
    Note right of SMF: For details, see the Paging chapter (paging.md)
    AMF->>RAN: NGAP Paging (to the gNBs of the Registration Area)
    RAN-->>UE: Air Paging (RRC, DRX)
    Note over UE: From here, start the same Service Request as "UE-triggered" above
    UE->>RAN: Service Request (NAS)
    Note over UE,UPF: Connection re-establishment / U-Plane re-activation (common with the diagram above)
    Note over UPF,UE: After re-establishment, deliver the buffered DL data

Step-by-step explanation (numbers correspond to the UE-triggered diagram)¶

1. UE→(R)AN: the need to originate, send UL data, etc. arises; the UE (on the radio side) establishes/resumes the RRC connection (outline/out of scope) and carries the Service Request (NAS). The NAS may include a Service type (e.g. mo-signalling / mo-data, etc.; values to be confirmed) and information on the PDU Session(s) to be re-activated. Reference: TS 24.501 §5.6.1 (section number to be confirmed).
2. (R)AN→AMF: the gNB puts the NAS onto an Initial UE Message (NGAP) and sends it to the AMF (N2 / TS 38.413).
3. (Conditional) security/re-authentication: the AMF verifies the existing security context. It re-authenticates and runs Security Mode only when needed (situation dependent; the details are the subject of the Security/Authentication chapter).
4. AMF's determination: the AMF determines which PDU Session(s) to re-activate, and notifies the SMF of the targets.
5. AMF→SMF: requests U-Plane activation via Nsmf_PDUSession_UpdateSMContext (N11-equivalent SBI). The specific operation name/conditions are to be confirmed.
6. SMF→UPF: reconfigures the UPF's N3/FAR via a PFCP Session Modification Request (N4). If the gNB-side N3 TEID is not yet fixed at this point, it may be fixed/reflected in a later step (steps 10-11) (procedure/implementation-dependent). Reference: TS 29.244.
7. SMF→AMF: returns U-Plane information (the UPF-side N3 TEID, etc.) in the UpdateSMContext Response.
8. AMF→(R)AN: sets the UE context, AS security, and PDU Session N3 information in the gNB via an Initial Context Setup Request (NGAP).
9. (R)AN⇔UE (radio side, outline/out of scope): the gNB sets the AS security/radio resources via RRC, and the UE returns completion.
10. (R)AN→AMF: notifies the gNB-side N3 TEID, etc. via an Initial Context Setup Response (NGAP).
11. (Implementation/procedure dependent) reflecting the gNB N3 TEID: to reflect the gNB-side N3 TEID into the UPF's downlink FAR, an N4 update via AMF→SMF→UPF may be performed again (procedure/implementation-dependent; some implementations integrate this with step 6 above = to be confirmed).
12. Data flow / state transition: N3 (GTP-U) is re-established, and uplink/downlink data flows. The UE transitions to CM-CONNECTED. In the Network-triggered case, the DL data buffered in the UPF is delivered.

Reference: TS 23.502 §4.2.3 series (UE Triggered / Network Triggered Service Request, section number to be confirmed), TS 24.501 §5.6 series (NAS Service Request), TS 38.413 (NGAP), TS 29.244 (PFCP).

Signal Flow¶

The key Messages / service operations organized in a table. The IEs are made consistent with the Message Dictionary. Some IE names and operation names are marked to be confirmed because they are version/implementation dependent.

State Machine¶

The CM (Connection Management) state transitions on the UE side. A Service Request returns a CM-IDLE UE to CM-CONNECTED, and the reverse-direction AN Release drops CM-CONNECTED to CM-IDLE (basis: TS 23.501 §5.3 series, section number to be confirmed).

stateDiagram-v2
    [*] --> CM_IDLE: registered, after connection release
    CM_IDLE --> CM_CONNECTED: UE-triggered Service Request (origination / UL data)
    CM_IDLE --> CM_CONNECTED: Network-triggered Service Request (Paging response)
    CM_CONNECTED --> CM_IDLE: AN Release (radio connection release / U-Plane deactivation)
    CM_CONNECTED --> [*]

• CM-IDLE — standby. There is no signaling connection for the UE, and the PDU Session's U-Plane (N3) is also deactivated. Starting a Service Request here (UE-triggered or a Paging response) moves it to CM-CONNECTED.
• CM-CONNECTED — connected. Data/signaling are possible. After a period of no communication, etc., it returns to CM-IDLE via AN Release (the U-Plane is deactivated).

Packet Analysis (Wireshark)¶

The key points when analyzing a Service Request with Wireshark. On the core side, the main observation targets are NAS Service Request / NGAP Initial Context Setup (N2) and PFCP Session Modification (N4).

Key Display Filters¶

Points to note when decoding (key IEs)¶

• NAS Service Request (UE→AMF) — note the following IEs (the IE names are representative notation, to be confirmed).
  • Service type — what the Service Request is for (mo-signalling / mo-data, etc.; the enumerated values are to be confirmed).
  • 5GS mobile identity — typically the 5G-S-TMSI (a short ID for Paging/connection resume).
  • Information on the PDU Session(s) to be re-activated — the instruction on which PDU Session to wake (equivalent to List Of PDU Sessions To Be Activated; IE name to be confirmed).
• NGAP Initial Context Setup Request/Response (AMF⇔gNB) — the UE context setup and the PDU Session Resource (N3 TEID information). The gNB-side N3 TEID is fixed in the Response.
• PFCP Session Modification Request (SMF→UPF) — the destination of the downlink FAR is updated to the new gNB's N3 TEID (the essence of U-Plane re-establishment).

The structure of NAS nested inside NGAP¶

The Service Request's NAS goes inside an NGAP message (Initial UE Message) as a NAS-PDU (the same nested structure as in Registration). In the packet detail pane it is displayed hierarchically as follows (the notation is conceptual; the actual names are dissector dependent = to be confirmed).

NGAP-PDU
 └─ InitialUEMessage
     └─ NAS-PDU
         └─ 5GS NAS Message
             └─ Service Request (Service type / 5G-S-TMSI, etc.)

Configuration¶

The structural-level key points of the configuration for making a Service Request work. Specific values and vendor-specific details (Cisco, etc.) are implementation-dependent, and no fictitious values are written here. Much of the transition to CM-IDLE (AN Release) determination and the RRC resume is on the radio-access side (gNB), and the core (5GC) side's configuration is limited.

Related to the CM-IDLE transition (AN Release)¶

• The deactivation timer / inactivity determination — how long a lack of communication must continue before AN Release drops it to CM-IDLE. The entity making the determination and the threshold are radio-side/implementation-dependent (the gNB's inactivity timer, etc.).
• The core (AMF) side must be configured to, upon receiving an AN Release, update the UE context's CM state to IDLE and reflect the U-Plane deactivation to the SMF/UPF.

Related to U-Plane re-establishment (the core AMF/SMF/UPF side)¶

• AMF — N2 (NGAP) is established, and it can process the Service Request (Initial UE Message / Initial Context Setup). It must hold the target UE's context (CM state, PDU Session list).
• SMF/UPF — a PDU Session is already established, an N4 (PFCP) association is established, and it must be configured to be able to reconfigure N3/FAR.

Trouble Shooting¶

Isolating typical Service Request failures (general discussion). For the details of Cause values, see the Cause Dictionary.

Comparison with EPC¶

A comparison so that those experienced with 4G (EPC) can bridge to 5G. The basic idea is common between 4G and 5G: "return from idle and re-lay the user plane of the bearer / session." 4G also has UE-triggered / Network-triggered (Paging response) Service Requests.

Release differences¶

The main topics related to the Service Request. Uncertain items are marked to be confirmed and not asserted.

• Rel-15 — the basics of the 5GC Service Request (UE-triggered / Network-triggered, CM states, U-Plane re-activation of the PDU Session) were established.
• RRC Inactive (RRC_INACTIVE) — a UE state introduced in Rel-15. When the UE is in RRC_INACTIVE, a lightweight connection resume via RRC Resume, rather than a full Service Request, may be used (a radio-side mechanism; the handling of the CM state as seen from the core and the details are to be confirmed). This chapter focuses on the core-triggered Service Request, and the details of RRC Resume are out of scope.
• Small Data Transmission (SDT) — a signaling-saving extension discussed/introduced from Rel-16 onward, for sending a small amount of data without fully establishing a connection (radio-centric; the scope of application and the impact on the core are to be confirmed). Out of scope of this chapter's Rel-15 basics.
• Rel-17 / Rel-18 (5G-Advanced) — further power-saving/signaling-saving extensions continue (the specific differences to the Service Request procedure itself are to be confirmed).

3GPP Specification¶

FAQ¶

Summary¶

• A Service Request is the procedure by which a registered UE in CM-IDLE re-establishes the radio connection and UE context and transitions from CM-IDLE → CM-CONNECTED.
• There are two triggers. UE-triggered = the UE spontaneously starts it for origination/UL data. Network-triggered = it is called by Paging on the arrival of DL data and starts as a response (Paging precedes it).
• From the core's viewpoint, the leading roles are the AMF (NAS/N2 control) and the SMF/UPF (U-Plane re-establishment). Radio details such as RRC Resume are out of scope.
• The broad flow is NAS Service Request (N1/N2) → the AMF sends Nsmf UpdateSMContext to the SMF → the SMF reconfigures the UPF's N3/FAR over N4 → NGAP Initial Context Setup sets the UE context/N3 information → N3 re-establishment → uplink/downlink flow.
• The U-Plane re-activation of the PDU Session (reconfiguration of the N3 tunnel/FAR) is essential. The reverse-direction AN Release folds up CM-CONNECTED → CM-IDLE (a two-sided pair).
• It corresponds to the 4G Service Request (MME / S1AP / ECM-IDLE→CONNECTED / EPS bearer re-activation), while 5G uses the AMF / NGAP / CM-IDLE→CONNECTED / U-Plane re-activation of the PDU Session.
• The basis is TS 23.502 §4.2.3 series / TS 23.501 §5.3 series / TS 24.501 §5.6 series / TS 38.413 / TS 29.244 (some section numbers and IE names are to be confirmed).

Practice — comprehension check and exercises¶

Comprehension check¶

Exercises¶

Problem: Reorder the following main UE-triggered Service Request steps into the correct order.

A. AMF → gNB: Initial Context Setup Request (NGAP)
B. UE → gNB: Service Request (NAS) (after RRC connection establishment)
C. SMF → UPF: PFCP Session Modification (N3/FAR reconfiguration)
D. gNB → AMF: carry the NAS via Initial UE Message (NGAP)
E. N3 (GTP-U) re-established → uplink/downlink data flowing (CM-CONNECTED)
F. AMF → SMF: Nsmf_PDUSession_UpdateSMContext (U-Plane activation)
G. gNB → AMF: Initial Context Setup Response (NGAP) (gNB N3 TEID)

Next Step¶

The next steps to deepen your understanding.

• Direct upstream: Paging (the calling procedure that the Network-triggered Service Request responds to)
• Procedure prerequisites: Initial Registration / PDU Session Establishment
• Sister procedure: Handover (connection switching while moving)
• Mobility Registration Update chapter (registration update across Registration Areas = the equivalent of 4G's TAU)
• RRC Resume / Small Data Transmission (lightweight return from RRC Inactive, radio-centric)
• Related NFs: AMF / SMF / UPF
• Related Interfaces: N1 / N2 / N3 / N4
• Dictionaries: Message Dictionary / Timer Dictionary / Cause Dictionary / Protocol Dictionary / NF Dictionary / Interface Dictionary