好的，我们继续进行深度拆解。这是本系列的第十六篇文章，将深入剖析一个在协议栈层面进行大胆革新的方案——Solution #11。

深度解析 3GPP TR 23.700-19：6.11 Solution #11: 非IP传输与IP呈现

本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在我们探讨了多种从承载和PDN连接层面进行优化的方案之后，本文将带领我们再次聚焦于协议本身，深入解读 6.11 Solution #11。这个方案可以看作是Solution #3（NIDD语音传输）思想的一次极致升华和全面应用，它不仅要让语音“裸奔”，更要让信令也“脱掉IP的外套”，并通过P-GW的“协议魔法”，在IMS网络面前伪装成一个完全正常的IP终端。

引言：终极的“隐身术”

让我们回到Alex团队对Evelyn博士通信方案的持续优化中。Solution 3已经成功地为语音包“脱掉了IP/UDP外套”，极大地提升了空口效率。然而，团队里的网络协议专家王工提出了一个更深层次的问题：“我们只让‘货物’（语音）裸奔，但每次发货的‘订单’（SIP信令）还是用厚重的‘羊皮纸’（IP协议）写的。在NB-IoT这条‘羊肠小道’上，运送‘羊皮纸’的开销也不容忽视。我们能不能把‘订单’也简化成一张小纸条，到达‘物流中心’（P-GW）后，再由工作人员誊写成标准的‘羊皮纸’格式？”

这个想法，正是Solution 11的核心。它不再满足于只对媒体流进行NIDD优化，而是将优化的范围扩大到了IMS会话的全部流量，包括信令和媒体。它试图在UE和P-GW之间，构建一个纯粹的、与IP无关的“内部传输通道”，而在P-GW之外，一切看起来都和标准的IP世界别无二致。这是一种终极的“隐身术”和“协议代理”。

This solution addresses KI#1, in particular message size optimization. In this solution, for UL, UE sends Non-IP packets and P-GW adds IP header. For DL, P-GW receives IP packets, removes IP header, and sends Non-IP packets.

规范的原则描述，开宗明义地揭示了这种双向、全流量的“穿脱外套”机制。

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

本节的一句话原则，点明了方案的目标。

This solution addresses KI#1, in particular message size optimization.

• 目标: 解决基础的IMS语音支持问题，其特别关注点是消息尺寸的优化。这预示着方案的核心手段将是减少协议开销。

This solution is intended to be used together with another solution shown in “Support of CP/UP combination and QoS for IMS voice service over GEO satellite with a pair of PDN connections”.

这是一个非常重要的上下文。方案明确建议与Solution #10（双PDN连接方案）结合使用。这意味着，Solution 11并非一个独立的承载方案，而是一个可以应用在Solution 10架构之上的协议层增强方案。

组合后的图景是这样的：

1. 架构层面 (Solution #10): 存在两个PDN连接。一个是纯CP的信令PDN，另一个是纯UP的媒体PDN。
2. 协议层面 (Solution #11): 在这两个PDN连接之上，UE与P-GW之间传输的数据，都是Non-IP格式的。

2. 方案详述：6.11.1 Description - P-GW的“协议魔法”

本节通过三个核心原则，详细描述了P-GW是如何实现这种“协议魔法”的。

• For UL, UE sends Non-IP packets and P-GW adds IP header. For DL, P-GW receives IP packets, removes IP header, and sends Non-IP packets.

这是方案的灵魂，定义了P-GW作为“协议转换网关”的双向操作：

• 上行 (Uplink): UE发送的是“裸”的SIP信令包和RTP语音包（都没有IP/UDP头）。当这些包到达P-GW时，P-GW会像一个代理服务器，为它们“穿上”标准的IP/UDP头，然后将格式完整的IP包发往IMS网络（P-CSCF或AGW）。
• 下行 (Downlink): P-GW收到来自IMS网络的标准IP包（SIP或RTP）。在将它们发往UE之前，P-GW会“脱掉”它们的IP/UDP头，只将“裸”的荷载（SIP消息体或RTP荷载）通过Non-IP PDN发给UE。

• UE receives an IP address allocated to it from P-GW at establishment of the PDN connection for voice media and uses the IP address when creating contents of SDP messages.
• UE sends to P-GW an IP address allocated in IMS AGW, when the UE receives the IP address in SDP. P-GW uses this IP address when adding IP header to voice media packets.

这两条原则解决了“协议魔法”中最关键的一个问题：P-GW在凭空捏造IP头时，源/目的IP地址从何而来？

• UE如何知晓自己的IP地址？
  • 尽管UE实际发送的是Non-IP包，但在PDN连接建立时，P-GW依然会通过PCO（Protocol Configuration Options）等机制，“假装”分给UE一个IP地址。
  • UE会将这个“名义上”的IP地址，用于填写SIP信令中的关键字段，比如Contact头域，以及SDP中的c-line（连接地址）。这样，IMS网络收到的SIP消息在逻辑上就是完全合法的。
• P-GW如何知晓对端的IP地址？
  • 对于信令, P-GW被假设为预配置了P-CSCF的IP地址。
  • 对于媒体, UE在收到网络的SDP Answer后，会解析出其中媒体网关（AGW）的IP地址和端口。UE会将这个地址信息，通过某种**带外（out-of-band）或带内（in-band）**信令（方案未详述，但暗示需要新的信令交互）告知P-GW。P-GW收到后，就知道上行语音包的目的IP地址应该是这个AGW地址。

“看，” Alex兴奋地解释道，“这是一个完美的‘皮影戏’。UE和P-GW在幕后（UE-PGW之间）用‘小纸条’（Non-IP）高效沟通，但在台前（IMS网络看来），P-GW这个‘操纵者’却为UE这个‘皮影’伪造了所有标准的IP交互动作。IMS网络从始至终都以为自己正在和一个标准的IP终端对话。”

3. 流程剖析：6.11.2 Procedures - “隐身模式”下的通信

本节以与Solution 10的结合为背景，展示了在这种“隐身模式”下，PDN连接建立、IMS注册和呼叫建立的详细流程。

3.1 增强的PDN连接建立 (6.11.2.2)

规范的 “Figure 6.11.2.2-1: Establishment of PDN connection for SIP message exchange” 展示了一个增强版的PDN建立流程。相比Solution #10，它增加了新的信令元素：

• ePCO(CN header handling request):
  • 在UE发起的PDN Connectivity Request中，增加了一个新的扩展协议配置选项（ePCO），内容为**“请求核心网处理头部 (CN header handling request)”**。
  • 这个请求，就是UE明确告知P-GW：“接下来的通信，请开启‘协议魔法’模式，由你来负责IP头的添加和剥离。”
• ePCO(CN header handling accepted indication):
  • 如果P-GW支持并同意开启此模式，它会在响应消息中，同样通过ePCO返回一个**“接受核心网处理头部指示”**。
• PDN Address Allocation(IP address):
  • P-GW在响应中，会为这个即将进行Non-IP传输的PDN连接，分配一个“名义上”的IP地址，并通过标准的PDN Address Allocation参数下发给UE。

3.2 “无头”的IMS注册 (6.11.2.3)

规范的 “Figure 6.11.2.3-1: IMS registration” 展示了一个非IP传输下的IMS注册流程：

1. UE → MME → PGW: UE发送不带IP/UDP头的SIP REGISTER消息体。
2. P-GW (魔法发生): P-GW收到后，执行“穿外套”操作。它使用在PDN建立时分配给UE的IP地址作为源IP，使用预配置的P-CSCF地址作为目的IP，添加上标准的UDP头，构造出一个完整的IP包。
3. PGW → P-CSCF → … → S-CSCF: 标准的IMS注册流程。
4. S-CSCF → … → PGW: IMS核心网返回200 OK响应，这是一个标准的IP包。
5. P-GW (再次施法): P-GW收到200 OK，执行“脱外套”操作，剥离其IP/UDP头。
6. PGW → MME → UE: 只将SIP 200 OK的消息体通过Non-IP PDN发送给UE。

3.3 “无头”的IMS呼叫 (6.11.2.4)

呼叫流程与注册流程类似，所有UE与P-GW之间的信令和媒体包，都在空口上以“无头”的Non-IP形式传输，由P-GW在网络边缘进行双向的、实时的协议转换。

NOTE: Steps 13 to 18 in the below for establishing a PDN connection for voice media can be performed only after UE receives SDP answer (in MO side).

这个注释指出了与Solution 10结合时的流程时序：UE必须先在信令PDN上，通过SIP信令交互收到包含媒体网关地址的SDP Answer之后，才能知道该如何与P-GW协商媒体PDN的对端地址，并最终建立媒体PDN。

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

Solution 11的改动是高度集中但极其深刻的。

• UE:
  • 核心改动: 需要支持在发起PDN连接时协商“CN header handling”能力。需要能够将“名义上”的IP地址用于构造SIP/SDP消息体，但在实际发送时，却要剥离IP/UDP头，发送Non-IP包。这要求IMS协议栈与底层传输协议栈之间有深度的协同。
• P-GW (改动最大):
  • 核心改动: 必须成为一个功能强大的协议转换网关（Protocol Translation Gateway）。它需要具备：
    • 支持“CN header handling”能力的协商。
    • 为Non-IP会话分配和管理“名义上”的IP地址。
    • 实时的、双向的IP/UDP头部添加和剥离能力。
    • 管理和使用对端地址（P-CSCF, AGW）的上下文信息。
• MME, SGW, PCRF:
  • 需要透明传输新的ePCO参数。
• IMS Network:
  • 无影响。 整个IMS核心网都被P-GW的“魔法”所“欺骗”，完全感觉不到任何异常。

5. 结论：极致效率的“代理”，系统复杂性的权衡

Alex最后对Solution 11进行了高度概括：“Solution 11将P-GW的角色从一个‘网关’，彻底提升为了一个‘智能代理’。它通过在网络边缘引入一个强大的协议转换层，实现了UE侧在空口上的‘终极隐身’，将协议开销降到了物理极限。”

“它的优点是极致的效率和完美的兼容性：”

• “最大化的带宽节省： 通过对信令和媒体流的同时优化，它在理论上提供了最高的空口频谱效率。”
• “对IMS核心网零冲击： P-GW的‘代理’行为，使得所有卫星接入的复杂性都被完美地封装和隐藏了起来，对存量IMS网络的兼容性无与伦比。”

“然而，这种极致的效率，也带来了对P-GW功能的极高要求和新的复杂性：”

• “P-GW的重度增强： P-GW不再是一个简单的GTP隧道端点和路由器，它需要变成一个有状态、需要处理七层信令内容（解析SDP以获取AGW地址）的复杂应用层网关。这对P-GW的设计、性能和可扩展性都提出了巨大的挑战。”
• “引入新的信令交互： UE需要有一种机制将从SDP中获取的AGW地址告知P-GW，这引入了额外的UE-PGW之间的信令交互，增加了系统的复杂性。”

“总而言之，Solution 11和Solution 3共同开创了‘NIDD + 边缘转换’这一技术流派。Solution 3是‘小试牛刀’，只优化了媒体；而Solution 11则是‘火力全开’，将信令也纳入了优化的范畴。这个方案是否会被采纳，取决于业界对于‘将复杂性推向网络边缘’这一设计哲学的接受程度，以及P-GW设备制造商实现如此复杂的协议代理功能的意愿和成本。”

---

FAQ

Q1：Solution 11的核心思想是什么？它和Solution #3（NIDD语音）的本质区别是什么？ A1：Solution 11的核心思想是将UE与P-GW之间的所有IMS相关流量（包括信令和媒体）都进行非IP（Non-IP）化传输，并由P-GW作为代理完成与IP世界的协议转换。它与Solution 3的本质区别在于优化的范围：Solution 3只对语音媒体流进行Non-IP传输，而IMS信令依然走标准的IP路径；Solution 11则将优化范围扩大到了信令和媒体的全部流量，是一个更彻底的协议开销优化方案。

Q2：UE在发送Non-IP包，但IMS网络却认为它有IP地址，这是如何实现的？ A2：通过P-GW的“欺骗”和UE的“配合”。在PDN连接建立时，P-GW会分配一个IP地址给UE，但这只是一个“名义上”的地址。UE会 dutifully 地将这个地址填写在所有需要IP地址的SIP和SDP字段中。然而，当UE实际发送数据包时，它的底层协议栈会“知道”这是一个需要进行头部处理的特殊连接，因此会剥离IP/UDP头，只发送裸荷载。P-GW收到裸荷载后，会利用它之前分配给UE的那个“名义上”的IP地址作为源地址，构造出完整的IP包再发往IMS网络。

Q3：P-GW是如何知道上行数据包的目的IP地址的？ A3：分两种情况：1) 对于SIP信令，其目的地是P-CSCF。方案假设P-GW可以通过配置（Configuration）的方式，预先知道自己应该将SIP信令转发到哪个P-CSCF的IP地址。2) 对于RTP媒体，其目的地是媒体网关（AGW）。这个地址是在SIP信令的SDP协商过程中动态确定的。UE在收到包含AGW地址的SDP后，需要通过一种新的信令机制（方案未详述）将这个地址告知P-GW。P-GW收到后，就将其作为后续上行RTP包的目的地址。

Q4：为什么这个方案建议与Solution #10（双PDN连接）结合使用？ A4：因为两者的优化点是正交且互补的。Solution #10在承载/PDN架构层面解决了QoS分离的问题，通过CP和UP两个独立的PDN连接，为信令和媒体提供了隔离的通道。而Solution #11则在协议层面解决了协议开销的问题。将两者结合，就可以构建一个既有清晰QoS分离、又能实现极致空口效率的“理想”系统：信令走纯CP的Non-IP PDN，媒体走纯UP的Non-IP PDN。

Q5：这个方案最大的实现难点和风险在哪里？ A5：最大的实现难点在于对P-GW的功能和性能要求极高。P-GW不再是一个简单的三/四层网元，它需要具备七层应用感知能力（如解析SDP），需要维护复杂的状态（如对端地址上下文），还需要进行高吞吐量的实时协议封装/解封装。这大大增加了P-GW的实现复杂度和处理时延。风险在于，如此复杂的P-GW可能会成为网络的性能瓶颈和单点故障源，并且其专有实现可能导致不同厂商设备间的互通性问题。