51学通信

深度解析 3GPP TR 23.700-01：4.1 关键问题#1：卫星接入特性的应用使能

27分钟阅读

好的，我们马上开始对规范的逐章深度拆解。

深度解析 3GPP TR 23.700-01：4.1 关键问题#1：卫星接入特性的应用使能

本文技术原理深度参考了3GPP TR 23.700-01 V19.0.0 (2024-09) Release 19规范中，关于“4.1 Key issue #1: Usage of satellite access characteristics for the application enablement”的核心章节，旨在为读者提供一个关于应用层如何感知并利用卫星网络特性的全景视图。本文将首先对规范的第1、2、3章进行简要概述，为后续的深度解析奠定基础。

前言：从“连接”到“感知”

在上一篇全景解读中，我们跟随环境科学家阿里斯博士进入了亚马逊雨林，了解了3GPP为打通5G天地一体化网络在应用层面的“任督二脉”所做的宏伟研究。我们知道了，让设备简单地“连上”卫星只是第一步，真正的挑战在于如何让上层应用能够“看懂”和“听懂”卫星这条特殊的“路”，并智能地调整自己的“驾驶”行为。

从本篇文章开始，我们将严格按照规范的章节顺序，逐一“解剖”其中的技术细节。我们将首先快速浏览作为基础的第1至3章，它们定义了研究的边界、引用的文献和专业术语。随后，我们将正式进入规范的灵魂——第4章“关键问题（Key Issues）”的第一个核心议题（KI#1）：应用使能如何利用卫星接入特性。

这个问题是所有后续讨论的基石。如果应用对网络环境一无所知，那么所谓的“智能协同”就无从谈起。让我们继续跟随阿里斯博士的脚步，看看他的团队在雨林中部署的复杂应用生态，是如何迫切需要解决这个从“连接”到“感知”的根本性问题的。

1. 奠定基础：Scope, References & Definitions (第1-3章速览)

在建造任何宏伟大厦之前，都必须先明确图纸、备好料、统一单位。规范的第1、2、3章扮演的正是这样的角色。

  • 第1章：Scope (范围) 本章明确了这份技术报告（TR）的研究边界。它开宗明义地指出，这是一份“研究（Study）”，而非一份“标准（Specification）”。其核心任务是识别在卫星接入场景下，应用使能所需的架构需求，并探索相应的解决方案。这为我们阅读全文定下了基调：我们在看的是一份探索性的、充满可能性分析的文档，而非一份板上钉钉的技术法规。

  • 第2章：References (参考文献) 这一章是知识的“索引”，列出了本报告所依赖和引用的所有其他3GPP及外部规范。对于技术专家而言，这是一个宝藏。例如，它引用了TS 22.261（业务需求）、TS 23.501（5G系统架构）、TS 23.558（边缘计算架构）和TS 23.434（SEAL架构）等。这告诉我们，卫星应用使能并非空中楼阁，而是紧密地构建在现有的5G业务、架构和能力之上的演进。

  • 第3章：Definitions of terms, symbols and abbreviations (定义、符号和缩略语) 本章是全文的“通用语言词典”。它确保了所有参与者在讨论NTN（非地面网络）、SEAL（服务使能架构层）、EDGEAPP（边缘应用）、EAS（边缘应用服务器）等术语时，拥有完全一致的理解。对于初学者来说，在阅读后续章节时，频繁地回顾本章是扫清理解障碍的最佳途径。

对这三章的简述之后，我们已经做好了充分的准备，可以正式深入到第一个实质性的技术挑战中。

2. 关键问题#1：应用如何“看懂”卫星网络？(4.1)

想象一下，你是一位经验丰富的司机，但现在被蒙上双眼，让你在一条你完全陌生的道路上开车。你不知道路是宽是窄，是高速公路还是崎岖山路，甚至不知道下一个路口是红灯还是绿灯。你的驾驶体验无疑将是灾难性的。

当前，绝大多数移动应用在面对网络时，就是这位“被蒙上双眼的司机”。它们不知道自己跑在低延迟的光纤上，还是高延迟的卫星链路上。KI#1要解决的，就是如何为应用“摘掉眼罩”，让它清晰地“看到”自己脚下的路况。

2.1 问题描述 (4.1.1 Description)

让我们先来看规范原文如何描述这个问题：

3GPP SA1 has specified the service requirements for 5G for satellite access in 3GPP TS 22.261 which including supporting 5G system with satellite access, suitable QoS parameters for traffic over a satellite backhaul, etc. And 3GPP SA2 has also specified the architecture and solutions in Rel-17 and Rel-18 to support these services requirements identified in SA1.

Service enablers defined by SA6 should also considering to take advantage of the output from SA1 and SA2 to ensure that application enablers support the satellite access, and should utilize the satellite access characteristics (e.g. QoS parameters for traffic over a satellite access) to optimise application layer enablement behaviour to provide a better service experience. Also investigate the need of any new analytics related to satellite access characteristics that need to be supported as part of the ADAE service (3GPP TS 23.436) which can be utilized by the application servers and application enablement layers in order to provide a better service experience over satellite access.

深度解析：

这段描述传递了三个核心思想：

  1. 基础已存在：SA1（业务需求组）和SA2（架构组）已经为5G支持卫星接入做了大量工作，定义了需求和基础架构。例如，网络内部已经能够识别出这是一条卫星链路，并为其分配合适的QoS参数。
  2. SA6的任务是“桥梁”：SA6（应用使能组）的责任是利用这些底层网络已经具备的信息和能力，并将它们有效地传递给上层应用。这个“利用”和“传递”的过程，就是应用使能。
  3. 优化的目标：最终目标是让应用能够根据获取到的卫星特性，优化自身的行为（optimise application layer enablement behaviour），从而在卫星这种特殊环境下，提供更好的用户体验。
  4. 引入“分析”：规范还更进一步，提出要研究是否需要引入新的“分析（analytics）”能力，即ADAE（应用数据分析使能）。这暗示了不仅要告知“现状”，更要提供“预测”。

阿里斯博士的场景再现：

阿里斯博士的团队开发了一个名为“雨林之声（Rainforest Echo）”的应用，用于远程操控无人机。这个应用有两个核心功能模块：

  • “鹰眼”模块：控制一架搭载高清摄像头的无人机，对特定区域进行精细勘测，需要实时回传高清视频流，对带宽和延迟非常敏感。
  • “信使”模块：控制一架长航时无人机，它飞往各个传感器节点，通过短距离无线方式收集数据，然后将汇总的数据包传回总部。这个过程对实时性要求不高，但要求连接稳定可靠，能一次性传输较大的数据块。

在地面网络环境下，这两个模块可以随时按需启动。但在卫星环境下，问题来了。如果博士的团队在只有一个高延迟、窄带宽的GEO卫星链路可用时，冒然启动“鹰眼”模块，结果将是视频流卡顿、丢帧严重，无人机因为控制指令延迟而飞行不稳，任务彻底失败。反之，如果有一条宝贵的低延迟、高带宽的LEO卫星过境窗口，却只用来跑“信使”任务，那就是对稀缺资源的巨大浪费。

这里的核心矛盾是：应用的行为模式（启动“鹰眼”还是“信使”）与其所处的网络环境特性严重不匹配。 KI#1要解决的，就是打破这种不匹配。

2.2 待解的开放性问题 (4.1.2 Open issues)

为了解决上述问题，规范在4.1.2节中提出了三个需要深入研究的开放性问题。这三个问题层层递进，构成了解决KI#1的完整技术路线图。

开放问题一：哪些特性可以被利用？

  • What are the satellite access characteristics that can be utilized by the application enablers?

深度解析：

这是最基础的问题：我们到底能从网络那里拿到哪些有用的“情报”？这些情报必须是具体、可量化、对应用决策有直接帮助的。我们可以将这些特性分为几类：

  1. 静态/半静态特性 (Static/Semi-static Characteristics):

    • 卫星类型 (Satellite Type): GEO, MEO, LEO。这是最基本的区分，直接决定了延迟和移动性的基准。
    • 轨道信息 (Orbital Information): 对于NGSO卫星，其轨道参数（如星历ephemeris）是可知的，这为预测覆盖窗口奠定了基础。

  2. 动态性能特性 (Dynamic Performance Characteristics):

    • 延迟 (Latency): 单向或往返延迟的估计值。这是应用调整交互模式（实时vs批量）的最重要依据。
    • 抖动 (Jitter): 延迟的变化量。对于视频、语音等实时业务，抖动是关键考量。
    • 可用带宽 (Available Bandwidth): 上下行的预计吞吐率。应用可以据此决定传输数据的清晰度或码率。
    • 误码率/丢包率 (BER/PLR): 链路的可靠性指标。应用可以据此调整纠错编码或重传策略。

  3. 网络服务特性 (Network Service Characteristics):

    • QoS参数 (QoS Parameters): 网络能提供的服务质量等级，如5QI。应用可以申请不同等级的服务。
    • 覆盖状态 (Coverage Status): 当前是否在服务区，以及预计的覆盖中断时间（参考KI#3）。
    • S&F能力 (Store & Forward Capability): 网络是否支持存储转发模式（参考KI#7）。
    • 路径信息 (Path Information): 数据路径是否经过了UE-卫星-UE的直通链路（参考KI#6）。

对于阿里斯博士的“雨林之声”应用，如果能获得这些信息，它就能构建一个决策矩阵：

  • IF (卫星类型=LEO AND 延迟<100ms AND 带宽>50Mbps) THEN (启用“鹰眼”模块，使用UDP传输高清视频流)。
  • IF (卫星类型=GEO AND 延迟>500ms AND 带宽<5Mbps) THEN (禁用“鹰眼”模块，提示用户网络条件不足；“信使”模块切换至TCP协议，并使用数据压缩和断点续传)。

开放问题二：如何利用这些特性？

  • Whether and how to use the satellite access characteristics (e.g., QoS parameters for traffic over a satellite access) to optimise the application enablement behaviour for the existing application enablers.

深度解析：

知道了“有哪些情报”，下一步就是“如何获取和使用这些情报”。应用不可能、也不应该用ping或speedtest这类业余方式去猜测网络参数。必须有一套标准化的、可靠的机制。这里的“how”指向了应用使能平台。

3GPP SA6已经定义了诸如SEAL和EDGEAPP这样的平台。解决方案就是对这些现有平台进行增强，让它们扮演“情报中介”的角色。

实现方式猜想：

  • 订阅/通知模型 (Subscription/Notification): 应用（或应用服务器）向SEAL服务器发起订阅请求，例如：“请在我的网络延迟从‘低’（<100ms）变为‘高’（>500ms）时通知我”。当网络状况变化时，SEAL服务器会向应用发送一个异步通知。这是最高效、最实时的方案。
  • 查询/响应模型 (Query/Response): 应用在需要时，可以主动向SEAL服务器查询当前的网络特性。例如，在启动“鹰眼”任务前，先查询一次“当前可用带宽”。
  • 配置下发 (Configuration Provisioning): 对于一些半静态的信息，如某个地理区域主要由哪种卫星覆盖，网络可以通过SEAL的配置管理功能，提前下发给应用。

通过这些标准化的接口，应用的开发者无需关心底层复杂的网络信令和物理层细节，只需调用简单的API，就能获取到所需的情报，从而将精力聚焦于优化应用逻辑本身。

开放问题三：是否需要新的“分析”能力？

  • Whether and what new analytics required for the satellite access for providing a better service experience by the existing application enablement servers or application servers.

深度解析：

这个问题将“感知”提升到了“预测”的层面。仅仅知道“现在”的路况有时还不够，如果能知道“未来一小时”的路况，应用将能做出更具前瞻性的决策。这就需要引入数据分析和机器学习的能力，也就是规范中提到的ADAE (Application Data Analytics Enablement)。

场景需求： 阿里斯博士的“鹰眼”无人机电池只能维持90分钟。他计划在下午对一个美洲豹巢穴进行一次60分钟的持续空中观测。这次观测至关重要，绝不能因为网络中断而失败。

解决方案：

  • 传统方式 (无分析): 应用只能在起飞前查询一下“当前”网络状况。但也许起飞20分钟后，一颗提供服务的LEO卫星就飞离了服务区，导致任务中断，无人机被迫返航，浪费了宝贵的电池和时间。
  • 引入分析后 (ADAE):
    1. “雨林之声”应用服务器向ADAE服务器发起一个分析请求：“我计划在下午2点到3点，在坐标(X, Y)区域执行一次需要持续60分钟、最低下行带宽20Mbps的无人机任务。请分析该时段内的网络服务质量是否满足要求。”
    2. ADAE服务器会综合多种信息源：
      • 从SEAL获取的卫星轨道信息。
      • 从核心网（如NWDAF）获取的网络历史负荷数据。
      • 天气预报数据（大雨可能影响Ka/Ku波段的信号质量）。
    3. 通过分析模型，ADAE服务器返回一个预测结果：“在下午2:00-2:45，预计带宽可达30Mbps；但在2:45-3:10，由于卫星切换和仰角过低，带宽可能降至10Mbps。建议您将任务调整到下午3:15开始，届时将有另一颗卫星提供持续75分钟的优质覆盖。”

收到这个预测性的“情报”后，阿里斯博士就可以从容地调整计划，确保任务万无一失。这就是“分析”带来的革命性价值——将应用从被动的环境适应者，转变为主动的资源规划者。

3. 总结：开启智能天地的第一把钥匙

“关键问题#1”是整个TR 23.700-01报告的起点和基石。它提出了一个看似简单却极为深刻的议题：如何建立应用层与卫星网络之间的“信息对称”。没有信息的对称，应用就只能盲目地将地面环境下的行为模式照搬到天上，其结果必然是低效、昂贵和不可靠。

通过对三个开放性问题的层层剖析，3GPP为我们描绘了一条清晰的实现路径：

  1. 识别并标准化一系列对应用有价值的“卫星接入特性”。
  2. 增强现有的应用使能平台（如SEAL），使其成为传递这些特性的标准化“信道”。
  3. 引入预测性的分析能力（如ADAE），让应用不仅能“感知现状”，更能“预见未来”。

解决了KI#1，就等于为应用开发者找到了开启智能天地一体化网络大门的第一把钥匙。后续的所有关键问题，无论是星上边缘计算、非连续覆盖下的通信，还是关键任务保障，都将构建在这个坚实的基础之上。

FAQ环节

Q1：什么是“应用使能行为（application enablement behaviour）”？能否举一个例子？ A1：“应用使能行为”指的是应用层软件（App或服务器）根据从网络获取的信息，来自主调整其工作方式的行为。一个很好的例子是视频应用的码率自适应（Adaptive Bitrate Streaming）。在地面网络，它根据探测到的带宽来调整视频清晰度。在卫星场景下，这种行为可以被“优化”：应用不仅看当前带宽，还从SEAL处获取到“预计15分钟后将进入高带宽LEO覆盖窗口”的信息，于是它可能选择先以较低码率播放，同时在后台预先下载高清片段，以在覆盖窗口到来时提供无缝、高质量的观看体验。这种基于网络预测的调整，就是一种被优化的“应用使能行为”。

Q2：为什么不能让App自己去探测网络特性，比如用ping测延迟，而是要由网络来提供？ A2：让App自己探测有几个重大缺陷：1) 不准确和不全面：ping只能测往返延迟，无法得知卫星类型、抖动、误码率等丰富信息。2) 消耗资源：在卫星这种功耗和带宽都受限的环境下，频繁的探测本身就是一种资源浪费。3) 无预测能力：App只能探测“此时此刻”，无法知道10分钟后网络会怎样，而卫星网络的动态变化恰恰需要预测能力。4. 非标准化：每个App都用自己的方法去测，结果千差万别，无法形成统一、可靠的开发生态。因此，由网络通过标准化的应用使能接口来提供权威、全面、且包含预测性的信息，是唯一高效可靠的途径。

Q3：规范提到的ADAE（应用数据分析使能）和NWDAF（网络数据分析功能）有什么关系？ A3：这是一个很好的问题，涉及到5G架构的细节。NWDAF是5G核心网内部的网络功能（NF），它主要负责收集和分析网络自身的数据（如移动性、负载、服务质量等），为网络内部的优化（如策略控制、资源管理）提供决策支持，其服务对象主要是其他核心网NF。而ADAE是SA6定义的、更靠近应用层的功能，它可以被视为一个“对应用开放的分析平台”。ADAE可能会从NWDAF获取网络层面的分析结果作为其输入之一，但它还会结合应用层的信息（如用户行为、业务需求）以及第三方信息（如天气），进行更高维度、更贴近业务需求的分析，并最终将分析结果以简单易懂的方式提供给第三方应用服务器。可以理解为，NWDAF更多是“对内服务”，而ADAE是“对外服务”。

Q4：这些卫星特性信息会不会涉及用户隐私和网络安全问题？ A4：会的。3GPP对此有非常严格的考量。网络向第三方应用暴露任何信息，都必须经过一套完整的授权和认证流程。通常，这会通过5G的NEF（网络能力开放功能）来实现。应用服务器首先需要向运营商注册并获得授权，才能访问特定的API。对于涉及单个用户的信息（如精确位置），还需要获得用户的明确同意。所有的数据传输都会被加密，确保安全。因此，整个信息暴露过程是在一个“零信任”和“最小权限”的安全框架下进行的。

Q5：作为一名应用开发者，我现在应该为迎接卫星互联网做些什么准备？ A5：虽然标准仍在演进，但开发者可以从现在开始培养“网络感知”的设计思维。首先，将应用中与网络交互强相关的部分进行模块化，避免硬编码。其次，在应用逻辑中预留出处理网络特性（如高延迟、连接中断）的分支。例如，设计一套“在线-离线-缓存-同步”的状态机，而不仅仅是简单的“请求-响应”模式。关注3GPP SA6的标准化进展，一旦SEAL等平台的卫星能力API被确定，就可以快速将这些预留的逻辑与标准接口对接，让你的应用在第一时间就能“拥抱星辰大海”。

关系图谱