简介这份文档资料聚焦5G-A阶段通信感知融合的能力开放技术面向通信领域研究者、核心网工程师及高校相关专业师生帮助读者系统理解通感一体化从架构设计到业务落地的完整脉络。资源包内含1个docx文档大小约151KB内容围绕分层架构、网络架构、信令流程与应用场景四大板块展开。文档首先论述资源层、能力层与应用层构成的能力开放分层架构继而提出复用5GC网元、新增通信融合感知功能网元、结合NEF能力开放的组网思路并梳理Nx、Ny、N2等接口定义与基本信令流程最后延伸至目标检测、定位、识别、成像等典型应用场景。目前已有222人学习适合需要把握5G-A通感融合技术演进方向、开展网络部署与应用探讨的读者参考。1. 从一份 5G-A 通感融合能力开放文档说起NEF 到底怎么把感知数据卖出去运营商手里攥着一张 5G-A 网络基站天天在发参考信号这些信号打到人、车、无人机身上再弹回来本身就带着距离、角度、速度信息。问题是这些信息过去只在通信系统内部用来解调、调度没人把它当成一种可售卖的服务。这份《基于5G-A通信感知融合的能力开放技术》文档要解决的就是怎么把无线信号里“顺带”感知到的数据通过 NEFNetwork Exposure Function网络能力开放功能打包成第三方应用能调用的接口。它适合两类人一是做核心网架构设计、需要理清 NEF 与新增感知功能网元之间接口关系的工程师二是做行业应用无人机、自动驾驶、智能工厂的产品或方案人员想知道网络侧到底能开放出什么粒度的感知数据。文档本身不是代码包是一份架构与流程设计参考核心价值在于把“通信感知融合”从无线侧的算法问题拉到了核心网能力开放的服务化框架里。2. 分层架构怎么落到网元上资源层、能力层、应用层的映射关系2.1 三层架构不是画着好看每一层都要找到对应的 5GC 网元文档把通信感知融合的能力开放分成资源层、能力层、应用层。这个分法本身不新鲜新鲜的是它要求每一层都能在现有 5GC 服务化架构里找到落点。资源层对应的是频谱、软硬件和网络资源具体到 5G-A 网络里频谱资源就是通信频谱、感知频谱和一体化频谱的划分网络资源就是 gNB、UPF、AMF 这些设备。能力层是中间层负责把资源层的能力封装成原子化功能包括通信数据处理、感知数据处理、联合数据处理以及目标定位测距、测速、测角、跟踪、检测、成像这些感知功能。应用层直接面向业务低时延高可靠传输、大带宽传输、基于位置服务、基于测距服务、基于成像服务都在这一层。我一般会把这个分层理解成一个“能力漏斗”底层是物理资源和网元中间层把网元能力抽象成可调用的服务上层把服务组合成业务。关键点在于能力层不是凭空造出来的它必须通过 NEF 去调用资源层的资源。文档里有一句话很关键——“网络能力开放平台通过调用资源层资源封装形成不同原子化功能”。这意味着 NEF 不只是对外开个 API 网关它还要参与能力层的功能封装。在实际网络部署中这要求 NEF 与新增的通信感知融合功能网元之间有明确的接口定义否则能力层就是空中楼阁。2.2 资源层到能力层的封装哪些参数必须提前定义从资源层往能力层封装最怕的是参数没定义清楚。感知数据不是一种单一数据它至少包括以下几类参数这些参数必须在能力层封装时就想好怎么暴露给上层参数类别具体参数来源开放粒度距离信息测距值、距离分辨率gNB 无线感知探测按需上报可设周期角度信息到达角、离开角多天线阵列单次或连续速度信息多普勒频移换算的径向速度感知信号处理按感知周期成像信息2D/3D 点云或图像多维度感知融合高带宽按需触发定位信息经纬度、高度、置信度通信参考信号感知融合事件触发或周期上报这张表里的参数不是文档直接列出来的是我根据文档第 1 节和第 4 节的内容反推的。文档提到“目标定位测距测速测角、跟踪、检测和成像功能”这些功能的输出就是上面这些参数。实际做能力开放时NEF 需要把这些参数映射成 API 的字段比如 Sensing Data Type 就对应感知数据类型业务要求里要带上报周期、分辨率要求等。如果这些参数在能力层没有统一封装第三方应用拿到的数据就是一堆原始 IQ 采样根本没法用。2.3 应用层怎么调用从 NEF 到 AF 的数据流应用层调用感知能力走的是 NEF 对外暴露的 API。文档第 3 节的信令流程里第三方应用 AF 发送感知数据能力开放请求到 NEF请求消息里携带 AFID、APPID、UE Identifier、Sensing Data Type 和业务要求。这里有一个容易忽略的点UE Identifier 是必须的因为感知数据最终要关联到具体终端。但感知数据和通信数据不一样感知数据可能是对一个区域的探测不一定绑定单个 UE。文档里流程写的是“根据 UE Identifier 寻址 UE 所属 AMF”这说明当前设计还是以 UE 为锚点来触发感知。如果要做区域级感知比如路口车辆检测这个流程就需要扩展可能要用 TATracking Area或小区 ID 来替代 UE Identifier。这一点文档没有展开但实际做方案时必须考虑。3. 网络架构与接口Nx、Ny、N2 三条通道各管什么3.1 新增通信感知融合功能网元它和 NEF 是什么关系文档第 2 节明确说5G-A 通信感知融合架构要新增一个具备感知功能的 5GC 功能网元叫“通信融合感知功能网元”。这个网元负责三件事感知功能的管控、感知信息的计算和开放。管控是对 AMF 感知功能进行管理控制计算是对上报的感知信息进行智能化计算开放是对感知信息和数据对网络内部或外部开放。它和 NEF 的关系是NEF 是对外开放的锚点通信融合感知功能网元是感知能力的提供者。两者之间通过 Nx 接口通信。Nx 接口的作用是“实现通过 NEF 对外部应用或网络内部 NF 感知能力调用、感知结果上报”。也就是说第三方应用不直接连通信融合感知功能网元而是通过 NEF 中转。这个设计符合 5GC 服务化架构的一贯做法——NEF 作为唯一对外开放的网元内部网元不直接暴露给外部 AF。3.2 Ny 接口与 N2 接口控制面信令怎么走通信融合感知功能网元南向有两个接口Ny 和 N2。Ny 接口是通信融合感知功能网元对 AMF 感知功能的控制N2 接口是 AMF 对 gNB 感知功能的控制。文档里写得很清楚“通过 Ny实现通信融合感知功能网元对 AMF 感知功能的控制。通过 N2 接口实现 AMF 对 gNB 感知功能的控制AMF 将通信融合感知网元功能的控制指令转发给 gNB。”这里有一个实操中容易翻车的地方N2 接口在标准 5G 里是 AMF 和 gNB 之间的接口承载的是 NGAP 信令。现在要把感知控制指令塞进 N2意味着 NGAP 消息需要扩展。文档没有说怎么扩展但常见做法是在 NGAP 里新增 IEInformation Element或者用现有的透明容器透传。如果 AMF 不做功能增强感知控制指令就传不到 gNB。文档也提到“控制面网元 AMF 需要进行功能增强具备通信感知功能”这句话的分量很重——它意味着现网 AMF 要升级才能支持通感融合。3.3 用户面复用 N3/N6感知数据怎么从 gNB 回到核心网用户面复用 N3 和 N6 接口。N3 是 gNB 和 UPF 之间的接口N6 是 UPF 和 DNData Network之间的接口。文档写的是“基于 N3 接口将 gNB 感知数据上报基于 N6 接口将 gNB 获取的感知数据转发给融合感知功能网元”。这里有一个细节感知数据走用户面意味着它和普通用户数据一样需要建立 PDU Session 或者类似的承载。但感知数据可能不属于某个特定 UE 的会话这时候怎么建立承载文档没有展开。我一般会建议在方案设计时考虑两种模式一种是复用现有 UE 的 PDU Session把感知数据作为应用数据承载另一种是建立独立的感知数据通道但这需要 UPF 支持新的报文检测规则。前者实现简单后者更灵活但改动大。4. 信令流程拆解从 AF 请求到感知数据返回的八个步骤4.1 步骤 0 到步骤 3请求怎么从 AF 走到通信感知融合功能网元文档第 3 节给了完整的信令流程从步骤 000 到步骤 001一共 9 个步骤编号有点跳但逻辑是连贯的。我把它拆成三段来看。第一段是请求发起和转发步骤 000UE 向第三方应用 AF 发送感知业务请求。这一步是业务触发不是网络信令。步骤 1AF 发送感知数据能力开放请求至 NEF携带 AFID、APPID、UE Identifier、Sensing Data Type、业务要求。步骤 2NEF 与 UDM 进行感知请求的权限协商。这一步是鉴权确认 AF 有没有权限请求这个 UE 的感知数据。步骤 3NEF 将请求转发至通信感知融合功能网元。这里的关键参数是 Sensing Data Type 和业务要求。Sensing Data Type 决定了 gNB 要做哪种感知测距、测速、测角、成像业务要求决定了感知的精度、周期、时延。如果这两个参数没填对后面 gNB 就不知道该采什么数据。权限协商走 UDM说明感知数据的开放是受签约控制的不是任何 AF 都能随便请求。4.2 步骤 4 到步骤 6感知指令怎么下到 gNB数据怎么回来第二段是感知执行步骤 4通信感知融合功能网元根据 UE Identifier 寻址 UE 所属 AMF。步骤 5AMF 基于业务类型附加感知距离、分辨率、上报周期等控制信令转发至 gNB。步骤 6gNB 通过无线环境感知探测获取感知数据通过无线测距、多维感知、感知探测等技术获得数据携带在响应消息中返回给 AMFAMF 通过 UPF 返回给通信感知融合功能网元。步骤 5 是控制面下发感知参数的关键一步。AMF 在这里做了一件事把业务要求翻译成无线侧能理解的感知参数。比如业务要求是“高精度定位”AMF 要把它翻译成感知距离范围、距离分辨率、角度分辨率、上报周期这些具体参数。这个翻译逻辑目前没有标准定义是厂商实现差异最大的地方。步骤 6 里 gNB 返回的数据走的是 UPF也就是用户面但信令流程里写的是“携带在感知数据能力开放请求响应消息中返回给 AMF”这里响应消息走控制面还是用户面文档表述有点模糊。我倾向于理解成控制面信令通知数据就绪实际感知数据走用户面 N3/N6 回到通信感知融合功能网元。4.3 步骤 7 到步骤 001数据整合与最终返回第三段是数据返回步骤 7通信感知融合功能网元对感知数据进行整合及计算后返回给 NEFNEF 将 Sensing Data 开放给 AF。步骤 001AF 将获得的感知数据通过感知业务响应返回给 UE。步骤 7 的“整合及计算”是通信感知融合功能网元的核心价值。gNB 上报的原始感知数据可能是多个维度的、有噪声的、不完整的这个网元要做数据融合、滤波、目标跟踪、成像处理最后输出干净的感知结果。这一步的计算量不小尤其是成像和点云处理。如果这个网元部署在边缘云时延可以控制在几十毫秒如果部署在中心云时延可能上百毫秒。做低时延应用比如自动驾驶时这个网元的位置很关键。5. 避坑与常见问题通感融合能力开放落地时最容易翻车的五个点5.1 现象AF 请求感知数据NEF 返回权限错误原因NEF 与 UDM 的权限协商没有通过。感知数据的开放权限和普通通信能力开放权限是分开签约的很多现网 UDM 没有配置感知相关的签约数据。解决在 UDM 里为测试 UE 添加感知服务签约或者在 NEF 侧配置临时授权策略用于联调。文档步骤 2 明确写了 NEF 与 UDM 进行权限协商这一步不能跳过。5.2 现象gNB 收到感知控制指令但不执行原因AMF 没有做功能增强或者 N2 接口的 NGAP 消息没有扩展感知 IE。文档明确说 AMF 需要功能增强但很多测试环境用的是标准 AMF不支持感知控制。解决确认 AMF 版本是否支持通感融合功能如果不支持需要在 AMF 和 gNB 之间用透明容器透传感知参数或者升级 AMF。5.3 现象感知数据回来了但时间戳对不上原因感知数据走用户面 N3/N6和信令走控制面 N2/Ny两条路径的时延不一样。如果通信感知融合功能网元不做时间对齐感知数据的时间戳和信令时间戳会差几十毫秒。解决在通信感知融合功能网元里做时间同步或者用 gNB 的 GPS/北斗时钟作为统一时间源。文档没有提时间同步但这是实际部署必须解决的问题。5.4 现象UE Identifier 寻址不到 AMF原因感知请求里的 UE Identifier 格式和 5GC 内部使用的标识不一致。AF 可能用外部标识如 GPSI但 AMF 寻址需要内部标识如 SUPI 或 5G-GUTI。解决NEF 在转发请求前要做标识映射把外部标识转成内部标识。文档步骤 4 写的是“根据 UE Identifier 寻址 UE 所属 AMF”这个 UE Identifier 应该是 NEF 转换后的内部标识。5.5 现象感知数据带宽太大UPF 转发不过来原因高分辨率成像或高精度点云数据的数据量很大如果走 N3/N6 用户面可能占满 UPF 的转发带宽。解决在 gNB 侧做边缘计算只把感知结果而不是原始数据上报或者在 UPF 上配置 QoS 规则给感知数据单独的承载。文档第 4 节提到高分辨率成像服务这种场景下带宽规划必须提前做。6. 从架构到验证怎么用一份文档搭出可复现的测试思路这份文档是架构设计参考不是操作手册所以“验证”不是跑代码而是用文档里的架构和流程去对照实际网络配置。我一般会按下面这个顺序做验证第一步画一张自己的网络拓扑图把文档里的网元一个个标上去。AMF、NEF、通信感知融合功能网元、gNB、UPF、UDM每个网元的位置和接口都标清楚。特别是 Nx、Ny、N2、N3、N6 这五个接口哪个是新增的哪个是复用的标出来之后一目了然。第二步对照文档第 3 节的信令流程在拓扑图上走一遍消息。从 AF 发请求开始每经过一个网元就问三个问题这个网元需要什么参数它做什么处理它把什么传给下一个网元走完一遍你就知道哪些网元需要升级、哪些接口需要扩展。第三步用表格列出每个网元的功能增强点。比如 AMF 需要增强感知控制指令的解析和转发NEF 需要增强感知数据的 API 映射通信感知融合功能网元需要新增感知数据融合计算模块。这张表可以直接作为开发任务清单。网元功能增强点接口变化优先级AMF解析感知控制指令附加感知参数转发至 gNBN2 扩展、Ny 新增高NEF感知 API 映射与 UDM 权限协商与通信感知融合功能网元对接Nx 新增高通信感知融合功能网元感知数据融合、计算、开放Nx、Ny 新增高gNB无线感知探测感知数据上报N2 扩展、N3 复用高UDM感知服务签约数据无新增接口中UPF感知数据转发QoS 保障N3/N6 复用中第四步选一个最简单的场景做端到端验证。文档第 4 节给了三个应用场景高精度定位、高分辨率成像、虚拟环境重构。这三个里高精度定位对带宽和计算要求最低最适合做第一个验证场景。验证的时候先不管精度先跑通流程AF 发请求NEF 转发AMF 下指令gNB 返回数据通信感知融合功能网元整合NEF 返回给 AF。流程通了再调参数优化精度。第五步记录每个环节的时延。感知业务的时延敏感度比普通通信业务高尤其是定位和跟踪。从 AF 发请求到收到感知数据总时延要拆成几段AF 到 NEF、NEF 到通信感知融合功能网元、通信感知融合功能网元到 AMF、AMF 到 gNB、gNB 感知处理、数据回传。哪一段时延最大就优化哪一段。我见过一个案例gNB 感知处理只用了 10 毫秒但数据回传经过 UPF 绕了一圈多花了 50 毫秒。后来把通信感知融合功能网元部署到边缘云总时延从 120 毫秒降到了 40 毫秒。从那以后我每次拿到类似的架构文档都强制自己走一遍“拓扑-流程-增强点-验证场景-时延拆解”这五步。不走一遍文档里的架构图就只是图落不了地。希望帮到你。本文还有配套的精品资源点击获取