Tracking Area / TAI / Registration Area — 5GCはUEの「居場所」をどう管理するのか¶

学習目標¶

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

• TAC と TAI の違い（TAI = PLMN ID + TAC）を形式レベルで説明できる
• UEとAMFが、それぞれ どの経路でTAを知るか（SIB1 / NG Setup / User Location Information）を説明できる
• Registration Area（TAI List） の意味と、Registration Area 内の移動では Mobility Registration Update が必ずしも必要ではない理由を説明できる
• 5GS registration type（Initial / Mobility / Periodic 等）を見分け、Traceで「なぜこのRegistrationが来たか」を推定できる
• Registration Area の大きさが Registration Update の頻度と Paging 負荷のTrade-off になることを説明できる
• UE側の Forbidden TA リスト と網側の Forbidden Area（Mobility Restriction） を区別し、TAI List・T3512・TAC設定の不整合をTraceから切り分けられる

前提知識¶

• NG Setup Procedure — gNBが Supported TA List でAMFへTAを申告する
• Registration — Registration Request / Accept の基本
• 補助: Paging / Mobility Registration Update / Periodic Registration Update / RRC Resume

IP Reachability
      ↓
SCTP Association
      ↓
NG Setup              ← Supported TA List（gNBが担当するTA）
      ↓
UE-associated NGAP    ← Initial UE Message の User Location Information（UEが今いるTAI）
      ↓
Registration (NAS)    ← Registration Accept の TAI List（AMFが割り当てたRegistration Area）

Why — なぜCell単位で位置を管理しないのか¶

AMFがUEの位置を常に Cell単位 で把握しようとすると、UEはCellを移るたびにネットワークへ報告しなければなりません。待受中（CM-IDLE）のUEにとって、これは電池と無線リソースの浪費です。

逆に、AMFがUEの位置を まったく 知らなければ、着信（Downlink Data / 音声着信）時に網全体へPagingする必要があり、Paging負荷が膨大になります。

そこで5GSは、複数Cellを束ねた Tracking Area（TA） と、さらに複数TAを束ねた Registration Area という粗い単位で、CM-IDLE UEの位置を管理します（TS 23.501 Clause 5.3.2.3）。

例え話: Registration Area は「配達員に伝えておく担当エリア」です。UEは「この区内のどこかにいます」とだけ伝えておき、区内を移動するたびに連絡はしません。荷物（着信）が来たら、配達員は区内を呼び回ります（Paging）。区外へ出たときだけ、UEは新しい担当エリアを届け出ます（Mobility Registration Update）。

What — TA / TAC / TAI / Registration Area¶

Tracking Area¶

Tracking Area は、CM-IDLE UEの位置を管理するための Cellの集合 です。1つのCellは（PLMNごとに）1つのTAに属するのが基本です（NTNの例外は後述）。

             Tracking Area (TAC = 0x000064)
 ┌──────────────────────────────────────┐
 │  Cell A   Cell B   Cell C            │
 │  Cell D   Cell E   Cell F            │
 └──────────────────────────────────────┘

TAC と TAI — 同じものではない¶

TAI
├─ PLMN ID
│   ├─ MCC   (3桁)
│   └─ MNC   (2〜3桁)
└─ TAC       (24 bit)

TACだけではPLMNをまたいだ一意性がありません。網間・ローミングを含めてTAを一意に識別するのはTAI です。Traceで「TAC=100」とだけ書かれていたら、どのPLMNのTAC 100なのかを必ず確認します。

UEはTAをどう知るか — SIB1¶

UEは、gNBがBroadcastする SIB1 の中の PLMN-IdentityInfo（PLMN ID のリストと trackingAreaCode）から、そのCellのPLMNとTACを知ります（TS 38.331 Clause 6.2.2 / Clause 6.3.2、要確認）。

gNB ──(SIB1: PLMN-IdentityInfoList)──► UE
          ├─ PLMN-Identity: 440-11
          └─ trackingAreaCode: 0x000064

UEは、在圏Cellの TAI を、自分が保持している TAI List と照合し、Registration Area の内側にいるかを判断します。

AMFはTAをどう知るか — 2つの経路¶

User Location Information (CHOICE)                      … TS 38.413 Clause 9.3.1.16（要確認）
├─ User Location Information E-UTRA   (ng-eNB 配下)
├─ User Location Information NR       (gNB 配下)
│   ├─ NR CGI   (M)  PLMN + NR Cell Identity 36 bit
│   ├─ TAI      (M)  PLMN + TAC
│   └─ Age of Location（Time Stamp）等  (O)
└─ User Location Information N3IWF    (Non-3GPP access。IPアドレス・ポート)

• User Location Information は CHOICE型 で、アクセス種別ごとに中身が異なります。NR の場合、NR CGI と TAI の2つが必須、それ以外（位置の鮮度を示す Age of Location、Rel-16以降の PSCell Information / NID 等）は任意です。Rel-16以降は TNGF / TWIF / W-AGF 向けの選択肢も追加されています（各IEのpresenceと追加Releaseは TS 38.413 Clause 9.3.1.16 で要確認）。
• Initial UE Message では User Location Information は 必須IE です（TS 38.413 Clause 9.2.5.1、要確認）。つまり UEの最初のNASメッセージを受けた時点で、AMFはUEの在圏TAIを知っています。Uplink NAS Transport 等のUE-associatedメッセージでも都度最新の値が届きます。
• CM-CONNECTED 中にCell / TAの変化を継続的に知りたい場合、AMFはNG-RANへ Location Reporting Control を送り、Location Report で報告させることができます（TS 23.502 Clause 4.10 / TS 38.413 Clause 8.12、枝番は要確認）。報告イベントの種類（直ちに報告、在圏Cellの変化時 等）は NGAP の Location Reporting Request Type で規定されています（TS 38.413 Clause 9.3.1.65、要確認）。どの場面で報告を要求するかは、他NF（SMF / PCF 等）からの要求と、AMFの実装・運用によります（TS 23.502 Clause 4.10）。

Registration Area と TAI List¶

AMFは、UEに対して 1つ以上のTAからなるRegistration Area を割り当て、そのTAIの集合を TAI List としてNASでUEへ通知します（TS 23.501 Clause 5.3.2.3）。

Registration Area（UE-1 に割り当て）
┌────────┐ ┌────────┐ ┌────────┐
│ TA 100 │ │ TA 101 │ │ TA 102 │
└────────┘ └────────┘ └────────┘
          ↓ NASで通知
TAI List = { 440-11/100, 440-11/101, 440-11/102 }

• Registration Area は UEごと に割り当てられます。同じCellにいる2台のUEが異なるTAI Listを持つこともあります。AMFは割り当て時に、UEの移動パターン（Mobility Pattern）や Allowed / Non-Allowed Area 等を考慮できます（TS 23.501 Clause 5.3.2.3）。どう使うかは AMF実装・運用依存 です。
• Non-3GPP access の場合、Registration Area は予約された単一の N3GPP TAI になります（TS 23.501 Clause 5.3.2.3、要確認）。

NAS上の表現 — 5GS tracking area identity list IE¶

TAI List は、Registration Accept などに含まれる 5GS tracking area identity list IE で運ばれます（TS 24.501 Clause 8.2.7 / Clause 9.11.3.9）。IE内部は「部分リスト（partial tracking area identity list）」の並びで、各部分リストの先頭オクテットにある Type of list（bit 7–6）によって、続く内容の形式が決まります（TS 24.501 Clause 9.11.3.9）。

部分リストの先頭オクテット
 bit:   8      7   6        5   4   3   2   1
      ┌─────┬──────────┬─────────────────────┐
      │spare│Type of   │ Number of elements  │
      │     │list      │ （N−1 で符号化）    │
      └─────┴──────────┴─────────────────────┘

• Number of elements は「要素数 − 1」で符号化 されます（00000 = 1個 … 01111 = 16個）。Wiresharkの表示が符号化値なのか要素数なのかは版依存なので、生のビットと見比べます（範囲外の値の扱いを含め TS 24.501 Clause 9.11.3.9 で要確認）。
• 1つのIEに 複数の部分リストを並べられます（例: PLMN Aの連番TAC + PLMN Bの単独TAI）。ただしIE全体で含められるTAIは 最大16個 です（TS 24.501 Clause 9.11.3.9）。IE長は最小9オクテット・最大114オクテットです（TS 24.501 Clause 9.11.3.9、要確認）。
• 5GSではTACが 3オクテット（EPSは2オクテット）なので、EPSの TAI list IE（TS 24.301 Clause 9.9.3.33）とバイト列が同じにはなりません。
• 11 を含む上記以外の Type of list 値の扱いや、SNPN（Rel-16以降）に伴うReleaseごとの記述差は要確認です。

UE側は、Registration Request に Last visited registered TAI（TS 24.501 Clause 8.2.6 / Clause 9.11.3.8）を含めることがあり、AMFはこれで「UEが最後に登録していたTA」を知ることができます。ただしこのIEは cleartext IE ではない ため、有効なNASセキュリティコンテキストがある場合は NAS message container の中で暗号化されて運ばれます（TS 24.501 Clause 4.4.6、要確認）。

How — 位置管理はどう動くか¶

CM状態ごとの位置の粒度¶

RRC_INACTIVE の詳細は RRC Resume / Small Data を参照してください。

CM-IDLE UEへのDownlink — PagingはRegistration Areaの中で¶

CM-IDLE UEにはN2/N3の接続がないため、Downlink Dataをそのまま届けられません。AMFは、UEのRegistration Area に含まれるTAを担当するgNBへ Paging を送ります（TS 23.502 Clause 4.2.3.3）。

sequenceDiagram
    participant DN as Internet
    participant UPF
    participant SMF
    participant AMF
    participant gNB
    participant UE
    DN->>UPF: Downlink Data
    UPF->>SMF: Data Notification（N4）
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer
    Note over AMF: UEはCM-IDLE → Registration Area内のTAを担当するgNBを選ぶ
    AMF->>gNB: NGAP Paging（TAI List for Paging）
    gNB->>UE: RRC Paging
    UE->>AMF: Service Request（NAS）
    Note over UE,AMF: CM-CONNECTED → User Planeを再確立

• NGAP Paging には TAI List for Paging（必須IE）が入り、gNBはそのTAに属する自Cellで無線Pagingを行います（TS 38.413 Clause 8.5.1 / Clause 9.2.4.1、要確認）。
• AMFが「どのgNBへPagingを送るか」を決められるのは、NG Setup の Supported TA List でgNB⇔TAの対応を覚えているからです（前章）。
• 「最後にいたCell・TAから先にPagingし、応答がなければ範囲を広げる」といった Paging戦略 は、オペレータ設定・AMF実装に依存します（TS 23.501 Clause 5.4.3、要確認）。

詳細は Paging / Service Request を参照してください。CM-IDLE → CM-CONNECTED の遷移と Service Request のIEは、次章（CM-IDLE / CM-CONNECTED と Service Request）で掘り下げます。

Registration Area外へ出たら — Mobility Registration Updating¶

UEは、TAI Listに含まれないTAに入ったこと を検出すると、Registration type = mobility registration updating の Registration Request を送ります（TS 24.501 Clause 5.5.1.3.2）。

TAI List = {100, 101, 102}

TA100 → TA101 → TA102 → TA200
  (内)    (内)    (内)    (外) ← ここで Mobility Registration Update

手順の全体は Mobility Registration Update を参照してください。

同じRegistration Area内でも — Periodic Registration Updating¶

Registration Area 内にとどまっていても、UEは T3512（periodic registration update timer）が満了すると、Registration type = periodic registration updating の Registration Request を送ります（TS 24.501 Clause 5.3.7 / Clause 5.5.1.3.2）。

Registration Accept（T3512 value を通知し得る）
   ↓ NAS信号接続の解放（5GMM-CONNECTED → 5GMM-IDLE）で T3512 開始
   ↓ 5GMM-IDLE のまま満了
Periodic Registration Update
   （途中で 5GMM-CONNECTED に入れば T3512 は停止し、次に IDLE へ戻ったとき初期値から再開）

• T3512 の開始・停止条件は TS 24.501 Clause 5.3.7 にあります。要点は「5GMM-IDLE の間だけ時を刻む」ことで、CM-CONNECTED（RRC_INACTIVE を含む）に長く留まるUEはその間 Periodic Registration Update を送りません（RRC_INACTIVE 中の扱いの細部は要確認）。
• T3512 value IE は GPRS timer 3 形式（TS 24.501 Clause 9.11.2.5 → TS 24.008 Clause 10.5.7.4a、要確認）で、「単位 + 値」で表されます。単位には deactivated（タイマ無効） を示す値もあり、この場合UEはPeriodic Registration Updateを行いません（TS 24.501 Clause 5.3.7、要確認）。
• AMFがT3512 valueを含めなかった場合のUE動作、MICO mode 等でのT3512の扱いは TS 24.501 Clause 5.3.7 / Clause 5.3.6（MICO mode）で要確認です。運用で使う値（何分にするか）は オペレータ設定・AMF実装依存 です。
• AMF側では、Periodic Registration Update が来ないまま Mobile reachable timer → Implicit De-registration timer が満了すると、AMFはUEを暗黙的に登録解除します（TS 24.501 Clause 5.3.7、要確認）。

Periodic Registration Update は、「UEがまだ圏内にいて登録が生きていること」をAMFに知らせる生存確認です。詳細は Periodic Registration Update を参照してください。

5GS registration type — Traceで最初に見るIE¶

Registration Request を見たら、まず 5GS registration type を確認します（TS 24.501 Clause 9.11.3.7）。

Rel-17以降は SNPN onboarding registration 等の値も追加されています（要確認）。同じIEに Follow-on request pending（FOR） ビットも含まれ、登録後もNAS信号接続を維持したいかどうかを示します。

「Registration Requestが来た」だけでは情報が足りません。Initial なのか、Mobility なのか、Periodic なのか で、疑うべき原因がまったく変わります。

Forbidden Tracking Area と Mobility Restriction¶

UEには、利用すべきでないTAを覚えておくリストがあります（TS 24.501 Clause 5.3.13）。

causeごとのUE動作の正確な記述（5GMM状態・カウンタ・リストへの追加条件等）は、TS 24.501 Clause 5.5.1.2.5（Initial）/ Clause 5.5.1.3.5（Mobility・Periodic）の各cause記述を参照してください（要確認）。

Forbidden TA リストには「一度入るとしばらく残る」という運用上重要な性質があります（TS 24.501 Clause 5.3.13、TAI List受信時の削除は Clause 5.5.1.2.4 / Clause 5.5.1.3.4。いずれも要確認）。

• リストは 電源OFF、USIMの取り外し時、および周期的（12〜24時間の範囲） に消去される
• Registration Accept の TAI List にそのTAIが含まれて受信された場合、そのTAIはリストから削除される
• このため、網側の設定ミスで #12 / #13 / #15 を返してしまうと、設定を直した後も、すでにリストに入れたUEはしばらくそのTAで通常登録を試みない ことがある

網側では、加入者情報に基づく Mobility Restriction（RAT Restriction、Forbidden Area、Service Area Restriction（Allowed Area / Non-Allowed Area）等）が適用されます。このうち Forbidden Area と Service Area Restriction はTA単位 で表現されます（TS 23.501 Clause 5.3.4.1）。UE側での Service Area Restriction の扱いは TS 24.501 Clause 5.3.5 を参照してください（要確認）。

Traceで「Forbidden」という語を見たら、UE側のリストの話か、網側のMobility Restrictionの話か をまず区別します。

Registration Area の設計 Trade-off¶

Registration Area の大きさ自体は、3GPPが値を決めていない 設計パラメータ です（割り当て方は AMF実装・運用依存。ただしTAI List内のTAI数の上限はIE形式で決まります）。

flowchart LR
    S["Registration Area 小
（TAIが少ない）"] --> S1["Mobility Registration Update ↑
（UE電池・NAS信号が増える）"]
    S --> S2["Paging範囲 ↓
（1回の着信で呼ぶgNBが少ない）"]
    L["Registration Area 大
（TAIが多い）"] --> L1["Mobility Registration Update ↓"]
    L --> L2["Paging範囲 ↑
（無線・N2のPaging負荷が増える）"]

TA境界の置き方（例: 高速道路・鉄道沿いで境界を多数またがない）や、UEごとにTAI Listを変える工夫も、オペレータ設計・実装依存の領域です。

Packet Analysis (Wireshark)¶

Display Filter¶

個々のフィールド名（例: registration type、TAC）はWiresharkの版によって異なるため、本ページでは断定しません（要確認）。パケット詳細でフィールドを右クリックし「フィルタとして適用」するのが確実です。なお、NASが暗号化されている区間は、復号できなければ中身は見えません。

見るポイント¶

① NG Setup Request
   └─ Supported TA List          ← gNBが担当するTA（TAC + PLMN + S-NSSAI）

② Initial UE Message
   └─ User Location Information
      └─ NR CGI / TAI            ← UEが実際にいる場所

③ Registration Request（NAS）
   ├─ 5GS registration type      ← Initial / Mobility / Periodic（cleartext IE）
   └─ Last visited registered TAI（任意・非cleartext IE。復号が必要な場合あり）

④ Registration Accept / Reject（NAS）
   ├─ 5GS tracking area identity list  ← AMFが割り当てたRegistration Area
   ├─ T3512 value（任意）
   └─ 5GMM cause（Rejectの場合）

Decode例（概念表現）¶

以下は表示構造の概念表現で、値はテスト用PLMN（001-01）の架空例です（実キャプチャではありません）。NAS復号済みの表示 を想定しています。5GS registration type は cleartext IE ですが、Last visited registered TAI は非cleartext IE です。有効なNASセキュリティコンテキストがある場合は NAS message container 内で暗号化されて運ばれ、復号しないと見えません。有効なコンテキストが無い場合は、最初の Registration Request には cleartext IE のみを含め、完全なメッセージはNASセキュリティ確立後に Security Mode Complete の NAS message container で送られます（TS 24.501 Clause 4.4.6、要確認）。実表示では、完全な Registration request は NAS message container の中に入れ子で見えます。

NGAP InitialUEMessage
 ├─ RAN-UE-NGAP-ID: 1
 ├─ NAS-PDU
 │   └─ Registration request
 │       ├─ 5GS registration type: mobility registration updating (2)
 │       └─ NAS message container（復号後）
 │           └─ Registration request（完全版）
 │               └─ Last visited registered TAI: 001-01, TAC 0x000064
 └─ UserLocationInformation
     └─ userLocationInformationNR
         ├─ nR-CGI: 001-01, NR Cell Identity 0x000000010
         └─ tAI: 001-01, TAC 0x0000c8

NAS Registration accept
 └─ 5GS tracking area identity list
     └─ Partial TAI list: type = 01 (consecutive)
         ├─ PLMN: 001-01
         ├─ TAC: 0x0000c8
         └─ Number of elements: 3   → TAC 200, 201, 202（ビット上の符号化値は N−1 = 2）

比較表を作る¶

TAが絡む問題は、4か所の値を並べる と原因箇所が見えやすくなります。

この例では、RAN側は一貫してTAC 1131なのに、AMFはTAC 1132で設定されています。これがNG Setupで拒否されるか、受け入れた上でRegistrationやPagingで問題になるかは AMF実装・設定依存 です（前章参照）。

比較表を作るときの落とし穴:

• 10進と16進の取り違え: 設定画面やCLIでのTACの表記（10進か16進か）は 製品依存 です。TAC「1131」が10進なら 0x00046B、16進の 0x1131 なら10進 4401 で、別のTAです。Trace上の値（24 bit）に揃えてから比較します。
• MNCの桁数: MNC 2桁の「440-11」と3桁の「440-011」は 別のPLMN です（TS 23.003 Clause 2.2 / Clause 12.1、要確認）。設定やログの表記がどちらなのかを確認します。
• Registration Request の Last visited registered TAI は「今いる場所」ではない: これはUEが 最後に登録していたTA で、Mobility Registration Update では新しいTAとは異なるのが普通です。「UEが今いるTAI」は NGAP の User Location Information で確認します（Last visited registered TAI は非cleartext IEなので、復号が必要な場合もあります）。

Trouble Shooting¶

NTN（衛星アクセス）でのTracking Area¶

衛星アクセス（NR NTN、Rel-17以降）では、衛星の移動に伴ってCellが地上を移動する場合があり、Tracking Area の扱いが地上網より複雑になります。たとえば、1つのCellがPLMNごとに 複数のTACをBroadcastし得る などの拡張があります（TS 38.300 Clause 16.14、TS 23.501 Clause 5.4.11、枝番は要確認）。本章では詳細に立ち入らず、「地上網の前提（1セル = 1TA）がそのまま当てはまらない」ことだけを押さえておきます。

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

EPC（4G）との比較¶

5GでもTA・TAI Listの考え方はEPSとほぼ同じです。大きな違いは、TAU が Registration 手続きの一種（Registration type）に統合された 点と、TACが24 bitに拡張された点です。

3GPP Specification¶

Summary¶

TAC（Tracking Area Code, 24 bit）
   + PLMN ID（MCC + MNC）
   ↓
TAI（Tracking Area Identity）

TAI #1 ─┐
TAI #2 ─┼──► TAI List = Registration Area（UEごと・最大16 TAI）
TAI #3 ─┘

• TAC はPLMN内のTA番号（5GSは24 bit）、TAI = PLMN ID + TAC。両者は同じではない
• UEは SIB1 でTAを知り、AMFは Supported TA List（gNB単位）と User Location Information（UE単位）でTAを知る
• AMFはUEごとに Registration Area（TAI List） を割り当てる。CM-IDLE UEについてAMFが在圏を保証できるのは Registration Area 単位（最後に報告されたTAI・Cellは参考情報として保持し得る）
• TAI List 外 へ出たら Mobility Registration Updating。Registration Area内のTA移動だけでは不要。ただし他のトリガーもある
• Registration Area内にいても T3512 満了で Periodic Registration Updating。T3512は5GMM-IDLEの間だけ動き、deactivated も通知できる
• Forbidden TA リスト（UE側。#12 / #13 / #15 で追加され、しばらく残る）と、網側の Forbidden Area（Mobility Restriction）は別物
• Registration Area の大きさは Registration Update頻度とPaging負荷のTrade-off（設計は実装・運用依存）
• Traceでは Supported TA List → User Location Information → TAI List / Cause を突き合わせ、Registration Request では registration type を最初に見る

理解度チェック¶

Next Step¶

• 次章: Paging で起こされたUEがどう CM-CONNECTED に戻るか → CM-IDLE / CM-CONNECTED と Service Request
• TAを申告するN2の握手 → NG Setup Procedure
• TAI List 外への移動で起きる手続き → Mobility Registration Update
• T3512 による周期登録 → Periodic Registration Update
• CM-IDLE UEへの着信 → Paging / Service Request
• RRC_INACTIVE と RAN Notification Area → RRC Resume / Small Data
• NAS / NGAP のメッセージ・IE → NAS辞典 / NGAP辞典
• T3512 等のタイマ → Timer辞典 ／ 5GMM cause 全般 → Cause辞典