Service Request — サービスリクエスト¶

学習目標¶

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

• Why（なぜ Service Request が必要か）を、省電力で待機(CM-IDLE)に落ちたUEが通信再開時に接続とユーザプレーンを張り直す仕組みとして説明できる。
• UE-triggered（UE起点） と Network-triggered（NW起点） の Service Request の違い（起動のきっかけ・Paging の先行有無）を対比して説明できる。
• CM-IDLE → CM-CONNECTED の状態遷移と、逆方向の AN Release（CM-CONNECTED → CM-IDLE） を図で説明できる。
• PDU Session のユーザプレーン再アクティブ化（AMF→SMF の Nsmf UpdateSMContext → N4 で UPF の N3 トンネル/FAR 再設定 → gNB との N3 パス再確立）の流れを追える。
• Service Request の主役が AMF（NAS/N2制御） と SMF/UPF（U-Plane再確立） であることを、コア観点で説明できる。
• Wireshark の Display Filter を使って、NAS Service Request / NGAP Initial Context Setup / PFCP Session Modification を解析する着眼点を挙げられる。
• 4G(EPC) の Service Request（MME起点 / UE起点、S1AP、ECM-IDLE→CONNECTED）と 5G の Service Request の違いを対比できる。

前提知識¶

先に以下を理解しておくとスムーズです。まだの人は カリキュラム から始めてください。

• UEが登録済みであること — Service Request は登録済み(5GMM-REGISTERED)のUEが対象です。登録の流れは Initial Registration を参照。
• PDU Session が確立済みであること（再アクティブ化する対象のユーザプレーンが過去に張られていること） → PDU Session Establishment
• Paging の理解（NW起点 Service Request は Paging への応答として起動する） → Paging
• N1 / N2 / N3 / N4（UE⇔AMF の NAS、gNB⇔AMF の NGAP、gNB⇔UPF のU-Plane、SMF⇔UPF の PFCP） → N1 / N2 / N3 / N4
• 主役NFの役割 → AMF / SMF / UPF

この章で学べること¶

本章は Service Request 手続き に焦点を絞ります。CM-IDLE（待機）状態のUEが、無線接続とUEコンテキストを再確立し、CM-IDLE → CM-CONNECTED へ遷移する手続きです。次の2つの起点を扱います。

• UE-triggered（UE起点）Service Request — UEが発信・UL(上り)データ送信・NW起点シグナリングへの応答のために、自発的に接続を再開する。
• Network-triggered（NW起点）Service Request — DL(下り)データ到来時に Paging で起こされたUEが、応答として起動する。これは paging.md の続きに相当します。

本章はコア（5GC）の関与に焦点を当てます。 とくに AMF が受ける NAS Service Request（N1/N2） と、その後の PDU Session のユーザプレーン再アクティブ化（AMF→SMF→UPF の N3/N4 連携）を中心に解説します。次のものは本章の範囲外です（触れますが詳細には立ち入りません）。

• RRC Resume / 無線(RRC)側の詳細手続き — 無線接続の再開手順（RRC Setup/Resume、無線リソース割当）は概念にとどめ、コアの関与に焦点を当てます（無線側・実装依存）。
• AKA 再認証の詳細 — Service Request 中に再認証が起きる場合がありますが、認証の詳細は別章（Security/Authentication）へ誘導します。
• Handover の詳細 — 移動中の接続切替は本章の対象外です（Handover を参照）。
• RRC Inactive / Small Data Transmission — Rel-16 以降の拡張は Release差分 で概要のみ触れます。

Why — なぜ Service Request が必要なのか¶

Why（なぜ必要か）から始めます。 登録済み(5GMM-REGISTERED)のUEでも、通信していない間は無線の個別接続を握りっぱなしにはしません。無線接続を常時維持すると、UE側の電池がすぐに尽き、ネットワーク側の無線リソースも枯渇するからです。そこでUEは、通信が無い間は無線の個別接続を解放した待機状態（CM-IDLE）に入り、電池を節約します（この「接続を解放して待機に落とす」逆方向の手続きが AN Release です）。

ところが待機中(CM-IDLE)のUEが、いざ通信を再開しようとすると問題があります。CM-IDLE では次の2つが切れているからです。

1. シグナリング接続 — UE⇔AMF の NAS 接続と、gNB⇔AMF の N2 UE関連接続が無い。制御メッセージをすぐには送れない。
2. ユーザプレーン経路 — PDU Session は論理的には維持されているが、実データが流れる N3(gNB⇔UPF)トンネル が非活性（deactivated）になっている。このままでは上り/下りデータが流れない。

Service Request とは、この待機中のUEが「また通信します。接続とデータの通り道を張り直してください」と申告し、シグナリング接続を再確立し、PDU Session のユーザプレーンを再アクティブ化して、CM-CONNECTED へ戻る手続きです。

Overview — 概要¶

Service Request は、2つの起点から起動します。どちらも結果は同じ——UEが CM-CONNECTED へ遷移し、PDU Session のユーザプレーン（N3）が再アクティブ化されて上り/下りデータが流れ始めます。

• UE-triggered（UE起点） — UEが自発的に起動。発信、UL(上り)データの送信、NW起点シグナリングへの応答などがきっかけ。UEが NAS Service Request を送る。
• Network-triggered（NW起点） — DLデータ到来を UPF/SMF/AMF が検知し、AMF が Paging でUEを呼ぶ。Paging を受けたUEが起動する Service Request。つまり NW起点は Paging が先行する点が UE起点との最大の違いです。

flowchart LR
    UEtrig["UE起点
(発信 / UL data)"] --> SR["Service Request
(NAS)"]
    DL[("DLデータ到来")] --> PG["Paging
(NW起点の先行手続き)"]
    PG --> SR
    SR --> ACT["U-Plane 再アクティブ化
(AMF→SMF→N4→UPF, N3再確立)"]
    ACT --> CONN(("CM-CONNECTED
データ疎通"))

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

Basic Concept — 初心者向け説明¶

Service Request を理解するには、3つのキーワードを押さえます。

1. なぜ CM-IDLE から復帰が要るのか¶

CM = Connection Management（接続管理）。登録済みのUEは、UE⇔AMF の N1(NAS)シグナリング接続 と、gNB⇔AMF 間の N2 UE関連接続 の有無で、主に2つの状態を持ちます（詳細は Paging と厳密に揃えています）。

• CM-IDLE（待機）— UEとネットワークの間に、そのUE用のシグナリング接続が無い状態。UEは無線の個別接続を解放し電池を節約。PDU Session のユーザプレーン(N3)も非活性。
• CM-CONNECTED（接続中）— そのUE用のシグナリング接続が確立している状態。データ/シグナリングをすぐにやり取りできる。

通信が無くなると、ネットワークは AN Release（無線接続の解放）でUEを CM-CONNECTED → CM-IDLE に落とします。省電力のためです。ところが再び通信したくなったら、切れた接続とU-Planeを張り直す必要があります。この復帰手続きが Service Request で、CM-IDLE → CM-CONNECTED へ戻します。なお RM状態（Registration Management: REGISTERED / DEREGISTERED）とは別軸で、Service Request の対象は「RM=REGISTERED かつ CM=IDLE」のUEです。

2. UE起点と NW起点の違い¶

同じ Service Request でも、誰が最初に動くかが違います。

• UE起点 — UE自身が「これから発信する」「上りデータを送りたい」ときに、自発的に NAS Service Request を送ります。Paging は要りません（自分で気づいて動くから）。
• NW起点 — ネットワーク側にUE宛ての用事（DLデータ）が来たとき、UEは待機中でそれに気づけません。そこでネットワークが Paging で「起きてください」と呼び、呼ばれたUEが応答として Service Request を起動します。

3. PDU Session のアクティブ化（なぜU-Plane再確立が要るか）¶

CM-IDLE の間、PDU Session 自体は論理的には維持されています（UEのIPアドレスや PDU Session ID は消えない）。しかし、実データが流れる N3(gNB⇔UPF)のユーザプレーントンネルは非活性にされています。理由は、UEが待機中で無線接続が無いのに N3 トンネルだけ維持しても下りデータの届け先(gNB)が定まらず無駄だからです。

したがって Service Request では、シグナリング接続の再確立に加えて、PDU Session のユーザプレーンを再アクティブ化します。具体的には次を張り直します。

• gNB⇔UPF の N3 トンネル — 上り/下りデータが流れる N3(GTP-U) の経路。gNB側・UPF側の TEID/アドレスを新たに設定・更新する。
• UPF の転送ルール — SMF が N4(PFCP) で UPF の FAR（Forwarding Action Rule） 等を更新し、下りデータを新しい gNB の N3 TEID へ向ける。

このとき、UEがどの PDU Session を再アクティブ化するかは、Service Request に含める情報（後述の List Of PDU Sessions To Be Activated 相当、IE名は要確認）で示され得ます。全PDU Session を一度に起こすとは限らず、必要なものだけを起こす設計です（詳細・条件は要確認）。

Architecture¶

Service Request に関わる要素と、それらを結ぶInterfaceです。UEの NAS Service Request が gNB→AMF に届き、AMF が SMF を介して UPF の N3(U-Plane)を再確立する経路を強調しています。

flowchart LR
    UE(("UE
(CM-IDLE→CONNECTED)"))
    RAN["(R)AN / gNB"]
    AMF["AMF
(NAS/N2 制御)"]
    SMF["SMF
(PDU Session活性化)"]
    UPF["UPF
(N3再設定)"]
    DN[(Data Network)]

    UE -- "N1 (NAS): Service Request" --> AMF
    UE -. "RRC (無線・範囲外)" .- RAN
    RAN -- "N2 (NGAP): Initial UE Message / InitialContextSetup" --> AMF
    AMF -- "N11相当 (Nsmf UpdateSMContext)" --> SMF
    SMF -- "N4 (PFCP): Session Modification" --> UPF
    RAN == "N3 (GTP-U 再確立)" ==> UPF
    UPF == "N6" ==> DN

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

各要素の役割は次の通りです。

• UE — 復帰する端末。UE起点では自発的に、NW起点では Paging 応答として NAS Service Request を送る。無線側の RRC 再開は範囲外。
• (R)AN / gNB — 無線アクセス。UEの NAS を Initial UE Message(NGAP) で AMF へ運び、AMF からの InitialContextSetup でUEコンテキスト/AS security/無線リソースを設定し、N3(GTP-U) をUPFへ再確立する。
• AMF — 制御の司令塔。N1(NAS)/N2(NGAP)を終端し、Service Request を受け付け、再アクティブ化すべき PDU Session について SMF へ指示する。
• SMF — セッション管理。AMFの依頼を受け、N4(PFCP) で UPF のU-Plane(N3/FAR)を再設定し、PDU Session を再アクティブ化する。
• UPF — ユーザプレーンの転送実体。SMFの指示で N3 トンネル(gNB側 TEID/アドレス)と FAR を再設定し、上り/下りデータを流す。
• DN（Data Network） — 外部データ網。再確立後、U-Plane を通じてUEと疎通する。

Interfaceの詳細は Interface辞典 を参照してください。

Network Function（登場NF）¶

Service Request に登場するコア側NFの役割です。gNB は無線アクセス側であり、コアNFではありません（本表はコアNFに限定）。

Interface / Protocol¶

この手順で使うInterfaceとProtocolです。

Protocolの詳細は Protocol辞典、Interface一覧は Interface辞典 を参照してください。

Procedure — Call Flow¶

このページの心臓部です。 Service Request の主要手順を、Mermaid の sequenceDiagram で示します。根拠は 3GPP TS 23.502 §4.2.3系（UE Triggered / Network Triggered Service Request） および TS 24.501 §5.6系（NAS Service Request）、TS 38.413（NGAP） です（章番号の細部は要確認）。UE-triggered（UE起点）を主軸に示し、NW起点は「Paging が先行する差分」として補足します。

UE-triggered Service Request（主軸）¶

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

    Note over UE,RAN: 発信 / UL data 送信の必要が発生
    Note over UE,RAN: RRC接続の確立/再開（無線側・概略/範囲外）
    UE->>RAN: Service Request (NAS) を運ぶ
    Note right of UE: TS 24.501 §5.6.1。Service type（mo-signalling/mo-data 等）
    RAN->>AMF: Initial UE Message (NGAP) に NAS を載せる
    Note right of RAN: N2 / TS 38.413

    opt セキュリティ再確立/再認証（条件付き・状況依存）
        Note over UE,AMF: 既存セキュリティコンテキスト検証。必要時のみ再認証（詳細は別章）
    end

    Note over AMF: 再アクティブ化すべき PDU Session を判断
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext（U-Plane活性化要請）
    Note right of AMF: N11相当(SBI)。要確認: オペレーション名/条件
    SMF->>UPF: PFCP Session Modification Request（N4）
    Note right of SMF: N3/FAR 再設定（gNB側 N3 TEID 反映は後続で確定し得る）
    UPF-->>SMF: PFCP Session Modification Response
    SMF-->>AMF: UpdateSMContext Response（U-Plane情報）

    AMF->>RAN: Initial Context Setup Request (NGAP)
    Note right of AMF: UEコンテキスト/AS security/PDU Session の N3 情報を設定
    RAN->>UE: RRC 設定（AS security/無線リソース・概略/範囲外）
    UE-->>RAN: RRC 設定完了（概略/範囲外）
    RAN-->>AMF: Initial Context Setup Response (NGAP)
    Note right of RAN: gNB側 N3 TEID を通知

    opt gNB側 N3 TEID を UPF へ反映（実装/手順依存）
        AMF->>SMF: Nsmf_PDUSession_UpdateSMContext（gNB N3 情報）
        SMF->>UPF: PFCP Session Modification（下りFARを gNB N3 TEID へ）
        UPF-->>SMF: PFCP Session Modification Response
    end

    Note over UE,UPF: N3(GTP-U) 再確立 → 上り/下りデータ疎通
    Note over UE: CM-CONNECTED へ遷移

Network-triggered との差分（Paging が先行）¶

NW起点では、上図の手前に Paging が入るのが最大の違いです。DLデータ到来を UPF がバッファ・通知し、SMF→AMF を経て AMF が NGAP Paging を送出、Paging を受けたUEが上図の Service Request を起動します。

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

    Note over UPF: 宛先UEへのDLデータ到来（N3未活性）→ バッファ
    UPF->>SMF: PFCP Session Report (Downlink Data Report)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer（DL通知）
    Note right of SMF: 詳細は Paging 章参照（paging.md）
    AMF->>RAN: NGAP Paging（Registration Area のgNB群へ）
    RAN-->>UE: エア Paging（RRC, DRX）
    Note over UE: 以降は上の「UE-triggered」と同じ Service Request を起動
    UE->>RAN: Service Request (NAS)
    Note over UE,UPF: 接続再確立・U-Plane再アクティブ化（上図と共通）
    Note over UPF,UE: 再確立後、バッファ済みDLデータを配送

ステップ解説（番号は UE-triggered 図に対応）¶

1. UE→(R)AN: 発信・UL data 等の必要が生じ、UEは（無線側で）RRC接続を確立/再開し（概略/範囲外）、Service Request(NAS) を運ぶ。NAS には Service type（例: mo-signalling / mo-data 等、値は要確認）や再アクティブ化対象の PDU Session 情報が含まれ得る。参照: TS 24.501 §5.6.1（章番号要確認）。
2. (R)AN→AMF: gNBは Initial UE Message(NGAP) に NAS を載せて AMF へ送る（N2 / TS 38.413）。
3. （条件付き）セキュリティ/再認証: AMFが既存セキュリティコンテキストを検証。必要な場合のみ再認証・Security Mode を行う（状況依存、詳細は Security/Authentication 章の対象）。
4. AMFの判断: AMFがどの PDU Session を再アクティブ化するかを判断し、対象について SMF へ通知する。
5. AMF→SMF: Nsmf_PDUSession_UpdateSMContext で U-Plane 活性化を要請（N11相当のSBI）。具体的オペレーション名・条件は要確認。
6. SMF→UPF: PFCP Session Modification Request(N4) で UPF の N3/FAR を再設定する。この時点で gNB側 N3 TEID が未確定なら、後続（ステップ10-11）で確定・反映され得る（手順・実装依存）。参照: TS 29.244。
7. SMF→AMF: UpdateSMContext Response で U-Plane 情報（UPF側 N3 TEID 等）を返す。
8. AMF→(R)AN: Initial Context Setup Request(NGAP) で UEコンテキスト・AS security・PDU Session の N3 情報を gNB に設定する。
9. (R)AN⇔UE（無線側・概略/範囲外）: gNB が RRC で AS security/無線リソースを設定し、UEが完了を返す。
10. (R)AN→AMF: Initial Context Setup Response(NGAP) で gNB側 N3 TEID 等を通知する。
11. （実装/手順依存）gNB N3 TEID の反映: gNB側 N3 TEID を UPF の下り FAR へ反映するため、AMF→SMF→UPF で再度 N4 更新が行われ得る（手順・実装依存、上記ステップ6 と統合される実装もある＝要確認）。
12. 疎通・状態遷移: N3(GTP-U) が再確立され、上り/下りデータが流れる。UEは CM-CONNECTED へ遷移する。NW起点の場合は、UPFにバッファされていたDLデータが配送される。

参照: TS 23.502 §4.2.3系（UE Triggered / Network Triggered Service Request、章番号要確認）、TS 24.501 §5.6系（NAS Service Request）、TS 38.413（NGAP）、TS 29.244（PFCP）。

Signal Flow¶

主要Message／サービスオペレーションを表で整理します。IEは Message辞典 と整合させています。IE名・オペレーション名の一部は版・実装依存のため要確認としています。

State Machine¶

UE側の CM（Connection Management）状態 遷移です。Service Request は CM-IDLE のUEを CM-CONNECTED へ戻し、逆方向の AN Release が CM-CONNECTED を CM-IDLE へ落とします（根拠: TS 23.501 §5.3系、章番号要確認）。

stateDiagram-v2
    [*] --> CM_IDLE: 登録済み・接続解放後
    CM_IDLE --> CM_CONNECTED: UE起点 Service Request（発信・UL data）
    CM_IDLE --> CM_CONNECTED: NW起点 Service Request（Paging 応答）
    CM_CONNECTED --> CM_IDLE: AN Release（無線接続解放・U-Plane非活性化）
    CM_CONNECTED --> [*]

• CM-IDLE — 待機。UE用のシグナリング接続が無く、PDU Session のU-Plane(N3)も非活性。ここで Service Request を起動（UE起点 or Paging応答）すると CM-CONNECTED へ。
• CM-CONNECTED — 接続中。データ/シグナリング可能。一定時間無通信等で AN Release により CM-IDLE へ戻る（U-Plane が非活性化される）。

Packet Analysis (Wireshark)¶

Service Request を Wireshark で解析するときの要点です。コア側では NAS Service Request / NGAP Initial Context Setup（N2） と PFCP Session Modification（N4） が主な観測対象です。

主要 Display Filter¶

Decode の見どころ（主要IE）¶

• NAS Service Request（UE→AMF） — 次のIEに注目（IE名は代表表記、要確認）。
  • Service type — 何のための Service Request か（mo-signalling / mo-data 等。列挙値は要確認）。
  • 5GS mobile identity — 典型的に 5G-S-TMSI（Paging/接続再開用の短縮ID）。
  • 再アクティブ化対象 PDU Session 情報 — どの PDU Session を起こすかの指示（List Of PDU Sessions To Be Activated 相当、IE名要確認）。
• NGAP Initial Context Setup Request/Response（AMF⇔gNB） — UEコンテキスト設定と PDU Session Resource（N3 TEID 情報）。Response で gNB側 N3 TEID が確定する。
• PFCP Session Modification Request（SMF→UPF） — 下り FAR の宛先が 新gNBの N3 TEID へ更新される（U-Plane 再確立の要）。

メッセージのネスト構造（NGAP に NAS がネスト）¶

Service Request の NAS は、NGAP メッセージ（Initial UE Message）の中に NAS-PDU として入ります（Registration と同じ入れ子構造）。パケット詳細ペインでは次のように階層表示されます（表記は概念、実際の名称はディセクタ依存＝要確認）。

NGAP-PDU
 └─ InitialUEMessage
     └─ NAS-PDU
         └─ 5GS NAS Message
             └─ Service Request（Service type / 5G-S-TMSI 等）

Configuration¶

Service Request を成立させるための設定の構造レベルの要点です。具体値・ベンダー固有（Cisco 等）は実装依存であり、ここでは架空の値を書きません。CM-IDLE への遷移（AN Release）の判定や RRC 再開の多くは無線アクセス側（gNB）であり、コア（5GC）側の設定は限定的です。

CM-IDLE 遷移（AN Release）関連¶

• 非活性化タイマ / インアクティビティ判定 — 無通信がどれだけ続いたら AN Release で CM-IDLE に落とすか。判定の主体・しきい値は無線側/実装依存（gNB のインアクティビティタイマ等）。
• コア(AMF)側は、AN Release を受けて UEコンテキストの CM状態を IDLE に更新し、SMF/UPF に U-Plane 非活性化を反映できる構成であること。

U-Plane 再確立関連（コア AMF/SMF/UPF 側）¶

• AMF — N2(NGAP) が確立され、Service Request（Initial UE Message / Initial Context Setup）を処理できること。対象UEのコンテキスト（CM状態、PDU Session 一覧）を保持していること。
• SMF/UPF — PDU Session が確立済みで、N4(PFCP) アソシエーションが確立され、N3/FAR を再設定できる構成であること。

Trouble Shooting¶

代表的な Service Request 失敗の切り分けです（一般論）。Cause値の詳細は Cause辞典 を参照してください。

EPCとの比較¶

4G(EPC) 経験者が 5G へ橋渡しできるよう対比します。「アイドルから復帰し、ベアラ／セッションのユーザプレーンを張り直す」という基本思想は4Gと5Gで共通です。4Gにも UE起点／NW起点（Paging応答）の Service Request があります。

Release差分¶

Service Request 関連の主なトピックです。不確かなものは要確認とし、断定しません。

• Rel-15 — 5GC の基本 Service Request（UE-triggered / Network-triggered、CM状態、PDU Session のU-Plane再アクティブ化）の基礎が確立。
• RRC Inactive（RRC_INACTIVE） — Rel-15 で導入されたUE状態。UEが RRC_INACTIVE のときは、フルな Service Request ではなく RRC Resume による軽量な接続再開が使われ得る（無線側の仕組み。コアから見た CM 状態の扱い・詳細は要確認）。本章はコア起点の Service Request に焦点を当て、RRC Resume の詳細は範囲外。
• Small Data Transmission（SDT） — Rel-16 以降で議論・導入された、少量データを接続をフル確立せずに送る省シグナリング拡張（無線主体。適用範囲・コア影響は要確認）。本章の Rel-15 基礎の範囲外。
• Rel-17 / Rel-18（5G-Advanced） — 省電力・省シグナリングのさらなる拡張が継続（Service Request 手続き本体への具体差分は要確認）。

3GPP Specification¶

FAQ¶

Summary¶

• Service Request は、CM-IDLE の登録済みUEが無線接続とUEコンテキストを再確立し、CM-IDLE → CM-CONNECTED へ遷移する手続き。
• 起点は2つ。UE起点（UE-triggered）＝発信/UL data のためUEが自発的に起動。NW起点（Network-triggered）＝DLデータ到来で Paging に呼ばれ応答として起動（Paging が先行）。
• コア観点の主役は AMF（NAS/N2制御） と SMF/UPF（U-Plane再確立）。RRC Resume 等の無線詳細は範囲外。
• 大きな流れは NAS Service Request(N1/N2) → AMF が SMF へ Nsmf UpdateSMContext → SMF が N4 で UPF の N3/FAR 再設定 → NGAP Initial Context Setup でUEコンテキスト/N3情報設定 → N3 再確立 → 上り/下り疎通。
• PDU Session のU-Plane再アクティブ化（N3 トンネル/FAR の再設定）が要。逆方向の AN Release が CM-CONNECTED → CM-IDLE に畳む（表裏のペア）。
• 4Gの Service Request（MME / S1AP / ECM-IDLE→CONNECTED / EPSベアラ再アクティブ化）に対応し、5Gは AMF / NGAP / CM-IDLE→CONNECTED / PDU Session のU-Plane再アクティブ化。
• 根拠は TS 23.502 §4.2.3系 / TS 23.501 §5.3系 / TS 24.501 §5.6系 / TS 38.413 / TS 29.244（章番号・IE名の一部は要確認）。

Practice — 理解度チェック・演習¶

理解度チェック¶

演習¶

問: 次の UE-triggered Service Request 主要ステップを正しい順に並べ替えてください。

A. AMF → gNB: Initial Context Setup Request(NGAP)
B. UE → gNB: Service Request(NAS)（RRC接続確立後）
C. SMF → UPF: PFCP Session Modification（N3/FAR 再設定）
D. gNB → AMF: Initial UE Message(NGAP) で NAS を運搬
E. N3(GTP-U) 再確立 → 上り/下りデータ疎通（CM-CONNECTED）
F. AMF → SMF: Nsmf_PDUSession_UpdateSMContext（U-Plane活性化）
G. gNB → AMF: Initial Context Setup Response(NGAP)（gNB N3 TEID）

Next Step¶

理解を深めるための次の一歩です。

• 直接の上流: Paging（NW起点 Service Request が応答する呼び出し手続き）
• 手順の前提: Initial Registration / PDU Session Establishment
• 姉妹手順: Handover（移動中の接続切替）
• Mobility Registration Update 章（Registration Area をまたぐ登録更新＝4GのTAU相当）
• RRC Resume / Small Data Transmission（RRC Inactive からの軽量復帰、無線主体）
• 関連NF: AMF / SMF / UPF
• 関連Interface: N1 / N2 / N3 / N4
• 辞典: Message辞典 / Timer辞典 / Cause辞典 / Protocol辞典 / NF辞典 / Interface辞典