51学通信

深度解析 3GPP TS 29.552：5.7.14 Session Management Congestion Control Experience Analytics (会话管理拥塞控制体验分析)

21分钟阅读

好的，我们继续深入TS 29.552规范的特定分析流程。在前几篇文章中，我们已经探讨了网络拥塞、QoS、用户行为等多个关键分析领域。今天，我们将聚焦于一个更具体、更贴近协议层面的体验分析——会话管理拥塞控制体验分析。这涉及到5G核心网一个重要的自我保护机制，以及如何从用户的角度来评估这个机制的实际影响。

深度解析 3GPP TS 29.552：5.7.14 Session Management Congestion Control Experience Analytics (会话管理拥塞控制体验分析)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范中关于“5.7.14 Session Management Congestion Control Experience Analytics”的核心章节，旨在为读者详细拆解NWDAF是如何评估SMF（会话管理功能）的拥塞控制机制对用户PDU会话建立体验的实际影响，从而为网络策略优化和提升用户体验提供精细化的洞察。

前言：当网络“刹车”时，用户的“体感”如何？

在任何复杂的系统中，自我保护机制都至关重要。5G核心网中的SMF（会话管理功能），作为处理所有PDU会话建立、修改和释放的“交通枢纽”，当其自身或其所控制的下游网元（如UPF）面临超负荷运行时，会触发一种名为**“会话管理拥塞控制（SM CC）”**的机制。

这个机制，本质上是一种“流量管制”或“服务降级”。当拥塞发生时，SMF可能会：

  • 拒绝一部分新的PDU会话建立请求。
  • 延迟处理一部分请求，并告知UE“请稍后再试”。

这就像在高速公路入口处，交警因为主路拥堵而临时关闭了部分入口匝道。这种机制对于保护核心网不因过载而崩溃是必要的，但它无疑会直接影响到用户的体验。用户会感觉“上不了网”或“上网变慢了”。

那么，这种“刹车”机制的实际影响到底有多大？它在哪些区域、哪些时间段被频繁触发？哪些类型的用户或业务受影响最严重？仅仅依靠SMF自身的日志来回答这些问题是不够的，我们需要一个更高维度的、能够关联用户和业务上下文的分析。

这正是会话管理拥塞控制体验分析（SMCCE Analytics）的使命。它的核心任务，就是从用户和业务的视角，去度量和评估SM CC机制对用户体验的实际影响。

在“未来科技博览会”场景中，由于人流和业务量巨大，SMF集群的负载持续处于高位。运营商的网络体验保障团队（“QoE-Guards”）需要实时了解SMF的拥塞控制是否对观众的“扫码入场”、“扫码支付”等关键业务的连接成功率造成了影响。他们向‘洞察者’(Insight-AI)发起了这项分析的请求。

本文将深入5.7.14节的信令流程，看看‘洞察者’是如何收集SMF的“刹车”记录，并将其转化为一份关于用户真实“体感”的体验分析报告的。

1. 任务简报：量化“拥堵管制”的影响

这项分析的目标是，为消费者提供关于SMF的拥塞控制对UE PDU会话建立过程所造成体验影响的统计分析。

规范原文引用 (Clause 5.7.14 Introduction):

This procedure is used by the NWDAF service consumer e.g. SMF to obtain the Session Management Congestion Control Experience Analytics which are calculated by the NWDAF based on the information collected from the SMF.

‘洞察者’解读道：“我的任务很简单，但也很重要。我要当一名‘现场记者’，专门采访我的同事SMF。每当它因为拥堵而‘拒绝’或‘延迟’服务一位用户时，我都需要记录下来，并分析这次‘管制’对用户造成了多大的影响。”

  • 情报来源: 该分析的数据来源非常聚焦，核心情报完全来自于SMF。因为只有SMF自己，才知道它在何时、何地、对哪个UE、因为何种拥堵，实施了拥塞控制。
  • 分析ID: SM_CONGESTION
  • 分析维度: 这项分析可以从多个维度进行统计和下钻：
    • 区域维度: 哪个TAI或小区内的用户，经历SM CC的次数最多？
    • 时间维度: SM CC主要发生在每天的哪个时间段？
    • 切片/DNN维度: 哪个网络切片或数据网络上的业务，受SM CC影响最严重？
    • 拥塞原因维度: 是因为SMF自身CPU过高，还是因为找不到可用的UPF资源？

2. 行动方案：解构SMCCE分析的信令流程

规范中的 “Figure 5.7.14-1: Procedure for Session Management Congestion Control Experience Analytics” 为我们展示了这个流程。由于数据源单一，这个流程相对简洁和直观。

阶段一：任务启动 (步骤1)

“QoE-Guards”团队（作为消费者）向‘洞察者’发起订阅：“请为博览会区域，按切片维度，统计和分析SMF拥塞控制事件的发生频率和影响。”

步骤1a-1c：发起分析请求

消费者通过Nnwdaf_AnalyticsInfo_Request或Nnwdaf_EventsSubscription_Subscribe发起请求，analyticsId为SM_CONGESTION，并可以通过eventFilter来限定分析的范围（如areaOfInterest）。

阶段二：从SMF收集“拥堵管制”记录 (步骤2 - 3)

这是整个流程的核心数据收集环节。

规范原文引用 (Step 2a-2b):

The NWDAF may invoke Nsmf_EventExposure_Subscribe service operation by sending an HTTP POST request targeting the resource “SMF Notification Subscriptions” to subscribe to the notification of Information on UE ID and SMCC experience for PDU Session.

  1. 动作: ‘洞察者’向服务于该区域的SMF发起Nsmf_EventExposure_Subscribe订阅。
  2. 订阅内容: 订阅一个特殊的事件——SMCC（会话管理拥塞控制）体验数据。这份订阅就像是告诉SMF：“请把你每一次执行‘拥堵管制’的详细案底，都抄送我一份。”
  3. 信息流 (步骤3a-3b):
    • 场景: 在博览会午餐高峰期，一个服务于“扫码支付”业务的SMF实例负载飙升。此时，一位观众尝试扫码支付，其PDU会话建立请求到达了这个SMF。
    • SMF的行动: SMF判断自身已过载，决定拒绝这次请求，并向UE返回一个带有“back-off timer”（退避定时器）的拒绝消息，告诉UE“请10秒后再试”。
    • SMF的通知: 在执行这次拥塞控制的同时，SMF会立刻通过Nsmf_EventExposure_Notify服务，向‘洞察者’发送一个通知。
    • 通知内容 (SmccInfo): 这份“案底”非常详细，可能包含：
      • ueId: 被影响的UE的ID。
      • snssai: UE请求的切片。
      • dnn: UE请求的DNN。
      • areaOfInterest: UE所在的位置。
      • congestionType: 拥塞类型（例如，SMF_CPU_HIGH）。
      • backOffTimer: SMF建议UE等待的时间。

阶段三：分析计算与体验报告交付 (步骤4 - 5)

规范原文引用 (Step 4):

The NWDAF calculates the Session Management Congestion Control Experience analytics based on the data collected from SMF.

‘洞察者’持续地收集着来自各个SMF的“拥堵管制”事件报告。

  1. 统计与聚合分析 (Step 4): AnLF的分析引擎开始对这些原始事件数据进行加工和提炼：

    • 频率统计: 计算出在博览会区域，“扫码支付”切片上的SMCC事件发生频率为“每分钟10次”，远高于其他切片。
    • 影响范围分析: 发现受影响的用户主要集中在“餐饮区”。
    • 原因归因: 发现90%的事件，其拥塞原因都是SMF_CPU_HIGH。
    • 体验量化: 计算出用户的平均“受挫等待时间”（backOffTimer的平均值）为15秒。

  2. 生成分析报告: ‘洞察者’生成一份SMCCE分析报告：

    • 核心结论: “博览会餐饮区的‘扫码支付’业务，在午餐高峰期（12:00-13:00）正经历频繁的会话建立失败，主要瓶颈在于服务该区域的SMF-3实例CPU性能不足。这导致用户平均需要多等待15秒才能完成支付，QoE体验严重下降。”

  3. 交付报告 (Step 5a-5c): ‘洞察者’将这份精准的诊断报告，通过_Notify服务，交付给“QoE-Guards”团队。

闭环完成：“QoE-Guards”团队收到报告后，可以立即采取行动：

  1. 紧急扩容: 通知OAM系统，为SMF-3实例紧急增加虚拟CPU资源。
  2. 流量调度: 与AMF团队协作，调整AMF的SMF选择策略，将一部分来自餐饮区的新会话请求，引导到其他负载较低的SMF实例上。
  3. 长期优化: 将这次事件记录在案，作为网络容量规划的输入，考虑在未来对该区域的SMF集群进行永久性的扩容。

总结：洞察网络“自我保护”的代价

5.7.14节的SMCCE分析，为网络运维提供了一个独特的、聚焦于控制面拥塞体验的分析视角。它虽然不像业务体验分析那样“端到端”，但其价值在于精准和可归因。

  • 问题定位精准: 该分析的数据源直接来自拥塞控制的执行者——SMF，因此可以非常精确地知道拥塞的发生时间、地点、影响对象和直接原因。这为快速排障和优化提供了“靶向”指引。
  • 量化“软”指标: 它将“上不了网”、“连接慢”这种用户的主观抱怨，量化为了“SMCC事件频率”、“平均退避时间”等客观、可度量的技术指标，使得体验的优化变得有据可依。
  • 优化网络弹性策略: SMF的拥塞控制参数（如过载阈值、退避定时器的计算方法）通常是可以配置的。SMCCE的分析结果，可以反过来指导运营商去优化这些参数，在“保护网络”和“保障体验”之间，找到一个最佳的平衡点。

SMCCE分析，如同在网络的“刹车系统”上安装了一个性能监视器。它让运营商清楚地知道，每一次“踩刹车”的必要性、时机和力度是否得当，以及它对“乘客”（用户）造成了多大的“颠簸”。这种精细化的洞察，是实现一个既健壮又有弹性的、用户体验至上的5G网络所不可或缺的。

在下一篇文章中，我们将探讨一个与可靠性密切相关的、5G Advanced中的热门话题——5.7.15 Redundant Transmission Experience Analytics (冗余传输体验分析)，看看‘洞察者’是如何评估“双发选收”这类高可靠传输机制的实际效果的。

FAQ 环节

Q1：SMF的拥塞控制（SM CC）和UPF的用户面拥塞（User Data Congestion）有什么区别？

A1：它们是发生在不同层面、针对不同资源的拥塞：

  • SMF拥塞控制 (SM CC): 发生在控制面。拥塞的是SMF自身的处理能力（如CPU、内存）或其能调度的控制面资源（如可用的IP地址池、UPF连接池）。它影响的是PDU会话的建立、修改、删除等信令过程。当它发生时，用户会感觉“无法建立新的连接”。
  • 用户面拥塞 (User Data Congestion): 发生在用户面。拥塞的是数据传输的物理通道，如无线空口、UPF的数据处理能力、传输链路的带宽等。它影响的是已建立PDU会话的数据传输性能（速率、时延、丢包）。当它发生时，用户会感觉“网速变慢、卡顿”。 两者可能有关联（例如，大量会话建立请求也可能最终导致用户面流量增加），但它们是两个独立的拥塞域和分析对象。

Q2：这项分析的消费者为什么示例中是SMF自己？SMF分析自己的拥塞体验有什么意义？

A2：这是一个很好的问题，体现了NWDAF赋能网络功能“自我认知、自我优化”的设计思想。SMF作为消费者，订阅自己的拥塞体验分析，有以下重要意义：

  1. 参数自整定 (Self-tuning): SMF的拥塞控制策略（如启动拥塞控制的CPU阈值、给UE的back-off timer时长）通常是可配置的。NWDAF可以从一个更全局、更长期的视角去分析这些策略的实际效果。例如，NWDAF可能发现：“SMF-A的阈值设置得太敏感了，导致在业务高峰期频繁地误触发拥塞控制，影响了大量正常用户。” SMF收到这个分析后，就可以动态地、智能地调整自己的拥塞控制参数。
  2. 负载均衡决策: 在一个SMF Set（一组SMF）中，一个SMF可以订阅整个Set的SMCCE分析。如果它发现邻近的SMF-B频繁发生拥塞，而自己很空闲，它可以主动地通知AMF或NRF，请求多分担一些流量。 这体现了5G NF从被动接受配置，向主动感知、自我优化的智能化演进方向。

Q3：SmccInfo中上报的拥塞类型（Congestion Type）有哪些？

A3：规范定义了一系列标准的拥塞类型，帮助NWDAF和消费者精确地归因。例如（非完整列表）：

  • SMF内部资源: SMF_CPU_HIGH, SMF_MEMORY_HIGH。
  • 下游资源: NO_UPF_AVAILABLE (找不到可用的UPF), IP_ADDRESS_POOL_EXHAUSTED (IP地址用尽)。
  • 用户或会话限制: MAX_PDU_SESSIONS_REACHED_FOR_UE, MAX_PDU_SESSIONS_REACHED_FOR_DNN。 这些精细的原因码，使得网络运维能够“对症下药”，快速解决问题。

Q4：这项分析结果如何帮助提升用户体验？

A4：主要通过以下几个方面：

  1. 快速响应和恢复: 通过实时监控SMCCE，运维团队可以在用户大规模感知和投诉之前，就发现控制面的性能瓶颈，并采取紧急措施（如扩容、倒流），快速恢复服务。
  2. 优化网络容量规划: 通过对SMCCE数据的长期趋势分析，可以精确地识别出网络中的控制面容量瓶颈区域和时间段，为SMF、UPF等网元的容量规划和扩容提供科学依据。
  3. 驱动NF智能化: 如Q2所述，分析结果可以作为SMF等NF进行参数自整定的输入，使其拥塞控制行为更加智能、对用户影响更小。
  4. 差异化策略: 运营商可以根据分析结果，制定差异化的拥塞控制策略。例如，对于VIP用户或高优先级切片（如VoNR语音），即使在拥塞时也应尽量保障其会话建立成功，而可以优先拒绝低优先级业务的请求。

Q5：如果SMF因为极度拥塞，连上报SMCCE通知的能力都没有了怎么办？

A5：这是一个很现实的极端情况。如果SMF的CPU已经100%，它可能确实无法及时处理并发送_Notify消息，这会导致NWDAF无法感知到这些拥塞事件。对此，架构和运维上有几种补充机制：

  1. NF自身的优先级队列: SMF的内部实现通常会对任务进行优先级排序。上报管理和监控信息（如通知NWDAF）的优先级，通常会高于处理新的、低优先级的PDU会话请求。这可以尽量保证“上报通道”的畅通。
  2. 外部监控补充: 这种情况下，来自OAM的监控就变得至关重要。OAM系统通过带外管理接口，监控SMF的CPU、内存等底层资源。即使SMF自身“失声”，OAM也能发现其处于极度过载状态，并发出告警。
  3. NWDAF的关联分析: NWDAF不仅收集SMCCE，它还收集其他指标。如果‘洞察者’发现，某个区域的“PDU会话建立成功率”（来自OAM或PCF）在急剧下降，但却没有收到任何SMF上报的SMCCE事件，它就可以做出一个推断：“该区域的SMF可能已经处于极度拥塞或故障状态，甚至无法上报通知了。” 这体现了多源数据交叉验证的重要性。

关系图谱