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。
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) |
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(显式独立)
根据TS 24.501 Section 6.4.1.2,以下条件满足时UE发起PDU Session Establishment:
以下是基于TS 23.502 Figure 4.3.2.2.1-1绘制的UE发起PDU Session Establishment完整信令流程:
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<br/>(查询NRF或使用本地配置)
Note over UE,DN: Step 3: AMF向SMF创建SM Context
AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request<br/>{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<br/>{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<br/>{F-TEID(CN), PDR, FAR, QER, URR}
UPF-->>SMF: N4 Session Establishment Response<br/>{F-TEID(UPF)}
Note over UE,DN: Step 7: SMF返回N1N2消息给AMF
SMF-->>AMF: Nsmf_PDUSession_CreateSMContext Response<br/>含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<br/>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<br/>{AN Tunnel Info(F-TEID), PDU Session ID}
Note over UE,DN: Step 11: AMF更新SMF的SM Context
AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request<br/>{AN Tunnel Info, PDU Session Resource Setup Response}
Note over UE,DN: Step 12: SMF更新UPF的N4会话
SMF->>UPF: N4 Session Modification Request<br/>{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
这是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标志等 |
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会话的锚点行为:
graph TD
A[SSC Mode选择] --> B[SSC Mode 1]
A --> C[SSC Mode 2]
A --> D[SSC Mode 3]
B --> B1[UPF锚点不变<br/>IP地址保持<br/>适用:语音、IMS]
C --> C1[离开锚点区域时<br/>释放旧会话<br/>重建新会话<br/>IP地址改变]
D --> D1[先建新锚点<br/>再释放旧锚点<br/>Make-Before-Break<br/>IP地址暂时双栈]
style B1 fill:#e8f5e9
style C1 fill:#fff3e0
style D1 fill:#e3f2fd
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 |
选择过程:
supi + S-NSSAI + DNN + smf-service-areaAMF通过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)
│ └── <binary NAS PDU>
├── anType: "3GPP_ACCESS" # 接入类型
├── ratType: "NR" # RAT类型
├── ueLocation: # UE位置
│ └── tai: "46000123456"
└── guami: # AMF的GUMMEI
SMF收到请求后,执行一系列内部处理和外部交互:
SMF调用 Nudm_SDM_Get(SUPI, S-NSSAI, DNN) 获取以下关键数据:
SMF调用 Npcf_SMPolicyControl_Create 获取PCC(Policy and Charging Control)规则:
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)携带以下关键规则:
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 |
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层分配。
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。
5G的QoS模型(TS 23.501 Section 5.7)相比LTE的承载模型有本质区别:
graph TB
subgraph "LTE QoS模型"
L1[EPS Bearer] --> L2[Default Bearer<br/>QCI: 9]
L1 --> L3[Dedicated Bearer 1<br/>QCI: 1]
L1 --> L4[Dedicated Bearer 2<br/>QCI: 5]
end
subgraph "5G QoS模型"
N1[PDU Session] --> N2[Default QoS Flow<br/>QFI: 9, 5QI: 9]
N1 --> N3[QoS Flow 1<br/>QFI: 1, 5QI: 1]
N1 --> N4[QoS Flow 2<br/>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) |
在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"的兜底规则。
stateDiagram-v2
[*] --> QoSFlowNotExists: PDU Session建立前
QoSFlowNotExists --> DefaultQoSFlowCreated: PDU Session Establishment<br/>(SMF自动创建QFI=9)
DefaultQoSFlowCreated --> DedicatedQoSFlowAdded: PDU Session Modification<br/>(SMF添加专用QoS Flow)
DedicatedQoSFlowAdded --> QoSFlowModified: PDU Session Modification<br/>(更新QoS参数)
QoSFlowModified --> QoSFlowModified: 参数持续调整
DedicatedQoSFlowAdded --> DefaultQoSFlowOnly: PDU Session Modification<br/>(删除专用QoS Flow)
DefaultQoSFlowOnly --> DefaultQoSFlowCreated: 再次添加专用Flow
DefaultQoSFlowCreated --> [*]: PDU Session Release
DefaultQoSFlowOnly --> [*]: PDU Session Release
根据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对应的网络功能负载 |
| 定时器 | 方向 | 初始值(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失败,向高层报告失败原因。
在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"
场景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 1 | SSC Mode 2 | SSC Mode 3 |
|---|---|---|---|
| UPF锚点 | 固定不变 | 允许变更 | 允许变更 |
| IP地址 | 保持不变 | 随锚点变更而改变 | 过渡期保持旧IP,新锚点分配新IP |
| 会话连续性 | 永远保持 | 断开再重建 | Make-Before-Break |
| 适用场景 | IMS语音、会话类服务 | 后台数据、非实时应用 | 需要平滑切换的业务 |
| PDU Session ID | 不变 | 释放后新建Session时改变 | 不变(锚点迁移) |
| 切换复杂度 | 低(但可能绕路) | 低(直接释放重建) | 高(需要双UPF协调) |
SMF根据以下优先级决定最终使用的SSC Mode:
PDU Session Establishment Accept中的Mapped EPS Bearer Contexts IE(TS 24.501 Section 9.11.4.5)为5G→LTE互操作做准备:
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据此自动创建对应的包过滤器。
本文由「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 等场景全覆盖。
