<!-- title: 5G初始注册完整信令流拆解 -->
<!-- domain: protocols -->

# 5G初始注册完整信令流拆解：从RRC到NAS的20步全链路解析

## 一、引言：为什么Registration是5G协议栈的"第一道门"

5G注册（Registration）是UE接入5GS后与核心网建立MM上下文的第一个NAS级过程，定义于**TS 23.502 V18.x Section 4.2.2.2**。与LTE Attach不同，5G将"注册"与"PDU会话建立"解耦——Registration仅建立 Mobility Management上下文，不承载任何数据面资源。这一设计哲学直接源于5G网络切片的架构需求：UE先注册获得Allowed NSSAI，再按需建立PDU会话。

本文聚焦**Initial Registration**（初始注册）的完整信令流，逐消息拆解NAS/NGAP层的每一个关键IE，并深入分析AMF选择、Identity Request/Response、5G-AKA认证、Security Mode Control等子过程之间的时序关系与设计意图。

---

## 二、初始注册总体信令时序图

以下是基于TS 23.502 Section 4.2.2.2 Figure 4.2.2.2.2-1的完整时序流，涵盖从RRC建立到Registration Complete的全部20个步骤：

```mermaid
sequenceDiagram
    participant UE
    participant gNB as gNB(NG-RAN)
    participant AMF
    participant AUSF
    participant UDM
    participant SNSSAI as NSSF

    Note over UE,gNB: 阶段1: RRC连接建立
    UE->>gNB: 1. RRC Setup Request (Random Access)
    gNB->>UE: 2. RRC Setup
    UE->>gNB: 3. RRC Setup Complete (携带NAS: Registration Request)

    Note over gNB,AMF: 阶段2: NGAP Initial UE Message + AMF选择
    gNB->>AMF: 4. NGAP Initial UE Message(NAS-PDU=Registration Request, RAN UE NGAP ID, UserLocationInformation, RRC Establishment Cause)

    Note over AMF,AMF: 5. AMF执行Initial AMF Selection(基于GUAMI/SUCI/PLMN)
    AMF->>AMF: 6. 检查UE Context是否存在(5G-GUTI)

    alt UE Context不存在 或 需要Identity
        AMF-->>UE: 7. NAS: Identity Request(SUCI类型)
        UE-->>AMF: 8. NAS: Identity Response(SUCI=加密后的SUPI)
    end

    Note over AMF,AUSF: 阶段3: 5G-AKA主认证
    AMF->>AUSF: 9. Nausf_UEAuthentication Authenticate(SUPI, SNN)
    AUSF->>UDM: 10. Nudm_UEAuthentication Get(Authentication Vector)
    UDM->>UDM: 11. 生成AV(RAND, AUTN, XRES*, KAUSF)
    UDM-->>AUSF: 12. 返回5G HE AV
    AUSF->>AUSF: 13. 计算HXRES*和KSEAF
    AUSF-->>AMF: 14. 返回5G AV(RAND, AUTN, HXRES*)

    AMF-->>UE: 15. NAS: Authentication Request(RAND, AUTN, ngKSI)
    UE->>UE: 16. UE验证AUTN, 计算RES*
    UE-->>AMF: 17. NAS: Authentication Response(RES*)

    AMF->>AMF: 18. 比较HXRES*与H(RES*)

    Note over AMF,UE: 阶段4: NAS安全模式控制
    AMF-->>UE: 19. NAS: Security Mode Command(Selected Security Algorithm, ngKSI, ReplayComplete)
    UE-->>AMF: 20. NAS: Security Mode Complete(IMEISV)

    Note over AMF,NSSAI: 阶段5: 切片选择 + UDM注册
    AMF->>SNSSAI: 21. Nnssf_NSSelection Get(Requested NSSAI, TA)
    SNSSAI-->>AMF: 22. Allowed NSSAI + Configured NSSAI
    AMF->>UDM: 23. Nudm_UECM_Registration(Registration Type, Access Type)
    UDM-->>AMF: 24. 返回Subscription Data(AccessAndMobilitySubscriptionData)

    Note over gNB,UE: 阶段6: NGAP上下文建立 + Registration Accept
    AMF->>gNB: 25. NGAP Initial Context Setup Request(AMF UE NGAP ID, NAS-PDU=Registration Accept, Security Key, UE Aggregate Max Bit Rate)
    gNB->>UE: 26. RRC Reconfiguration(AS Security激活 + NAS: Registration Accept)
    UE-->>gNB: 27. RRC Reconfiguration Complete
    gNB-->>AMF: 28. NGAP Initial Context Setup Response
    UE->>gNB: 29. NAS: Registration Complete(UL NAS Transport)
    gNB->>AMF: 30. NGAP Uplink NAS Transport(NAS-PDU=Registration Complete)
```

---

## 三、阶段一：RRC连接建立（步骤1-3）

### 3.1 RRC Setup Request → RRC Setup

UE通过PRACH完成随机接入后，发起RRC连接建立（TS 38.331 Section 5.3.2）。RRC Setup Complete消息中通过 `dedicatedNAS-Message` 字段将NAS层的Registration Request封装并传递给gNB。

关键点在于：**gNB不解码NAS消息**，仅作为透明传输管道，将NAS-PDU通过NGAP Initial UE Message转发给AMF。

### 3.2 RRC Establishment Cause映射

gNB在转发NGAP消息时，将RRC Establishment Cause映射为NGAP的RRCEstablishmentCause IE：

| RRC Establishment Cause (TS 38.331) | NGAP Cause | 典型场景 |
|---|---|---|
| emergency | emergency | 紧急呼叫 |
| highPriorityAccess | highPriorityAccess | MPS/MCS用户 |
| mt-Access | mt-Access | 被叫寻呼响应 |
| mo-Signalling | mo-Signalling | 注册/TAU |
| mo-Data | mo-Data | 主叫数据 |
| mo-VoiceCall | mo-VoiceCall | VoNR主叫 |
| mo-VideoCall | mo-VideoCall | 视频通话 |
| mo-SMS | mo-SMS | SMS over NAS |

---

## 四、阶段二：NGAP Initial UE Message与AMF选择（步骤4-8）

### 4.1 NGAP Initial UE Message关键IE解析

gNB收到RRC Setup Complete后，构造NGAP Initial UE Message（TS 38.413 Section 8.6.1），核心IE如下：

| IE名称 | 来源 | 说明 |
|---|---|---|
| **RAN UE NGAP ID** | gNB本地生成 | gNB侧UE标识，32bit，NG连接内唯一 |
| **NAS-PDU** | RRC Setup Complete透传 | 封装Registration Request |
| **UserLocationInformation** | gNB从Cell/TAI获取 | 包含NR-CGI和TAI |
| **RRCEstablishmentCause** | RRC层映射 | 如上表所示 |
| **UERadioCapability** | 可选 | UE无线能力信息 |
| **AMF Set ID**（5GS TMSI解析） | 从5G-GUTI解析 | 用于路由到正确的AMF Set |
| **Selected PLMN Identity** | gNB广播PLMN列表中选择 | 用于AMF PLMN匹配 |

### 4.2 AMF选择机制（TS 23.501 Section 6.3.5）

gNB首先尝试基于5G-GUTI中的GUAMI选择AMF。若GUAMI无效或无可用AMF，gNB执行**Default AMF Selection**：

```mermaid
flowchart TD
    A[NGAP Initial UE Message到达gNB] --> B{5G-GUTI中GUAMI有效?}
    B -->|是| C[基于GUAMI路由到对应AMF]
    B -->|否| D{gNB配置了AMF Set?}
    D -->|是| E[从AMF Set中选择负载最低的AMF]
    D -->|否| F[基于Selected PLMN + S-NSSAI选择Default AMF]
    C --> G[转发NAS-PDU至目标AMF]
    E --> G
    F --> G
    G --> H{AMF接受?}
    H -->|是| I[正常处理Registration]
    H -->|否: Overload/Unavailable| J[NGAP Reroute NAS Message至备用AMF]
```

**设计意图**：5G引入GUAMI（Globally Unique AMF ID）替代LTE中MMEGI+MMEC的扁平结构，支持AMF Set内多AMF实例的负载分担，同时通过Reroute机制保障AMF故障时的业务连续性。

### 4.3 Identity Request/Response（TS 24.501 Section 8.2.9）

当AMF无法从5G-GUTI检索到UE上下文（首次注册或AMF重启后），AMF发起Identity Request请求UE提供SUCI：

| 字段 | 值 | 说明 |
|---|---|---|
| Message Type | Identity Request | 5GMM消息 |
| Identity Type | SUCI (Type 5) | 请求加密的订阅标识 |
| 5GS Identity Type | SUCI | 唯一需要的IE |

UE响应Identity Response，携带使用归属网络公钥加密的SUCI（ECIES方案，详见TS 33.501 Section 6.12）。SUCI格式为 `SUPI类型- MCC-MNC-路由指示-加密输出`，例如：

```
SUCI: 0-460-00-0-<encrypted_payload>
        ↑  ↑    ↑ ↑        ↑
        |  |    | |    ECIES加密的MSIN
        |  |    | 保护方案(0=空方案,1=Profile A,2=Profile B)
        |  |    路由指示(可用于AUSF路由)
        |  PLMN(460-00=CMCC)
        SUPI类型(0=IMSI, 1=NAI, 2=GMSI...)
```

---

## 五、阶段三：5G-AKA主认证（步骤9-18）

### 5.1 认证向量获取

AMF通过Nausf_UEAuthentication_Authenticate服务向AUSF请求认证（TS 29.509），AUSF调用UDM的Nudm_UEAuthentication_Get获取5G认证向量。UDM/ARPF生成认证向量的核心参数：

| 参数 | 长度 | 生成方 | 说明 |
|---|---|---|---|
| RAND | 128 bit | UDM/ARPF | 随机挑战值 |
| AUTN | 128 bit | UDM/ARPF | 网络认证令牌(含SQN⊕AK, AMF, MAC-A) |
| XRES* | 可变(最长256bit) | UDM/ARPF | 期望响应值(由XRES扩展生成) |
| KAUSF | 256 bit | UDM/ARPF | AUSF与UDM之间的共享密钥 |
| HXRES* | 可变 | AUSF | 由XRES*派生的哈希值，用于AMF本地验证 |
| KSEAF | 256 bit | AUSF | 从KAUSF派生的SEAF锚点密钥 |

### 5.2 UE侧AUTN验证流程

UE收到Authentication Request后执行以下验证步骤：

```mermaid
flowchart TD
    A[UE收到RAND+AUTN+ngKSI] --> B[从USIM读取K]
    B --> C[计算AK=f5_K RAND]
    C --> D[恢复SQN = AUTN中SQN⊕AK ⊕ AK]
    D --> E[计算XMAC = f1_K SQN, RAND, AMF]
    E --> F{XMAC == AUTN中MAC?}
    F -->|否| G[返回Authentication Failure#cause=MAC Failure]
    F -->|是| H{SQN在有效窗口内?}
    H -->|否| I[返回Authentication Failure#cause=SYNC Failure,携带AUTS]
    H -->|是| J[计算RES*=KDF XRES, SNN]
    J --> K[返回Authentication Response携带RES*]
```

**ngKSI（NAS Key Set Identifier）**：标识当前认证使用的密钥集。值为0-6标识可用密钥集，值为7标识"密钥集不可用"——AMF收到ngKSI=7时必须触发完整认证流程。

### 5.3 HXRES*验证设计意图

AUSF返回给AMF的是HXRES*（而非XRES*），AMF收到UE的RES*后计算H(RES*)与HXRES*比对。这样设计的核心目的是：

1. **AMF不需要知道真实的XRES***，即使AMF被攻破，攻击者也无法获得完整的认证响应
2. 减少AMF与AUSF之间的安全依赖，AMF仅需做哈希比对
3. 与LTE的XRES/H(XRES)机制相比，5G使用可变长度的XRES*/HXRES*（支持扩展），增强了抗离线字典攻击能力

---

## 六、阶段四：NAS安全模式控制（步骤19-20）

### 6.1 Security Mode Command关键IE

认证通过后，AMF发起NAS Security Mode Control（TS 24.501 Section 8.2.21），建立NAS层安全上下文：

| IE | 说明 |
|---|---|
| **Selected Security Algorithm** | 选定的加密+完整性保护算法对 |
| **ngKSI** | 安全密钥集标识(0-6) |
| **Replayed Security Capability** | AMF回显UE上报的安全能力(防降级攻击) |
| **Replayed 5G-GUTI** | 可选，回显5G-GUTI |
| **IMEISV Request** | 可选，请求UE设备标识 |
| **Additional 5G Security Information** | 可选，含EPS Security Context信息 |

### 6.2 安全算法选择

TS 33.501 Section 6.7定义了5G NAS支持的加密和完整性保护算法：

| 算法 | 类型 | 说明 |
|---|---|---|
| NEA0 | 加密 | 空加密(仅用于紧急呼叫) |
| 128-NEA1 | 加密 | 基于SNOW 3G |
| 128-NEA2 | 加密 | 基于AES |
| 128-NEA3 | 加密 | 基于ZUC(国密) |
| NIA0 | 完整性 | 空完整性保护(仅紧急注册) |
| 128-NIA1 | 完整性 | 埍于SNOW 3G |
| 128-NIA2 | 完整性 | 基于AES |
| 128-NIA3 | 完整性 | 基于ZUC(国密) |

**Replayed Security Capability防降级**：AMF在SMC中回显UE在Registration Request中上报的Security Capability。UE验证AMF回显值是否与自己原始上报一致——若不一致说明中间人篡改了Registration Request中的安全能力字段（Bidding Down Attack），UE拒绝该SMC。

### 6.3 密钥层级推演

认证完成后，各层密钥通过KDF（Key Derivation Function, HMAC-SHA-256）逐层推演：

```
K (USIM/UDM共享根密钥)
├── CK, IK (认证向量分量)
    ├── KAUSF = KDF(CK||IK, SNN||SQN⊕AK)         [UDM→AUSF]
        ├── KSEAF = KDF(KAUSF, SNN)                [AUSF→SEAF(AMF)]
            ├── KAMF = KDF(KSEAF, SUPi||ABBA)      [AMF锚点密钥]
                ├── KNASenc = KDF(KAMF, NAS-enc-algo)
                ├── KNASint = KDF(KAMF, NAS-int-algo)
                ├── KgNB = KDF(KAMF, access-type)   [AS层锚点]
                    ├── KRRCenc = KDF(KgNB, RRC-enc-algo)
                    ├── KRRCint = KDF(KgNB, RRC-int-algo)
                    ├── KUPenc = KDF(KgNB, UP-enc-algo)
                    └── KUPint = KDF(KgNB, UP-int-algo)
```

---

## 七、阶段五：切片选择与UDM注册（步骤21-24）

### 7.1 NSSF切片选择

AMF调用Nnssf_NSSelection_Get（TS 29.531）获取UE的Allowed NSSAI。输入参数包括Requested NSSAI（UE在Registration Request中携带）、UE当前TAI、Subscription信息等。

**S-NSSAI协商状态机**：

```mermaid
stateDiagram-v2
    [*] --> Requested: UE携带Requested NSSAI
    Requested --> Allowed: NSSF匹配成功
    Requested --> Rejected: 切片未订阅或TA不支持
    Requested --> Configured: 需要UE更新Configured NSSAI
    Allowed --> HomeRouted: S-NSSAI需Home路由
    Configured --> Requested: UE重新发起Registration
    Rejected --> Requested: UE修改Requested NSSAI
```

NSSAI的四种形态及含义：

| NSSAI类型 | 携带方向 | 说明 |
|---|---|---|
| **Requested NSSAI** | UE → Network | UE请求使用的切片列表 |
| **Allowed NSSAI** | Network → UE | 网络允许在当前RA使用的切片 |
| **Configured NSSAI** | Network → UE | 运营商配置UE可用的默认切片 |
| **Rejected NSSAI** | Network → UE | 被拒绝的切片(含拒绝原因) |

### 7.2 UDM注册（Nudm_UECM_Registration）

AMF向UDM注册自己为当前服务该UE的AMF（TS 29.503 Section 5.4.2），同时获取用户的AccessAndMobilitySubscriptionData。UDM会通知旧AMF（若存在）执行Deregistration，确保一个UE同一时刻只有一个Serving AMF。

---

## 八、阶段六：NGAP Initial Context Setup与Registration Accept（步骤25-30）

### 8.1 NGAP Initial Context Setup Request

AMF通过NGAP Initial Context Setup Request（TS 38.413 Section 8.4.1）通知gNB建立UE逻辑上下文，同时携带加密的Registration Accept：

| IE | 说明 |
|---|---|
| **AMF UE NGAP ID** | AMF侧UE标识 |
| **Security Key** | KAMF推演的KgNB，用于AS层安全 |
| **UE Aggregate Maximum Bit Rate** | UE-AMBR，限制UE所有Non-GBR QoS Flow总速率 |
| **Allowed NSSAI** | 允许的切片列表，gNB用于后续PDU Session验证 |
| **NAS-PDU** | 封装Registration Accept |
| **Mobility Restriction List** | 禁止漫游区域/PLMN列表 |
| **RAT Restrictions** | 禁止接入的RAT类型 |
| **Masked IMEISV** | 脱敏后的设备标识(TAC+SV) |

### 8.2 Registration Accept关键IE（TS 24.501 Section 8.2.7）

Registration Accept是AMF对UE注册请求的成功响应，核心IE如下：

| IE | 必选/可选 | 说明 |
|---|---|---|
| **5G-GUTI** | 必选 | AMF分配的临时标识，用于后续NAS消息标识UE |
| **Registration Area** | 必选 | TAI列表，UE在该列表内移动无需重新注册 |
| **5GS Registration Result** | 必选 | 注册结果(3GPP/Non-3GPP/both) |
| **Allowed NSSAI** | 条件必选 | 网络允许的切片 |
| **Rejected NSSAI** | 可选 | 被拒绝的切片及原因 |
| **Configured NSSAI** | 可选 | 运营商配置的默认切片 |
| **T3512 Timer** | 必选 | 周期性注册定时器(默认54分钟) |
| **Service Area List** | 可选 | 服务区域限制列表 |
| **MICO Indication** | 可选 | MICO模式指示(仅注册区外寻呼) |
| **Network Slicing Indication** | 可选 | 切片变更指示(触发UE重新Registration) |
| **Emergency Number List** | 可选 | 紧急号码列表 |
| **Negotiated DRX Parameters** | 可选 | 协商的DRX参数 |
| **PLMN List** | 可选 | 等效PLMN列表 |
| **LADN Information** | 可选 | 本地数据网信息(含DNN+跟踪区) |
| **5GS DRX Parameters** | 可选 | 5GS DRX参数 |

### 8.3 Registration Complete（TS 24.501 Section 8.2.8）

UE收到Registration Accept后，通过UL NAS Transport消息发送Registration Complete，确认已收到并应用5G-GUTI和配置参数。**这是一个纯粹的确认消息，不携带任何强制性IE**——其作用是确保5G-GUTI分配的可靠性（类比TCP的ACK机制），防止AMF分配新GUTI后UE未收到导致标识不一致。

---

## 九、Registration Request NAS消息结构详解

Registration Request的编码结构遵循TS 24.501 Section 8.2.6：

```mermaid
graph TD
    subgraph "Registration Request NAS消息结构"
        A["Protocol Discriminator (5GMM) = 0x7E<br/>4 bit"] --> B["Security Header Type = 0x00<br/>4 bit"]
        B --> C["Message Type = 0x41 (Registration Request)<br/>1 octet"]
        C --> D["5GS Registration Type<br/>1 octet"]
        D --> E["Mobile Identity (SUCI/GUTI)<br/>可变长度"]
        E --> F["Optional IEs..."]
    end

    subgraph "5GS Registration Type (1 octet)"
        D1["bit 4: Follow-on request pending<br/>bit 3-1: Registration Type<br/>000=Initial, 001=Mobility, 010=Periodic, 011=Emergency"]
    end

    subgraph "Optional IEs (按O/T/V排列)"
        F1["5G-GUTI (Type 5G-GUTI)<br/>5GS Tracking Area Identity<br/>5GS DRX Parameters<br/>5GMM Capability<br/>UE Security Capability<br/>Requested NSSAI<br/>Last Visited Registered TAI<br/>UE Usage Setting<br/>Update Type<br/>MICO Indication<br/>UE Status<br/>EPS NAS Message Container<br/>Payload Container"]
    end

    D --> D1
    F --> F1
```

**UE Security Capability IE详解**（TS 24.501 Section 9.11.3.54）：

| 字节位 | 字段 | 说明 |
|---|---|---|
| Octet 3 bit 8-7 | 128-NEA0/NEA1/NEA2/NEA3支持 | 加密算法位图 |
| Octet 3 bit 1 | NEA0 | 空加密支持 |
| Octet 3 bit 2-4 | NEA1/2/3 | 各算法独立bit |
| Octet 4 bit 8-7 | 128-NIA0/NIA1/NIA2/NIA3支持 | 完整性保护算法位图 |
| Octet 5 bit 8-5 | 128-NEA0-NEA3(EA for 802.11) | Non-3GPP加密 |
| Octet 6 bit 8-5 | 128-NIA0-NIA3(IA for 802.11) | Non-3GPP完整性 |

---

## 十、Registration类型对比表

| 注册类型 | 触发条件 | 关键差异 | 携带Identity |
|---|---|---|---|
| **Initial Registration** | 开机/飞行模式退出 | 完整认证+SMC+上下文建立 | SUCI(首次)或5G-GUTI |
| **Mobility Registration Update** | 进入新RA(TAI不在列表中) | 可跳过认证(安全上下文有效) | 5G-GUTI |
| **Periodic Registration Update** | T3512超时 | 轻量级，通常无认证 | 5G-GUTI |
| **Emergency Registration** | 无USIM/受限服务 | 跳过认证或使用EAP-AKA' | IMEI或SUCI |

---

## 十一、实战抓包识别与故障排查

### 11.1 Wireshark抓包识别Registration流程

使用Wireshark（需5G NAS/NGAP协议插件）识别Registration流程的关键过滤表达式：

```
# 过滤NAS Registration消息
nas-5gs.message_type == 0x41  # Registration Request
nas-5gs.message_type == 0x42  # Registration Accept
nas-5gs.message_type == 0x43  # Registration Complete

# 过滤NGAP Initial UE Message
ngap.procedureCode == 15  # Initial UE Message
ngap.procedureCode == 15 && ngap.BearerType == "nas-pdu"  # 含NAS-PDU

# 过滤完整认证流程
nas-5gs.message_type == 0x52  # Authentication Request
nas-5gs.message_type == 0x53  # Authentication Response
nas-5gs.message_type == 0x5c  # Security Mode Command
nas-5gs.message_type == 0x5d  # Security Mode Complete
```

### 11.2 常见故障点与排错思路

| 故障现象 | 可能原因 | 排错方法 |
|---|---|---|
| Registration Reject #5 (Illegal UE) | USIM与网络不匹配/黑名单 | 检查IMSI与UDM订阅数据 |
| Registration Reject #11 (PLMN not allowed) | UE选择了禁止PLMN | 检查gNB广播PLMN与UE USIM PLMN |
| Authentication Failure #20 (MAC Failure) | USIM K值与UDM不一致 | 对比USIM Ki与UDM存储的密钥 |
| Authentication Failure #21 (SYNC Failure) | USIM SQN与UDM SQN不同步 | UDM执行Re-synchronization |
| SMC Reject #23 (Security Mode Rejected) | 安全能力不匹配/降级攻击 | 检查UE与AMF支持的安全算法交集 |
| Registration后立即Deregistration | AMF过载或UDM订阅数据异常 | 检查AMF日志和UDM返回的Subscription Data |
| gNB无响应Initial Context Setup | KAMF推演KgNB失败 | 检查ngKSI和密钥推演参数 |
## 十二、Registration状态机全貌

```mermaid
stateDiagram-v2
    [*] --> RM_DEREGISTERED: UE开机
    RM_DEREGISTERED --> RM_REGISTERED: Registration Accept
    RM_REGISTERED --> RM_REGISTERED: Mobility/Periodic Update
    RM_REGISTERED --> RM_DEREGISTERED: Deregistration
    RM_REGISTERED --> RM_DEREGISTERED: Implicit Deregistration(T3502超时)

    state RM_DEREGISTERED {
        [*] --> PLMN_SEARCH
        PLMN_SEARCH --> CELL_SELECTION
        CELL_SELECTION --> RRC_CONNECTING
        RRC_CONNECTING --> NAS_REGISTERING
    }

    state RM_REGISTERED {
        [*] --> CM_IDLE
        CM_IDLE --> CM_CONNECTED: Service Request/RAN Paging
        CM_CONNECTED --> CM_IDLE: RRC Release/UE Context Release
        CM_IDLE --> CM_IDLE: Periodic Registration(T3512)
        CM_IDLE --> CM_IDLE: Mobility Registration(TAI变化)
    }

    state CM_CONNECTED {
        [*] --> ACTIVE
        ACTIVE --> INACTIVE: RRC Inactive(挂起)
        INACTIVE --> ACTIVE: Resume
    }
```

**关键定时器**：

| 定时器 | 值 | 作用 | TS引用 |
|---|---|---|---|
| T3512 | Registration Accept中分配 | 周期性注册间隔 | TS 24.501 Section 5.3.2 |
| T3502 | 默认12分钟(AMF可配置) | 禁止注册区域内的注册重试间隔 | TS 24.501 Section 5.3.1 |
| T3510 | 默认15秒 | Registration Request重传定时器 | TS 24.501 Section 5.3.6 |
| T3511 | 默认10秒 | Registration Attempt间重试间隔 | TS 24.501 Section 5.3.5 |
| T3504 | 默认10秒 | Identity Response等待定时器 | TS 24.501 Section 5.3.3 |

---

## 十三、Registration Accept中的LADN机制

LADN（Local Area Data Network）是5G引入的概念，定义于TS 23.501 Section 5.6.5。Registration Accept可携带LADN Information IE，告知UE哪些DNN仅在特定跟踪区域内可用（典型的MEC场景）。

| IE字段 | 说明 |
|---|---|
| LADN DNN | 本地数据网的DNN（如"internet.mec.local"） |
| LADN Tracking Area List | 该LADN可用的TAI列表 |

**设计意图**：UE仅在进入LADN覆盖区域时才发起对应DNN的PDU Session Establishment，避免无效的PDU会话建立尝试。这对园区5G、工业互联网场景尤为重要。

---

## 十四、常见问题

**Q1: Initial Registration和Mobility Registration Update在信令流上的核心区别是什么？**
A: 最大的区别在于是否需要执行完整的认证流程。Initial Registration必须执行5G-AKA认证和Security Mode Control（除非AMF已有有效的安全上下文且选择跳过）。而Mobility Registration Update通常可复用已有安全上下文，AMF仅需通过Security Mode Command重激活即可，无需Authentication Request/Response交互。因此Mobility Registration的信令消息数可从约15条缩减至约6条。

**Q2: 为什么5G要把Registration和PDU Session建立分离，而不像LTE Attach一起做？**
A: 三个原因：(1) 网络切片——UE必须先通过Registration获取Allowed NSSAI，才能知道可以在哪些切片上建立PDU会话；(2) 信令效率——大量IoT设备仅需注册告知网络"我在"，不需要立即建立数据通道；(3) 多PDU会话独立管理——UE可以在不同切片、不同DNN上按需建立多个PDU Session，Registration只需一次。

**Q3: SUCI中的Profile A和Profile B有什么区别？**
A: 两者都是ECIES（Elliptic Curve Integrated Encryption Scheme）保护方案，区别在于椭圆曲线选择：Profile A使用Curve25519（x-coordinate only, Montgomery曲线），Profile B使用secp256r1（NIST P-256, Weierstrass曲线）。中国运营商通常使用Profile B（配合国密算法体系）。SUCI中的保护方案标识字段指示UE使用哪种Profile，AUSF需根据该标识选择对应的解密密钥。

**Q4: AMF如何在Registration过程中判断是否需要触发Identity Request？**
A: AMF首先从Registration Request中的Mobile Identity字段判断类型。如果是5G-GUTI，AMF尝试查找对应的UE Context。若本地无缓存（AMF重启、跨AMF移动）或通过Nudm_UECM_Get确认该GUTI不指向自己，AMF触发Identity Request请求UE提供SUCI，然后通过SUCI中的SUPI从UDM获取订阅数据。如果是SUCI则直接使用，无需Identity Request。

**Q5: Registration Accept中的MICO模式对网络有什么影响？**
A: MICO（Mobile Initiated Connection Only）模式下，AMF不向UE发送寻呼，UE始终处于CM-IDLE状态。这意味着：(1) 网络侧无法发起下行数据推送；(2) AMF无需为MICO UE分配寻呼资源，显著节省核心网和无线侧寻呼开销；(3) 仅当UE主动发起Service Request或Periodic Registration时才建立连接。适用于智能水表、环境传感器等几乎不需要网络主动推送的场景。R18进一步增强了MICO模式，支持按切片粒度配置。

---

## 参考来源

1. [3GPP TS 23.502 V18.10.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — Section 4.2.2.2 Registration Procedures
2. [3GPP TS 24.501 V18.x](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3370) — Section 8.2.6/8.2.7/8.2.8 NAS Registration Messages
3. [ShareTechnote - 5G Registration](https://www.sharetechnote.com/html/5G/5G_Registration.html) — NAS Registration消息详解与抓包分析
4. [free5GC - Registration Procedures](https://free5gc.org/blog/20240119/20240119/) — 开源5GC中的Registration实现分析
5. [EventHelix - 5G Standalone Access Registration](https://www.eventhelix.com/5G/standalone-access-registration/) — 完整的5G SA Registration序列图与消息详解
6. [3GPP TS 38.413](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3223) — NGAP Initial UE Message / Initial Context Setup
7. [TelecomTrainer - 5G NAS Authentication](https://www.telecomtrainer.com/5g-nas-authentication-and-security-procedures-explained-step-by-step-analysis/) — 5G-AKA认证流程逐步解析

---

> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。
> 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)