<!-- title: 5G业务请求信令流程深度解读 -->
<!-- domain: protocols -->

# 5G业务请求（Service Request）信令流程深度解读：TS 23.502 §4.2.3.2 逐条拆解

在5G网络中，如果统计NAS层消息出现频率，**Service Request几乎一定是第一名**。UE每一次从空闲态被“唤醒”——无论是App来了一条微信推送、基站要下发寻呼、还是上层需要发一条NAS信令——只要UE处于CM-IDLE，都必须先走一遍TS 23.502第4.2.3.2节定义的**UE Triggered Service Request**流程。它与Registration（注册）不同：注册解决的是“我是谁、我能不能入网”，而Service Request解决的是“给我把N2/N1连接和用户面通道恢复起来”。本文基于TS 23.502（§4.2.3.2/§4.2.3.3）、TS 24.501（§5.6）、TS 38.413（NGAP）和TS 33.501，逐消息、逐IE地拆解这条网络中最繁忙的信令流。

---

## 一、前置概念：CM状态、RRC状态与5G-S-TMSI

### 1.1 两套状态的映射关系

5GC引入了**连接管理（CM）状态**（TS 23.501中定义于移动性与连接管理章节，即CM-IDLE/CM-CONNECTED），它与接入网的RRC状态是两个独立维度：

| CM状态（NAS/核心网视角） | 对应RRC状态（空口视角） | 网络能否直接触达UE |
|---|---|---|
| CM-IDLE | RRC_IDLE | 不能，需寻呼 |
| CM-CONNECTED | RRC_CONNECTED | 能，N2/N1均建立 |
| CM-CONNECTED | RRC_INACTIVE | 核心网可见、空口需RAN内寻呼 |

注意第三行：**RRC_INACTIVE下UE仍是CM-CONNECTED**，AMF侧N2连接逻辑上仍然保持。这意味着Service Request在RRC_INACTIVE场景下有完全不同的触发方式（见第四节），这是5G相对4G最大的架构变化之一。

### 1.2 5G-S-TMSI：寻呼的“门牌号”

CM-IDLE下的UE没有RRC连接，网络唯一的触达手段是寻呼，而寻呼的索引就是5G-S-TMSI。其结构定义于TS 23.003第2.10节（5G-GUTI的简化形式）：

```
5G-GUTI = <AMF Region ID>(8bit) + <AMF Set ID>(10bit) + <AMF Pointer>(6bit) + <5G-TMSI>(32bit)
5G-S-TMSI = <AMF Set ID>(10bit) + <AMF Pointer>(6bit) + <5G-TMSI>(32bit) = 48bit = 6字节
```

- **AMF Set ID + AMF Pointer（16bit）**：精确指向AMF区域（Region）内某个AMF集合中的某一台AMF。Service Request流程中，gNB正是靠这16bit把NGAP消息路由到正确的AMF；
- **5G-TMSI（32bit）**：UE在AMF内的临时标识，AMF用它查回UE上下文，**不暴露IMSI/SUPI**——这是5G身份隐私设计（SUCI体系）在寻呼域的延伸。

### 1.3 ngKSI：让AMF找到正确的密钥

Service Request是UE在空闲态发出的第一条NAS消息，网络如何确认它没被伪造？答案是**完整性保护校验**。UE在SERVICE REQUEST中携带**ngKSI**（key Set Identifier，TS 33.501密钥体系中的K_AMF标识），AMF据此选择本地保存的K_AMF派生NAS完整性密钥K_NASint，校验消息中的NAS MAC。校验通过，流程才继续——这是整条流程的安全基石。

---

## 二、UE Triggered Service Request完整信令流（TS 23.502 §4.2.3.2）

### 2.1 总体时序图

以UE处于CM-IDLE、有下行数据待收（或上层需要发信令）为典型场景：

```mermaid
sequenceDiagram
    autonumber
    participant UE as UE (CM-IDLE)
    participant RAN as NG-RAN (gNB)
    participant AMF as AMF
    participant SMF as SMF
    participant UPF as UPF

    UE->>RAN: RRCSetupRequest (establishmentCause=mo-Data)
    RAN-->>UE: RRCSetup
    UE->>RAN: RRCSetupComplete (携带NAS: SERVICE REQUEST)
    Note over UE: ngKSI + Service type + 5G-S-TMSI(6字节)
    RAN->>AMF: NGAP INITIAL UE MESSAGE<br/>(5G-S-TMSI, NAS-PDU, User Location Info, RRC Cause)
    Note over AMF: 按ngKSI选K_AMF校验NAS MAC<br/>解析5G-S-TMSI确认本AMF即目标AMF
    opt 本AMF无完整上下文(如AMF迁移)
        AMF->>AMF: Namf_Communication_UEContextTransfer(向旧AMF取上下文)
    end
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext(通知UE可达)
    SMF->>UPF: N4 Session Modification(PFCP)
    UPF-->>SMF: N4 Session Modification Response
    SMF-->>AMF: UpdateSMContext Response(含N2 SM Info: UPF侧N3隧道信息)
    AMF->>RAN: NGAP INITIAL CONTEXT SETUP REQUEST<br/>(NAS-PDU, K_gNB, UE安全能力,<br/>PDU Session Resource Setup List, UE-AMBR)
    RAN-->>UE: RRC Reconfiguration(SRB2/DRB建立, AS安全激活)
    RAN->>AMF: INITIAL CONTEXT SETUP RESPONSE(各PDU会话的RAN侧N3 TEID/IP)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext(转发RAN侧N3隧道信息)
    SMF->>UPF: N4 Session Modification(下行隧道指向gNB)
    UPF->>RAN: 下行数据经N3隧道下发
    RAN-->>UE: 下行数据送达
    opt 无其他NAS消息可发时
        AMF-->>UE: NAS SERVICE ACCEPT
    end
```

### 2.2 逐条消息深度解析

**第1–3步：RRC连接建立与NAS消息搭车**

UE发送`RRCSetupRequest`时的`establishmentCause`是排错时的重要线索：`mo-Signalling`对应Service type=Signalling，`mo-Data`对应Service type=Data，`mps-PriorityAccess`对应高优先级接入。关键在于：**NAS的SERVICE REQUEST是装在`RRCSetupComplete`里“搭车”上行的**（即NR RRC的UL DCCH承载），gNB并不解析其内容，只负责转发和路由。

**第4步：NGAP INITIAL UE MESSAGE（TS 38.413）**

这是gNB发给AMF的第一条NGAP UE关联消息，关键IE：

| IE | 作用与排错价值 |
|---|---|
| RAN_UE_NGAP_ID | gNB分配的UE级NGAP标识，此后所有NGAP消息凭这对(RAN_ID, AMF_ID)关联 |
| 5G-S_TMSI | 可选IE；gNB从SERVICE REQUEST中提取后填入，AMF据此确认目标 |
| NAS-PDU | 原封不动的SERVICE REQUEST |
| User Location Information | TAI + Cell ID；后续计费、合法监听、TA管理都依赖它 |
| RRC Establishment Cause | UE发起的原因，与NAS侧Service type交叉验证 |

**第5步：AMF的完整性校验（TS 33.501）**

AMF收到消息后第一件事不是查会话，而是**验MAC**。SECURITY REQUEST消息中的ngKSI指示AMF应使用哪个K_AMF；若校验失败，AMF直接回SERVICE REJECT（cause = #20 MAC failure），UE需重新触发鉴权。若AMF发现上下文不全（典型场景：UE上次注册后AMF池内发生迁移、或旧AMF已释放部分上下文），会通过`Namf_Communication_UEContextTransfer`向旧AMF拉取完整UE上下文，这是§4.2.3.2中的条件分支。

**第6–9步：会话面的“批量唤醒”**

这是5G与4G最本质的设计差异之一：**SERVICE REQUEST中不携带任何PDU Session ID**。UE只说“我要连上”，具体恢复哪些会话由**网络侧决定**——AMF根据本地保存的PDU会话状态，逐个向SMF发`Nsmf_PDUSession_UpdateSMContext`。SMF通过N4/PFCP通知UPF“UE要醒了”，并把UPF侧的N3隧道信息（TEID + IP）打包成**N2 SM Information（PDU Session Resource Setup Request Transfer）**交给AMF。设计意图：注册时允许一个UE的多个PDU会话锚定在不同SMF甚至不同切片上，MM与SM彻底解耦后，连接恢复就不再依赖UE枚举会话，也天然规避了会话状态不一致问题。

**第10步：NGAP INITIAL CONTEXT SETUP REQUEST**

AMF发给gNB的“总装清单”，IE极为密集，排错重点：

| IE | 说明 |
|---|---|
| Security Key | AMF基于K_AMF和上行/下行NAS计数值垂直派生的K_gNB，gNB再派生RRC/UP层密钥——AMF绝不直接下发K_AMF |
| UE Security Capabilities | NEA/NIA算法集合，gNB据此与UE协商AS算法 |
| PDU Session Resource Setup List | 每个待恢复会话的PDU Session ID + QoS Flow列表（QFI、5QI、GFBR/MFBR、优先级）+ UPF侧N3隧道信息 |
| UE Aggregate Maximum Bit Rate | UE级总限速，gNB执行 |
| RRC Inactive Assistance Information | 告知gNB该UE是否适合进入RRC_INACTIVE及配置建议 |
| Allowed NSSAI | 本AMF允许UE使用的切片，gNB据此做RRC层切片资源映射 |

**第11–15步：空口重配与双向隧道打通**

gNB通过`RRC Reconfiguration`下发SRB2与DRB配置并激活AS安全；随后`INITIAL CONTEXT SETUP RESPONSE`把gNB侧N3 TEID/IP逐会话回给AMF，AMF再经SMF/N4写入UPF。至此**下行隧道指到gNB、上行隧道指到UPF**，数据面贯通。若此消息迟迟不到或携带失败IE（如`PDU Session Resource Failed to Setup List`），排错方向就是空口质量或gNB资源。

**第16步：SERVICE ACCEPT的“补位”逻辑（TS 24.501）**

一个容易被忽略的细节：网络**并不总是**回复SERVICE ACCEPT。如果AMF本来就有别的NAS消息要发（如CONFIGURATION UPDATE COMMAND），那条消息本身就完成了对Service Request的应答；只有“没有任何其他NAS消息可发”时（典型为Service type=Signalling场景），AMF才补发SERVICE ACCEPT。抓包时看到“只有请求没有ACCEPT”未必是异常。

---

## 三、NAS SERVICE REQUEST消息结构（TS 24.501）

### 3.1 消息体IE结构图

```mermaid
flowchart TB
    subgraph SEC["安全保护头(所有非紧急NAS消息必带)"]
        EPD["Extended protocol discriminator = 0x7E"]
        SHT["Security header type = 0x02<br/>(完整性保护+加密)"]
        MACI["NAS Message Authentication Code (4字节)"]
        SEQN["NAS Sequence Number (1字节, 防重放)"]
    end
    subgraph PLAIN["SERVICE REQUEST 明文载荷"]
        NKI["ngKSI + TSC位<br/>(TSC=0原生密钥/1映射密钥)"]
        STV["Service type (4bit)"]
        STMSI["5G-S-TMSI (6字节, CM-IDLE必带)<br/>AMF Set ID 10bit + AMF Pointer 6bit + 5G-TMSI 32bit"]
    end
    SEC --> PLAIN
```

注意：SERVICE REQUEST**没有**Message type字段——它是5GMM中极少数凭“Security header type + 半字节组合”即可识别的短消息，整条明文部分最小仅7字节，这是刻意为之的精简设计（频次最高的消息必须最短）。

### 3.2 Service type取值表

| 值 | 名称 | 网络行为差异 |
|---|---|---|
| 0 | Signalling | 仅恢复N2/N1信令连接，**不**请求恢复用户面 |
| 1 | Data | 恢复信令连接+按网络侧状态恢复PDU会话用户面 |
| 2 | Mobile terminated services | 响应网络寻呼（下行触发场景） |
| 3 | Emergency services | 紧急业务，受限服务区也可发起，可免完整性保护 |
| 4 | Emergency services fallback | 鉴权失败后回退继续紧急业务 |
| 5 | High priority access | MPS/优先业务，寻呼时网络可带优先级策略 |

---

## 四、两个变体场景

### 4.1 Network Triggered Service Request（TS 23.502 §4.2.3.3）

```mermaid
sequenceDiagram
    autonumber
    participant UPF
    participant SMF
    participant AMF
    participant RAN as NG-RAN
    participant UE as UE (CM-IDLE)

    UPF->>UPF: 收到下行PDU, UE无N3连接
    Note over UPF: 按策略缓存数据
    UPF->>SMF: PFCP Session Report(数据到达通知)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer(N2 SM Info)
    AMF->>RAN: NGAP PAGING<br/>(5G-S-TMSI, TAI List, Paging Priority,<br/>Paging Attempt Counter)
    Note over AMF: T3513超时未响应则重发, 计数递增
    RAN-->>UE: PDCCH(P-RNTI) + Paging记录(含S-TMSI)
    UE->>RAN: RRCSetupComplete携带 SERVICE REQUEST<br/>(Service type=Mobile terminated services)
    RAN->>AMF: INITIAL UE MESSAGE(回传寻呼携带的N2 SM Info)
    Note over AMF,SMF: 后续与UE触发流程汇合:<br/>上下文建立→N4修改→数据下发
```

要点：**T3513**（AMF寻呼重发定时器）与NGAP Paging中的`Paging Attempt Counter / Intended Number of Paging Attempts`配合控制寻呼节奏；多次寻呼无响应后，AMF通过N1N2 Message Transfer失败通知告知SMF“UE不可达”，SMF/UPF据此执行缓存与下行数据投递状态上报。若UE注册为**MICO模式**（Mobility Idleness Per Communication...即移动性仅空闲模式），网络根本不寻呼——下行数据由UPF拒绝/丢弃，靠应用层推送机制兜底，这正是MICO“省电优先”的体现。

### 4.2 RRC_INACTIVE下的Service Request

UE在RRC_INACTIVE发起业务时，不发`RRCSetupRequest`，而是发**`RRCResumeRequest`（携带I-RNTI）+ NAS SERVICE REQUEST**：

```mermaid
flowchart TB
    A["UE处于RRC_INACTIVE (CM-CONNECTED)"] --> B{"服务gNB是否为<br/>锚点gNB(最后服务gNB)?"}
    B -- "是" --> C["锚点gNB本地恢复上下文<br/>直接发INITIAL UE MESSAGE给AMF<br/>(无需Xn取上下文, 时延最低)"]
    B -- "否(UE已移动)" --> D["新gNB经Xn接口向锚点<br/>取回UE上下文(RRCResume成功)"]
    D --> C
    D -- "Xn取上下文失败" --> E["回退RRC重建立<br/>UE在RRCSetupComplete中携带<br/>含5G-S-TMSI的SERVICE REQUEST<br/>→ 汇入CM-IDLE标准流程"]
    C --> F["后续同标准流程:<br/>INITIAL CONTEXT SETUP / N4修改"]
```

这个设计的目标是把控制面信令收敛在**RAN内**（Xn接口），只有必要时才惊动AMF——这是5G降低小包业务时延（配合后来的RNA配置、寻呼优化）的关键路径。

---

## 五、状态机与定时器

### 5.1 5GMM状态转换（TS 24.501）

```mermaid
stateDiagram-v2
    [*] --> 5GMM_DEREGISTERED
    5GMM_DEREGISTERED --> 5GMM_REGISTERED_INITIATED : REGISTRATION REQUEST (T3550启动)
    5GMM_REGISTERED_INITIATED --> 5GMM_REGISTERED : REGISTRATION ACCEPT
    5GMM_REGISTERED --> 5GMM_SERVICE_REQUEST_INITIATED : 发送SERVICE REQUEST<br/>(T3517启动)
    5GMM_SERVICE_REQUEST_INITIATED --> 5GMM_REGISTERED : 收到任意NAS消息(非REJECT)<br/>T3517停止, 流程成功
    5GMM_SERVICE_REQUEST_INITIATED --> 5GMM_REGISTERED : T3517超时或收到<br/>SERVICE REJECT(计入尝试计数)
    5GMM_REGISTERED --> 5GMM_DEREGISTERED : 去注册(Deregistration或隐式)
```

TS 24.501专门定义了`5GMM-SERVICE-REQUEST-INITIATED`这个中间态。**T3517**是UE侧守护定时器：发出SERVICE REQUEST即启动，收到**任何非SERVICE REJECT的NAS消息**即停止——注意是“任何消息”，这解释了为什么AMF可以用REGISTRATION ACCEPT、DL NAS TRANSPORT等消息“顺带”终止Service Request流程。T3517超时后UE允许重发，但**尝试计数达到上限（5次）后UE将抑制继续发起**，直到条件变化（如更换小区/TA），防止弱覆盖下的信令风暴——这与AMF过载控制机制形成“UE侧自律+网络侧管制”的双保险。

### 5.2 SERVICE REJECT常见cause值速查

| Cause | 含义 | 排错方向 |
|---|---|---|
| #3 | Illegal UE | AMF查无此上下文/上下文非法；常见于5G-S-TMSI过期 |
| #7 | 5GS services not allowed | 签约/运营商策略禁止 |
| #10 | Implicitly deregistered | AMF隐式去注册定时器已到，上下文已删 |
| #20 | MAC failure | 完整性校验失败→UE需重新AKA鉴权 |
| #27 | N1 mode not allowed | 网络禁止该UE使用N1信令（如仅EPS场景） |
| #28 | Restricted service area | UE当前TA在禁止区域，切换小区后可恢复 |

---

## 六、实战：抓包识别与排错

### 6.1 抓包与过滤

N2接口为SCTP承载，端口**38412**（NGAP的SCTP PPID为60）。Wireshark常用过滤器：

```
sctp.port == 38412                          — 全部NGAP
ngap.procedureCode == 46                    — INITIAL UE MESSAGE
ngap.procedureCode == 9                     — INITIAL CONTEXT SETUP
nas_5gs.mm.message_type == 0x4c             — NAS SERVICE REQUEST (消息类型值76)
nas_5gs.mm.message_type == 0x4d             — NAS SERVICE REJECT
```

一条健康的UE触发流程在抓包里呈现为固定的四段式：**RRCSetupComplete携带SR → InitialUEMessage → InitialContextSetupRequest/Response → N4交互（若同时抓N4/SBI可完整对齐）**。交叉核对`INITIAL UE MESSAGE`中的5G-S-TMSI与此前REGISTRATION ACCEPT中AMF下发的5G-GUTI，可以验证AMF分配逻辑是否正确。

### 6.2 常见故障模式

1. **“反复SR但收不到InitialContextSetup”**：多因NAS完整性校验失败（cause #20）或AMF上下文缺失且旧AMF的ContextTransfer失败；检查ngKSI是否与AMF保存的密钥集一致、UE与AMF的NAS COUNT是否漂移（UE长时间休眠后计数不同步是经典问题）。
2. **“ContextSetup成功但无数据”**：信令面正常、用户面不通——优先查UPF的N4会话状态与PFCP关联（N3隧道是否真正写入）、防火墙对GTP-U（2152端口）的策略。
3. **“寻呼反复下发UE不响应”**：核对AMF的TAI List与UE实际驻留TA是否匹配（TA规划错误会导致“永不被呼”）；核查gNB侧SIB1中寻呼配置与P-RNTI计算参数。
4. **“RRC_INACTIVE场景时延异常”**：多为Xn取上下文失败频繁回退到RRC重建立，检查锚点gNB与新gNB间Xn建立与切片级Xn配置。
5. **试验网/新版本对接时的ASN.1解码失败**：Wireshark显示RAW/乱码，多为两端NGAP版本（Rel-15/16/17扩展IE）不对齐，比对两端基线版本。

### 6.3 实现层面的差异点（部署观察）

标准允许实现自由度的位置，正是多厂商对接的差异高发区：寻呼重发策略（次数、间隔、是否区分5QI做Paging Policy Differentiation）、INITIAL CONTEXT SETUP REQUEST中PDU会话的**全量恢复还是按需恢复**（Rel-16起SERVICE ACCEPT可携带PDU session status帮助UE与网络对齐会话视图，各实现对“恢复时机”取舍不同）、AMF池内ContextTransfer的触发阈值等。跨厂商联调时，建议先对齐这三类策略参数再排信令问题，可少走弯路。

---

## 七、与4G EPS Service Request的对比

| 维度 | 4G EPS（TS 24.301） | 5GS（TS 24.501） |
|---|---|---|
| 消息携带会话信息 | 携带EPS bearer context status、PTI，EPS承载随E-RAB逐一恢复 | **不含任何会话ID**，恢复范围由网络侧AMF/SMF决定 |
| MM/SM耦合 | 承载概念贯穿MM/SM，耦合较紧 | MM与SM彻底解耦（PDU会话独立于连接状态存在） |
| 中间状态 | 仅ECM-IDLE/CONNECTED二态 | 增加RRC_INACTIVE，SR可终结于RAN内部（Xn） |
| 应答行为 | Network一般以Activate Dedicated EPS Bearer Context等隐式应答 | 明确定义SERVICE ACCEPT补位逻辑，可携带PDU session status |
| 安全触发 | 完整性失败走类似路径但密钥层级为K_ASME | 基于ngKSI选K_AMF，密钥层级更细（K_gNB垂直派生） |
| 触发类型 | Service type仅区分“被叫”与“主叫信令” | 细分6种，含紧急、MPS高优先级 |

理解了“**UE不指定会话、网络决定恢复范围**”这一条，就理解了5G会话管理整个解耦设计的钥匙。

---

## 常见问题

**Q1: Service Request和Registration Request的区别是什么？**
A: Registration改变网络与UE的“注册关系”（区域、切片、签约生效），完成后UE获得5G-GUTI/TAI List/Allowed NSSAI；Service Request不改变任何注册属性，只把CM-IDLE的UE恢复到CM-CONNECTED并按需重建用户面。UE注册后驻留不动，期间每次业务唤醒走的都是SR，所以SR频率远高于Registration。

**Q2: 为什么5G的SERVICE REQUEST不带PDU Session ID，而4G的Service Request有承载关联？**
A: 4G的EPS bearer把MM和SM绑在一起，UE侧知道承载状态所以需要上报EPS bearer context status；5G把PDU会话设计为“与连接状态无关的持久对象”，会话的激活/去激活完全由网络管理，SR只表达“我到了”这个事实。好处是多会话跨SMF/跨切片时恢复逻辑简单，且UE与网络的会话状态即使短暂不一致也不阻塞连接建立（Rel-16再通过SERVICE ACCEPT中的PDU session status兜底同步）。

**Q3: RRC_INACTIVE状态下UE发的是SERVICE REQUEST还是RRC消息？**
A: 两者都发：空口上是`RRCResumeRequest`（携带I-RNTI），其内封装NAS SERVICE REQUEST（此时可不带5G-S-TMSI，因为锚点gNB凭I-RNTI即可定位上下文）。若gNB间Xn上下文获取失败，流程退化为RRC重建立，UE改用带5G-S-TMSI的SR走CM-IDLE路径。

**Q4: T3517超时后会怎样？会无限重试吗？**
A: 不会。超时后UE可重发SERVICE REQUEST，但按TS 24.501的尝试计数机制，连续5次失败后UE进入抑制状态，不再发起，直至条件变化（更换小区等）。这是标准的防信令风暴设计，也解释了弱覆盖下“手机突然长时间没信号但开机正常”的现象。

**Q5: 抓包里只有SERVICE REQUEST没有SERVICE ACCEPT，是流程失败了吗？**
A: 不一定。规范规定只有AMF没有其他NAS消息可发时才补发SERVICE ACCEPT；如果随后看到INITIAL CONTEXT SETUP REQUEST或DL NAS TRANSPORT，说明流程已被这些消息隐式终止，属正常现象。只有“SR之后什么都没有、且RRC被释放”才指向失败，此时查cause值和完整性校验。

---

## 参考来源

1. [3GPP TS 23.502（ Procedures for the 5G System）](https://www.3gpp.org/ftp/Specs/archive/23_series/23.502/) — §4.2.3.2 UE Triggered Service Request、§4.2.3.3 Network Triggered Service Request为本文主线依据
2. [3GPP TS 24.501（NAS protocol for 5GS）](https://www.3gpp.org/ftp/Specs/archive/24_series/24.501/) — SERVICE REQUEST/REJECT消息结构、Service type取值、T3517与5GMM状态机、尝试计数机制
3. [3GPP TS 38.413（NGAP）](https://www.3gpp.org/ftp/Specs/archive/38_series/38.413/) — INITIAL UE MESSAGE、INITIAL CONTEXT SETUP REQUEST/RESPONSE、Paging的IE定义与procedure code
4. [3GPP TS 23.003（Numbering, addressing and identification）](https://www.etsi.org/deliver/etsi_ts/123003_123099/123003/) — 第2.10节5G-GUTI/5G-S-TMSI位结构与AMF标识分配
5. [3GPP TS 33.501（Security architecture and procedures for 5GS）](https://www.3gpp.org/ftp/Specs/archive/33_series/33.501/) — ngKSI/K_AMF密钥体系、NAS完整性保护、K_gNB垂直派生

---
> 本文由「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)