# 5G业务请求信令唤醒全链路解码
在5G网络中，终端（UE）大部分时间处于CM-IDLE或RRC_INACTIVE态以节省电量。当有数据需要收发时，一条NAS **Service Request**消息便如同闹钟，将整个数据面从沉睡中唤醒——从空口RRC连接建立，到N2/N3隧道重建，再到UPF缓冲数据下发，涉及**UE、gNB、AMF、SMF、UPF**五个网元、四个接口、至少13步信令交互。本文基于3GPP TS 23.502 Section 4.2.3.2、TS 24.501 Section 8.2.9、TS 38.331 Section 5.3.7等核心规范，对这条"唤醒链路"进行逐字节、逐消息的全链路拆解。
---
## 一、Service Request的触发场景与设计意图
### 1.1 两种触发路径
5G Service Request存在两条触发路径，它们的起点不同但最终汇合到同一条信令链路：
| 触发类型 | 起点 | 典型场景 | 规范章节 |
|----------|------|----------|----------|
| **UE触发** | UE有上行数据/信令需要发送 | 用户打开APP、发起呼叫 | TS 23.502 §4.2.3.2 |
| **网络触发** | UPF收到下行数据但N3隧道不存在 | 来电、推送通知、下行数据到达 | TS 23.502 §4.2.3.3 |
网络触发的场景中，**UPF充当"守门人"**——当UE处于CM-IDLE态时，N3用户面隧道已被拆除，UPF无法将下行数据转发给gNB。此时UPF会：
1. 将下行数据包缓存在本地缓冲区
2. 通过N4接口向SMF发送**Downlink Data Notification (DDN)**
3. SMF通过`Namf_Communication_N1N2MessageTransfer`通知AMF
4. AMF在UE注册的TAI List范围内发起**Paging**
> *图表 1*
### 1.2 设计意图：为什么不是"重建PDU Session"？
Service Request的核心设计哲学是**"恢复"而非"重建"**。当UE从CM-IDLE态被唤醒时，其PDU Session的上下文仍然保存在SMF和UPF中——被释放的只是N2/N3隧道和无线承载DRB。Service Request通过**Nsmf_PDUSession_UpdateSMContext**操作复用已有的PDU Session上下文，仅需重新建立隧道映射，避免了完整的PDU Session Establishment流程（后者涉及DHCPv6、IP地址分配、计费触发等重量级操作），将唤醒时延从数百毫秒压缩到50-100ms量级。
---
## 二、完整信令时序图
以下时序图展示了从UE发出Service Request到数据面完全打通的全链路过程：
> *图表 2*
### 时序图关键节点解读
| 阶段 | 涉及接口 | 关键操作 | 规范依据 |
|------|----------|----------|----------|
| 阶段一 | Uu, N2 | RRC连接建立+NAS Service Request传输 | TS 38.331 §5.3.2, TS 24.501 §8.2.9 |
| 阶段二 | N1, N11 | NAS安全验证+SM上下文更新 | TS 24.501 §6.4.2, TS 29.502 §5.2 |
| 阶段三 | N4 | SMF获取UPF侧隧道信息 | TS 29.244 §7.5.4 |
| 阶段四 | N2, Uu | N2资源建立+DRB配置 | TS 38.413 §8.4.1, TS 38.331 §5.3.5 |
| 阶段五 | N11, N4 | 隧道确认+数据面打通 | TS 23.502 §4.2.3.2 Step 12-16 |
---
## 三、NAS Service Request消息结构深度解析
### 3.1 消息整体编码
根据TS 24.501 Section 8.2.9，NAS Service Request的MessageType值为**0x53（十进制83）**，其整体编码结构如下：
```
| Octet 1: Extended Protocol Discriminator (0x7E = 5GS Mobility Management) |
| Octet 2: Spare Half Octet (0x0) + Security Header Type (0x0 = No Security) |
| Octet 3-4: Message Type (0x53) + Spare Half Octet |
| Octet 5-10: 5G-S-TMSI (48 bits) |
| ... Optional IEs follow ... |
```
### 3.2 关键Information Element详解
#### 5G-S-TMSI（必选IE，48 bits）
5G-S-TMSI是Service Request中最核心的IE，AMF通过它定位UE的MM上下文：
| 字段 | 比特长度 | 说明 |
|------|----------|------|
| AMF Set ID | 10 bits | 标识AMF集合，用于AMF选择 |
| AMF Pointer | 6 bits | 集合内具体AMF实例 |
| 5G-TMSI | 32 bits | AMF内UE唯一标识 |
这48比特的设计有深意：AMF Set ID（10 bits）支持最多1024个AMF集合，使网络能够在**AMF集合级别**进行负载均衡，而非单个AMF实例级别。当UE移动到新TA时，新gNB可以根据5G-S-TMSI中的AMF Set ID路由到正确的AMF集合。
#### PDU Session Status（可选IE，Bitmap）
这是一个**位图（bitmap）**结构，每一位对应一个PDU Session Identity（PSI），告知网络UE侧哪些PDU Session仍然处于活跃状态：
```
| IEI (1 octet) | Length (2 octets) | Bitmap (variable) |
| PSI 1 | PSI 2 | ... | PSI 16 |
| bit 1 | bit 2 | ... | bit 8 | (Octet 1)
```
**编码规则**：第 *n* 个bit位为1，表示PSI=n的PDU Session在UE侧处于active状态。
#### Uplink Data Status（可选IE，Bitmap）
与PDU Session Status结构相同，但语义不同——bit=1表示UE在该PDU Session上有**待发送的上行数据**。AMF据此决定哪些PDU Session需要优先恢复用户面资源。
### 3.3 NAS Service Request IE决策树
> *图表 3*
---
## 四、RRC层：从IDLE/INACTIVE到CONNECTED的双路径
Service Request的底层传输依赖RRC连接，但RRC_INACTIVE态和RRC_IDLE态的路径完全不同：
### 4.1 RRC_IDLE态：全新RRC连接建立
UE处于RRC_IDLE时，没有任何RRC上下文，需要从零建立：
| 步骤 | 消息 | 信道 | 关键IE |
|------|------|------|--------|
| 1 | RRCSetupRequest | SRB0/CCCH | 40-bit随机/Identity值 |
| 2 | RRCSetup | SRB0/CCCH | radioBearerConfig(SRB1) |
| 3 | RRCSetupComplete | SRB1/DCCH | selectedPLMN-Identity + NAS Service Request |
**设计要点**：RRCSetup仅配置SRB1（信令承载），DRB在后续的RRCReconfiguration中才配置。这种两步设计将**控制面和用户面解耦**，AMF可以先完成鉴权和安全流程，再决定是否分配无线资源。
### 4.2 RRC_INACTIVE态：轻量级RRC Resume
UE处于RRC_INACTIVE时，gNB仍保留UE上下文（由I-RNTI标识），可通过更轻量的Resume流程恢复：
| 步骤 | 消息 | 信道 | 关键IE |
|------|------|------|--------|
| 1 | RRCResumeRequest | SRB0/CCCH | I-RNTI + resumeCause + resumeMAC-I |
| 2 | RRCResume | SRB0/CCCH | radioBearerConfig + masterCellGroup + fullConfig(可选) |
| 3 | RRCResumeComplete | SRB1/DCCH | NAS Service Request(上行的pending UL data) |
**resumeMAC-I**是Resume流程的安全核心——这是一个基于之前保存的**K_RRCint**密钥和I-RNTI计算出的16-bit MAC校验值，让新gNB（如果不是最后服务gNB）能通过Xn接口向最后服务gNB请求验证UE上下文的真实性。
### 4.3 DRB重建的PDCP/RLC层操作
当gNB在RRCResume/RRCReconfiguration中指示恢复DRB时，UE的协议栈执行以下操作：
> *图表 4*
**PDCP状态保留是关键**：对于AM（Acknowledged Mode）DRB，PDCP Status Report让发送端知道哪些SDU已被对端确认，避免数据重传丢失。这就是为什么Resume比全新的Setup在数据完整性上更优。
---
## 五、N2/N3隧道重建：SMF的指挥枢纽角色
### 5.1 Nsmf_PDUSession_UpdateSMContext（TS 29.502 §5.2.3.1）
这是Service Request流程中AMF与SMF之间的核心交互。AMF调用此SBI操作时，Request Body中包含以下关键字段：
```json
{
"n2SmInfoType": "PDU_RES_SETUP_REQ",
"n2SmInfo": {
"pduSessionId": 1,
"qosFlowSetupRequestList": [
{
"qosFlowIdentifier": 1,
"qosFlowLevelQosParameters": {
"qosCharacteristics": {"5qi": 9},
"allocationAndRetentionPriority": {"priorityLevel": 15}
}
}
]
},
"ueLocation": {"nrLocation": {...}},
"anType": "3GPP_ACCESS"
}
```
SMF收到后执行两个并行操作：
1. **N4 Session Modification**：向UPF获取DL N3 Tunnel Info（UPF侧的TEID和IP地址）
2. **构造N2 SM Information**：包含QoS Flow描述和UPF隧道信息，返回给AMF
### 5.2 N4/PFCP Session Modification（TS 29.244 §7.5.4）
SMF通过PFCP Session Modification Request通知UPF准备恢复数据面：
| IE | 类型 | 说明 |
|----|------|------|
| Create FAR | Mandatory | 创建新的Forwarding Action Rule，指示UPF将下行数据转发到新的AN Tunnel |
| Update FAR | Conditional | 更新已有FAR，添加新的Outer Header Creation（gNB IP+TEID） |
| Apply Action | Mandatory | FORW（转发）标志位置1 |
| BAR ID | Optional | Buffering Action Rule标识，用于释放缓冲 |
**UPF侧的关键动作**：UPF在收到携带新AN Tunnel Info的N4 Modification后，将缓存在Buffer中的下行数据包打上新的GTP-U Outer Header（目标为gNB的N3 IP和TEID），通过N3隧道发送出去。这个过程就是UPF缓冲数据的"排空"。
### 5.3 N2 PDU Session Resource Setup（TS 38.413 §8.4.1）
AMF将SMF返回的N2 SM Information通过**N2 PDU Session Resource Setup Request**发送给gNB：
```text
flowchart LR
subgraph AMF构造N2 Request
A[NAS Service Accept] --> B[N2 SM Info: QoS Flow List]
B --> C[N2 SM Info: UL Tunnel Info
UPF TEID + IP]
C --> D[N2 SM Info: S-NSSAI]
end
subgraph gNB处理
E[解析QoS Flow] --> F[映射到DRB]
F --> G[分配AN Tunnel
gNB TEID + IP]
G --> H[构造RRCReconfiguration]
end
AMF构造N2 Request --> gNB处理
```
gNB的核心工作是**QoS Flow到DRB的映射**：
- 每个5QI对应的QoS Flow需要映射到一个DRB
- 多个QoS Flow可以复用同一个DRB（通过不同的QFI标记区分）
- gNB根据QoS参数（5QI、ARP、GBR/Non-GBR）决定DRB的无线资源配置
---
## 六、状态转换全景图
> *图表 6*
**RRC_INACTIVE态的特殊性**：UE处于RRC_INACTIVE时，NAS层面仍然认为是**CM-CONNECTED**状态（N2关联仍存在），但RRC连接和DRB被挂起。这意味着Service Request在此场景下可以走更快的RRC Resume路径，跳过完整的RRC Setup和AMF鉴权流程。
---
## 七、实战：抓包识别与故障排查
### 7.1 抓包过滤规则
| 接口 | 抓包工具 | 过滤条件 |
|------|----------|----------|
| Uu（空口） | QXDM/XCAL | `NAS-5GS.MessageType == 0x53` |
| N2（NGAP） | Wireshark | `ngap.procedureCode == 15`（InitialUE）+ `nas-5gs.message_type == 83` |
| N11（SBI） | tcpdump | HTTP body中`"n2SmInfoType": "PDU_RES_SETUP_REQ"` |
| N4（PFCP） | Wireshark | `pfcp.message_type == 53`（Session Modification Request） |
### 7.2 常见故障点与排错思路
#### 故障一：Service Request被AMF拒绝
**现象**：UE收到NAS Service Reject，Cause Value为 `#27 (N1 mode not allowed)` 或 `#22 (Congestion)`
**排错路径**：
1. 检查AMF日志确认UE的RM状态是否为RM-DEREGISTERED（如果是，说明UE未完成Registration）
2. 检查AMF是否触发了过载控制（TS 23.502 §4.2.6），此时AMF会在Service Reject中携带back-off timer
3. 检查5G-S-TMSI是否有效——如果AMF重启导致上下文丢失，将无法匹配UE
#### 故障二：PDU Session Resource Setup在gNB失败
**现象**：N2 Request Ack中携带**PDU Session Resource Failed to Setup List**，Cause为"Multiple PDU Session ID instances"或"QoS Flow Allocation Failure"
**排错路径**：
1. 检查gNB的无线资源是否充足（PRB利用率、DRB数量上限）
2. 检查QoS Flow的5QI值是否在gNB支持的范围内
3. 检查S-NSSAI（切片标识）是否与gNB配置的切片一致
#### 故障三：UPF缓冲数据丢失
**现象**：Service Request成功但UE收不到预期的下行数据包
**排错路径**：
1. 检查UPF的Buffer容量配置——部分厂商默认Buffer仅256KB
2. 检查N4 Session Modification中BAR（Buffering Action Rule）是否正确释放
3. 检查UPF是否在DDN发送后启动了缓冲定时器，超时后丢弃数据
## 八、Release 18增强：Service Request的新维度
### 8.1 Small Data Transmission (SDT)与Service Request的融合
Release 17/18引入的SDT机制允许UE在RRC_INACTIVE态直接传输小数据包，无需完整的Service Request流程。这对Service Request的影响是：
- **CIoT设备**：数据量<1000字节时，通过RRCResumeRequest携带NAS Data PDU直接发送，跳过N2/N3隧道建立
- **触发条件**：UE在RRC_INACTIVE态，且配置了`mt-Data`或`mo-Data`的SDT允许指示
- **回退机制**：如果数据量超过SDT阈值，gNB触发full Service Request
### 8.2 Multi-USIM场景下的Service Request冲突
Release 18支持双SIM双待设备在Service Request中指示**Multi-USIM**能力：
- UE在Service Request中可携带**MULTI-USIM IE**，通知AMF该UE可能需要临时中断当前USIM的连接
- AMF在处理MT Service Request时，可以配置**MPS-PriorityAccess**或**MCS-PriorityAccess**以区分优先级
- 当两个USIM同时收到Paging时，UE可以选择性响应其中一个，另一个USIM的Paging将丢失
---
## 九、关键参数对照表
### 9.1 Service Request全链路定时器与计数器
| 参数 | 默认值 | 作用 | 规范 |
|------|--------|------|------|
| T3517（Service Request） | 5秒 | UE等待Service Accept的超时 | TS 24.501 §10.2.7 |
| T3517ext | 10秒 | MO SMS场景的扩展超时 | TS 24.501 §10.2.7a |
| NAS Back-off Timer | 可变 | AMF过载时拒绝并指示UE退避 | TS 24.501 §8.2.9.5 |
| RRC Resume定时器 | gNB配置 | gNB等待RRCResumeComplete | TS 38.331 §7.1 |
| N4 Session Mod超时 | SMF配置 | SMF等待UPF响应 | TS 29.244 |
### 9.2 Service Request vs Registration vs PDU Session Establishment对比
| 维度 | Service Request | Registration | PDU Session Establishment |
|------|----------------|--------------|---------------------------|
| 触发条件 | 数据到达/寻呼响应 | 开机/TA变更/周期性 | 新数据业务需求 |
| 涉及网元 | UE-gNB-AMF-SMF-UPF | UE-gNB-AMF(+AUSF/UDM) | UE-gNB-AMF-SMF-UPF-PCF |
| N4操作 | Session Modification | 无 | Session Establishment |
| NAS消息 | Service Request/Accept | Registration Request/Accept | PDU Session Est Request/Accept |
| 用户面操作 | 恢复已有隧道 | 不涉及 | 新建隧道+IP分配 |
| 典型时延 | 50-100ms | 200-500ms | 100-300ms |
| 安全操作 | 可选NAS SMC | 必选完整AKA | 依赖已有安全上下文 |
---
## 常见问题
**Q1: Service Request和RRC Resume是什么关系？**
A: Service Request是NAS层消息，RRC Resume是RRC层过程。当UE处于RRC_INACTIVE态时，NAS Service Request封装在RRCResumeComplete消息中通过SRB1传输给gNB，gNB再通过N2接口将NAS消息转发给AMF。两者是承载关系，不是替代关系。如果UE处于RRC_IDLE态，则使用RRC Setup流程承载Service Request。
**Q2: UPF缓冲数据会不会在Service Request过程中丢失？**
A: 有可能。UPF的缓冲区大小有限（通常256KB-1MB），如果下行数据持续到达且Service Request流程耗时过长（如AMF过载排队），超出缓冲容量的数据包将被丢弃。部分厂商支持DDN Forwarding机制——UPF可以在缓冲满时通过N4接口将数据包转发给SMF临时存储。
**Q3: 一个UE有多个PDU Session时，Service Request如何处理？**
A: NAS Service Request中的**Uplink Data Status** bitmap指示哪些PDU Session需要恢复用户面。AMF为每个需要恢复的PDU Session分别调用`Nsmf_PDUSession_UpdateSMContext`（并行或串行取决于厂商实现），然后在一条N2 Request中汇总所有PDU Session的N2 SM Information发给gNB。gNB在单次RRCReconfiguration中配置所有需要的DRB。
**Q4: Service Request为什么不需要完整鉴权？**
A: Service Request消息本身受NAS安全保护（完整性保护），AMF通过5G-S-TMSI定位UE的MM上下文，并验证消息中的MAC-I。只有在安全上下文失效或AMF重启丢失上下文时，AMF才会触发完整的鉴权流程。这是Service Request时延远低于Registration的关键原因。
**Q5: 网络触发的Service Request和UE触发的有什么信令差异？**
A: 信令路径相同，差异仅在起点。网络触发时，AMF先发Paging（包含5G-S-TMSI和Access Type），UE收到Paging后发出的Service Request中resumeCause为`mt-Access`。UE主动触发时，resumeCause为`mo-Data`或`mo-Signalling`。AMF会根据触发原因决定是否对所有PDU Session恢复用户面——MT场景通常只恢复触发Paging的那个Session。
---
## 参考来源
1. [3GPP TS 23.502 V18.6.0](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.2.3.2 UE-Triggered Service Request, Section 4.2.3.3 Network-Triggered Service Request
2. [3GPP TS 24.501 V18.5.0](https://www.3gpp.org/DynaReport/24501.htm) — Section 8.2.9 Service Request message, Section 6.4.2 Service Request procedure
3. [3GPP TS 38.331 V18.4.0](https://www.3gpp.org/DynaReport/38331.htm) — Section 5.3.7 RRC Resume, Section 6.2.2 RRCResumeRequest/RRCResume message definitions
4. [3GPP TS 29.502 V18.5.0](https://www.3gpp.org/DynaReport/29502.htm) — Section 5.2.3 Nsmf_PDUSession_UpdateSMContext service operation
5. [3GPP TS 29.244 V18.3.0](https://www.3gpp.org/DynaReport/29244.htm) — Section 7.5.4 PFCP Session Modification, BAR and FAR operations
---
> 本文由「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 等场景全覆盖。
