51学通信

深度解析 3GPP TS 23.207：第六章及附录 QoS协商的“信令之舞”

18分钟阅读

好的，我们继续对TS 23.207的深度拆解。

这是系列文章的第四篇，也是我们对这份规范解读的最终章。我们将深入规范的第六章：端到端QoS流程 (End-to-End QoS Procedures) 以及相关的附录。这一部分是整个规范的“动态剧本”，它将我们在第五章学到的静态“器官图”激活，展示了端到端QoS协商这一“生命活动”的完整信令流程。

深度解析 3GPP TS 23.207：第六章及附录 QoS协商的“信令之舞”

本文技术原理深度参考了3GPP TS 23.207 V18.0.0 (2024-03) Release 18规范中，关于“Chapter 6 End-to-End QoS Procedures”及相关附录的核心章节。本文旨在为读者呈现一幅动态的、端到端的QoS协商“信令之舞”全景图。我们将把之前学过的所有功能实体串联起来，通过具体的流程和场景，揭示一个来自应用层的QoS“愿望”，是如何转化为网络中实实在在的资源预留和策略执行的。

引言：从“蓝图”到“行动”，上演QoS协商的芭蕾舞

在上一篇中，我们已经“解剖”了端到端QoS系统的四大核心“器官”——UE, GGSN(PCEF), PCRF, AF。我们知道了每个器官的内部构造和职责。现在，是时候让它们“活”起来，共同上演一出名为“QoS协商”的精妙芭蕾舞了。

这场舞蹈的“剧本”，正是第六章“End-to-End QoS Procedures”。它不再描述静态的功能，而是聚焦于动态的**“流程（Procedures）”和“交互（Interaction）”。它将告诉我们，当用户李雷**点击视频会议App的“呼叫”按钮时，一场跨越应用层、IMS核心网、分组核心网和无线接入网的复杂信令交互，是如何在他毫不知情的情况下，在几百毫秒内精准完成的。

附录A至D则是这场舞蹈的“精彩选段集锦”和“背景音乐谱”，它们通过更具体的场景（Scenarios）和协议映射（如SDP, RSVP），为我们提供了更丰富的实践参考。

今天，我们将扮演这场芭蕾舞的“总导演”，跟随主线剧情（PCC流程），并穿插精彩的“选段”（RSVP流程），来完整地欣赏这场技术与艺术交融的“信令之舞”。

1. 6.1 QoS Procedures in Functional Elements (各功能实体的“舞步”分解)

本节首先从每个“舞者”（功能实体）的视角，提纲挈领地描述了它们各自的核心“舞步”。

  • 6.1.1 GGSN (PCEF): 它的“舞步”由UE发起的QoS信令（如PDP上下文激活）或PCRF下发的PCC规则来触发。它的核心动作是执行DiffServ边缘功能和策略。
  • 6.1.2 UE: 它的“舞步”由应用层（如SIP/SDP）的QoS需求来触发。它的核心动作是将应用需求向下映射为IP层（如RSVP）或UMTS层（如PDP上下文）的QoS参数。
  • 6.1.3a PCRF: 它的“舞步”由PCEF上报的IP-CAN会话事件或AF上报的业务信息来触发。它的核心动作是进行QoS授权，并将业务信息映射为QoS规则。
  • 6.1.4 AF: 它的“舞步”由应用层的会话信令（如收到SIP INVITE）触发。它的核心动作是解析应用信令（如SDP），并将提取出的业务信息传递给PCRF。

2. 6.3 Session Flow: QoS Interaction Procedures (会话流：PCC交互流程)

这是整场“舞蹈”的主线剧情。虽然规范原文在很多具体流程上都直接引用了更为详细的TS 23.203 (PCC架构)，但它在这里构建了PCC与端到端QoS交互的核心框架。

让我们以附录A.2.5 Scenario 5（在Figure A.7中有详细图示）为蓝本，这是最能体现PCC完整能力的场景：UE通过应用层信令发起QoS授权，并由GGSN（PCEF）与PCRF/AF联动执行。

2.1 主线舞步：一场由AF发起的“三方会谈”

场景: 李雷的视频会议App（IMS客户端）发起呼叫。

  1. 第一幕：AF向PCRF的“请求”

    • 动作: 李雷的SIP INVITE信令到达P-CSCF (AF)。AF解析出SDP中的媒体描述（如视频、带宽20Mbps）。
    • 信令: AF向PCRF发起AA-Request（Diameter消息），其中包含了从SDP中提取的业务信息（Service Information）。这就像是AF向PCRF说：“我需要为这个用户的视频流，申请一条20Mbps的VIP通道。”

  2. 第二幕：PCRF的“决策”与“预授权”

    • 动作: PCRF收到请求，进行策略决策（检查用户签约、网络策略等）。
    • 信令:
      • PCRF向AF回复AA-Answer，表示“请求已收到，正在处理”。
      • 同时，PCRF在内部生成了针对这个视频流的PCC规则，并将它们暂存起来，关联到这个会话。此时，这些规则是“待激活”状态。

  3. 第三幕：UE的“行动”与PCEF的“请示”

    • 动作: 李雷的UE在应用层信令交换的同时，或者之后，会发起一个二次PDP上下文激活/修改（Activate/Modify Secondary PDP Context）请求，用于承载这个视频流。这个请求中，会包含一个授权令牌（Authorization Token），这个令牌是在IMS注册时，由P-CSCF(AF)通过SIP信令传递给UE的。
    • 信令: 这个PDP上下文请求，通过SGSN，最终到达GGSN (PCEF)。
    • PCEF的动作: GGSN(PCEF)收到请求，解析出授权令牌。它并不知道这个令牌意味着什么，于是它向PCRF发起一次CC-Request（Diameter消息），其中包含了PDP上下文的QoS参数和这个授权令牌。这就像是PCEF向PCRF请示：“老大，有人拿着这张‘令牌’，申请开通一条承载，你看怎么办？”

  4. 第四幕：PCRF的“授权”与GGSN的“执行”

    • 动作: PCRF收到来自PCEF的请求。它使用授权令牌，将这个PDP上下文请求，与之前AF请求的那个“待激活”的会话关联起来。
    • 信令: PCRF发现一切吻合，于是将之前暂存的PCC规则，通过CC-Answer消息，正式下发给GGSN(PCEF)。指令中可能包含：“允许建立承载，QoS参数为xxx，为此业务流打开门控，计费规则为yyy…”。
    • 执行: GGSN(PCEF)收到最终指令，建立/修改PDP上下文，并在用户面配置好相应的流过滤器、门控和QoS策略（如DSCP标记）。
    • 舞步完成: PDP上下文建立成功，信令原路返回UE。至此，一条从应用层发起，经过PCC“神经中枢”精确调控的、端到端的QoS保障承载，宣告建立成功。李雷的视频数据，开始在这条VIP通道上畅快地流动。

3. 6.3.2 & 附录D：RSVP的“协奏曲”

除了PCC这条主线，规范还为RSVP这条技术路线，谱写了另一首“协奏曲”。

6.3.2.2 Resource Reservation with IP QoS signalling Editor’s note: There is still ongoing work in IETF on new IP QoS signalling techniques…Procedures describing resource reservation with end-to-end RSVP are described in Annex D.

  • 核心思想: 在这种模式下，QoS的建立由UE侧的RSVP信令驱动。

  • 附录D.1 (Figure D.1): MO Resource Reservation with End-to-End RSVP

    • 舞步分解:
      1. UE先建立“基础管道”: UE首先发起一个普通的二次PDP上下文激活，建立一条“尽力而为”的数据承载。
      2. UE发起RSVP“探路”: 视频会议App通过这条已建立的管道，向上游发送一个RSVP PATH消息。这个消息对GGSN来说，可能只是一个普通的IP包，它会将其透明转发到骨干网。
      3. 网络响应: PATH消息到达接收端，接收端返回RSVP RESV消息。
      4. UE“升级管道”: UE收到RESV消息后，知道了端到端的路径已经支持资源预留。于是，它可能会发起一次**PDP上下文修改（Modify PDP Context）**请求，将之前建立的“普通管道”的QoS，升级为与RSVP预留资源相匹配的、有保障的QoS。

  • 与PCC的结合 (Figure D.3): RSVP还可以与PCC架构（这里用更通用的PDF - Policy Decision Function来表示PCRF）结合。

    • GGSN在收到UE发来的PDP上下文请求或RSVP消息时，可以向PDF（PCRF）发起策略查询（COPS REQ），请求获取策略信息。
    • PDF根据策略，返回决策（COPS DEC）。
    • GGSN根据这个决策，来决定是否接受PDP上下文或RSVP请求。

4. 附录C：SDP到QoS授权的映射 - “翻译”的艺术

Annex C (informative): Sample Mapping of SDP Descriptions Into QoS Authorization

这个附录，为我们揭示了“信使”**AF（P-CSCF）**内部的“翻译”工作细节。

  • 输入: 一段来自SIP信令的SDP描述。 
    m=audio 29170 RTP/AVP 3 96 97  // 媒体类型: 音频, 端口, 协议, 编码格式
a=rtpmap:97 AMR                  // 编码详情
b=AS:64                          // 带宽: 64 kbps
  • 输出: 一个QoS授权请求，其中包含了：
    • Filter Specs (IP flow 5-tuples): 业务流的五元组。AF会根据SDP中的IP地址（c=行）、端口（m=行）和协议（m=行），生成精确的IP五元组过滤器，如SrcIP, SrcPort, DstIP, DstPort, Protocol。
    • Data rate and QoS class: AF会根据媒体类型（m=行，audio vs video）和带宽（b=行），向PCRF请求一个合适的QoS等级（QoS class）和数据速率（Data rate）。

场景演绎: 当P-CSCF(AF)看到m=audio和b=AS:64时，它就知道这是一个对话类的业务，带宽需求是64kbps。于是，它会向PCRF请求一个适用于会话语音的QoS授权。PCRF据此，可能会决策下发一个QCI=1的PCC规则。附录C，正是这座连接应用层语义与网络层QoS参数的“罗塞塔石碑”。

FAQ环节

Q1：PCC流程（6.3）和RSVP流程（6.3.2）是互斥的还是可以共存的？ A1：它们可以共存，并且可以协同工作。一个运营商的网络可能：

  • 主要依赖PCC: 这是主流模式。对于所有IMS等AF可控的业务，都通过Rx/Gx接口进行中心化的策略控制。
  • 兼容RSVP: 对于一些不支持IMS，但终端支持RSVP的“哑”应用，允许UE通过RSVP信令来触发QoS。GGSN/P-GW在收到RSVP消息时，可以将其转换为对PCRF的策略请求，从而将RSVP流程纳入PCC的统一管控之下。这种灵活性，使得网络能够最大程度地兼容不同类型的应用和终端。

Q2：在PCC流程中，UE为什么要发送一个“授权令牌（Authorization Token）”？ A2：授权令牌是关联AF会话和IP-CAN承载的“粘合剂”。

  • 问题: PCRF如何知道，UE当前申请建立的这条PDP上下文，就是刚刚AF为那个视频会议所申请的呢？两者在时间上可能是异步的。
  • 解决方案: 1) AF在向PCRF申请资源授权时，PCRF会返回一个唯一的授权令牌给AF。2) AF通过应用层信令（如SIP 183 Session Progress），将这个令牌传递给UE。3) UE在发起PDP上下文请求时，再将这个令牌带上。4) GGSN(PCEF)将这个令牌上报给PCRF。5) PCRF看到这个令牌，就能将前后两次请求（一次来自AF，一次来自PCEF）精确地关联起来，从而应用正确的PCC规则。

Q3：在RSVP流程中，如果GGSN不处理RSVP消息（透明转发），那它如何知道要为这个流提供QoS保障呢？ A3：在这种模式下，GGSN的QoS行为是由UE后续的PDP上下文修改来驱动的。

  1. RSVP信令对GGSN是“透明”的，GGSN只是像普通路由器一样转发它们。
  2. UE在收到了端到端RESV成功的确认后，“得知”端到端路径已经就绪。
  3. 此时，UE需要扮演“主动请示者”的角色，它会发起一次**Modify PDP Context Request**，将这条承载的QoS参数，从“尽力而为”修改为RSVP协商出的高QoS等级。
  4. GGSN收到这个修改请求后，再按照标准的UMTS QoS流程，在无线侧和核心网侧，为这条承载分配实际的资源。

Q4：附录中的场景（Scenarios）为什么有这么多？它们之间有什么区别？ A4：附录A中的多个场景，是为了展示在不同的**“能力组合”**下，端到端QoS是如何实现的。

  • Scenario 1: 最基础的场景。UE不具备任何IP QoS能力（没有IP BS Manager），所有QoS控制都由网络侧（GGSN）完成。
  • Scenario 2: UE具备IP QoS能力（支持DiffServ标记），但不使用IP层信令（如RSVP）。UE可以主动为上行数据打DSCP标记。
  • Scenario 3/4: UE同时支持DiffServ和RSVP信令。这是能力最强的终端。
  • Scenario 5: 专门展示PCC架构下，由AF发起的业务级策略控制流程。 通过这些场景的分解，规范为不同能力的UE和网络，都提供了清晰的QoS实现路径。

Q5：作为系列终章，回顾TS 23.207，它在3GPP标准体系中最重要的历史贡献是什么？ A5：TS 23.207最重要的历史贡献，是为3GPP网络引入了“策略控制”的基因，并搭建了连接应用层与网络层的桥梁。

  • 引入PCC思想: 它首次系统性地提出了AF-PCRF-PCEF这一后来被称为PCC的核心架构思想，将QoS管理从过去简单的、基于签约的静态配置，带入了一个动态的、业务驱动的、可编程的新时代。
  • 打通应用与网络: 通过定义Rx接口和AF的角色，它第一次让网络能够“听懂”应用的语言（SDP），并为其提供动态的、匹配的资源保障。这为IMS的成功商用，以及后续所有对QoS有高要求的业务（VoLTE, VoNR, V2X, 云游戏…）在移动网络上的蓬勃发展，奠定了最根本的架构基石。 可以说，没有TS 23.207，就没有我们今天体验到的高质量、高可靠的移动多媒体世界。

关系图谱