5G业务请求（Service Request）信令流程深度解读：TS 23.502 §4.2.3.2 逐条拆解

在5G网络中，如果统计NAS层消息出现频率，Service Request几乎一定是第一名。UE每一次从空闲态被“唤醒”——无论是App来了一条微信推送、基站要下发寻呼、还是上层需要发一条NAS信令——只要UE处于CM-IDLE，都必须先走一遍TS 23.502第4.2.3.2节定义的UE Triggered Service Request流程。它与Registration（注册）不同：注册解决的是“我是谁、我能不能入网”，而Service Request解决的是“给我把N2/N1连接和用户面通道恢复起来”。本文基于TS 23.502（§4.2.3.2/§4.2.3.3）、TS 24.501（§5.6）、TS 38.413（NGAP）和TS 33.501，逐消息、逐IE地拆解这条网络中最繁忙的信令流。

一、前置概念：CM状态、RRC状态与5G-S-TMSI

1.1 两套状态的映射关系

5GC引入了连接管理（CM）状态（TS 23.501中定义于移动性与连接管理章节，即CM-IDLE/CM-CONNECTED），它与接入网的RRC状态是两个独立维度：

注意第三行：RRC_INACTIVE下UE仍是CM-CONNECTED，AMF侧N2连接逻辑上仍然保持。这意味着Service Request在RRC_INACTIVE场景下有完全不同的触发方式（见第四节），这是5G相对4G最大的架构变化之一。

1.2 5G-S-TMSI：寻呼的“门牌号”

CM-IDLE下的UE没有RRC连接，网络唯一的触达手段是寻呼，而寻呼的索引就是5G-S-TMSI。其结构定义于TS 23.003第2.10节（5G-GUTI的简化形式）：

5G-GUTI = <AMF Region ID>(8bit) + <AMF Set ID>(10bit) + <AMF Pointer>(6bit) + <5G-TMSI>(32bit)
5G-S-TMSI = <AMF Set ID>(10bit) + <AMF Pointer>(6bit) + <5G-TMSI>(32bit) = 48bit = 6字节

• AMF Set ID + AMF Pointer（16bit）：精确指向AMF区域（Region）内某个AMF集合中的某一台AMF。Service Request流程中，gNB正是靠这16bit把NGAP消息路由到正确的AMF；
• 5G-TMSI（32bit）：UE在AMF内的临时标识，AMF用它查回UE上下文，不暴露IMSI/SUPI——这是5G身份隐私设计（SUCI体系）在寻呼域的延伸。

1.3 ngKSI：让AMF找到正确的密钥

Service Request是UE在空闲态发出的第一条NAS消息，网络如何确认它没被伪造？答案是完整性保护校验。UE在SERVICE REQUEST中携带ngKSI（key Set Identifier，TS 33.501密钥体系中的K_AMF标识），AMF据此选择本地保存的K_AMF派生NAS完整性密钥K_NASint，校验消息中的NAS MAC。校验通过，流程才继续——这是整条流程的安全基石。

二、UE Triggered Service Request完整信令流（TS 23.502 §4.2.3.2）

2.1 总体时序图

以UE处于CM-IDLE、有下行数据待收（或上层需要发信令）为典型场景：

sequenceDiagram
    autonumber
    participant UE as UE (CM-IDLE)
    participant RAN as NG-RAN (gNB)
    participant AMF as AMF
    participant SMF as SMF
    participant UPF as UPF

    UE->>RAN: RRCSetupRequest (establishmentCause=mo-Data)
    RAN-->>UE: RRCSetup
    UE->>RAN: RRCSetupComplete (携带NAS: SERVICE REQUEST)
    Note over UE: ngKSI + Service type + 5G-S-TMSI(6字节)
    RAN->>AMF: NGAP INITIAL UE MESSAGE<br/>(5G-S-TMSI, NAS-PDU, User Location Info, RRC Cause)
    Note over AMF: 按ngKSI选K_AMF校验NAS MAC<br/>解析5G-S-TMSI确认本AMF即目标AMF
    opt 本AMF无完整上下文(如AMF迁移)
        AMF->>AMF: Namf_Communication_UEContextTransfer(向旧AMF取上下文)
    end
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext(通知UE可达)
    SMF->>UPF: N4 Session Modification(PFCP)
    UPF-->>SMF: N4 Session Modification Response
    SMF-->>AMF: UpdateSMContext Response(含N2 SM Info: UPF侧N3隧道信息)
    AMF->>RAN: NGAP INITIAL CONTEXT SETUP REQUEST<br/>(NAS-PDU, K_gNB, UE安全能力,<br/>PDU Session Resource Setup List, UE-AMBR)
    RAN-->>UE: RRC Reconfiguration(SRB2/DRB建立, AS安全激活)
    RAN->>AMF: INITIAL CONTEXT SETUP RESPONSE(各PDU会话的RAN侧N3 TEID/IP)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext(转发RAN侧N3隧道信息)
    SMF->>UPF: N4 Session Modification(下行隧道指向gNB)
    UPF->>RAN: 下行数据经N3隧道下发
    RAN-->>UE: 下行数据送达
    opt 无其他NAS消息可发时
        AMF-->>UE: NAS SERVICE ACCEPT
    end

2.2 逐条消息深度解析

第1–3步：RRC连接建立与NAS消息搭车

UE发送RRCSetupRequest时的establishmentCause是排错时的重要线索：mo-Signalling对应Service type=Signalling，mo-Data对应Service type=Data，mps-PriorityAccess对应高优先级接入。关键在于：NAS的SERVICE REQUEST是装在RRCSetupComplete里“搭车”上行的（即NR RRC的UL DCCH承载），gNB并不解析其内容，只负责转发和路由。

第4步：NGAP INITIAL UE MESSAGE（TS 38.413）

这是gNB发给AMF的第一条NGAP UE关联消息，关键IE：

第5步：AMF的完整性校验（TS 33.501）

AMF收到消息后第一件事不是查会话，而是验MAC。SECURITY REQUEST消息中的ngKSI指示AMF应使用哪个K_AMF；若校验失败，AMF直接回SERVICE REJECT（cause = #20 MAC failure），UE需重新触发鉴权。若AMF发现上下文不全（典型场景：UE上次注册后AMF池内发生迁移、或旧AMF已释放部分上下文），会通过Namf_Communication_UEContextTransfer向旧AMF拉取完整UE上下文，这是§4.2.3.2中的条件分支。

第6–9步：会话面的“批量唤醒”

这是5G与4G最本质的设计差异之一：SERVICE REQUEST中不携带任何PDU Session ID。UE只说“我要连上”，具体恢复哪些会话由网络侧决定——AMF根据本地保存的PDU会话状态，逐个向SMF发Nsmf_PDUSession_UpdateSMContext。SMF通过N4/PFCP通知UPF“UE要醒了”，并把UPF侧的N3隧道信息（TEID + IP）打包成N2 SM Information（PDU Session Resource Setup Request Transfer）交给AMF。设计意图：注册时允许一个UE的多个PDU会话锚定在不同SMF甚至不同切片上，MM与SM彻底解耦后，连接恢复就不再依赖UE枚举会话，也天然规避了会话状态不一致问题。

第10步：NGAP INITIAL CONTEXT SETUP REQUEST

AMF发给gNB的“总装清单”，IE极为密集，排错重点：

第11–15步：空口重配与双向隧道打通

gNB通过RRC Reconfiguration下发SRB2与DRB配置并激活AS安全；随后INITIAL CONTEXT SETUP RESPONSE把gNB侧N3 TEID/IP逐会话回给AMF，AMF再经SMF/N4写入UPF。至此下行隧道指到gNB、上行隧道指到UPF，数据面贯通。若此消息迟迟不到或携带失败IE（如PDU Session Resource Failed to Setup List），排错方向就是空口质量或gNB资源。

第16步：SERVICE ACCEPT的“补位”逻辑（TS 24.501）

一个容易被忽略的细节：网络并不总是回复SERVICE ACCEPT。如果AMF本来就有别的NAS消息要发（如CONFIGURATION UPDATE COMMAND），那条消息本身就完成了对Service Request的应答；只有“没有任何其他NAS消息可发”时（典型为Service type=Signalling场景），AMF才补发SERVICE ACCEPT。抓包时看到“只有请求没有ACCEPT”未必是异常。

三、NAS SERVICE REQUEST消息结构（TS 24.501）

3.1 消息体IE结构图

flowchart TB
    subgraph SEC["安全保护头(所有非紧急NAS消息必带)"]
        EPD["Extended protocol discriminator = 0x7E"]
        SHT["Security header type = 0x02<br/>(完整性保护+加密)"]
        MACI["NAS Message Authentication Code (4字节)"]
        SEQN["NAS Sequence Number (1字节, 防重放)"]
    end
    subgraph PLAIN["SERVICE REQUEST 明文载荷"]
        NKI["ngKSI + TSC位<br/>(TSC=0原生密钥/1映射密钥)"]
        STV["Service type (4bit)"]
        STMSI["5G-S-TMSI (6字节, CM-IDLE必带)<br/>AMF Set ID 10bit + AMF Pointer 6bit + 5G-TMSI 32bit"]
    end
    SEC --> PLAIN

注意：SERVICE REQUEST没有Message type字段——它是5GMM中极少数凭“Security header type + 半字节组合”即可识别的短消息，整条明文部分最小仅7字节，这是刻意为之的精简设计（频次最高的消息必须最短）。

3.2 Service type取值表

四、两个变体场景

4.1 Network Triggered Service Request（TS 23.502 §4.2.3.3）

sequenceDiagram
    autonumber
    participant UPF
    participant SMF
    participant AMF
    participant RAN as NG-RAN
    participant UE as UE (CM-IDLE)

    UPF->>UPF: 收到下行PDU, UE无N3连接
    Note over UPF: 按策略缓存数据
    UPF->>SMF: PFCP Session Report(数据到达通知)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer(N2 SM Info)
    AMF->>RAN: NGAP PAGING<br/>(5G-S-TMSI, TAI List, Paging Priority,<br/>Paging Attempt Counter)
    Note over AMF: T3513超时未响应则重发, 计数递增
    RAN-->>UE: PDCCH(P-RNTI) + Paging记录(含S-TMSI)
    UE->>RAN: RRCSetupComplete携带 SERVICE REQUEST<br/>(Service type=Mobile terminated services)
    RAN->>AMF: INITIAL UE MESSAGE(回传寻呼携带的N2 SM Info)
    Note over AMF,SMF: 后续与UE触发流程汇合:<br/>上下文建立→N4修改→数据下发

要点：T3513（AMF寻呼重发定时器）与NGAP Paging中的Paging Attempt Counter / Intended Number of Paging Attempts配合控制寻呼节奏；多次寻呼无响应后，AMF通过N1N2 Message Transfer失败通知告知SMF“UE不可达”，SMF/UPF据此执行缓存与下行数据投递状态上报。若UE注册为MICO模式（Mobility Idleness Per Communication...即移动性仅空闲模式），网络根本不寻呼——下行数据由UPF拒绝/丢弃，靠应用层推送机制兜底，这正是MICO“省电优先”的体现。

4.2 RRC_INACTIVE下的Service Request

UE在RRC_INACTIVE发起业务时，不发RRCSetupRequest，而是发RRCResumeRequest（携带I-RNTI）+ NAS SERVICE REQUEST：

flowchart TB
    A["UE处于RRC_INACTIVE (CM-CONNECTED)"] --> B{"服务gNB是否为<br/>锚点gNB(最后服务gNB)?"}
    B -- "是" --> C["锚点gNB本地恢复上下文<br/>直接发INITIAL UE MESSAGE给AMF<br/>(无需Xn取上下文, 时延最低)"]
    B -- "否(UE已移动)" --> D["新gNB经Xn接口向锚点<br/>取回UE上下文(RRCResume成功)"]
    D --> C
    D -- "Xn取上下文失败" --> E["回退RRC重建立<br/>UE在RRCSetupComplete中携带<br/>含5G-S-TMSI的SERVICE REQUEST<br/>→ 汇入CM-IDLE标准流程"]
    C --> F["后续同标准流程:<br/>INITIAL CONTEXT SETUP / N4修改"]

这个设计的目标是把控制面信令收敛在RAN内（Xn接口），只有必要时才惊动AMF——这是5G降低小包业务时延（配合后来的RNA配置、寻呼优化）的关键路径。

五、状态机与定时器

5.1 5GMM状态转换（TS 24.501）

stateDiagram-v2
    [*] --> 5GMM_DEREGISTERED
    5GMM_DEREGISTERED --> 5GMM_REGISTERED_INITIATED : REGISTRATION REQUEST (T3550启动)
    5GMM_REGISTERED_INITIATED --> 5GMM_REGISTERED : REGISTRATION ACCEPT
    5GMM_REGISTERED --> 5GMM_SERVICE_REQUEST_INITIATED : 发送SERVICE REQUEST<br/>(T3517启动)
    5GMM_SERVICE_REQUEST_INITIATED --> 5GMM_REGISTERED : 收到任意NAS消息(非REJECT)<br/>T3517停止, 流程成功
    5GMM_SERVICE_REQUEST_INITIATED --> 5GMM_REGISTERED : T3517超时或收到<br/>SERVICE REJECT(计入尝试计数)
    5GMM_REGISTERED --> 5GMM_DEREGISTERED : 去注册(Deregistration或隐式)

TS 24.501专门定义了5GMM-SERVICE-REQUEST-INITIATED这个中间态。T3517是UE侧守护定时器：发出SERVICE REQUEST即启动，收到任何非SERVICE REJECT的NAS消息即停止——注意是“任何消息”，这解释了为什么AMF可以用REGISTRATION ACCEPT、DL NAS TRANSPORT等消息“顺带”终止Service Request流程。T3517超时后UE允许重发，但尝试计数达到上限（5次）后UE将抑制继续发起，直到条件变化（如更换小区/TA），防止弱覆盖下的信令风暴——这与AMF过载控制机制形成“UE侧自律+网络侧管制”的双保险。

5.2 SERVICE REJECT常见cause值速查

六、实战：抓包识别与排错

6.1 抓包与过滤

N2接口为SCTP承载，端口38412（NGAP的SCTP PPID为60）。Wireshark常用过滤器：

sctp.port == 38412                          — 全部NGAP
ngap.procedureCode == 46                    — INITIAL UE MESSAGE
ngap.procedureCode == 9                     — INITIAL CONTEXT SETUP
nas_5gs.mm.message_type == 0x4c             — NAS SERVICE REQUEST (消息类型值76)
nas_5gs.mm.message_type == 0x4d             — NAS SERVICE REJECT

一条健康的UE触发流程在抓包里呈现为固定的四段式：RRCSetupComplete携带SR → InitialUEMessage → InitialContextSetupRequest/Response → N4交互（若同时抓N4/SBI可完整对齐）。交叉核对INITIAL UE MESSAGE中的5G-S-TMSI与此前REGISTRATION ACCEPT中AMF下发的5G-GUTI，可以验证AMF分配逻辑是否正确。

6.2 常见故障模式

1. “反复SR但收不到InitialContextSetup”：多因NAS完整性校验失败（cause #20）或AMF上下文缺失且旧AMF的ContextTransfer失败；检查ngKSI是否与AMF保存的密钥集一致、UE与AMF的NAS COUNT是否漂移（UE长时间休眠后计数不同步是经典问题）。
2. “ContextSetup成功但无数据”：信令面正常、用户面不通——优先查UPF的N4会话状态与PFCP关联（N3隧道是否真正写入）、防火墙对GTP-U（2152端口）的策略。
3. “寻呼反复下发UE不响应”：核对AMF的TAI List与UE实际驻留TA是否匹配（TA规划错误会导致“永不被呼”）；核查gNB侧SIB1中寻呼配置与P-RNTI计算参数。
4. “RRC_INACTIVE场景时延异常”：多为Xn取上下文失败频繁回退到RRC重建立，检查锚点gNB与新gNB间Xn建立与切片级Xn配置。
5. 试验网/新版本对接时的ASN.1解码失败：Wireshark显示RAW/乱码，多为两端NGAP版本（Rel-15/16/17扩展IE）不对齐，比对两端基线版本。

6.3 实现层面的差异点（部署观察）

标准允许实现自由度的位置，正是多厂商对接的差异高发区：寻呼重发策略（次数、间隔、是否区分5QI做Paging Policy Differentiation）、INITIAL CONTEXT SETUP REQUEST中PDU会话的全量恢复还是按需恢复（Rel-16起SERVICE ACCEPT可携带PDU session status帮助UE与网络对齐会话视图，各实现对“恢复时机”取舍不同）、AMF池内ContextTransfer的触发阈值等。跨厂商联调时，建议先对齐这三类策略参数再排信令问题，可少走弯路。

七、与4G EPS Service Request的对比

理解了“UE不指定会话、网络决定恢复范围”这一条，就理解了5G会话管理整个解耦设计的钥匙。

常见问题

Q1: Service Request和Registration Request的区别是什么？ A: Registration改变网络与UE的“注册关系”（区域、切片、签约生效），完成后UE获得5G-GUTI/TAI List/Allowed NSSAI；Service Request不改变任何注册属性，只把CM-IDLE的UE恢复到CM-CONNECTED并按需重建用户面。UE注册后驻留不动，期间每次业务唤醒走的都是SR，所以SR频率远高于Registration。

Q2: 为什么5G的SERVICE REQUEST不带PDU Session ID，而4G的Service Request有承载关联？ A: 4G的EPS bearer把MM和SM绑在一起，UE侧知道承载状态所以需要上报EPS bearer context status；5G把PDU会话设计为“与连接状态无关的持久对象”，会话的激活/去激活完全由网络管理，SR只表达“我到了”这个事实。好处是多会话跨SMF/跨切片时恢复逻辑简单，且UE与网络的会话状态即使短暂不一致也不阻塞连接建立（Rel-16再通过SERVICE ACCEPT中的PDU session status兜底同步）。

Q3: RRC_INACTIVE状态下UE发的是SERVICE REQUEST还是RRC消息？ A: 两者都发：空口上是RRCResumeRequest（携带I-RNTI），其内封装NAS SERVICE REQUEST（此时可不带5G-S-TMSI，因为锚点gNB凭I-RNTI即可定位上下文）。若gNB间Xn上下文获取失败，流程退化为RRC重建立，UE改用带5G-S-TMSI的SR走CM-IDLE路径。

Q4: T3517超时后会怎样？会无限重试吗？ A: 不会。超时后UE可重发SERVICE REQUEST，但按TS 24.501的尝试计数机制，连续5次失败后UE进入抑制状态，不再发起，直至条件变化（更换小区等）。这是标准的防信令风暴设计，也解释了弱覆盖下“手机突然长时间没信号但开机正常”的现象。

Q5: 抓包里只有SERVICE REQUEST没有SERVICE ACCEPT，是流程失败了吗？ A: 不一定。规范规定只有AMF没有其他NAS消息可发时才补发SERVICE ACCEPT；如果随后看到INITIAL CONTEXT SETUP REQUEST或DL NAS TRANSPORT，说明流程已被这些消息隐式终止，属正常现象。只有“SR之后什么都没有、且RRC被释放”才指向失败，此时查cause值和完整性校验。

参考来源

1. 3GPP TS 23.502（ Procedures for the 5G System） — §4.2.3.2 UE Triggered Service Request、§4.2.3.3 Network Triggered Service Request为本文主线依据
2. 3GPP TS 24.501（NAS protocol for 5GS） — SERVICE REQUEST/REJECT消息结构、Service type取值、T3517与5GMM状态机、尝试计数机制
3. 3GPP TS 38.413（NGAP） — INITIAL UE MESSAGE、INITIAL CONTEXT SETUP REQUEST/RESPONSE、Paging的IE定义与procedure code
4. 3GPP TS 23.003（Numbering, addressing and identification） — 第2.10节5G-GUTI/5G-S-TMSI位结构与AMF标识分配
5. 3GPP TS 33.501（Security architecture and procedures for 5GS） — ngKSI/K_AMF密钥体系、NAS完整性保护、K_gNB垂直派生

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