51学通信

深度解析 3GPP TR 23.700-19：6.7 Solution #7 基于单一SRB和S1-U切换的CP语音方案

21分钟阅读

好的，我们继续进行深度拆解。这是本系列的第十二篇文章，将深入剖析一个力求极简的控制面方案——Solution #7。

深度解析 3GPP TR 23.700-19：6.7 Solution #7: 基于单一SRB和S1-U切换的CP语音方案

本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在我们探讨了Solution 5和6这两个试图在控制面复制复杂承载模型的方案之后，我们的目光将转向一个截然相反的设计哲学——极致简化。本文将深入剖析 6.7 Solution #7，这是一个独辟蹊径的控制面方案，它回归到最原始的单承载模型，并创新性地提出在通话过程中从控制面（CP）承载动态切换到用户面（UP）承载，试图在简单性、效率和性能之间找到一个全新的平衡点。

引言：从“复杂立交”到“智能潮汐车道”

Alex的团队在研究了Solution 5和6之后，陷入了沉思。无论是引入全新的SRB，还是在控制面复刻双承载模型，都带来了巨大的系统复杂性。团队里的资深架构师老张提出了一个发人深省的问题：“我们为了实现QoS分离，把系统搞得这么复杂，值得吗？有没有可能，我们从一开始就不需要那么复杂的分离？或者，只在真正需要的时候才进行分离？”

这个问题，恰好点亮了Solution 7的设计思路。Solution 7的工程师们仿佛在说：“为什么我们要在一条乡间小路上修建一座昂贵的永久性立交桥（复杂CP承载模型）呢？我们或许只需要一条‘智能潮汐车道’。”

  • 在通话建立的信令阶段（车流量小），信令和（可能存在的早期）媒体都挤在同一条控制面“车道”上，追求最快的建立速度。
  • 在通话保持的媒体阶段（车流量大且持续），如果需要，系统可以动态地开辟一条全新的用户面“高速公路”（S1-U数据通道），并将语音车流引导上去，以获得更好的传输效率。

“这是一种非常动态和务实的思路，” Alex评价道，“它不再追求一个‘一劳永逸’的静态架构，而是试图根据业务的实时需求，在控制面和用户面之间进行灵活的切换。这就像城市交通管理中的‘潮汐车道’，在不同时间引导车流走向最优路径。我们的任务，就是要搞清楚这条‘智能潮汐车道’是如何实现开通和切换的。”

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

本节用三个原则，概括了Solution 7的动态切换哲学。

  • The UE negotiates with MME on its capability of voice call support over NB-IoT as well as support of the Control Plane CIoT EPS optimisation and in addition support of S1-U data transfer.
  • The default EPS bearer is used for both IMS signalling and voice data transmission where an SRB is used for IMS signalling and can be switched to S1-U data transfer for voice data transmission if supported.
  • Bearer modification procedure for the QoS update or resource reservation is skipped or pre-initiated…

Alex为团队逐条解读这些原则：

  1. “UE与MME协商其…能力，以及对CP CIoT优化和S1-U数据传输的支持。”

    • 这是能力协商的“升级版”。UE（地理链接一号）在附着时，不仅要告诉网络它能打电话，还要告诉网络它掌握了两种“驾驶模式”：它既能走“控制面小路”（CP CIoT Optimisation），也能随时切换到“用户面高速”（S1-U data transfer）。这是实现动态切换的前提。

  2. “默认EPS承载被同时用于IMS信令和语音数据…其中SRB用于IMS信令，并且如果支持，可以切换到S1-U进行语音数据传输。”

    • 这是Solution 7的核心灵魂。它回归到了类似Solution 1的单默认承载模型。但与Solution 1最大的不同在于，这条承载的物理路径是动态可变的：
      • 初始阶段 (信令阶段): 默认承载的数据通过控制面路径（SRB → MME）传输。这利用了控制面启动快、优先级高的优点，非常适合传输呼叫建立时的SIP信令。
      • 切换后 (媒体阶段): 当通话接通，需要大量、持续地传输RTP语音包时，UE可以触发一次“切换”，将这个默认承载的底层数据路径，从控制面（CP）切换到用户面（UP），即从SRB路径切换到DRB → S1-U路径。

  3. “承载修改流程被跳过或预先发起…”

“所以，Solution 7的架构，” Alex在白板上画了一条可以变形的路径，“就像一条‘变形金刚’通道。它在呼叫建立时，呈现为一条高效的‘控制面通道’，以最快速度完成信令握手；在通话保持时，又能‘变形’为一条宽阔的‘用户面通道’，以最高效率传输语音数据。这种设计，试图兼得鱼与熊掌。”

2. 方案详述：6.7.1 Description

本节进一步阐述了这种动态切换的逻辑。

In this proposal, the use of Control plane CIoT EPS Optimisation is assumed to provide IMS voice services via the default EPS bearer. i.e. IMS signalling and IMS voice data are served via the default EPS bearer… And so the signalling and data are delivered via SRB. Moreover, Control plane CIoT EPS Optimisation can be used initially for SIP signalling for IMS call setup, later if continuous data transmission(e.g. voice call data transmission) is expected, UE may trigger switching to S1-U data transfer.

这段话清晰地描述了切换的触发逻辑：

  • 初始使用CP: 呼叫建立的信令阶段，默认使用CP CIoT优化，所有数据（信令，可能还有早期的媒体包）都通过SRB传输。
  • 按需切换到UP: 当进入持续的数据传输阶段（即通话接通后），UE可以主动触发 (UE may trigger) 切换到S1-U用户面传输。

这个“UE触发”是方案的一个关键特点，它赋予了UE根据自身应用需求和网络状况，决定数据路径的灵活性。

Editor’s note: Overhead analysis for this approach is to be updated.

规范的编辑注再次提醒，这种动态方案的开销和性能，依然有待详细的量化分析。

3. 流程剖析：6.7.2 Procedures - “潮汐车道”的切换魔法

本节详细描述了附着、承载使用和最关键的“S1-U切换”流程。

3.1 附着流程：协商“双模”能力 (6.7.2.1)

NB-IoT(GEO) cell shall broadcast … that it supports Control Plane CIoT EPS Optimisation… …UE … negotiate its capability of … Control Plane CIoT EPS Optimisation … and in addition include “S1-U data transfer is supported”.

  • 网络侧广播: 支持此方案的基站，需要在广播消息（SIB）中明确告知自己支持CP CIoT优化。
  • UE侧声明: UE在 Attach Request 中，除了包含 Preferred Network Behaviour = “CP CIoT Optimisation is supported”之外，还必须额外包含一个新的指示——"S1-U data transfer is supported"。这个双重声明，才算是完成了“双模”能力的协商。

3.2 初始承载：纯粹的控制面 (6.7.2.2)

For IMS service, we assume the default EPS bearer is used for both IMS signalling and voice data, which can be delivered via an SRB. Editor’s note: It is FFS whether an existing SRB or newly defined SRB is used for delivery.

在呼叫建立阶段，所有数据都通过SRB走控制面路径。这里，规范提出了一个与Solution 5类似的问题：是使用现有的SRB（如SRB1bis），还是需要定义一个新的SRB？如果信令和语音混跑在一个SRB上，又会回到Solution 1的QoS区分难题。这是一个方案细节上的开放性问题。

Editor’s note: It is FFS whether alternative approach(e.g. P-CSCF provides indication of voice call over NB-IoT(GEO)) is considered.

另一个编辑注提出了P-CSCF是否可以提供“这是卫星语音呼叫”的指示，这可以帮助网络更早地做出QoS决策。

3.3 切换激活：S1-U Data Transfer Activation (6.7.2.3)

这是Solution 7的**“魔法”核心**。

If S1-U data transfer is supported, UE triggers switching to data delivery via DRB and S1-U bearer by sending control plane service request with active flag for voice call data transmission, which can be used to differentiate priority of voice data from IMS signalling delivered via an SRB.

这个切换过程是如何实现的？

  1. 触发: UE决定需要切换到用户面（例如，当IMS应用通知底层“通话已接通”）。
  2. 信令: UE向MME发送一个 Control Plane Service Request 消息。
  3. 关键参数: 在这个请求消息中，UE会设置一个特殊的标志位 active flag for voice call data transmission。
  4. 网络响应:
    • MME收到这个带“激活标志”的请求后，就理解UE要将会话的数据路径切换到用户面。
    • MME会触发一个流程，指示eNB为这个UE建立一个DRB（数据无线承载），并将该承载与现有的默认EPS承载进行关联。
    • 同时，MME也会更新SGW，告知它后续该承载的数据将从S1-U接口（来自eNB）而不是S11-U接口（来自MME）过来。
  5. 完成切换: 一旦DRB建立完成，UE就可以将后续的RTP语音包，通过这个新的DRB发送出去。数据流路径就此从 UE->SRB->eNB->MME->SGW 变成了 UE->DRB->eNB->SGW。

Editor’s note: It is FFS whether or how to differentiate QoS/priority further between IMS signalling and voice data.

最后一个编辑注依然点出了一个难题：即使语音切换到了用户面，IMS信令（如通话中的UPDATE消息，或SIP keep-alive）依然可能停留在控制面。那么，当网络资源紧张时，如何协调这两条不同路径上的数据流的优先级？

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

Solution 7的改动是独特的，它引入了动态性。

  • UE:
    • 需要支持“双模”能力（CP和S1-U）的协商。
    • 需要具备在通话过程中，主动触发从CP切换到UP的逻辑和信令能力。
  • MME:
    • 需要能够处理UE的“切换”请求，并触发建立DRB和更新核心网用户面路径的流程。
  • eNB:
    • 需要在RRC连接状态下，为已经通过CP模式连接的UE，动态地建立一个DRB。
  • P-GW:
    • 影响相对较小，它只需要能够处理来自同一个EPS承载的数据流，前期从S11-U（经MME）过来，后期从S1-U（经SGW）过来的路径变化。

5. 结论：灵活的策略，隐藏的复杂性

Alex对Solution 7做出了最终的评价：“Solution 7是一个非常聪明的方案。它试图通过引入‘时间维度’上的动态切换，来化解‘空间维度’上的架构复杂性。它避免了永久性的复杂承载模型，而是提供了一种‘按需服务’的思路。”

“它的优点非常突出：”

  • “呼叫建立快： 初始阶段完全利用控制面，可以实现非常快速的信令交互和呼叫建立。”
  • “传输效率高： 在需要大流量传输的通话阶段，切换到用户面，可以使用ROHC等高效的用户面传输机制。”
  • “架构相对简洁： 它坚守了单默认承载模型，避免了引入专用承载带来的管理复杂性。”

“然而，这种灵活性背后，也隐藏着新的复杂性：”

  • “切换时延与信令开销： 从CP到UP的切换过程本身，需要一次额外的信令交互（Control Plane Service Request），并需要动态建立DRB。这个过程会引入一定的时延和信令开销。虽然发生在通话接通后，但可能会对通话初始阶段的语音质量产生影响（所谓的‘切后抖动’）。”
  • 状态不一致的风险： 网络需要在UE、eNB、MME和SGW之间，精确地同步数据路径的切换状态。任何一个环节出现状态不一致，都可能导致数据包丢失或路由错误。
  • QoS区分依然不完美： 方案依然没有完美解决信令（留在CP）和语音（切换到UP）之间的优先级协调问题。

“总而言之，Solution 7为我们提供了一种‘混合动力’的思路。它在‘纯电动’（纯CP）和‘纯燃油’（纯UP）之间，找到了一个可以智能切换的模式。这个方案是否优于其他方案，很大程度上取决于实际场景中，这个‘切换’动作本身带来的开销，是否小于它所节省的资源和带来的性能提升。”

FAQ

Q1：Solution 7的核心思想是什么？它与之前所有方案最大的不同点在哪里？ A1：Solution 7的核心思想是引入一种动态的数据路径切换机制。它在呼叫建立阶段使用控制面（CP）承载来传输所有数据以求快速，在通话保持阶段则可以切换到用户面（UP）承载来高效传输语音流。它与之前所有方案最大的不同在于动态性：之前的方案（无论是CP还是UP）一旦选定了数据路径，在整个通话过程中都是固定的；而Solution 7的路径是可变的，实现了在CP和UP两种模式之间的“变形”。

Q2：这种从控制面到用户面的“切换”是如何触发和实现的？ A2：切换是由UE主动触发的。当UE判断需要进入持续的大流量传输阶段时（如通话接通），它会向MME发送一个**Control Plane Service Request信令消息，并在这个消息中携带一个特殊的“激活标志 (active flag)”**。MME收到这个带标志的请求后，就会启动切换流程，包括指示eNB为UE建立一个DRB（数据无线承载），并更新SGW的用户面路径。一旦DRB建立完成，切换即告成功。

Q3：为什么说Solution 7回归了“单默认承载模型”？它和Solution 1有什么区别？ A3：说它回归了“单默认承载模型”，是因为在EPS承载管理层面，自始至终只存在一个逻辑上的默认EPS承载，没有建立额外的专用承载。这与Solution 2和6的双承载模型形成了对比。它和Solution 1的区别在于，虽然都是单默认承载，但Solution 1的承载物理路径是固定的（要么纯UP，要么纯CP，但本TR中的Solution 1是UP），而Solution 7的承载物理路径是动态可变的，可以在CP路径（通过SRB）和UP路径（通过DRB）之间切换。

Q4：方案中提到的UE需要协商支持“CP CIoT Optimisation”和“S1-U data transfer”，这两者是什么关系？ A4：这两者代表了UE需要具备的“双模”能力，是实现动态切换的前提。**“CP CIoT Optimisation”代表了UE具备通过控制面（经由MME）传输数据的能力。“S1-U data transfer”**则代表了UE具备通过标准用户面（经由S-GW的S1-U接口）传输数据的能力。UE必须同时声明支持这两种能力，网络侧（MME）才能理解这个UE是支持动态切换的，并为其启用Solution 7的相应逻辑。

Q5：Solution 7的“潮汐车道”模型有什么潜在的风险或缺点？ A5：主要有三个潜在风险：1) 切换开销： 切换过程本身需要信令交互和无线资源重建（建立DRB），这会引入额外的时延。虽然发生在通话接通后，但可能会造成通话开始几秒钟的语音质量波动或短暂中断。2) 系统复杂性： 引入动态状态切换，对UE、eNB和MME之间的状态同步要求极高，增加了系统的复杂性和潜在的出错风险。3) QoS协调难题： 切换后，IMS信令可能仍留在控制面，而语音在用户面。当网络拥塞时，如何在这两条异构路径之间进行有效的QoS仲裁和优先级管理，依然是一个悬而未决的问题。

关系图谱