51学通信

深度解析 3GPP TR 23.700-19：6.3 Solution #3 NIDD voice transfer in IP Type IMS PDN (IP类型PDN下的NIDD语音传输)_x0...

22分钟阅读

好的，我们继续进行深度拆解。这是本系列的第八篇文章，将深入剖S 析剑走偏锋但极具创新性的Solution #3。

深度解析 3GPP TR 23.700-19：6.3 Solution #3: NIDD voice transfer in IP Type IMS PDN (IP类型PDN下的NIDD语音传输)

本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在我们已经剖析了两种相对常规的用户面方案之后，本文将带领大家进入一个更具颠覆性的领域。我们将深入探讨 6.3 Solution #3，这是一个极其精巧且高效的方案，它首次将 NIDD (Non-IP Data Delivery, 非IP数据交付) 的思想引入到了IP类型的IMS PDN连接中，试图在保证与标准IMS网络兼容的同时，将空口的协议开销压缩到极致。

引言：为语音包“脱下厚重的外套”

让我们再次回到科学家Evelyn博士的科考站。通过前两个方案的学习，Alex的团队已经为Evelyn博士的“地理链接一号”规划了独立的“快车道”（专用承载）来传输语音。然而，一个新的问题摆在了他们面前：即便是行驶在快车道上，每一辆运送语音的“卡车”（数据包）自身也过于笨重。

一个典型的RTP语音包，其“货物”（语音净荷）可能只有区区20-30字节，但其“车头和车身”（IP/UDP/RTP协议头）却长达40-60字节。在GEO NB-IoT这条每克“燃料”（带宽）都极其珍贵的链路上，这意味着超过一半的能量都消耗在了运送“车皮”本身，效率极其低下。

“我们需要一场‘物流革命’，” Alex在技术研讨会上提出了新的挑战，“我们能不能让货物在最关键的运输段（空口）‘裸奔’？只运送货物本身，到达目的地（核心网）后再给它套上标准的外包装（协议头）。这就是Solution 3的核心思想——为语音包脱下厚重的IP/UDP/RTP外套。”

Solution 3因此成为第一个正面应对“协议开销”这一核心痛点的方案，它在Solution 2的双承载模型基础上，进行了一次大胆的“偷天换日”。

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

本节用几条原则，揭示了Solution 3的革命性设计。

This solution is to address Key Issue #1. This solution uses a single IMS APN PDN connection with two EPS bearers. The IMS PDN is IP type … In order to reduce the header overhead to the most extreme level:

  • it is proposed to transmit the IMS voice traffic as non-IP (NIDD) traffic over dedicated EPS bearer; and
  • the PGW will translate the NIDD voice packets to IP/UDP/RTP packets before forwarding them to the IMS entity…

Alex为团队逐一解读这些原则的深刻含义：

  1. “使用一个拥有两个EPS承载的单一IMS APN PDN连接，该PDN连接是IP类型的。”

    • 双承载模型: 这表明Solution 3继承了Solution 2的“分道行驶”思想，依然使用默认承载传输信令，专用承载传输语音。
    • IP类型PDN: 这是本方案最精妙、也最容易混淆的地方。尽管我们要在专用承载上传输“非IP”的语音，但整个PDN连接的“户口本”上，写的依然是“IP类型”。这意味着，这个PDN连接对IMS核心网而言，看起来完全是一个标准的、分配了IP地址的连接。这极大地降低了对IMS核心网的改动要求。

  2. “为了将头部开销降低到极致…” 这明确了本方案的核心动机——极致的效率。

  3. “建议在专用EPS承载上，将IMS语音流量作为non-IP (NIDD)流量传输。”

    • 这就是“脱外套”的具体操作。当UE发送RTP语音包时，不再为其添加IP/UDP头部，可能只保留一个极简的RTP头（例如，只保留序列号），甚至完全是裸的语音净荷。这些“半裸”的数据包，将被发送到专用的EPS承载上。

  4. “P-GW将在转发语音包到IMS实体之前，将其从NIDD包翻译成IP/UDP/RTP包。”

    • 这就是“穿外套”的操作。P-GW作为核心网的边缘节点，扮演了“协议转换器”的角色。当它从专用承载上收到来自UE的NIDD语音包后，它会负责为其重新封装上标准的IP/UDP/RTP头部，然后将一个看起来完全正常的RTP包转发给媒体网关（AGW）。

Alex总结道：“Solution 3的 genius 之处在于，它实现了一次巧妙的‘欺骗’。它对空口进行了极致的优化（NIDD），但通过在P-GW侧进行协议转换，使得这次优化对远端的IMS核心网完全透明。IMS网络完全不知道自己正在和-一个‘衣不蔽体’的UE通话，因为它看到的只是P-GW送来的一个个‘衣冠楚楚’的标准数据包。”

2. 方案详述与架构图景：6.3.1 Description

本节的 “Figure 6.3.1-1: IP Type IMS PDN connection over User Plane with NIDD voice transfer between UE and PGW” 直观地展示了这一过程。

  • IMS信令 (IMS Signalling): 依然走默认承载，使用标准的IP协议栈。
  • IMS语音 (IMS voice): 在专用承Gitlab上，路径被清晰地分为两段：
    1. UE ←> PGW 段: 语音包以NIDD的形式传输，图中表示为 Voice/RTP-SN，意味着可能只保留了RTP序列号（Sequence Number）这样的最基本信息。
    2. PGW ←> IMS DN 段: P-GW完成协议转换后，语音包以标准的 Voice/RTP/UDP/IP 格式在核心网内部及IMS域中传输。

NOTE 1 Assuming data rate is 1Kbps and voice codec rate is 0.7Kbps, then there is only 0.3Kbps remaining for voice packet “header” overhead… each voice packet can only tolerate maximum 3 Bytes header size…

这个注释极其生动地量化了协议开销问题的严重性。假设总带宽1kbps，语音编码占用0.7kbps，那么留给所有协议头（从RRC/MAC到RTP/UDP/IP）的总开销只剩下0.3kbps。如果每秒发12.5个包（ptime=80ms），则每个包的头部大小不能超过 300 bits / 12.5 = 24 bits，也就是3个字节！而一个标准的IPv4/UDP/RTP头就有 20+8+12 = 40 字节。常规路径根本走不通，这为NIDD的引入提供了无可辩驳的理由。

Editor’s note: In the context of using “Non-IP” voice packet transfer, only one call or more than one call needs to be supported is FFS based on SA WG1 discussion.

这个编辑注则提出了一个开放性问题：这种NIDD传输，是只设计为支持一路通话，还是需要考虑支持多路通话（如电话会议）？这会影响到NIDD包的格式设计（例如，是否需要一个标识来区分不同的通话流）。

3. 流程剖析：6.3.2 Procedures - “变身”的实现细节

要实现这种巧妙的“变身”，UE和P-GW都需要学习新的技能。

3.1 连接的建立与协商 (6.3.2.1)

…the UE supports the this feature indicates support of “IP and non-IP Hybrid Transfer” in UE network capability in Attach request, and the MME … indicates to accept to use it…

这个过程需要在附着时，UE和MME之间进行一次新的能力协商。UE需要声明自己支持“IP与非IP混合传输”这种高级能力。MME在确认网络也支持后，予以同意。这个协商是后续P-GW启用NIDD转换功能的前提。

…during Dedicated EPS bearer context activation procedure the network indicates, for a dedicated bearer to be activated for voice, the traffic type to be sent over the bearer is non-IP traffic.

当为语音建立专用承载时，网络会在承载激活消息中，明确指示这个承载的“交通规则”是 non-IP。这就告诉UE：“在这条路上，请‘脱掉外套’再发货。”

3.2 NIDD语音传输 (6.3.2.2)

3.2.1 上行传输 (UE → PGW)

  • UE侧的挑战：TFT的识别 (6.3.2.2.1.1) 标准的TFT是基于IP五元组来工作的。既然我们要发送非IP包，UE如何知道要把这些包映射到这个专用的NIDD承载上呢？

    …a new Packet filter component type identifier may be introduced, e.g. “(IMS) voice traffic type”, to indicate the UE to steer NIDD voice traffic to the dedicated EPS bearer context.

    方案提出，需要引入一种新的TFT过滤器类型，它不再是识别IP地址或端口，而是直接识别“流量类型”，例如，一个专门的 (IMS) voice traffic type。当UE的IMS应用生成一个语音包时，底层协议栈会识别出这个包的“类型”，然后根据这个新的TFT规则，将其发送到NIDD专用承载上。

  • P-GW侧的挑战：协议的重建 (6.3.2.2.1.2) 当P-GW从NIDD承载上收到一个“裸奔”的语音包时，它如何为其“穿上”正确的IP/UDP/RTP外套呢？

    …the PGW also builds and stores the context (e.g. IP(es) and Port(s)), based on information received from PCRF, in order to perform the conversion…

    答案在于上下文的存储。在SIP信令交互过程中，P-CSCF会通过PCRF，将协商好的媒体流信息（如对端的IP地址、端口，编解码器类型等）告知P-GW。P-GW会将这些信息（我们称之为“转换上下文”）与这个NIDD承载进行绑定。当一个NIDD包到达时，P-GW就利用这个上下文，为其构建出完整的IP/UDP/RTP头部，然后发往IMS网络。

3.2.2 下行传输 (PGW → UE)

For the downlink voice packet, the PGW may still leverage the current DL TFT as usual, but for DL traffic steered to the NIDD dedicated EPS bearer the PGW converts the DL Voice over RTP/UDP/IP packets to Voice with RTP info…

下行过程是上行的逆操作。

  1. P-GW通过标准的下行TFT，识别出从IMS网络发往UE的RTP语音包。
  2. 在将这个包转发到NIDD专用承载之前，P-GW执行“脱外套”操作，剥离其IP/UDP/RTP头部，可能只保留一个1字节的RTP序列号。
  3. 这个“裸奔”的包通过NIDD承载发送给UE。

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

Solution 3的改动是精准而深刻的，主要集中在UE和P-GW。

  • UE:

    • 需要支持“IP and non-IP Hybrid Transfer”能力协商。
    • 需要支持新的TFT过滤器类型，以识别并路由NIDD语音流量。
    • IMS应用层以上基本无影响，但底层的传输协议栈需要进行改造，以支持在发送语音时剥离IP/UDP头。

  • MME:

    • 需要支持新的能力协商，并在承载建立时向UE指示承载的 non-IP 属性。

  • RAN (eNB):

    • 需要支持NIDD类型的承载。这可能涉及到对PDCP层配置的修改（例如，是否启用ROHC）。

  • PGW (改动最大):

    • 需要支持“IP and non-IP Hybrid Transfer”PDN连接。
    • 核心功能：必须具备NIDD与IP/UDP/RTP之间的双向协议转换能力。
    • 需要能够存储和管理与NIDD承载绑定的“转换上下文”。

  • IMS Network:

    • 几乎没有影响 (None)。 这正是该方案设计的最大亮点。

5. 结论：优雅的“障眼法”，高效的传输方案

Alex最后总结道：“Solution 3是目前我们看到的、在技术上最为优雅和高效的方案之一。它像一位高明的魔术师，通过一个巧妙的‘障眼法’——IP类型的PDN连接，成功地将NIDD这种极致的空口优化技术，无缝地融入到了标准的IMS体系中。”

“它的优点是显而易见的：极低的协议开销，最大限度地节省了宝贵的卫星带宽，从而可能在极端的网络条件下，提供更稳定、更可靠的语音质量。同时，它对IMS核心网的冲击几乎为零，具有极佳的向后兼容性。”

“然而，它的缺点也同样突出：对P-GW和UE的改动较大。P-GW不再是一个简单的路由器，而变成了一个需要维护状态、进行协议转换的复杂网元。UE的底层协议栈也需要进行深度定制。这些改动，都带来了额外的实现复杂度和成本。”

“总而言之，Solution 3为我们提供了一种‘用边缘的复杂性，换取端到端的简洁性和空口的极致效率’的设计思路。它是否是最佳方案，还需要与后续的其他方案，特别是那些同样极具创新性的控制面方案，进行全面的比较和权衡。”

FAQ

Q1：Solution 3的核心创新点是什么？它与之前方案的最大区别在哪里？ A1：核心创新点是在IP类型的IMS PDN连接中，为语音流量引入了NIDD（非IP数据交付）传输机制。它与之前方案的最大区别在于，Solution 1和2都依然在空口传输标准的IP数据包，只是在承载管理上做文章；而Solution 3则从根本上改变了语音数据包在空口的“形态”，通过剥离IP/UDP头部，将协议开销降至最低，实现了空口传输效率的飞跃。

Q2：为什么方案强调PDN连接是“IP类型”，但这又有什么好处？ A2：这是一个非常精巧的设计。将PDN连接类型设置为“IP”，意味着在核心网看来，这个连接是完全正常的。UE会被分配一个IP地址，P-GW会向IMS网络通告这个IP地址。这使得整个IMS核心网（P-CSCF, S-CSCF等）可以完全按照标准流程来处理这个用户的IMS注册和会话。好处是对IMS核心网完全透明，无需任何改动，极大地降低了方案的部署难度和对现有网络的影响。NIDD的“魔法”被完全限制在了UE和P-GW之间。

Q3：P-GW是如何知道该如何为“裸奔”的NIDD语音包“穿上”正确的外套（IP/UDP/RTP头）的？ A3：通过存储和利用“转换上下文”。在IMS呼叫建立的SIP信令交互过程中，包含了SDP协商，其中确定了媒体流的所有参数，如对端（媒体网关）的IP地址和端口、编解码器类型、RTP荷载类型等。这些信息会通过IMS核心网，经由PCRF传递给P-GW。P-GW会将这些关键信息（即“转换上下文”）缓存起来，并与承载语音的那个专用NIDD承载进行绑定。当一个NIDD语音包从该承载到达P-GW时，P-GW就取出对应的上下文，利用其中的IP地址、端口等信息，为其构建出完整、正确的IP/UDP/RTP头部。

Q4：既然NIDD这么高效，为什么不把IMS信令也用NIDD传输？ A4：这是一个很好的问题。理论上是可行的，但可能得不偿失。原因有几点：1) 复杂性： IMS信令（SIP）的交互逻辑比单向的RTP流复杂得多，它需要与网络中多个不同的实体（P-CSCF, S-CSCF, AS等）通信，每个实体的IP地址和端口都可能不同。在P-GW侧为所有这些信令流维护和转换上下文，将极其复杂。2) 开销占比： 信令虽然消息大，但属于偶发流量；而语音是持续性流量。在整个通话过程中，语音包的总开销远大于信令。因此，对语音流进行NIDD优化的“性价比”最高。3) 可靠性： SIP信令通常需要更可靠的传输，而NIDD的底层传输机制可能与IP的路由和重传机制有所不同，需要额外的机制来保证信令的可靠交付。因此，Solution 3采用了务实的策略：让信令走标准IP路径以保证兼容性和可靠性，让语音走NIDD路径以追求极致效率。

Q5：这个方案对终端（UE）的改动主要在哪一层？是APP层还是底层？ A5：改动主要在底层协议栈，对上层的IMS应用（如拨号器APP）应该是透明的。具体来说，当IMS应用层生成一个语音净荷并交给底层协议栈发送时，协议栈需要有一个新的逻辑：它会判断这个包是语音包，并且知道要通过一个被网络指定为non-IP的专用承载来发送。因此，它会跳过构建IP/UDP头的步骤，可能只添加一个极简的RTP头或不添加，然后将这个NIDD包交给更底层的PDCP/RLC层去传输。这个过程需要对UE的通信模组固件进行修改。

关系图谱