51学通信

深度解析 3GPP TS 28.552：5.1.1.5 PDU Session Management (PDU会话管理)

22分钟阅读

深度解析 3GPP TS 28.552：5.1.1.5 PDU Session Management (PDU会话管理)

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.1.1.5 PDU Session Management”的核心章节，旨在为读者提供一个关于5G网络在无线侧如何为用户建立数据通道的性能测量全景解析。

引言：无人机“鹰眼-01”的“航线申请”

“王哥，音乐节的复盘报告我整理得差不多了，”年轻的网优工程师小林向他的导师老王汇报，“通过分析RRC连接数，我们精准地评估了现场用户的‘入场’和‘离场’规模，以及网络的峰值承载压力。但有个问题，这份报告好像只说明了‘有多少人进了公园’，却没说‘有多少人成功坐上了过山车’。”

老王赞许地笑了：“问得好，小林！你已经抓住了网络性能分析的精髓——分层解耦。RRC连接，仅仅是为用户打开了网络世界的大门。但用户真正的目的，是上网、看视频、玩游戏。要实现这些，就必须为他建立一条专属的数据通道，也就是我们常说的PDU会话。这就像在公园里，每个游客都需要一张‘游乐项目通票’才能玩具体的项目。今天，我们就来学习如何监控这些‘通票’的发放情况。”

他将TS 28.552规范翻到了5.1.1.5节。“PDU Session Management”，从gNB的视角来看，这一节并不管理PDU会话的完整生命周期（那是核心网SMF的工作），而是聚焦于一个关键环节：当核心网请求gNB为某个PDU会话分配无线资源时，gNB的响应情况。

为了让小林更直观地理解，老王调出了音乐节期间媒体直播团队的无人机“鹰眼-01”的信令回放。“这架无人机负责4K超高清直播，它的数据流必须通过一个高质量、高带宽的专用网络切片来传输。当它开机准备起飞时，它的通信模块就会向网络发起一次‘航线申请’，请求建立一个PDU会话。我们今天就以‘鹰眼-01’的这次任务为线索，看看gNB是如何处理它的‘航线申请’的，以及我们是如何通过这五个测量项来评估整个申请流程的效率和成功率的。”

这篇文章，我们将化身为“航线管制员”，通过解读PDU会话在无线侧的资源建立过程，理解5G网络是如何将一个抽象的“上网请求”转化为一条实实在在的数据链路的。

1. 航线申请的提交：5.1.1.5.1 Number of PDU Sessions requested to setup (请求建立的PDU会话数)

“鹰眼-01”在停机坪上完成了自检，旋翼开始缓缓转动。它的通信模块，作为UE，早已通过RRC连接与基站取得了联系。现在，它需要一条能够承载4K视频流的专用数据通道。于是，一个请求从核心网的AMF，穿越NG接口，抵达了gNB。

“小林，看这里，”老王指着信令流，“这就是我们测量的第一个动作：PDU SESSION RESOURCE SETUP REQUEST消息到达gNB。这标志着一次PDU会话资源建立流程的开始。”

a) This measurement provides the number of PDU Sessions by the gNB. This measurement is split into subcounters per S-NSSAI and per PLMN ID.

b) CC.

c) On receipt of PDU SESSION RESOURCE SETUP REQUEST message, INITIAL CONTEXT SETUP REQUEST message (see TS 38.413) by the gNB from the AMF. Each PDU Session requested to setup increments the relevant subcounter per S-NSSAI and per PLMN ID by 1.

e) SM.PDUSessionSetupReq.SNSSAI. Where SNSSAI identifies the S-NSSAI. SM.PDUSessionSetupReq.PLMN. Where PLMN identifies the PLMN ID.

1.1 深度解析

  • 目标 (a项): number of PDU Sessions requested to setup by the gNB。统计gNB收到了多少次“为PDU会话建立无线资源”的请求。这是所有后续成功、失败分析的基础，是总的“申请量”。

  • 类型 (b项): CC (Cumulative Counter)。这是一个累计计数器，来一个请求，计数器就加一，简单直接。

  • 触发条件 (c项): 这里提到了两个消息：

    1. PDU SESSION RESOURCE SETUP REQUEST: 当UE已经处于RRC Connected状态，需要新建一个PDU会话时，AMF会向gNB发送此消息。例如，“鹰眼-01”开机后已经连上了网，现在要开启直播流，就属于这种情况。
    2. INITIAL CONTEXT SETUP REQUEST: 当UE从Idle/Inactive状态恢复，并且在恢复的同时需要建立一个PDU会话时，AMF会将两者“打包”在一个消息里发给gNB。例如，一个刚开机的手机，在完成RRC连接后，AMF会立刻通过这个消息为它建立初始的上网通道。

  • 过滤维度 (a项 & e项): 这个计数器可以按照S-NSSAI（网络切片标识）和PLMN ID（运营商标识）进行细分。这是网络切片运维和多运营商共享网络运维的核心能力。

1.2 场景化举例：“鹰眼-01”的专属通道申请

“鹰眼-01”的SIM卡签约了媒体直播专用切片，其S-NSSAI为{SST=1, SD=123}。当它请求建立PDU会话时：

  1. AMF向gNB发送了PDU SESSION RESOURCE SETUP REQUEST消息，消息中明确携带了S-NSSAI {SST=1, SD=123}。
  2. gNB收到消息后，它内部的测量模块立刻执行了操作：SM.PDUSessionSetupReq.SNSSAI_1_123这个子计数器的值+1。

“通过这个子计数器，”老王解释道，“我们在后台就能清晰地看到，在音乐节期间，媒体直播切片总共发起了多少次PDU会话建立请求。这对于评估切片业务的活跃度至关重要。”

2. 航线批准，数据起飞：5.1.1.5.2 Number of PDU Sessions successfully setup (成功建立的PDU会话数)

gNB收到了“鹰眼-01”的请求后，立刻开始工作。它检查了无线资源，确认有能力满足4K直播流所需的QoS要求，于是为它分配了专属的数据无线承载（DRB），并配置好了相应的QoS流。一切准备就绪后，gNB向AMF回复了一条“航线已批准”的消息。

a) This measurement provides the number of PDU Sessions successfully setup by the gNB from AMF. This measurement is split into subcounters per S-NSSAI and per PLMN ID.

c) On transmission of PDU SESSION RESOURCE SETUP RESPONSE message, INITIAL CONTEXT SETUP RESPONSE message containing the “PDU Session Resource Setup Response List” IE (see TS 38.413) by the gNB to the AMF. Each PDU Session listed in the “PDU Session Resource Setup Response List” IE increments the relevant subcounter per S-NSSAI and per PLMN ID by 1.

e) SM.PDUSessionSetupSucc.SNSSAI.

2.1 深度解析

  • 目标 (a项): 统计gNB成功为多少个PDU会话请求分配了无线资源。这是衡量网络服务可提供性 (Availability) 的关键分子。

  • 触发条件 (c项): 触发动作为gNB向AMF发送对应的RESPONSE消息。这表明gNB已经完成了内部的资源分配和配置，并向核心网确认“我已经准备好了，可以让数据流过来了”。

  • 命名与过滤 (e项): 测量名为SM.PDUSessionSetupSucc，Succ是Success的缩写。同样，它也支持按S-NSSAI和PLMN ID进行细分统计。

2.2 场景化举例：PDU会话建立成功率 KPI

在“鹰眼-01”的案例中，gNB成功分配资源后，向AMF发送了PDU SESSION RESOURCE SETUP RESPONSE。此刻，gNB内部的SM.PDUSessionSetupSucc.SNSSAI_1_123子计数器+1。

“小林，现在我们有了‘申请量’和‘成功量’，你能想到什么？”老王问道。

“PDU会话建立成功率！”小林立刻回答，“成功率 = (SM.PDUSessionSetupSucc / SM.PDUSessionSetupReq) * 100%。我们可以为媒体切片单独计算这个KPI！”

“完全正确！”老王欣慰地说，“这个KPI是衡量一个切片、一个小区乃至整个网络服务接入能力的最核心指标之一。如果这个成功率低于99.5%，就意味着网络存在严重的接入问题，我们必须立刻介入调查。”

3. 航线驳回，原因何在：5.1.1.5.3 Number of PDU Sessions failed to setup (建立失败的PDU会话数)

现在，我们来看一个反面案例。音乐节现场的另一架备用无人机“鹰眼-02”，它所在的位置非常偏僻，无线信号覆盖较差。当它也尝试发起4K直播的PDU会话请求时，gNB经过评估，发现当前该区域的无线资源已经被大量普通观众占用，无法再额外承载一路高要求的GBR视频流。于是，gNB向AMF回复了一条“航线申请驳回”的消息。

a) This measurement provides the number of PDU Sessions failed to setup by the gNB. This measurement is split into subcounters per failure cause.

c) On transmission of PDU SESSION RESOURCE SETUP RESPONSE message, INITIAL CONTEXT SETUP FAILURE message containing the “PDU Session Resource Failed to Setup List” IE… Each PDU Session listed in the “PDU Session Resource Failed to Setup List” IE increments the relevant subcounter per failure cause… by 1.

e) SM.PDUSessionSetupFail.Cause. Where Cause identifies the cause of the PDU Sessions Resource Setup failure…

3.1 深度解析：失败乃成功之母，但前提是知道为何失败

  • 目标 (a项): 统计建立失败的PDU会话数量。

  • 触发条件 (c项): gNB向AMF发送包含“Failed to Setup List”的RESPONSE或FAILURE消息。

  • 最关键的维度——Cause (e项): This measurement is split into subcounters per failure cause. 这是故障诊断的“金钥匙”。规范不再按S-NSSAI过滤，而是要求按失败原因进行细分。这些原因码在TS 38.413中有详细定义，常见的包括：

    • radio-resources-not-available (无线资源不可用)
    • failure-in-radio-interface-procedure (无线接口流程失败)
    • invalid-qos-combination (无效的QoS组合)
    • radio-connection-with-ue-lost (与UE的无线连接丢失)
    • …等等

3.2 场景化举例：用Cause码精准定位故障

对于“鹰眼-02”的失败案例，gNB发送的FAILURE消息中携带的Cause就是radio-resources-not-available。因此，gNB内部的SM.PDUSessionSetupFail.Cause_RadioResNotAvail这个子计数器会+1。

在音乐节结束后复盘时，小林发现媒体切片的PDU会话建立成功率只有98%，不达标。他立刻查看了SM.PDUSessionSetupFail的各个子计数器分布：

  • ...Cause_RadioResNotAvail: 150次
  • ...Cause_UeLost: 5次
  • 其他原因: 2次

“王哥，一目了然！”小林指着数据说，“绝大部分失败都是因为无线资源不足。这说明我们在那个偏僻角落的容量规划有欠缺，或者是在高峰时段，普通用户的流量挤占了本应留给切片的资源，QoS策略没有生效！”

“非常好的分析，”老王说，“你看，没有Cause码的细分，我们只能得到一个笼统的‘失败了’的结论。而有了它，我们就拿到了清晰的优化方向——要么扩容，要么加强QoS保障。”

4. 网络会话的“实时人口”：平均与峰值会话数 (5.1.1.5.4 & 5.1.1.5.5)

解决了“能否上车”的问题，我们还需要关心“车上一直有多少人”。

4.1 深度解析与场景应用

5.1.1.5.4 Mean number of PDU sessions being allocated a) This measurement provides the mean number of PDU sessions that have been allocated in the NRCellCU. This measurement is split into subcounters per S-NSSAI. c) Each measurement is obtained by sampling at a pre-defined interval, the number of PDU sessions being allocated in the NRCellCU, and taking the arithmetic mean of the samples.

5.1.1.5.5 Peak number of PDU sessions being allocated a) This measurement provides the peak number of PDU sessions that have been allocated in the NRCellCU. c) Each measurement is obtained by sampling at a pre-defined interval… and selecting the sample with the maximum value…

这两个测量项与RRC连接数的平均/最大值测量方法如出一辙，都是通过周期性采样（SI） 来统计：

  • SM.MeanPDUSessionSetupReq.SNSSAI (平均数): 统计周期内，一个小区（或一个切片）上正在进行中的PDU会话的平均数量。它反映了网络的常规业务承载规模。
  • SM.MaxPDUSessionSetupReq.SNSSAI (最大数): 统计周期内，并发PDU会话数的峰值。它反映了网络在最繁忙时刻所承受的会话压力。

在音乐节的案例中：

  • 通过MeanPDUSession，老王团队可以评估媒体切片在整场活动中平均需要维持多少路直播流，用于计算切片的资源基线。
  • 通过MaxPDUSession，他们则能看到，在偶像登台、所有媒体都开启直播的那个瞬间，网络需要同时处理的PDU会话峰值是多少。这个数据对于gNB和核心网SMF/UPF的会话容量规划至关重要，很多网元设备能够支持的并发会话数是有限的，这个指标就是衡量是否逼近硬件或软件极限的“压力表”。

结论：PDU会话测量——服务可达性的试金石

“鹰眼-01”的航线申请之旅，完美地串联起了5.1.1.5节的五个核心测量项。通过这次学习，小林深刻地理解到，PDU会话在无线侧的资源建立测量，不仅仅是简单的计数，而是一个完整、闭环的诊断体系：

  1. Req (请求数) 定义了分析的总样本。
  2. Succ (成功数) 定义了服务的可提供性。
  3. Fail.Cause (失败数及原因) 提供了故障诊断的方向。
  4. Mean & Max (平均/峰值并发数) 评估了网络的容量压力和资源占用规模。

这五个测量项，共同回答了网络运维中最核心的问题之一：“用户想要的服务，我们的网络能给吗？如果不能，为什么？” 它们是连接用户请求和网络资源供给的桥梁，是衡量服务可达性的终极试金石。

FAQ 环节

Q1：PDU会话和RRC连接是什么关系？为什么有了RRC连接还需要PDU会话？ A1：可以把RRC连接比作进入一家餐厅并坐下，你和餐厅（网络）建立了联系。而PDU会话则是你向服务员（核心网）点了一份具体的套餐（如“上网套餐”或“语音通话套餐”），餐厅的厨房（gNB）为你准备好了餐具和上菜通道（无线承载）。一个用户可以只有一个RRC连接，但可以同时拥有多个PDU会话，比如一个用于上网，一个用于IMS通话。RRC连接是“在网”的信令基础，PDU会话是“业务”的数据通道。

Q2：管理PDU会话的到底是gNB还是核心网的SMF？ A2：PDU会话的“大脑”是核心网的SMF（会话管理功能）。SMF负责PDU会话的整个生命周期管理，包括创建、修改、删除，以及IP地址分配、QoS策略决策等。而gNB的角色是“执行者”。当SMF决定要建立一个PDU会话后，它会通过AMF指示gNB在无线接口上为这个会话分配实际的无线资源（DRB），并按照SMF下发的QoS策略进行数据调度。TS 28.552中这一节的测量，正是从gNB这个“执行者”的视角，来评估它执行这些指令的成功率和效率。

Q3：SM.PDUSessionSetupFail.Cause这个失败原因统计，对于网络优化有多大的实际价值？ A3：价值巨大，它是从“发现问题”到“定位问题”的关键一步。一个笼统的“PDU会话建立成功率下降”告警，可能对应着十几种完全不同的根本原因。而通过分析Cause码的分布，我们可以快速聚焦。例如，如果主要是radio-resources-not-available，说明是容量问题；如果是radio-connection-with-ue-lost，说明是覆盖或干扰问题，用户在建立过程中掉线了；如果是invalid-qos-combination，则可能是核心网与gNB之间的QoS参数配置不匹配。这种精细化的诊断能力，能将故障定位时间从几小时缩短到几分钟。

Q4：为什么需要同时测量Mean number和Peak number of PDU sessions？ A4：两者服务于不同的网络运维目标。Mean number（平均数）主要用于资源利用率评估和常规容量规划。它告诉我们，在正常情况下，网络需要承载多少并发业务，帮助我们评估资源是否被有效利用。而Peak number（峰值数）则用于网络极限能力验证和突发事件应对。它揭示了网络在最极端负载下的会话压力，是决定是否需要对设备（如gNB、SMF）进行会话容量扩容、以及评估网络在大型活动或突发情况下的稳定性的关键依据。

Q5：S-NSSAI这个过滤器在PDU会话测量中为什么如此重要？ A5：因为PDU会话是网络切片服务落地的直接载体。一个网络切片（由S-NSSAI标识）的核心承诺，就是为其承载的PDU会话提供特定的SLA保障（如带宽、时延、可靠性）。如果不对PDU会话测量按S-NSSAI进行过滤，我们就只能得到一个混合了所有切片业务的、模糊的平均性能。而通过S-NSSAI过滤器，我们可以独立地计算出每个切片的PDU会话建立成功率、失败原因分布、并发会话数等，从而能够真正地监控和保障每个切片的SLA，实现对不同行业客户的差异化服务承诺。

关系图谱