51学通信

深度解析 3GPP TS 29.244：第5.2.8节 Session Reporting Rule Handling (会话报告规则处理)

20分钟阅读

好的，我们继续深入解析3GPP TS 29.244规范。

深度解析 3GPP TS 29.244：第5.2.8节 Session Reporting Rule Handling (会话报告规则处理)

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中，关于“第5.2.8节 Session Reporting Rule Handling”的核心章节，并结合3GPP TS 23.501中关于ATSSS和QoS监控的相关架构，旨在为读者提供一个关于PFCP协议中特殊事件报告机制——会话报告规则（SRR）的全景视图。

引言：超越流量统计，感知会话“状态”

在之前的系列文章中，我们已经系统地剖析了PFCP协议中PDR（识别）、URR（统计）、FAR（转发）、QER（QoS）、BAR（缓冲）以及专为多接入场景设计的MAR。这些规则共同构成了5G用户面功能（UPF）处理数据包的“IF-THEN”逻辑链。其中，使用情况报告规则（URR）作为网络的“会计师”，其核心使命是度量与特定PDR相关联的流量使用情况，例如数据量、时长等，为计费提供依据。

然而，网络运营和策略控制的需求远不止于计费。控制面（SMF）不仅想知道“用了多少”，更迫切地想知道“用得怎么样”以及“连接状态如何”。例如，对于一个同时使用5G和Wi-Fi的ATSSS会话，当Wi-Fi连接突然断开时，SMF需要被及时告知，以便调整流量策略。又或者，对于一个需要超低时延保障的GBR业务，SMF需要知道其实际的端到端时延是否真的达标。这些与具体流量计数无关的、描述整个会话或特定QoS流状态的事件，正是**会话报告规则（Session Reporting Rule, SRR）**所要处理的核心范畴。

The CP function may provision SRR(s) for a PFCP session in a PFCP Session Establishment Request or a PFCP Session Modification Request to request the UP function to detect and report events for a PFCP session that are not related to specific PDRs of the PFCP session or that are not related to traffic usage measurement.

SRR是PFCP协议中一位特殊的“情报官”，它不关心流过了多少数据，而是专注于监控会话层面的关键“状态”变化，并向SMF汇报。我们将继续跟随主角美美的脚步，探索SRR在她的电竞直播场景中如何发挥关键作用：

场景深化：美美正在咖啡馆进行一场重要的手游排位赛直播。她的手机通过ATSSS功能，建立了一个MA PDU会话，同时使用5G和Wi-Fi网络。SMF通过MAR规则，为她的游戏流配置了“最低时延”策略，为直播推流配置了“主备”策略。但新的挑战出现了：

  1. 连接稳定性挑战：咖啡馆的Wi-Fi信号突然变得极不稳定，频繁断开。SMF如何才能实时感知到Wi-Fi链路的不可用，从而动态地将所有流量（包括原本走Wi-Fi的）切换到5G，确保美美的游戏和直播不中断？
  2. 服务质量保障挑战：虽然为游戏流配置了低时延的QoS策略，但实际网络中可能出现拥塞，导致时延抖动。SMF如何才能持续监控游戏流的真实往返时延（RTT），并在其超出SLA（服务等级协议）承诺的阈值（如20ms）时得到告警，以便进行网络优化或策略调整？

这两个问题的答案，都指向了SRR。SMF将通过配置不同的SRR，赋予UPF“感知”接入链路状态和“度量”QoS流真实性能的能力。

1. SRR的核心定位与监控事件 (5.2.8.1 General)

SRR的核心定位是报告与流量计量无关的会话级事件。这使得它与专注于流量计量的URR形成了功能上的互补。

The CP function may provision SRR(s) for a PFCP session … to detect and report events for a PFCP session that are not related to specific PDRs of the PFCP session or that are not related to traffic usage measurement.

规范在本章节及相关章节中，明确了SRR可以监控和报告的几类关键事件：

  • 接入可用性变化 (Change of 3GPP or non-3GPP access availability)：这专用于MA PDU会话。当3GPP或非3GPP接入链路变得可用或不可用时，UPF可以向SMF报告这一状态变化。
  • QoS流级别的QoS监控 (Per QoS flow QoS Monitoring and Reporting)：UPF可以对指定的QoS流进行性能测量（如时延、丢包率等），并在测量结果满足特定条件（如超过阈值）时上报。
  • GTP-U路径QoS监控 (GTP-U Path QoS Monitoring)：UPF可以监控特定GTP-U路径的性能，这对于保障URLLC等高要求业务的传输质量至关重要。
  • N6抖动测量 (N6 Jitter Measurement)：UPF可以测量来自N6接口（数据网络侧）的流量抖动情况，这对于视频、XR等对抖动敏感的业务非常重要。

可以看到，SRR的监控范围覆盖了从接入链路状态到具体业务流性能的多个维度，为SMF提供了决策所需的全方位“态势感知”能力。

2. SRR的配置与下发 (5.2.8.2 Provisioning)

与其它规则类似，SMF通过PFCP会话建立请求（PFCP Session Establishment Request）或PFCP会话修改请求（PFCP Session Modification Request），向UPF下发一条或多条SRR。每条SRR都通过其唯一的SRR ID进行标识。

The CP function may request the UP function to detect and report one or more of the events listed in clause 5.2.8.1 by provisioning one or more SRRs in the PFCP Session Establishment Request or the PFCP Session Modification Request.

我们将通过解析Create SRR IE中的关键信息元素，来理解SRR的具体配置方法。规范中的 Table 7.5.2.9-1: Create SRR IE within PFCP Session Establishment Request 对此进行了详细定义。

关键信息元素 (IE)描述与作用
SRR IDSRR的唯一标识符，用于在会话内引用此规则。
Access Availability Control Information接入可用性控制信息：指示UPF监控并报告3GPP或非3GPP接入的可用性变化。
QoS Monitoring per QoS flow Control Information每QoS流的QoS监控控制信息：指示UPF对特定QoS流进行性能测量与报告。
Direct Reporting Information直接报告信息：指示UPF将事件报告直接发送给某个NF（如NEF/AF），而不是（或同时）发送给SMF。
Traffic Parameter Measurement Control Information流量参数测量控制信息：指示UPF测量N6抖动、UL/DL周期性等参数。

接下来，我们将结合美美的场景，对这些关键IE进行逐一剖析。

2.1 接入可用性监控 (Access Availability Control Information)

这是保障ATSSS功能稳定运行的核心机制。当SMF为一个MA PDU会话启用ATSSS时，它必须能够及时获知两条接入链路的状态。

Access Availability Control Information: This IE shall be present if the UPF needs to report when an access type becomes available or not available (see clause 5.20.4.2).

  • 场景示例：
    1. 在为美美的MA PDU会话建立PFCP会话时，SMF会下发一条SRR，其中包含Access Availability Control Information IE。该IE内部的Requested Access Availability Information字段（见 Table 7.5.2.9-2）会被设置为请求报告接入链路的变化。
    2. UPF收到此SRR后，其内部的**PMF（性能测量功能）**会与UE侧的PMF协同工作，持续监控3GPP和非3GPP两条链路的健康状况。
    3. 当美美在咖啡馆移动，Wi-Fi信号变得过弱导致连接中断时，UE侧的ATSSS-LL功能会检测到这一变化，并通过仍然可用的5G链路上报给UPF。
    4. UPF的PMF收到此信息后，判定非3GPP接入已不可用，这便触发了SRR。

2.2 每QoS流的QoS监控 (QoS Monitoring per QoS flow Control Information)

这是实现SLA保障、确保关键业务体验的核心工具。它允许网络从用户面真实地度量一个QoS流的性能，而不仅仅是依赖控制面的配置。

QoS Monitoring per QoS flow Control Information: This IE shall be present if per QoS Flow QoS monitoring reporting is triggered.

该IE内部包含了丰富的参数，用于定义一次精细化的监控任务（见 Table 7.5.2.9-3）：

  • QFI：指定要监控的QoS流。

  • Requested QoS Monitoring：指定要测量的具体指标，如ULPD（上行包时延）、DLPD（下行包时延）、RPPD（往返包时延）。

  • Reporting Frequency：报告频率，可以是PERIO（周期性）或THR（基于门限）。

  • Packet Delay Thresholds：与THR配合使用，定义触发报告的时延门限值。

  • Measurement Period：与PERIO配合使用，定义报告的周期。

  • 场景示例：

    1. SMF为保障美美的游戏体验，下发了第二条SRR，专门用于监控游戏数据流。
    2. 该SRR中的QoS Monitoring per QoS flow Control Information IE配置如下：
      • QFI: 指向游戏流的QFI（例如，5QI=82，代表实时游戏）。
      • Requested QoS Monitoring: 设置RPPD标志，要求测量往返时延。
      • Reporting Frequency: 设置为THR，基于门限报告。
      • Packet Delay Thresholds: 设置Round trip packet delay threshold = 20ms。
    3. UPF收到此SRR后，其PMF功能开始对所有进出该QoS流的数据包进行时延测量（这通常需要与RAN侧进行时间戳配合）。
    4. 如果在游戏过程中，由于网络瞬时拥塞，UPF测得某一对数据包的RTT为25ms，超过了20ms的门限，该SRR被触发。

3. SRR的报告机制 (5.2.8.3 Reporting)

当SRR的触发条件被满足时，UPF会立即通过**PFCP会话报告请求（PFCP Session Report Request）**消息，向SMF（或SRR中指定的其他NF）发送报告。

When detecting one of the events for which a report has been requested in one of the SRRs of the PFCP session, the UP function shall send a PFCP Session Report Request including a Session Report IE.

报告的核心内容封装在**会话报告IE（Session Report IE）**中。该IE的结构在 Table 7.5.8.6-1 中有详细定义，其内部的关键组件与SRR的监控项一一对应：

  • SRR ID：指明是哪条SRR触发了本次报告。

  • Access Availability Report：用于报告接入可用性的变化。

  • QoS Monitoring Report：用于报告QoS流的性能测量结果。

  • Traffic Parameter Measurement Report：用于报告N6抖动等参数的测量结果。

  • 场景联动示例：

    1. 当Wi-Fi连接中断，触发了接入可用性监控的SRR后，UPF会向SMF发送一个PFCP Session Report Request。其中Session Report IE内部会包含一个Access Availability Report IE，内容为：Access Type = Non-3GPP, Availability Status = Access has become unavailable。
    2. SMF收到此报告后，立即采取行动。它会发送一个PFCP Session Modification Request给UPF，更新与美美PDU会话相关的所有MAR规则，将其中原本可能使用Wi-Fi的策略（如Load-Balancing或Smallest Delay）全部修改为Active-Standby模式，并将3GPP接入设置为唯一的Active路径。这样，美美的所有流量都会无缝地切换到5G链路上，她的游戏和直播体验不会受到任何影响。
    3. 与此同时，如果游戏时延超过20ms，触发了QoS监控的SRR，UPF会发送另一个PFCP Session Report Request。其中Session Report IE内部包含一个QoS Monitoring Report IE，内容为：QFI = 82, QoS Monitoring Measurement.RPPD = 25ms。
    4. SMF收到此时延超标报告后，可能会将其上报给**NWDAF（网络数据分析功能）**进行分析，或者触发与PCF的交互，检查是否有更高优先级的业务抢占了资源，从而进行动态的QoS策略调整。

通过这两类SRR报告的联动，SMF不仅保障了连接的连续性，还对业务体验进行了主动监控和潜在优化，实现了真正智能化的网络管理。

FAQ环节

Q1：SRR（会话报告规则）和URR（使用情况报告规则）最根本的区别是什么？

A1： 最根本的区别在于报告的内容和目的。URR专注于流量计量，它报告的是与某个PDR（包检测规则）关联的数据流“用了多少”资源，例如数据量（Volume）、时长（Duration）或事件次数，其主要目的是为了计费和用量控制。而SRR专注于会话状态和性能监控，它报告的是与具体流量计数无关的会话级事件，例如一个多接入会话的某条链路是否可用，或者某个QoS流的实际时延、抖动等性能指标是否达标，其主要目的是为了动态策略调整和SLA保障。

Q2：在ATSSS场景下，UPF是如何得知Wi-Fi链路不可用的？

A2： 这是通过UE和UPF中内置的**PMF（性能测量功能）**协同完成的。当一个MA PDU会话建立后，UE和UPF会通过两条接入链路（3GPP和非3GPP）周期性地交换探测包，以测量各自的性能，如时延和丢包率。当Wi-Fi链路中断时，UE侧的PMF会最先检测到（例如，连续多个探测包无响应），然后它会立即通过仍然可用的3GPP链路，向UPF侧的PMF发送一个“接入不可用”的报告。UPF收到这个报告后，便确认了非3GPP链路的不可用状态，从而触发配置好的SRR向SMF汇报。

Q3：SRR可以监控所有QoS流的时延吗？还是只能监控特定类型的？

A3： SRR可以被配置为监控任何一个QoS流的性能，无论是GBR还是非GBR流，只要该QoS流有一个唯一的**QFI（QoS流标识符）**即可。SMF在下发SRR时，会在QoS Monitoring per QoS flow Control Information IE中明确指定要监控的QFI。UPF随后便会对所有标记了该QFI的数据包进行相应的性能测量。这使得网络可以对任何一个需要保障的关键业务流（如VoNR、实时游戏、远程控制等）进行精细化的SLA监控。

Q4：SMF收到SRR报告后，一定会修改UPF上的规则吗？

A4： 不一定。SMF收到SRR报告后的行为是基于策略的。对于某些事件，SMF通常会立即采取行动，例如，收到“接入不可用”的报告后，SMF会立刻修改MAR规则以避免业务中断。但对于另一些事件，SMF可能只是将信息记录下来或上报给其他网元。例如，当收到一个“时延超阈值”的报告时，SMF可能只是将该事件上报给NWDAF（网络数据分析功能）进行长期趋势分析，或者上报给PCF进行更复杂的策略评估，而不会立即修改QoS参数，以避免频繁的网络波动。

Q5：Direct Reporting Information（直接报告信息）有什么用？为什么不都报告给SMF？

A5： Direct Reporting Information IE允许UPF将SRR触发的事件报告直接发送给一个指定的NF，例如NEF（网络能力开放功能），进而送达给AF（应用功能），而不是必须经过SMF中转。这样做的主要好处是降低了时延和信令开销。对于某些对实时性要求极高的应用，例如云游戏或远程手术，应用服务器（AF）可能需要比SMF更快地知道网络性能的抖动。通过直接报告，UPF可以将QoS监控报告直接发给AF，使其能迅速做出应用层的适应性调整（如调整视频码率），而无需等待SMF→PCF→AF这条更长的信令链路。😊

关系图谱