コンテンツにスキップ

Periodic Registration Update — 周期登録更新

難易度: 上級 / 想定学習時間: 35分 / 対象: Periodic Registration Update のみ / 主役NF: AMF / 主Interface: N1, N2

学習目標

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

  • Why(なぜ Periodic Registration Update が必要か)を、ネットワークはUEの圏外・電源断を明示的には知れないため定期的な生存確認が要る、という観点で説明できる。
  • Periodic Registration Update のトリガ(UE側の周期登録更新タイマ満了)を説明できる。
  • 生存確認(reachability 維持)の意義と、更新が来ないUEが implicit deregistration(暗黙デタッチ) 扱いされ得ることを説明できる。
  • Registration type のうち、本章が periodic registration updating に対応することを整理して説明できる。
  • 周期登録更新タイマ(一般に T3512 と呼ばれるとされる。名称・値は要確認)の役割と、AMFが Accept 時に次のタイマ値を割り当て得ることを説明できる。
  • Mobility Registration Update との契機の違い(場所が変わった/時間が経った)を対比できる。
  • 4G(EPC) の Periodic TAU(Periodic Tracking Area Update) と 5G の Periodic Registration Update の対応関係を対比できる。

前提知識

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

  • Initial Registration(初回登録)の理解 — 本章は登録手続きの別バリアントです。登録の全体像・認証・セキュリティは Initial Registration を参照。
  • Mobility Registration Update の理解 — 手続きの骨格を共有する最も近い姉妹手順です。契機(場所か時間か)の違いを対比するため先に読むとスムーズ。 → Mobility Registration Update
  • Registration Area(登録エリア=TAIリスト)と CM状態の理解 — なぜエリア単位で管理するか、待機(CM-IDLE)のUEをどう追跡するか。 → Paging(Registration Area の上流概念)
  • N1 / N2(UE⇔AMF の NAS、gNB⇔AMF の NGAP) → N1 / N2
  • 主役NFの役割AMF

この章で学べること

本章は Periodic Registration Update(周期登録更新)に限定します。UEが移動していなくても、UE側の周期登録更新タイマが満了したときに、「まだ在圏・生存しています」ことをネットワークへ知らせる定期的な登録更新手続きです。4GのPeriodic TAU(Periodic Tracking Area Update)に相当します。コア観点、とくに AMF が受ける Registration Request(Registration type = periodic registration updating) と、その本質である UEの生存確認(reachability の維持)、そして更新が来ないUEの implicit deregistration(暗黙デタッチ) に焦点を当てます。

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

  • Mobility Registration Update の詳細 — 「場所が変わった」ことを契機とする別バリアントです。本章では 契機の違い で対比として触れるにとどめ、詳細手順は Mobility Registration Update へ誘導します(重複は誘導)。
  • Initial Registration の認証/セキュリティ詳細 — 本章では「既存コンテキスト再利用でさらに軽量になり得る」点を主題化し、5G-AKA 等の詳細は Initial Registration / Security 章へ誘導します。
  • 周期タイマの具体値 — 周期登録更新タイマ(T3512 相当とされる)や implicit deregistration 関連タイマの具体値・名称は版・実装依存であり、断定せず要確認とします(後述)。
  • implicit deregistration の詳細手順 — 更新が来ないUEをネットワークがどの時点で・どう暗黙デタッチするかの厳密な手順は概念のみ扱います(細部は要確認)。
  • 無線(RRC/RAN)側の詳細 — RRC接続確立・無線リソース割当は概念にとどめ、コアの関与に焦点を当てます(無線側・実装依存)。
  • SMF/UPF 側のセッション扱い — 周期更新に伴うユーザプレーンの扱いには深入りせず、生存確認のコア手続きに焦点を当てます。

Why — なぜ Periodic Registration Update が必要なのか

Why(なぜ必要か)から始めます。 登録済み(5GMM-REGISTERED)のUEが、Registration Area(=割り当てられた TAIリスト)の内側にいる限り、待機中(CM-IDLE)のUEはセル単位では追跡されず、無線の個別接続も解放して省電力に待機します(Paging / Service Request の設計と表裏です)。

ここで根本的な問題があります。ネットワークは、待機中のUEが「まだそこにいるのか」を明示的には知りません。 UEは次のような形で、何も言わずにネットワークから消えることがあります。

  • 圏外へ出た — 電波の届かない場所(地下・山間部・機内)へ移動した。
  • 電源が切れた — 電池切れ・電源OFF。De-registration(明示的な登録解除)を送れないまま消えることがある。

待機中のUEはネットワークへ何も送らないため、これらは放置すると検知できません。ネットワークはいつまでも「このUEは在圏している」と信じてコンテキストを保持し、着信時には届かない相手へ Paging を投げ続け、リソース(UEコンテキスト・ページング対象)を無駄に抱えます。

Periodic Registration Update とは、UEが移動していなくても、周期的に「まだ生きています。在圏しています」とネットワークへ定期報告する手続きです。ネットワークはこの定期報告が来続ける限りUEを在圏とみなし、来なくなったら「離脱したらしい」と判断して implicit deregistration(暗黙デタッチ) に進み、コンテキストを解放してリソースを適正化します。

例え話: 定期的な安否確認/勤怠の定時打刻

Periodic Registration Update は、定期的な安否確認の連絡勤怠の定時打刻に似ています。元気に過ごしている間は、毎日「無事です」と一言だけ連絡します(周期報告)。連絡が途絶えたとき、初めて相手は「何かあったらしい」と気づけます。連絡が来続ける限りは「在席」扱い、途絶えたら「退席(暗黙デタッチ)」とみなしてその人の席(コンテキスト)を片付ける、という運用です。ポイントは、「異常が起きた」ことをUE自身が知らせるのではなく、「正常の連絡が途絶えた」ことでネットワークが異常を推定する点です。

Overview — 概要

Periodic Registration Update は、大きく次の流れで起きます。

UE側の周期登録更新タイマが満了 → UEが Registration Request(Registration type = periodic registration updating) を gNB 経由で AMF へ送る(N1/N2) → AMFが既存のUEコンテキストを確認し、生存記録(UEが在圏であること)を更新(通常は認証・UDM照会なし=軽量)→ AMFが Registration Accept で応答し、(必要なら)次の周期タイマ値を通知 → UEが(必要なら)Registration Complete を返し、UEは周期タイマを再スタートして完了です。

Registration type は、同じ Registration 手続きの「用途」を示す種別です。本章はこのうち periodic に対応します。

Registration type いつ使うか 本章との関係
initial registration UEが電源ON後などにはじめて登録する 別章 Initial Registration の対象
mobility registration updating UEが Registration Area(TAIリスト)の外へ移動した 別章 Mobility Registration Update の対象
periodic registration updating 周期タイマ満了時に生存確認として定期更新 本章の対象
emergency registration 緊急呼のための登録 範囲外

Registration type の列挙値・名称は要確認

上表の Registration type は 3GPP TS 24.501 の 5GS registration type に基づく代表的な種別ですが、正確な列挙名・値("periodic registration updating" 等の表記や符号値)はディセクタ・版により表示が異なる場合があり、要確認とします。架空の符号値は本ページに記載しません(Packet Analysis 参照)。

契機の違い(mobility との対比)を整理します。手続きの骨格は共通ですが、なぜ起動するかが異なります。

観点 Mobility Registration Update Periodic Registration Update(本章)
起動の契機 場所が変わった(在圏TAが割当TAIリスト外へ) 時間が経った(周期タイマ満了)
主な目的 Registration Area(TAIリスト)の再割当・位置更新 UEの生存確認(reachability 維持)
TAIリスト再割当 基本的に発生(新エリアへ) 通常は必須でない(同一エリア内。起こり得る=条件付き)
典型的な軽さ 既存コンテキスト再利用で簡略化され得る 通常はさらに軽量(認証/UDM照会なしが基本=状況依存)
項目 内容
トリガ UE側の周期登録更新タイマ満了(T3512 相当とされる。名称・値は要確認
対象UE 5GMM-REGISTERED の登録済みUE(移動していなくてよい)
Registration type periodic registration updating
主役NF AMF(生存記録更新・タイマ管理・暗黙デタッチ判断・受諾)
使うInterface N1(NAS)/ N2(NGAP)(UDM/AUSF は通常関与薄い=条件付き)
結果 生存確認完了、(必要なら)次の周期タイマ値割当。UEは周期タイマを再スタート

Basic Concept — 初心者向け説明

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

1. なぜ生存確認が要るか(NWがUE離脱を検知できない問題)

待機中(CM-IDLE)のUEは、ネットワークへ何も送らずに省電力で待機します。これは効率的ですが、裏返すとネットワークはUEが離脱(圏外・電源断)したことを能動的には知れないという弱点になります。

  • UEが正常に登録解除する場合は De-registration(明示的な登録解除)を送れます。
  • しかし圏外・電池切れでは、UEは何も送れずに消えます。

この「沈黙が正常なのか異常なのか区別できない」問題を解くのが、定期的な生存報告です。UEが周期的に「在圏しています」と送り続ければ、ネットワークは「報告が来る=在圏」「報告が途絶える=離脱の疑い」と判断できます。

2. 周期タイマの仕組み(満了で起動、Acceptで次値割当)

Periodic Registration Update は、UE側の周期登録更新タイマが満了したときに起動します。

  • UEは前回の登録/更新が成功すると、周期登録更新タイマをスタートします。
  • タイマが満了すると、UEは Registration Request(type=periodic)を送ります。
  • AMFは Registration Accept で応答し、必要なら次の周期タイマ値をUEへ通知し得ます(値はネットワーク側の運用で決められる)。
  • UEはタイマを再スタートし、また次の満了を待ちます。

つまり周期タイマの値が、生存報告の間隔を決めます。短くすれば離脱をより早く検知できますが更新シグナリングが増え、長くすれば省シグナリングだが離脱検知が遅れる、というトレードオフです。

周期タイマの名称・値は要確認

周期登録更新タイマは、一般に T3512 と呼ばれる周期登録更新タイマが該当するとされますが、正確な名称・デフォルト値・AMFからの通知方法は版・実装依存の面があり、本ページでは要確認として断定しません。現在の Timer辞典 には T3510/T3511/T3550/T3560 は載っていますが、T3512 の行は未収録です。辞典に無いものを断定リンクしないため、ここでは概念名として扱います(具体値は TS 24.501 §10.2 の各タイマー表を要確認)。

3. implicit deregistration(更新が来ないUEの扱い)

UEからの周期報告が期待した時刻に来ない場合、ネットワークは「このUEは離脱したらしい」と推定します。ネットワークは自分側でも関連するタイマ(周期タイマ+余裕分に相当する監視タイマ)を持ち、それが満了してもUEから連絡が無ければ、明示的なやり取りなしにUEを登録解除扱いにします。これが implicit deregistration(暗黙デタッチ/暗黙登録解除) です。

  • implicit(暗黙)=UEとメッセージ交換をせずに、ネットワーク側の判断だけで登録を解除する。
  • 目的はリソース(UEコンテキスト・ページング対象)の適正化。届かない相手のために資源を抱え続けないため。
  • 暗黙デタッチ後、UEが再び電波の届く場所へ戻る・電源が入ると、UEは(周期更新ではなく)改めて登録(Initial Registration 等)をやり直すことになります。

implicit deregistration の具体的タイミング・タイマは要確認

ネットワークが「どのタイマが満了したら」「いつ」UEを暗黙デタッチするかの厳密な条件・タイマ名(周期タイマとネットワーク側監視タイマの関係、余裕分の取り方等)は版・実装依存であり、本章では概念のみ扱い、具体的なタイマ名・値は要確認とします(TS 23.501 の UE reachability / registration management 該当節を要確認)。


Architecture

Periodic Registration Update に関わる要素と、それらを結ぶInterfaceです。主役は AMF で、生存記録の更新とタイマ管理・暗黙デタッチ判断を担います。Mobility Registration Update と異なり、TAIリスト再割当は通常不要で、UDM / AUSF の関与は通常薄い(条件付き)ため、破線・注記で表します。

flowchart LR
    UE(("UE
(REGISTERED)
周期タイマ満了")) ---|"N1 (NAS): Registration Request
type=periodic"| AMF UE -. "RRC (無線・範囲外)" .- RAN["(R)AN / gNB"] RAN ---|"N2 (NGAP)"| AMF["AMF
(生存記録更新
タイマ管理・暗黙デタッチ判断)"] AMF -.->|"N12 (通常不要: 再認証時のみ)"| AUSF["AUSF
(通常関与薄い)"] AMF -.->|"N8 (通常不要: 加入情報変更時のみ)"| UDM["UDM
(通常関与薄い)"] AMF -. "更新が来ない → implicit deregistration
(概念・要確認)" .- IMPL["暗黙デタッチ判断"] classDef core fill:#efe,stroke:#3a3,stroke-width:2px; classDef cond fill:#eef,stroke:#66a,stroke-width:1px,stroke-dasharray:4 2; class AMF core; class AUSF,UDM,IMPL cond;

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

  • UE — 周期登録更新タイマが満了した端末。移動していなくてよいRegistration Request(type=periodic registration updating) を送り、応答後にタイマを再スタートする。無線側のRRCは範囲外。
  • (R)AN / gNB — 無線アクセス。UEの NAS を NGAP に載せて AMF へ運ぶ。
  • AMF — 周期更新の受付主体。既存UEコンテキストを確認し、UEの生存記録(在圏であること)を更新、(必要なら)次の周期タイマ値を割り当て、Registration Accept で応答する。周期報告が来ないUEの implicit deregistration を判断する。
  • AUSF(通常関与薄い) — 再認証が必要な例外的な場合のみ関与し得る(N12)。周期更新では通常発生しない。
  • UDM(通常関与薄い) — 加入情報の変更等がある例外的な場合のみ関与し得る(N8)。周期更新では通常発生しない。

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

Network Function(登場NF)

Periodic Registration Update に登場するコア側NFの役割です。gNB は無線アクセス側であり、コアNFではありません(本表はコアNFに限定)。周期更新では AMF が単独で処理を完結できるのが基本で、UDM / AUSF は通常関与しません(条件付き=例外時のみ)。

NF この手順での役割 保持/取得する情報 この手順で使う主なAPI/手続き 障害時の影響
AMF 周期更新の受付・処理主体。既存UEコンテキスト確認、UEの生存記録更新、次の周期タイマ値割当、Registration Accept 送出、implicit deregistration 判断 UEコンテキスト、5G-GUTI、周期タイマ状態、在圏(TAI)、Registration Area(TAIリスト) NGAP(Initial UE Message 受領 等, N2)/通常は他NFを消費しない 周期更新が処理されず、生存確認が滞る。誤って暗黙デタッチされると再登録が必要になり得る
UDM(通常関与薄い) 加入情報変更等の例外時のみ関与し得る 加入者データ、SUPI、UE↔AMF 対応 Nudm_UECM_Registration / Nudm_SDM_Get(例外時のみ, N8) (関与時のみ)加入情報更新不可
AUSF(通常関与薄い) 再認証が必要な例外時のみ 5G-AKA 等に関与し得る KSEAF, KAUSF(再認証時) Nausf_UEAuthentication(例外時のみ, N12) (関与時のみ)再認証が完了せず更新が進まない

UDM / AUSF は周期更新では通常不要

Periodic Registration Update は既存のUEコンテキスト・セキュリティコンテキストを再利用でき、位置も通常は変わらないため、UDM / AUSF への照会は通常発生しません。関与するのは、再認証が必要・加入情報が変わった等の例外的な条件が成立したときのみです(状況依存、具体条件は要確認)。断定は避けます。

Interface / Protocol

この手順で使うInterfaceとProtocolです。周期更新では基本的に N1 / N2 のみで完結し、N8 / N12 は通常不要(例外時のみ)です。

Interface Protocol Transport 相手 この手順での用途
N1 NAS(5GMM) (NGAP/N2上でトンネル) UE ⇔ AMF UE→AMF の Registration Request(type=periodic)、AMF→UE の Registration Accept、(必要時)UE→AMF の Registration Complete
N2 NGAP SCTP(port 38412) gNB ⇔ AMF NAS の運搬(Initial UE Message 等)、UEコンテキスト関連手続き
N8(通常不要) SBI(HTTP/2, TLS, JSON) TCP/TLS AMF ⇔ UDM 加入情報変更等の例外時のみ(Nudm_*)
N12(通常不要) SBI(HTTP/2, TLS, JSON) TCP/TLS AMF ⇔ AUSF 再認証が必要な例外時のみ(Nausf_UEAuthentication)

N8 / N12 は周期更新では通常発生しない

3GPPアーキテクチャでは AMF⇔UDM は N8、AMF⇔AUSF は N12 と呼ばれ、実体は SBI(Service Based Interface, HTTP/2) 上の Nudm_ / Nausf_ サービスです。Mobility Registration Update では条件付きでこれらが用いられ得ますが、Periodic Registration Update では通常これらは不要で、AMFが単独で生存記録の更新を完結できるのが基本です。例外的に関与する具体条件は TS 23.502 の該当手順で要確認とし、断定は避けます。

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


Procedure — Call Flow

このページの心臓部です。 Periodic Registration Update の主要手順を、Mermaid の sequenceDiagram で示します。根拠は 3GPP TS 23.502 §4.2.2.2系(Registration procedures) および TS 24.501 §5.5.1系(NAS Registration procedure)TS 38.413(NGAP) です(章番号の細部は要確認)。Mobility Registration Update と骨格は共通ですが、認証・加入者取得・TAIリスト再割当が通常は発生せず、より軽量である点を強調します。

前提: UEは登録済み(5GMM-REGISTERED)で、周期タイマが満了

UEは 5GMM-REGISTERED で、直近の登録で得た 5G-GUTI とセキュリティコンテキストを保持しているとします。移動していなくても、周期登録更新タイマが満了したことを契機に本手続きを起動します。Initial Registration の全体は Initial Registration を参照。

sequenceDiagram
    autonumber
    participant UE as UE (REGISTERED)
    participant RAN as (R)AN / gNB
    participant AMF
    participant UDM

    Note over UE: 周期登録更新タイマ満了(移動なしでよい)
    Note over UE,RAN: RRC接続確立/再開(無線側・概略/範囲外)
    UE->>RAN: Registration Request (NAS)
type=periodic registration updating Note right of UE: TS 24.501 §5.5.1。5GS registration type=periodic(要確認) RAN->>AMF: Initial UE Message (NGAP) に NAS を載せる Note right of RAN: N2 / TS 38.413 Note over AMF: 既存UEコンテキストを確認(5G-GUTI で解決) Note over AMF: UEの生存記録を更新(在圏とみなす) opt 例外時のみ: 再認証/加入情報照会(通常は発生しない) AMF->>UDM: Nudm_*(加入情報変更時等, N8) UDM-->>AMF: 加入者データ(例外時のみ) end AMF->>UE: Registration Accept (NAS)
(必要なら)次の周期タイマ値 Note right of AMF: TS 24.501 §5.5.1。通常はTAIリスト再割当なし opt 必要時(次タイマ値/5G-GUTI 再割当時 等) UE->>AMF: Registration Complete (NAS) end Note over UE,AMF: UEは周期タイマを再スタート。5GMM-REGISTERED を維持

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

  1. UE→(R)AN: UEは周期登録更新タイマの満了を契機に(無線側で)RRC接続を確立/再開し(概略/範囲外)、Registration Request(NAS)Registration type = periodic registration updating で運ぶ。5GS mobile identity には有効な 5G-GUTI が入るのが典型(IE名・type 値は要確認)。参照: TS 24.501 §5.5.1(章番号要確認)。
  2. (R)AN→AMF: gNBは Initial UE Message(NGAP) に NAS を載せて AMF へ送る(N2 / TS 38.413)。
  3. AMFの判断(コンテキスト確認): AMFが 5G-GUTI から既存UEコンテキストを解決する。周期更新では既存のセキュリティ・加入情報を再利用できるのが基本で、Mobility よりさらに軽量。
  4. 生存記録の更新: AMFはUEが在圏していることを記録し(reachability の維持)、周期タイマ監視を更新する。これが本手続きの本質。
  5. (例外時のみ)再認証/加入情報照会: 再認証が必要・加入情報が変わった等の例外的な場合のみ、AMF→AUSF(N12)/AMF→UDM(N8)を行い得る。周期更新では通常発生しない状況依存)。
  6. 受諾: AMF→UE Registration Accept(NAS) で応答する。通常はTAIリスト再割当なし(同一エリア内)。必要なら次の周期タイマ値や registration result 等を通知し得る(IE名・扱いは要確認)。
  7. (必要時)完了: 次タイマ値の適用や 5G-GUTI 再割当がある場合等、UE→AMF Registration Complete(NAS) を返す。UEは周期タイマを再スタートし、5GMM-REGISTERED を維持する(DEREGISTERED からの新規遷移ではない)。

条件分岐は状況・実装依存。周期更新は「軽量が基本」だが断定はしない

再認証・UDM照会(ステップ5)、次タイマ値の通知・5G-GUTI 再割当(ステップ6-7)は、既存コンテキストの有効性・構成・オペレータポリシーにより省略・変化します。周期更新は通常これらが発生しない軽量な手続きですが、「必ず発生しない」と断定はできません(状況依存)。TS 23.502 §4.2.2系 は多くの任意/条件付きステップを含むため、具体条件は個別に仕様確認が必要です(一部は要確認)。

参照: TS 23.502 §4.2.2.2系(Registration procedures、章番号要確認)、TS 24.501 §5.5.1系(NAS側 Registration procedure)、TS 38.413(NGAP)。

Signal Flow

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

Message / Operation Protocol 送信元→先 目的 主要IE(要確認あり) 結果
Registration Request NAS(5GMM) UE→AMF 周期登録更新要求 5GS registration type = periodic registration updating、5GS mobile identity(5G-GUTI)、UE security capability 等(type値・IE名要確認 AMFが生存記録更新処理を開始
Initial UE Message NGAP gNB→AMF NAS(Registration Request)の運搬 NAS-PDU、User Location(在圏TAI)等 AMFがNASを受領
Nudm_ / Nausf_(例外時のみ) SBI(HTTP/2) AMF→UDM/AUSF 加入情報照会・再認証(通常不要 SUPI 等(要確認 (関与時のみ)加入情報更新・再認証
Registration Accept NAS(5GMM) AMF→UE 周期登録更新受諾 registration result、(必要なら)次の周期タイマ値、(通常は再割当なしだが起こり得る)TAI list / 5G-GUTI 等(IE名要確認 UEが生存確認完了を認識
Registration Complete NAS(5GMM) UE→AMF 周期登録更新完了(必要時) (次タイマ値/5G-GUTI 再割当時のACK 等) 手続きの完了確認

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

State Machine

UE側の 5GMM 状態 の観点です。Periodic Registration Update は 5GMM-REGISTERED を維持したまま生存確認を行い、周期タイマを再スタートします(根拠: TS 24.501 §5.1.3 / §5.5.1系、章番号要確認)。重要なのは、更新が来続ける限り REGISTERED を維持し、更新が来ないと ネットワーク判断で implicit deregistration → DEREGISTERED へ至り得る、という分岐です。

stateDiagram-v2
    [*] --> REGISTERED: Initial Registration 完了後(周期タイマ開始)
    REGISTERED --> REGISTERED_UPDATE: 周期タイマ満了 → Registration Request (type=periodic) 送信
    REGISTERED_UPDATE --> REGISTERED: Registration Accept 受信(周期タイマ再スタート)
    REGISTERED --> DEREGISTERED: 周期更新が来ない → implicit deregistration(NW判断・概念)
    REGISTERED --> DEREGISTERED: De-registration / 登録失効
    DEREGISTERED --> [*]
  • 5GMM-REGISTERED — 登録済み。周期タイマが動いている間は状態を変えない。タイマ満了で周期更新を送ると更新の過渡状態へ。
  • 5GMM-REGISTERED(更新中/過渡) — Registration Request(type=periodic)を送って応答待ちの過渡状態(上図では REGISTERED_UPDATE として図示)。Registration Accept を受けたら周期タイマを再スタートして REGISTERED へ戻る。
  • 5GMM-DEREGISTERED — 未登録。周期更新が期待時刻に来ずネットワークが implicit deregistration を判断した場合、明示的なやり取りなしにこの状態へ至り得る(NW側判断・概念、厳密なタイミングは要確認)。De-registration・登録失効でも遷移し得る。

図中の状態名は説明用(過渡状態の表記)/implicit deregistration は概念図

上図の REGISTERED_UPDATE は「REGISTERED 内で周期更新に入り応答待ちの過渡状態」を説明するための表記です。3GPP の 5GMM 状態定義(TS 24.501 §5.1.3)は主に 5GMM-DEREGISTERED / 5GMM-REGISTERED / 5GMM-REGISTERED-INITIATED / 5GMM-DEREGISTERED-INITIATED 等で構成されます。periodic registration updating が具体的にどの下位状態を用いるか、および implicit deregistration がネットワーク側でどのタイマ満了で発火するかの厳密な対応は要確認とし、本図は概念図として提示します。CM状態(CM-IDLE / CM-CONNECTED)とは別軸であり、周期更新のためにUEは CM-CONNECTED になって手続きを行います(CM状態の詳細は Service Request 参照)。

Packet Analysis (Wireshark)

Periodic Registration Update を Wireshark で解析するときの要点です。コア側では NAS Registration Request/AcceptNGAP(Initial UE Message 等) にネストされて観測されます。Mobility との決め手の違いは 5GS registration type の値です。

主要 Display Filter

Filter 意味
ngap NGAP メッセージ全般(Initial UE Message 等を含む)
nas-5gs 5GS NAS メッセージ全般(Registration Request/Accept/Complete を含む)
sctp.port == 38412 N2(NGAP) の SCTP ポート

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

NAS の message type 値や ngap.procedureCode の数値、5GS registration type の符号値、各IEの名前は 3GPP の割当に基づきますが、Wireshark のバージョンやディセクタ実装で表示・照合方法が異なる場合があります。本ページでは架空の数値を断定しません。具体的な procedureCode / message type / registration type 値は要確認とし、実機では GUI のプロトコル階層表示で確認するのが確実です。

Decode の見どころ(主要IE)

  • NAS Registration Request(UE→AMF) — 次のIEに注目(IE名は代表表記、要確認)。
    • 5GS registration type — ここが periodic registration updating になっているのが本手続きの決め手(Initial では initial registration、Mobility では mobility registration updating)。値の符号は要確認
    • 5GS mobile identity — Periodic Registration Update では典型的に 5G-GUTI(初回登録の SUCI とは異なる)。
  • NAS Registration Accept(AMF→UE) — 次のIEに注目。
    • registration result 等。周期更新では通常 TAI list 再割当なし(同一エリア)だが、起こり得る(要確認)。
    • 次の周期タイマ値(AMFが通知する場合)— 具体的なIE名・扱いは要確認

暗号化に注意(Registration Accept 以降)

既存のNASセキュリティコンテキストが有効な場合、Registration Request 以降のNASは暗号化・完全性保護され得るため、Wireshark で平文の中身が見えないことがあります(正常)。これは Initial Registration の Security Mode 以降と同様です。解析はキー投入や実装のログと併用します。

メッセージのネスト構造(NGAP に NAS がネスト)

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

NGAP-PDU
 └─ InitialUEMessage
     └─ NAS-PDU
         └─ 5GS NAS Message
             └─ Registration Request(5GS registration type=periodic)

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

本ページのフィルタ・IE名は解析の指針です。実際のパケットは無線・コアの実装や設定に依存します。Open5GSfree5GC のテストベッドで、周期登録更新タイマを短めに設定してUEを移動させずに放置すると、周期タイマ満了時の N2区間 NAS Registration Request(type=periodic)/ Registration Accept を実際にキャプチャして学習できます(タイマのキー名・値は実装依存=後述)。

Configuration

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

周期登録更新タイマ関連(AMF 側)

  • 周期登録更新タイマ(一般に T3512 と呼ばれる周期登録更新タイマが該当するとされる)— UEが周期更新を起動する間隔を決める。AMFが Accept 時にUEへ値を通知し得る。名称・値・設定キーは版・実装依存の面があり要確認。Open5GS / free5GC で設定可能な範囲・キー名は各実装のドキュメントで確認する。
  • implicit deregistration 関連タイマ(ネットワーク側で「更新が来ない」を判定する監視タイマ。周期タイマ+余裕分に相当するとされる)— 名称・値・キー名は版・実装依存であり要確認。周期タイマとの関係も実装依存。

具体値・ベンダー固有・タイマ名は実装依存/要確認

設定ファイルのキー名・階層・必須項目・タイマの具体値は、Open5GS / free5GC / 商用ベンダー(Cisco 等)で異なります。上記は構造レベルの要点であり、実際のキー名や値は各実装のドキュメントで確認してください(実装依存)。周期登録更新タイマの名称(T3512 等)・implicit deregistration タイマの名称と値は要確認とし、架空の設定値は本ページには記載しません(Timer辞典 参照。現状 T3512 は辞典未収録)。

Trouble Shooting

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

症状 想定原因 確認ポイント 関連ログ/Packet 対処の方向性
(a) 在圏中のはずのUEが暗黙デタッチされている 周期更新が届いていない/ネットワーク側監視タイマ満了。無線区間の不達等 直近の周期更新の成否、周期タイマ値とNW側監視タイマの整合、無線カバレッジ NAS Registration Request(type=periodic)、AMFログ タイマ値の整合、周期更新の到達性を確認。暗黙デタッチ後はUE再登録
(b) 更新頻度が過大(シグナリング過多) 周期タイマ値が短すぎる 周期タイマ設定値、AMFの割当方針 周期 Registration Request の頻度、AMFログ 周期タイマ値を運用に合わせて延長(実装依存
(c) 更新頻度が過小(離脱検知が遅い) 周期タイマ値が長すぎる/NW側監視タイマとの不整合 周期タイマ設定値、implicit deregistration 判定条件 暗黙デタッチまでの時間、AMFログ 周期タイマ値・監視タイマの見直し(要確認・実装依存)
(d) 周期更新が拒否される(Registration Reject) 既存コンテキスト不整合、5G-GUTI 解決不可、加入状態の問題 AMFのUEコンテキスト、5G-GUTI マッピング NAS Registration Request/Reject、AMFログ UEコンテキスト整合、SUCI での再登録を確認

EPCとの比較

4G(EPC) 経験者が 5G へ橋渡しできるよう対比します。「移動していなくても、定期的に生存を届け出て、来なければ暗黙的に登録解除する」という基本思想は4Gと5Gで共通です。4Gの Periodic TAU(Periodic Tracking Area Update) が、5Gの Periodic Registration Update に対応します。

観点 4G / EPC 5G / 5GC
周期更新手続き Periodic TAU(Periodic Tracking Area Update) Periodic Registration Update
手続きメッセージ TAU Request(periodic)/ TAU Accept Registration Request(type=periodic)/ Registration Accept
制御NF MME AMF
無線ノード制御 S1AP(TS 36.413) NGAP(TS 38.413)
周期タイマ 周期TAUタイマ(一般に T3412 とされる。値要確認 周期登録更新タイマ(一般に T3512 とされる。値要確認
更新が来ない場合 implicit detach(暗黙デタッチ) implicit deregistration(暗黙登録解除)
登録/接続状態 EMM-REGISTERED を維持 5GMM-REGISTERED を維持

Periodic TAU ↔ Periodic Registration Update の対応

4Gでは、UEが移動していなくても周期TAUタイマ(一般に T3412 とされる。名称・値は要確認)の満了時に Periodic TAUMME へ送り、生存を届け出ました。更新が来なければ MME は implicit detach でUEを登録解除しました。5Gでは、同じ役割を Periodic Registration Update が担い、AMF が生存を記録し、来なければ implicit deregistration に進みます。MME ↔ AMFPeriodic TAU ↔ Periodic Registration Updateimplicit detach ↔ implicit deregistration、そして周期タイマ(T3412 相当 ↔ T3512 相当、いずれも名称・値は要確認)という生存確認の考え方は共通です。

Release差分

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

  • Rel-15 — 5GC の基本 Registration 手順(initial / mobility / periodic / emergency の Registration type、周期登録更新タイマ、implicit deregistration の基礎)が確立。本章はこの Rel-15 基礎の範囲。
  • MICO mode(Mobile Initiated Connection Only) — UEがネットワーク起点の到達(Paging)を受けない省電力モード。周期更新・到達性(reachability)管理と関係する概念だが、本章のスコープ外で概念のみ触れる。MICO 有効時の周期更新・到達性の扱いは版・構成依存であり、詳細は要確認FAQ 参照)。
  • RRC Inactive / RAN Notification Area(RNA) — Rel-15 で導入されたUE状態。無線側では RNA Update という別レイヤの手続きがあり、コア(AMF)起点の周期登録更新とは別の概念(無線側・概念のみ)。
  • 省電力・到達性拡張(Rel-16 以降) — 省電力や到達性管理の拡張が進んだ世代。周期登録更新手続き本体への具体差分は要確認

Release差分・MICO mode は要確認

各Releaseで「周期登録更新・到達性管理」にどの機能がどこまで織り込まれたか、とくに MICO mode と周期更新の相互作用は、対象TSの版差分を個別に確認する必要があります。上記は概観であり、具体項目は要確認です。

3GPP Specification

Spec 内容
TS 23.502 §4.2.2.2系 Registration procedures(Periodic Registration Update を含む。細目章番号は要確認
TS 23.501 §5.3系 登録管理(RM)・periodic registration の位置づけ(章番号要確認
TS 23.501 §5.4系 UE reachability・到達性管理(周期更新・implicit deregistration の背景。章番号要確認
TS 24.501 §5.5.1系 NAS 側 Registration procedure(Registration type / periodic registration updating 等。章番号要確認
TS 24.501 §5.1.3 5GMM 状態(状態遷移の根拠)
TS 24.501 §10.2 NAS タイマー(周期登録更新タイマ T3512 相当の定義。名称・値要確認
TS 38.413 (NGAP各章) NGAP(Initial UE Message 等。個別章番号要確認
TS 29.518 Namf(AMFのサービスAPI)

章番号の扱い

TS 23.502 §4.2.2.2系(Registration procedures)/ TS 24.501 §5.5.1系(NAS Registration procedure)・§5.1.3(5GMM 状態)・§10.2(NASタイマー)/ TS 23.501 §5.3系・§5.4系(RM・UE reachability)は本章の骨格として参照しています。ただし細かな章番号(Periodic Registration Update の枝番、UE reachability の節番号)は版により異なる場合があり、一部は要確認としています。TS 38.413 の NGAP 個別章番号、各IE名、5GS registration type=periodic の符号値、および周期登録更新タイマ(T3512 相当)・4Gの周期TAUタイマ(T3412 相当)・implicit deregistration 監視タイマの名称と値要確認です。

FAQ

Q1. Mobility Registration Update と Periodic Registration Update は何が違うのか?

起動の契機が違います。Mobility は「場所が変わった(在圏TAが割当TAIリスト外になった)」ことが契機で、主目的は Registration Area(TAIリスト)の再割当・位置更新です。一方 Periodic(本章)は「時間が経った(周期タイマ満了)」ことが契機で、UEが移動していなくても定期的に生存を届け出るのが主目的です。手続きの骨格は共通ですが、周期更新では通常 TAIリスト再割当も認証もUDM照会も発生せず、より軽量です(状況依存)。詳細は Mobility Registration Update 参照。

Q2. 周期更新をしないとどうなるのか?

ネットワークは周期更新が期待時刻に来ないと「UEが離脱した(圏外・電源断)らしい」と推定し、明示的なやり取りなしにUEを登録解除する implicit deregistration(暗黙デタッチ) に進み得ます。これによりUEコンテキストやページング対象などのリソースが解放されます。暗黙デタッチ後、UEが再び通信可能になると改めて登録(Initial Registration 等)をやり直すことになります。厳密な発火タイミング・タイマは要確認State Machine 参照)。

Q3. 周期タイマはどれくらいの間隔なのか?

周期登録更新タイマ(一般に T3512 と呼ばれるとされる)の具体的な値は断定できません。名称・デフォルト値はネットワーク設定・実装・版に依存し、AMFが Accept 時にUEへ通知し得ます。値は「離脱を早く検知したい(短く)」と「省シグナリングにしたい(長く)」のトレードオフで運用側が決めます。名称・値ともに要確認とし、現状 Timer辞典 にも T3512 の行はありません(TS 24.501 §10.2 を要確認)。

Q4. MICO mode とは関係があるのか?

関係し得ますが、本章のスコープ外で概念のみ扱います。MICO mode(Mobile Initiated Connection Only) は、UEがネットワーク起点の到達(Paging)を受けない省電力モードで、到達性(reachability)管理・周期更新と関わります。MICO 有効時に周期更新や到達性がどう扱われるかは版・構成依存であり、要確認です(Release差分 参照)。

Q5. 4G の周期TAU(Periodic TAU)と同じものか?

役割は対応します。4Gの Periodic TAU(Periodic Tracking Area Update) は、UEが移動していなくても周期TAUタイマ(一般に T3412 とされる。要確認)満了時に MME へ生存を届け出る手続きで、来なければ implicit detach で登録解除されました。5Gの Periodic Registration Update は同じ役割を AMF に対して果たし、来なければ implicit deregistration に進みます。MME↔AMF、Periodic TAU↔Periodic Registration Update、implicit detach↔implicit deregistration という生存確認の考え方は共通です。タイマ名(T3412/T3512)は要確認EPCとの比較 参照)。

Summary

  • Periodic Registration Update は、UEが移動していなくても周期登録更新タイマ満了を契機に「まだ在圏・生存している」ことをネットワークへ届け出る定期的な登録更新4GのPeriodic TAUに相当する。
  • Why の核心は「ネットワークは待機中UEの圏外・電源断を明示的には知れない」こと。定期的な生存確認が来続ければ在圏、途絶えれば implicit deregistration(暗黙デタッチ) でリソースを適正化する。
  • トリガは UE側の周期登録更新タイマ満了(一般に T3512 とされるが名称・値は要確認)。UEが Registration Request(type=periodic registration updating) を AMF へ送る。
  • 主役は AMF(既存UEコンテキスト確認・生存記録更新・タイマ管理・暗黙デタッチ判断・Registration Accept 送出)。UDM / AUSF は通常関与しない(例外時のみ)。
  • Mobility Registration Update骨格は共通だが、契機が「時間」であり、通常はTAIリスト再割当・認証・UDM照会が発生せず、より軽量(状況依存)。5GMM-REGISTERED を維持し、UEは周期タイマを再スタートする。
  • 根拠は TS 23.502 §4.2.2.2系 / TS 24.501 §5.5.1系・§5.1.3・§10.2 / TS 23.501 §5.3系・§5.4系 / TS 38.413(章番号・IE名・registration type 値・周期タイマ名/値・implicit deregistration タイマの一部は要確認)。

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

理解度チェック

Q1. Periodic Registration Update のトリガは何か?(解答)

UE側の周期登録更新タイマの満了。UEは移動していなくても、タイマ満了を契機に登録更新(type=periodic)を起動する。

Q2. Registration Request の 5GS registration type には何が入るか?(解答)

periodic registration updating(本手続きの決め手)。Initial では initial registration、Mobility では mobility registration updating。値の符号は要確認

Q3. 周期更新が来ないUEはネットワークにどう扱われ得るか?(解答)

ネットワークが「離脱したらしい」と推定し、明示的なやり取りなしに登録解除する implicit deregistration(暗黙デタッチ) 扱いになり得る。目的はリソース(コンテキスト・ページング対象)の適正化。厳密なタイミング・タイマは要確認

Q4. Mobility Registration Update と比べて、Periodic Registration Update の契機と軽さの違いは?(解答)

契機は Mobility が「場所が変わった」、Periodic が「時間が経った(周期タイマ満了)」。Periodic は通常 TAIリスト再割当も認証もUDM照会も発生せずより軽量(状況依存・断定しない)。

Q5. 4G で Periodic Registration Update に相当する手続きと、その制御NF・更新が来ない場合の扱いは?(解答)

4Gの Periodic TAU(Periodic Tracking Area Update)、制御NFは MME、更新が来なければ implicit detach。5Gでは Periodic Registration UpdateAMF が担い、来なければ implicit deregistration

演習

: 次の Periodic Registration Update 主要ステップを正しい順に並べ替えてください。

A. AMF が UEの生存記録を更新(在圏とみなす)
B. UE → gNB: Registration Request(NAS, type=periodic)(RRC確立後)
C. AMF → UE: Registration Accept((必要なら)次の周期タイマ値)
D. gNB → AMF: Initial UE Message(NGAP) で NAS を運搬
E. AMF が 5G-GUTI から既存UEコンテキストを確認
F. UE の周期登録更新タイマが満了
G. UE が周期タイマを再スタート(5GMM-REGISTERED 維持)
解答

F → B → D → E → A → C → G

  • F: UEの周期登録更新タイマ満了(契機。移動なしでよい)
  • B: UEが Registration Request(type=periodic、RRC確立は無線側・概略)
  • D: gNB→AMF Initial UE Message で NAS 運搬(N2)
  • E: AMFが 5G-GUTI から既存UEコンテキストを確認
  • A: AMFがUEの生存記録を更新(在圏とみなす)
  • C: AMF→UE Registration Accept((必要なら)次の周期タイマ値)
  • G: UEが周期タイマを再スタート、5GMM-REGISTERED を維持

※ 通常は認証・UDM照会・TAIリスト再割当は発生しない(状況依存)。次タイマ値/5G-GUTI 再割当時は C の後に Registration Complete が入り得る。

Next Step

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