好的，我们继续进行深度拆解。这是本系列的第三篇文章，将聚焦于3GPP TR 23.700-19的第5章“Key Issues (核心挑战)”。
深度解析 3GPP TR 23.700-19：5 Key Issues (核心挑战)
本文技术原理1 承载类型的选择**
标准的VoLTE会为IMS信令建立一个QCI=5的默认深度参考了3GPP TR 23.700-19 V1.0.0 (承载，为语音媒体流建立一个QCI=1的专用GBR承载。但在NB-IoT上2025-09) Release 20规范。在深入剖析了作为研究基石的“，这条路走不通。
- GBR承载的缺失： NB-IoT不支持GBR承载。架构假设”之后，我们正式进入这份技术报告的心脏地带——第5章“Key Issues (核心挑战这意味着我们无法为语音流预留固定的带宽。
- 承载数量的限制： NB-IoT终端)”。本章精准地定义了星地融合之路上必须攻克的五大技术堡垒，它们是后续通常只支持非常有限的承载数量（例如，最多两个）。
这就迫使我们必须进行系统性的增强所有解决方案的“靶心”和“考题”。
引言：从“规则”到“挑战，考虑替代方案，这也正是后续解决方案章节（Chapter 6）中激烈辩论的焦点：
- **”，明确需要翻越的五座大山
在上一场研讨会中，我们的主角，5G工程师Alex，已经带领团队彻底厘清了TR 23.700-19研究工作的“游戏方案A：All in One (单承载方案):** 将IMS信令和语音流都放在同一个默认的non规则”，即第4章的“架构假设”。他们清楚地知道，自己正站在EPC和5GS这两-GBR承载上传输。这最简单，但问题是如何区分信令和语音的优先级？如何保证片截然不同的“战场”上，面临着GEO卫星高时延和NB-IoT窄带宽等先天语音包不被其他数据“饿死”？ 2. **方案B：数据与信令分离约束。
“如果说第4章给了我们一张地图，标明了边界和地形，” Alex在新的 (双承载方案):** 为IMS建立一个默认承载（non-GBR）用于传输信令，团队会议上打开了投影，“那么第5章，就是在这张地图上，为我们圈出了五个必须攻占再为语音建立一个专用的non-GBR承载。这需要网络支持在NB-IoT上建立的战略高地。这五个‘Key Issues’，是3GPP经过深思熟虑后提炼出的核心专用承载，并且需要定义一个新的QCI（QoS类别标识符）来描述这种特殊的“尽力而为的实时语音”。 3. 方案C：另辟蹊径 (控制面承载): 彻底技术难题。我们对它们的理解深度，将直接决定我们能否看懂后续那二十多种解决方案的精髓抛弃用户面承载（DRB）来传输语音的想法，而是将语音数据包封装在NAS信令中所在。”
Alex将这五个核心挑战比作五座必须翻越的大山，每一座都代表了一个，通过控制面（SRB）传输。这需要对MME和UE的协议栈进行重大增强，让独特而复杂的技术领域。今天，他的任务就是带领团队，逐一勘察这五座大山的地MME扮演一部分类似S-GW的角色。
这些增强方案，每一种都牵动着EPC核心架构的神经形地貌，理解其艰巨性。
1. 第一座山：GEO NB-IoT NT。
2.3 阶段三：IMS注册与呼叫 - “漫长的等待”
假设N上的IMS语音支持 (Key Issue #1)
Alex指向第一座大山，也是最基础、最核心的一PDN连接已经建立，Evelyn博士的设备现在可以和IMS网络“对话”了。她拨座。“我们的第一个，也是最直接的挑战是：如何让IMS语音通话这个‘现代交通工具’，跑打了实验室的号码，设备开始发起IMS注册和呼叫流程。在GEO卫星环境下，这将是一场对在GEO NB-IoT NTN这条‘崎岖泥泞的乡间小路’上。”
一次标准的IMS呼叫建立，包含IMS注册和会话建立两个 5.1 Key Issue #1: Support of IMS voice call over NB-IoT NTN via GEO satellite connecting阶段，涉及大量的SIP（会话发起协议）消息交互：
- IMS注册:
REGISTER→ `4 to EPC
To support IMS voice call over NB-IoT NTN via GEO satellite connecting to EPC, this key issue studies01 Unauthorized
->REGISTER(带鉴权信息) ->200 OK`。这里至少有 the following issues:
- System enhancements to support IMS voice service over NB-IoT NTN via GEO satellite connecting to EPC;
- Whether and how to support QoS for IMS voice service over GEO satellite.
Alex将这个问题拆解为两个更两次往返交互。
- 会话建立 (以PRACK为例):
INVITE→100 Trying→183 Session Progress→PRACK→ `200 OK (具体的子问题，并用生动的比喻向团队解释。
1.1 系统需要做出哪些增强for PRACK)->180 Ringing->200 OK (for INVITE)` → 改造？ (System enhancements)
“首先，我们的UE和网络需要学会一种‘新的方言’，” Alex解释ACK。这是一个极其复杂的“探戈舞”，包含了多次消息往返。
现在，让我们计算一下时间道，“一个支持卫星语音的NB-IoT终端，在开机接入网络时，不能再像普通终端。假设一次消息往返（地-天-地-天-地）的延迟是600毫秒那样‘沉默’。它必须在第一时间就告诉网络：‘你好，我叫Alex的手机，我不仅。仅IMS注册就需要 2 * 600ms = 1.2秒。而会话建立过程中的 INVITE → 183 → PRACK → 200 OK → `2能发物联网数据，我还能通过头顶这颗GEO卫星打电话！’”
这种“宣告”就需要对00 OK->ACK粗略计算就需要3 * 600ms = 1.8系统进行增强。在4G EPC中，这通常意味着要在NAS（非接入层）信令，如秒。两者相加，光是理想情况下的信令交互延迟就高达3秒，这还不包括Attach Request或TAU Request消息中，增加新的信息元素（IE）或能力位。这个消息本身的传输时间和处理时间！一个标准的SIP INVITE`消息可能包含几百甚至上千字节，小小的标志，将触发网络侧一系列全新的处理逻辑。
同样，网络侧的MME（移动性管理实体）在NB-IoT的窄带上，光传输这个消息就需要好几秒。
因此，“系统增强”在这里也必须“听得懂”这种方言。当它看到这个标志，它需要知道：
- **意味着必须对IMS流程进行大刀阔斧的改革，例如：
- 信令压缩: 减少SIP鉴权与授权：** 这个用户是否有权限使用这项“高级”服务？这需要查询HSS（归消息的大小，比如省略非必要头域、使用二进制编码等。
- 流程简化: 减少消息属签约用户服务器）中的签约数据。
- 资源选择与协商： 它需要为这个特殊的业务选择合适的S-GW和P-GW，并在建立承载的过程中，传递与卫星语音相关的特殊信息交互的往返次数，比如取消或合并某些步骤。
这些都是后续解决方案章节需要详细探讨和评估的。
3. 服务质量 (QoS) 的挑战 - 在“沼泽”里规划“高速。
“所以，‘系统增强’的本质，就是定义一套全新的‘接头暗号’，让公路”
规范的第二项研究点，直击问题的要害：QoS。如果说系统增强是在UE和网络能够相互识别，并为即将到来的语音业务启动一套特殊的、非标准的处理流程。”
修路，那么QoS保障就是在路上设置交通规则，确保“跑车”能够畅行无阻。
1.2 如何提供服务质量保障？ (QoS support)
“如果我们把语音数据包比作需要> - Whether and how to support QoS for IMS voice service over GEO satellite.
“‘Whether and how’这个紧急运送的‘救心丸’，那么QoS就是为运送它的救护车开辟的‘紧急用词非常精妙，” Alex对团队说，“‘Whether’意味着3GPP甚至不确定在這種极端条件下是否还能提供传统意义上的QoS。‘How’则代表了如果要做，我们该如何打破常规通道’，” Alex继续比喻道，“但在NB-IoT这条路上，原本就没有紧急通道。”
VoLTE，创造出一套全新的QoS体系。”
3.1 承载层的QoS失效
如（基于LTE的语音）之所以体验流畅，是因为网络为其建立了一条专用的、具有保证比特率（GBR前所述，EPC的QoS体系是围绕“承载”和QCI建立的。但在我们的场景下，这个）的承载（Bearer），QCI（QoS等级标识符）通常为1。这条“VIP通道”确保体系几乎失效了。
- 没有GBR，就没有“保证”: 无法使用GBR承载，了语音包被优先发送，且拥有稳定、可预期的带宽。
然而，在GEO NB-IoT NT意味着从空口层面，我们无法为语音流预留固定带宽。所有的数据包，包括语音包，都在一个N场景下，我们面临三重困境：
- NB-IoT不支持GBR承载： NB共享的、尽力而为的资源池中竞争。
- QCI的局限性: 现有的non-GBR QCI（如QCI 6-9）是为非实时业务设计的，它们的-IoT的设计初衷是传输非实时的小数据包，其承载模型通常只支持“尽力而为”（Best Effort）的非GBR承載。
- GEO链路的高时延与不稳定性： 长丢包率和时延指标完全不适用于语音。例如，QCI 9的PDB（Packet Delay Budget，分组延迟预算）是300ms，这对于地面网络已经很宽松，但在GEO场景下，光达数百毫秒的物理时延，以及可能因天气等因素变化的链路质量，使得保证低时延和低传播延迟就几乎耗尽了这个预算。
因此，我们需要一套全新的QoS思考方式。
3.2抖动变得异常困难。
- 资源极度受限： 窄带信道上的任何 新的QoS保障思路
既然传统的承载层QoS模型靠不住，我们就必须在整个数据通一点带宽都弥足珍贵。
“所以，KI#1的第二个核心难题就是，” Alex总结道，“在一个路上寻找所有可能的“控制点”，进行端到端的协同保障。
3.2.1 空没有VIP通道、路况还很差的系统里，我们如何确保‘救心丸’（语音包）能够口层 (RAN)
- 调度优先级: 虽然没有GBR，但eNB在进行无线资源调度时，准时、稳定地送达？我们是需要为NB-IoT引入一种新的‘准GBR’承载仍然可以为不同的逻辑信道（Logical Channel）设置不同的优先级。系统增强需要定义一种机制，让网络类型吗？还是通过改造调度算法，赋予语音包绝对的抢占优先级？或者，我们干脆放弃能够识别出承载语音的无线承载（无论是DRB还是SRB），并赋予其最高的调度优先级。
3.2.2 核心网层 (EPC)
- 创建新的QCI? 一个在用户面（UP）送，改走控制面（CP）这条‘特供小路’？这些都是后续解决方案要回答的问题。”
2. 第二座山：IMS协议栈的增强与直接的思路是，为这种“尽力而为的卫星语音”创建一个新的non-GBR QCI。这个优化 (Key Issue #2)
“好了，假设我们已经修好了路（KI#1），但现在发现新的QCI需要定义一套全新的参数，例如一个非常大的PDB（比如800ms），以及一个相对较低，运送‘救心丸’的卡车（IMS信令）本身太笨重了，根本开的丢包率。这需要对3GPP的QoS规范进行修订。
- **P-GW的不上这条乡间小路。” Alex引出了第二个挑战。
5.2 Key Issue #2:差分服务 (DiffServ):** P-GW是连接运营商网络和外部IP网络的关口。它可以根据数据 IMS enhancement for GEO NB-IoT NTN access
To meet the requirements on experienced data rate and call setup time包的来源（例如，来自承载语音的承载）或内容，在IP头中打上不同的 documented in TS 22.261, this key issue studies:
- Whether and how to enhanceDSCP（Differentiated Services Code Point）标记。这些标记可以被后续的IP网络路由器识别，从而为 IMS to utilize NB-IoT as IP-CAN;
- Potential IMS optimization.
IMS是基于SIP（语音包提供优先转发。例如，为来自卫星语音的RTP包打上EF (Expedited Forwarding会话初始协议）的，而SIP是一种文本协议，其信令消息通常较为冗长，包含大量的) 标记。
3.2.3 IMS层
- 自适应抖动缓冲区 (头域和描述信息。在一个标准的VoLTE呼叫中，一次完整的呼叫建立需要十几次信令交互，总Adaptive Jitter Buffer): 在接收端（无论是UE还是网络侧的媒体网关），需要设计一个更大信令量可能达到数千甚至上万字节。
2.1 如何让IMS“适应”NB-、更智能的抖动缓冲区。由于卫星链路的时延和抖动都很大，这个缓冲区需要能够缓存IoT？
“第一个子问题是，IMS作为一个上层应用系统，它得知道自己脚下的‘路’更多的语音包，以平滑数据包到达时间的波动，但又不能过大，否则会引入额外的端到端时延。
Alex总结道：“QoS的挑战是系统性的。它不再是单一承载层能解决的问题，（IP-CAN, IP承载网络）已经从宽阔的LTE高速公路，变成了NB-IoT NTN这条羊肠小道。它不能再像以前那样‘大手大脚’了。”
这意味着IMS实体而是需要从空口调度、核心网流控、IP层标记到应用层缓冲的端到端协同设计（如P-CSCF）需要能够识别出来自NB-IoT NTN的接入，并可能为此启用。每一个环节，都需要进行精心的增强和适配。”
4. 总结：Key Issue #1 的一套专门的、精简的处理逻辑。
2.2 如何对IMS进行“瘦身”？ (艰巨性
通过以上剖析，我们可以看到，TR 23.700-19的Potential IMS optimization)
这是KI#2的核心。3GPP TS 22.261对卫星Key Issue 1不仅仅是一个技术问题，它是一个由**物理定律（高时延）、技术标准（NB-接入的呼叫建立时间提出了要求（例如，不能超过几十秒）。但在GEO NB-IoT链路上，一个标准的IoT/EPC限制）和业务需求（实时语音）**三者共同构建起来的复杂系统工程。
-SIP INVITE消息（通常大于1KB）可能因为太大，需要被分片成多个小包才能在 系统增强 回答了“能不能通”的问题。它要求我们改造从UE能力上报、网络NB-IoT的空口上传输。每一次分片传输，加上GEO的高时延，都会让呼叫建立时间附着、承载建立到IMS信令交互的全链路流程，让这条路至少能走通。
- **变得无法忍受。
“所以，我们必须对IMS进行大刀阔斧的优化，” Alex列出了QoS保障** 回答了“通了之后好不好用”的问题。它要求我们在一套几乎失效几个主要方向：
- 信令压缩 (Signalling Compression): 能不能像压缩文件一样，把的传统QoS体系之上，创造性地构建一个多层次、端到端的服务质量保障框架。
ESIP信令压得更小再传输？比如使用SigComp等标准压缩协议。
- 消息velyn博士在喜马拉雅山巅的每一次呼唤，都是对我们整个通信系统极限能力的一次拷简化 (Message Simplification): UE在给网络发信令时，能不能只说“关键信息”？比如问。而Key Issue #1，正是3GPP试图回答这份拷问的第一份、也是最艰难的一，那些网络在UE注册时已经知道的信息（如UE的能力、联系地址等），是不是就可以在呼叫建立份答卷。后续的解决方案，将围绕这些挑战，展开一场精彩纷呈的技术博弈。
时省略掉，由网络侧的P-CSCF帮忙“补全”？
- **流程简化 (Procedure FAQ
Q1：为什么Key Issue 1的研究基于EPC（4G核心网）而不是更先进的5GC Simplification): 一个标准的IMS呼叫建立，为了保证QoS，有复杂的前置条件协商（Precondition？** A1：这主要是出于现实和商业的考量。NB-IoT作为一项关键的物联网技术）流程。在这个本就“弱QoS”的系统里，这套复杂的流程是否还有必要？我们，其绝大多数现网部署都是基于EPC的。全球已经有数以亿计的NB-IoT设备连接能不能跳过它，或者用一种更简单的方式来替代？
- 协议替换 (Protocol Substitution): SIP协议是不是唯一的选择？有没有更轻量级的协议（比如二进制编码的I1协议）可以用在UE和网络之间在EPC网络上。在EPC上进行卫星语音的研究，意味着这项能力可以作为现有网络的平滑演进，，来传递呼叫信令？
“KI#2的本质，就是一场针对IMS协议的‘极限保护运营商的投资，并快速赋能广大的存量物联网市场。虽然5GC更先进，但为瘦身’运动。每一个被节省下来的字节，每一次被减少的信令交互，在GEO链路上都可能转化为庞大的EPC存量网络寻找新的增长点和应用场景，同样是3GPP的重要工作。
**Q2数秒的宝贵时间。”
3. 第三、四座山：紧急呼叫及其：IMS语音在GEO NB-IoT NTN上的最大瓶颈是带宽还是时延？**
A2位置服务 (Key Issue #3 & #4)
“接下来的两座山，事关生命安全，：两者都是严重瓶颈，但时延是更根本、更难解决的物理瓶颈。带宽是法规的红线，没有任何妥协的余地。” Alex的表情变得格外严肃。
5.问题，可以通过极致的协议压缩、高效的语音编解码器在一定程度上缓解。例如，NIDD3 Key Issue #3: Support of IMS emergency call over NB-IoT NTN via GEO satellite connecting to EPC
技术可以省去IP头开销，先进的语音编码器可以在几kbps下提供可接受的音> 5.4 Key Issue #4: Location service for IMS emergency call and regulatory services over NB-IoT NTN质。然而，GEO卫星~270ms的单向物理传播时延是由光速和轨道高度
他将这两个问题放在一起讲解，因为它们紧密相关。
3.1 如何确保紧急呼叫的最高优先级？ (KI#3)
在杳无人烟的海洋、沙漠或山区，卫星是唯一的决定的，这是任何技术都无法消除的。它使得任何需要“一来一回”的信令交互都会变得极其缓慢，并直接挑战了人类对话的时延容忍极限。
**Q3：什么是QCI求救通道。当用户拨打紧急号码时，网络必须能够：
- 准确识别：？为什么在NB-IoT上支持合适的QCI如此困难？** A3：QCI（QoS Class Identifier） 无论UE是否插卡、是否注册，网络都必须能够识别出这是一个紧急呼叫。
- 绝对是EPC网络中用于标识一组QoS特性的数字标签（1到9是标准化的）。例如，Q优先： 紧急呼叫必须能抢占任何非紧急业务正在使用的网络资源。在带宽本就CI=1代表需要GBR保障的实时语音，QCI=9代表需要non-GBR的尽捉襟见肘的NB-IoT NTN链路上，这意味着可能需要中断其他用户的通信，来保障这条力而为的互联网数据。每个QCI都关联着一套具体的QoS参数，如优先级、延迟预算（PDB“生命热线”的建立。
- 正确路由： 呼叫必须被准确地）、丢包率等。在NB-IoT上支持合适的语音QCI之所以困难，核心在于NB-IoT的路由到相应的公共安全应答点（PSAP），如警察、火警或医疗急救中心。
“极简”设计理念。它为了实现低功耗和低成本，裁剪了许多LTE的复杂功能，其中就包括对GBR承载的支持。因此，无法使用为VoLTE设计的QCI=1。而现“挑战在于，现有的紧急呼叫流程都是为地面网络设计的。如何将这套复杂的机制，平移并适配到高时延、资源受限的卫星链路上，确保其绝对的可靠性和最高优先级有的non-GBR QCI，其参数都是为非实时数据设计的，完全不满足语音需求。所以，是KI#3需要解决的核心。”
3.2 如何在太空中为生命“定位”？，要么创造一个全新的QCI，要么就得彻底改变QoS的实现思路。
**Q4：“ (KI#4)
“一个没有位置信息的求救电话，价值会大打折扣。” Alex指出了KI系统增强”是否意味着现有的NB-IoT模块都需要硬件升级？** A4：不一定。大部分#4的关键。
This key issue studies whether existing location services can be used to obtain the UE location… meeting“系统增强”都发生在协议和软件层面。例如，在NAS信令中增加新的IE、实现新的 regulatory requirements…
地面网络定位相对容易，可以通过测量信号到达不同基站的时间差（OTDOA）IMS信令简化逻辑、支持控制面数据传输等，这些通常可以通过终端的固件升级（FOTA）来实现或角度差（E-CID）来进行三角定位。但在卫星场景下：
- GEO卫星视角。3GPP在进行标准化设计时，会非常谨慎地避免引入需要大规模硬件改动的方案，以保证向后兼容性和方案的可落地性。当然，对于非常早期的、协议栈固化得比较死的单一： 对于单个GEO卫星，它就像一个高悬在空中的“天眼”，很难通过单一信号源进行精准的三角定位。
- GNSS的局限性： 虽然UE可以内置GPSNB-IoT模块，可能无法通过升级来支持这些新功能。
Q5：既然GEO卫星时、北斗等GNSS模块来主动上报位置，但在某些情况下（如室内、设备无电、GN延这么高，为什么不直接在时延更低的LEO卫星上研究NB-IoT语音？ A5SS模块损坏），UE可能无法获取位置。
“法规要求网络必须具备提供位置信息的能力，不能完全依赖终端：这是一个权衡。虽然LEO（低轨）卫星时延低（通常在几十毫秒），但它。所以KI#4的研究重点是：现有的网络定位技术能否在卫星上使用？如果不能，我们需要也带来了新的复杂性：1) 覆盖不连续： 单颗卫星过顶时间短，需要庞研究哪些新技术？比如，利用卫星信号的往返时间（RTT）和多普勒频移，结合精确大的星座才能实现连续覆盖，建设和运营成本高。2) 高动态性： 卫星高速的卫星星历数据，能否估算出一个大致但足以满足基本救援需求的UE位置？这对于紧急救援移动，导致频繁的小区切换和大的多普勒频移，对终端的移动性管理和信号跟踪至关重要。”
5. 第五座山：面向未来的UE-SAT-UE通信 (能力提出了更高要求。相比之下，GEO卫星链路稳定，移动性管理简单，覆盖范围广。从研究Key Issue #5)
“前面四座山，我们都是在EPC这张‘旧地图’上攻坚。现在角度看，在GEO这个“最差条件”下验证了可行性，其优化方案（如协议压缩、流程，我们来到最后一座山，它建立在5GS这张‘新蓝图’之上，代表了星地融合的未来。” Alex的语气再次变得兴奋起来。
5.5 Key Issue #5: UE简化）同样可以应用于LEO场景，并获得更好的效果。因此，攻克GEO场景具有很强的技术代表性。-SAT-UE communication via UPF only onboard satellite for non-IMS services
This key issue studies:
- How to support UE-SAT-UE communication via UPF only onboard satellite for non-IMS services (e.g. 5G-LAN services with IP and Ethernet PDU Session type).
这个挑战的核心，正如其名，是研究如何实现用户数据流完全在太空中完成转发，而不再需要落地。
NOTE 1: Whether existing mechanisms can be reused will be considered in this KI. NOTE 2: Any UE impact will not be considered in this KI
Alex结合这两条注释，深入解读了这个前瞻性的课题。 “想象一个场景：在某个偏远的科考站，两名队员需要互传高清勘测视频。传统的卫星通信，视频流需要先传到卫星，再下行到几千公里外的地面站，由核心网处理后，再上行到卫星，最后才传给另一名队员。这一来一回，时延巨大，还占用了宝贵的星地链路带宽。”
“而KI#5要研究的，就是如何让这段视频流直接在他们头顶的卫星上‘拐个弯’，从一个队员的终端直接转发到另一个队员的终端。这就是通过‘星上UPF’实现的UE-SAT-UE通信。”
这项研究需要解决的问题包括：
- 触发与决策： 地面核心网的SMF（会话管理功能）如何“智能”地判断出