51学通信

深度解析 3GPP TR 23.700-28：6.17 轨迹的预言 (事件列表覆盖信息)

23分钟阅读

深度解析 3GPP TR 23.700-28：6.17 轨迹的预言 (事件列表覆盖信息)

本文技术原理深度参考了3GPP TR 23.700-28 V18.1.0 (2023-03) Release 18规范中, 关于“第六章 Solutions”的 6.17 节 “Solution #17: Solution with event list coverage information over NAS” 的核心章节, 旨在为读者深度剖析一种将覆盖信息的维度从“静态地图”提升到“动态事件流”的革命性方案, 揭示UE如何通过上报未来轨迹, 从网络换取一份精准、个性化的“覆盖命运剧本”。

在前一篇的探索中, 我们见证了Solution 16如何通过“广义不可用周期”的“请假制度”, 优雅地将UE的自我感知与网络的高级服务相结合。然而, 无论是UE自己“规划日程”, 还是Solution 15中网络下发的“覆盖地图”, 它们所处理的“覆盖信息”, 在本质上, 依然是相对静态和宏观的。

想象一下, 伊芙琳博士的“仿生蜂群”无人机, 它们收到的“覆盖地图”可能是一份覆盖方圆数百平方公里的网格数据。但对于单架无人机而言, 它真正在乎的, 只是其未来飞行轨迹上那“一线天”的信号变化。一份宏观的地图, 对它来说信息冗余度太高, 而且不够精准。

此时, 一个更深层次的问题浮出水面：我们能否将“信息服务”的模式, 从“我给你一张通用地图, 你自己查”, 升级为“你告诉我你要去哪, 我为你写一份专属的行程指南”？

这, 正是Solution #17——“通过NAS传递的事件列表覆盖信息”——所要实现的革命性转变。这个方案的核心, 是将覆盖信息的形态, 从一张静态的、二维的“地图”, 变成了一份动态的、一维的、沿着UE未来轨迹展开的“事件列表（Event List）”。它不再是一个被动的查询工具, 而是一份为UE量身定制的、关于未来连接命运的“预言剧本”。

为了演绎这场从“地图”到“剧本”的升维之旅, 我们的主角“仿生蜂群-01号”无人机, 将在起飞前, 向网络提交一份它未来3小时的飞行计划。网络则会化身为一位全知的“剧作家”, 为它谱写出一段跌宕起伏的“信号传奇”。

1. 核心哲学：从“面”到“线”，信息的升维与聚焦 (解读 6.17.1 Description)

Solution 17的哲学根基, 在于对“信息效率”的极致追求。它认为, 对于一个移动的UE, 最有价值的信息, 不是其周围广阔区域的覆盖情况, 而是其自身未来轨迹上, 覆盖状态将要发生变化的那些关键节点。

6.17.1 Description

This solution proposes that the UE requests, using existing NAS signalling messages, coverage information from the core network, specifying in the request a trajectory or area of geographical evolution (type of shape), as well as a sampling distance and a study time. The core network will return projections of coverage for sampled positions, with corresponding locations, timing elements, and coverage type information, under the form of coverage event list…

这段描述是整个方案的灵魂, 它定义了一种全新的“请求-响应”模型：

  • UE的请求 (Request): 不再是“给我这个区域的地图”, 而是“请帮我分析一下我未来的这段旅程”。这份请求包含了三个核心要素：

    1. 轨迹/区域 (Trajectory or area of evolution): 由一系列未来路径点（经纬度坐标）定义的一条“线”, 或由几个顶点定义的一个“面”（活动区域）。
    2. 采样距离 (Sampling distance): UE希望网络以多高的精度来分析这条轨迹, 例如“每隔1公里采样一次”。
    3. 研究时长 (Study time): UE希望这份“行程指南”能覆盖未来多长的时间, 例如“未来3小时”。

  • 网络的回应 (Response): 不再是一张包含大量0和1的网格地图, 而是一份简洁、高效的“事件列表 (Event List)”。

Figure 6.17.1-1: Illustration of the solution for Type of shape = trajectory 直观地展示了这个过程：UE上报了未来的路径点{P0, P1, P2, P3...}，网络则沿着这条轨迹, 按照UE要求的“采样距离”, 选取了一系列采样点{Q0, Q1, ..., Q6}，并对这些点的未来覆盖状态进行了“预言”。

1.1 “事件列表”：一份UE专属的“命运剧本”

这份“事件列表”到底长什么样？规范中给出的例子, 让我们得以一窥这份“剧本”的精彩片段：

Coverage information returned to the UE in NAS downlink message… will then be the following, under the form of event list:

  • Q0 (POS=LAT, LONG, ALT); GNSS time = T0; EVENT TYPE= COVERAGE LEO; CELL ID =W
  • …
  • Q3 (POS=LAT, LONG, ALT); GNSS time = T1; EVENT TYPE= LOST COVERAGE LEO; CELL ID =X
  • Q4 (POS=LAT, LONG, ALT); GNSS time = T1; EVENT TYPE= LOST COVERAGE LEO; CELL ID =Y
  • Q4 (POS=LAT, LONG, ALT); GNSS time = T2; EVENT TYPE= RECOVER COVERAGE LEO; CELL ID =Z

这份列表, 如同一部电影的分镜头脚本, 清晰地记录了无人机未来旅程中的每一个“关键转折”：

  • 镜头一 (Q0, T0): 在T0时刻, 于Q0点, 你将处于“W”小区的LEO卫星覆盖下。
  • 镜头二 (Q3, T1): 在T1时刻, 当你飞抵Q3点时, 你将失去“X”小区的LEO卫星覆盖。
  • 镜头三 (Q4, T1): 几乎在同一时刻, 当你继续前行到Q4点时, 你也将失去“Y”小区的LEO卫星覆盖。
  • 镜头四 (Q4, T2): 但别担心, 在稍后的T2时刻, 当你仍在Q4点盘旋时, 你将重新获得“Z”小区的LEO卫星覆盖。

这份“剧本”的价值是无可估量的：

  1. 信息密度极高： 它只记录“变化”的事件, 过滤掉了所有“状态不变”的冗余信息。
  2. 高度个性化： 它是为这架无人机的特定轨迹量身定制的。
  3. 多维、丰富： 它不仅告知“有/无”, 还告知了具体的RAT类型 (LEO/MEO/GEO/Terrestrial)、小区ID等丰富信息, 为UE做出更精细的切换或重选决策提供了依据。

1.2 引入“剧作家”：覆盖地图管理网络功能 (CMNF)

谁来谱写这份精妙的“剧本”？Solution 17为5G服务化架构（SBA）引入了一个全新的角色——覆盖地图管理网络功能 (Coverage Map management Network Function, CMNF)。

Figure 6.17.1-3: New Coverage Map Network Function integrated in SBA/SBI 展示了这个新网元的生态位。

  • CMNF的角色： 这是一个专职的、网络级的“首席剧作家”。它通过SBI接口, 与AMF、O&M中心、卫星网络控制中心等所有“信息源”互联, 是全网覆盖信息的汇聚、管理和分析中心。
  • 工作模式：
    • 请求/响应模式： AMF收到UE的“轨迹分析”请求后, 直接将请求转发给CMNF。CMNF完成分析后, 将“事件列表”返回给AMF, AMF再透传给UE。
    • 订阅/通知模式： AMF可以代表UE, 向CMNF“订阅”某条轨迹的覆盖事件。在整个“研究时长”内, 只要CMNF的分析模型发现了任何新的、未预见的覆盖变化（例如, 某颗卫星突然故障）, 它就会主动向AMF推送一份更新后的“剧本”, AMF再通过UE Configuration Update通知UE。这种模式, 实现了对覆盖变化的近乎实时的动态响应。

2. 操作流程：一场UE与网络之间的“头脑风暴” (解读 6.17.2 Procedures)

这套“剧本创作”的流程, 可以在多种NAS信令交互中完成, Figure 6.17.2.1-1: Sequence chart based on registration procedure 以注册流程为例, 揭示了其核心步骤。

场景复现：“仿生蜂群-01号”的任务规划

  1. 步骤 1: UE提交“剧本大纲”

    The UE sends a Registration Request… and includes a list of points, the type of shape, a sampling distance, a study period. 在起飞前的初始注册中, “仿生蜂-01”无人机向AMF提交了它的“剧本大纲”：

    • list of points: 未来3小时的飞行路径关键点坐标。
    • type of shape: trajectory (轨迹)。
    • sampling distance: 500 meters。
    • study period: 3 hours。

  2. 步骤 2: AMF转交“创作任务”

    AMF performs usual procedures… AMF在执行完常规的身份认证等流程后, 将这份“创作任务”转交给了CMNF（或另一个非SBA架构的服务器）。

  3. 步骤 3: CMNF的“奋笔疾书”

    In coordination with a Coverage map server, the AMF determines the list of coverage events for all the positions sampled… CMNF开始工作。它沿着无人机提交的轨迹, 每隔500米取一个采样点, 然后调用其庞大的时空覆盖数据库, 对每一个采样点在未来3小时内的覆盖状态进行“预言”, 并将所有“状态变化”的节点, 整理成一份简洁的“事件列表”。

  4. 步骤 4: AMF回传“最终剧本”

    The coverage event list… is returned. AMF在Registration Accept消息中, 将这份新鲜出炉的、为无人机量身定制的“覆盖命运剧本”, 下发给了它。

  5. 无人机的“依剧本行事”

    Analyses the list and adapt power saving mechanisms, e.g.: setting up ad-hoc parameters, MICO Active time, Periodic registration timer, eDRX… 无人机收到这份“剧本”后, 其任务规划系统和功耗管理系统如获至宝。它可以：

    • 优化任务： 将需要稳定回传高清视频的“精细扫描”任务, 全部安排在剧本中标注的“COVERAGE LEO”时段。
    • 精准节电： 对于剧本中标注的“LOST COVERAGE LEO”时段, 它可以提前与网络协商好PSM或广义不可用周期, 进入深度休眠。
    • 预判切换： 当剧本显示它将从“CELL ID = X”的小区, 飞入“CELL ID = Z”的小区时, 它可以提前做好切换的准备。

3. 系统影响分析：一次全方位的“智慧”升级 (解读 6.17.3 Impacts)

UE:

  • Determines its future trajectory or evolution zone…
  • Determines the sample distance…
  • Using NAS, send to AMF/MME above elements and retrieve coverage information event list.
  • Analyses the list and adapt power saving mechanisms…

UE的影响： 需要从一个简单的“执行者”, 升级为**“规划师”与“分析师”**。它需要具备规划未来轨迹、并将网络返回的“剧本”转化为具体行动的能力。

AMF/MME:

  • Act as interface between UE and server/CMNF
  • (for CMNF) subscribe for notifications, according configuration.

AMF/MME的影响： 角色被重新定位为**“智能网关”和“订阅代理”**。它不再需要自己进行复杂的计算, 而是扮演着UE请求与后台分析服务之间的桥梁。

Server/CMNF:

  • Receive a request for coverage data from AMF/MME.
  • Perform Sampling and determination on the coverage info event list…
  • (for CMNF) perform regular evaluation… generates a notification… if new event is detected.

CMNF的影响： 这是新增的核心大脑。它承担了所有的复杂计算和动态维护工作, 是整个方案的“智慧引擎”。

4. 方案评估：信息服务的“终极形态” (解读 6.17.4 Solution evaluation)

6.17.4 Solution evaluation

The solution proposes an alternative way to provide accurate coverage information to the UE… Using event list to describe future coverage information has several advantages compared to provision of satellite orbital data using SIB:

  • A UE is not required to perform any complex calculation…
  • The coverage events are managed in real time based on satellite operator knowledge… and by the way is more reliable and complete…
  • The coverage events can be provided for terrestrial RATs as well as satellite RATs…

评估部分高度赞扬了“事件列表”模型相较于传统方法的革命性优势：

  1. UE零计算： 彻底将终端从复杂的轨道计算中解放出来。
  2. 极致的准确与完整： 由掌握全局信息的“专家”（CMNF）实时生成, 可靠性最高。
  3. 跨RAT通用性： 同一套“剧本”中, 可以无缝地包含“失去LEO覆盖”、“获得地面5G覆盖”等混合事件, 为未来的空地一体化网络协同, 奠定了信息基础。
  4. 架构优势： CMNF的引入, 使得覆盖信息的管理和分发变得标准化、中心化, 便于未来的升级和扩展（如用于PWS公共预警、切片策略等）。

总结：从“被动感知”到“主动规划”的飞跃

Solution 17以其“事件列表”的创新理念, 将5G NTN的信息服务水平, 推向了一个前所未有的新高度。它彻底改变了UE与网络在覆盖信息上的交互模式, 从过去UE被动地接收广播、盲人摸象般地“感知”世界, 进化到了UE主动地提交规划、并从网络获取一份关于未来的、个性化的“确定性”剧本。

“仿生蜂群-01号”无人机与CMNF这位“剧作家”的精彩互动, 正是这场从“被动感知”到“主动规划”的伟大飞跃的生动写照。这份“命运剧本”, 不仅赋予了无人机精准规避“信号风暴”的能力, 更使其自身的任务执行与能源管理, 达到了一种前所未有的智能化水平。

然而, 这份“剧本”的创作, 依赖于UE能够提供一份清晰的“大纲”——未来的轨迹。这对于按计划行事的无人机来说轻而易举, 但对于移动完全随机的个人终端, 或是那些业务延迟要求极高的场景, 这套流程可能显得过于“重”。

在某些情况下, 我们需要的可能不是一份详尽的未来剧本, 而是一个简单的、关于当前“可容忍的最大延迟”的承诺。如何将应用层的业务需求, 转化为网络可以理解并执行的移动性策略？这, 正是我们将要在下一篇文章中探讨的Solution #18——“AF影响的周期性注册”。一场关于业务需求与网络参数的直接“对话”, 即将上演。

FAQ

Q1：Solution 17和Solution #15（提供覆盖地图）有什么本质区别？ A1：本质区别在于信息的“维度”和“焦点”。Solution 15提供的是一份**“面”的信息——一个地理区域在未来不同时间点的覆盖情况, UE需要自己去“查”。而Solution 17提供的是一份沿着UE未来轨迹的“线”的信息, 它只包含这条“线”上覆盖状态发生“变化”**的关键事件, 信息更聚焦、更个性化。可以说, Solution 15是“通用地图”, 而Solution 17是“专属导航路线”。

Q2：如果UE的实际轨迹偏离了它上报给网络的计划, 会发生什么？ A2：网络提供的“事件列表”将失效, 因为它是严格基于UE提交的轨迹计算的。如果无人机临时改变航线, 它之前收到的那份“剧本”就不再具有指导意义。在这种情况下, UE需要立即向网络发起一次新的请求, 提交其更新后的轨迹, 以获取一份新的“剧本”。如果网络支持订阅/通知模式, 并且能够通过其他方式（如NWDAF的位置分析）感知到UE偏离了轨迹, 它也可能主动撤销旧的订阅, 并提示UE需要重新规划。

Q3：CMNF这个新的网络功能, 会不会让5G核心网变得更臃肿？ A3：恰恰相反, 这是5G服务化架构（SBA）思想的体现, 它会让核心网变得更清晰、更灵活。在没有CMNF的架构中, “覆盖信息管理”这个复杂的职责, 可能会被分散地、重复地实现在多个AMF实例中, 造成功能冗余和管理困难。而CMNF的出现, 将这个“通用能力”抽取出来, 形成一个独立的、标准化的微服务。任何需要这项服务的NF（如AMF）, 都可以通过标准API来调用它。这使得系统架构更解耦、更易于维护和独立升级。

Q4：这个方案看起来非常强大, 它是否能完全取代前面讨论过的其他功耗节省方案？ A4：不能完全取代。它是一个信息赋能方案, 而非一个具体的功耗节省执行方案。它为UE提供了做出更优决策所需的输入, 但UE如何利用这份“剧本”去执行具体的节电动作（例如, 是选择PSM, 还是上报广义不可用周期）, 仍然需要依赖像Solution 3或Solution 16这样的执行方案。可以说, Solution 17是“大脑”和“眼睛”, 而其他方案是“手”和“脚”。

Q5：UE提交的“轨迹”信息, 是否会引发用户隐私方面的担忧？ A5：是的, 这是一个非常重要的问题。UE向网络上报其详细的未来行动轨迹, 确实涉及到敏感的用户隐私。3GPP对此有严格的安全和隐私保护框架。首先, 所有的NAS信令都是经过加密的。其次, 这项功能很可能是一种需要用户**明确授权（opt-in）**的服务。再者, 网络对这些轨迹数据的使用, 必须严格限定在“提供覆盖信息”这一目的上, 并接受法律和监管的约束。对于企业级应用（如无人机蜂群管理）, 企业客户通常会与运营商签订专门的数据使用协议, 来合法合规地利用这些轨迹信息。

关系图谱