CM-IDLE / CM-CONNECTED and Service Request — Keeping Registration State and CM State Apart¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain, using the four combinations, that the RM state (registration state) and the CM state (connection state) are two independent axes
• Distinguish what is released on the transition to CM-IDLE (the UE-associated logical NG-connection, the N3 User Plane connection, the UE Context in the gNB) from what is kept (the AMF UE Context, the registration, the PDU Session, the PFCP Session in the UPF)
• Trace what each NGAP, Nsmf and PFCP message changes during AN Release (TS 23.502 §4.2.6)
• Explain how Paging → Service Request reactivates the User Plane, and that it is normal for the gNB-side N3 TEID and the NGAP IDs to change across it
• Explain what it means that a UE in RRC_INACTIVE is CM-CONNECTED from the core's point of view, and how this differs from CM-IDLE
• Avoid confusing "the subscriber shows up in the CLI" with "the UE is CM-CONNECTED," and list which state to check where

Prerequisites¶

• Tracking Area / TAI / Registration Area — the previous chapter; why the location of a CM-IDLE UE is known only at Registration Area granularity
• Service Request — the overall flow of the procedure (this chapter digs into its "states" and "what is kept and what is lost")
• Paging — incoming traffic to CM-IDLE UEs
• Supplementary: N2 / N3 / N4 / RRC Resume / Small Data / SUPI / SUCI / 5G-GUTI (5G-S-TMSI)

Why — why keep "registration" and "connection" as separate states?¶

If a UE stayed registered with the 5GC and also kept N2 and N3 up permanently, the following problems would arise:

• The UE would keep its radio connection (RRC) alive and drain its battery
• The gNB would keep holding UE Contexts and radio resources that are not being used
• The AMF and the gNB would have to maintain a huge number of UE-associated N2 connections for UEs that are not communicating

On the other hand, if the registration itself were deleted every time communication paused, every resumption would require authentication, security setup, Registration and PDU Session Establishment all over again, with enormous signaling and latency.

5GS therefore manages "is the UE registered with the network?" (Registration Management, RM) and "does the UE currently have a signaling connection?" (Connection Management, CM) as independent states (TS 23.501 §5.3.2 / §5.3.3). While there is no traffic, only CM drops to IDLE; registration, security and PDU Sessions are kept. On resumption, only the parts that were cut (N2, N3 and radio) are re-established by a Service Request.

Analogy: RM is "your membership," and CM is "whether you are currently sitting at the counter." When you leave the counter (CM-IDLE), your membership card (5G-GUTI) and the documents you handed in (UE Context, PDU Session) stay on file. When you have business again, you return to the counter and show your card (Service Request), and the procedure resumes right away without resubmitting all the documents. Cancelling your membership (Deregistration) is a different matter.

What — RM state and CM state¶

The two states are independent¶

The NAS signalling connection consists of two segments: the AN signalling connection between the UE and the AN (the RRC connection for 3GPP access) and the N2 connection for that UE between the AN and the AMF (TS 23.501 §5.3.3.1). The CM state tells whether this "control path dedicated to the UE" exists.

On the NAS side (TS 24.501), the same concepts are expressed with the terms 5GMM-REGISTERED / 5GMM-DEREGISTERED (5GMM sublayer states) and 5GMM-IDLE mode / 5GMM-CONNECTED mode. The definitions in TS 24.501 §3.1 state explicitly that 5GMM-IDLE mode corresponds to the CM-IDLE state of TS 23.501 (to be confirmed). When a trace or a log says "5GMM-IDLE," read it as CM-IDLE. Note, however, that the 5GMM sublayer states include intermediate states such as 5GMM-REGISTERED-INITIATED (during Initial Registration), 5GMM-SERVICE-REQUEST-INITIATED and 5GMM-DEREGISTERED-INITIATED, so they do not map one-to-one onto the RM state (TS 24.501 §5.1.3.2.1, to be confirmed). For example, during Initial Registration (before the Registration Accept), the UE's 5GMM sublayer state is 5GMM-REGISTERED-INITIATED (how logs display it is implementation dependent).

The four combinations¶

flowchart TD
    subgraph REG["RM-REGISTERED"]
        A["CM-CONNECTED
communicating or signaling"]
        B["CM-IDLE
idle. Paging target"]
    end
    subgraph DEREG["RM-DEREGISTERED"]
        C["CM-CONNECTED
Initial Registration in progress
right after Reject or Deregistration"]
        D["CM-IDLE
power off or not registered"]
    end
    A -- "AN Release" --> B
    B -- "Service Request / Registration" --> A
    D -- "Registration Request sent" --> C
    C -- "Registration Accept" --> A

"DEREGISTERED but CONNECTED" looks odd at first, but in Initial Registration the UE enters CM-CONNECTED when the Registration Request (an initial NAS message) is sent and enters RM-REGISTERED with the Registration Accept, so this combination always occurs in between (TS 23.501 §5.3.2.2 / §5.3.3.2.2). It is a good illustration that the two axes are independent.

UE and AMF behavior per CM state¶

On the AMF side, the UE becomes CM-CONNECTED on receipt of an initial N2 message such as the Initial UE Message, and becomes CM-IDLE when the logical NGAP signalling connection and the N3 user plane connection are released on completion of the AN Release procedure (TS 23.501 §5.3.3.2.2 / §5.3.3.2.3).

What — what is released and what is kept in CM-IDLE¶

This is the most important table in the chapter.

           CM-CONNECTED                          CM-IDLE
 UE ──RRC── gNB ──N2(UE-assoc)── AMF     UE        gNB        AMF [UE Context ○]
             │                    │                            │
             └──N3 GTP-U──► UPF   │                 UPF [PFCP Session ○]
                           (DL FAR: forward)            (DL FAR: buffer / notify)
 SMF [SM Context ○]                       SMF [SM Context ○]  upCnxState = DEACTIVATED

What remains in the AMF UE Context¶

AMF UE Context (kept while CM-IDLE)
├─ SUPI / 5G-GUTI (→ 5G-S-TMSI is used for Paging)
├─ 5G NAS security context (KAMF, NAS COUNTs, etc.)
├─ Registration Area (TAI List), last known TAI / cell
├─ UE Radio Capability (if stored, can be handed to the gNB next time)
├─ Allowed NSSAI, Mobility Restriction, etc.
├─ Mapping PDU Session ID ⇔ SMF (SM Context)
└─ Assistance information for Paging (may be received from the gNB in UE Context Release Complete)

• Because the 5G NAS security context is kept, a Service Request can normally be integrity-protected without re-authentication. The AS key for the gNB (KgNB) is derived anew from KAMF and the UL NAS COUNT of the Service Request and handed to the gNB in the Security Key IE of the Initial Context Setup Request (derivation function: TS 33.501 Annex A.9; key handling on the CM-IDLE → CM-CONNECTED transition: under TS 33.501 §6.8.1; both to be confirmed). Note that AS security is not "kept"; it is rebuilt every time.
• If the AMF stores the UE Radio Capability, it can hand it to the gNB in the Initial Context Setup Request, so the gNB does not have to query the UE for its capabilities again (TS 23.501 §5.4.4.1, to be confirmed).
• The gNB can include Information on Recommended Cells and RAN Nodes for Paging in UE Context Release Complete, and the AMF can use it to optimize the next Paging (TS 23.502 §4.2.6, TS 38.413 §9.2.2.6, to be confirmed). How it is used depends on the AMF implementation.

How — AN Release (CM-CONNECTED → CM-IDLE)¶

AN Release is the procedure that releases the logical NG-AP signalling connection between the UE and the AMF, the associated N3 User Plane connections, and the (R)AN RRC signalling and resources (TS 23.502 §4.2.6). It can be (R)AN-initiated (e.g. user inactivity, O&M, radio link failure) or AMF-initiated (e.g. there is no reason to keep the NAS signalling connection after a procedure completes).

Call Flow (gNB-initiated, user inactivity example)¶

sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    participant SMF
    participant UPF
    Note over UE,gNB: No data for a while (decision is gNB implementation dependent)
    gNB->>AMF: NGAP UE Context Release Request
(Cause, PDU Session Resource List)
    AMF->>gNB: NGAP UE Context Release Command
(UE NGAP IDs, Cause)
    gNB->>UE: RRC Release
    gNB->>AMF: NGAP UE Context Release Complete
(User Location Information, Recommended Cells for Paging, etc.)
    Note over gNB,AMF: UE-associated logical NG-connection released
AMF UE NGAP ID / RAN UE NGAP ID become invalid
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(upCnxState = DEACTIVATED)
    SMF->>UPF: PFCP Session Modification Request
(remove AN Tunnel Info, DL FAR to buffer / notify)
    UPF-->>SMF: PFCP Session Modification Response
    SMF-->>AMF: UpdateSMContext Response
    Note over AMF: UE is CM-IDLE (still RM-REGISTERED)

When the AMF initiates, step 1 is absent and the AMF starts with the UE Context Release Command. A typical case is the AMF releasing the NAS signalling connection after Registration completes when there is no Follow-on request (TS 24.501 §5.3.1.3, TS 23.502 §4.2.2.2.2; exact location to be confirmed). When to release is a local decision of the AMF.

What happens in the UPF — switching the DL FAR¶

When a DL packet reaches the UPF during CM-IDLE, the UPF does not know the gNB's F-TEID. So in the N4 update of AN Release, the SMF switches the DL FAR as follows (Apply Action: TS 29.244 §8.2.26, to be confirmed).

The SMF decides whether buffering is done in the UPF or in the SMF (TS 23.501 §5.8.3, to be confirmed). When the SMF buffers, the UPF forwards DL packets to the SMF over N4.

How — Paging → Service Request (CM-IDLE → CM-CONNECTED)¶

The main way back from CM-IDLE to CM-CONNECTED is the Service Request (TS 23.502 §4.2.3). There are two triggers.

The Service type values (signalling / data / mobile terminated services / emergency services / emergency services fallback / high priority access / elevated signalling, etc.) are defined in TS 24.501 §9.11.3.50 (values have been added across Releases, to be confirmed).

First half of Network-triggered — up to Paging¶

sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    participant SMF
    participant UPF
    Note over UPF: DL packet arrives. DL FAR is BUFF + NOCP
    UPF->>SMF: PFCP Session Report Request
(Report Type = DLDR, PDR ID)
    SMF-->>UPF: PFCP Session Report Response
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer
(PDU Session ID, N2 SM information)
    AMF-->>SMF: 202 Accepted
(ATTEMPTING_TO_REACH_UE)
    AMF->>gNB: NGAP Paging
(UE Paging Identity = 5G-S-TMSI, TAI List for Paging)
    gNB->>UE: RRC Paging
    Note over UE: From here the flow is the same as a UE-triggered Service Request
Service type = mobile terminated services

• When the AMF receives the N1N2MessageTransfer from the SMF and the UE is CM-IDLE, the AMF pages it and first replies that it is "attempting to reach the UE" (TS 23.502 §4.2.3.3, TS 29.518 §5.2.2.3.1; details of the response to be confirmed). If the UE is CM-CONNECTED, no Paging is needed and the AMF goes straight to N2 PDU Session Resource Setup.
• If the UE does not respond, the AMF notifies the SMF of the N1N2 transfer failure, and the SMF can instruct the UPF how to handle the buffered data (TS 23.502 §4.2.3.3, to be confirmed).
• A UE in MICO mode is considered unreachable while CM-IDLE (except during an Active Time, if one has been granted) and is not paged (TS 23.501 §5.4.1.3, to be confirmed). It is not true that "a CM-IDLE UE can always be paged."
• For how the Paging destination (TAI List for Paging) is derived from the Registration Area, see the previous chapter.

UE-triggered Service Request and User Plane activation¶

sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    participant SMF
    participant UPF
    UE->>gNB: RRC Setup + Service Request (NAS)
    gNB->>AMF: NGAP Initial UE Message
(new RAN UE NGAP ID, 5G-S-TMSI, NAS-PDU)
    Note over AMF: Identify the existing UE Context by 5G-S-TMSI
Allocate a new AMF UE NGAP ID
Verify NAS integrity (re-authenticate only if needed)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(upCnxState = ACTIVATING)
    SMF-->>AMF: Response (N2 SM information
UPF-side N3 F-TEID, QoS Flows, etc.)
    AMF->>gNB: NGAP Initial Context Setup Request
(Security Key, PDU Session Resource Setup List, NAS: Service Accept)
    gNB->>UE: RRC Security Mode Command (AS security)
RRC Reconfiguration (DRB)
    Note over UE,UPF: UL can now flow gNB → UPF
    gNB->>AMF: NGAP Initial Context Setup Response
(gNB-side N3 F-TEID = new TEID)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(N2 SM information)
    SMF->>UPF: PFCP Session Modification Request
(DL FAR = FORW, new gNB F-TEID)
    UPF-->>SMF: PFCP Session Modification Response
    SMF-->>AMF: Response (upCnxState = ACTIVATED)
    Note over UE,UPF: DL flows too. Buffered DL data is sent out

Service Request is also used in CM-CONNECTED¶

The Service Request is not exclusive to CM-IDLE. It is also sent when a CM-CONNECTED UE wants to activate a PDU Session whose User Plane is inactive (TS 23.502 §4.2.3.2). In that case the gNB already has a UE Context, so the NAS is carried in Uplink NAS Transport (TS 38.413 §8.6.3), and the AMF sets up N3 with PDU Session Resource Setup (TS 38.413 §8.2.1) rather than Initial Context Setup. Assuming "Service Request = return from IDLE" leads to misreading traces.

How — values that change and values that do not across a Service Request¶

(The addresses are documentation example addresses, and the TEIDs are fictitious values.)

gNB DL F-TEID:  0x0000aa01 ──(removed by AN Release)──► none ──(Service Request)──► 0x0000bb07

Relationship with RRC_INACTIVE — "the radio is resting but the UE is CM-CONNECTED"¶

NR RRC has three states: RRC_IDLE / RRC_INACTIVE / RRC_CONNECTED. A UE in RRC_INACTIVE remains CM-CONNECTED from the core's (AMF's) point of view (TS 23.501 §5.3.3.2.5).

• The AMF gives NG-RAN RRC Inactive Assistance Information as input for deciding whether to use RRC_INACTIVE, and can, if needed, ask NG-RAN to report the UE's RRC state transitions with RRC Inactive Transition Report (TS 38.413 §8.3.5) (TS 23.501 §5.3.3.2.5, to be confirmed). Unless it asks for the report, the AMF does not distinguish whether the UE is RRC_INACTIVE or RRC_CONNECTED.
• What happens when the UE does not respond to RAN Paging depends on the case. If there is a pending NAS PDU to deliver, NG-RAN initiates AN Release and moves the CM state in the AMF back to CM-IDLE. If only User Plane data is pending, NG-RAN decides by local configuration whether to keep N2 or initiate AN Release (TS 23.501 §5.3.3.2.5, to be confirmed).
• When the UE resumes RRC at a different gNB, the N2 Path Switch Request (TS 38.413 §8.4.4, to be confirmed) switches the DL N3 destination to the new gNB.

See RRC Resume / Small Data for details. The point to take away here is that "the radio is resting" is not the same as "CM-IDLE."

Packet Analysis (Wireshark)¶

Display filters¶

The numeric NGAP procedureCode values may be displayed differently depending on the dissector and version, so this page does not assert them. Checking the message names in the GUI protocol tree is the reliable approach. SBI (Nsmf / Namf) is often TLS-encrypted and its content is not visible without a key log; in that case, check the upCnxState transitions in the SMF / AMF logs.

Decode example (conceptual)¶

The following is a conceptual representation of the display structure; the values use the test PLMN (001-01) and fictitious values (capture required).

NGAP UEContextReleaseCommand
 ├─ UE-NGAP-IDs
 │   └─ uE-NGAP-ID-pair: AMF-UE-NGAP-ID = 7, RAN-UE-NGAP-ID = 1001
 └─ Cause: radioNetwork = user-inactivity

PFCP Session Modification Request (after AN Release)
 └─ Update FAR (FAR ID = 2, DL)
     ├─ Apply Action: BUFF, NOCP
     └─ (forwarding to the gNB via Forwarding Parameters is no longer used; IE-level handling is implementation dependent, to be confirmed)

NGAP InitialUEMessage (at Service Request)
 ├─ RAN-UE-NGAP-ID: 1042            ← different from the previous 1001
 ├─ NAS-PDU
 │   └─ Service request
 │       ├─ Service type: data
 │       ├─ 5GS mobile identity: 5G-S-TMSI
 │       └─ NAS message container (after deciphering: Uplink data status / PDU session status)
 ├─ UserLocationInformation (NR CGI / TAI)
 └─ FiveG-S-TMSI

NGAP InitialContextSetupResponse
 └─ PDUSessionResourceSetupListCxtRes
     └─ PDU Session ID = 1
         └─ PDUSessionResourceSetupResponseTransfer (N2 SM information; the AMF forwards it to the SMF transparently)
             └─ DL QoS Flow per TNL Information > UP Transport Layer Information
                 └─ 192.0.2.10 / TEID 0x0000bb07   ← new gNB F-TEID

Order of checks¶

flowchart LR
    A["① AN Release
UE Context Release
Request / Command / Complete"] --> B["② N4
DL FAR to BUFF/NOCP"]
    B --> C["③ DL arrives
Session Report DLDR
→ NGAP Paging"]
    C --> D["④ Service Request
Initial UE Message
find context by 5G-S-TMSI"]
    D --> E["⑤ Initial Context Setup
gNB F-TEID in Response"]
    E --> F["⑥ N4
DL FAR now FORW +
new F-TEID?"]
    F --> G["⑦ GTP-U
DL flowing on new TEID?"]

In the UE-triggered case, ③ is absent and the flow starts at ④.

Trouble Shooting¶

"Visible in show subscriber" does not mean "CONNECTED"¶

Even if a UE appears in an operational CLI (e.g. a show subscriber-style command), that only shows that the AMF or SMF has a context for it; it does not mean the UE is CM-CONNECTED. A CM-IDLE UE also still has an AMF UE Context and PDU Sessions. CLI command names and displayed items are vendor implementation dependent, but the states to check can be organized with the specification's concepts.

When "the subscriber is visible but incoming traffic does not arrive," check the states separately, at least in the order RM state → CM state → upCnxState → DL FAR in the UPF.

Boundary between 3GPP specifications and vendor implementations¶

Comparison with EPC (4G)¶

The ideas are almost the same; the major differences in the 5GC are selective User Plane activation per PDU Session and RRC_INACTIVE.

3GPP Specification¶

Summary¶

• The RM state (registration) and the CM state (connection) are independent. RM-REGISTERED + CM-IDLE is the most common state, and RM-DEREGISTERED + CM-CONNECTED always appears during Initial Registration
• What is released in CM-IDLE is on the Access Network side (RRC, the gNB's UE Context, the UE-associated logical NG-connection, the N3 User Plane connection)
• What is kept is on the core side (the AMF UE Context, the registration, the 5G NAS security context, the PDU Session, the PFCP Session in the PSA UPF). The UPF's DL FAR is switched to buffer / notify
• The way back is the Service Request. Network-triggered starts with Paging, then follows the same steps as UE-triggered and activates the User Plane per PDU Session
• It is normal for the gNB-side N3 TEID, the NGAP IDs and KgNB to change across a Service Request. After a response to Paging, the 5G-GUTI (5G-S-TMSI) is also reallocated. What is abnormal is the UPF still pointing at the old TEID
• RRC_INACTIVE is CM-CONNECTED. N2 / N3 are kept, and DL reaches the UE through RAN Paging
• In operations, look at RM state → CM state → upCnxState → DL FAR separately. "The subscriber is visible" is not evidence of CONNECTED

Comprehension check¶

Next Step¶

• How the PDU Session's N3 is created in the first place (N1 SM / N2 SM / F-TEID hand-off) → PDU Session Establishment Deep Dive
• The contents of the UPF's DL FAR (BUFF / NOCP / FORW) → PFCP and PDR / FAR / QER / URR
• The overall procedures → Service Request / Paging
• Location management of CM-IDLE UEs → Tracking Area / TAI / Registration Area / Periodic Registration Update
• RRC_INACTIVE and RRC Resume → RRC Resume / Small Data
• The 5G-S-TMSI used for Paging → SUPI / SUCI / 5G-GUTI
• Interfaces → N2 / N3 / N4 / NGAP Dictionary / NAS Dictionary