CM-IDLE / CM-CONNECTED と Service Request — Registration StateとCM Stateを分けて考える¶

学習目標¶

この章を読み終えると、次のことができるようになります。

• RM state（登録状態） と CM state（接続状態） が独立した2軸であることを、4つの組み合わせで説明できる
• CM-IDLEへ遷移したときに 解放されるもの（UE-associated logical NG-connection、N3 User Plane connection、gNBのUE Context）と 残るもの（AMF UE Context、Registration、PDU Session、UPFのPFCP Session）を区別できる
• AN Release（TS 23.502 §4.2.6）で、NGAP・Nsmf・PFCPの各メッセージが何を変えるかを追跡できる
• Paging → Service Request でUser Planeが再アクティブ化される流れと、その前後で gNB側N3 TEID や NGAP ID が変わるのは正常 であることを説明できる
• RRC_INACTIVE のUEがコアから見て CM-CONNECTED である意味と、CM-IDLEとの違いを説明できる
• 運用CLIで「Subscriberが見える」ことと「CM-CONNECTEDである」ことを混同せず、どの状態をどこで確認すべきかを挙げられる

前提知識¶

• Tracking Area / TAI / Registration Area — 前章。CM-IDLE UEの位置が Registration Area 単位でしか分からない理由
• Service Request — 手続き全体の流れ（本章はその「状態」と「残るもの・消えるもの」を深掘りします）
• Paging — CM-IDLE UEへの着信
• 補助: N2 / N3 / N4 / RRC Resume / Small Data / SUPI / SUCI / 5G-GUTI（5G-S-TMSI）

Why — なぜ「登録」と「接続」を別の状態として持つのか¶

UEが5GCに登録したまま、常にN2とN3を張りっぱなしにすると、次の問題が起きます。

• UEは無線接続（RRC）を維持し続けるため、電池を消費 する
• gNBは使われないUE Contextと無線リソースを抱え続ける
• AMF・gNBは、通信していないUEのためにUE-associatedなN2接続を大量に維持することになる

一方、通信が途切れるたびに 登録まで消してしまう と、再開のたびに認証・セキュリティ確立・Registration・PDU Session Establishment をやり直すことになり、シグナリングと遅延が膨大になります。

そこで5GSは、「網に登録されているか」（Registration Management, RM） と 「いまシグナリング接続を持っているか」（Connection Management, CM） を独立した状態として管理します（TS 23.501 §5.3.2 / §5.3.3）。通信が無い間は CM だけを IDLE に落とし、登録・セキュリティ・PDU Session は残しておく。再開時は、切った部分（N2・N3・無線）だけを Service Request で張り直します。

例え話: RM は「会員登録」、CM は「いま窓口に座っているか」です。窓口を離れても（CM-IDLE）会員証（5G-GUTI）も預けた書類（UE Context・PDU Session）も残っています。用事ができたら窓口に戻って会員証を見せれば（Service Request）、書類一式を出し直さずにすぐ手続きを再開できます。会員を辞める（Deregistration）こととは別の話です。

What — RM state と CM state¶

2つの状態は独立している¶

NAS signalling connection は、UE⇔AN間のAN signalling connection（3GPP accessではRRC接続） と、そのUEのためのAN⇔AMF間のN2 connection の2区間からなります（TS 23.501 §5.3.3.1）。CM state は、この「UE専用の制御の通り道」があるかどうかの状態です。

NAS（TS 24.501）側では、同じ概念を 5GMM-REGISTERED / 5GMM-DEREGISTERED（5GMM sublayer state）と 5GMM-IDLE mode / 5GMM-CONNECTED mode という用語で表します。TS 24.501 §3.1 の定義で、5GMM-IDLE mode は TS 23.501 の CM-IDLE state に対応すると明記されています（要確認）。Traceやログで「5GMM-IDLE」と書かれていたら、CM-IDLE の話だと読み替えてください。ただし 5GMM sublayer state には 5GMM-REGISTERED-INITIATED（Initial Registration 中）、5GMM-SERVICE-REQUEST-INITIATED、5GMM-DEREGISTERED-INITIATED などの中間状態があり、RM state と1対1には対応しません（TS 24.501 §5.1.3.2.1、要確認）。たとえば Initial Registration 中（Registration Accept 前）の UE の 5GMM sublayer state は 5GMM-REGISTERED-INITIATED です（ログ上の表記は実装依存）。

4つの組み合わせ¶

flowchart TD
    subgraph REG["RM-REGISTERED"]
        A["CM-CONNECTED
通信中・シグナリング中"]
        B["CM-IDLE
待受中。Paging対象"]
    end
    subgraph DEREG["RM-DEREGISTERED"]
        C["CM-CONNECTED
Initial Registration処理中
Reject・Deregistration直後"]
        D["CM-IDLE
電源OFF・未登録"]
    end
    A -- "AN Release" --> B
    B -- "Service Request / Registration" --> A
    D -- "Registration Request送信" --> C
    C -- "Registration Accept" --> A

「DEREGISTERED なのに CONNECTED」は一見奇妙ですが、Initial Registration では Registration Request（Initial NAS message）の送信でCM-CONNECTEDに入り、Registration Accept でRM-REGISTEREDに入る ため、その間は必ずこの組み合わせになります（TS 23.501 §5.3.2.2 / §5.3.3.2.2）。2軸が独立していることがよく分かる例です。

CM state ごとの「UEとAMFの振る舞い」¶

AMF側では、Initial UE Message 等の initial N2 message を受信すると CM-CONNECTED に、AN Release 手続きの完了で logical NGAP signalling connection と N3 user plane connection が解放されると CM-IDLE に遷移します（TS 23.501 §5.3.3.2.2 / §5.3.3.2.3）。

What — CM-IDLE で何が解放され、何が残るのか¶

この章でいちばん大事な表です。

           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: 転送)               (DL FAR: バッファ／通知)
 SMF [SM Context ○]                       SMF [SM Context ○]  upCnxState = DEACTIVATED

AMF の UE Context に何が残るか¶

AMF UE Context（CM-IDLE 中も保持）
├─ SUPI / 5G-GUTI（→ 5G-S-TMSI は Paging に使う）
├─ 5G NAS security context（KAMF、NAS COUNT 等）
├─ Registration Area（TAI List）、最後に分かったTAI / Cell
├─ UE Radio Capability（保持していれば、次回gNBへ渡せる）
├─ Allowed NSSAI、Mobility Restriction 等
├─ PDU Session ID ⇔ SMF（SM Context）の対応
└─ Paging 用の補助情報（UE Context Release Complete で gNB から受け取り得る）

• 5G NAS security context が残る ので、Service Request では通常、再認証なしで NAS を integrity protect できます。gNB 用の AS 鍵（KgNB）は KAMF と Service Request の UL NAS COUNT から導出し直し、Initial Context Setup Request の Security Key IE で gNB に渡します（導出関数は TS 33.501 Annex A.9、CM-IDLE → CM-CONNECTED 遷移時の鍵の扱いは TS 33.501 §6.8.1 配下、いずれも要確認）。AS security は「残る」のではなく 毎回作り直される 点に注意します。
• UE Radio Capability を AMF が保持していれば、Initial Context Setup Request で gNB へ渡せるため、gNB が UE に能力照会をやり直す必要がなくなります（TS 23.501 §5.4.4.1、要確認）。
• gNB は UE Context Release Complete に Information on Recommended Cells and RAN Nodes for Paging を含めることができ、AMF はこれを次回の Paging の最適化に使えます（TS 23.502 §4.2.6、TS 38.413 §9.2.2.6、要確認）。どう使うかは AMF 実装依存です。

How — AN Release（CM-CONNECTED → CM-IDLE）¶

AN Release は、UEとAMFの間の logical NG-AP signalling connection と、それに関連する N3 User Plane connection、および (R)AN の RRC signalling と資源を解放する 手続きです（TS 23.502 §4.2.6）。(R)AN 起点（例: User Inactivity、O&M、無線リンク障害）と AMF 起点（例: 手続き完了後に NAS signalling connection を維持する理由が無い）があります。

Call Flow（gNB起点・User Inactivity の例）¶

sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    participant SMF
    participant UPF
    Note over UE,gNB: 一定時間データ無し（判定は gNB 実装依存）
    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 等)
    Note over gNB,AMF: UE-associated logical NG-connection 解放
AMF UE NGAP ID / RAN UE NGAP ID は無効に
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(upCnxState = DEACTIVATED)
    SMF->>UPF: PFCP Session Modification Request
(AN Tunnel Info 削除、DL FAR をバッファ／通知へ)
    UPF-->>SMF: PFCP Session Modification Response
    SMF-->>AMF: UpdateSMContext Response
    Note over AMF: UE は CM-IDLE（RM-REGISTERED のまま）

AMF 起点の場合は、手順1が無く、AMF が UE Context Release Command から始めます。Registration 完了後に Follow-on request が無ければ AMF が NAS signalling connection を解放する、というのがその典型です（TS 24.501 §5.3.1.3、TS 23.502 §4.2.2.2.2、該当箇所は要確認）。解放するタイミングは AMF のローカル判断です。

UPF では何が起きるか — DL FAR の切り替え¶

CM-IDLE の間に DL パケットが UPF に届いたとき、UPF は gNB の F-TEID を知りません。そこで SMF は AN Release の N4 更新で、DL 方向の FAR を次のように切り替えます（Apply Action は TS 29.244 §8.2.26、要確認）。

バッファを UPF で行うか SMF で行うか は SMF が決めます（TS 23.501 §5.8.3、要確認）。SMF でバッファする場合、UPF は DL パケットを N4 経由で SMF へ転送します。

How — Paging → Service Request（CM-IDLE → CM-CONNECTED）¶

CM-IDLE から CM-CONNECTED へ戻る主な手段が Service Request です（TS 23.502 §4.2.3）。起点は2つあります。

Service type の値（signalling / data / mobile terminated services / emergency services / emergency services fallback / high priority access / elevated signalling 等）は TS 24.501 §9.11.3.50 で定義されています（値の一覧は Release により追加あり、要確認）。

Network-triggered の前半 — Paging まで¶

sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    participant SMF
    participant UPF
    Note over UPF: DL パケット到着。DL FAR は 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: 以降は UE-triggered Service Request と同じ流れ
Service type = mobile terminated services

• SMF からの N1N2MessageTransfer を受けたとき、UE が CM-IDLE なら AMF は Paging を行い、まず「UEに到達を試みている」旨を応答します（TS 23.502 §4.2.3.3、TS 29.518 §5.2.2.3.1、応答の細部は要確認）。UE が CM-CONNECTED なら Paging は不要 で、AMF はそのまま N2 の PDU Session Resource Setup へ進みます。
• UE が応答しない場合、AMF は SMF へ N1N2 transfer の失敗を通知し、SMF はバッファしたデータの扱いを UPF に指示できます（TS 23.502 §4.2.3.3、要確認）。
• MICO mode の UE は、CM-IDLE 中は（Active Time が付与されている場合のその期間を除き）到達不能とみなされ、Paging されません（TS 23.501 §5.4.1.3、要確認）。「CM-IDLE なら必ず Paging できる」わけではありません。
• Paging の宛先（TAI List for Paging）が Registration Area から決まる仕組みは 前章 を参照してください。

UE-triggered Service Request と 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
(新しい RAN UE NGAP ID, 5G-S-TMSI, NAS-PDU)
    Note over AMF: 5G-S-TMSI で既存 UE Context を特定
新しい AMF UE NGAP ID を割り当て
NAS integrity を検証（必要時のみ再認証）
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(upCnxState = ACTIVATING)
    SMF-->>AMF: Response (N2 SM information
UPF 側 N3 F-TEID, QoS Flow 等)
    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 は gNB → UPF へ流せるようになる
    gNB->>AMF: NGAP Initial Context Setup Response
(gNB 側 N3 F-TEID ＝ 新しい TEID)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
(N2 SM information)
    SMF->>UPF: PFCP Session Modification Request
(DL FAR = FORW, 新しい gNB F-TEID)
    UPF-->>SMF: PFCP Session Modification Response
    SMF-->>AMF: Response (upCnxState = ACTIVATED)
    Note over UE,UPF: DL も流れる。バッファ済み DL データを送出

CM-CONNECTED でも Service Request は使われる¶

Service Request は CM-IDLE 専用ではありません。CM-CONNECTED の UE が、User Plane が非活性な PDU Session を活性化したいとき にも送られます（TS 23.502 §4.2.3.2）。この場合 gNB には既に UE Context があるため、NAS は Uplink NAS Transport（TS 38.413 §8.6.3）で運ばれ、AMF は Initial Context Setup ではなく PDU Session Resource Setup（TS 38.413 §8.2.1）で N3 を張ります。「Service Request = IDLE からの復帰」と決めつけると、Trace の読み間違いにつながります。

How — Service Request の前後で「変わる値」と「変わらない値」¶

（アドレスはドキュメント用の例示アドレス、TEID は架空値です。）

gNB DL F-TEID:  0x0000aa01 ──(AN Release で削除)──► なし ──(Service Request)──► 0x0000bb07

RRC_INACTIVE との関係 — 「無線は休んでいるが CM-CONNECTED」¶

NR では RRC に RRC_IDLE / RRC_INACTIVE / RRC_CONNECTED の3状態があります。RRC_INACTIVE の UE は、コア（AMF）から見ると CM-CONNECTED のままです（TS 23.501 §5.3.3.2.5）。

• AMF は、RRC_INACTIVE を使うかどうかの判断材料として RRC Inactive Assistance Information を NG-RAN に渡し、必要なら RRC Inactive Transition Report（TS 38.413 §8.3.5）で UE の RRC 状態の遷移を報告させることができます（TS 23.501 §5.3.3.2.5、要確認）。報告を求めない限り、AMF は UE が RRC_INACTIVE か RRC_CONNECTED かを区別して知りません。
• RAN Paging に UE が応答しない場合の扱いは場合分けされています。配送待ちの NAS PDU がある場合、NG-RAN は AN Release を起動して AMF 上の CM state を CM-IDLE に戻します。保留中なのが User Plane データだけの場合は、N2 を維持するか AN Release を起動するかを NG-RAN のローカル設定で決めます（TS 23.501 §5.3.3.2.5、要確認）。
• 別の gNB で RRC Resume した場合は、N2 の Path Switch Request（TS 38.413 §8.4.4、要確認）で DL の N3 宛先が新しい gNB に切り替わります。

詳細は RRC Resume / Small Data を参照してください。ここで押さえるべきは、「無線が休んでいる」と「CM-IDLE」は同じではない という点です。

Packet Analysis (Wireshark)¶

Display Filter¶

NGAP の procedureCode の数値はディセクタ・版で表示が異なり得るため、本ページでは断定しません。GUI のプロトコル階層表示でメッセージ名を確認するのが確実です。SBI（Nsmf / Namf）は TLS で暗号化されていることが多く、キーログが無ければ中身は見えません。その場合は SMF / AMF のログで upCnxState の遷移を確認します。

Decode例（概念表現）¶

以下は表示構造の概念表現で、値はテスト用 PLMN（001-01）と架空の値です（要キャプチャ）。

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（AN Release 後）
 └─ Update FAR (FAR ID = 2, DL)
     ├─ Apply Action: BUFF, NOCP
     └─ （Forwarding Parameters による gNB への転送は使われなくなる。IE 上の扱いは実装依存、要確認）

NGAP InitialUEMessage（Service Request 時）
 ├─ RAN-UE-NGAP-ID: 1042            ← 前回の 1001 とは別
 ├─ NAS-PDU
 │   └─ Service request
 │       ├─ Service type: data
 │       ├─ 5GS mobile identity: 5G-S-TMSI
 │       └─ NAS message container（復号後: Uplink data status / PDU session status）
 ├─ UserLocationInformation（NR CGI / TAI）
 └─ FiveG-S-TMSI

NGAP InitialContextSetupResponse
 └─ PDUSessionResourceSetupListCxtRes
     └─ PDU Session ID = 1
         └─ PDUSessionResourceSetupResponseTransfer（N2 SM information。AMF は中身を見ずに SMF へ透過転送）
             └─ DL QoS Flow per TNL Information > UP Transport Layer Information
                 └─ 192.0.2.10 / TEID 0x0000bb07   ← 新しい gNB F-TEID

見る順番¶

flowchart LR
    A["① AN Release
UE Context Release
Request / Command / Complete"] --> B["② N4
DL FAR を BUFF/NOCP へ"]
    B --> C["③ DL 到着
Session Report DLDR
→ NGAP Paging"]
    C --> D["④ Service Request
Initial UE Message
5G-S-TMSI で既存 Context 特定"]
    D --> E["⑤ Initial Context Setup
Response の gNB F-TEID"]
    E --> F["⑥ N4
DL FAR が FORW +
新 F-TEID になったか"]
    F --> G["⑦ GTP-U
新 TEID で DL が流れるか"]

UE-triggered の場合は ③ が無く、④ から始まります。

Trouble Shooting¶

「show subscriber に見える = CONNECTED」ではない¶

運用 CLI（例: show subscriber 系）で UE が表示されても、それは AMF または SMF に Context がある ことを示すだけで、CM-CONNECTED であるとは限りません。CM-IDLE の UE にも AMF UE Context と PDU Session は残っているからです。CLI のコマンド名・表示項目は Vendor 実装依存 ですが、確認すべき状態は仕様の概念で整理できます。

「Subscriber が見えるのに着信しない」ときは、少なくとも RM state → CM state → upCnxState → UPF の DL FAR の順に分けて確認します。

3GPP仕様とVendor実装の境界¶

EPC（4G）との比較¶

考え方はほぼ同じで、5GC では PDU Session 単位の選択的な User Plane 活性化 と RRC_INACTIVE が加わった点が大きな違いです。

3GPP Specification¶

Summary¶

• RM state（登録）と CM state（接続）は独立。RM-REGISTERED + CM-IDLE は最も普通の状態で、RM-DEREGISTERED + CM-CONNECTED も Initial Registration 中に必ず現れる
• CM-IDLE で 解放されるのは Access Network 側（RRC、gNB の UE Context、UE-associated logical NG-connection、N3 User Plane connection）
• 残るのはコア側（AMF UE Context、Registration、5G NAS security context、PDU Session、PSA UPF の PFCP Session）。UPF の DL FAR はバッファ／通知に切り替わる
• 復帰は Service Request。Network-triggered は Paging が先行し、その後は UE-triggered と同じ手順で PDU Session ごとに User Plane を活性化する
• Service Request の前後で gNB 側 N3 TEID・NGAP ID・KgNB が変わるのは正常。Paging 応答後は 5G-GUTI（5G-S-TMSI）も再割当てされる。異常なのは UPF が古い TEID を指したままのこと
• RRC_INACTIVE は CM-CONNECTED。N2 / N3 は維持され、DL は RAN Paging で届く
• 運用では RM state → CM state → upCnxState → DL FAR を分けて見る。「Subscriber が見える」は CONNECTED の証拠ではない

理解度チェック¶

Next Step¶

• PDU Session の N3 が 最初にどう作られるか（N1 SM / N2 SM / F-TEID の受け渡し） → PDU Session Establishment 深掘り
• UPF の DL FAR（BUFF / NOCP / FORW）の中身 → PFCP と PDR / FAR / QER / URR
• 手続きの全体像 → Service Request / Paging
• CM-IDLE UE の位置管理 → Tracking Area / TAI / Registration Area / Periodic Registration Update
• RRC_INACTIVE と RRC Resume → RRC Resume / Small Data
• Paging に使う 5G-S-TMSI → SUPI / SUCI / 5G-GUTI
• Interface → N2 / N3 / N4 / NGAP辞典 / NAS辞典