51学通信

深度解析 3GPP TR 23.700-19：6.10 Solution #10 基于双PDN连接的CPUP组合与QoS方案

20分钟阅读

好的，我们继续进行深度拆解。这是本系列的第十五篇文章，将深入剖析一个在PDN连接管理上提出新思路的方案——Solution #10。

深度解析 3GPP TR 23.700-19：6.10 Solution #10: 基于双PDN连接的CP/UP组合与QoS方案

本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在我们已经探讨了多种在单一PDN连接内部进行优化的方案（如单承载、双承载、混合承载）之后，本文将带领我们进入一个全新的维度：跨PDN连接的协同。我们将深入解读 6.10 Solution #10，这是一个在架构上非常独特的方案，它大胆地提出使用两个独立的PDN连接来分别承载IMS信令和IMS语音，试图通过最高级别的隔离，来实现最清晰的QoS保障和路径控制。

引言：从“车道分离”到“高速公路分离”

在之前的方案中，Alex的团队一直在一个共同的框架下思考问题：如何在一个为IMS业务建立的单一PDN连接内部，通过划分不同的“车道”（EPS承载）来解决信令和语音的QoS冲突。无论是用户面的双承载（Solution #2），还是控制面/用户面的混合承载（Solution #8），都遵循着这个基本思路。

“我们一直在尝试在一座大桥上划分出快车道和慢车道，” Alex在一次新的架构评审会上提出了一个新问题，“但如果这座桥本身就不够稳固，或者入口设计不合理呢？我们有没有想过，干脆建两座完全独立的桥？一座专门走‘信令摩托’，另一座专门跑‘语音卡车’？”

这个“建两座桥”的想法，正是Solution 10的精髓。它不再局限于单个PDN连接内部的优化，而是将IMS信令和语音彻底分离到两个物理上和逻辑上都独立的PDN连接上，每个PDN连接都可以拥有自己独立的APN、IP地址、P-GW以及QoS策略。

This solution utilizes a pair of PDN connections.

规范开宗明义，一句话点明了其与其他方案的根本区别。

1. 方案总纲：6.10.0 High-level solution Principles (高层解决方案原则)

本节的一句话原则，清晰地定义了Solution 10的核心目标。

This solution addresses KI#1, in particular QoS aspects.

  • “addresses KI#1”: 目标依然是基础的IMS语音支持。
  • “in particular QoS aspects”: 特别强调了方案的主要动机是为了解决QoS问题。通过建立两个PDN连接，方案试图实现最彻底的QoS隔离。

NOTE: This solution does not address any optimization aspect e.g. on how to achieve a shorter call setup time… This solution is intended to be used together with other solutions to achieve such optimization.

这个注释非常重要，它明确了Solution 10的“专长”和“短板”。

  • 专长: 提供健壮的QoS分离架构。
  • 短板: 方案本身不关注呼叫建立时延等性能优化。
  • 协作性: 方案建议与其他优化方案（如Solution 9的IDLE态优化，或Solution 11等的协议压缩方案）组合使用，以形成一个完整的、既健壮又高效的解决方案。

2. 方案详述：6.10.1 Description - “双子星座”架构

本节通过一系列原则，详细描述了这个双PDN架构是如何运作的。

  • No impacts on the QoS mechanism in UE using NB IoT.

这是一个非常大胆的声明。方案声称，通过其架构设计，可以避免对UE在NB-IoT上现有的QoS机制产生影响。这是因为它将问题从“如何在一个受限的承载上区分QoS”转换为了“如何为两个独立的连接分别应用最适合的QoS”。

  • Two PDN connections are used for IMS voice, where one without DRB is used for SIP message exchange and the other with DRB is used for voice media. These two PDN connections are linked together by using (newly introduced) PDN connectivity pair ID.

这是Solution 10的核心灵魂。让我们逐句分解：

  • “Two PDN connections are used for IMS voice”: 为一次IMS语音通话，建立两个PDN连接。
  • “one without DRB is used for SIP message exchange”:
    • 第一个PDN连接（信令PDN）: 这个连接没有数据无线承载（DRB）。这意味着它是一个纯粹的控制面（CP）PDN连接。所有的SIP信令都将通过CP CIoT优化路径，经由MME传输。
  • “the other with DRB is used for voice media”:
    • 第二个PDN连接（媒体PDN）: 这个连接拥有一个数据无线承载（DRB）。这是一个标准的用户面（UP）PDN连接，专门用于高效传输RTP语音流。
  • “linked together by using … PDN connectivity pair ID”:
    • 这是实现“双子”协同的关键。为了让网络知道这两个独立的PDN连接实际上是服务于同一个IMS会话的，方案引入了一个新的参数——“PDN连接配对ID”。UE在发起这两个PDN连接请求时，会携带相同的pair ID。核心网中的相关节点（如MME, PGW, PCRF）就可以利用这个ID，将两个会话的上下文关联起来。
  • UE may explicitly request to establish PDN connection without DRB by using (newly introduced) “Control Plane Only Indicator requested” indicator.

为了建立那个纯CP的信令PDN，UE需要在PDN Connectivity Request中携带一个新的指示——“请求仅控制面指示”。MME看到这个指示后，就不会为这个PDN连接去触发DRB的建立。

  • UE internally associates contexts of the two PDN connections.
  • PCRF internally associates contexts of the two PDN connections.

这两个原则强调了上下文关联的重要性。在UE侧和网络策略核心（PCRF）侧，都需要维护这两个PDN连接之间的逻辑关联。例如，PCRF需要知道，针对pair ID = X的媒体PDN的授权，是依赖于pair ID = X的信令PDN上正在进行的SIP协商的。

Alex总结道：“Solution 10的架构异常清晰。它就是Solution 8混合承载思想的‘终极形态’。Solution 8是在一个PDN连接的‘屋檐’下管理两个不同类型的承载，而Solution 10则干脆为它们分配了两栋独立的‘房子’，并通过一个‘门牌号’（pair ID）将它们关联起来。这实现了最高级别的隔离，但也带来了新的协同问题。”

3. 流程剖析：6.10.2 Procedures - “双子”的诞生与协作

本节通过信令流程图，展示了这个双PDN方案的具体实现。

3.1 建立信令PDN连接 (6.10.2.2)

规范的 “Figure 6.10.2.2-1: Establishment of PDN connection for SIP message exchange” 展示了第一步：建立纯CP的信令PDN。

  1. 步骤 0-1: UE在附着后，发起第一次PDN Connectivity Request。
    • APN = ims
    • 携带新的"Control Plane Only Indicator requested"
    • 携带新的"PDN connectivity pair ID" (例如, ID=1)
  2. 步骤 2-4: MME → SGW → PGW → PCRF。
    • MME在Create Session Request中会包含Control Plane Only PDN Connection Indication和pair ID。
    • PGW和PCRF都会记录下，这个pair ID=1的PDN连接是一个纯控制面的信令连接。
  3. 步骤 5-6: 流程成功后，一个纯CP的PDN连接被建立。UE和MME之间建立起了NAS信令通道，MME和PGW之间也建立起了S11-U用户数据隧道。SIP消息就可以在这条路径上传输了。

3.2 IMS语音呼叫建立 (6.10.2.3.1 - MO procedure)

规范的 “Figure 6.10.2.3.1-1: IMS voice call setup MO” 展示了主叫流程。

  1. 步骤 0-8 (信令交互):

    • UE通过刚刚建立的信令PDN，发送SIP INVITE消息（封装在NAS中）。
    • 信令在IMS核心网中流转，P-CSCF向PCRF请求资源授权。
    • IMS网络返回183 Session Progress消息，其中包含了SDP Answer。

  2. 步骤 9: 建立媒体PDN连接

    • UE在收到183消息、解析出SDP后，认识到需要为媒体流建立一条新的通道。
    • UE发起第二次PDN Connectivity Request。
      • APN = ims_media (一个新的、专门用于媒体的APN)
      • 关键: 携带与信令PDN相同的"PDN connectivity pair ID" (ID=1)。
      • 这次不带"Control Plane Only Indicator"，因此将建立一个标准的UP承载。

  3. 步骤 10-14: 媒体PDN的建立与关联

    • MME/SGW/PGW/PCRF在处理这个请求时，会看到这个熟悉的pair ID=1。
    • PCRF就会将这个新的媒体PDN会话，与之前已经存在的、同样pair ID=1的信令PDN会话关联起来，形成一个完整的IMS会话视图。
    • MME会选择与信令PDN相同的PGW，以保证策略的统一。
    • 最终，一个标准的、拥有DRB的用户面媒体PDN被建立。

  4. 步骤 15-后续:

    • 语音媒体路径（voice media path）在新的媒体PDN上准备就绪。
    • 后续的RTP语音包，将通过这个UP承载进行传输。
    • 后续的IMS信令（如200 OK, ACK），依然通过之前的信令PDN传输。

4. 影响分析：6.10.3 Impacts on Services, Entities and Interfaces

Solution 10引入了新的概念，因此对多个网络实体都提出了新的要求。

  • UE:
    • 核心改动: 需要支持管理两个服务于同一IMS会话的PDN连接，并能在发起请求时生成和携带PDN connectivity pair ID和Control Plane Only Indicator。
  • MME, SGW, PGW, PCRF:
    • 核心改动: 都需要支持识别、传递和处理PDN connectivity pair ID和Control Plane Only Indicator。
    • PCRF/PGW: 需要具备基于pair ID关联不同PDN连接会话上下文的能力，这是实现统一策略控制的关键。
  • IMS Network (P-CSCF):
    • 潜在影响: UE现在因为有两个PDN连接，可能会拥有两个IP地址。P-CSCF需要能够处理来自一个UE、但在SIP信令（Via, Contact头）和媒体描述（SDP c-line）中使用不同IP地址的情况。这是一个重要的互通性问题。

5. 结论：终极的隔离，协同的挑战

Alex最后对Solution 10进行了全面的评价：“Solution 10为我们展示了一种在架构上最为‘干净’的QoS解决方案。它通过物理和逻辑上都完全独立的双PDN连接，实现了信令和语音的终极隔离，为各自路径的独立优化提供了最大的可能性。”

“它的优点是架构上的完美主义：”

  • “最彻底的QoS隔离： CP信令和UP媒体运行在完全独立的PDN连接中，互不影响，QoS策略可以被最清晰地应用。”
  • “路径选择最优化： 信令天然地运行在最高优先级的CP路径上，媒体则运行在最高效的UP路径上。”

“然而，这种架构上的完美，是以系统协同的巨大复杂性为代价的：”

  • “引入全新概念和信令： PDN connectivity pair ID等新参数需要端到端的标准化和支持，改动范围广。”
  • “双IP地址问题： 可能导致UE拥有两个IP地址，对IMS网络的信令处理和媒体绑定（Binding）带来了新的挑战。”
  • “资源消耗和信令开销： 建立和维护两个独立的PDN连接，会消耗双倍的会话上下文资源（在UE, MME, SGW, PGW中），并且引入了两次PDN连接建立的信令开销，这在高时延链路上会进一步延长呼叫建立时间。”

“总而言之，Solution 10是一个‘理论最优’的架构方案。它清晰地告诉我们，为了实现完美的QoS，我们可以走到哪一步。但它也提醒我们，架构的优雅往往伴随着实现的复杂。这个方案最大的价值，可能不在于它本身会被原封不动地采纳，而在于它提出的‘跨PDN关联’的思想，以及它所揭示的双IP地址等深层次问题，这些都为后续更成熟的方案设计，提供了宝贵的经验和教训。”

FAQ

Q1：Solution 10的核心思想是什么？它和Solution 8的“混合承载”方案有何本质区别？ A1：Solution 10的核心思想是使用两个完全独立的PDN连接来分别承载IMS信令和语音。一个PDN是纯控制面（CP）的，用于信令；另一个是纯用户面（UP）的，用于语音。它与Solution 8的本质区别在于隔离的级别：Solution 8是在一个PDN连接内部，通过两个不同类型的EPS承载进行隔离；而Solution 10则是在PDN连接的级别上进行隔离，这是更高、更彻底的隔离方式。

Q2：什么是“PDN connectivity pair ID”？为什么它是实现该方案的关键？ A2：“PDN connectivity pair ID”是Solution 10引入的一个新参数，用于逻辑上关联两个独立的PDN连接。它是关键，因为网络需要一种机制来得知“这个为ims_media APN建立的UP连接”和“那个为ims APN建立的CP连接”实际上是服务于同一个用户的同一次IMS通话的。通过在建立这两个PDN连接时使用相同的pair ID，UE和网络（特别是PGW/PCRF）就能将它们的会话上下文链接起来，实现统一的策略控制、计费和会话管理。

Q3：为什么信令PDN连接要设置为“without DRB”（没有数据无线承载）？ A3：因为这个PDN连接被设计为纯控制面（CP）连接。在CP CIoT优化模式下，少量用户数据（这里是SIP信令）被封装在NAS消息中，通过信令无线承载（SRB）在空口传输，数据路径经过MME。这个过程完全不需要建立专门的用户面无线通道，即数据无线承载（DRB）。因此，通过请求一个“without DRB”的PDN连接，UE明确告知网络，它希望为这个连接启用纯粹的控制面传输路径。

Q4：双PDN连接方案可能导致UE拥有两个IP地址，这会带来什么问题？ A4：这会给IMS信令处理带来挑战。在SIP协议中，Via和Contact头域通常携带UE用于信令的IP地址，而SDP（Session Description Protocol）中的c-line则携带UE用于接收媒体的IP地址。在常规情况下，这两个地址是相同的。但在双PDN方案中，信令PDN和媒体PDN可能会被分配不同的IP地址。P-CSCF在处理来自该UE的SIP消息时，必须能够正确理解和处理这种信令源IP和媒体源IP不一致的情况，并确保能够将媒体流正确地路由到UE的媒体IP地址。这需要IMS网络具备处理这种“分裂IP”场景的能力。

Q5：该方案建议与其他优化方案组合使用，可以举一个例子吗？ A5：当然可以。Solution 10本身只解决了QoS的架构问题，但没有优化呼叫建立时延。它可以与**Solution #9（IDLE态呼叫发起优化）**完美结合。组合后的流程可能是：

  1. IDLE态的UE发起呼叫，发送一个增强的Service Request，其中捆绑了第一次PDN连接（信令PDN）的建立请求（包含Control Plane Only Indicator和pair ID），甚至可以直接捆绑SIP INVITE。
  2. 网络侧在处理这个请求时，一步到位地建立起CP信令通道，并立即开始处理SIP INVITE。
  3. 当IMS网络返回183 Progress后，UE再发起第二次PDN连接（媒体PDN）的建立流程。 通过这种组合，既利用了Solution #9“抢跑”的优势来加速初始信令交互，又利用了Solution 10的双PDN架构来保证后续通话的QoS。

关系图谱