好的，我们继续进行深度拆解。这是本系列的第二十四篇文章，将聚焦于TR 23.700-19的附录A，深入探讨评估卫星通信呼叫建立时间的方法论。

深度解析 3GPP TR 23.700-19：附录A 呼叫建立时间估算方法论

本文技术原理深度参考了3GPP TR 23.700-19 V1.0.0 (2025-09) Release 20规范。在系统性地回顾了TR 23.700-19的所有核心挑战与解决方案之后，我们的探索之旅进入了“方法论”层面。本文将深入解读 附录A (Annex A)，这是一个至关重要的章节，它为所有解决方案的性能评估，特别是呼叫建立时间 (Call Setup Time, CST) 的估算，提供了一套标准化的、可量化的计算公式和基准参数。

引言：从“定性”到“定量”的科学标尺

在之前的方案评估中，我们经常使用“更快”、“更高效”、“时延更低”等定性描述。然而，在工程和科学的世界里，没有量化就没有比较，没有比较就没有决策。Alex的团队在向CTO汇报时，被问到了一个尖锐的问题：“Solution 20的二进制编码，到底比Solution 15的文本简化快多少？快2秒还是5秒？在1kbps和3kbps的带宽下，差异又是多少？”

要回答这些问题，就不能再依赖于感觉和描述，而需要一把统一的、公认的“科学标尺”。附录A，就是3GPP为所有参与星地融合研究的工程师们，提供的这样一把“标尺”。

“先生们，女士们，” Alex在一次性能分析专题会上说道，“附录A虽然是附录，但它的重要性不亚于任何一个解决方案。它定义了我们进行性能‘赛马’的‘跑道长度’和‘计时规则’。没有它，我们对各个方案的评估就会陷入‘公说公有理，婆说婆有理’的混乱。今天，我们的任务就是彻底搞懂这套方法论，学会如何科学地、公平地为每一个方案‘掐表计时’。”

To ensure consistency in evaluating solutions based on estimated call setup time, solutions for evaluation must adhere to a standardized baseline methodology…

规范开宗明义，点明了附录A的宗旨：为了确保评估的一致性，必须遵守标准化的基线方法论。

1. 呼叫建立时间（ECST）的总体计算框架 (A.1.1 General)

附录A首先给出了估算呼叫建立时间（ECST, Estimated Call Setup Time）的总体计算公式。它区分了两种主要场景：

1.1 卫星到地面（Sat-to-Terr）呼叫

ECSTsat to terr [s] ≈ ETstateTransition[s] + ETimsDelay[s] + ETepsDelay[s] + ETterr [s]

• 场景: Evelyn博士（卫星用户）呼叫她位于地面实验室的同事。
• 公式解读:
  • ETstateTransition: 状态转换时间。如果UE是IDLE态，这是从IDLE转换到CONNECTED态所需的时间（包括寻呼、服务请求等流程）。对于MO（主叫）呼叫，这是Service Request的时间；对于MT（被叫）呼叫，这是Paging+Service Request的时间。
  • ETimsDelay: IMS信令流程时延。这是IMS呼叫建立信令（如INVITE, 183, PRACK等）在星地链路上产生的传输和传播时延。
  • ETepsDelay: EPS信令流程时延。这是在呼叫过程中，如果需要动态建立或修改EPS承载（如专用承载）所产生的信令时延。
  • ETterr: 地面网络时延。这是一个估算值，用于代表信令在地面IMS核心网和对端地面网络中传输和处理的总时延。规范建议取VoLTE经验值的一半，2.5秒。

1.2 卫星到卫星（Sat-to-Sat）呼叫

公式更为复杂，它将IMS和EPS时延分成了主叫侧（MO）和被叫侧（MT）两部分，因为两端的星地链路时延需要分别计算。

ECSTsat to sat [s] ≈ ETstateTransition [MO] + ETstateTransition [MT] + ETimsDelay [MO] + ETimsDelay [MT] + ETepsDelay [MO] + ETepsDelay [MT]

“这个总体框架，给了我们一个清晰的分析模型，” Alex解释道，“它告诉我们，一次完整的呼叫建立，其总时延是由‘终端唤醒、IMS信令、承载建立、地面网络’这四大块组成的。我们后续对不同方案的评估，就是看它们分别在ETimsDelay和ETepsDelay这两块上，节省了多少时间。”

2. IMS信令时延 (ETimsDelay) 的计算方法 (A.1.2)

这是整个估算方法论的核心，因为它直接关系到各种信令优化方案的性能对比。

ETimsDelay [s] ≈ ( SsignallingIMS [bits] + Sepstheader [bits] ) / Rtransmission [bps] * 3 + Dpropagation × (NUL-IMS + NDL-IMS) [s] (Note 1 modified the formula for better understanding: *3 for UL transmission)

这个公式看起来复杂，但Alex将其分解为三个清晰的部分：

1. 传输时延 (Transmission Delay):

   • SsignallingIMS: 这是IMS信令消息本身的尺寸（bits）。例如，一个简化后的INVITE消息是1121字节，这里就是1121 * 8 bits。
   • Sepstheader: 这是承载IMS信令的底层协议开销（bits）。规范给出的典型值是52 Bytes (UDP/IPv6/PDCP/RLC/MAC)。
   • Rtransmission: 这是NB-IoT的传输速率（bps），例如1kbps或3kbps。
   • * 3: 这是一个非常重要的修正系数。规范注释中提到，考虑到NB-IoT的上行资源申请流程（RACH），一次上行传输实际上需要3个步骤（Scheduling Request → UL Grant → PUSCH data）。因此，所有上行消息的传输时间，都需要乘以3。

2. 传播时延 (Propagation Delay):

   • Dpropagation: 这是单向的空口传播延迟。对于GEO卫星，规范建议取值为 0.28秒 (280ms)。
   • NUL-IMS: 整个呼叫流程中，上行IMS消息的总数。
   • NDL-IMS: 整个呼叫流程中，下行IMS消息的总数。
   • Dpropagation × (NUL-IMS + NDL-IMS): 这就是所有消息在空口上的总的“飞行时间”。

3. 总时延:

   • ETimsDelay 就是所有上行消息的传输时延 + 所有下行消息的传输时延 + 所有消息的总传播时延。

“通过这个公式，” Alex强调，“我们就可以量化任何一种信令优化的效果。比如，Solution 15通过简化消息，减小了SsignallingIMS；Solution 16通过预配置，减少了NUL-IMS和NDL-IMS的数量。我们可以把不同方案的参数代入这个公式，直接计算出它们的ETimsDelay，从而进行公平的比较。”

3. EPS信令时延 (ETepsDelay) 的计算方法 (A.1.3)

如果一个方案需要在呼叫过程中动态建立EPS承载（如Solution #8），那么这部分的时延也必须计算在内。

ETepsDelay [s] ≈ ( SsignallingEPS [bits] + Sepstheader [bits] ) / Rtransmission [bps] * 3 + Dpropagation × (NUL-EPS + NDL-EPS) [s]

• 公式结构: 与ETimsDelay的计算方法完全相同。
• 参数区别:
  • SsignallingEPS: 指的是EPS承载管理信令的尺寸（如Activate Dedicated Bearer Request的RRC部分）。
  • NUL-EPS, NDL-EPS: 指的是承载建立流程中的上下行EPS信令消息数量。

附录A.2的Table A.2-2给出了一个典型的EPS信令交互（RRC Reconfiguration）的示例尺寸和传输延迟，为计算ETepsDelay提供了基准数据。

4. 状态转换时延 (ETstateTransition) 的估算 (A.1.4)

Editor’s note: The formula for calculating estimated time for state transition from RRC-IDLE to RRC-CONNECTED and estimated time for paging MT UE is FFS.

• FFS (For Further Study): 在V1.0.0版本中，这部分的具体计算公式还是一个“待研究”项。
• 实际估算: 尽管没有统一公式，但在评估时，通常会将其估算为一次Service Request流程（MO呼叫）或一次Paging + Service Request流程（MT呼叫）的总时延。这至少包含一次上行传输和一次下行传输的传播和传输时延。例如，一个简化的估算可以是 (上行SR传输时延 + 下行响应传输时延) + 2 * Dpropagation。

5. 附录中的基准数据：A.2 & A.3

附录A的后两节，为上述公式提供了宝贵的基准数据 (Baseline Data)，它们是进行实际计算的基础。

• A.2 Example for SIP messages:

  • Figure A.2-1: 展示了一个非常标准的、带Precondition的IMS呼叫流程，作为“原始”流程的参照。
  • Table A.2-1: 详细列出了这个标准流程中，每一个SIP消息（INVITE, 183, PRACK等）的典型尺寸（字节）。例如，一个标准的INVITE消息尺寸被估算为2564 (+52)字节。
  • 这些数据，构成了我们评估Solution 15等信令简化方案时，计算“压缩率”的基准。

• A.3 Example for I1 messages:

  • Figure A.3-1 & A.3-2: 展示了基于I1协议的MO和MT呼叫流程。
  • Table A.3-1: 列出了I1消息的典型尺寸。例如，一个I1 INVITE消息只有36字节！
  • 这些数据，为我们评估Solution #4, 20等二进制方案的巨大优势，提供了直接的量化证据。36字节 vs 2564字节，这就是“二进制革命”的力量。

6. 结论：从抽象到具体的桥梁

Alex最后对附录A进行了总结：“附录A是这份TR的‘度量衡’。它将所有天马行空的解决方案，都拉到了一个统一的、可量化的评估平台上。它虽然没有告诉我们哪个方案最好，但它给了我们一把尺子，让我们自己去‘丈量’。”

“它的核心贡献在于：”

• “提供了一套标准化的评估框架： 将CST分解为状态转换、IMS信令、EPS信令和地面网络四大模块，使得分析过程清晰、系统。”
• “给出了可操作的计算公式： 详细定义了如何将消息尺寸、数量、带宽、传播延迟等参数，综合计算为最终的信令时延，使得评估过程可复现、可比较。”
• “提供了宝贵的基准数据： 它给出的标准SIP消息和I1消息的尺寸，是所有性能评估工作的起点和参照系。”

“对于我们工程师来说，熟练掌握附录A的方法论，意味着我们具备了独立评估和设计星地融合通信方案性能的能力。当我们面对一个新的优化想法时，我们不再只能说‘我觉得它会更快’，而是可以拿起这把‘尺子’，通过科学的计算，精确地告诉别人‘在1.5kbps带宽下，我的方案可以将呼叫建立时间从12.3秒优化到9.7秒’。这，就是从‘艺术’到‘工程’的飞跃。”

至此，我们对TR 23.700-19的核心技术内容的解读已全部完成。从挑战到方案，再到评估方法论，我们已经构建起了一幅完整的知识图谱。

---

FAQ

Q1：附录A中的计算公式是否考虑了所有现实世界中的复杂情况？ A1：没有。规范明确指出，这些公式是基于理想无线环境的，例如没有重传、没有分片等。现实世界中的无线链路是不稳定的，尤其是在卫星通信中，天气、遮挡等都可能导致丢包和重传，这将显著增加实际的呼叫建立时间。因此，附录A提供的ECST（估算呼叫建立时间）应该被看作是理论性能的下限或最佳情况下的性能基准，实际商用系统的性能通常会比这个值要差。

Q2：公式中针对上行传输的“乘以3”这个修正常数，背后的具体原理是什么？ A2：这个“乘以3”是为了模拟NB-IoT中一次上行数据传输的基本资源请求流程。在NB-IoT的连接态，当UE有数据要发送时，它不能直接发送，而是需要先向eNB请求上行资源。这个过程简化来看包含三个步骤：1) UE发送调度请求 (SR - Scheduling Request) 到上行控制信道。2) eNB在下行控制信道上响应，分配上行资源 (UL Grant)。3) UE在获得授权的上行数据信道 (PUSCH) 上，发送真正的数据包。这三个步骤构成了一次完整的“请求-授权-发送”交互。因此，附录A为了简化模型，将一次上行传输的总时间，粗略地估算为单纯数据传输时间的三倍，以计入资源请求带来的额外开销。

Q3：为什么地面网络时延ETterr被估算为2.5秒？这个数值是如何得来的？ A3：这个数值是基于地面VoLTE网络的经验值得出的一个工程估算。规范中提到，一次完整的端到端VoLTE呼叫（从主叫到被叫），其在核心网和对端网络中的总处理时延经验值约为4-5秒。在一个卫星到地面的呼叫中，只有被叫侧是纯地面网络。因此，附录A简单地取了总时延的一半，即2.5秒，来代表信令在地面段的平均旅行时间。这是一个为了简化计算而设定的基准值，实际值会因不同运营商的网络架构和负载而异。

Q4：附录A的方法论对于LEO（低轨）卫星通信的评估是否也适用？ A4：框架适用，但参数需要修改。附录A的计算框架（CST = 状态转换 + IMS时延 + EPS时延 + …）是通用的。但是，当用于评估LEO场景时，其中的关键参数必须被替换：

• Dpropagation (传播延迟): LEO卫星的传播延迟要小得多，通常在几毫秒到几十毫毫秒之间，并且是动态变化的。需要使用一个更复杂的、与卫星轨道相关的动态时延模型。
• 状态转换时间: LEO卫星的高速移动，可能导致更频繁的切换和更复杂的IDLE态唤醒流程（如需要先确定服务卫星），ETstateTransition的计算会更复杂。
• 上行传输修正系数: 如果LEO系统采用了更高效的上行资源调度机制，那个“乘以3”的系数也可能需要调整。 因此，可以直接借鉴附录A的思想，但必须为其“换上一套LEO的参数表”。

Q5：作为方案设计者，我如何利用附录A来证明我的新方案是优秀的？ A5：可以遵循以下步骤：

1. 明确优化点： 首先明确你的新方案主要优化了哪个或哪些部分。是减少了SIP消息的尺寸(SsignallingIMS)？还是减少了信令交互的次数(NUL-IMS/NDL-IMS)？还是避免了动态承载建立（使ETepsDelay=0）？
2. 量化参数变化： 参照附录中的基准数据，计算出你的方案实施后，上述参数具体会变成多少。例如，通过分析，得出你的方案可以将INVITE从2564字节减少到800字节。
3. 代入公式计算： 将新的参数值，连同附录A给出的其他基准参数（如Dpropagation=0.28s, 带宽=1kbps等），代入ECST的计算公式中。
4. 对比与展示： 计算出“原始方案”和“你的新方案”的ECST，并清晰地展示你的方案带来了多少秒（或百分之多少）的性能提升。通过这种方式，你的方案的优势就从一个定性的描述，变成了一个可信的、可比较的量化结论。