5G Service Request（业务请求）信令流程全链拆解：CM-IDLE 态连接恢复与用户面重建机制

一、为什么 Service Request 是 5GS 协议栈最频繁的信令

在 5G 系统中，UE 一旦进入 CM-IDLE 态，意味着它与 AMF 之间的 NAS 信令连接被释放、与 (R)AN 之间的 N2 信令连接和 N3 用户面隧道也全部释放，仅保留注册状态和 PDU 会话上下文。当这个 UE 需要重新发送上行数据，或者网络有下行数据要送达它时，必须先恢复这条"端到端通道"——执行这一恢复动作的核心协议过程就是 Service Request（业务请求）。

按 3GPP TS 24.501 §5.6.1.1 的定义，Service Request 的根本目的是 "将 5GMM 模式从 5GMM-IDLE 改变为 5GMM-CONNECTED 模式"；按 TS 23.502 §4.2.3.1，它由处于 CM-IDLE 态的 UE 或 5GC 发起，用于：(1) 请求与 AMF 建立安全连接；(2) 恢复一个或多个 PDU 会话的用户面连接。

Service Request 与初始注册（Initial Registration）有本质区别：注册是 UE 首次接入网络、获取服务的"开户"动作，会建立完整的 UE 上下文；而 Service Request 是在已经注册的前提下，对一个"已注册但暂时离线"的 UE 进行"唤醒 + 重连"。从协议演进看，Service Request 继承自 4G EPC 的同名流程，但 5G 引入了 多 PDU 会话并行恢复、Uplink Data Status 位图、Allowed PDU Session Status、MICO/扩展空闲模式 DRX、异步通信、寻呼策略差异化 等新机制，使其复杂度远超 4G。

今天聚焦 TS 23.502 §4.2.3（Release 18），逐消息、逐 IE 拆解三类 Service Request 信令链，并给出抓包识别与排错实战。

二、触发条件：谁会发起 Service Request

2.1 UE 触发的场景（TS 24.501 §5.6.1.1）

2.2 网络触发的场景（TS 23.502 §4.2.3.3）

网络触发 Service Request 的核心是 "下行数据/下行信令到达，但 UE 离线"，常见于： - 场景 A：UPF 收到某 PDU 会话的下行数据，但 UPF 中没有该 PDU 会话的 AN 隧道信息（N3 隧道已释放）→ UPF 上报 Data Notification → SMF → AMF 发起 Paging； - 场景 B：SMF/SMSF/PCF/LMF 等需要用 Namf_Communication_N1N2MessageTransfer 向 UE 投递 N1 消息，且 UE 处于 CM-IDLE； - 场景 C：NF 使用 Namf_MT_EnableUEReachability 请求 AMF 建立与 UE 的 NAS 连接（如移动终止 SMS、定位）。

三、UE 触发的 Service Request：完整信令时序（TS 23.502 §4.2.3.2）

这是现网中最常见的形态——UE 从口袋里掏出手机准备发数据，触发的就是这条链路。

sequenceDiagram
    autonumber
    participant UE
    participant RAN as (R)AN/gNB
    participant AMF
    participant SMF
    participant UPF
    Note over UE: 处于 CM-IDLE，PDU会话上下文已存在但N3隧道释放
    UE->>RAN: RRC Setup Request (RRC Establishment Cause)
    RAN->>UE: RRC Setup
    UE->>RAN: RRC Setup Complete<br/>(携带 NAS Service Request)
    RAN->>AMF: N2 Initial UE Message (NAS Service Request, RRC Cause, User Location)
    Note over AMF: 解析Uplink Data Status，识别待恢复的PDU会话
    AMF->>AMF: 校验安全上下文(可能触发Security Mode Control)
    loop 对每个待恢复的PDU会话
        AMF->>SMF: Nsmf_PDUSession_UpdateSMContext<br/>(PDU Session ID, Operation="Activate", N2 SM Info pending)
        SMF->>UPF: N4 Session Modification Request<br/>(为该PDU会话重新分配/确认N3/N9隧道)
        UPF-->>SMF: N4 Session Modification Response
        SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response<br/>(N2 SM Info: QFI, QoS Profile, CN Tunnel Info)
    end
    AMF->>RAN: N2 Request (N2 SM Info, NAS Service Accept)
    RAN->>UE: RRC Reconfiguration (建立DRB, N3隧道对端地址)
    UE-->>RAN: RRC Reconfiguration Complete
    RAN->>AMF: N2 Request Ack (RAN Tunnel Info = TEID)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext<br/>(AN Tunnel Info)
    SMF->>UPF: N4 Session Modification (AN Tunnel Info)
    Note over UE,UPF: N3用户面隧道恢复，上下行数据可双向传输

3.1 关键信令消息解析

① NAS Service Request 消息（TS 24.501 §8.2.16）

这条 NAS 消息是整个流程的灵魂，它"搭载"在 RRC Setup Complete 中，经 gNB 透传给 AMF。其消息类型字段（Message type）固定为 0x4c，是抓包时识别该流程的第一指纹。

设计意图：UE 在一条 NAS 消息里用位图一次性表达"我现在有哪些会话、哪些急着想发数据、哪些请你别动"三重信息，让 AMF 可以批量为多个 PDU 会话并行触发用户面恢复，避免逐会话往返——这是 5G 相对 4G 在"恢复效率"上的关键优化。

② N2 Initial UE Message（TS 38.413）

gNB 收到 RRC 消息后，用 NGAP 的 Initial UE Message 把 NAS PDU 上交给 AMF，并携带 RRC Establishment Cause（如 mo-Signalling、mo-Data、mt-Access）、User Location Information（TAI+NR-CGI）、UE Context Request 等关键 IE。其中 RRC Cause 反过来帮助 AMF 判断这是 UE 主动发起还是响应 Paging。

③ Nsmf_PDUSession_UpdateSMContext（TS 23.502 §4.2.3.2 step 4）

AMF 对每个待恢复的 PDU 会话，向其锚点 SMF 发起 SBI 更新，关键参数包括 PDU Session ID、PDU Session Resource Setup Transfer（N2 SM Info）、Operation type = "Activate"。SMF 据此通过 N4 Session Modification 让 UPF 准备好接收下行数据（安装转发规则、确认 N9 隧道），并把 N2 SM Info（含 QFI、QoS Profile、CN N3 Tunnel Info）回给 AMF。

④ N2 Request（PDU Session Resource Setup）与 RRC Reconfiguration

AMF 把 N2 SM Info 装进 NGAP 下行消息发给 gNB，gNB 通过 RRC Reconfiguration 建立 DRB（数据无线承载），并把 UPF 的 N3 隧道对端地址告诉 UE 侧协议栈。UE 回复 RRC Reconfiguration Complete 后，gNB 用 N2 Request Ack 把自己分配的 AN Tunnel Info（TEID）上报，AMF 再回传给 SMF/UPF，至此 N3 用户面隧道双向打通。

四、网络触发的 Service Request：从下行数据到 Paging 再到连接（TS 23.502 §4.2.3.3）

网络触发链路的"前半段"在核心网内部完成（UPF→SMF→AMF），后半段才转化为 Paging，最终落到 UE 触发的 Service Request。

sequenceDiagram
    autonumber
    participant UE
    participant RAN
    participant AMF
    participant SMF
    participant UPF
    Note over UPF: 收到下行数据包，但无AN隧道信息(N3已释放)
    alt UPF缓存模式
        UPF->>UPF: 缓存下行数据(步骤2a/2b)
        UPF->>SMF: Data Notification(N4 Session ID, QFI, DSCP)
        SMF-->>UPF: Data Notification Ack
    else SMF缓存模式
        UPF->>SMF: 转发下行数据包(步骤2c)
    end
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(SUPI, PDU Session ID, N2 SM Info:<br/>QFI/QoS Profile/CN N3 Tunnel Info/S-NSSAI, ARP, Paging Policy Indicator)
    alt UE在AMF为CM-CONNECTED
        AMF-->>SMF: 响应(N1/N2已下发)
        Note over AMF: 流程跳转至步骤6，直接走N2下发
    else UE在AMF为CM-IDLE
        AMF-->>SMF: 响应(尝试联系UE，N2 SM Info可能需重发)
        AMF->>RAN: Paging(UE Paging Identity, TAI List,<br/>Paging Priority, 服务类型)
        RAN->>UE: 空口 Paging
        UE->>RAN: 触发UE Initiated Service Request(响应Paging)
        Note over UE,SMF: 接续第三节流程，恢复用户面
        SMF->>UPF: 缓存数据/转发下行数据经N3
    end

4.1 Data Notification 与缓冲策略（TS 23.501 §5.8.3）

这是网络触发流程最精妙的设计。当 UPF 收到下行数据却发现"对端隧道没了"，并不会直接丢弃，而是：

• UPF 缓冲（UPF-based buffering）：UPF 自行缓存数据包，向 SMF 发送 Data Notification（携带 N4 Session ID、QFI、DSCP）；SMF 回复 Data Notification Ack。
• SMF 缓冲（SMF-based buffering）：若 SMF 指示，UPF 直接把数据包转发给 SMF 缓存，待用户面恢复后再发。

这种"缓冲 + 通知"机制保证了 CM-IDLE UE 在被唤醒期间到达的下行数据不丢失。当 扩展缓冲（Extended Buffering） 启用时（典型于 MICO 模式或扩展空闲 DRX），SMF 会在 N1N2MessageTransfer 中携带 "扩展缓冲支持"指示，AMF 若判定 UE 暂不可达，会在拒绝响应里回送 "估计的最大等待时间"（依据 UE 下次周期性注册时间或下一个寻呼时间窗口推算），供 SMF 决定缓冲多久。

4.2 寻呼策略差异化（Paging Policy Differentiation，TS 23.501 §5.4.3）

当 PDU 会话类型为 IP 时，UPF 会从下行数据包的 IP 头取出 DSCP（IPv4）/ TC（IPv6），连同 QFI 一起放进 Data Notification。SMF 据此推导出 Paging Policy Indicator（PPI），再通过 N1N2MessageTransfer 交给 AMF，最终影响空口 Paging 的优先级。这意味着高优先级业务（如 IMS 语音）的下行数据能更快唤醒 UE。

4.3 AMF 的多重可达性判定

收到 N1N2MessageTransfer 后，AMF 并非无条件 Paging，而是要逐项判定： - UE 是否处于 CM-IDLE 且 AMF 能寻呼到； - 是否存在 Paging Restriction（寻呼限制，TS 23.501 §5.38.1）； - UE 是否处于 MICO 模式 / 扩展空闲 DRX / 仅非 3GPP 注册 等导致不可达； - UE 是否在 不允许区域（Non-Allowed Area）； - 是否启用了 异步通信（Asynchronous Type Communication）——若是，AMF 先缓存消息，等 UE 进 CM-CONNECTED 再投递。

任一判定失败，AMF 都会以带原因值的响应拒绝 SMF，避免无效寻呼风暴。

五、Service Accept / Service Reject：流程的收尾与异常分支

stateDiagram-v2
    [*] --> CM_IDLE: UE注册成功后释放NAS连接
    CM_IDLE --> CM_CONNECTED: UE/NW触发Service Request成功<br/>(Service Accept)
    CM_CONNECTED --> CM_IDLE: AN Release(UE Context Release)
    CM_IDLE --> CM_IDLE: Service Reject(保持5GMM-REGISTERED)
    CM_CONNECTED --> CM_CONNECTED: Service Request<br/>(CM-CONNECTED态激活用户面)
    note right of CM_IDLE
        仅5GMM-REGISTERED.ATTEMPTING在non-allowed area
        可发elevated signalling
    end note

• Service Accept：当 AMF 成功恢复信令连接/用户面，回复 Service Accept，可携带 PDU Session Status（网络侧视角）与 PDU Session Reactivation Result（哪些会话恢复成功/失败），让 UE 与网络对齐状态。
• Service Reject：当 UE 处于不允许区域、网络拒绝时，回送 Service Reject（TS 24.501 §8.2.18）。UE 进入 5GMM-REGISTERED 但停止 T3517，若非紧急业务，UE 需重新发起注册；若消息携带 T3346（退避定时器），UE 在该定时器超时前不得重发，除非高优先级/紧急/响应 Paging。

5.1 PDU Session Status 对齐机制

这是 Service Request 易被忽视但极重要的副作用。UE 与 AMF 各自维护一份 PDU 会话状态位图，Service Request/Service Accept 是双方"对账"的时刻：若 AMF 发现 UE 上报的某会话状态与自己存储的不一致（如 UE 侧已释放但网络侧还认为 active），AMF 可通过 Configuration Update Command 或后续过程发起去激活，保持 UE 与 5GC 的会话视图同步。

六、抓包实战：如何识别一条 Service Request

工具：Wireshark + ngap / nas-5gs / pfcp 解析器（需配合 KSEa / SQN 解密 NAS）。

过滤表达式速查：

识别要点： 1. 在空口/N2 侧，先看到 RRC Setup（三步接入）→ RRC Setup Complete 里嵌 NAS message type = 0x4c，即可确认 Service Request； 2. 展开 NAS 消息，检查 Service type 字段：data（0x01）= 有上行数据；signalling（0x00）= 仅有信令；elevated signalling（0x03）= 高优先级； 3. 检查 Uplink Data Status 位图，与紧随其后的 N4 Session Modification 一一对应，验证用户面恢复范围； 4. 若是网络触发，先于 Paging 出现的应是 UPF→SMF 的 Data Notification（N4 接口）与 SMF→AMF 的 N1N2MessageTransfer（HTTP/2 SBI）。

七、常见故障点与排错思路

八、Release 18 中的增强点

R18 在 Service Request 框架下持续演进，值得关注的增强包括： - 异步通信（Asynchronous Communication）与 MICO 的协同：NF 触发的消息可在 AMF 缓存，待 UE 可达再投递，减少寻呼； - 多接入 PDU 会话（ATSSS）场景下 Service Request 的 MA PDU session information 处理； - 卫星/非地面网络（NTN）场景下，配合更长往返时延对 Service Request 计时器与寻呼窗口的调整； - RedCap / CIoT 终端下扩展缓冲与用户面 IoT 优化（TS 23.501 §5.31.8）对 Service Request 的精简。

九、常见问题

Q1: Service Request 和 Registration 有什么本质区别？ A: Registration 是"开户/接入"——UE 首次或重新建立注册关系，建立/更新 UE 上下文（包括鉴权、获取临时 ID、TAI List 等）；Service Request 是"唤醒/重连"——在已注册前提下，把一个 CM-IDLE 的 UE 重新拉回 CM-CONNECTED 并恢复用户面，不改变注册关系本身。Service Request 失败可能要求重新 Registration，但二者目的和信令内容完全不同。

Q2: UE 触发和网络触发的 Service Request，最终信令链路是否相同？ A: 后半段相同。网络触发的前半段在核心网内（UPF Data Notification → SMF → AMF N1N2MessageTransfer → AMF Paging），一旦 UE 收到 Paging 并响应，就转化为标准的 UE 触发 Service Request（§4.2.3.2），后续用户面恢复链路完全一致。

Q3: Uplink Data Status 和 PDU Session Status 这两个位图有什么区别？ A: PDU Session Status 表达"UE 侧认为当前哪些 PDU 会话是 active 的"（状态对账用）；Uplink Data Status 表达"哪些 PDU 会话此刻有上行数据急着想发"（驱动用户面恢复）。前者是"有什么"，后者是"现在要什么"。AMF 主要依据后者决定为哪些会话发起 N2 SM Info 下发。

Q4: 为什么 CM-CONNECTED 态也会用 Service Request？ A: CM-CONNECTED 态下 N2/N1 信令连接还在，但某个 PDU 会话的用户面连接可能被去激活（User Plane Deactivated，TS 23.502 §4.2.3 描述 SR 在 CM-IDLE 和 CM-CONNECTED 均可用于激活用户面）。此时 Service Request 不需要重建 RRC/N2，仅触发 N4 修改与 N2 SM Info 恢复用户面，是"局部"用户面激活。

Q5: Service Reject 里的 T3346 和注册拒绝里的 T3346 是一回事吗？ A: 概念上都是"退避定时器"，让 UE 在拥塞时退避，但触发场景不同：注册流程的 T3346 用于 Registration Reject，Service Request 的 T3346 用于 Service Reject。两者都要求 UE 在超时前不得重发（紧急/高优先级/响应 Paging 除外）。

参考来源

1. 3GPP TS 23.502 — Procedures for the 5G System, §4.2.3 Service Request — UE 触发与网络触发业务请求流程定义
2. 3GPP TS 24.501 — NAS protocol for 5G, §5.6.1.1 / §8.2.16 — Service Request 过程目的与 NAS 消息 IE 结构
3. 3GPP TS 38.413 — NG-RAN NGAP, Initial UE Message / Paging — N2 接口信令 IE
4. ShareTechnote — 5G Service Setup — Service Request 触发条件与 NAS 消息字段图解
5. Cisco Ultra Cloud Core 5G SMF — UP Session Activation/Deactivation Service Request Procedures — SMF 侧用户面激活/去激活实现细节
6. 通信大视野 / 博客园 — 5G 系统流程 Service Request 网络触发 — Data Notification 与 N1N2MessageTransfer 中文流程解析

本文由「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 等场景全覆盖。