<!-- title: 5G Service Request信令流全链拆解 -->
<!-- domain: protocols -->

# 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场景：

| 场景 | 触发方 | 典型场景 | 核心差异 |
|------|--------|---------|---------|
| **UE-Triggered Service Request** | UE主动发起 | UE有上行数据、MO信令 | UE自主决定何时发起 |
| **Network-Triggered Service Request** | 网络侧Paging触发 | 下行数据到达、MT SMS、MT Voice | UE响应Paging后发起 |

该过程的**核心目标**引用自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）绘制的完整信令时序图：

```mermaid
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)
```

```mermaid
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）

```mermaid
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参数详解

| IE名称 | TS 24.501章节 | 长度 | 必选/可选 | 编码说明 |
|--------|--------------|------|---------|---------|
| **Extended Protocol Discriminator** | §9.3.0.1 | 1字节 | M | 固定值0x7E，标识5GMM消息 |
| **Security Header Type** | §9.3.0.2 | 1/2字节 | M | 0x12=完整性保护+加密（Service Request总是被安全保护） |
| **5G-S-TMSI** | §9.10.2.6 | 48 bit | M | AMF Set ID(10bit) + AMF Pointer(6bit) + 5G-TMSI(32bit) |
| **Service Type** | §9.10.3.56 | 1/2字节 | M | 0=signaling, 1=moData, 2=mtAccess, 3=emergency, 4=moSMS, 5=mtSMS |
| **NAS Key Set Identifier** | §9.10.2.8 | 1/2字节 | M | 标识当前使用的安全上下文，TSC+KSI(3bit) |
| **Uplink Data Status** | §9.10.2.22 | 可变 | O | Bitmap，每位对应一个PSI，1=该会话有上行数据待发 |
| **PDU Session Status** | §9.10.2.23 | 可变 | O | Bitmap，标识UE认为活跃的PDU会话 |
| **Allowed PDU Session Status** | §9.10.2.50 | 可变 | O | R18新增，指示允许的PDU会话 |
| **NAS Message Container** | §9.10.2.17 | 可变 | O | 可携带Registration Request等封装消息 |

### 3.3 Service Type字段的6种取值

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

| Service Type值 | 含义 | 触发场景 | AMF行为差异 |
|---------------|------|---------|------------|
| 0 | Signaling | UE需要发送NAS信令 | 仅建立信令连接，不激活用户面 |
| 1 | MO Data | UE有上行数据待发 | 触发PDU Session用户面重建 |
| 2 | MT Access | 响应网络Paging | 激活被Paging的PDU Session |
| 3 | Emergency | 紧急呼叫 | 高优先级处理，可跳过部分验证 |
| 4 | MO SMS | UE发送SMS | 仅激活SMS相关信令路径 |
| 5 | MT SMS | 网络下发SMS | 激活MT SMS信令路径 |

**设计意图**：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）：

| NAS Service Type | RRC establishmentCause | 说明 |
|-----------------|----------------------|------|
| moData | mo-Data | 移动台主叫数据 |
| moSignaling | mo-Signalling | 移动台主叫信令 |
| mtAccess | mt-Access | 响应网络寻呼 |
| emergency | emergency | 紧急呼叫 |
| moSMS/moSMS | mo-Data (多数实现) | 短信通常复用数据通道 |

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

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

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

```mermaid
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过程 | N2过程 | NAS过程 | 延迟 |
|------------|--------|--------|---------|------|
| CM-IDLE → CM-CONNECTED | RRC Setup（全新建立） | N2 Initial UE Message + Initial Context Setup | Service Request + Service Accept | **~50-100ms** |
| CM-CONNECTED(RRC-INACTIVE) → CM-CONNECTED(RRC-CONNECTED) | RRC Resume（恢复挂起的连接） | 可能无需N2交互（RAN本地恢复） | Service Request（可选） | **~10-20ms** |

**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消息，它同时携带：

| 内容 | 来源 | 作用 |
|------|------|------|
| NAS Service Accept | AMF生成 | 确认Service Request成功 |
| UE Security Capability | AMF从UE Context获取 | gNB用于AS层安全建立 |
| Security Key | AMF根据K~AMF~推演 | gNB用于RRC加密/完整性保护 |
| N2 SM Information (per PDU Session) | SMF提供 | QoS Profile + N3 Tunnel Info |
| Mobile Restriction List | UDM获取 | 限制UE的接入能力 |

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流程有本质不同：

```mermaid
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：

| IE | 说明 |
|----|------|
| **PDU Session Status** | 网络侧认为活跃的PDU会话列表 |
| **PDU Session Reactivation Result** | 成功激活的PDU会话列表 |
| **PDU Session Reactivation Result Error Cause** | 激活失败的PDU会话及失败原因 |
| **Allowed PDU Session Status** | R18新增，允许的PDU会话 |

**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，常见拒绝原因：

| Cause Code | 值 | 含义 | UE后续行为 |
|-----------|-----|------|-----------|
| #3 | 3 | Illegal UE | 等待T3247后重新注册 |
| #6 | 6 | Illegal ME | 等待T3247后重新注册 |
| #7 | 7 | 5GS Services Not Allowed | 进入5GMM-DEREGISTERED状态 |
| #9 | 9 | UE Identity Cannot Be Derived | 等待T3246后重试 |
| #10 | 10 | Implicitly Detached | 执行本地去注册后重新注册 |
| #11 | 11 | PLMN Not Allowed | 搜索其他PLMN |
| #27 | 27 | Missing or Unknown DNN | 可能需要重新建立PDU Session |
| #62 | 62 | No Suitable Cells In Tracking Area | 执行PLMN选择 |
| #73 | 73 | Congestion | 等待backoff timer后重试 |

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

| 对比维度 | 5G Service Request | 4G EPS Service Request/Extended Service Request |
|---------|-------------------|-----------------------------------------------|
| **定义规范** | TS 24.501 §5.6.1 | TS 24.301 §5.6.1 |
| **流程规范** | TS 23.502 §4.2.3.2 | TS 23.401 §5.3.4.1 |
| **NAS消息名** | SERVICE REQUEST | SERVICE REQUEST / EXTENDED SERVICE REQUEST |
| **临时标识** | 5G-S-TMSI (48bit) | S-TMSI (40bit) + MMEGI (16bit) |
| **会话概念** | PDU Session (bitmap) | EPS Bearer (单一或多个) |
| **RRC Inactive** | ✅ 原生支持（RRC Resume） | ❌ 不支持（LTE无RRC_INACTIVE） |
| **SBA接口** | Nsmf_PDUSession_UpdateSMContext | Modify Bearer Request (GTP-C) |
| **多PDU Session** | 支持同时激活多个PDU Session | 单一PDN连接 |
| **安全架构** | 5G AKA/EAP-AKA', K~AMF~推演 | EPS AKA, K~ASME~推演 |
| **Service Type** | 6种（signaling/data/MT/emergency/SMS） | 3种（signaling/data/emergency） |

**关键改进**：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后无Service Accept | AMF找不到UE Context | 检查5G-S-TMSI有效性、AMF是否重启 |
| Service Reject #9 | UE标识无法解析 | 检查5G-S-TMSI格式、AMF Set分配 |
| PDU Session未激活 | SMF/UPF故障 | 检查Nsmf_PDUSession_UpdateSMContext返回 |
| 用户面不通 | N3 Tunnel未建立 | 检查N2 Setup Response中的AN Tunnel Info |
| RRC Resume失败 | I-RNTI无效/超时 | 检查gNB上下文保持定时器配置 |
## 十、定时器与计数器

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

| 定时器 | 值 | 作用 | 超时行为 |
|--------|-----|------|---------|
| **T3517** | 5秒（默认） | Service Request发送后等待Service Accept | 超时后重发Service Request（最多5次） |
| **T3511** | 3秒（默认） | Service Reject with backoff后重试等待 | 超时后可重新发起Service Request |
| **T3502** | 60分钟 | Service Reject #9后等待时间 | 超时后重新注册 |

**设计意图**：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](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — Section 4.2.3.2 Service Request procedure
2. [3GPP TS 24.501](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3398) — Section 5.6.1 Service Request procedure, Section 8.2.15 SERVICE REQUEST message
3. [ShareTechnote - 5G NAS Service Setup](https://www.sharetechnote.com/html/5G/5G_ServiceSetup.html) — Service Request信令流程图解
4. [3glteinfo - 5G NAS Service Request](https://www.3glteinfo.com/messages/5g/nas/service-request/) — NAS消息IE详解
5. [HiCellTek - LTE vs 5G NR Signaling](https://hicelltek.com/en/lte-vs-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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)