跳到主要内容

QoS 和承载管理

概述​

PGW-C 实现了一个基于策略的承载和 QoS 管理系统，协调三个关键接口：

  • Gx (Diameter) - 从 PCRF 接收策略决策和 QoS 参数
  • S5/S8 (GTP-C) - 与 SGW-C 管理承载上下文
  • Sxb (PFCP) - 将 QoS 强制规则编程到 PGW-U

架构流程​

关键概念​

  • 会话: 包含 UE 信息、承载映射、PDR/FAR/QER/BAR 映射和 AMBR
  • 承载上下文: 将 EBI (EPS 承载 ID) 链接到特定的 PDR、FAR 和 QER
  • QER (QoS 强制规则): 在用户平面中强制执行 MBR/GBR 限制和门状态
  • 默认承载: 始终与 PDN 会话一起创建，提供基本连接
  • 专用承载: 根据 PCRF 策略动态创建���提供特定的 QoS 保证

配置​

重要提示: 动态 QoS 策略​

所有 QoS 参数通过 Diameter Gx 接口动态接收自 PCRF，并在 PCRF 中定义（有关更多信息，请参见 OmniHSS）。

运营商在 config/runtime.exs 中配置 PCRF 连接：

config :pgw_c,
  diameter: %{
    listen_ip: "0.0.0.0",
    host: "omni-pgw_c.epc.mnc999.mcc999.3gppnetwork.org",
    realm: "epc.mnc999.mcc999.3gppnetwork.org",
    peer_list: [
      %{
        host: "pcrf.epc.mnc999.mcc999.3gppnetwork.org",
        realm: "epc.mnc999.mcc999.3gppnetwork.org",
        ip: "192.168.1.100",
        initiate_connection: true
      }
    ]
  }

QoS 策略、计费规则和带宽限制在 PCRF 上配置，而不是在 PGW-C 配置文件中。

承载生命周期​

默认承载创建​

默认承载在 PDN 会话建立期间创建：

工作流程:

  1. SGW-C 发送 Create Session Request
  2. PGW-C 从配置的池中分配 UE IP 地址
  3. PGW-C 发送 CCR-Initial 到 PCRF，包含 IMSI、APN、IP 地址
  4. PCRF 响应 CCA-Initial，包含 QoS 参数：
    • Default-EPS-Bearer-QoS (QCI, ARP)
    • QoS-Information (AMBR 调整)
  5. PGW-C 创建承载上下文，包含：
    • 固定 ID: 下行 PDR=1，上行 PDR=2，下行 FAR=1，上行 FAR=2，QER=1，BAR=1
    • QER 编程为承载 QoS 中的 MBR
  6. PGW-C 向 PGW-U 发送 PFCP Session Establishment Request
  7. PGW-C 向 SGW-C 发送 Create Session Response

默认承载特性:

  • 在 PDN 会话的整个生命周期内始终存在
  • 通常使用 QCI 5 或 QCI 9（非 GBR）
  • EBI 在会话状态中跟踪
  • 不能独立删除（删除它会终止会话）

专用承载创建​

专用承载根据 PCRF 策略动态创建：

触发: 来自 PCRF 的 Re-Auth Request (RAR)，包含 Charging-Rule-Install

工作流程:

  1. PCRF 发送 RAR，包含 Charging-Rule-Definition，内容包括：
    • Charging-Rule-Name (策略规则标识符)
    • Flow-Information (数据包过滤器)
    • QoS-Information (QCI, MBR, GBR, ARP)
    • Precedence (规则匹配优先级)
  2. PGW-C 将动态规则转换为 PFCP 实体：
    • 每个 Flow-Information 条目 → 新的 PDR，带 SDF 过滤器
    • QoS-Information → 新的 QER，带 MBR/GBR 强制
    • Flow-Description → IP 5-元组匹配规则
  3. PGW-C 发送 PFCP Session Modification Request，以添加 PDRs/FARs/QERs
  4. PGW-C 向 SGW-C 发起 Create Bearer Request
  5. SGW-C 响应 Create Bearer Response，确认建立

示例 Charging-Rule-Definition:

Charging-Rule-Name: "video_streaming"
Flow-Information:
  - Flow-Description: "permit in ip from any to 10.0.0.1 5000-6000"
    Flow-Direction: 1 (downlink)
QoS-Information:
  QoS-Class-Identifier: 7
  Max-Requested-Bandwidth-UL: 5000000 (5 Mbps)
  Max-Requested-Bandwidth-DL: 10000000 (10 Mbps)
  Guaranteed-Bitrate-UL: 1000000 (1 Mbps)
  Guaranteed-Bitrate-DL: 2000000 (2 Mbps)
Precedence: 100
Flow-Status: 2 (ENABLED)

承载修改​

承载 QoS 可以通过以下方式修改：

  • Gx RAR，带更新的 Charging-Rule-Definition
  • PFCP Session Modification，以更新现有的 QERs（更改比特率）、FARs（更改转发）或 PDRs（更改数据包过滤器）

承载删除​

触发:

  • Delete Session Request（SGW 发起） - 删除默认承载并终止会话
  • Re-Auth Request with Charging-Rule-Remove（PCRF 发起） - 删除专用承载

工作流程:

  1. 从会话状态中移除承载
  2. 移除相关的 PDRs/FARs/QERs
  3. 向 SGW-C 发送 Delete Bearer Request（如果是 PCRF 发起）
  4. 发送 PFCP Session Modification（移除规则）或 Session Deletion（如果是默认承载）

QoS 参数​

QCI (QoS 类标识符)​

来源: PCRF 通过 Gx QoS-Class-Identifier AVP

标准值:

  • QCI 1: 对话语音 (GBR, 100ms 延迟预算)
  • QCI 2: 对话视频 (GBR, 150ms 延迟预算)
  • QCI 3: 实时游戏 (GBR, 50ms 延迟预算)
  • QCI 4: 非对话视频 (GBR, 300ms 延迟预算)
  • QCI 5: IMS 信令 (非 GBR, 100ms 延迟预算) - 默认用于默认承载
  • QCI 6: 视频 (基于 TCP)，直播流 (非 GBR, 300ms 延迟预算)
  • QCI 7: 语音，互动游戏 (非 GBR, 100ms 延迟预算)
  • QCI 8: 视频 (基于 TCP)，例如 YouTube (非 GBR, 300ms 延迟预算)
  • QCI 9: 默认互联网 (非 GBR, 300ms 延迟预算)

运营商注意:

  • QCI 从 PCRF 接收，并在承载级 QoS IE 中向 SGW-C 信号
  • PGW-C 不直接强制执行 QCI 行为 - 实际强制通过 QERs 中的 MBR/GBR 实现
  • 较低的 QCI 值通常表示更高的优先级
  • QCI 决定数据包转发处理和调度优先级

ARP (分配和保留优先级)​

来源: PCRF 通过 Allocation-Retention-Priority 分组 AVP

组件:

  • 优先级级别: 1（最高优先级）到 15（最低优先级）
  • 抢占能力: 此承载是否可以抢占低优先级承载？
    • 0 = 启用（可以抢占其他）
    • 1 = 禁用（不能抢占）
  • ���占脆弱性: 此承载是否可以被高优先级承载抢占？
    • 0 = 启用（可以被抢占）
    • 1 = 禁用（不能被抢占）

默认值:

  • 优先级级别: 1
  • 抢占能力: 启用 (0)
  • 抢占脆弱性: 禁用 (1)

运营商注意:

  • ARP 向 SGW-C 信号，最终传递到 eNodeB
  • PGW-C 不强制执行 - 强制通常在 eNodeB 的无线接入控制中进行
  • 在网络拥塞期间用于确定允许或删除哪些承载
  • 对于紧急服务（优先级级别 1）和高价值服务至关重要

MBR (最大比特率)​

来源: PCRF 通过 Max-Requested-Bandwidth-UL 和 Max-Requested-Bandwidth-DL AVPs

格式: 每秒字节（内部转换为 kbps: bytes / 1000）

适用范围: 所有承载（默认和专用）

工作原理:

  • PGW-C 创建 QER，带有 mbr: %Bitrate{ul: kbps_ul, dl: kbps_dl}
  • QER 通过 PFCP 发送到 PGW-U
  • PGW-U 强制执行速率限制（流量控制）
  • 超过 MBR 的流量将被丢弃

示例:

Max-Requested-Bandwidth-UL: 5000000 (5 Mbps)
Max-Requested-Bandwidth-DL: 10000000 (10 Mbps)

→ QER 创建为 mbr: {ul: 5000, dl: 10000} kbps
→ PGW-U 丢弃超过 5 Mbps 的上行数据包
→ PGW-U 丢弃超过 10 Mbps 的下行数据包

GBR (保证比特率)​

来源: PCRF 通过 Guaranteed-Bitrate-UL 和 Guaranteed-Bitrate-DL AVPs

格式: 每秒字节（转换为 kbps）

适用范围: 仅适用于专用承载（GBR 承载）

工作原理:

  • 如果在 Charging-Rule-Definition 中指定了 GBR，则承载为 GBR 类型
  • PGW-U 通过 QER 强制执行最小比特率保证
  • 需要在 eNodeB 进行适当调度以保留无线资源
  • GBR 承载有接入控制 - 如果资源不可用，可以被拒绝

示例:

Guaranteed-Bitrate-UL: 1000000 (1 Mbps)
Guaranteed-Bitrate-DL: 2000000 (2 Mbps)

→ QER 创建为 gbr: {ul: 1000, dl: 2000} kbps
→ 网络保证至少 1 Mbps 的上行和 2 Mbps 的下行
→ 用于 VoIP、视频通话、直播流

运营商注意:

  • GBR 需要足够的网络容量规划
  • 过度订阅 GBR 资源会导致接入失败
  • 通过会话计数和承载指标监控 GBR 使用情况

AMBR (聚合最大比特率)​

来源: PCRF 通过 APN-Aggregate-Max-Bitrate-UL 和 APN-Aggregate-Max-Bitrate-DL AVPs

范围: 适用于 所有非 GBR 承载 的 APN（而不是每个承载）

工作原理:

  • AMBR 是会话中所有非 GBR 承载的聚合限制
  • 在 Create Session Response 中发送到 SGW-C
  • 强制通常在 eNodeB/SGW 进行
  • PGW-C 在会话状态中存储 AMBR，并将其信号传递给 SGW-C

示例:

APN-Aggregate-Max-Bitrate-UL: 50000000 (50 Mbps)
APN-Aggregate-Max-Bitrate-DL: 100000000 (100 Mbps)

→ 所有非 GBR 承载的总和不能超过 50 Mbps 上行 / 100 Mbps 下行
→ 各个承载受其自身 MBR 限制
→ AMBR 为每个 UE/APN 提供额外的整体上限

运营商注意:

  • 通过 HSS/PCRF 中的订阅者配置文件设置
  • 用于强制执行订阅层级（例如，10 Mbps 计划与 100 Mbps 计划）
  • 不影响 GBR 承载

流状态和门控​

流状态 (Gx) 到门状态 (PFCP) 映射​

PCRF 控制通过 Flow-Status AVP 在 Charging-Rule-Definition 中是否允许流量：

Flow-Status (Gx)Gate-Status (PFCP QER)意义
0 = ENABLED-UPLINKul: OPEN, dl: CLOSED仅允许上行流量
1 = ENABLED-DOWNLINKul: CLOSED, dl: OPEN仅允许下行流量
2 = ENABLEDul: OPEN, dl: OPEN两个方向都允许
3 = DISABLEDul: CLOSED, dl: CLOSED不允许流量
4 = REMOVEDul: CLOSED, dl: CLOSED正在删除承载

用例:

  • DISABLED: 用于停放服务或信用耗尽（数据包丢弃但承载保留）
  • ENABLED-UPLINK: 不常见，但可以用于仅上传服务
  • ENABLED-DOWNLINK: 下载仅服务或信用有限的场景
  • ENABLED: 正常操作

监控与可观察性​

Prometheus 指标​

���话级指标:

session_registry_count        # 活动承载 (IMSI, EBI 对)
address_registry_count        # 分配的 UE IP
charging_id_registry_count    # 活动计费会话

Gx 接口指标:

gx_inbound_messages_total{message_type="gx_RAR"}     # 来自 PCRF 的策略更新
gx_outbound_messages_total{message_type="gx_CCR"}    # 向 PCRF 的策略请求
gx_outbound_transaction_duration_bucket              # 到 PCRF 的延迟

PFCP 接口指标:

sxb_outbound_messages_total{message_type="pfcp_session_establishment_request"}
sxb_outbound_messages_total{message_type="pfcp_session_modification_request"}
sxb_outbound_transaction_duration_bucket

承载创建指标:

s5s8_inbound_messages_total{message_type="create_session_request"}   # 默认承载
s5s8_outbound_messages_total{message_type="create_bearer_request"}   # 专用承载

Web UI 监控​

PGW 会话页面 (/pgw_sessions):

  • 按 IMSI、IP 地址、MSISDN 或 APN 搜索
  • 查看每个会话的活动承载
  • 检查承载 QoS 参数 (QCI, MBR, GBR, AMBR)
  • 实时自动刷新 (2 秒)

Diameter 页面 (/diameter):

  • PCRF 对等连接状态
  • Gx 会话计数
  • 对等状态（已连接/未连接）

日志页面 (/logs):

  • 实时日志流
  • 通过 "Credit Control" 过滤 CCR/CCA ���换
  • 通过 "Re-Auth" 过滤 RAR 事件（策略变化）
  • 通过 "PFCP" 过滤用户平面编程事件

关键日志消息​

[debug] Sending Credit Control Request: ...          # CCR 到 PCRF
[debug] Handling Credit Control Answer: ...          # CCA 来自 PCRF（包含 QoS）
[debug] Handling Re-Auth Request                     # RAR 来自 PCRF（策略变化）
[debug] Sending Session Establishment Request        # PFCP 到 PGW-U（编程 QERs）
[debug] Sending Session Modification Request         # PFCP 到 PGW-U（更新 QERs）

操作任务​

验证应用于会话的 QoS​

  1. 访问 Web UI → PGW 会话 页面
  2. 搜索 IMSI（例如，999000123456789）
  3. 展开会话详细信息
  4. 检查 qer_map 部分： 
    qer_id: 1
    gate_status: {ul: OPEN, dl: OPEN}
    mbr: {ul: 50000, dl: 100000}  # kbps
    gbr: {ul: 10000, dl: 20000}   # kbps（或 nil 表示非 GBR）
  5. 验证值与预期的 PCRF 策略匹配

排查缺失的 QoS​

症状: 会话已创建但未应用 QoS

步骤:

  1. 检查 PCRF 连接:

    • 访问 Web UI → Diameter 页面
    • 验证 PCRF 对等状态 = "connected"
    • 如果未连接，请检查网络连接和 Diameter 配置

  2. 验证 CCR/CCA 交换:

    • 访问 Web UI → Logs 页面
    • 搜索 "Credit Control Answer"
    • 验证 CCA 日志中存在 QoS-Information AVP
    • 检查 CCA 中的错误（Result-Code 应为 2001 = SUCCESS）

  3. 验证 PFCP 编程:

    • 搜索日志中的 "PFCP Session Establishment Request"
    • 验证消息中包含 QER
    • 检查 PGW-U 日志中的 PFCP 处理错误

  4. 检查 PCRF 策略配置:

    • 验证 PCRF 中的订阅者配置文件
    • 确认存在 APN 特定的策略规则
    • 检查 PCRF 日志中的策略评估错误

监控承载创建速率​

Prometheus 查询:

# 默认承载创建速率（会话/秒）
rate(s5s8_inbound_messages_total{message_type="create_session_request"}[5m])

# 专用承载创建速率
rate(s5s8_outbound_messages_total{message_type="create_bearer_request"}[5m])

# 来自 PCRF 的策略更新速率
rate(gx_inbound_messages_total{message_type="gx_RAR"}[5m])

容量规划​

关键指标监控:

# UE IP 地址利用率（百分比）
(address_registry_count / <configured_pool_size>) * 100

# 活动承载计数
session_registry_count

# PCRF 查询延迟（P95）
histogram_quantile(0.95, gx_outbound_transaction_duration_bucket)

容量限制:

  • 地址池大小：在 config/runtime.exs 中配置，位于 ue.subnet_map 下
  • TEID 空间：32 位（40 亿个唯一标识符，自动管理）
  • 并发会话：通常受地址池大小限制

规划指南:

  • 监控 IP 地址利用率 - 在超过 80% 之前扩展池
  • 监控 PCRF 延迟 - 高延迟会影响会话建立时间
  • 监控专用承载创建速率 - 指示策略复杂性

相关文档​

最后于 更新