コンテンツにスキップ

Paging — ページング

難易度: 上級 / 想定学習時間: 40分 / 対象: Network Triggered Paging のみ / 主役NF: AMF / 主Interface: N2, N4(SMF→AMF は N11 相当のSBI)

学習目標

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

  • Why(なぜ Paging が必要か)を、待機中(CM-IDLE)のUEに着信を届ける仕組みとして説明できる。
  • CM-IDLE / CM-CONNECTED の違いと、Paging がどちらの状態のUEを対象にするかを説明できる。
  • Registration Area(登録エリア=TAIリスト) の考え方と、なぜエリア単位でUEを呼ぶのかを説明できる。
  • Paging の トリガ(DLデータ到来/NW起点シグナリング)と、UPFバッファ → SMF通知 → AMF判断 → NGAP Paging という流れを追える。
  • DRX / eDRX(間欠受信)が省電力とPagingタイミングにどう関わるかを概念として説明できる。
  • UEが Paging に応じて Service Request を出し、CM-IDLE → CM-CONNECTED へ遷移する流れを説明できる。
  • 4G(EPC) の Paging(MME起点 / S1AP Paging)と 5G の Paging(AMF起点 / NGAP Paging)の違いを対比できる。

前提知識

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

  • UEが登録済みであること — Paging は登録済み(5GMM-REGISTERED)のUEに対する手続きです。登録の流れは Initial Registration を参照。
  • N2 / NGAP(gNB⇔AMF の制御Interface。Paging は NGAP の手続きのひとつ) → N2
  • N4 / PFCP(SMF⇔UPF。UPFのDLバッファと通知を運ぶ) → N4
  • 主役NFの役割AMF / SMF / UPF

この章で学べること

本章は Network Triggered Paging(ネットワーク起動のページング)に限定します。CM-IDLE 状態のUEに対し、着信データやNW起点シグナリングが来たときに、ネットワークがUEを呼び出す手続きです。コア観点、とくに AMF が発する NGAP Paging(N2) と、その引き金となる UPFバッファ/SMF通知(N4) に焦点を当てます。

次は本章の範囲外、または概念どまりとします。

  • 無線(RRC/RAN)内部の詳細 — エア上のPaging送信やDRXの物理層タイミングは概念として触れるにとどめ、コアの関与に焦点を当てます。
  • eDRX の詳細パラメータ — 省電力の考え方は説明しますが、具体的なサイクル値やパラメータ設計は実装依存として扱います。
  • Service Request 手続きの詳細 — Paging への応答としての位置づけを本章で概説しますが、Service Request 自体の詳細手順は別章の対象です(未作成のためプレーンテキストで言及します)。
  • RRC Inactive 時の RAN Paging — 5G特有の概念として Release差分FAQ で概要のみ触れます。

Why — なぜ Paging が必要なのか

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

ところが待機中のUEには問題があります。着信データやNW起点のシグナリングが来ても、ネットワークはそのUEがいま正確にどのセルにいるかを知りません(セル単位では追跡していない)。知っているのは「このあたりのエリア(Registration Area)にいるはず」という大まかな範囲だけです。

Paging とは、この待機中のUEに対し、ネットワークが「あなた宛ての用事があります。起きてください」とエリア全体に呼びかける手続きです。呼ばれたUEは無線接続を張り直し(Service Request)、通信できる状態(CM-CONNECTED)へ戻ります。

例え話: 不在時の呼び鈴とアナウンス

Paging は、留守番中の人を呼び出す仕組みに似ています。宅配便(着信データ)が届いても、配達員はあなたが家のどの部屋にいるか分かりません。分かるのは「この家(Registration Area)にいるはず」ということだけ。そこで呼び鈴を鳴らす(Paging)と、あなたは玄関へ出てきて(Service Request)荷物を受け取れます。四六時中ドアの前で待つ(常時接続)必要はなく、呼ばれてから出れば良いので体力(電池)を温存できます。しかも、どの部屋にいるか分からないので家全体に聞こえるように鳴らす——これがエリア単位で呼ぶ理由です。

Overview — 概要

Paging は、大きく次の流れで起きます。

待機中(CM-IDLE)のUE宛てに DLデータ が到来 → UPF がそのデータをバッファし、SMF へ通知(N4) → SMF が AMF へ「このUEに用事がある」と通知(N11相当のSBI) → AMF が該当UEの Registration Area(TAIリスト) をカバーする gNB群NGAP Paging を送る(N2) → 各gNBがエア上でPaging → UEが受信して Service Request で応答 → UEが CM-CONNECTED へ遷移し、バッファされていたデータが配送されます。

項目 内容
トリガ DLデータ到来(UPFバッファ経由)/ NW起点シグナリング
対象UE CM-IDLE 状態の登録済みUE
呼び出す範囲 UEの Registration Area(TAIリスト)に含まれるTA/セル群
主役NF AMF(Paging判断・NGAP Paging送信)
使うInterface N2(NGAP Paging)/ N4(UPFバッファ・通知)/ N11相当(SMF→AMF通知)
結果 UEが Service Request で応答し CM-CONNECTED へ。データ配送が始まる

Basic Concept — 初心者向け説明

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

1. CM-IDLE と CM-CONNECTED(接続の状態)

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

  • CM-IDLE(待機)— UEとネットワークの間に、そのUE用のシグナリング接続が無い状態。UEは無線の個別接続を解放し、電池を節約している。ネットワークはUEをセル単位では追跡していない。
  • CM-CONNECTED(接続中)— そのUE用のシグナリング接続が確立している状態。データやシグナリングをすぐにやり取りできる。

Paging は、CM-IDLE のUEを呼び出して CM-CONNECTED へ戻すきっかけになります(詳細は State Machine)。なお RM状態(Registration Management: REGISTERED / DEREGISTERED)とは別軸で、Paging の対象は「RM=REGISTERED かつ CM=IDLE」のUEです。

2. Registration Area(なぜエリア単位で呼ぶか)

Registration Area(登録エリア) は、AMFがUEに割り当てる TAI(Tracking Area Identity)のリストです。登録受諾(Registration Accept)時にUEへ通知されます。

  • UEはこのエリアを移動する限り、いちいち登録更新しなくてよい(=シグナリング削減・省電力)。
  • ネットワークはUEをセル単位では追跡しないため、着信時に「正確にどのセルか」は分からない。
  • そこで、Paging は Registration Area 全体(=TAIリストに含まれるTA群のセル)へ呼びかけます。どこかのセルにUEがいれば、呼び出しが届きます。

エリアが広いほど呼ぶ範囲も広い

Registration Area を広く設計すると、UEの登録更新は減りますが、Paging 時に呼びかける範囲(無線リソースの消費)が広がります。逆に狭くすると登録更新が増えます。このトレードオフのバランス設計はオペレータの方針・実装依存です(Configuration 参照)。UEがエリアの外へ出たときは、Mobility Registration Update(4GのTAU相当)で新しいエリアを取得します。

3. DRX(なぜ間欠受信で省電力か)

DRX = Discontinuous Reception(間欠受信)。CM-IDLE のUEが Paging を受けるために、四六時中エアを聞き続けると電池が持ちません。そこでUEは、決まったタイミング(Paging occasion)だけPagingチャネルを聞き、それ以外は受信部を休ませます。これがDRXです。

  • ネットワークとUEは同じDRXサイクルを共有し、UEが起きているその瞬間にPagingを送るよう合わせます。
  • サイクルを長くするほど省電力ですが、着信に気づくまでの遅延が増えます。
  • eDRX(extended DRX) はサイクルをさらに延ばす省電力拡張です(詳細パラメータは実装依存・本章範囲外)。

DRX/Paging occasion の物理層詳細は範囲外

UEが「いつ起きるか」を決める Paging occasion の計算や、無線側のPaging送信は RRC/RAN の領域です。本章はコアの関与(AMFがどのgNBへNGAP Pagingを送るか)に焦点を当て、無線側は概念どまりとします(実装・RAN依存)。


Architecture

Paging に関わる要素と、それらを結ぶInterfaceです。DLデータ到来を起点に、UPF → SMF → AMF → 複数gNB(Registration Area)→ UE へと呼び出しが伝わります。

flowchart LR
    DN[("DN / 外部NW
(DLデータ源)")] -->|"DL data"| UPF UPF["UPF
(DLバッファ)"] ---|"N4 (PFCP) Data Notification"| SMF["SMF"] SMF ---|"N11相当 (SBI) N1N2 Message Transfer"| AMF["AMF
(Paging判断)"] AMF ==>|"N2 (NGAP Paging)"| gNB1["gNB #1"] AMF ==>|"N2 (NGAP Paging)"| gNB2["gNB #2"] AMF ==>|"N2 (NGAP Paging)"| gNB3["gNB #3"] gNB1 -.->|"エア Paging (RRC)"| UE(("UE
(CM-IDLE)")) gNB2 -.->|"エア Paging (RRC)"| UE gNB3 -.->|"エア Paging (RRC)"| UE subgraph RA["Registration Area (TAIリスト)"] gNB1 gNB2 gNB3 end classDef core fill:#efe,stroke:#3a3,stroke-width:2px; class AMF,SMF,UPF core;

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

  • UPF — DLデータの転送点。宛先UEが CM-IDLE でDL経路が確立していないと、データをバッファし、SMFへ通知する(N4)。
  • SMF — UPFからの通知を受け、AMFへ「このUEにDLデータが来ている」と中継する(N11相当のSBI)。
  • AMF — Paging の司令塔。UEが CM-IDLE と判断すると、そのUEの Registration Area をカバーするgNB群へ NGAP Paging を送る(N2)。
  • (R)AN / gNB — NGAP Paging を受け、エア上でPaging(RRC)を送出する。無線側の実際の呼び出し役。
  • UE — CM-IDLE で間欠受信(DRX)中。Paging を受け取ると Service Request で応答する。

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

Network Function(登場NF)

NF この手順での役割 保持/取得する情報 この手順で使う主なAPI/手続き 障害時の影響
AMF Paging の判断主体。UEが CM-IDLE のとき Registration Area のgNB群へ NGAP Paging を送出 UEコンテキスト、CM状態、Registration Area(TAIリスト)、5G-S-TMSI、DRXパラメータ NGAP Paging(N2, TS 38.413)/ Namf_Communication(SMFから受ける) Paging が発行されず、着信データが届かない
SMF UPFのDL通知を受け、AMFへDLデータ到来を通知(Paging起動を促す) PDU Session コンテキスト、通知先AMF Namf_Communication_N1N2MessageTransfer(SMF→AMF、要確認: オペレーション名) AMFへ通知が届かず Paging が起動しない
UPF DLデータをバッファし、SMFへ Downlink Data Report で通知 バッファされたDLパケット、PDR/FAR等のルール PFCP Session Report Request(Downlink Data Report, N4/TS 29.244) バッファ・通知不可でDLデータが失われる/通知されない

Interface / Protocol

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

Interface Protocol 相手 この手順での用途
N2 NGAP(SCTP:38412) gNB ⇔ AMF AMF→gNB の NGAP Paging 送信(UE関連ではなく、TAIリスト宛の非UE個別接続手続き)
N4 PFCP(UDP:8805) SMF ⇔ UPF UPFのDLバッファと Session Report(Downlink Data Report) による通知
N11相当 SBI(HTTP/2, TLS, JSON) SMF → AMF SMF→AMF のDLデータ到来通知(Namf_Communication)

N11 と SBI の表記について

3GPPアーキテクチャでは、AMF⇔SMF 間の参照点は N11 と呼ばれますが、実体は SBI(Service Based Interface, HTTP/2) 上の Namf_Communication サービスを介したやり取りです。ここでは「N11相当(SBI)」と表記します。SMF→AMF の具体的オペレーション名(Namf_Communication_N1N2MessageTransfer を想定)は代表例であり、正確な適用条件は TS 23.502 の該当手順で要確認です。

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


Procedure — Call Flow

このページの心臓部です。 DLデータ到来を起点とする Network Triggered Paging の主要手順を、Mermaid の sequenceDiagram で示します。根拠は 3GPP TS 23.502 §4.2.3.3(Network Triggered Service Request) および TS 38.413(NGAP Paging) です(章番号の細部は要確認)。

前提: UEは登録済みで CM-IDLE であること

UEは 5GMM-REGISTERED かつ CM-IDLE であるとします。CM-CONNECTED であれば既に接続があるためPagingは不要で、直接DLデータを配送できます。

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データが到来(DL経路未確立)
    UPF->>SMF: PFCP Session Report Request (Downlink Data Report)
    Note right of UPF: N4 / TS 29.244。UPFはDLデータをバッファ
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer(DL通知)
    Note right of SMF: N11相当(SBI)。要確認: オペレーション名/条件

    Note over AMF: UEが CM-IDLE と判断 → Paging を決定
    AMF->>RAN: NGAP Paging(N2, Registration Area のgNB群へ)
    Note right of AMF: TS 38.413。UE Paging Identity=5G-S-TMSI, TAI List 等
    RAN-->>UE: エア上 Paging(RRC, DRX の Paging occasion)

    Note over UE: Paging を受信 → 応答を開始
    UE->>RAN: Service Request 手続きを起動(NAS)
    RAN->>AMF: Initial UE Message 等でNASを運搬(N2)
    Note over UE,AMF: Service Request 詳細は別章の対象(本章は概要)

    Note over UE,AMF: UEコンテキスト/AS security 確立、DL経路の再確立
    AMF->>SMF: DL経路確立を要請(PDU Session の再アクティブ化)
    SMF->>UPF: N4でDL経路(FAR等)を更新
    UPF-->>UE: バッファ済みDLデータを配送
    Note over UE: CM-CONNECTED へ遷移し受信

ステップ解説(番号は上図に対応)

  1. UPF→SMF: 宛先UE向けの DLデータが到来したが、UEが CM-IDLE でDL経路(N3トンネル)が確立していないため、UPFはデータをバッファし、PFCP Session Report Request(Downlink Data Report / DLDR) でSMFへ通知する(N4 / TS 29.244)。IE名 "Downlink Data Report" は代表表記、詳細は要確認
  2. SMF→AMF: SMFがAMFへ「このUEにDLデータが来ている」と通知する。オペレーションは Namf_Communication_N1N2MessageTransfer を想定(N11相当のSBI)。具体的オペレーション名・適用条件は要確認
  3. AMFの判断: AMFがUEコンテキストを確認し、CM-IDLE と判断すると Paging を決定する。CM-CONNECTED ならPaging不要。
  4. AMF→(R)AN: AMFがUEの Registration Area(TAIリスト) をカバーするgNB群NGAP Paging を送る(N2 / TS 38.413)。主要IEに UE Paging Identity(5G-S-TMSI)TAI List for PagingPaging DRX 等(IE名は要確認Packet Analysis 参照)。
  5. (R)AN→UE: 各gNBがエア上で Paging(RRC) を送出。UEはDRXの Paging occasion で受信する(無線側詳細は範囲外)。
  6. UE→応答: Paging を受けたUEが Service Request 手続き を起動し、NASを Initial UE Message 等でAMFへ運ぶ(N2)。Service Request 手続きの詳細は別章の対象(本章では概要)。
  7. 接続確立・DL経路再確立: UEコンテキストと AS security を確立し、AMF→SMF→UPF(N4)でDL経路を再アクティブ化する。UPFがバッファ済みDLデータを配送し、UEは CM-CONNECTED で受信する。

手順の一部は状況・実装依存

上記は Network Triggered(DLデータ起点)の典型です。NW起点シグナリング(例: AMF/NW都合の呼び出し)の場合はステップ1-2が異なります。また Paging の再送回数・タイマ・Registration Area 全体を一度に呼ぶか段階的に呼ぶか(例: 最終在圏TAだけ先に呼ぶ等)は、オペレータ方針・実装により変化します(実装依存、一部要確認)。

参照: TS 23.502 §4.2.3.3(Network Triggered Service Request、章番号要確認)、TS 38.413(NGAP Paging)、TS 29.244(PFCP Session Report)。

Signal Flow

主要Messageを表で整理します。

Message Protocol 送信元→送信先 目的 主要IE(要確認あり) 結果
PFCP Session Report Request PFCP UPF→SMF DLデータ到来通知(バッファ発生) Report Type=Downlink Data Report(DLDR)等 SMFがDL通知を認識
Namf_Communication_N1N2MessageTransfer SBI(HTTP/2) SMF→AMF DLデータ到来をAMFへ通知 対象UE/PDU Session識別情報(要確認) AMFがPaging判断を開始
NGAP Paging NGAP AMF→gNB群 UE呼び出し UE Paging Identity(5G-S-TMSI), TAI List for Paging, Paging DRX(IE名要確認) gNBがエアPagingを送出
(エア)Paging RRC gNB→UE UEを起こす Paging Record(5G-S-TMSI等、RAN側・概念) UEがService Requestを起動
Service Request NAS(5GMM) UE→AMF Pagingへの応答・接続再開 Service type 等(詳細は別章) UEがCM-CONNECTEDへ

各Messageの詳細IE・参照Specは Message辞典 を参照してください。IE名の一部は実装・版依存のため要確認としています。

State Machine

UE側の CM(Connection Management)状態 遷移です。Paging は CM-IDLE のUEを CM-CONNECTED へ戻すきっかけになります(根拠: TS 23.501 §5.3系、章番号要確認)。

stateDiagram-v2
    [*] --> CM_IDLE: 登録済み・接続解放後
    CM_IDLE --> CM_CONNECTED: Paging 受信 → Service Request 応答
    CM_IDLE --> CM_CONNECTED: UE起点 Service Request(発信・UL data)
    CM_CONNECTED --> CM_IDLE: AN Release(無線接続解放・非活性化)
    CM_CONNECTED --> [*]
  • CM-IDLE — 待機。UE用のシグナリング接続が無い。Paging の対象。ここで Paging を受け Service Request で応答すると CM-CONNECTED へ。
  • CM-CONNECTED — 接続中。データ/シグナリング可能。一定時間無通信等で AN Release により CM-IDLE へ戻る。

RM状態とは別軸

上図は CM状態(接続の有無)です。RM状態(REGISTERED / DEREGISTERED)とは独立で、Paging の対象は「RM=REGISTERED かつ CM=IDLE」のUEです。CM-IDLE ⇔ CM-CONNECTED を行き来しても、RM=REGISTERED は維持されます(De-registration や登録失効が起きない限り)。状態定義の詳細は TS 23.501 §5.3系を要確認

Packet Analysis (Wireshark)

Paging を Wireshark で解析するときの要点です。コア側では NGAP Paging(N2)PFCP Session Report(N4) が観測対象です。

主要 Display Filter

Filter 意味
ngap NGAP メッセージ全般(Paging を含む)
pfcp PFCP メッセージ全般(Session Report を含む)
sctp.port == 38412 N2(NGAP) の SCTP ポート
udp.port == 8805 N4(PFCP) の UDP ポート
ngap.procedureCode == 24 Paging(要確認: procedureCode値はディセクタ/版依存)

フィルタ値・IE名は環境依存・要確認

ngap.procedureCode の数値や各IEの名前は、3GPP仕様の割当に基づきますが、Wireshark のバージョンやディセクタ実装によって表示・照合方法が異なる場合があります。上記の procedureCode == 24 を含む数値は要確認とし、実機では GUI のプロトコル階層表示で確認するのが確実です。

Decode の見どころ(主要IE)

  • NGAP Paging(AMF→gNB) — 次のIEに注目(IE名は代表表記、要確認)。
    • UE Paging Identity — 呼び出す相手の識別子。典型的に 5G-S-TMSI(TMSIから導いた Paging 用の短縮ID)。
    • TAI List for Paging — どのTA群へ呼びかけるか(=Registration Area の範囲)。
    • Paging DRX — UEのDRXサイクル情報(gNBがPaging occasionを合わせるため)。
  • PFCP Session Report Request(UPF→SMF)Report TypeDownlink Data Report(DLDR) が立ち、DLデータ到来とバッファ発生を示す(IE名要確認)。

メッセージのネスト構造(NGAP Paging)

NGAP Paging は、NGAP-PDU の中にPaging用のIE群が入る構造です。パケット詳細ペインでは次のように階層表示されます(表記は概念、実際の名称はディセクタ依存=要確認)。

NGAP-PDU
 └─ Paging (initiatingMessage)
     ├─ UE Paging Identity (5G-S-TMSI)
     ├─ TAI List for Paging
     └─ Paging DRX

実際のpcapは環境依存(実装依存)

本ページのフィルタ・IE名は解析の指針です。実際のパケットは無線・コアの実装や設定に依存します。Open5GSfree5GC のテストベッドを構築すれば、N2区間の NGAP Paging や N4区間の PFCP Session Report を実際にキャプチャして学習できます。

Configuration

Paging を成立させるための設定の構造レベルの要点です。具体値・ベンダー固有(Cisco 等)は実装依存であり、ここでは架空の値を書きません。

Registration Area / TAI リスト設計(AMF 側)

  • TAI / TAC(Tracking Area)— AMFがサービスするTAを定義。gNB の TA と一致している必要がある。
  • Registration Area(TAIリスト)の割当方針 — UEへ割り当てるTAIリストの範囲。広くすると登録更新は減るがPaging範囲が広がり、狭くするとその逆(Basic Concept のトレードオフ)。具体的な割当アルゴリズムは実装依存
  • GUAMI / 5G-S-TMSI 割当 — AMFのGUAMIから 5G-S-TMSI(Paging Identity)が導かれる。

DRX / 省電力関連

  • デフォルトDRXサイクル — UEとネットワークで共有するDRXサイクル。値・設定キーは実装依存
  • eDRX(拡張DRX)— さらなる省電力拡張。パラメータ設計は実装依存・本章範囲外。

具体値・ベンダー固有は実装依存

設定ファイルのキー名・階層・必須項目・DRXの具体値は、Open5GS / free5GC / 商用ベンダー(Cisco 等)で異なります。上記は構造レベルの要点であり、実際のキー名や値は各実装のドキュメントで確認してください(実装依存)。架空の設定値は本ページには記載しません。

Trouble Shooting

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

症状 想定原因 確認ポイント 関連ログ/Packet 対処の方向性
(a) Paging が発行されない SMF→AMF 通知が届かない/UPFがバッファ通知しない N4 の Session Report、SMF→AMF の Namf_Communication PFCP Session Report、AMF/SMFログ N4疎通・UPFバッファ設定、SMF→AMF通知経路を確認
(b) Paging は出るがUEが応答しない UEが在圏外/DRXタイミング不一致/エリア設計ミス UEの実在圏TAとRegistration Areaの整合、DRX設定 NGAP Paging、gNBのエアPagingログ TAIリスト設計、DRX整合、UEの在圏(Mobility Reg Update)を確認
(c) Registration Area 設計ミスで呼び漏れ UEが割当TAIリスト外にいるのに更新されていない 直近のMobility Registration Update、TAC整合 Registration/NGAP Paging、AMFログ TAI設計見直し、登録更新の発生条件を確認
(d) 応答後にDL経路が張れずデータ配送されない Service Request 後のPDU Session再アクティブ化失敗 AMF→SMF→UPF のN4更新(FAR等) N4 Session Modification、UPFログ N3トンネル/FAR再設定、SMF-UPF疎通を確認

EPCとの比較

4G(EPC) の経験者が 5G へ橋渡しできるよう対比します。Paging の基本思想(エリア単位で待機端末を呼ぶ)は4Gと5Gで共通です。

観点 4G / EPC 5G / 5GC
Paging起点NF MME AMF
Paging用プロトコル S1AP Paging(TS 36.413) NGAP Paging(TS 38.413)
呼び出し範囲 TAI List(Tracking Area) TAI List for Paging(Registration Area)
UE識別子(Paging) S-TMSI 5G-S-TMSI
DLバッファ S-GW がバッファ、MMEへ Downlink Data Notification UPF がバッファ、SMF経由でAMFへ通知(N4→N11相当)
待機状態 ECM-IDLE CM-IDLE
省電力受信 DRX / eDRX DRX / eDRX(共通概念)
エリア更新 TAU(Tracking Area Update) Mobility Registration Update

バッファ位置の違いに注目

4Gでは S-GW がDLデータをバッファし MME へ Downlink Data Notification を送りました。5Gでは UPF がバッファし、SMF を経由して AMF へ通知します(CUPS/SBAによる制御・転送分離の反映)。呼び出す主体が MME → AMF、プロトコルが S1AP → NGAP に置き換わる対応関係を押さえると理解しやすくなります。

Release差分

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

  • Rel-15 — 5GC の基本 Paging 手順が確立。CM状態 / Registration Area / NGAP Paging / DRX の基礎が規定。
  • RRC Inactive(RAN Paging) — Rel-15 で導入されたUE状態。UEが RRC_INACTIVE のときは、コア(AMF)ではなく gNB(RAN) が RAN Notification Area 内で RAN Paging を行う(コア起点のCN Pagingとは別レイヤ)。本章のスコープはコア起点の Paging であり、RAN Paging は概念紹介にとどめる(詳細は要確認)。
  • eDRX 拡張 — 省電力(MICO/eDRX)関連の拡張が各Releaseで継続。具体パラメータは実装依存要確認
  • Rel-16 / Rel-17 / Rel-18 — スライス・省電力・測位等の拡張が進んだ世代。Paging手続き自体への具体的な織り込み範囲は要確認

Release差分は要確認

各Releaseで「Paging手続き自体」にどの機能がどこまで織り込まれたかは、対象TSの版差分を個別に確認する必要があります。上記は概観であり、具体項目は要確認です。

3GPP Specification

Spec 内容
TS 23.502 §4.2.3.3 Network Triggered Service Request(Paging起動の手順、章番号要確認)
TS 23.501 §5.3系 CM状態(CM-IDLE/CONNECTED)・Registration Area(要確認: 章番号)
TS 38.413 (NGAP各章) NGAP Paging(UE Paging Identity / TAI List / Paging DRX 等、個別章要確認)
TS 24.501 §5.1系 / §5.6系 5GMM状態・Service Request(NAS側、章番号要確認)
TS 29.244 (PFCP各章) PFCP Session Report(Downlink Data Report)
TS 29.518 Namf(AMFのサービスAPI、Namf_Communication)

章番号の扱い

TS 23.502 §4.2.3.3 / TS 23.501 §5.3系 / TS 24.501 §5.1系・§5.6系 は本章の骨格として参照しています。ただし細かな章番号は版により異なる場合があり、一部は要確認としています。TS 38.413 の NGAP Paging 個別章番号、および各IE名(UE Paging Identity / TAI List for Paging / Paging DRX)も要確認です。

FAQ

Q1. なぜセル単位ではなくエリア(Registration Area)全体を呼ぶのか?

ネットワークは待機中(CM-IDLE)のUEをセル単位では追跡していないからです。追跡を細かくすると登録更新シグナリングが増えて省電力が損なわれます。そこで「このエリア(Registration Area)のどこかにいる」という粒度で管理し、着信時はエリア全体へ呼びかけます。どこかのセルでUEが受信すれば呼び出しは成立します。

Q2. DRX(間欠受信)だと着信が遅れるのでは?

はい、DRXサイクルが長いほど、UEが次に起きて Paging を受け取るまでの待ち時間が増え、着信検知が遅れ得ます。これは省電力と応答遅延のトレードオフです。用途(常時オンライン重視か省電力重視か)に応じてサイクルを設計します。eDRX はさらに省電力寄りに振った拡張です(実装依存)。

Q3. RRC Inactive の RAN Paging とは何が違うのか?

本章で扱うのは AMF(コア)起点 の Paging(CN Paging)で、UEが CM-IDLE のときに起きます。一方 RRC_INACTIVE 状態では、コアから見るとUEは接続中扱いのまま、無線側で軽い待機に入り、gNB(RAN) が RAN Notification Area 内で RAN Paging を行います。呼び出す主体(AMF か gNB)と範囲(Registration Area か RAN Notification Area)が異なります。詳細は要確認

Q4. UEが Paging を受けた後は何をするのか?

UEは Service Request 手続き を起動して無線接続とUEコンテキストを再確立し、CM-CONNECTED へ遷移します。その後、UPFにバッファされていたDLデータが配送されます。Service Request 手続きの詳細は別章の対象です(本章では応答としての位置づけのみ)。

Q5. DLデータのバッファはどこで行われるのか?

UPF です。宛先UEが CM-IDLE でDL経路(N3)が確立していないと、UPFがDLパケットを一時的にバッファし、SMFへ(N4 PFCP Session Report で)通知します。SMFがAMFへ通知し、AMFがPagingを起動します。UEが接続を回復するとバッファ済みデータが配送されます。

Summary

  • Paging は、CM-IDLE の登録済みUEに着信(DLデータ/NW起点シグナリング)を届けるため、ネットワークがUEを呼び出す手続き。
  • 大きな流れは UPFバッファ → SMF通知(N4→N11相当) → AMF判断 → NGAP Paging(N2) → エアPaging(RRC) → UEがService Requestで応答 → CM-CONNECTED
  • 司令塔は AMF(NGAP Paging を Registration Area のgNB群へ送出)。DLバッファは UPF、通知中継は SMF
  • Registration Area(TAIリスト) 単位で呼ぶのは、待機中UEをセル単位で追跡しないため。DRX で間欠受信し省電力を実現する(省電力と応答遅延のトレードオフ)。
  • 4Gの Paging(MME 起点 / S1AP / S-TMSI)に対し、5Gは AMF 起点 / NGAP / 5G-S-TMSI。バッファは S-GW → UPF に。
  • 根拠は TS 23.502 §4.2.3.3 / TS 23.501 §5.3系 / TS 38.413 / TS 29.244(章番号・IE名の一部は要確認)。

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

理解度チェック

Q1. Paging の対象となるUEのCM状態はどちらか?(解答)

CM-IDLE。CM-CONNECTED なら既に接続があるためPagingは不要で、直接DLデータを配送できる。

Q2. AMFがUEを呼び出す範囲は何を基準に決まるか?(解答)

UEの Registration Area(TAIリスト)。この範囲に含まれるTA群のgNBへ NGAP Paging を送る。

Q3. DLデータをバッファし、DLデータ到来をSMFへ通知するNFはどれか?(解答)

UPF。PFCP Session Report Request(Downlink Data Report)でSMFへ通知する(N4)。

Q4. Paging を受けたUEが接続を回復するために起動する手続きは?(解答)

Service Request 手続き。これにより CM-IDLE → CM-CONNECTED へ遷移する。

Q5. 4Gで Paging を起動するNFと、5Gで起動するNFは?(解答)

4Gは MME(S1AP Paging)、5Gは AMF(NGAP Paging)。

演習

: 次の Paging(Network Triggered)主要ステップを正しい順に並べ替えてください。

A. AMF が NGAP Paging を Registration Area のgNB群へ送る
B. UPF が DLデータをバッファし SMF へ Session Report で通知
C. UE が Service Request で応答し CM-CONNECTED へ
D. gNB がエア上で Paging(RRC)を送出
E. SMF が AMF へ DLデータ到来を通知(N11相当)
F. UPF がバッファ済みDLデータを配送
解答

B → E → A → D → C → F

  • B: UPFがバッファ・通知(N4 Session Report)
  • E: SMF→AMF 通知(Namf_Communication)
  • A: AMFが NGAP Paging(N2, Registration Area)
  • D: gNBがエアPaging(RRC)
  • C: UEが Service Request で応答 → CM-CONNECTED
  • F: バッファ済みDLデータの配送

※ NW起点シグナリングが引き金の場合、B・E は別の起点に置き換わる(状況・実装依存)。

Next Step

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