Mobility Registration Update — モビリティ登録更新¶
学習目標¶
このページを読み終えると、次のことができるようになります。
- Why(なぜ Mobility Registration Update が必要か)を、UEが Registration Area の外へ移動するとネットワークがUEの居場所を見失う、という観点で説明できる。
- Mobility Registration Update のトリガ(在圏TAが割当済みTAIリストに含まれないエリアへ移動)を説明できる。
- Registration type(initial / mobility / periodic / emergency)の違いを整理し、本章が mobility registration updating に対応することを説明できる。
- Registration Area(TAIリスト)の再割当と、5G-GUTI 再割当の可能性を説明できる。
- Initial Registration との差分(既存のUEコンテキスト・セキュリティコンテキストを再利用し、本人確認・加入者情報取得が簡略化され得る点)を説明できる。
- 4G(EPC) の TAU(Tracking Area Update) と 5G の Mobility Registration Update の対応関係を対比できる。
- Paging / Service Request と Mobility Registration Update の関係と使い分けを整理できる。
前提知識¶
先に以下を理解しておくとスムーズです。まだの人は カリキュラム から始めてください。
- Initial Registration(初回登録)の理解 — 本章は登録手続きの別バリアントです。登録の全体像・認証・セキュリティは Initial Registration を参照。
- Registration Area(登録エリア=TAIリスト)の理解 — なぜエリア単位で管理するか、なぜエリアを出ると更新が要るか。 → Paging(Registration Area の上流概念)
- Service Request の理解(Mobility Registration Update と対比するため) → Service Request
- N1 / N2(UE⇔AMF の NAS、gNB⇔AMF の NGAP) → N1 / N2
- 主役NFの役割 → AMF(条件付きで UDM / AUSF)
この章で学べること¶
本章は Mobility Registration Update(モビリティ登録更新)に限定します。UEが現在の Registration Area(TAIリスト)の外へ移動したときに、登録情報と位置をネットワークへ更新する手続きです。4GのTAU(Tracking Area Update)に相当します。コア観点、とくに AMF が受ける Registration Request(Registration type = mobility registration updating) と、その結果としての Registration Area(TAIリスト)の再割当 に焦点を当てます。
次は本章の範囲外、または概念どまりとします。
- Initial Registration の認証/セキュリティ詳細 — 本章では「既存コンテキスト再利用で簡略化され得る」点を主題化し、5G-AKA 等の詳細は Initial Registration / Security 章へ誘導します(重複は誘導)。
- Periodic Registration Update(周期的登録更新)の詳細 — 別の Registration type です。本章では Registration type の違い で対比として触れるにとどめ、詳細手順は Periodic Registration Update 章 を参照してください(範囲外)。
- AMF 間コンテキスト移送の細部 — AMF変更(AMF再選択)が起きるケースは Release・構成依存であり、概念のみ扱います(細部は要確認)。
- 無線(RRC/RAN)側の詳細 — RRC接続確立・無線リソース割当は概念にとどめ、コアの関与に焦点を当てます(無線側・実装依存)。
- SMF/UPF 側のセッション扱い — 登録更新に伴うユーザプレーンの扱いには深入りせず、登録更新のコア手続きに焦点を当てます。
Why — なぜ Mobility Registration Update が必要なのか¶
Why(なぜ必要か)から始めます。 登録済み(5GMM-REGISTERED)のUEは、Registration Area(=割り当てられた TAIリスト)の内側を移動する限り、いちいちネットワークへ届け出る必要はありません。これは、待機中(CM-IDLE)のUEをセル単位では追跡せず、「このエリアのどこかにいるはず」という粒度で管理することで、登録更新シグナリングを削減し省電力にするためです(Paging の Registration Area 設計と表裏です)。
ところがUEがそのエリアの外へ移動すると問題が起きます。ネットワークが知っている「このあたりにいるはず」の範囲(Registration Area)に、UEはもういません。この状態を放置すると次の不都合が生じます。
- 着信が届かない — Paging は Registration Area(TAIリスト)の範囲へ呼びかけますが、UEはその範囲外にいるため、呼び出しが届きません。
- 位置情報が古いまま — ネットワークが保持するUEの在圏情報が実際とズレます。
Mobility Registration Update とは、UEが「引っ越しました。新しいエリアに登録し直してください」と申告し、ネットワークが新しい Registration Area(TAIリスト)を再割当して位置情報を更新する手続きです。これによりUEは、移動先でも着信・発信・データ通信を継続できます。
例え話: 引っ越したら役所に転居届を出す
Mobility Registration Update は、引っ越したときの転居届に似ています。前の住所(旧 Registration Area)に住んでいる間は、市内をどれだけ動き回っても届け出は不要です。ところが別の市へ引っ越す(Registration Area の外へ出る)と、役所(AMF)は前の住所へ郵便物(Paging)を届けても本人に届きません。そこで転居届(Mobility Registration Update)を出すと、役所は新しい担当エリア(新 TAIリスト)を割り当て、以降は新しい住所へ郵便物が届くようになります。本人確認(認証)は、前の登録で済んでいれば毎回やり直す必要はなく、簡略化され得ます。
Overview — 概要¶
Mobility Registration Update は、大きく次の流れで起きます。
UEが移動し、在圏TA(Tracking Area)が割当済みTAIリストに含まれないことを検知 → UEが Registration Request(Registration type = mobility registration updating) を gNB 経由で AMF へ送る(N1/N2) → AMFが既存のUEコンテキストを確認(必要なら再認証・UDM照会は条件付き) → AMFが新しい Registration Area(TAIリスト) を決定 → AMFが Registration Accept で応答し、新TAIリスト・(必要なら)新 5G-GUTI を通知 → UEが Registration Complete を返して完了です。
Registration type は、同じ Registration 手続きの「用途」を示す種別です。本章はこのうち mobility に対応します。
| Registration type | いつ使うか | 本章との関係 |
|---|---|---|
| initial registration | UEが電源ON後などにはじめて登録する | 別章 Initial Registration の対象 |
| mobility registration updating | UEが Registration Area(TAIリスト)の外へ移動した | 本章の対象 |
| periodic registration updating | 周期タイマ満了時に生存確認として定期更新 | 別章 Periodic Registration Update の対象 |
| emergency registration | 緊急呼のための登録 | 範囲外 |
Registration type の列挙値・名称は要確認
上表の Registration type は 3GPP TS 24.501 の 5GS registration type に基づく代表的な種別ですが、正確な列挙名・値("mobility registration updating" 等の表記や符号値)はディセクタ・版により表示が異なる場合があり、要確認とします。架空の符号値は本ページに記載しません(Packet Analysis 参照)。
| 項目 | 内容 |
|---|---|
| トリガ | 在圏TAが割当済みTAIリストに含まれないエリアへの移動 |
| 対象UE | 5GMM-REGISTERED の登録済みUE |
| Registration type | mobility registration updating |
| 主役NF | AMF(コンテキスト確認・TAIリスト再割当・受諾) |
| 使うInterface | N1(NAS)/ N2(NGAP)(条件付き: N8/N12 SBI=再認証・加入情報時) |
| 結果 | 新 Registration Area(TAIリスト) 割当、必要なら 5G-GUTI 再割当。位置情報更新 |
Basic Concept — 初心者向け説明¶
Mobility Registration Update を理解するには、3つのキーワードを押さえます。
1. Registration Area と移動(なぜ出ると更新が要るか)¶
Registration Area(登録エリア) は、AMFがUEに割り当てる TAI(Tracking Area Identity)のリストです。登録受諾(Registration Accept)時にUEへ通知されます(この定義は Paging と厳密に揃えています)。
- UEはこのエリア内を移動する限り、いちいち登録更新しなくてよい(=シグナリング削減・省電力)。
- ネットワークはUEをセル単位では追跡しないため、着信時は Registration Area 全体へ Paging で呼びかける。
- UEがエリア外へ出ると、Paging が届かなくなる。そこで Mobility Registration Update で新しいエリア(新TAIリスト)を取得する。
UE側は、自分の在圏TAが、割り当てられているTAIリストに含まれるかどうかを常にチェックしています。含まれなくなった瞬間が、Mobility Registration Update を起動する契機です。
エリア設計はトレードオフ(Paging章と共通)
Registration Area を広く設計すると、Mobility Registration Update(登録更新)は減りますが、Paging 時に呼びかける範囲が広がります。逆に狭くすると登録更新が増えます。このトレードオフの設計はオペレータ方針・実装依存です(Configuration / Paging 参照)。
2. Registration type の違い(initial / mobility / periodic)¶
同じ「登録(Registration)」手続きでも、Registration type によって用途と分岐が異なります。
- initial registration — UEが電源ON後などにはじめて登録する。本人確認(認証)・加入者情報取得をフルに行う。→ Initial Registration
- mobility registration updating — 既に登録済みのUEが Registration Area の外へ移動したときの更新。既存コンテキストを再利用できる分、簡略化され得る(本章の対象)。
- periodic registration updating — UEが移動していなくても、周期タイマの満了時に「まだ生きています」と定期的に更新する。ネットワークがUEの離脱を検知するための生存確認的な役割(詳細は Periodic Registration Update を参照)。
mobility と periodic はどちらも「更新(updating)」だが契機が違う
mobility は「場所が変わった(エリアを出た)」ことが契機、periodic は「時間が経った(周期タイマ満了)」ことが契機です。手続きの骨格は共通部分が多いものの、起動条件が異なります。周期更新に使うタイマ(一般に T3512 と呼ばれる周期登録更新タイマが該当するとされる)は、名称・値ともに版・実装依存の面があり、正確な扱いは要確認とします(Timer辞典 参照)。
3. Initial Registration との差分(何を省き何を更新するか)¶
Mobility Registration Update は「登録手続きの別バリアント」ですが、Initial Registration と同じことを全部やり直すわけではありません。既にUEはネットワークに登録済みで、UEコンテキスト(セキュリティコンテキスト・加入者情報・5G-GUTI 等)が存在するからです。
| 観点 | Initial Registration | Mobility Registration Update |
|---|---|---|
| 前提状態 | 5GMM-DEREGISTERED(未登録) | 5GMM-REGISTERED(登録済み) |
| Registration type | initial registration | mobility registration updating |
| 本人確認(認証) | 基本的に実施(5G-AKA) | 既存セキュリティコンテキスト再利用で省略され得る(条件付き・状況依存) |
| 加入者情報取得(UDM) | 取得する | 既存情報を再利用し得る(変更時等のみ照会=条件付き) |
| 主な更新対象 | 在圏・認証・鍵・加入情報の新規確立 | Registration Area(TAIリスト)の再割当、位置情報更新、必要なら 5G-GUTI 再割当 |
| 結果状態 | 5GMM-REGISTERED へ遷移 | 5GMM-REGISTERED を維持(Registration Area を更新) |
省略可否は状況・実装依存
認証やUDM照会を省略できるかは、既存セキュリティコンテキストの有効性・オペレータポリシー・AMF変更の有無などに依存します。必ず省略される/必ず実施されると断定はできません(条件付き・状況依存、詳細条件は TS 23.502 / TS 24.501 の該当条件を要確認)。
Architecture¶
Mobility Registration Update に関わる要素と、それらを結ぶInterfaceです。主役は AMF で、UDM / AUSF は条件付き(再認証・加入情報照会が必要な場合のみ)関与します。AMF変更(AMF再選択)が起きる場合の旧AMFからのコンテキスト移送は、Release・構成依存のため破線・注記で概念表現します。
flowchart LR
UE(("UE
(REGISTERED)")) ---|"N1 (NAS): Registration Request
type=mobility"| AMF
UE -. "RRC (無線・範囲外)" .- RAN["(R)AN / gNB"]
RAN ---|"N2 (NGAP)"| AMF["AMF
(登録更新処理
TAIリスト再割当)"]
AMF -.->|"N12 (条件付き: 再認証)"| AUSF["AUSF
(条件付き)"]
AMF -.->|"N8 (条件付き: 加入情報)"| UDM["UDM
(条件付き)"]
AMF -. "AMF変更時: コンテキスト移送
(Rel/構成依存・概念)" .- oldAMF["旧AMF
(AMF変更時のみ)"]
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,oldAMF cond;
各要素の役割は次の通りです。
- UE — 移動した端末。在圏TAが割当TAIリスト外になったことを検知し、Registration Request(type=mobility registration updating) を送る。無線側のRRCは範囲外。
- (R)AN / gNB — 無線アクセス。UEの NAS を NGAP に載せて AMF へ運ぶ。AMF選択(AMF selection)を行い得る。
- AMF — 登録更新の司令塔。既存UEコンテキストを確認し、新しい Registration Area(TAIリスト)を再割当、必要なら 5G-GUTI を再割当し、Registration Accept で応答する。
- AUSF(条件付き) — 再認証が必要な場合のみ、5G-AKA 等の認証処理に関与する(N12)。既存セキュリティコンテキスト再利用時は関与しない。
- UDM(条件付き) — 加入者情報の(再)取得やAMF登録更新が必要な場合のみ関与する(N8)。AMF変更時にも関与し得る。
- 旧AMF(AMF変更時のみ) — AMF再選択が起きた場合、新AMFがUEコンテキストを旧AMFから移送し得る(Rel・構成依存・概念のみ、細部は要確認)。
Interfaceの詳細は Interface辞典 を参照してください。
Network Function(登場NF)¶
Mobility Registration Update に登場するコア側NFの役割です。gNB は無線アクセス側であり、コアNFではありません(本表はコアNFに限定)。UDM / AUSF は条件付き(必要時のみ)です。
| NF | この手順での役割 | 保持/取得する情報 | この手順で使う主なAPI/手続き | 障害時の影響 |
|---|---|---|---|---|
| AMF | 登録更新の受付・処理主体。既存UEコンテキスト確認、新 Registration Area(TAIリスト)の再割当、5G-GUTI 再割当判断、Registration Accept 送出 | UEコンテキスト、5G-GUTI、セキュリティ鍵、在圏(TAI)、Registration Area(TAIリスト) | NGAP(Initial UE Message 受領 等, N2)/(条件付き)AUSF・UDM のサービスを消費 | 登録更新が処理されず、着信/位置更新に支障(更新漏れで Paging 不達等) |
| UDM(条件付き) | 加入者情報の(再)取得、AMF登録の更新(AMF変更時等)。必要時のみ関与 | 加入者データ、SUPI、UE↔AMF 対応 | Nudm_UECM_Registration / Nudm_SDM_Get(条件付き, N8) | (関与時)加入情報更新不可・AMF登録更新不可 |
| AUSF(条件付き) | 再認証が必要な場合のみ 5G-AKA 等の認証処理に関与 | KSEAF, KAUSF(再認証時) | Nausf_UEAuthentication(条件付き, N12) | (関与時)再認証が完了せず登録更新が進まない |
UDM / AUSF は条件付き
Mobility Registration Update では、既存のUEコンテキスト・セキュリティコンテキストを再利用できる場合、UDM / AUSF への照会は省略され得ます。関与するのは、再認証が必要・加入情報が変わった・AMFが変わった等の条件が成立したときのみです(状況依存、具体条件は要確認)。
Interface / Protocol¶
この手順で使うInterfaceとProtocolです。N8 / N12 は条件付き(再認証・加入情報照会・AMF登録更新が必要な場合のみ)です。
| Interface | Protocol | Transport | 相手 | この手順での用途 |
|---|---|---|---|---|
| N1 | NAS(5GMM) | (NGAP/N2上でトンネル) | UE ⇔ AMF | UE→AMF の Registration Request(type=mobility)、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 | 加入者データ(再)取得・AMF登録更新(必要時のみ、Nudm_*) |
| N12(条件付き) | SBI(HTTP/2, TLS, JSON) | TCP/TLS | AMF ⇔ AUSF | 再認証(必要時のみ、Nausf_UEAuthentication) |
N8 / N12 と SBI の表記について
3GPPアーキテクチャでは、AMF⇔UDM は N8、AMF⇔AUSF は N12 と呼ばれますが、実体は SBI(Service Based Interface, HTTP/2) 上の Nudm_ / Nausf_ サービスを介したやり取りです。ここでは「N8/N12(SBI)」と表記します。これらは Mobility Registration Update では条件付き(再認証・加入情報照会時のみ)で用いられ、常に発生するとは限りません。具体的オペレーション名・適用条件は TS 23.502 の該当手順で要確認です。
Protocolの詳細は Protocol辞典、Interface一覧は Interface辞典 を参照してください。
Procedure — Call Flow¶
このページの心臓部です。 Mobility 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) です(章番号の細部は要確認)。Initial Registration にある認証・加入者取得ステップが、本手続きでは条件付き/簡略化され得る点を強調します。
前提: UEは登録済み(5GMM-REGISTERED)で、有効な 5G-GUTI を保持
UEは 5GMM-REGISTERED で、直近の登録で得た 5G-GUTI とセキュリティコンテキストを保持しているとします。在圏TAが割当TAIリスト外になったことを検知して本手続きを起動します。Initial Registration の全体は Initial Registration を参照(重複は誘導)。
sequenceDiagram
autonumber
participant UE as UE (REGISTERED)
participant RAN as (R)AN / gNB
participant AMF
participant AUSF
participant UDM
Note over UE: 在圏TAが割当TAIリスト外 → 登録更新を起動
Note over UE,RAN: RRC接続確立/再開(無線側・概略/範囲外)
UE->>RAN: Registration Request (NAS)
type=mobility registration updating
Note right of UE: TS 24.501 §5.5.1。5GS registration type=mobility(要確認)
RAN->>AMF: Initial UE Message (NGAP) に NAS を載せる
Note right of RAN: N2 / TS 38.413。AMF selection を実施し得る
Note over AMF: 既存UEコンテキストを確認(5G-GUTI で解決)
opt AMF変更時(AMF再選択・Rel/構成依存・概念)
AMF->>AMF: 旧AMFからUEコンテキストを移送(要確認)
end
opt 条件付き: 再認証(状況依存)
AMF->>AUSF: Nausf_UEAuthentication(再認証, N12)
AMF->>UE: Authentication Request / Response(5G-AKA, 詳細は別章)
end
opt 条件付き: 加入情報照会/AMF登録更新(状況依存)
AMF->>UDM: Nudm_UECM_Registration / Nudm_SDM_Get(N8)
UDM-->>AMF: 加入者データ(必要時)
end
Note over AMF: 新しい Registration Area(TAIリスト)を決定
AMF->>UE: Registration Accept (NAS)
新TAIリスト / (必要なら)新5G-GUTI
Note right of AMF: TS 24.501 §5.5.1。registration result 等
opt 5G-GUTI 再割当時
UE->>AMF: Registration Complete (NAS)
Note right of UE: 新5G-GUTI 割当のACK 等
end
Note over UE,AMF: 5GMM-REGISTERED を維持したまま Registration Area 更新完了
ステップ解説(番号は上図に対応)¶
- UE→(R)AN: UEは在圏TAが割当TAIリスト外になったことを検知し、(無線側で)RRC接続を確立/再開し(概略/範囲外)、Registration Request(NAS) を Registration type = mobility registration updating で運ぶ。5GS mobile identity には有効な 5G-GUTI が入るのが典型(IE名・type 値は要確認)。参照: TS 24.501 §5.5.1(章番号要確認)。
- (R)AN→AMF: gNBは Initial UE Message(NGAP) に NAS を載せて AMF へ送る(N2 / TS 38.413)。同時に AMF selection を行い得る。
- AMFの判断(コンテキスト確認): AMFが 5G-GUTI から既存UEコンテキストを解決し、更新処理を開始する。Initial Registration と異なり、ここで既存のセキュリティ・加入情報を再利用できるのが基本。
- (条件付き・AMF変更時)コンテキスト移送: AMF再選択が起きた場合、新AMFがUEコンテキストを旧AMFから移送し得る(Rel・構成依存・概念のみ、細部は要確認)。
- (条件付き)再認証: 既存セキュリティコンテキストが再利用できない等の場合のみ、AMF→AUSF の再認証(5G-AKA、N12)を行う。省略され得る(状況依存、詳細は Security/Authentication 章の対象)。
- (条件付き)加入情報照会/AMF登録更新: 加入情報が変わった・AMFが変わった等の場合のみ、AMF→UDM(Nudm_UECM_Registration / Nudm_SDM_Get、N8)を行う。省略され得る(状況依存)。
- 新 Registration Area 決定: AMFが新しい Registration Area(TAIリスト)を決定する。UEの現在地をカバーするTA群を割り当てる。
- 受諾: AMF→UE Registration Accept(NAS) で、新TAIリストと(必要なら)新 5G-GUTI、registration result 等を通知する。
- (5G-GUTI 再割当時)完了: 新 5G-GUTI が割り当てられた場合等、UE→AMF Registration Complete(NAS) を返す。これは完了確認であり、UEは手続きを通じて 5GMM-REGISTERED を維持する(DEREGISTERED からの新規遷移ではない)。
条件分岐は状況・実装依存
再認証(ステップ5)、UDM照会(ステップ6)、AMF変更時のコンテキスト移送(ステップ4)、5G-GUTI 再割当(ステップ8-9)は、既存コンテキストの有効性・構成・オペレータポリシー・AMF変更の有無により省略・変化します。3GPP TS 23.502 §4.2.2系 は多くの任意/条件付きステップを含むため、具体的な省略条件は個別に仕様確認が必要です(詳細な分岐条件の一部は要確認)。とくに AMF再選択時のコンテキスト移送の細部は本章の範囲外とし、概念にとどめます。
参照: 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 = mobility registration updating、5GS mobile identity(5G-GUTI)、UE security capability、Requested NSSAI 等(type値・IE名要確認) | AMFが登録更新処理を開始 |
| Initial UE Message | NGAP | gNB→AMF | NAS(Registration Request)の運搬 | NAS-PDU、User Location(在圏TAI)等 | AMFがNASを受領 |
| Nausf_UEAuthentication(条件付き) | SBI(HTTP/2) | AMF→AUSF | 再認証(必要時のみ) | SUPI/認証関連(要確認) | (関与時)再認証を実施 |
| Nudm_UECM_Registration / Nudm_SDM_Get(条件付き) | SBI(HTTP/2) | AMF→UDM | AMF登録更新・加入情報照会(必要時のみ) | SUPI、AMF識別情報、Data Set Name 等 | (関与時)加入情報更新・AMF登録更新 |
| Registration Accept | NAS(5GMM) | AMF→UE | 登録更新受諾 | 新 TAI list(Registration Area)、(必要なら)5G-GUTI、registration result、allowed NSSAI 等(IE名要確認) | UEが新エリアで登録を認識 |
| Registration Complete | NAS(5GMM) | UE→AMF | 登録更新完了 | (5G-GUTI 再割当時のACK 等) | 手続きの完了確認 |
各Messageの詳細IE・参照Specは Message辞典 を参照してください。IE名・type値の一部は実装・版依存のため要確認としています。
State Machine¶
UE側の 5GMM 状態 の観点です。Mobility Registration Update は 5GMM-REGISTERED を維持したまま Registration Area を更新します(根拠: TS 24.501 §5.1.3 / §5.5.1系、章番号要確認)。Initial Registration が DEREGISTERED → REGISTERED へ遷移させるのとは異なり、本手続きは REGISTERED 内での更新である点が要点です。
stateDiagram-v2
[*] --> REGISTERED: Initial Registration 完了後
REGISTERED --> REGISTERED_UPDATE: Registration Request (type=mobility) 送信
REGISTERED_UPDATE --> REGISTERED: Registration Accept 受信(新TAIリスト適用)
REGISTERED_UPDATE --> DEREGISTERED: Registration Reject 受信 / 手続き失敗
REGISTERED --> DEREGISTERED: De-registration / 登録失効
DEREGISTERED --> [*]
- 5GMM-REGISTERED — 登録済み。Registration Area 内の移動では状態を変えない。エリア外へ出て登録更新を送ると更新の過渡状態へ。
- 5GMM-REGISTERED(更新中/過渡) — Registration Request(type=mobility)を送って応答待ちの過渡状態(上図では
REGISTERED_UPDATEとして図示)。Registration Accept で新TAIリストを適用して REGISTERED へ戻る。Registration Reject/手続き失敗時は DEREGISTERED へ遷移し得る。 - 5GMM-DEREGISTERED — 未登録。De-registration・登録失効・更新失敗(Reject)等で遷移し得る。
図中の状態名は説明用(過渡状態の表記)
上図の REGISTERED_UPDATE は「REGISTERED 内で登録更新に入り応答待ちの過渡状態」を説明するための表記です。3GPP の 5GMM 状態定義(TS 24.501 §5.1.3)は主に 5GMM-DEREGISTERED / 5GMM-REGISTERED / 5GMM-REGISTERED-INITIATED / 5GMM-DEREGISTERED-INITIATED 等で構成されます。mobility registration updating が具体的にどの下位状態を用いるかの厳密な対応は要確認とし、本図は概念図として提示します。CM状態(CM-IDLE / CM-CONNECTED)とは別軸であり、登録更新のためにUEは CM-CONNECTED になって手続きを行います(CM状態の詳細は Service Request 参照)。
Packet Analysis (Wireshark)¶
Mobility Registration Update を Wireshark で解析するときの要点です。コア側では NAS Registration Request/Accept が NGAP(Initial UE Message 等) にネストされて観測されます。
主要 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 — ここが mobility registration updating になっているのが本手続きの決め手(Initial Registration では initial registration)。値の符号は要確認。
- 5GS mobile identity — Mobility Registration Update では典型的に 5G-GUTI(初回登録の SUCI とは異なる)。
- Requested NSSAI / UE security capability — 要求スライスや対応アルゴリズム。
- NAS Registration Accept(AMF→UE) — 次のIEに注目。
- TAI list(新 Registration Area) — 再割当された新しいTAIリスト。本手続きの主眼。
- 5G-GUTI(再割当時)— 新しい一時ID(再割当される場合)。
- registration result 等。
暗号化に注意(Registration Accept 以降)
既存のNASセキュリティコンテキストが有効な場合、Registration Request 以降のNASは暗号化・完全性保護され得るため、Wireshark で平文の中身が見えないことがあります(正常)。これは Initial Registration の Security Mode 以降と同様です。解析はキー投入や実装のログと併用します。
メッセージのネスト構造(NGAP に NAS がネスト)¶
Registration Request の NAS は、NGAP メッセージ(Initial UE Message)の中に NAS-PDU として入ります(Initial Registration / Service Request と同じ入れ子構造)。パケット詳細ペインでは次のように階層表示されます(表記は概念、実際の名称はディセクタ依存=要確認)。
NGAP-PDU
└─ InitialUEMessage
└─ NAS-PDU
└─ 5GS NAS Message
└─ Registration Request(5GS registration type=mobility)
実際のpcapは環境依存(実装依存)
本ページのフィルタ・IE名は解析の指針です。実際のパケットは無線・コアの実装や設定に依存します。Open5GS や free5GC のテストベッドで、UEの在圏TAをTAIリスト外に変える(複数TA/gNB構成でUEを移動させる)と、N2区間の NAS Registration Request(type=mobility)/ Registration Accept を実際にキャプチャして学習できます。
Configuration¶
Mobility Registration Update を成立させるための設定の構造レベルの要点です。具体値・ベンダー固有(Cisco 等)は実装依存であり、ここでは架空の値を書きません。
Registration Area / TAI リスト設計(AMF 側)¶
- TAI / TAC(Tracking Area)— AMFがサービスするTAを定義。gNB の TA と一致している必要がある。複数TA/gNBが無いと、そもそもエリアをまたぐ移動(=Mobility Registration Update)を再現できない。
- Registration Area(TAIリスト)の割当方針 — UEへ割り当てるTAIリストの範囲。広くすると登録更新は減るがPaging範囲が広がり、狭くするとその逆(Basic Concept / Paging のトレードオフ)。具体的な割当アルゴリズムは実装依存。
- GUAMI / 5G-GUTI 割当 — AMFのGUAMIから 5G-GUTI が導かれる。再割当ポリシーは実装依存。
周期登録更新タイマ関連(対比)¶
- 周期登録更新タイマ(一般に T3512 と呼ばれる周期登録更新タイマが該当するとされる)— 周期的 Registration Update(本章対象外)の起動間隔に関わる。名称・値・設定キーは版・実装依存の面があり要確認。Open5GS / free5GC で設定可能な範囲・キー名は各実装のドキュメントで確認する。
具体値・ベンダー固有・タイマ名は実装依存/要確認
設定ファイルのキー名・階層・必須項目・タイマの具体値は、Open5GS / free5GC / 商用ベンダー(Cisco 等)で異なります。上記は構造レベルの要点であり、実際のキー名や値は各実装のドキュメントで確認してください(実装依存)。周期登録更新タイマの名称(T3512 等)と値は要確認とし、架空の設定値は本ページには記載しません(Timer辞典 参照)。
Trouble Shooting¶
代表的な Mobility Registration Update 失敗の切り分けです(一般論)。Cause値の詳細は Cause辞典 を参照してください。
| 症状 | 想定原因 | 確認ポイント | 関連ログ/Packet | 対処の方向性 |
|---|---|---|---|---|
| (a) 登録更新が拒否される(Registration Reject) | 既存コンテキスト不整合、5G-GUTI 解決不可、加入状態の問題 | AMFのUEコンテキスト、5G-GUTI マッピング、必要時の再認証 | NAS Registration Request/Reject、AMFログ | UEコンテキスト整合・再認証の要否、SUCI での再登録/AMF再選択を確認 |
| (b) TAIリスト不整合でエリアをまたいでも更新されない | UEの在圏TAがどのTAIリストにも整合しない/TAC設計ミス | gNBのTAC、AMFのTAI設定、割当TAIリスト | Registration Request の User Location、AMFログ | TAI/TAC設計の見直し、gNBとAMFのTA整合を確認 |
| (c) 更新漏れで Paging が届かない | UEが割当TAIリスト外に移動したのに登録更新が発火/成功していない | 直近の Mobility Registration Update の成否、在圏TAとTAIリスト整合 | NGAP Paging(Paging)、Registration ログ | 登録更新の発火条件、TAIリスト設計、Paging 範囲を確認 |
| (d) AMF変更時にコンテキストが引き継がれない | AMF再選択時の旧AMF→新AMF コンテキスト移送失敗(構成依存) | AMF間の疎通・構成、UEコンテキスト移送手続き | AMFログ、(該当時)AMF間シグナリング | AMF構成・移送手続きを確認(細部は要確認・Rel/構成依存) |
EPCとの比較¶
4G(EPC) 経験者が 5G へ橋渡しできるよう対比します。「エリアをまたいだら位置を届け出て、追跡エリアを更新する」という基本思想は4Gと5Gで共通です。4Gの TAU(Tracking Area Update) が、5Gの Mobility Registration Update に対応します。
| 観点 | 4G / EPC | 5G / 5GC |
|---|---|---|
| エリア更新手続き | TAU(Tracking Area Update) | Mobility Registration Update |
| 手続きメッセージ | TAU Request / TAU Accept | Registration Request(type=mobility)/ Registration Accept |
| 制御NF | MME | AMF |
| 無線ノード制御 | S1AP(TS 36.413) | NGAP(TS 38.413) |
| 追跡エリア | TAI List(Tracking Area) | TAI List(Registration Area) |
| 一時ID | GUTI(再割当あり) | 5G-GUTI(再割当あり) |
| 登録/接続状態 | EMM-REGISTERED を維持 | 5GMM-REGISTERED を維持 |
TAU ↔ Mobility Registration Update の対応
4Gでは、UEが割当TAIリスト外へ移動すると TAU(Tracking Area Update) を MME へ送り、新しい TAI List を取得しました。5Gでは、同じ役割を Mobility Registration Update が担い、AMF が新しい Registration Area(TAIリスト)を再割当します。MME ↔ AMF、TAU ↔ Mobility Registration Update、そして TAI List という追跡エリアの考え方は共通です。5Gでは登録手続きが Registration type で区別され、TAU相当が "mobility registration updating" という type で表現される点が構造上の違いです。
Release差分¶
Mobility Registration Update 関連の主なトピックです。不確かなものは要確認とし、断定しません。
- Rel-15 — 5GC の基本 Registration 手順(initial / mobility / periodic / emergency の Registration type、Registration Area、5G-GUTI 再割当)の基礎が確立。本章はこの Rel-15 基礎の範囲。
- RRC Inactive / RAN Notification Area(RNA) — Rel-15 で導入されたUE状態。UEが RRC_INACTIVE のとき、無線側では RAN Notification Area(RNA) の更新(RNA Update)という別レイヤの手続きがある。これはコア(AMF)起点の登録更新(Registration Area 更新)とは別の概念であり、本章のスコープ外(概念のみ、詳細は要確認)。
- 登録最適化・省シグナリング拡張 — 各Releaseで登録関連の最適化が継続。Mobility Registration Update 手続き自体への具体的な織り込み範囲は要確認。
- Rel-16 / Rel-17 / Rel-18(5G-Advanced) — スライス・省電力等の拡張が進んだ世代。登録更新手続き本体への具体差分は要確認。
Release差分は要確認
各Releaseで「登録更新手続き自体」にどの機能がどこまで織り込まれたかは、対象TSの版差分を個別に確認する必要があります。特に RRC Inactive の RNA Update と、コア起点の Registration Area 更新(本章) の区別に注意してください。上記は概観であり、具体項目は要確認です。
3GPP Specification¶
| Spec | 章 | 内容 |
|---|---|---|
| TS 23.502 | §4.2.2.2系 | Registration procedures(Mobility Registration Update を含む。細目章番号は要確認) |
| TS 23.501 | §5.3系 | 登録管理(RM)・Registration Area・移動性管理(章番号要確認) |
| TS 24.501 | §5.5.1系 | NAS 側 Registration procedure(Registration type / mobility registration updating 等。章番号要確認) |
| TS 24.501 | §5.1.3 | 5GMM 状態(状態遷移の根拠) |
| TS 38.413 | (NGAP各章) | NGAP(Initial UE Message 等。個別章番号要確認) |
| TS 29.503 | — | Nudm(UDMのサービスAPI、条件付き) |
| TS 29.509 | — | Nausf(AUSFのサービスAPI、条件付き) |
| 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 状態)/ TS 23.501 §5.3系(RM・Registration Area)は本章の骨格として参照しています。ただし細かな章番号(Mobility Registration Update の枝番)は版により異なる場合があり、一部は要確認としています。TS 38.413 の NGAP 個別章番号、各IE名(5GS registration type / TAI list 等)、および 5GS registration type の符号値も要確認です。
FAQ¶
Q1. Initial Registration と Mobility Registration Update は何が違うのか?
前提状態と目的が違います。Initial Registration は 5GMM-DEREGISTERED(未登録)のUEがはじめて登録する手続きで、本人確認(5G-AKA 認証)・加入者情報取得をフルに行います。Mobility Registration Update は既に 5GMM-REGISTERED のUEが Registration Area(TAIリスト)の外へ移動したときの更新で、既存のUEコンテキスト・セキュリティコンテキストを再利用できる分、認証やUDM照会が簡略化・省略され得ます(条件付き)。主眼は新しい Registration Area の再割当と位置情報の更新です。
Q2. Periodic Registration Update とは何が違うのか?
起動の契機が違います。Mobility(本章)は「場所が変わった(在圏TAが割当TAIリスト外になった)」ことが契機です。一方 Periodic Registration Update は「時間が経った(周期タイマ満了)」ことが契機で、UEが移動していなくても定期的に「まだ生きています」と生存確認的に更新します。手続きの骨格は共通部分が多いですが、Registration type と起動条件が異なります。Periodic の詳細は Periodic Registration Update 章 を参照してください。周期タイマ(一般に T3512 とされる)の名称・値は要確認です。
Q3. Service Request とどう使い分けるのか?
目的が異なります。Service Request は、CM-IDLE のUEが通信を再開するために、シグナリング接続と PDU Session のユーザプレーン(N3)を再確立する手続きです(データの通り道を張り直す)。Mobility Registration Update は、UEが Registration Area の外へ移動したときに、登録情報・位置(Registration Area/TAIリスト)を更新する手続きです(住所変更の届け出)。前者は「接続・U-Planeの再確立」、後者は「登録情報・位置の更新」が主眼で、目的が違います。
Q4. 4G の TAU と同じものか?
役割は対応します。4Gの TAU(Tracking Area Update) は、UEが割当TAIリスト外へ移動したときに MME へ位置更新を届け出て新しい TAI List を得る手続きでした。5Gの Mobility Registration Update は、同じ役割を AMF に対して果たします。MME↔AMF、TAU↔Mobility Registration Update、TAI List という追跡エリアの考え方は共通です。5Gでは登録手続きが Registration type で区別され、TAU相当が "mobility registration updating" という type で表現される点が構造上の違いです(EPCとの比較 参照)。
Q5. Mobility Registration Update で 5G-GUTI は必ず再割当されるのか?
必ずではありません。5G-GUTI の再割当は Registration Accept で行われ得ますが、常に再割当されるとは限らず、オペレータポリシー・実装・AMF変更の有無などに依存します(状況・実装依存、条件は要確認)。再割当された場合、UEは Registration Complete で確認を返し得ます。
Q6. 登録更新でUEの 5GMM 状態は変わるのか?
基本的に 5GMM-REGISTERED を維持します。Mobility Registration Update は「REGISTERED 内での Registration Area の更新」であり、Initial Registration のように DEREGISTERED → REGISTERED へ新規遷移するわけではありません。ただし手続きが失敗(Registration Reject 等)した場合は DEREGISTERED へ遷移し得ます(State Machine 参照)。
Summary¶
- Mobility Registration Update は、UEが Registration Area(TAIリスト)の外へ移動したときに、登録情報・位置を更新する手続き。4GのTAU(Tracking Area Update)に相当する。
- トリガは「在圏TAが割当済みTAIリストに含まれないエリアへの移動」。UEが Registration Request(type=mobility registration updating) を AMF へ送る。
- 主役は AMF(既存UEコンテキスト確認・新 Registration Area(TAIリスト)の再割当・Registration Accept 送出)。UDM / AUSF は条件付き(再認証・加入情報照会が必要な場合のみ)。
- Initial Registration との差分が要点。既存コンテキストを再利用でき、認証・加入者取得が簡略化・省略され得る(条件付き)。5GMM-REGISTERED を維持したままエリアを更新する。
- 5G-GUTI 再割当は行われ得るが必須ではない(状況・実装依存)。AMF変更時のコンテキスト移送は Rel・構成依存で概念のみ(要確認)。
- Service Request(U-Plane再確立)や Paging(着信呼び出し)とは目的が異なる。Mobility Registration Update は「登録情報・位置の更新」。
- 根拠は TS 23.502 §4.2.2.2系 / TS 24.501 §5.5.1系・§5.1.3 / TS 23.501 §5.3系 / TS 38.413(章番号・IE名・registration type 値の一部は要確認)。
Practice — 理解度チェック・演習¶
理解度チェック¶
Q1. Mobility Registration Update のトリガは何か?(解答)
UEの在圏TAが、割り当てられているTAIリスト(Registration Area)に含まれないエリアへ移動したこと。UEはこれを検知して登録更新を起動する。
Q2. Registration Request の 5GS registration type には何が入るか?(解答)
mobility registration updating(本手続きの決め手)。Initial Registration では initial registration。値の符号は要確認。
Q3. Mobility Registration Update で AMF が主に再割当するものは何か?(解答)
新しい Registration Area(TAIリスト)。必要なら 5G-GUTI も再割当され得る。
Q4. Initial Registration と比べて、Mobility Registration Update で省略され得るのは何か?(解答)
本人確認(認証, 5G-AKA)と加入者情報取得(UDM照会)。既存のUEコンテキスト・セキュリティコンテキストを再利用できる場合、これらは条件付きで省略され得る(状況依存)。
Q5. 4G で Mobility Registration Update に相当する手続きと、その制御NFは?(解答)
4Gの TAU(Tracking Area Update)、制御NFは MME。5Gでは Mobility Registration Update を AMF が担う。
演習¶
問: 次の Mobility Registration Update 主要ステップを正しい順に並べ替えてください。
A. AMF が新しい Registration Area(TAIリスト)を決定
B. UE → gNB: Registration Request(NAS, type=mobility)(RRC確立後)
C. AMF → UE: Registration Accept(新TAIリスト /(必要なら)新5G-GUTI)
D. gNB → AMF: Initial UE Message(NGAP) で NAS を運搬
E. AMF が 5G-GUTI から既存UEコンテキストを確認
F.(条件付き)AMF が再認証(N12)/UDM照会(N8) を実施
G.(5G-GUTI 再割当時)UE → AMF: Registration Complete(NAS)
解答
B → D → E → F → A → C → G
- B: UEが Registration Request(type=mobility、RRC確立は無線側・概略)
- D: gNB→AMF Initial UE Message で NAS 運搬(N2)
- E: AMFが 5G-GUTI から既存UEコンテキストを確認
- F: (条件付き)再認証・UDM照会(必要時のみ・状況依存)
- A: AMFが新 Registration Area(TAIリスト)を決定
- C: AMF→UE Registration Accept(新TAIリスト /(必要なら)新5G-GUTI)
- G: (5G-GUTI 再割当時)UE→AMF Registration Complete
※ F と G は条件により省略される(状況・実装依存)。AMF変更時は E の後にコンテキスト移送が入り得る(Rel/構成依存・概念)。
Next Step¶
理解を深めるための次の一歩です。
- 手続きの前提: Initial Registration(登録の全体像・認証・セキュリティ)
- 直接の関連: Paging(Registration Area の上流概念。更新漏れは Paging 不達につながる)
- 対比の関連: Service Request(U-Plane再確立。目的が異なる姉妹手順)
- 姉妹手順: Handover(移動中の接続切替)
- Periodic Registration Update 章(周期的な登録更新=別の Registration type。契機は時間=周期タイマ満了)
- 関連NF: AMF / UDM / AUSF
- 関連Interface: N1 / N2
- 辞典: Message辞典 / Timer辞典 / Cause辞典 / Protocol辞典 / NF辞典 / Interface辞典