简介一份基于5G-A通信感知融合的能力开放技术文档面向通信网络研究者、5G/6G技术工程师及网络规划人员系统梳理了通信感知融合的分层架构、网络架构、信令流程与典型应用场景帮助读者理解如何通过能力开放实现通感业务。压缩包内含1个Word文档约151KB内容完整、结构清晰。已有222人学习浏览。文档详细阐述了资源层、能力层与应用层的功能划分资源层涵盖频谱、软硬件及网络资源能力层聚焦数据处理、通信、感知与能力协同应用层则支持低时延高可靠传输、大带宽传输、定位、测距与成像等服务同时结合NEF网元分析了通信感知融合的网络演进思路和感知业务流程并探讨了目标检测、定位、识别与成像等实际场景能为后续网络部署、方案评估与相关研究提供有价值的参考。1. 从论文到方案5G-A 通信感知融合能力开放这份文档能帮你省掉大半前期调研做核心网或垂直行业通信方案的工程师这两年应该没少被 5G-A 通感融合这个概念刷屏。但真正落到方案设计时你会发现一个很尴尬的问题感知能力怎么提供给第三方应用业内几乎没有一份能把架构、接口、信令流程串起来的完整参考。市面上讲通感融合的论文不少但多数停在场景畅想真正把 NEF、AMF、gNB 之间的配合关系讲清楚的不多。这份文档的价值就在这里——它给出了一套从资源层到应用层的三层能力开放架构定义了通信感知融合功能网元的管控、计算、开放三项职责还画出了从第三方 AF 发起请求到 gNB 感知、UPF 回传、NEF 开放出去的完整 8 步信令链路。适合正在做 5G-A 核心网架构设计、通感算一体方案预研、或者写行业解决方案标书的从业者。我拆这份文档时最大的感受是它把「感知能力怎么变成一种可开放的服务」这件事从概念层面拉到了可讨论的工程层面。2. 三层能力开放架构资源层、能力层与应用层各自承担什么2.1 为什么需要单独设计一套分层架构而不是直接在 5GC 上加接口5G 核心网现有的能力开放体系已经很成熟NEF 对外提供 QoD、NIDD、定位等能力第三方应用通过 CAPIF 调用。但通感融合有个本质区别定位能力只输出位置信息感知能力输出的可能是点云、成像数据、测距测速结果数据类型和计算复杂度完全不在一个量级。如果直接在 5GC 网元上打补丁控制面信令会非常拥挤感知数据的传输和计算也没有清晰的归属。文档给出的分层架构借鉴了云原生和微服务的设计理念把通感融合系统拆成三个独立演进的层资源层解决「用什么感知」能力层解决「怎么把原始感知变成服务」应用层解决「开放给谁用」。分层的核心收益在于底层资源的变化比如新增一种感知频谱不应该影响上层应用的接口定义能力层通过原子化封装屏蔽掉资源差异。这个思路和 5G 服务化架构 SBA 是一致的——把网络能力当作服务来设计。2.2 资源层频谱、网络、软硬件的映射关系文档把资源层分为频谱资源、网络资源、软硬件资源三大类。频谱资源里最值得关注的是「一体化频谱」这个提法——通信和感知共用同一段频谱这是通感融合和传统通信最根本的差异点。通信频谱侧重数据传输效率感知频谱需要大带宽和良好的反射特性一体化频谱则要求在两者之间做动态权衡。网络资源包括通信设备、感知设备和一体化网络设备对应到实际部署中就是现有 gNB 的感知功能增强、独立的感知节点、以及两者共存的混合形态。这里有一个参数层面的细节需要理解资源层的具体表现是硬件资源池和频谱策略能力开放平台通过调用这些资源封装成不同的原子化功能。也就是说资源层本身不对外暴露它只向上层提供「可被调用的资源视图」。实际做部署规划时资源层的设计决定了感知节点的部署密度、频谱分配策略、计算存储资源的冗余度。文档没有给出具体的资源量化指标这是当前 3GPP R18/R19 还在讨论的内容但分层边界已经清晰了。2.3 能力层数据处理、通信、感知与协同的关系能力层是这套架构里最有内容的部分包含四个模块。数据处理功能细分为通信数据处理、感知数据感知、联合数据处理——联合数据处理指的是把通信链路质量信息和感知结果放在一起分析比如通过感知到的环境信息反向优化波束管理。通信功能包括无线接入和通信质量控制这部分基本复用现有 5G 体系。感知功能是新增的核心包括目标定位内部又分测距、测速、测角三种操作、目标跟踪、目标检测和目标成像。能力协同是容易被忽略的一层。单个基站感知能力有限多基站协同感知、感知与通信资源协同调度都需要能力协同模块统一编排。在做方案设计时我一般会把定位精度、感知距离、上报周期、分辨率这些参数作为能力层的性能指标这些参数直接决定了后续应用层能提供什么等级的服务——它们同时也是信令流程中请求消息的重要字段。2.4 应用层从低时延高可靠传输到成像服务的服务收敛应用层是能力开放的实际出口文档列举了低时延高可靠传输、大带宽传输、基于位置服务、基于测距服务、基于成像服务五大类。注意这里的分类粒度前两类是通信类服务后三类是感知类服务正好对应能力层的通信功能和感知功能。文档还提到这些服务可以进一步支持人机交互、智能体交互和虚实交互——智能体交互这个提法说明应用层不只面向传统 App还要面向未来 AI Agent 调用网络能力这在架构预留上是很有前瞻性的。针对应用层的设计我的判断是分层架构的价值在于让应用层可以组合调用多个能力。比如无人机低空监管既需要连续定位测距测速测角又需要环境重构成像还需要低时延高可靠的数据回传通信。三层架构把这三类需求解耦到不同层级应用层只需要通过统一接口组合调用能力层服务即可。层级核心职责主要构成对外出口资源层提供感知与通信的基础资源频谱、网络设备、软硬件资源池不直接对外通过能力开放平台封装能力层把资源封装为原子化服务能力数据处理、通信、感知、能力协同向应用层暴露标准化服务接口应用层面向最终用户提供服务定位、成像、测距、传输服务通过 NEF 向第三方 AF 开放3. 网络架构改动新增通感融合网元与 Nx/Ny 接口的定位与复用3.1 四种主流演进观点的对比与取舍文档把当前业内对 5G-A 通感融合网络架构的讨论归纳为四种观点。第一种是最大化复用 5GC 现有功能网元和接口优点是改动小、标准化进度快但感知功能的管控和计算没有明确归属只能硬塞进现有网元第二种是新增具备控制、计算能力的通信感知功能网元好处是职责清晰但需要标准化新网元和接口第三种是与 5GC 位置感知系统平滑演进优势是复用已有的 LCS 定位体系但定位只是感知的一种类型覆盖不了成像、环境重构这类更复杂的感知需求第四种是提供能力开放功能把感知能力作为服务对外暴露。文档给出的架构综合了这四种观点核心是新增通信融合感知功能网元同时最大化复用现有 5GC 网元和接口流程。这个取舍很务实——完全推倒重来不现实完全复用又解决不了感知管控问题。我理解的定位是这个新网元承担感知功能的集中管控和计算结果输出而 gNB 的感知信号发射与接收、AMF 的感知控制转发、UPF 的数据传输都沿用现有网元和接口改动被有效控制住了。3.2 通信融合感知功能网元的三角色职责新增网元被赋予三个角色管控、计算、开放。管控的对象是 AMF 的感知功能——具体来说是控制 AMF 如何向 gNB 下发感知配置、如何上报感知结果计算职责是对 gNB 上报的原始感知数据进行智能化计算把测距、测速、测角、成像数据整合成有业务意义的结果开放职责是把处理后的感知信息向网络内部 NF 或外部第三方开放。这个三角色设计有一个容易被忽略的点感知数据的计算没有放在 gNB 侧完成而是上收到核心网网元统一处理。这种集中式设计的考虑是支持多基站感知数据融合——单基站感知视角有限多基站协同才能支撑高分辨率成像和环境重构。代价就是核心网需要引入较强的计算资源实际部署时通常会把计算能力下沉到靠近接入网的位置或者干脆把新网元部署在 MEC 节点上。文档没有展开这部分部署细节但架构上留了口子。3.3 控制面与用户面的接口走向控制面新增了两个接口南向是 Nx北向是 Ny。Nx 接口连接通信感知融合功能网元和 NEF承载感知能力调用请求、感知结果上报走的是能力开放通道Ny 接口连接通信感知融合功能网元和 AMF承载对 AMF 感知功能的控制指令。AMF 通过现有的 N2 接口把感知控制信令转发给 gNB——AMF 在这里扮演一个透明的控制指令中继角色自身只需功能增强支持感知控制信令透传。用户面走 N3 和 N6。gNB 感知数据通过 N3 接口上报到 UPFUPF 再通过 N6 接口把感知数据转发给通信感知融合功能网元。这里有一个值得注意的设计决策感知数据没有直接走新接口而是复用了用户面通道。原因很直接——感知数据量大控制面信令通道承载不了。不过文档第 4 章的流程里有一个细节让整个链路看起来有点跳跃gNB 把感知数据返回给 AMFAMF 再通过 UPF 返回给通信感知融合功能网元。这里的实际含义应该是 gNB 的响应信令先回到 AMF同时感知数据本身通过 UPF 单独传输两条路径在通信感知融合功能网元汇合。接口方向承载内容复用情况Nx通感融合网元 ↔ NEF感知能力调用请求、感知结果上报新增Ny通感融合网元 → AMF对 AMF 感知功能的控制指令新增N2AMF → gNB感知控制信令转发透传复用现有接口N3gNB → UPF感知数据上报复用现有接口N6UPF → 通感融合网元感知数据转发复用现有接口3.4 与 5GC 位置感知系统的平滑演进关系文档提到需要与 5GC 位置感知系统平滑演进这意味着新增的通信感知融合功能网元设计上可以考虑兼容旧的定位体系感知能力开放的路径可以逐步从已有能力开放网元迁移到新架构。例如R15-R17 阶段定位服务已标准化在现有流程上叠加感知能力开放功能能够降低初期改造的复杂度。在设计网元功能时有必要预留对现有定位相关接口的兼容避免后续做系统升级时出现业务断档。提示Nx、Ny 接口目前在 3GPP 标准化体系里还没有正式定义文档里是研究性命名做方案时不要当作规范依据要关注 R18/R19 的标准化进展。4. 8 步信令流程拆解从第三方 AF 请求到感知数据回传的核心链路4.1 流程全景两个端点、三次转发、一条回传链通信感知融合的能力开放流程从 UE 发起感知业务请求开始到 UE 收到感知业务响应结束核心链条是 AF → NEF → 通信感知融合功能网元 → AMF → gNB 的下行控制链路以及 gNB → AMF → UPF → 通信感知融合功能网元 → NEF → AF 的上行数据回传链路。整个流程涉及 UE、AF、NEF、UDM、通信感知融合功能网元、AMF、gNB、UPF 共 8 个节点理解的关键在于区分哪些消息走控制面、哪些走用户面。这个流程设计里有一个整体思路值得关注AF 始终通过 NEF 与核心网交互不直接连接通信感知融合功能网元或 AMF。这样第三方应用就不需要感知核心网内部的拓扑变化——新增网元时AF 和 NEF 之间的接口保持稳定。这也是「能力开放」在信令层面的具体体现。4.2 逐步拆解每一步消息的携带内容与处理逻辑步骤节点动作关键携带信息000UE → AF发送感知业务请求感知业务类型1AF → NEF发送感知数据能力开放请求AFID、APPID、UE Identifier、Sensing Data Type、业务要求2NEF ↔ UDM权限协商确认AF 身份、业务权限、签约数据3NEF → 通感融合网元转发能力开放请求保留原请求全部字段4通感融合网元 → AMF寻址 UE 所属 AMFUE Identifier 映射、感知配置参数5AMF → gNB转发感知控制信令感知距离、分辨率、上报周期等6gNB → 通感融合网元感知探测并返回感知数据无线测距、多维感知、感知探测结果7通感融合网元 → NEF整合计算后返回响应处理后感知数据001AF → UE返回感知业务响应感知业务结果步骤 1 的关键字段里AFID 和 APPID 用于标识调用方身份UE Identifier 用于感知目标寻址Sensing Data Type 决定 gNB 采用哪种感知方式业务要求里通常携带精度、时延、周期等指标。步骤 2 的权限协商很关键——NEF 需要与 UDM 确认这个 AF 是否有权请求该 UE 的感知数据这个流程复用了 5G 现有的 NEF-UDM 协商机制避免为感知业务单独建立信任体系。步骤 4 的寻址逻辑是通信感知融合功能网元根据 UE Identifier向 AMF 查询该 UE 当前所在的 AMF。步骤 5 中 AMF 附带上感知业务的感知距离、分辨率、上报周期等参数与通信感知控制信令一起发送给 gNB。步骤 6 是感知数据产生的核心环节——gNB 根据 Sensing Data Type 选择无线测距、多维感知或感知探测方式获得感知数据后将感知数据搭载在响应消息中返回给 AMFAMF 再通过 UPF 返回给通信感知融合功能网元。这里「gNB → AMF → UPF → 通感融合网元」的路径和架构章节描述的感知数据传输路径一致。4.3 三个关键设计判断为什么感知数据路径与信令路径分离整个流程中最值得深入理解的设计判断有三个。第一个是 AF 不直接连 AMF 或 gNB所有请求经过 NEF 中转NEF 是唯一的开放锚点便于统一做认证、授权、计费。第二个是感知数据不通过控制面直接传送而是经 UPF 走用户面——如果感知结果较大走控制面会给 AMF 和 NEF 带来很大压力。第三个是数据的处理和计算集中在通信感知融合功能网元gNB 只负责原始感知数据的采集这样从逻辑上支持多基站数据融合。这三点组合在一起体现的架构思路是控制信令走控制面感知数据走用户面计算和开放集中在新增网元。从流程可以看到AMF 被定位成一个「控制转发节点」既不解析感知数据内容也不承担计算任务原有的信令承载机制被直接复用了。5. 避坑与排查通感能力开放落地中的五个常见认知偏差5.1 误区把通感融合当成 R15/R16 定位增强现象方案设计直接用 LCS 定位流程做通感融合认为在现有定位架构上加几个参数就能支持感知业务场景讨论只围绕「定位更准」展开。原因通感融合的感知范围远不止定位——成像、虚拟环境重构、多目标跟踪都涉及远超定位的数据处理能力。R15-R17 标准化的是定位服务不是感知服务两者的数据量、计算复杂度、接口要求都不在一个量级。解决在架构设计初期明确区分「定位能力」和「感知能力」。定位可以复用 LCS 体系感知必须走独立的通信感知融合功能网元链路。如果只是做定位精度增强不建议选用这套架构直接用 R16/R17 定位增强更省成本。5.2 误区忽略 NEF 与 UDM 的权限协商现象直接让 AF 通过 NEF 发起感知请求结果大量请求没到 gNB 就被拒绝。原因感知数据比普通业务数据敏感得多——测距结果可能暴露目标的位置成像数据可能涉及隐私。NEF 与 UDM 的权限协商不是可选项是关键安全环节。设计时如果跳过协商过程会导致接口对接失败或安全合规问题。解决在设计流程时不可省略 NEF-UDM 权限检查的环节需要在请求消息里预先设计好 AFID、APPID 对应的签约关系和开放策略。第三方 AF 接入前建议先做 NEF 侧的权限配置再开展联调。5.3 误区感知数据全部走控制面回传现象联调时 AMF 负载异常升高信令面时延恶化感知业务的响应时间明显异常。原因感知数据量大控制面消息结构设计承载大量数据本就不是专长。如果实现时将感知数据封装在控制面消息里直接传给通信感知融合功能网元AMF 会成为瓶颈。解决严格按照文档设计感知数据经 N3 到 UPF再由 UPF 经 N6 转发给通信感知融合功能网元。控制面只传控制信令。实现时需注意 gNB 侧的接口适配将感知数据与信令消息正确分流。5.4 误区把 Nx/Ny 接口当成 3GPP 已定义的标准接口现象开发做接口联调时发现 Nx、Ny 并没有规范的协议栈定义各家实现不一致。原因Nx、Ny 是研究阶段提出的接口名称3GPP 标准尚未正式定义。针对感知业务的标准化工作尚在推进中早期实现通过扩展现有接口承载。解决架构验证阶段可以基于 HTTP/2 或现有的服务化接口自行定义消息格式但要留好后续向标准接口迁移的改造空间。与厂商对接时需要先确认对方在北向接口上的具体实现情况避免兼容性问题。5.5 误区感知数据统一集中到核心网计算忽略端到端时延现象演示环境里感知结果的实时性不理想自动驾驶等场景无法满足低时延要求。原因如果通信感知融合功能网元部署在核心网数据要经用户面上传到核心网、完成计算后再下发链路过长。文档架构适合对时延不敏感的宏观感知应用时延敏感场景需考虑把计算下沉到边缘节点。解决需要在部署平面灵活调整——把感知计算能力下沉到 MEC 节点让通信感知融合功能网元的计算模块就近部署在 UPF 旁边数据在边缘完成计算和开放。6. 把论文机制用到自己的网络三个应用场景的适配判断与验证清单通信感知融合的能力开放最终价值体现在应用层。选对应用场景架构的合理性就更容易验证场景选择不当投入产出比会很难看。文档重点论述了三个方向我根据自己的实践给出判断标准。第一类是高精度定位。最适合的是无人机监管和自动驾驶这类场景对连续定位、测速测角有刚需且现有 GPS/RTK 覆盖不到的区域正好是通感融合的空白市场。验证重点是定位精度和上报周期精度能不能做到米级甚至亚米级高动态目标能不能稳定跟踪。测试时不宜只用单基站多基站协同效果是这项能力的核心指标。第二类是高分辨率成像。工业缺陷检测、医疗检测是典型场景通感融合的优势是全天候、无接触、无电离损伤。这类场景需要重视分辨率和数据开放接口的标准化程度感知数据量较大要提前评估数据回传和存储的带宽与容量规划是否足够。第三类是虚拟环境重构。数字孪生城市、智慧园区管理都在此列核心指标是 2D/3D 地图的构建速度与精度。验证时先跑通静态场景再引入动态目标逐步增加复杂度。归根结底方案设计要先想清楚应用场景所在行业的数据敏感度需要正确处理感知数据的合规要求。如果是面向外部第三方开放制定清晰的业务开放策略、接口调用限制和数据边界管理是必要的。提示感知数据类型不同对网络带宽和计算资源的要求差异很大。成像数据通常是测距数据的数十倍规划资源池时建议按最高量级的场景预留容量避免后期扩容。我拆这份文档时踩过一个坑拿到文档后没有先做分层架构的映射直接把信令流程照着画进方案里导致资源层和能力层的对应关系一直对不上被评审问住了。从那以后我每次做通信感知融合方案都强制走一遍「资源层→能力层→应用层→信令流程」的完整推导先确认新增网元的管控、计算、开放定位再谈接口和流程顺序不能乱。这份文档适合作为方案设计前的基线参考建议结合 3GPP R18/R19 最新进展和厂商生态现状一起看希望帮到你。本文还有配套的精品资源点击获取