51学通信

深度解析 3GPP TR 23.700-01：卫星通信与5G应用使能的融合之路 (全景解读)

37分钟阅读

深度解析 3GPP TR 23.700-01：卫星通信与5G应用使能的融合之路 (全景解读)

本文技术原理深度参考了3GPP TR 23.700-01 V19.0.0 (2024-09) Release 19规范，旨在为读者提供一个关于“5G卫星接入应用使能（Application Enablement for Satellite Access）”研究项目的全景视图，揭示天地一体化网络如何从概念走向现实。

引言：当5G仰望星辰

5G的宏伟蓝图，早已不止于地面。为了实现“万物互联”的终极愿景，移动通信的边界必须突破地平线，向广阔的太空延伸。非地面网络（NTN, Non-Terrestrial Networks），特别是卫星通信，正成为5G演进不可或缺的一环，它承诺为海洋、沙漠、深山、天空乃至灾区等地面网络难以覆盖的区域，提供无处不在的连接。

然而，将应用和服务从成熟的地面5G网络无缝迁移到卫星网络，面临着巨大挑战。卫星链路固有的高延迟、动态变化的网络拓扑、以及可能出现的“非连续覆盖”，都与地面网络的设计假设大相径庭。一个在城市中运行流畅的App，在卫星环境下可能会变得迟钝、低效甚至完全不可用。

为了弥合这一鸿沟，3GPP SA6（业务与系统应用层）工作组启动了FS_5GSAT_Ph3_APP研究项目，其成果凝聚于技术报告 TR 23.700-01。这份报告并非一部硬性的技术标准（TS），而是一份探索性的研究报告（TR），它系统性地识别了“应用使能”在卫星接入场景下面临的关键问题（Key Issues），并对潜在的解决方案进行了深入研究与评估。

本文将为您全面解读这份重要的技术报告，我们将跟随一位虚构的环境科学家——“阿里斯博士（Dr. Aris）” 的脚步，深入他位于亚马逊雨林深处的“盖亚之眼”科考项目。阿里斯博士需要部署大量环境传感器、利用无人机和高清摄像头追踪珍稀物种，并与远在千里之外的总部保持关键任务通信。他的项目完美复现了TR 23.700-01所要解决的全部挑战。让我们跟随他，一同探索5G与卫星融合的未来。

1. 报告的使命与范畴：为应用开发者架设通往太空的桥梁

在深入技术细节之前，我们首先要理解这份报告的核心目标。

The present document is a technical report capturing the study on application enablement for Satellite access enabled 5G Services over 3GPP networks. The aspects of the study include identifying architecture requirements, supporting architecture for satellite access enabled 3GPP services and application enablers (either by defining new functional model or by enhancing existing functional model), and corresponding solutions.

这段来自规范第1章“Scope”的原文精准地概括了报告的全部工作：

  1. 研究对象：为通过卫星接入的5G服务提供“应用使能”。
  2. 研究内容：识别架构需求、研究支持性架构（通过新建或增强现有功能模型）、并提出相应解决方案。

深度解析：

“应用使能（Application Enablement）”是这里的关键词。它不是指让UE（用户设备）简单地“连接”到卫星，这个任务由RAN（无线接入网）和核心网团队完成。SA6关注的是更高层的问题：网络如何将卫星环境的特殊“属性”和“能力”以一种标准化的方式暴露给上层应用（APP）或应用服务器（AS），从而让APP能够“感知”到自己正处于卫星环境中，并做出智能化的、最优的行为调整。

让我们回到阿里斯博士的“盖亚之眼”项目。他的团队开发了一套复杂的生态数据同步应用。在城市实验室里，这个应用通过5G网络可以实时上传高清视频和海量传感器数据。但现在，他面临的问题是：

  • 高延迟：数据从雨林的传感器经由GEO（地球静止轨道）卫星传回总部，单程延迟就可能高达280毫秒。他的应用如果还按照地面网络的低延迟假设进行频繁的“请求-响应”式交互，通信效率将极其低下。
  • 非连续覆盖：为了节省成本和获取更低延迟，他部分采用了LEO（低地球轨道）卫星星座。但星座目前还不够密集，导致每天总有几个小时，特定的传感器节点上空没有卫星飞过，这就是“非连续覆盖”。如果他的应用在这期间盲目地尝试发送数据，只会造成设备电量浪费和数据丢失。
  • 带宽受限：卫星链路的带宽远比地面光纤珍贵。将所有原始高清视频传回总部进行分析，不仅成本高昂，也可能堵塞整个链路，影响更重要的紧急通信。

TR 23.700-01的使命，就是研究如何让5G系统帮助阿里斯博士的应用解决这些问题。比如，5G网络能否主动告知APP：“你现在正通过GEO卫星连接，预计往返延迟560毫秒”？或者，“未来3小时内你将没有网络覆盖，下一次覆盖窗口将在下午2点开启，持续15分钟”？再或者，“在卫星上部署一个边缘计算节点，可以直接在太空对你的视频进行AI分析，只传回结果”？

这些“告知”和“能力开放”的机制，就是“应用使能”的核心。这份报告正是对实现这些机制所需的技术路径进行全面摸底和可行性分析。

2. 八大关键挑战（Key Issues）：卫星应用使能的核心难题

报告的第4章“Key Issues”是全文的灵魂，它精准地剖析了卫星接入给应用层带来的八大核心挑战。这八个KI构成了后续所有解决方案的靶点。

2.1 KI #1: 卫星接入特性的利用 (Usage of satellite access characteristics)

这是最基础也是最核心的问题：应用层如何获知并利用卫星接入的独有特性？

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.

深度解析：

规范指出，SA6定义的应用使能层（例如SEAL、EDGEAPP）应该利用底层网络（由SA1定义需求，SA2设计架构）提供的信息。这些信息包括但不限于：卫星类型（GEO/MEO/LEO）、预计延迟、可用带宽、QoS参数等。

在阿里斯博士的场景中，这意味着：

  • 智能数据同步：他的数据同步应用，通过网络暴露的API得知当前连接的是高延迟GEO卫星时，会自动切换到“批量打包上传”模式，减少握手次数。当连接切换到低延迟LEO卫星时，则可能切换回更具交互性的模式。
  • QoS感知：当博士需要发送一份紧急的医疗求助邮件时，应用可以向网络申请更高的QoS等级，确保这条“救命”信息在宝贵的卫星带宽中得到优先传输。

这个KI的本质是建立一条从网络层到应用层的“信息通道”，打破应用对网络环境的“盲视”。

2.2 KI #2 & KI #5: 卫星边缘计算 (Edge computing on satellite)

KI#2 和 KI#5 都聚焦于边缘计算，但侧重点不同。KI#2 关注GEO卫星上的边缘计算，而KI#5 关注更复杂的NGSO（非对地静止轨道，如LEO、MEO）卫星上的边缘计算。

UPF and Edge in the backhaul part of a 5GS (i.e. on board a GEO satellite) facilitates reduction of latency and faster service provisioning to end users… explore whether EDGEAPP enhancements could reduce latency in cases when Edge has been placed on board GEO satellite.

深度解析：

这是解决卫星高延迟和带宽瓶颈的“杀手锏”。与其将所有原始数据都“愚笨”地传回地面，不如在离数据源最近的地方——卫星上，部署计算能力。

  • 场景痛点：阿里斯博士在雨林里部署了上百个高清摄像头陷阱，用于拍摄美洲豹。每个摄像头每天产生几十GB的视频数据。如果全部传回总部，将是天文数字的成本和时间。
  • 边缘计算解决方案：在为该区域提供服务的卫星上，部署一个边缘应用服务器（EAS）。这个EAS上运行着一个AI图像识别模型。摄像头陷阱拍摄的视频流不再直接传回地面，而是先上传到这颗卫星上。卫星上的AI模型实时分析视频，当且仅当识别出美洲豹时，才将这段几分钟的关键视频剪辑和告警信息传回地面总部。99%的空镜头（风吹草动、其他小动物）数据都不会占用宝贵的星地链路。
  • KI#5的复杂性：对于移动的NGSO卫星，挑战更大。卫星本身在高速移动，上面的EAS也在移动。阿里斯博士的无人机在追踪一只迁徙中的金刚鹦鹉，无人机本身在移动，提供服务的LEO卫星在移动，卫星上的EAS也在移动。如何保证无人机与EAS之间服务的连续性？如何进行高效的服务发现和切换？这正是KI#5需要研究的难题。

2.3 KI #3: 非连续覆盖下的卫星接入 (Satellite access with discontinuous coverage)

这是物联网（IoT）和广域传感场景下的一个致命问题。

In a network with satellite access, a UE may experience a situation of discontinuous coverage, due to e.g., a sparse NGSO satellite constellation deployment… Supplying information on the discontinuous coverage pattern or related services to the application layer will help applications to design themselves for handling discontinuity accordingly.

深度解析：

规范中引用了一张非常形象的图（Figure 4.3.1-1: Flyovers and duration of visibility…），展示了在某个地面位置，一颗LEO卫星一天内只有少数几个时间窗口是可见的，每次可见时长仅几分钟到十几分钟不等。

  • 阿里斯博士的困境：他部署在雨林深处的土壤温湿度传感器，使用的是低功耗的NB-IoT技术，通过LEO卫星回传数据。这些传感器需要尽可能地省电。如果在没有卫星覆盖的时候频繁唤醒并尝试发送数据，电池很快就会耗尽。
  • 应用使能的价值：5G网络（通过SEAL等应用使能平台）可以将“卫星过境信息”或更直接的“UE不可用时段信息（UE unavailability period）”提供给传感器上的应用或其后端的应用服务器。
    • 对于传感器端：APP可以设置一个定时器，只在预知的卫星过境窗口期前唤醒，进行数据打包和发送，其余时间则进入深度睡眠模式，极大延长了电池寿命。
    • 对于服务器端：总部的应用服务器也收到了来自网络的通知：“预计在接下来的4小时内，无法向雨林的A-01号传感器下发任何指令”。这样，服务器就不会徒劳地尝试连接，并且可以更好地管理下行消息队列。

2.4 KI #7: 存储转发（S&F）事件信息的利用 (Usage of S&F events information)

这个KI与KI#3紧密相关，是解决非连续覆盖的一种重要网络能力。

When a UE registers to the network in S&F mode and is available to send/receive data on specific occasions only (e.g. when satellites fly-over and later connect to ground station), AF can leverage S&F events information.

深度解析：

S&F（Store and Forward）即存储转发，是卫星物联网的核心技术。当UE（传感器）有数据要发送，但没有可用的卫星-地面链路时，数据可以先上传到卫星上存储起来。等到卫星飞到地面站覆盖范围时，再将存储的数据转发下去。

  • 应用层的需求：阿里斯博士的应用服务器向传感器发送了一条配置更新指令。网络侧执行了S&F操作。应用服务器最关心的问题是：这条指令发出去了吗？什么时候能送达？我是否需要调整重传计时器？
  • S&F事件：KI#7研究的就是网络应该向应用层暴露哪些S&F相关的“事件”。报告中提到了几个关键事件：
    • Registration in S&F Mode：UE已进入S&F模式。
    • Feeder Link Available：卫星到地面的馈线链路可用了（意味着数据可以开始转发了）。
    • Expected Delivery/Delay Time：预计的消息送达时间。

通过订阅这些事件，阿里斯博士的服务器可以获得近乎实时的状态更新，从而实现更智能、更可靠的应用层逻辑，例如动态调整应用层ACK的超时时间，或者在得知馈线链路可用后，主动推送一批高优先级数据。

2.5 KI #4 & KI #8: 关键任务（MC）业务的支持 (Support for MC services)

关键任务通信是卫星应用的另一大重要场景，尤其是应急救援。

To ensure reliable MC services with larger coverage area, MC systems can benefit from satellite access… it should be considered that it is likely that Mission Critical group communication KPIs may be impacted for all participants if one participant is connected via Satellite access.

深度解析：

  • 场景需求：阿里斯博士的一名队员在野外考察时被毒蛇咬伤，情况危急。博士立刻通过卫星电话发起了一个MCPTT（关键任务一键通）群组呼叫，呼叫组里包括了雨林营地的留守医生、负责联络救援直升机的后勤人员、以及远在总部的医疗专家。
  • KI#4的挑战：卫星链路的长延迟，对于要求“毫秒级”响应的MCPTT来说是巨大的考验。例如，规范要求“口到耳延迟（Mouth-to-ear latency）”应小于300毫秒，而GEO卫星的单向延迟就已经逼近这个极限。如何在这种极端条件下，依然保障MC业务的基本可用性和可靠性？
  • KI#8的挑战：这是一个更微妙的问题。假设群组呼叫中，博士和营地医生是通过地面网络连接，延迟很低。但救援直升机飞行员是通过卫星接入的。当飞行员按下PTT键讲话时，他的声音会因为卫星延迟，比其他人晚半秒多才被听到。这会严重破坏通话节奏，导致抢话、混乱，甚至在争分夺秒的救援指挥中造成误判。KI#8研究的就是，如何让系统和其他参与者“感知”到组内有高延迟成员的存在，并可能在应用层做出相应调整（例如，在UI上提示“XX正在通过卫星发言”，或调整通话权的判决逻辑）。

2.6 KI #6: UE-卫星-UE直接通信 (Support of UE-Satellite-UE communication)

这是一种颠覆性的通信模式，旨在进一步降低延迟，提升区域通信效率。

…the UE-satellite-UE communication refers to the communication between UEs under the coverage of one or more serving satellites without the user plane traffic going through the ground network.

深度解析：

传统卫星通信，即便是两个身处同一颗卫星波束覆盖下的用户通话，其语音数据流也需要遵循“UE → 卫星 → 地面关口站 → 核心网 → 地面关口站 → 卫星 → 对端UE”的漫长路径。这带来了双倍的星地往返延迟。

  • 阿里斯博士的理想场景：他的两个外勤小组，A组和B组，在雨林中相隔10公里，都在同一颗带有“再生载荷（regenerative payload）”能力的LEO卫星覆盖下。A组需要紧急告知B组前方有塌方危险。
  • UE-卫星-UE的优势：如果启用该模式，A组的语音数据上传到卫星后，卫星上的交换载荷可以直接将数据转发给B组，无需落地。通信路径缩短为“A组UE → 卫星 → B组UE”，延迟只有一次星间链路的延迟，对于LEO卫星可能只有几十毫秒，通话体验将与地面网络无异。
  • 应用使能的挑战：应用（例如IMS客户端）如何知道何时可以发起这种“本地直通”呼叫？网络如何将这种能力暴露给应用层？相关的信令交互和功能协商机制，是KI#6研究的核心。

3. 架构与方案：构建天地一体化的应用使能框架

面对上述八大挑战，TR 23.700-01在第5、6、7章中系统性地提出了架构要求、架构选项和具体解决方案。

3.1 架构要求与选项（第5、6章）

第5章“Architecture requirements”将Key Issues中识别出的需求，提炼为对系统架构的具体要求。例如：

[AR-5.3-a] The EDGEAPP shall support satellite connectivity enabled with deployment of EDGEAPP architecture components onboard satellite. [AR-5.4-b] The SEAL architecture shall support satellite coverage availability information during discontinuous coverage of satellite connectivity.

这些要求直接驱动了第6章中对现有架构（EDGEAPP, SEAL, MC Services）进行增强的讨论。报告明确，无需为卫星接入发明一套全新的应用使能架构，而是在现有成熟的5G应用使能框架上进行“升级改造”，以支持卫星的特殊性。

  • Option#2: EDGEAPP over Satellite：增强5G边缘计算（TS 23.558）架构，使其能够处理卫星上的EAS/EES的发现、部署和移动性管理。
  • Option#3: SEAL over Satellite：增强服务使能架构层（TS 23.434），使其成为向应用暴露卫星特性（如覆盖信息、S&F事件）的核心平台。

3.2 核心解决方案（第7章）

第7章是报告中技术细节最丰富的部分，它针对每个Key Issue提出了一个或多个具体的解决方案。我们可以通过阿里斯博士的视角来快速理解几个核心方案的精髓。

方案簇#AE1, AE5, AE7：让边缘计算适应“移动的卫星”

为了解决KI#2和KI#5中星上边缘计算的难题，这些方案的核心思想是在现有的EDGEAPP信息元素中，增加与卫星强相关的字段。

例如，在EAS Profile（边缘应用服务器档案） 中增加：

新增信息元素描述阿里斯博士的应用场景
Dynamic service area indication指示服务区域是否为动态。对于LEO/MEO卫星上的EAS，此项为真。系统知道这个EAS是移动的，需要为其规划不同的服务连续性策略。
Trajectory ID唯一的轨迹ID，用于标识LEO/MEO卫星及其轨道。阿里斯博士的无人机在追踪动物时，可以向网络提供自己的预计轨迹，网络则为其匹配一个具有最长共同服务时间的、拥有相同轨迹ID的卫星EAS。这实现了智能、可预测的服务切换，避免了频繁的重新发现和连接中断。
Satellite ID卫星的唯一标识。用于精确识别和定位服务资源。
Ephemeris information卫星星历信息，用于计算卫星的精确位置和移动轨迹。让UE或网络实体能够自主预测卫星的可见性和连接质量。

通过在EES（边缘使能服务器）和EAS的注册、发现流程中加入这些信息，系统就具备了在动态、移动的卫星环境中进行高效边缘服务调度的能力。

方案#AE3：通过SEAL量化“非连续覆盖”

该方案直面KI#3，旨在将模糊的“没信号”问题，变为精确的、可预测的“不可用时段”。其核心是利用SEAL服务器。

流程可以概括为：

  1. 信息获取：SEAL服务器从卫星运营商或网络内部获取所有相关卫星的星历数据。
  2. 计算与生成：结合UE上报的地理位置，SEAL服务器计算出该UE在未来一段时间内的“卫星覆盖可用性信息（SCAI）”和“不可用时段（unavailability period）”。这个信息非常具体，例如：“从 UTC 14:00:00 到 17:30:00，UE位于（x,y）处将无NB-IoT-NTN覆盖”。
  3. 信息下发与暴露：
    • SEAL服务器可以通过配置流程，将这个“不可用时段列表”直接下发给UE上的SEAL客户端，供APP使用。
    • 同时，SEAL服务器也可以将此信息通过标准API暴露给后端的应用服务器（AS）。

如下图“Figure 7.2.3.1.2-1: Procedure for AS handling UE unavailability period information”所示，当AS（如阿里斯博士的总部服务器）需要与UE通信时，它可以先向5GC/SEAL查询UE的可用性。如果得知UE正处于不可用时段，AS便会启动缓存机制，将下行数据暂存，等到网络通知其可用性恢复后再发送，从而避免了无效的传输尝试和资源浪费。

方案#AE4, AE8：将S&F状态转化为应用层“情报”

这两个方案致力于解决KI#7，让S&F操作对应用层透明化。同样以SEAL为核心。

The VAL server sends UE S&F status events subscription requests to the SEAL server. The subscription events may include the UE Registration status in S&F Mode, the status of Feeder Link, the expected Delivery/Delay Time, the maximum S&F data storage quota per UE, the trigger conditions, etc.

深度解析：

这里描绘了一个清晰的“订阅-通知”模型。

  1. 订阅：阿里斯博士的总部服务器（VAL Server）向SEAL服务器发起订阅请求，表示“我对雨林A-01号传感器的S&F状态很感兴趣，请在以下事件发生时通知我：UE进入S&F模式、馈线链路状态变化、预计送达时间更新”。
  2. 信息汇总：SEAL服务器从核心网（通过NEF/SCEF）获取底层的S&F事件。
  3. 通知：当核心网上报“卫星XYZ已连接地面站，馈线链路可用”时，SEAL服务器立刻将此事件通知给订阅了的总部服务器。
  4. 智能决策：收到通知后，总部服务器立即采取行动，例如：
    • 调整应用行为：将缓存的优先级最高的数据（如设备故障告警）立刻发送出去。
    • 优化数据传输：根据通知中附带的“最大S&F数据存储配额”，决定本次传输的数据量，避免超出卫星存储能力。
    • 更新UI状态：在操作界面上，将传感器的状态从“离线-S&F”更新为“数据回传中”，并显示预计完成时间。

4. 总结与展望：迈向真正的全球无缝覆盖

3GPP TR 23.700-01 是一份承前启后的重要文献。它没有直接定义最终的标准，但通过系统性的问题识别和解决方案研究，为Release 19及后续版本中“应用使能支持卫星接入”的标准化工作（Normative Work）铺平了道路。

报告的第11章“Conclusions” 中明确指出：

  • 架构重用：现有的EDGEAPP和SEAL架构是支持卫星连接的坚实基础，无需推倒重来，只需进行针对性的增强。
  • 方案可行性：报告中提出的大部分解决方案，如#AE1, AE3, AE7等，被认为是可行且有前景的，可以进入后续的标准化阶段。

对于像阿里斯博士这样的前沿探索者而言，这份报告描绘的未来无比激动人心。一个“聪明”的、能够与应用双向互动的5G天地一体化网络，将彻底改变偏远地区科学研究、应急救援、物联网部署和关键通信的游戏规则。

当网络能够智能地告诉应用“何时说、说什么、怎么说”，应用才能真正挣脱物理链路的束服，在星辰大海的征途中，发挥出全部的潜力。TR 23.700-01，正是这曲天地协同交响乐的序章。

FAQ环节

Q1：这份TR 23.700-01技术报告和我们通常说的TS 23.501这样的技术规范有什么区别？ A1：TR（Technical Report）是技术报告，它是一份研究性文档，主要用于对新技术或新场景进行可行性分析、识别潜在问题（Key Issues）并探索可能的解决方案。TR不具有强制性，是后续标准化的基础。而TS（Technical Specification）是技术规范，是具有约束力的、需要设备商和运营商遵循实现的“标准”，它详细定义了功能、接口和流程。简单说，TR是“研究该怎么做”，TS是“规定就这么做”。TR 23.700-01的研究成果，将会在未来的TS（如TS 23.434对SEAL的增强）中以标准化的形式体现出来。

Q2：为什么在卫星上部署边缘计算（Edge Computing）如此重要？ A2：主要有两个原因：降低延迟和节省带宽。卫星通信，特别是GEO卫星，星地往返延迟非常高（超过500ms），不适合需要快速交互的应用。通过在卫星上部署边缘计算节点，可以将计算任务（如AI分析、数据预处理）直接在太空完成，只需将最终的、小体积的结果传回地面，极大地降低了对地面计算的依赖，实现了近乎实时的响应。同时，只传输结果而非原始海量数据，也极大地节省了宝贵且昂贵的星地链路带宽。

Q3：什么是“非连续覆盖（Discontinuous Coverage）”，这份报告提出了怎样的解决思路？ A3：“非连续覆盖”主要发生在使用非静止轨道（NGSO）卫星星座（特别是尚未完全部署的LEO星座）的场景中。由于卫星在高速移动，对于地面某个特定点来说，可能一天中只有几个时间段头顶上有卫星经过，这些时间段之外就是网络覆盖的“盲区”。这份报告的核心解决思路是“可预测性”。通过应用使能层（如SEAL），网络可以将精确的“不可用时段信息”暴露给应用层（包括UE上的App和后端的服务器）。应用据此可以智能地规划自己的行为，比如在“盲区”时段进入休眠以省电，在覆盖窗口来临前提前准备好数据进行“脉冲式”通信。

Q4：报告中反复提到的SEAL（Service Enabler Architecture Layer）到底是什么？它在卫星通信中扮演什么角色？ A4：SEAL是3GPP SA6定义的一个通用的服务使能架构层，可以理解为一个位于核心网和上层应用之间的“中间件”或“能力开放平台”。它的作用是把网络的能力（如位置、群组通信、配置管理等）打包成标准化的API，供第三方应用调用，从而加速业务创新。在卫星通信这个场景下，SEAL扮演了“网络信息翻译官和代理人”的角色。它负责从底层网络获取卫星特有的信息（如覆盖间隙、S&F事件、延迟特性等），并以一种对应用友好的、标准化的方式（API）将这些“情报”提供给上层应用，使得应用能够智能地适应卫星环境。

Q5：这份报告里的解决方案，现在可以在商用网络中使用了吗？ A5：还不可以。作为一份Release 19的研究报告（TR），其主要任务是为标准化指明方向。报告中提出的解决方案，比如对EES Profile增加“Trajectory ID”，或者SEAL暴露“unavailability period”的API，都需要在后续的标准化工作中，在对应的技术规范（TS）中被正式采纳和详细定义。这个过程通常需要经过多个工作组的讨论和成员公司间的共识。因此，可以预见在未来的1-2年内，基于这些研究成果的标准化功能会逐步出现在5G-Advanced（Rel-19及以后）的商用网络设备和终端中。

关系图谱