# PDU会话建立完整信令流拆解：从NAS请求到QoS Flow创建的全链IE解析 PDU Session Establishment（PDU会话建立）是5G系统中最核心的会话管理过程之一，定义于 **3GPP TS 23.502 Section 4.3.2.2**。该过程在UE完成5GMM注册之后触发，负责建立UE到数据网络（DN）的完整用户面数据通路，包括SMF选择、UPF选择、N4会话建立、QoS Flow创建以及N3/N9隧道分配。本文将聚焦TS 23.502和TS 24.501中的具体机制，逐条消息拆解信令流程中的每一个关键Information Element。 --- ## 一、过程概览与触发条件 ### 1.1 过程定位 PDU Session Establishment在5G协议栈中的定位如下： | 维度 | 说明 | |------|------| | **协议层** | 5GSM（5GS Session Management），NAS层 | | **主规范** | TS 23.502 V18.x Section 4.3.2.2（UE发起） | | **NAS消息格式** | TS 24.501 Section 6.4.1（过程定义）、8.3.1/8.3.2（消息格式） | | **N4接口** | TS 29.244 Section 7.5.2（N4 Session Establishment） | | **NGAP接口** | TS 38.413 Section 8.4.1（PDU Session Resource Setup） | | **触发方式** | UE发起（主流）、网络发起（SMF/AF触发，TS 23.502 4.3.2.3） | ### 1.2 与LTE PDN Connectivity的本质区别 5G将注册（5GMM）和会话管理（5GSM）彻底分离。LTE中，PDN Connectivity Request搭载在Attach Request中隐式触发默认承载建立；5G中，UE必须先完成Registration，再显式发起独立的PDU Session Establishment。这种设计带来的好处是：会话管理与移动性管理解耦，支持更灵活的多会话并发、SSC模式切换和网络切片映射。 ``` LTE: Attach Request → PDN Connectivity Request（隐式绑定） 5G: Registration Request → Registration Complete → PDU Session Establishment Request（显式独立） ``` ### 1.3 触发条件 根据TS 24.501 Section 6.4.1.2，以下条件满足时UE发起PDU Session Establishment： - UE已完成5GMM Registration并处于5GMM-REGISTERED状态 - UE上层（应用层/IMS层）请求新的数据连接 - UE请求的DNN+S-NSSAI组合不在已有PDU Session中 - Request Type为"initial request"（初始请求） --- ## 二、完整信令时序图 以下是基于TS 23.502 Figure 4.3.2.2.1-1绘制的UE发起PDU Session Establishment完整信令流程： ```mermaid sequenceDiagram participant UE participant RAN as (R)AN/gNB participant AMF participant SMF participant UDM participant PCF participant UPF participant DN as Data Network Note over UE,DN: Step 1: UE发起PDU Session Establishment Request UE->>RAN: ULInformationTransfer (RRC) RAN->>AMF: NGAP Uplink NAS Transport + NAS(UL NAS Transport + PDU Session Establishment Request) Note right of UE: 启动定时器T3580 Note over UE,DN: Step 2: AMF执行SMF选择 AMF->>AMF: 基于S-NSSAI + DNN + SUPI选择SMF
（查询NRF或使用本地配置） Note over UE,DN: Step 3: AMF向SMF创建SM Context AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request
{SUPI, PDU Session ID, DNN, S-NSSAI, AMF ID, N1 SM Container} Note over UE,DN: Step 4: SMF向UDM获取签约数据 SMF->>UDM: Nudm_SDM_Get(SUPI, S-NSSAI, DNN) UDM-->>SMF: 订阅数据（允许的DNN列表、SSC模式、QoS Profile等） SMF->>UDM: Nudm_SDM_Subscribe(SUPI)（订阅数据变更通知） Note over UE,DN: Step 5: SMF与PCF建立策略关联 SMF->>PCF: Npcf_SMPolicyControl_Create
{SUPI, DNN, S-NSSAI, PDU Session Type} PCF-->>SMF: PCC Rules + Session AMBR + Authorized QoS Note over UE,DN: Step 6: SMF选择UPF并建立N4会话 SMF->>SMF: 基于DNAI + S-NSSAI + DNN + UE位置选择UPF SMF->>UPF: N4 Session Establishment Request
{F-TEID(CN), PDR, FAR, QER, URR} UPF-->>SMF: N4 Session Establishment Response
{F-TEID(UPF)} Note over UE,DN: Step 7: SMF返回N1N2消息给AMF SMF-->>AMF: Nsmf_PDUSession_CreateSMContext Response
含N1(PDU Session Establishment Accept) + N2(PDU Session Resource Setup) Note right of UE: 停止定时器T3580 Note over UE,DN: Step 8: AMF向RAN发送N2请求 AMF->>RAN: NGAP PDU Session Resource Setup Request
N2 SM Info + NAS PDU(PDU Session Establishment Accept) Note over UE,DN: Step 9: RAN建立无线承载并转发NAS给UE RAN->>UE: RRC Reconfiguration（建立DRB） RAN->>UE: DLInformationTransfer(NAS PDU Session Establishment Accept) Note over UE,DN: Step 10: RAN返回N2响应 RAN-->>AMF: NGAP PDU Session Resource Setup Response
{AN Tunnel Info(F-TEID), PDU Session ID} Note over UE,DN: Step 11: AMF更新SMF的SM Context AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request
{AN Tunnel Info, PDU Session Resource Setup Response} Note over UE,DN: Step 12: SMF更新UPF的N4会话 SMF->>UPF: N4 Session Modification Request
{AN Tunnel Info(F-TEID for DL)} UPF-->>SMF: N4 Session Modification Response Note over UE,DN: Step 13: SMF向AMF确认 SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response Note over UE,DN: Step 14: 可选 - SMF向PCF报告会话事件 SMF->>PCF: Npcf_SMPolicyControl_Update（会话开始通知） Note over UE,DN: 用户面数据通路建立完成 UE<<->>UPF: N3 Tunnel (GTP-U) UPF<<->>DN: N6 Interface ``` --- ## 三、关键消息IE逐步解析 ### 3.1 PDU Session Establishment Request（TS 24.501 Section 8.3.1） 这是UE发出的第一个NAS 5GSM消息，承载在UL NAS Transport中经gNB转发至AMF。 | IE名称 | 存在性 | TS 24.501章节 | 说明 | |--------|--------|---------------|------| | **Extended Protocol Discriminator** | 必选 | 9.2 | 值为0x2E，标识5GSM消息 | | **PDU Session ID** | 必选 | 9.3 | 取值范围0-255，标识此PDU会话 | | **PTI** | 必选 | 9.6 | Procedure Transaction Identity，匹配请求与响应 | | **Message Type** | 必选 | 9.7 | 0xC1（PDU Session Establishment Request） | | **Integrity Protection Maximum Data Rate** | 必选 | 9.11.4.7 | UL/DL各自的最大用户面完整性保护数据速率 | | **PDU Session Type** | 必选 | 9.11.4.11 | IPv4(001)/IPv6(010)/IPv4v6(011)/Ethernet(100)/Unstructured(101) | | **SSC Mode** | 必选 | 9.11.4.16 | SSC mode 1/2/3，决定会话连续性行为 | | **5GSM Capability** | 可选 | 9.11.4.1 | UE的5GSM能力（反射QoS、最大包过滤器数等） | | **Maximum Number of Supported Packet Filters** | 可选 | 9.11.4.9 | UE支持的最大包过滤器数量 | | **Always-on PDU Session Requested** | 可选 | 9.11.4.4 | 请求建立Always-on PDU会话 | | **SM PDU DN Request Container** | 可选 | 9.11.4.15 | 外部DN认证/授权信息（EAP消息） | | **DNN** | 可选 | 9.11.4.2 | 请求的Data Network Name | | **S-NSSAI** | 可选 | 9.11.4.3 | 请求的切片标识（SST + SD） | | **Extended Protocol Configuration Options** | 可选 | 9.11.4.6 | DNS请求、P-CSCF地址请求、IM CN标志等 | #### 关键IE设计意图 **DNN（Data Network Name）**：在5G中替代LTE的APN。当UE未提供DNN时，AMF/SMF使用UDM签约数据中的Default DNN。DNN的NAS编码格式与APN相同（TS 24.501 Section 9.11.4.2），但语义上DNN更准确地描述了"数据网络"的概念，而不仅仅是"接入点"。 **S-NSSAI**：由SST（Slice/Service Type，8bit标准值或24bit运营商自定义值）和可选的SD（Slice Differentiator，24bit）组成。UE只能使用Registration过程中AMF下发的Allowed NSSAI中的S-NSSAI来发起PDU Session Establishment。如果UE使用了不在Allowed NSSAI中的切片标识，AMF将拒绝请求。 **SSC Mode**：这是5G相比LTE的重要增强，三种模式决定了UE移动时PDU会话的锚点行为： ```mermaid graph TD A[SSC Mode选择] --> B[SSC Mode 1] A --> C[SSC Mode 2] A --> D[SSC Mode 3] B --> B1[UPF锚点不变
IP地址保持
适用:语音、IMS] C --> C1[离开锚点区域时
释放旧会话
重建新会话
IP地址改变] D --> D1[先建新锚点
再释放旧锚点
Make-Before-Break
IP地址暂时双栈] style B1 fill:#e8f5e9 style C1 fill:#fff3e0 style D1 fill:#e3f2fd ``` ### 3.2 AMF的SMF选择过程（TS 23.502 Section 4.3.2.2 Step 2） AMF收到PDU Session Establishment Request后，首先执行SMF选择。这是整个流程中的关键决策点： **SMF选择的输入参数：** | 参数 | 来源 | 用途 | |------|------|------| | S-NSSAI | NAS Request或Allowed NSSAI | 确定切片 | | DNN | NAS Request或UDM默认DNN | 确定目标数据网络 | | SUPI | Registration Context | 签约标识 | | UE Location（TAI） | AMF维护 | SMF服务区匹配 | | PLMN ID | 当前服务网络 | 漫游场景下选择H-SMF或V-SMF | **选择过程：** 1. AMF检查是否已有此PDU Session ID对应的SMF（会话已存在场景） 2. 若无，AMF通过NRF（Nnrf_NFDiscovery）查询：`supi + S-NSSAI + DNN + smf-service-area` 3. NRF返回候选SMF列表 4. AMF基于负载均衡策略选择一个SMF 5. 若NRF查询失败，AMF使用本地配置的默认SMF ### 3.3 Nsmf_PDUSession_CreateSMContext Request（TS 29.502 Section 5.1.1） AMF通过SBI（Service-Based Interface）调用SMF的Nsmf_PDUSession_CreateSMContext服务： **关键参数：** ``` Nsmf_PDUSession_CreateSMContext Request: ├── supi: "imsi-460001234567890" # 用户永久标识 ├── pduSessionId: 5 # PDU Session ID ├── dnn: "internet" # 数据网络名称 ├── sNssai: # 切片信息 │ ├── sst: 1 # eMBB │ └── sd: "112233" ├── pduSessionType: "IPV4V6" # PDU会话类型 ├── servingNfId: "amf-1" # AMF标识 ├── servingNetwork: "46000" # PLMN ID ├── n1SmContainer: # N1 SM信息（PDU Session Establishment Request的完整NAS PDU） │ └── ├── anType: "3GPP_ACCESS" # 接入类型 ├── ratType: "NR" # RAT类型 ├── ueLocation: # UE位置 │ └── tai: "46000123456" └── guami: # AMF的GUMMEI ``` ### 3.4 SMF处理流程（TS 23.502 Section 4.3.2.2 Steps 3-6） SMF收到请求后，执行一系列内部处理和外部交互： #### Step 3: 签约数据获取 SMF调用 `Nudm_SDM_Get(SUPI, S-NSSAI, DNN)` 获取以下关键数据： - **允许的DNN列表**：验证请求的DNN是否在签约范围内 - **允许的SSC Mode列表**：验证请求的SSC Mode是否被允许 - **允许的PDU Session Type列表**：IPv4/IPv6/IPv4v6/Ethernet/Unstructured - **Default 5QI和ARP**：默认QoS参数 - **Session AMBR**：会话级聚合最大比特率 - **Charging特征**：计费相关参数 #### Step 4: PCF策略关联 SMF调用 `Npcf_SMPolicyControl_Create` 获取PCC（Policy and Charging Control）规则： - **Authorized Default QoS**：包含5QI、ARP、GBR/MBR（对于GBR Flow） - **Authorized Session AMBR**：网络最终授权的上下行速率 - **Charging Key**：计费键值 - **Gate Status**：门控状态（open/close） #### Step 5-6: UPF选择与N4会话建立 SMF选择UPF是PDU Session Establishment中最关键的决策之一： | 选择因子 | 说明 | |----------|------| | **DNAI** | Data Network Access Identifier，UPF必须能到达目标DN | | **S-NSSAI** | UPF必须支持对应的网络切片 | | **UPF服务区** | UPF的覆盖区域必须包含UE当前TA | | **UPF容量与负载** | 避免选择过载的UPF | | **PDU Session Type** | UPF必须支持IPv4/IPv6/Ethernet等类型 | | **SSC Mode** | SSC Mode 3可能需要选择两个UPF | | **UL CL/BP需求** | 上行分类器/分支点需求 | SMF与选定UPF之间的N4 Session Establishment（TS 29.244 Section 7.5.2）携带以下关键规则： ```text graph LR subgraph N4 Session Establishment A[PDR - Packet Detection Rule] --> A1[Source Interface: CORE/F-TEID] A --> A2[Destination Interface: ACCESS/CP-TEID] C[FAR - Forwarding Action Rule] --> C1[Action: FORWARD] C --> C2[Destination Interface: ACCESS] D[QER - QoS Enforcement Rule] --> D1[QFI: 9 (Default)] D --> D2[Gate Status: OPEN] D --> D3[UL/DL MBR/GFBR] E[URR - Usage Reporting Rule] --> E1[Measurement Method: VOLUME] E --> E2[Reporting Triggers] end ``` **N4 Session Establishment Request关键IE：** | IE | 说明 | |----|------| | **Node ID** | SMF的标识（IP+FQDN） | | **F-SEID** | SMF侧的N4会话端点标识 | | **Create PDR** | 创建包检测规则（匹配上行/下行数据包） | | **Create FAR** | 创建转发行为规则 | | **Create QER** | 创建QoS执行规则（含QFI、MBR、GBR） | | **Create URR** | 创建使用量上报规则（计费） | | **PDI（Packet Detection Information）** | 包检测信息：Source Interface + F-TEID或UE IP Address | ### 3.5 PDU Session Establishment Accept（TS 24.501 Section 8.3.2） SMF构建Accept消息经AMF和RAN转发至UE。这是整个过程中信息量最大的NAS消息： | IE名称 | 存在性 | 说明 | |--------|--------|------| | **PDU Session ID** | 必选 | 与Request中的相同 | | **PTI** | 必选 | 与Request匹配 | | **PDU Session Type** | 必选 | 网络最终接受的类型（可能与请求不同） | | **SSC Mode** | 必选 | 网络授权的SSC Mode | | **PDU Address** | 必选 | 分配给UE的IP地址/前缀 | | **Authorized QoS Rules** | 必选 | 网络授权的QoS规则（含默认QoS Flow的QFI=9） | | **Session AMBR** | 必选 | 上下行聚合最大比特率 | | **5GSM Cause** | 条件 | 某些场景下的原因值 | | **DNN** | 条件 | 网络选择的DNN（可能与请求不同） | | **S-NSSAI** | 条件 | 网络选择的切片（含映射的HPLMN S-NSSAI） | | **Always-on PDU Session Indication** | 可选 | 指示此会话是否为Always-on | | **Mapped EPS Bearer Contexts** | 可选 | EPS承载映射（用于5G→LTE互操作） | | **EAP Message** | 条件 | DN认证/授权的EAP消息 | | **Extended Protocol Configuration Options** | 可选 | DNS地址、P-CSCF地址等 | **PDU Address IE详解：** 当PDU Session Type为IPv4v6时，PDU Address包含一个IPv4地址和一个IPv6接口标识符。IPv6地址的前缀通过Router Advertisement在用户面传递（TS 23.502 Section 5.8.2.2.2），IPv4地址直接在NAS层分配。 ### 3.6 N2 PDU Session Resource Setup（TS 38.413 Section 8.4.1） AMF通过NGAP接口向gNB发送PDU Session Resource Setup请求： **NGAP PDU Session Resource Setup Request Transfer关键IE：** | IE | 说明 | |----|------| | **PDU Session Aggregate Maximum Bit Rate** | 上行/下行Session AMBR | | **UL NG-U UP TNL Information** | UPF的N3隧道端点（F-TEID，IP+TEID） | | **QoS Flow Setup Request List** | 需要建立的QoS Flow列表 | | **QoS Flow Identifier (QFI)** | 默认QFI=9（Non-GBR） | | **QoS Flow Level QoS Parameters** | 5QI、ARP、Priority Level等 | | **PDU Session Type** | IPv4/IPv6/Ethernet等 | | **Security Indication** | 用户面完整性保护和加密指示 | gNB收到后建立DRB（Data Radio Bearer），通过RRC Reconfiguration向UE配置无线侧资源，同时将PDU Session Establishment Accept作为NAS PDU通过DLInformationTransfer转发给UE。 --- ## 四、QoS Flow创建机制深度解析 ### 4.1 QoS Flow vs EPS Bearer 5G的QoS模型（TS 23.501 Section 5.7）相比LTE的承载模型有本质区别： ```mermaid graph TB subgraph "LTE QoS模型" L1[EPS Bearer] --> L2[Default Bearer
QCI: 9] L1 --> L3[Dedicated Bearer 1
QCI: 1] L1 --> L4[Dedicated Bearer 2
QCI: 5] end subgraph "5G QoS模型" N1[PDU Session] --> N2[Default QoS Flow
QFI: 9, 5QI: 9] N1 --> N3[QoS Flow 1
QFI: 1, 5QI: 1] N1 --> N4[QoS Flow 2
QFI: 2, 5QI: 5] end style N2 fill:#e8f5e9 style N3 fill:#e3f2fd style N4 fill:#fff3e0 ``` 关键区别： | 维度 | LTE EPS Bearer | 5G QoS Flow | |------|---------------|-------------| | QoS标识 | QCI（QoS Class Identifier） | 5QI + QFI | | 粒度 | 每个承载一个QCI | 一个PDU Session内多个QoS Flow | | 信令开销 | 每个承载需要独立的NAS/NGAP信令 | QoS Flow由SMF通过QoS规则控制 | | 默认QoS | Attach时自动建立默认承载 | PDU Session Establishment时自动建立默认QoS Flow | | 反射QoS | 不支持 | UE可通过上行包自动推导下行QoS规则 | | 用户面标记 | 不标记（承载级隐式映射） | N3/N9隧道使用QFI标记（GTP-U Extension Header） | ### 4.2 默认QoS Flow的创建 在PDU Session Establishment过程中，SMF自动创建一个默认QoS Flow（通常QFI=9，5QI=9，Non-GBR），无需UE显式请求。这个默认QoS Flow的参数来源于PCF下发的PCC规则或UDM签约数据中的Default 5QI。 **Authorized QoS Rules结构（TS 24.501 Section 9.11.4.12）：** ``` QoS Rule: ├── Rule Identifier: 1 # 规则ID ├── Rule Operation Code: 1 # 创建默认QoS规则 ├── DQR bit: 1 # Default QoS Rule标识 ├── QoS Rule Precedence: 255 # 最低优先级（兜底规则） ├── QFI: 9 # QoS Flow Identifier ├── Packet Filter List: (空) # 默认规则无包过滤器，匹配所有流量 └── Packet Filter Identifier: 0 # 无特定过滤器 ``` 默认QoS Rule的特点是**没有包过滤器**（Packet Filter List为空），这意味着它匹配PDU Session中所有未被其他QoS Rule匹配的数据包——这就是"Best Effort"的兜底规则。 ### 4.3 QoS Flow的状态转换 ```mermaid stateDiagram-v2 [*] --> QoSFlowNotExists: PDU Session建立前 QoSFlowNotExists --> DefaultQoSFlowCreated: PDU Session Establishment
(SMF自动创建QFI=9) DefaultQoSFlowCreated --> DedicatedQoSFlowAdded: PDU Session Modification
(SMF添加专用QoS Flow) DedicatedQoSFlowAdded --> QoSFlowModified: PDU Session Modification
(更新QoS参数) QoSFlowModified --> QoSFlowModified: 参数持续调整 DedicatedQoSFlowAdded --> DefaultQoSFlowOnly: PDU Session Modification
(删除专用QoS Flow) DefaultQoSFlowOnly --> DefaultQoSFlowCreated: 再次添加专用Flow DefaultQoSFlowCreated --> [*]: PDU Session Release DefaultQoSFlowOnly --> [*]: PDU Session Release ``` --- ## 五、异常流程与5GSM Cause Code分析 ### 5.1 PDU Session Establishment Reject原因值 根据TS 24.501 Section 6.4.1.4和Annex A，以下是最关键的Reject Cause值及其排错指引： | 5GSM Cause | 含义 | 典型原因 | 排错方向 | |-----------|------|---------|---------| | #26 | Insufficient Resources | UPF资源不足、N4会话数达到上限 | 检查UPF容量、N4 Session数 | | #27 | Missing or Unknown DNN | 请求的DNN不在签约数据中 | 检查UDM中该SUPI的Allowed DNN列表 | | #28 | Unknown PDU Session Type | 请求的PDU Type不被支持 | 检查SMF配置和UDM签约的PDU Type | | #29 | User Auth/Authorization Failed | DN-AAA认证失败 | 检查SM PDU DN Request Container | | #46 | Out of LADN Service Area | UE在LADN服务区外 | 检查UE位置与LADN可用区 | | #50 | PDU Session Type IPv4 Only Allowed | 网络只允许IPv4 | 修改UE请求的PDU Session Type | | #51 | PDU Session Type IPv6 Only Allowed | 网络只允许IPv6 | 修改UE请求的PDU Session Type | | #67 | Insufficient Resources for Specific Slice and DNN | 切片资源不足 | 检查该S-NSSAI+DNN的容量 | | #68 | Not Supported SSC Mode | 请求的SSC Mode不被支持 | 检查UDM签约允许的SSC Mode列表 | | #69 | Insufficient Resources for Specific Slice | 切片整体资源不足 | 检查该S-NSSAI对应的网络功能负载 | ### 5.2 定时器行为 | 定时器 | 方向 | 初始值（TS 24.501） | 超时行为 | |--------|------|---------------------|---------| | **T3580** | UE→NW | 16秒（默认） | 重传PDU Session Establishment Request，最多重传4次 | | **T3582** | NW→UE | 16秒（默认） | UE等待PDU Session Modification消息的定时器 | | **T3584** | NW→UE | 16秒 | UE等待PDU Session Release消息的定时器 | T3580超时4次后，UE认为PDU Session Establishment失败，向高层报告失败原因。 --- ## 六、抓包识别与故障排错 ### 6.1 Wireshark抓包识别 在Wireshark中识别PDU Session Establishment流程，按以下协议栈层次过滤： **N1接口（NAS层）过滤：** ``` # 过滤NAS 5GSM消息 nas-5gs.message_type == 0xc1 # PDU Session Establishment Request nas-5gs.message_type == 0xc2 # PDU Session Establishment Accept nas-5gs.message_type == 0xc3 # PDU Session Establishment Reject ``` **N2接口（NGAP层）过滤：** ``` # 过滤NGAP PDU Session Resource Setup ngap.procedureCode == 38 # PDU Session Resource Setup ``` **N4接口过滤：** ``` # 过滤PFCP N4 Session Establishment pfcp.message_type == 50 # PFCP Session Establishment Request pfcp.message_type == 51 # PFCP Session Establishment Response ``` **N11接口（SBI层）过滤：** ``` # 过滤SBI Nsmf_PDUSession服务调用 http2.headers.path contains "nsmf-pdusession" ``` ### 6.2 常见故障场景与排错思路 **场景1：PDU Session Establishment Request发出后无响应** 排查步骤： 1. 检查gNB是否正常转发UL NAS Transport（RRC层/NGAP层日志） 2. 检查AMF是否正确解析N1 SM Container并触发SMF选择 3. 检查SMF是否可达（SBI Nsmf_PDUSession_CreateSMContext超时？） 4. 检查T3580定时器是否触发重传 **场景2：SMF返回Reject #27 Missing or Unknown DNN** 排查步骤： 1. 解码NAS PDU中的DNN字段，确认UE请求的DNN拼写 2. 查询UDM中该SUPI的签约数据，确认Allowed DNN列表 3. 检查AMF是否正确传递了DNN（AMF可能使用了默认DNN替换UE请求的DNN） **场景3：PDU Session Establishment Accept但无数据通路** 排查步骤： 1. 检查N4 Session是否成功建立（PFCP Session Establishment Response的Cause） 2. 检查N3隧道端点是否正确交换（UPF的F-TEID和gNB的F-TEID） 3. 检查gNB是否收到NGAP PDU Session Resource Setup Response 4. 检查UPF是否收到更新的AN Tunnel Info（N4 Session Modification） ## 七、SSC Mode对PDU Session行为的影响 ### 7.1 三种SSC Mode的对比 | 特征 | SSC Mode 1 | SSC Mode 2 | SSC Mode 3 | |------|-----------|-----------|-----------| | **UPF锚点** | 固定不变 | 允许变更 | 允许变更 | | **IP地址** | 保持不变 | 随锚点变更而改变 | 过渡期保持旧IP，新锚点分配新IP | | **会话连续性** | 永远保持 | 断开再重建 | Make-Before-Break | | **适用场景** | IMS语音、会话类服务 | 后台数据、非实时应用 | 需要平滑切换的业务 | | **PDU Session ID** | 不变 | 释放后新建Session时改变 | 不变（锚点迁移） | | **切换复杂度** | 低（但可能绕路） | 低（直接释放重建） | 高（需要双UPF协调） | ### 7.2 SSC Mode选择逻辑 SMF根据以下优先级决定最终使用的SSC Mode： 1. UE请求的SSC Mode必须在UDM签约允许的SSC Mode列表中 2. 若UE请求的Mode不在允许列表中，SMF选择允许列表中的默认Mode 3. 若Reject，SMF包含5GSM Cause #68和Allowed SSC Mode IE --- ## 八、与EPS互操作的影响 PDU Session Establishment Accept中的**Mapped EPS Bearer Contexts** IE（TS 24.501 Section 9.11.4.5）为5G→LTE互操作做准备： - SMF将默认QoS Flow映射为EPS Default Bearer（EBI + QCI映射） - 专用QoS Flow映射为EPS Dedicated Bearer - 映射关系在PDU Session建立时就确定，而非切换时临时协商 **5QI到QCI的映射规则（TS 23.501 Table 5.7.4-1）：** | 5QI | QoS特性 | 映射QCI | |-----|---------|---------| | 1 | Conversational Voice | 1 | | 2 | Conversational Video | 2 | | 5 | IMS Signaling | 5 | | 9 | Default/Best Effort | 9 | | 70-76 | V2X | （视运营商配置） | | 80 | Low latency eMBB | 80 | --- ## 常见问题 **Q1: PDU Session Establishment和Registration有什么区别和依赖关系？** A: Registration是5GMM层的移动性管理过程，建立UE与AMF之间的信令连接和安全上下文。PDU Session Establishment是5GSM层的会话管理过程，建立UE到DN的数据通路。Registration必须先完成，UE才能发起PDU Session Establishment。一个Registration可以关联多个PDU Session（不同DNN/S-NSSAI组合）。 **Q2: UE没有在Request中携带DNN时，网络如何处理？** A: 根据TS 24.501 Section 6.4.1.2，当UE未提供DNN时，AMF使用UDM签约数据中的Default DNN。若签约数据中也没有Default DNN，AMF拒绝请求（5GSM Cause #27）。此外，AMF在调用Nsmf_PDUSession_CreateSMContext时会将选定的DNN传给SMF。 **Q3: 一个PDU Session中可以有多少个QoS Flow？** A: 标准未规定最大数量限制，但实际受限于UE支持的Maximum Number of Supported Packet Filters（在5GSM Capability中声明）和SMF/UPF的实现限制。典型商用网络中，一个PDU Session通常包含1个默认QoS Flow（QFI=9）+ 数个专用QoS Flow（如QFI=1/2/5用于IMS语音/视频/信令）。 **Q4: N4 Session Establishment失败会导致什么后果？** A: 若UPF返回PFCP Session Establishment Response中Cause不为"Success"，SMF将终止PDU Session Establishment过程，向UE返回PDU Session Establishment Reject（5GSM Cause #26 "Insufficient Resources"），并通过Nsmf_PDUSession_ReleaseSMContext释放已创建的SM Context。 **Q5: 反射QoS（Reflective QoS）在PDU Session Establishment中如何启用？** A: UE在5GSM Capability IE中声明支持Reflective QoS。SMF在PDU Session Establishment Accept的Authorized QoS Rules中可以为特定QoS Flow设置RQA（Reflective QoS Attribute）标记。当RQA被设置时，UE通过检测下行数据包中的QFI来推导上行QoS规则，无需SMF显式下发上行QoS规则。UPF会在下行GTP-U包的Extension Header中携带QFI，UE据此自动创建对应的包过滤器。 --- ## 参考来源 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.3.2.2 UE-requested PDU Session Establishment 2. [3GPP TS 24.501](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3370) — Section 6.4.1 PDU Session Establishment procedure, Section 8.3.1/8.3.2 NAS message format 3. [ShareTechnote - 5G PDU Session Establishment](https://www.sharetechnote.com/html/5G/5G_PDUSessionEstablishment.html) — NAS消息结构和IE详细说明 4. [3glteinfo - 5G NAS PDU Session Establishment Request](https://www.3glteinfo.com/messages/5g/nas/pdu-session-establishment-request/) — NAS消息IE参考和抓包分析 5. [HiCellTek - PDU Session Establishment](https://hicelltek.com/en/pdu-session-establishment/) — 5GSM NAS协议完整解读和LTE对比 --- > 本文由「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 等场景全覆盖。