当前位置： 首页 > news >正文

【卫星通信】3GPP标准提案：面向NB-IoT（GEO）场景的IMS信令优化方案-降低卫星通信场景下的语音呼叫建立时延

news 2025/6/15 7:35:39

在这里插入图片描述

一、引言

随着5G非地面网络（NTN）技术的演进，基于NB-IoT的卫星通信（如GEO地球同步轨道卫星）逐渐成为偏远地区语音服务的重要补充。然而，传统IP多媒体子系统（IMS）的信令流程在带宽受限、时延较高的卫星链路中面临显著挑战。2025年5月，vivo、MediaTek、ZTE、OPPO等厂商联合向3GPP SA WG2提交提案（S2-2504682），针对NB-IoT（GEO）场景提出IMS信令优化方案，旨在通过减少SIP协议消息数量与负载大小，显著降低语音呼叫建立时延。本文基于提案内容，系统性解析其技术原理与实现路径。

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

二、问题背景：卫星通信场景下的IMS信令瓶颈

在NB-IoT（GEO）语音通信场景中，呼叫建立时延的主要来源为SIP协议的多轮次信令交互。典型流程需完成8次消息交换（INVITE→100 Trying→183 Progressing→PRACK→200 OK→UPDATE→200 OK→180 Ringing），累计数据量约10KB。这一流程在带宽受限的NB-IoT网络中导致以下问题：

  1. 高时延累积：GEO卫星链路的传播时延（约250ms单向）与多轮次信令交互叠加，显著延长呼叫建立时间。
  2. 带宽资源浪费：冗余信令字段（如重复的To头域、注册信息）与预条件协商机制（RFC 4032）增加了不必要的数据传输量。
  3. QoS保障不足：传统QCI（QoS Class Identifier）机制未针对卫星信道特性优化，导致资源分配效率低下。

提案明确指出，需通过协议层优化与流程重构，实现“轻量化信令交互”与“带宽高效利用”的双重目标。

三、解决方案：双路径优化策略

提案提出两项核心优化方案，分别针对信令交互次数与消息负载大小，具体如下：

3.1. 禁用预条件机制（Precondition Disabling）

技术原理：
预条件机制（RFC 4032）要求SIP会话在建立前完成媒体质量协商（如带宽、编解码器），需额外引入PRACK与UPDATE消息。在NB-IoT（GEO）场景中，该机制因链路稳定性差与资源分配动态性而失效。
优化措施：

  • 移除预条件协商流程：在P-CSCF（代理呼叫会话控制功能）与IMS应用服务器（IMS AS）间禁用预条件功能，直接进入会话建立阶段。
  • 动态资源分配触发：通过PCRF（策略与计费规则功能）实时监控EPS承载状态，当语音资源就绪时，由P-CSCF发送SIP MESSAGE通知IMS AS（见Figure 6.X.3.4-1）。

效果验证：
禁用预条件后，信令交互次数从8次减少至5次（INVITE→100 Trying→183 Progressing→200 OK→180 Ringing），累计数据量降低约30%。

3.2. SIP消息负载优化

技术原理：
SIP消息中存在大量冗余字段（如重复的To头域、注册信息）与低效编码（如SDP会话描述协议的冗长格式）。
优化措施：

  • 字段精简：
    • 在INVITE请求中，省略Request-URI中已包含的To头域信息（示例见Figure 6.X.3.2-1）。
    • 移除注册流程中已提供的用户能力信息（如编解码器支持列表）。
  • SDP压缩：
    • 采用SigComp协议（RFC 5049）对SDP内容进行压缩，将媒体描述字段（如m=audio、a=rtpmap）编码为紧凑二进制格式。
    • 针对GEO场景优化编解码器选择，仅携带低带宽适配的编解码器（如G.711 PCMU/8k）。

效果验证：
优化后，单个SIP INVITE消息负载从120字节降至约70字节，SDP压缩率超过40%。

四、技术实现：流程重构与协议适配

提案通过两阶段流程重构实现优化方案，具体如下：

阶段一：服务请求与EPS承载激活

  1. UE状态迁移：

    • 终端从RRC-IDLE状态发起Service Request，过渡至RRC-CONNECTED状态。
    • 若接入类型为NB-IoT（GEO），核心网在Service Request过程中激活语音专用EPS承载。

  2. SIP INVITE优化：

    • 终端发送SIP INVITE时，仅携带GEO语音适配的编解码器列表（如m=audio 49155 RTP/AVP 0 8）。
    • P-CSCF作为B2BUA（Back-to-Back User Agent）终止信令，根据接入网络信息添加必要扩展头域（如Supported: 100rel）。

阶段二：会话建立与资源协调

  1. IMS AS介入：

    • IMS AS作为B2BUA发起与被叫方的会话交互，通过PCRF动态监控EPS承载资源状态。
    • 当语音资源就绪时，P-CSCF发送SIP MESSAGE通知IMS AS（消息体包含AGW分配的IP地址与端口）。

  2. 媒体路径优化：

    • 媒体会话通过NIDD（Non-IP Data Delivery）用户面传输，避免IP头开销。
    • MGW（媒体网关）根据编解码器能力协商结果，执行转码或直接转发RTP流。

五、会话过程的技术细节扩展

提案对NB-IoT（GEO）场景下的IMS信令流程进行了系统性细化，涵盖主叫（MO）流程、被叫（MT）流程及紧急呼叫流程，并针对不同网元角色（如P-CSCF、IMS AS）的职责分工进行了规范。

5.1. “P-CSCF模式”** 与 “IMS AS模式”

在NB-IoT（GEO）卫星通信场景中， “P-CSCF模式” 与 “IMS AS模式”是针对移动主叫语音呼叫的两种优化流程。尽管二者均旨在降低信令开销并适配高时延、低带宽的卫星环境，但在关键实现细节和功能分工上存在显著差异。以下是核心区别的详细对比：

5.1.1. B2BUA角色的分工差异
特性P-CSCF模式IMS AS模式
B2BUA角色归属P-CSCF（代理呼叫会话控制功能）作为B2BUAIMS AS（IMS应用服务器）作为B2BUA
功能职责P-CSCF同时终止主叫与被叫侧的SIP信令，负责媒体协商、资源分配和EPS承载触发IMS AS接管B2BUA功能，P-CSCF仅作为透明转发节点，负责信令路由
适用场景适用于EPS承载无法预激活的简化流程适用于需动态资源协调的复杂场景（如跨网络域交互）

核心区别：

  • 在P-CSCF模式中，P-CSCF直接参与媒体路径控制（如SDP协商、资源分配），并通过触发EPS承载激活（如TFT配置）完成本地资源管理。
  • 在IMS AS模式中，P-CSCF仅作为信令中继，由IMS AS承担B2BUA功能，负责协调终端侧（GEO卫星）与网络侧（IMS核心网或第三方网络）的资源分配与媒体协商。
5.1.2. EPS承载激活时序差异
特性P-CSCF模式IMS AS模式
激活流程触发点P-CSCF在步骤5直接触发EPS承载激活EPS承载激活延迟至步骤5（由IMS AS控制），并与PCRF通知联动
资源分配逻辑AGW（接入网关）根据P-CSCF指令进行本地资源预配置IMS AS根据PCRF状态通知动态触发资源分配，灵活性更强
信令交互次数5轮次（INVITE→100→183→200→180）5轮次（与P-CSCF模式相同，但新增SIP MESSAGE交互）

核心区别：

  • P-CSCF模式通过步骤3和步骤5的AGW预配置和EPS激活并行化，减少了信令延迟。
  • IMS AS模式增加了访问PCRF精确状态通知的“SIP MESSAGE”步骤（步骤9），实现动态资源调控，但可能导致轻微时延增加。
5.1.3. SIP消息头部与媒体描述优化差异
特性P-CSCF模式IMS AS模式
SDP优化禁用预条件机制，SDP仅涉及GEO适配编解码器SDP进一步简化，禁用RFC 4032预条件头域（如precondition）
冗余字段精简INVITE中省略To头域与注册冗余信息IMS AS发起的新INVITE进一步移除冗余能力字段（如重复的Contact头域）
扩展头域支持P-CSCF添加Supported: 100rel以兼容旧终端IMS AS根据网络侧要求添加扩展头域（如MediaProxy）

核心区别：

  • P-CSCF模式侧重于终端侧与核心网之间的精简交互，通过本地资源分配优化单跳路径性能。
  • IMS AS模式通过增加IMS AS的决策层，能够跨网络域适配不同接入技术（如卫星与地面用户域），编解码器和媒体参数协商更灵活。
5.1.4. QoS保障与资源协调策略
特性P-CSCF模式IMS AS模式
QoS机制使用静态QCI（如QCI=1）保障语音优先级动态QCI调整，通过GQ-C（策略与计费控制）实时优化
承载资源触发步骤5中由P-CSCF直接通过TFT配置激活EPS承载步骤5中由IMS AS在PCRF通知后触发承载激活（更准确）
媒体网关(MGW)参与AGW单点控制，音频路径直接透传IMS AS协调MGW进行转码或资源优化（如CAPEX降低）

核心区别：

  • P-CSCF模式适用于简单的QoS场景，以降低网络复杂性为目标。
  • IMS AS模式通过PCRF联动与多级协调，支撑更复杂的QoS策略（如带宽弹性分配）和跨域媒体处理（如G.711→AMR转码）。
5.1.5. 紧急呼叫与用户隐私特性
特性P-CSCF模式IMS AS模式
紧急呼叫SCC-AS直接处理匿名紧急呼叫，P-CSCF路由至PSAPIMS AS接管紧急呼叫，支持MSD（最小紧急数据集透传）
隐私保护P-CSCF保留用户位置信息，不透传至核心网IMS AS启用隐私扩展（如privacy: id），隐藏用户身份与设备详情
地理位置上报通过AGW定位GEO终端坐标IMS AS融合GPS与NG-RAN定位信息，精度更高

核心区别：

  • P-CSCF模式以快速路由为目标，优先保障紧急呼叫可达性。
  • IMS AS模式通过IMS AS的中央控制，实现更细粒度的隐私保护机制与多源位置聚合。
5.1.6. 典型场景用例对比
场景P-CSCF模式适用情况IMS AS模式适用情况
孤网卫星通信终端与核心网间仅通过单跳GEO链路连接，适合快速建立语音通道终端需漫游至其他网络（如地面LTE/5G），需跨域协商
低成本终端2G/3G IoT节点通过NB-IoT接入，要求低处理负荷智能穿戴设备通过多网融合（Satellite + WiFi）接入
应急搜救场景灾难现场快速部署，音频流直接透传至救援中心灾难区域同时上报MSD、视频流与传感器数据
5.1.7. 选择建议

  • 选择P-CSCF模式：
    若网络架构简单（如单运营商单制式网络）、QoS策略固定且终端能力受限，P-CSCF模式可快速部署并保证基础语音服务。适用于资源紧张的GEO卫星场景。

  • 选择IMS AS模式：
    若需支持跨网域交互（如国际漫游）、动态QoS调整或高级媒体处理（如转码、隐私保护），IMS AS模式更灵活且可扩展性更强，但会增加网络部署复杂度。

两种模式的技术路径均符合3GPP Rel-20标准提案要求，并可根据实际部署场景混合使用。

5.2 IMS注册流程（Registration）

NB-IoT（地球同步轨道卫星，GEO）场景下用户设备（UE）向 IMS 网络发起的注册过程。
该流程通过以下关键技术优化了注册效率：

  1. 信令数据压缩：利用 SigComp 协议压缩 SIP 消息负载，减少卫星链路带宽占用；
  2. 冗余字段精简：省略 SIP 消息中重复的 To 头域信息；
  3. 接入网络信息透传：通过 P-Access-Network-Info（PANI）字段传递 NB-IoT(GEO) 的网络属性；
  4. 安全性保障：基于 IPSec 的加密传输与基于 Digest 的鉴权机制。
    IMS注册过程
步骤1：UE 发起初始 REGISTER 请求

场景条件：终端检测到当前接入技术为 NB-IoT（GEO）。
核心操作：

  • 信令压缩：在 INVITE 消息中通过 comp=sigcomp 指示 SigComp 协议启用，并携带 sigcomp-id 作为标识。
  • 头域优化：
    • Request-URI 包含完整的 URI（如 tel:+8613512345678），而 To 头域仅提供简略标识 A，避免冗余。
    • From 头域与 Contact 头域中省略在注册流程中已隐含的 URI 信息。

P-CSCF 行为：

  • To 头域恢复：将 sip:A 替换为 tel:+8613512345678，对齐 Request-URI。
  • SigComp 处理：通过内置解压器还原 SigComp 压缩的 SIP 消息。
步骤2：IMS 核心网发起鉴权挑战

核心操作：

  • 401 Unauthenticated 响应：IMS 核心网返回要求鉴权的 SIP 响应消息，包含 WWW-Authenticate 头域。

P-CSCF 行为：

  • SigComp 启用通知：在 Via 头域中添加支持 SigComp 的标识，确保 UE 在后续消息中继续使用压缩。
步骤3：UE 发送带有鉴权信息的 REGISTER 请求

核心优化：

  • 鉴权参数完整化：在 Authorization 头域中填写 nonce 与 response，完成 Digest 鉴权。
  • PANI 头域透传：
    • 标识接入网络为 3GPP-NB-IoT(GEO)；
    • 携带 utran-cell-id-3gpp=C359A 用于后续 QoS 策略决策。
  • 安全传输保障：SIP 消息通过 IPSec 加密传输。

P-CSCF 行为：

  • 信息存储：
    • 保存 Via、From、Contact 头域用于后续会话路径维护；
    • 由于卫星小区（eNB）固定不动，缓存 PANI 中的 NB-IoT(GEO) 标识以优化资源分配。
步骤4：IMS 核心网返回注册成功响应

核心操作：

  • 200 OK 响应：IMS 核心网确认注册成功，P-CSCF 转发该响应至 UE。
  • IMS AS 感知 NB-IoT(GEO)：IMS AS 通过 PANI 头域获悉 UE 的接入网络属性，动态调整后续语音服务的 QoS 策略。

5.3 移动主叫流程（Mobile Originating, MO Call）

适用场景：终端发起语音呼叫时，若仅在呼叫建立过程中触发EPS承载激活（非预激活），则由P-CSCF或IMS AS作为B2BUA（Back-to-Back User Agent）介入信令交互。
Mobile originating, P-CSCF as B2BUA if EPS bearer not pre-established
Mobile originating with IMS AS acting as B2BUA

关键步骤解析：

  1. UE注册与服务请求：

    • 终端完成IMS注册后，通过拨号启动呼叫。
    • 若处于RRC-IDLE状态，执行Service Request以过渡至RRC-CONNECTED，并触发EPS语音承载激活（步骤1）。

  2. SIP INVITE优化：

    • 终端发送的SIP INVITE消息精简冗余字段：
      • To头域省略：沿用Request-URI中已包含的被叫方地址（如tel:+8613587654321），避免重复信息。
      • 编解码器列表裁剪：仅携带G.711 PCMU/8k、G.729等卫星低带宽适配的编解码器。
    • P-CSCF收到INVITE后，发送SIP 100 Trying（可选，具体根据RAT类型动态判断）。

  3. 资源分配与信令转发：

    • P-CSCF指令AGW（接入网关）为终端与网络侧分配音频资源，并根据注册信息补充缺失信令字段（如Contact头域）。
    • P-CSCF作为B2BUA转发INVITE至IMS核心网，添加Supported: 100rel, precondition以适配预条件机制（步骤4）。

  4. EPS承载激活触发：

    • 若卫星链路未预激活语音承载，P-CSCF将触发TFT（流量模板识别）配置以激活EPS承载（步骤5）。

  5. 预条件协商简化：

    • 在后续信令交互（如183 Progressing、PRACK、UPDATE）中，仅保留核心网与终端间的SDP协商，省略冗余的资源监控（步骤6-10）。

  6. 会话建立与媒体传输：

    • IMS核心网返回180 Ringing后，P-CSCF将180消息转发至终端（步骤11），触发振铃提示。
    • 终端接收到200 OK（INVITE）后，通过ACK确认，并完成与网络侧的媒体流同步（步骤12-13）。

优化效果：

  • 时延缩短：信令交互次数从8次减少至5次（INVITE→100→183→200→180），减少37.5%。
  • 流量压缩：SIP消息总负载从10KB降至6KB以下，SDP压缩后单条INVITE仅70字节。

5.4 移动被叫流程（Mobile Terminating, MT Call）

适用场景：核心网向NB-IoT终端发起语音呼叫时，同样面临卫星链路时延高、带宽低的挑战。提案对MT流程进行了针对性优化。
Mobile terminating, P-CSCF as B2BUA if EPS bearer not pre-established
Mobile terminating with IMS AS acting as B2BUA

关键技术步骤：

  1. 核心网发起INVITE：

    • IMS核心网向P-CSCF发送INVITE，可能包含预条件支持标识（步骤1）。

  2. AGW资源分配与INVITE转换：

    • P-CSCF指令AGW分配终端侧音频资源，并将核心网的INVITE转换为适用于NB-IoT（GEO）的简化版本：
      • 剥离预条件扩展头域，仅携带Supported: 100rel。
      • 编解码器兼容性调整：确保仅传递GEO适配的编解码器（如G.711）。

  3. 终端响应与EPS激活：

    • 终端在收到简化版INVITE后，触发Service Request流程以激活EPS承载（步骤3）。
    • 终端发送183 Progressing包含自身SDP应答，供AGW配置资源（步骤4）。

  4. 核心网侧预条件协商替代：

    • P-CSCF通过P-CSCF感知PCR状态，在获悉承载就绪后，向核心网发送183 Progressing（步骤7），标注要求100rel与预条件（若策略需要）。

  5. 媒体流打通：

    • 用户接听后，终端发送200 OK至P-CSCF，P-CSCF补全Contact头域并转发至核心网（步骤11）。
    • 最终通过ACK完成三次握手，媒体流经NIDD用户面透传（步骤12）。

优化亮点：

  • 网络侧触发简化：核心网免于处理冗余SDP协商，降低处理负荷。
  • NIDD承载适配：媒体流通过非IP传输，减少IP头开销，提升卫星链路效率5-10%。

5.5 紧急呼叫流程（Emergency Call Procedures）

合规性要求：提案严格遵循TS 22.261与TS 22.101标准，确保紧急呼叫满足以下监管需求：

  • 匿名呼叫支持：允许未完成IMS注册的终端发起紧急呼叫。
  • MSD（最小紧急数据集）透传：Metadata通过NIDD用户面传递，无需SIP信令封装。
  • 地理位置上报：通过NB-IoT与GEO链路定位终端位置，满足应急响应需求。

技术实现路径：

  1. 紧急呼叫检测：

    • SCC-AS（Service Centralization and Continuity Application Server）通过I1接口检测终端发送的紧急号码（如112）或eCall标识。

  2. 匿名呼叫处理：

    • 跳过IMS注册流程，SCC-AS直接生成临时标识（如匿名SIP URI）并路由至PSAP（公共安全应答点）。

  3. MSD数据透传：

    • MSD字段经NIDD用户面透明传输，保持原始格式（如车辆GPS坐标、碰撞传感器数据）。

  4. 卫星定位服务：

    • 通过TS 23.273定义的5G定位架构，结合终端GPS模块与NG-RAN提供地理信息。

典型案例分析：

  • 场景：矿难事故中，矿工佩戴支持NB-IoT（GEO）的对讲终端，因地面基站损毁无法通信。
  • 流程：
    1. 终端通过GEO卫星发送包含MSD的eCall至PSAP。
    2. SCC-AS绕过IMS注册，直接将紧急SIP INVITE推送E-CSCF。
    3. PSAP接收到MSD后，通过GIS系统定位事故矿井坐标，调度救援。

六、参考标准与兼容性设计

提案严格遵循3GPP与IETF标准，确保与现有网络的兼容性：

  1. 3GPP标准引用：
    • TS 23.501（5G系统架构）、TS 23.502（5G系统流程）、TS 23.228（IMS Stage 2）定义IMS核心网功能。
    • TS 22.261（5G服务需求）、TS 22.101（服务原则）明确卫星通信场景下的QoS与监管要求。
  2. IETF协议适配：
    • RFC 3261（SIP协议）、RFC 4566（SDP协议）作为信令与会话描述基础。
    • RFC 5049（SigComp）用于SDP压缩，降低带宽消耗。

兼容性保障：

  • 预条件禁用：通过P-CSCF与IMS AS的协同，确保禁用策略不影响非优化终端的正常呼叫流程。
  • 渐进式部署：网络侧可基于终端能力（如GEO接入标识）动态启用优化功能，避免全网升级风险。

七、结论与展望

本提案通过禁用预条件机制与SIP消息优化，为NB-IoT（GEO）场景下的IMS语音服务提供了低时延、高带宽利用率的解决方案。其核心价值在于：

  1. 性能提升：信令交互次数减少37.5%，消息负载降低40%，显著缩短呼叫建立时间。
  2. 标准化路径：基于3GPP Rel-20框架，与TS 23.501/TS 23.502等标准无缝集成，加速商用落地。
  3. 场景适配性：针对卫星信道特性优化编解码器选择与资源分配策略，为未来6G空天地一体化网络奠定基础。

未来，随着NTN技术的进一步发展，该方案可扩展至LEO（低轨卫星）与MEO（中轨卫星）场景，并结合AI驱动的QoS预测机制，实现更智能的资源调度与用户体验优化。

http://www.xdnf.cn/news/1038295.html

相关文章：

  • ELK日志文件分析系统——L(Logstash)
  • Flutter 状态管理与 API 调用的完美结合：从理论到实践
  • python实战：使用Python合并PDF文件
  • pyqt5，python开发软件，文件目录如何设置，如何引用，软件架构如何设计
  • 洛谷 P5711：闰年判断
  • 基于Python学习《Head First设计模式》第十一章 代理模式
  • 「Linux中Shell命令」Shell常见命令
  • Vue 3 砸金蛋互动抽奖游戏
  • Redis事务与驱动的学习(一)
  • 出现端口占用，关闭端口进程命令
  • Redis三种集群概述：主从复制、哨兵模式与Cluster模式
  • MySQL 究极奥义·动态乾坤大挪移·无敌行列转换术
  • SSH参数优化与内网穿透技术融合：打造高效远程访问解决方案
  • Android 获取签名 keystore 的 SHA1和MD5值
  • transactional-update原子性更新常用命令
  • 数据库期末
  • LangChain开发智能问答(RAG)系统实战教程：从零构建知识驱动型AI助手
  • 推荐一个轻量级跨平台打包工具 PakePlus：重塑前端项目桌面化体验
  • 微软云注册被阻止怎么解决？
  • uniapp 腾讯地图服务
  • 【DSP笔记 · 第3章】数字世界的“棱镜”：离散傅里叶变换（DFT）完全解析
  • 自定义 eslint 规则
  • 基于Java开发的浏览器自动化Playwright-MCP服务器
  • 图表工具 ECharts vs Chart.js 对比
  • 问题记录_如何让程序以root权限启动_如何无视系统的路径问题
  • 从零开始：VMware上的Linux与Java开发环境配置
  • Python训练营-Day31-文件的拆分和使用
  • 自编码模型原理
  • SpringBoot源码解析(十二)：@ConfigurationProperties配置绑定的底层转换
  • 【卫星通信】高通提案S2-2504588解读-基于控制平面优化的GEO卫星IMS语音解决方案