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存在两条触发路径，它们的起点不同但最终汇合到同一条信令链路：

网络触发的场景中，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

时序图关键节点解读

三、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上下文：

这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上下文，需要从零建立：

设计要点：RRCSetup仅配置SRB1（信令承载），DRB在后续的RRCReconfiguration中才配置。这种两步设计将控制面和用户面解耦，AMF可以先完成鉴权和安全流程，再决定是否分配无线资源。

4.2 RRC_INACTIVE态：轻量级RRC Resume

UE处于RRC_INACTIVE时，gNB仍保留UE上下文（由I-RNTI标识），可通过更轻量的Resume流程恢复：

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中包含以下关键字段：

{
  "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准备恢复数据面：

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：

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<br/>UPF TEID + IP]
        C --> D[N2 SM Info: S-NSSAI]
    end
    subgraph gNB处理
        E[解析QoS Flow] --> F[映射到DRB]
        F --> G[分配AN Tunnel<br/>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 抓包过滤规则

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全链路定时器与计数器

9.2 Service Request vs Registration vs PDU Session Establishment对比

常见问题

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 — 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 — Section 8.2.9 Service Request message, Section 6.4.2 Service Request procedure
3. 3GPP TS 38.331 V18.4.0 — Section 5.3.7 RRC Resume, Section 6.2.2 RRCResumeRequest/RRCResume message definitions
4. 3GPP TS 29.502 V18.5.0 — Section 5.2.3 Nsmf_PDUSession_UpdateSMContext service operation
5. 3GPP TS 29.244 V18.3.0 — 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 等场景全覆盖。