在 5G 核心网中，UE 完成注册后并不会一直占用 NG-RAN 与核心网之间的 N2、N3 资源。为了节省空口与传输资源、降低 gNB 与 UPF 的内存压力，当 UE 一段时间没有上下行数据时，网络会执行 AN Release（TS 23.502 clause 4.2.6），将 UE 从 CM-CONNECTED 迁移到 CM-IDLE，释放 N2 信令连接、N3 用户面隧道以及 RRC 连接。此时 UE 进入 RRC_IDLE（或经过 RRC_INACTIVE 的 CM-CONNECTED），网络侧仅保留 UE 的注册上下文（在 UDSF/UDM 与 AMF/SMF 中），N2/N3 资源全部回收。
当 UE 再次需要收发数据或信令时，必须有一套机制把"已释放但已注册"的 UE 重新拉回在线状态，重新建立 NAS 信令连接、N2 连接以及 N3 用户面隧道。这套机制就是 Service Request（业务请求）流程，定义在 TS 23.502 clause 4.2.3，对应的 NAS 消息 SERVICE REQUEST 定义在 TS 24.501 section 8.2（消息内容表）与 section 9.11.3（各 IE 定义）。
它的设计意图可以归纳为三点：
Uplink data status / PDU session status 等位图 IE，一次性精确告诉网络"哪几个 PDU Session 需要恢复、哪几个有上行数据待发"，而不是逐条重建，减少信令往返。业务请求存在两条触发路径：UE 触发（UE 主动，对应 TS 23.502 clause 4.2.3.2）和网络触发（网络有下行数据/信令要送给空闲 UE，对应 clause 4.2.3.3 与 clause 4.2.3.4 的移动终接数据场景）。两者最终汇合到同一段"用户面重建"逻辑上。
下图给出 UE 在两种触发下共同经历的核心状态迁移：
stateDiagram-v2
[*] --> CM_IDLE: 注册成功后 AN Release
note right of CM_IDLE: 无N2/N3/RRC连接\n仅保留注册上下文
CM_IDLE --> CM_CONNECTED: UE触发 SERVICE REQUEST\n或响应Paging
note left of CM_CONNECTED: 有NAS信令连接+N2+N3\n可立即收发用户面
CM_CONNECTED --> CM_IDLE: AN Release (N2 Release)
当 UE 处于 CM-IDLE 且有上行信令/数据，或要响应寻呼时，UE 主动发起。完整信令链如下（TS 23.502 clause 4.2.3.2）：
sequenceDiagram
participant UE
participant gNB as gNB (NG-RAN)
participant AMF
participant SMF
participant UPF
Note over UE: CM-IDLE / RRC_IDLE\n有上行数据或响应寻呼
UE->>gNB: RRCSetupRequest (5G-S-TMSI, cause)
gNB-->>UE: RRCSetup
UE->>gNB: RRCSetupComplete\n(NAS: SERVICE REQUEST, NgKSI, Service type)
gNB->>AMF: NGAP Initial UE Message (NAS-PDU)
Note over AMF: 校验MAC完整性\n比对KAMF与NAS COUNT
AMF->>SMF: Nsmf_PDUSession_UpdateSMContext\n(Activate, N2 SM: PDU Session Resource Setup)
SMF->>UPF: N4 Session Modification\n(更新FAR, 通知RAN N3地址)
SMF-->>AMF: UpdateSMContext Response (含 N2 SM)
AMF->>gNB: NGAP Initial Context Setup Request\n(PDU Session Resource Setup List, NAS: SERVICE ACCEPT)
gNB->>UE: SecurityModeCommand + RRCReconfiguration\n(建立DRB, 携带 NAS: SERVICE ACCEPT)
UE-->>gNB: RRCReconfigurationComplete
gNB-->>AMF: Initial Context Setup Response (N3 TEID)
AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (上报N3地址)
Note over UE,UPF: CM-CONNECTED, N3用户面建立完成
逐消息解析关键 IE：
rrcSetupRequest-UE-identity 中携带 ng-5G-S-TMSI（响应寻呼时）或 random value，并带 establishmentCause（如 mo-Data、mo-Signalling、mt-Access）。mt-Access 让 gNB 立刻识别这是寻呼响应。RAN UE NGAP ID、User Location Information、RRC Establishment Cause。AMF 依据安全上下文校验 NAS 完整性。Operation = activate，请求 SMF 生成 N2 SM 信息（PDU Session Resource Setup）。这就是把"建立请求"翻译成 N2 接口动作的桥梁。PDU Session Resource Setup List、安全上下文（KgNB 推演参数）、QoS 流参数，并把 NAS 消息 SERVICE ACCEPT 捎带在内——这是 5G 把"激活"与"建链"合并的高效做法。PDU session status、PDU session reactivation result、PDU session reactivation result error cause，告诉 UE 哪些 Session 恢复成功、哪些失败及原因。设计要点：AMF 选择 Initial Context Setup 而非单独的"PDU Session Resource Setup"，是因为此时 UE 同时缺少 RRC 安全模式与 DRB。把 NAS Service Accept 捎带进 Initial Context Setup，省去一条独立的 NAS 直传消息——这是 5G 信令合并（piggyback）哲学的典型体现。
当 UE 处于 CM-IDLE、网络侧有下行数据要送达时，由网络触发。下行数据通知是这条链的真正起点（TS 23.502 clause 4.2.3.3 / 4.2.3.4）：
sequenceDiagram
participant DN as 外部DN
participant UPF
participant SMF
participant AMF
participant gNB as gNB
participant UE
Note over UE: CM-IDLE, 无N2/N3
DN->>UPF: 下行数据 (无活动N3隧道)
Note over UPF: 缓存 + 触发 Data Notification
UPF->>SMF: PFCP Session Report Request\n(Downlink Data Report)
SMF-->>UPF: PFCP Session Report Response
SMF->>AMF: Namf_Communication_N1N2MessageTransfer\n(N2 SM: 下行数据通知)
alt UE 在 CM-CONNECTED
AMF->>gNB: N2 PDU Session Resource Setup (直接建链)
else UE 在 CM-IDLE
AMF->>gNB: NGAP Paging (5G-S-TMSI, TAI列表)
gNB->>UE: RRC Paging (Paging Frame/Occasion)
UE->>gNB: RRCSetupRequest (mt-Access)
UE->>gNB: RRCSetupComplete (NAS: SERVICE REQUEST, Service type=MT)
gNB->>AMF: Initial UE Message (NAS-PDU)
Note over AMF: 投递缓存的N1N2, 建UP
end
Note over UE,UPF: 用户面恢复, 下行数据送达
关键机制解读：
Session Report Request，其中 Report Type = DLPD（下行数据报告），并按 PDR ID 标识是哪个 QoS 流/会话。SMF 回 Session Report Response 并可选择下发进一步缓冲参数。UE Paging Identity = 5G-S-TMSI、TAI List for Paging、可选 Paging Priority（按 ARP/5QI 提升优先级）。gNB 据 5G-S-TMSI 与 UE DRX 周期计算 Paging Frame/Paging Occasion，在空口发 RRC Paging。Service type = mobile terminated services，establishmentCause = mt-Access。AMF 据此把缓存的 N1N2 投递并完成 UP 恢复。可以看到，两条触发路径在"用户面重建"这一段完全汇合。下图给出 SERVICE REQUEST 的 IE 构成（依据 TS 24.501 消息内容表），其中 M=必选、O=可选：
flowchart TB
SR["SERVICE REQUEST 消息\n(TS 24.501 sec.8.2)"]
SR --> M1["扩展协议鉴别符 EPD=5GMM (M)"]
SR --> M2["安全头类型 Security header type (M)"]
SR --> M3["空半字节 Spare half octet (M)"]
SR --> M4["NgKSI 5GS密钥集标识 (M)\n指示用哪个 KAMF 做完整性保护"]
SR --> M5["Service type 服务类型 (M)\n决定业务优先级与建链语义"]
SR --> O1["Uplink data status (O)\n有上行数据的 PSI 位图"]
SR --> O2["PDU session status (O)\nUE 侧活动 PSI 位图"]
SR --> O3["Allowed PDU session status (O)\n希望网络恢复的 PSI"]
SR --> O4["NAS message container (O)\n捎带封装其他NAS消息"]
style M4 fill:#e3f2fd
style M5 fill:#fff3e0
style O1 fill:#f1f8e9
style O2 fill:#f1f8e9
style O3 fill:#f1f8e9
核心 IE 说明表：
| IE（TS 24.501 参考） | 存在性 | 作用与工程含义 |
|---|---|---|
| NgKSI（5GS key set identifier，9.11.3.27） | M | 指明完整性保护所用 NAS 安全上下文（native 或 mapped），含 TSC 与 KSI 值（7=无可用密钥）。AMF 据此找 KAMF 校验 MAC。 |
| Service type（9.11.3.47） | M | 区分信令/数据/移动终接/紧急/紧急回落/提升级信令，决定是否建 UP、是否走 EPS Fallback、是否提升优先级。 |
| Uplink data status（9.11.3.69） | O | PSI 位图，置位即该 Session 有上行数据待发；AMF 仅对其触发 UP 恢复，避免全量重建。 |
| PDU session status（9.11.3.42） | O | UE 侧"活动 Session"位图，AMF 与本地状态比对，发现不一致即触发 Release/重建，做状态同步。 |
| Allowed PDU session status（9.11.3.40） | O | UE 期望网络恢复的 PSI 子集，进一步收窄恢复范围。 |
| NAS message container（9.11.3.31） | O | 在业务请求内捎带封装额外 NAS 消息，减少信令往返。 |
Service type 取值（TS 24.501 9.11.3.47，半字节编码）：
| 编码（十进制） | 取值 | 触发场景与行为差异 |
|---|---|---|
| 0 | signalling | 仅建 NAS 信令连接，不建 UP；常用于纯信令（如周期性注册替代、UP 策略更新）。 |
| 1 | data | 建信令连接并恢复带 Uplink data status 的 Session 用户面。 |
| 2 | mobile terminated services | 响应网络寻呼/通知的标准取值。 |
| 3 | emergency services | 紧急业务，提升接入优先级（AC 11–15）。 |
| 4 | emergency services fallback | 紧急回落：AMF 据此触发 EPS Fallback（TS 23.502 clause 4.13.2），把 UE 切到 EPC 承载紧急语音。 |
| 5 | elevated signalling | MPS/优先级用户的提升级信令。 |
两条触发路径对比：
| 维度 | UE 触发（4.2.3.2） | 网络触发（4.2.3.3 / 4.2.3.4） |
|---|---|---|
| 起点 | UE 有上行数据/信令 | UPF 收到下行数据（或 SMF 有 N1 信令要发） |
| 是否寻呼 | 否（UE 自发接入） | CM-IDLE 时必须先 Paging |
| Service type 典型值 | data / signalling | mobile terminated services（UE 侧响应） |
| 关键前置消息 | RRCSetupRequest(mo-Data) | PFCP Session Report → N1N2 Transfer → NGAP Paging |
| 信令往返数 | 较少 | 多一次 Paging 往返 |
| 共同终点 | CM-CONNECTED + N2/N3 用户面恢复 | 同左 |
Uplink data status / PDU session status / Allowed PDU session status 用一张位图同时表达多个 PDU Session 的状态与诉求。这在 UE 同时有多个 Session（如一个 IMS、一个 internet）时，把 N 条潜在信令压成一次，是 5GC 相比 EPC 的显著信令优化。PDU session status 让 AMF 与 UE 对"哪些 Session 还活着"做对账。一旦某 Session 在网络侧已释放而 UE 不知情（如 N4 故障），AMF 可主动发 Release，避免半开状态。抓包识别（TShark/Wireshark）：
nas-5gs 协议，5GMM Message type = 0x4c（SERVICE REQUEST），Service accept = 0x4e，Service reject = 0x4d。建议用 nas-5gs.mm.message_type == 0x4c 定位。ngap 过滤，关注 InitialUEMessage（含 NAS-PDU）、InitialContextSetupRequest/Response、Paging（procedure code 0x02）。pfcp 过滤，定位 Session Report Request 中 report_type.downlink_data_report == 1，即可确认网络触发的真正起点。POST /namf-comm/v1/ue-contexts/{supi}/n1-n2-messages（N1N2MessageTransfer）。常见故障与排错思路：
PDU session reactivation result 与 error cause，常见因 SMF/UPF 间 N4 Session Modification 失败或 N3 地址协商异常。IMS voice over PS session supported Indication 与 NR 覆盖下的 voice support。Q: SERVICE REQUEST 和 Registration Request 都能建立 NAS 信令连接，区别是什么？ A: Registration 用于（重新）建立/更新 UE 与网络的注册关系，伴随身份、安全模式的可能重建；Service Request 用于已注册、处于 CM-IDLE 的 UE 快速恢复在线与用户面，不再做注册级鉴权，只做完整性校验。前者是"建档"，后者是"唤醒"。
Q: 网络触发的业务请求，UPF 怎么知道要通知 SMF？
A: PDU Session 建立时 SMF 已通过 N4 给 UPF 下发缓冲策略与"DL 数据到达上报"规则。当 UE 处于 CM-IDLE 无 N3 隧道时，UPF 缓冲数据并通过 PFCP Session Report Request（Downlink Data Report）上报 SMF，SMF 再发 N1N2MessageTransfer 给 AMF 触发 Paging。
Q: Uplink data status 和 Allowed PDU session status 都讲恢复，为什么要两个？
A: Uplink data status 是"事实"——哪些 Session 确实有上行数据待发；Allowed PDU session status 是"意愿"——UE 希望网络恢复哪些。AMF 通常取二者交集决定恢复范围，既避免恢复没数据的 Session，也尊重 UE 的偏好。
Q: 响应寻呼的 Service Request 为什么 Service type 取 mobile terminated services？ A: 这告诉 AMF 本请求是寻呼响应而非 UE 主动发起，AMF 据此把此前缓存的 N1N2 消息（下行数据通知/N1 信令）投递并完成用户面恢复，与 UE 触发的"主动发数据"路径在语义上区分，便于计费与流程分支判定。
Q: CM-CONNECTED 时还会有网络触发的业务请求吗？ A: 会。当 UE 在 CM-CONNECTED 但某 PDU Session 的 N3 用户面因空口释放等原因不可用（如 RRC_INACTIVE、AN 内部资源回收）时，网络可直接发 N2 PDU Session Resource Setup 重建用户面，无需 Paging。这也是网络触发分支中 CM-CONNECTED 与 CM-IDLE 两条子路径的由来。
本文由「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 等场景全覆盖。