5G NAS Service Request信令流：从CM-IDLE到CM-CONNECTED的全链路拆解

一、机制概述：为什么需要Service Request？

在5G系统中，UE（用户设备）大部分时间处于CM-IDLE状态——NAS信令连接不存在、RRC连接已释放、无线资源已回收。但当UE有上行数据待发送（如用户点击微信发送消息），或网络侧有下行数据到达需要Paging唤醒UE时，必须在最短时间内重建完整的用户面传输通道。这个从"休眠到激活"的关键流程，就是Service Request过程。

3GPP TS 23.502 Section 4.2.3.2 定义了两种Service Request场景：

该过程的核心目标引用自TS 24.501 Section 5.6.1.1：

"The purpose of the service request procedure is to change the 5GMM mode from 5GMM-IDLE to 5GMM-CONNECTED mode."

二、完整信令时序图

以下是基于TS 23.502 Figure 4.2.3.2-1（UE-Triggered）和Figure 4.2.3.2-2（Network-Triggered）绘制的完整信令时序图：

sequenceDiagram
    participant UE
    participant RAN as (R)AN/gNB
    participant AMF
    participant SMF
    participant UPF

    Note over UE,UPF: === UE-Triggered Service Request (CM-IDLE场景) ===

    UE->>RAN: 1. RRC Setup Request (establishmentCause=moData)
    RAN->>UE: 2. RRC Setup
    UE->>RAN: 3. RRC Setup Complete<br/>(携带NAS Service Request)
    RAN->>AMF: 4. N2 Initial UE Message<br/>(NAS Service Request + RAN UE NGAP ID)

    Note over UE,AMF: NAS Service Request 关键IE:<br/>5G-S-TMSI, Service Type=moData,<br/>Uplink Data Status, PDU Session Status

    AMF->>AMF: 5. 验证UE上下文<br/>(根据5G-S-TMSI查找UE Context)

    alt 需要NAS安全重建立
        AMF->>UE: 6a. NAS Security Mode Command
        UE->>AMF: 6b. NAS Security Mode Complete
    end

    AMF->>SMF: 7. Nsmf_PDUSession_UpdateSMContext Request<br/>(PDU Session IDs to activate)

    SMF->>UPF: 8. N4 Session Modification Request<br/>(激活用户面)
    UPF->>SMF: 9. N4 Session Modification Response

    SMF-->>AMF: 10. Nsmf_PDUSession_UpdateSMContext Response<br/>(N2 SM Info: QoS Profile, N3 UL F-TEID)

    AMF->>RAN: 11. N2 Initial Context Setup Request<br/>(NAS Service Accept + N2 SM Info)
    RAN->>UE: 12. RRC Reconfiguration<br/>(DRB建立 + NAS Service Accept)
    UE->>RAN: 13. RRC Reconfiguration Complete

    RAN->>AMF: 14. N2 Initial Context Setup Response<br/>(N3 DL F-TEID: AN Tunnel Info)

    AMF->>SMF: 15. Nsmf_PDUSession_UpdateSMContext Request<br/>(AN Tunnel Info / N3 DL F-TEID)
    SMF->>UPF: 16. N4 Session Modification<br/>(更新DL F-TEID)
    UPF->>SMF: 17. N4 Session Modification Response

    Note over UE,UPF: === 用户面已建立，数据传输开始 ===
    UE<<->>UPF: 18. 双向数据传输 (UL/DL)

sequenceDiagram
    participant UE
    participant RAN as (R)AN/gNB
    participant AMF
    participant SMF
    participant UPF

    Note over UE,UPF: === Network-Triggered Service Request (MT场景) ===

    UPF->>AMF: 1. 下行数据到达通知<br/>(Data Notification)
    AMF->>RAN: 2. N2 Paging<br/>(5G-S-TMSI, TAI List)
    RAN->>UE: 3. RRC Paging<br/>(Paging Record with 5G-S-TMSI)

    UE->>RAN: 4. RRC Setup Request (establishmentCause=mtAccess)
    RAN->>UE: 5. RRC Setup
    UE->>RAN: 6. RRC Setup Complete<br/>(NAS Service Request)
    RAN->>AMF: 7. N2 Initial UE Message<br/>(NAS Service Request)

    Note over UE,AMF: NAS Service Request 关键IE:<br/>Service Type=mtAccess,<br/>PDU Session Status

    AMF->>SMF: 8. Nsmf_PDUSession_UpdateSMContext Request
    SMF->>UPF: 9. N4 Session Modification
    UPF->>SMF: 10. N4 Session Modification Response
    SMF-->>AMF: 11. Nsmf_PDUSession_UpdateSMContext Response

    AMF->>RAN: 12. N2 Initial Context Setup Request
    RAN->>UE: 13. RRC Reconfiguration + NAS Service Accept
    UE->>RAN: 14. RRC Reconfiguration Complete
    RAN->>AMF: 15. N2 Initial Context Setup Response

    AMF->>SMF: 16. 更新AN Tunnel Info
    SMF->>UPF: 17. N4 Session Modification

    UPF->>UE: 18. 下行数据传输开始

三、NAS Service Request消息深度解析

3.1 消息结构（TS 24.501 Section 8.2.15）

graph TB
    subgraph "NAS Service Request Message (TS 24.501 §8.2.15)"
        A["Extended Protocol Discriminator<br/>(5GMM = 0x7E)"]
        B["Security Header Type<br/>(Integrity Protected = 0x12)"]
        C["Spare Half Octet + Message Type<br/>(Service Request = 0x4D)"]
        D["5G-S-TMSI<br/>(48-bit UE临时标识)"]
        E["Service Type<br/>(MO Data/MT Access/MO Signaling...)"]
        F["NAS Key Set Identifier<br/>(KSI标识安全上下文)"]
        G["Uplink Data Status<br/>(可选: 指示有上行数据的PSI)"]
        H["PDU Session Status<br/>(可选: UE侧活跃的PDU会话)"]
        I["Allowed PDU Session Status<br/>(可选)"]
        J["NAS Message Container<br/>(可选: 携带额外NAS消息)"]
    end
    A --> B --> C --> D --> E --> F --> G --> H --> I --> J

3.2 关键IE参数详解

3.3 Service Type字段的6种取值

Service Type是决定网络侧行为的核心判断字段，直接影响AMF后续处理路径：

设计意图：Service Type的精细化分类使得AMF能够根据不同服务类型差异化分配无线和核心网资源——纯信令类请求不需要分配DRB和数据面隧道，大幅节省了网络资源开销。

四、RRC层与NAS层的协同机制

4.1 RRC Establishment Cause映射

Service Request过程中，UE在RRC层发起连接时需要携带establishmentCause，该值由NAS Service Type直接映射而来（TS 38.331 Section 6.2.2）：

抓包识别要点：在Wireshark中过滤RRC Setup Request消息，查看rrcSetupRequest.rrcSetupRequest establishmentCause字段即可快速判断Service Request类型。

4.2 CM状态与RRC状态的映射关系

5G引入了RRC_INACTIVE状态，使得CM状态与RRC状态不再是简单的1:1映射：

stateDiagram-v2
    [*] --> CM_IDLE_RRC_IDLE: UE开机/去注册完成

    state "CM-IDLE + RRC_IDLE" as CM_IDLE_RRC_IDLE {
        [*] --> 空闲态
    }

    state "CM-CONNECTED + RRC_INACTIVE" as CM_CONN_RRC_INACTIVE {
        [*] --> RAN保持UE上下文
        note right of RAN保持UE上下文: NAS连接逻辑存在\n但RRC连接挂起
    }

    state "CM-CONNECTED + RRC_CONNECTED" as CM_CONN_RRC_CONNECTED {
        [*] --> 全连接态
        note right of 全连接态: NAS信令+用户面\n均可用
    }

    CM_IDLE_RRC_IDLE --> CM_CONN_RRC_CONNECTED: Service Request\n(RRC Setup)
    CM_CONN_RRC_INACTIVE --> CM_CONN_RRC_CONNECTED: Service Request\n(RRC Resume)
    CM_CONN_RRC_CONNECTED --> CM_CONN_RRC_INACTIVE: RRC Inactivity Timer超时\n(RRC Release with Suspend)
    CM_CONN_RRC_INACTIVE --> CM_IDLE_RRC_IDLE: RNA Update失败/超时
    CM_CONN_RRC_CONNECTED --> CM_IDLE_RRC_IDLE: NAS Deregistration

关键差异：

RRC_INACTIVE的设计精妙之处：gNB保持UE上下文（包括DRB配置），当UE需要恢复时只需发送RRC Resume Request（携带I-RNTI），gNB即可在本地恢复连接，无需经过核心网，将恢复延迟从50-100ms降低到10-20ms——这对URLLC场景至关重要。

五、核心网侧处理流程拆解

5.1 AMF处理逻辑（TS 23.502 §4.2.3.2 Step 2-7）

AMF收到Service Request后，核心处理逻辑如下：

Step 2：AMF根据Service Request中的5G-S-TMSI查找本地存储的UE上下文。5G-S-TMSI的48 bit结构为：

| AMF Set ID (10 bit) | AMF Pointer (6 bit) | 5G-TMSI (32 bit) |

• AMF Set ID：标识AMF Set，用于AMF故障恢复场景
• AMF Pointer：标识Set内具体AMF实例
• 5G-TMSI：AMF分配的UE临时标识

Step 3：AMF验证UE的安全上下文状态。根据TS 24.501 Section 5.6.1.2： - 如果NAS安全上下文为current状态，AMF可直接使用 - 如果安全上下文为non-current或不存在，AMF需先发起NAS SMC（Security Mode Command）

Step 4-7：AMF根据Uplink Data Status和PDU Session Status确定需要激活的PDU Session列表，向对应的SMF发起Nsmf_PDUSession_UpdateSMContext Request。

5.2 SMF与UPF的N4交互（TS 23.502 §4.2.3.2 Step 8-10）

SMF收到AMF的请求后执行以下操作：

1. 查找PDU Session对应的N4 Session
2. 向UPF发送N4 Session Modification Request：激活用户面规则，UPF准备接收下行数据
3. UPF回复N4 Session Modification Response：携带N3 UL F-TEID（UPF侧上行隧道端点）
4. SMF构造N2 SM Information返回给AMF：包含QoS Profile、N3 UL F-TEID、QoS Flow配置等

5.3 N2 Initial Context Setup（TS 38.413 §8.4.1）

AMF向gNB发送的N2 Initial Context Setup Request是Service Request流程中最关键的N2消息，它同时携带：

gNB收到后执行： 1. AS安全激活：向UE发送SecurityModeCommand 2. DRB建立：RRC Reconfiguration配置数据无线承载 3. 透传NAS Service Accept：封装在RRC Reconfiguration中

六、RRC_INACTIVE场景下的Service Request

当UE处于CM-CONNECTED + RRC_INACTIVE状态时，Service Request流程有本质不同：

sequenceDiagram
    participant UE
    participant RAN as gNB
    participant Old_gNB as Old gNB
    participant AMF

    Note over UE,AMF: === RRC_INACTIVE场景的Service Request ===

    alt 场景A: 回到原gNB
        UE->>RAN: 1. RRC Resume Request<br/>(I-RNTI, Resume Cause)
        RAN->>RAN: 2. 本地恢复UE上下文<br/>(无需Retrieve UE Context)
        RAN->>UE: 3. RRC Resume<br/>(恢复DRB配置)
        UE->>RAN: 4. RRC Resume Complete
        Note over UE,RAN: 数据传输可在10-20ms内恢复
    else 场景B: 移动到新gNB
        UE->>RAN: 1. RRC Resume Request<br/>(I-RNTI指向Old gNB)
        RAN->>Old_gNB: 2. Xn: Retrieve UE Context Request<br/>(I-RNTI)
        Old_gNB->>RAN: 3. Xn: Retrieve UE Context Response<br/>(完整UE上下文)
        RAN->>AMF: 4. N2 Path Switch Request<br/>(Target NG-RAN Info)
        AMF->>RAN: 5. N2 Path Switch Request Ack
        RAN->>UE: 6. RRC Resume
        UE->>RAN: 7. RRC Resume Complete
    end

I-RNTI（Inactive-RNTI）是RRC_INACTIVE场景下的核心标识，由gNB在RRC Release with Suspend时分配，结构为：

| PLMN ID | Cell ID (28bit) | gNB-specific UE ID (up to 40bit) |

设计要点：I-RNTI不仅标识UE，还包含了gNB的地址信息，使得新gNB可以通过解析I-RNTI直接找到存储UE上下文的老gNB，通过Xn接口Retrieve UE Context，避免了核心网参与。

七、NAS Service Accept与Service Reject

7.1 Service Accept（TS 24.501 §8.2.14）

Service Accept由AMF发送，通常封装在N2消息中透传至gNB，再通过RRC Reconfiguration转交UE。关键IE：

UE侧收到Service Accept后的行为： - 将自身PDU Session Status与网络侧同步 - 如果某些PDU Session在网络侧已不存在，UE本地释放这些会话 - 进入CM-CONNECTED状态，开始数据传输

7.2 Service Reject（TS 24.501 §8.2.13）

Service Reject携带5GMM Cause Code，常见拒绝原因：

八、5G Service Request vs 4G EPS Service Request对比

关键改进：5G的Service Request最大的架构优势在于多PDU Session并行激活——UE通过Uplink Data Status bitmap一次性指示多个需要激活的PDU Session，AMF并行向多个SMF发起激活请求。相比之下4G的Service Request只能处理单一PDN连接。

九、抓包实战：如何识别和分析Service Request

9.1 Wireshark过滤表达式

# 过滤NAS Service Request消息
nas-5gs.message_type == 0x4d

# 过滤RRC Setup Request（Service Request的第一步）
rrc.setup_request

# 过滤N2 Initial UE Message（gNB转发Service Request）
ngap.procedureCode == 15 && ngap.nASPDU exists

# 过滤完整的Service Request流程
nas-5gs.message_type == 0x4d || (nas-5gs.message_type == 0x4c && ngap.procedureCode == 15)

# Service Reject
nas-5gs.message_type == 0x4b

9.2 关键检查点

在排障时，按以下顺序逐项检查：

1. RRC Setup → NAS Service Request：检查RRC establishmentCause是否与NAS Service Type匹配
2. 5G-S-TMSI解析：确认AMF Set ID和AMF Pointer可正确路由到AMF
3. Uplink Data Status：检查哪些PSI bit被置1，确认这些PDU Session确实存在
4. PDU Session Status同步：UE与AMF的PDU Session Status是否一致，不一致可能导致意外释放
5. NAS安全：Service Request必须被完整性保护，如果Security Header Type异常（如0x00），说明安全上下文丢失
6. N2 Initial Context Setup：检查是否包含正确的N2 SM Information（QoS Profile、N3 Tunnel Info）
7. N4 Session Modification：确认UPF正确接收并应用了新的DL F-TEID

9.3 常见故障场景

Service Request过程涉及的关键定时器（TS 24.501）：

设计意图：T3517设置为较短的5秒，因为Service Request对时延敏感——如果5秒内AMF没有响应，UE需要快速重试或执行其他恢复策略（如重新注册），避免用户面长时间中断。

常见问题

Q1: Service Request和Registration Request有什么区别？什么时候用哪个？

A: Service Request用于已有有效注册上下文的场景——UE已经注册过，只是从CM-IDLE恢复到CM-CONNECTED。Registration Request用于首次注册或注册更新场景（如周期性注册、移动性注册更新）。关键区别：Service Request不携带完整的Registration参数（如UE Network Capability），只携带最小化的标识和服务类型信息，因此信令开销更小、处理更快。

Q2: UE在RRC_INACTIVE状态下收到Paging，发的是RRC Resume还是Service Request？

A: 这取决于Paging的来源。如果Paging来自gNB（RAN Paging），说明UE在RRC_INACTIVE状态，UE发送RRC Resume Request即可，不一定需要NAS Service Request。如果Paging来自AMF（CN Paging）且经过gNB转发，则UE需要先RRC Resume，然后可能在NAS层发起Service Request（取决于具体实现）。实际中，多数厂商在RRC_INACTIVE下收到RAN Paging后，只做RRC Resume，不再触发NAS Service Request。

Q3: Uplink Data Status和PDU Session Status有什么区别？为什么要同时携带？

A: Uplink Data Status告诉网络"我想激活哪些PDU Session"（因为有数据要发），PDU Session Status告诉网络"我认为哪些PDU Session是活跃的"。网络侧根据两者做交叉校验——如果UE的PDU Session Status中包含网络侧已释放的Session，AMF会在Service Accept中通知UE同步状态。这种双向同步机制防止了UE与网络侧的PDU Session状态不一致。

Q4: Service Request过程中的NAS消息为什么总是完整性保护的？

A: 根据TS 24.501 Section 5.6.1.2，Service Request消息必须使用Integrity Protected with NAS Security Context（Security Header Type = 0x12）。这是因为Service Request中包含5G-S-TMSI和PDU Session信息，如果不做完整性保护，攻击者可以伪造Service Request占用网络资源或发起DoS攻击。但注意：Service Request通常是完整性保护但不加密的（plain NAS消息+MAC-I），因为UE在CM-IDLE状态下可能没有有效的加密上下文。

Q5: 5G Service Request相比4G有什么性能提升？

A: 主要有三方面提升：(1) RRC_INACTIVE状态支持使恢复延迟从50-100ms降至10-20ms；(2) 多PDU Session并行激活通过bitmap一次性完成，而4G只能逐个Bearer激活；(3) SBA架构下AMF与SMF的异步交互比4G的同步GTP-C交互更高效。实测数据显示，5G Service Request的端到端时延约为4G的60%。

参考来源

1. 3GPP TS 23.502 V18.10.0 — Section 4.2.3.2 Service Request procedure
2. 3GPP TS 24.501 — Section 5.6.1 Service Request procedure, Section 8.2.15 SERVICE REQUEST message
3. ShareTechnote - 5G NAS Service Setup — Service Request信令流程图解
4. 3glteinfo - 5G NAS Service Request — NAS消息IE详解
5. HiCellTek - LTE vs 5G NR Signaling — 4G/5G信令协议对比

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