企业官网建设流程全解析

简介：这份文档资料聚焦5G-A阶段通信感知融合的能力开放技术，面向通信领域研究者、核心网工程师及高校相关专业师生，帮助读者系统理解通感一体化从架构设计到业务落地的完整脉络。资源包内含1个docx文档，大小约151KB，内容围绕分层架构、网络架构、信令流程与应用场景四大板块展开。文档首先论述资源层、能力层与应用层构成的能力开放分层架构，继而提出复用5GC网元、新增通信融合感知功能网元、结合NEF能力开放的组网思路，并梳理Nx、Ny、N2等接口定义与基本信令流程，最后延伸至目标检测、定位、识别、成像等典型应用场景。目前已有222人学习，适合需要把握5G-A通感融合技术演进方向、开展网络部署与应用探讨的读者参考。

1. 从一份 5G-A 通感融合能力开放文档说起：NEF 到底怎么把感知数据卖出去

运营商手里攥着一张 5G-A 网络，基站天天在发参考信号，这些信号打到人、车、无人机身上再弹回来，本身就带着距离、角度、速度信息。问题是，这些信息过去只在通信系统内部用来解调、调度，没人把它当成一种可售卖的服务。这份《基于5G-A通信感知融合的能力开放技术》文档要解决的，就是怎么把无线信号里“顺带”感知到的数据，通过 NEF（Network Exposure Function，网络能力开放功能）打包成第三方应用能调用的接口。它适合两类人：一是做核心网架构设计、需要理清 NEF 与新增感知功能网元之间接口关系的工程师；二是做行业应用（无人机、自动驾驶、智能工厂）的产品或方案人员，想知道网络侧到底能开放出什么粒度的感知数据。文档本身不是代码包，是一份架构与流程设计参考，核心价值在于把“通信感知融合”从无线侧的算法问题，拉到了核心网能力开放的服务化框架里。

2. 分层架构怎么落到网元上：资源层、能力层、应用层的映射关系

2.1 三层架构不是画着好看，每一层都要找到对应的 5GC 网元

文档把通信感知融合的能力开放分成资源层、能力层、应用层。这个分法本身不新鲜，新鲜的是它要求每一层都能在现有 5GC 服务化架构里找到落点。资源层对应的是频谱、软硬件和网络资源，具体到 5G-A 网络里，频谱资源就是通信频谱、感知频谱和一体化频谱的划分，网络资源就是 gNB、UPF、AMF 这些设备。能力层是中间层，负责把资源层的能力封装成原子化功能，包括通信数据处理、感知数据处理、联合数据处理，以及目标定位（测距、测速、测角）、跟踪、检测、成像这些感知功能。应用层直接面向业务，低时延高可靠传输、大带宽传输、基于位置服务、基于测距服务、基于成像服务都在这一层。

我一般会把这个分层理解成一个“能力漏斗”：底层是物理资源和网元，中间层把网元能力抽象成可调用的服务，上层把服务组合成业务。关键点在于，能力层不是凭空造出来的，它必须通过 NEF 去调用资源层的资源。文档里有一句话很关键——“网络能力开放平台通过调用资源层资源，封装形成不同原子化功能”。这意味着 NEF 不只是对外开个 API 网关，它还要参与能力层的功能封装。在实际网络部署中，这要求 NEF 与新增的通信感知融合功能网元之间有明确的接口定义，否则能力层就是空中楼阁。

2.2 资源层到能力层的封装：哪些参数必须提前定义

从资源层往能力层封装，最怕的是参数没定义清楚。感知数据不是一种单一数据，它至少包括以下几类参数，这些参数必须在能力层封装时就想好怎么暴露给上层：

这张表里的参数不是文档直接列出来的，是我根据文档第 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 为锚点来触发感知。如果要做区域级感知（比如路口车辆检测），这个流程就需要扩展，可能要用 TA（Tracking 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 里新增 IE（Information Element），或者用现有的透明容器透传。如果 AMF 不做功能增强，感知控制指令就传不到 gNB。文档也提到“控制面网元 AMF 需要进行功能增强，具备通信感知功能”，这句话的分量很重——它意味着现网 AMF 要升级才能支持通感融合。

3.3 用户面复用 N3/N6：感知数据怎么从 gNB 回到核心网

用户面复用 N3 和 N6 接口。N3 是 gNB 和 UPF 之间的接口，N6 是 UPF 和 DN（Data Network）之间的接口。文档写的是“基于 N3 接口将 gNB 感知数据上报，基于 N6 接口将 gNB 获取的感知数据转发给融合感知功能网元”。这里有一个细节：感知数据走用户面，意味着它和普通用户数据一样，需要建立 PDU Session 或者类似的承载。但感知数据可能不属于某个特定 UE 的会话，这时候怎么建立承载？文档没有展开。我一般会建议在方案设计时考虑两种模式：一种是复用现有 UE 的 PDU Session，把感知数据作为应用数据承载；另一种是建立独立的感知数据通道，但这需要 UPF 支持新的报文检测规则。前者实现简单，后者更灵活但改动大。

4. 信令流程拆解：从 AF 请求到感知数据返回的八个步骤

4.1 步骤 0 到步骤 3：请求怎么从 AF 走到通信感知融合功能网元

文档第 3 节给了完整的信令流程，从步骤 000 到步骤 001，一共 9 个步骤（编号有点跳，但逻辑是连贯的）。我把它拆成三段来看。第一段是请求发起和转发：

• 步骤 000：UE 向第三方应用 AF 发送感知业务请求。这一步是业务触发，不是网络信令。
• 步骤 1：AF 发送感知数据能力开放请求至 NEF，携带 AFID、APPID、UE Identifier、Sensing Data Type、业务要求。
• 步骤 2：NEF 与 UDM 进行感知请求的权限协商。这一步是鉴权，确认 AF 有没有权限请求这个 UE 的感知数据。
• 步骤 3：NEF 将请求转发至通信感知融合功能网元。

这里的关键参数是 Sensing Data Type 和业务要求。Sensing Data Type 决定了 gNB 要做哪种感知（测距、测速、测角、成像），业务要求决定了感知的精度、周期、时延。如果这两个参数没填对，后面 gNB 就不知道该采什么数据。权限协商走 UDM，说明感知数据的开放是受签约控制的，不是任何 AF 都能随便请求。

4.2 步骤 4 到步骤 6：感知指令怎么下到 gNB，数据怎么回来

第二段是感知执行：

• 步骤 4：通信感知融合功能网元根据 UE Identifier 寻址 UE 所属 AMF。
• 步骤 5：AMF 基于业务类型附加感知距离、分辨率、上报周期等控制信令，转发至 gNB。
• 步骤 6：gNB 通过无线环境感知探测获取感知数据，通过无线测距、多维感知、感知探测等技术获得数据，携带在响应消息中返回给 AMF，AMF 通过 UPF 返回给通信感知融合功能网元。

步骤 5 是控制面下发感知参数的关键一步。AMF 在这里做了一件事：把业务要求翻译成无线侧能理解的感知参数。比如业务要求是“高精度定位”，AMF 要把它翻译成感知距离范围、距离分辨率、角度分辨率、上报周期这些具体参数。这个翻译逻辑目前没有标准定义，是厂商实现差异最大的地方。步骤 6 里 gNB 返回的数据走的是 UPF，也就是用户面，但信令流程里写的是“携带在感知数据能力开放请求响应消息中返回给 AMF”，这里响应消息走控制面还是用户面，文档表述有点模糊。我倾向于理解成：控制面信令通知数据就绪，实际感知数据走用户面 N3/N6 回到通信感知融合功能网元。

4.3 步骤 7 到步骤 001：数据整合与最终返回

第三段是数据返回：

• 步骤 7：通信感知融合功能网元对感知数据进行整合及计算后，返回给 NEF，NEF 将 Sensing Data 开放给 AF。
• 步骤 001：AF 将获得的感知数据通过感知业务响应返回给 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 映射，通信感知融合功能网元需要新增感知数据融合计算模块。这张表可以直接作为开发任务清单。

第四步，选一个最简单的场景做端到端验证。文档第 4 节给了三个应用场景：高精度定位、高分辨率成像、虚拟环境重构。这三个里，高精度定位对带宽和计算要求最低，最适合做第一个验证场景。验证的时候，先不管精度，先跑通流程：AF 发请求，NEF 转发，AMF 下指令，gNB 返回数据，通信感知融合功能网元整合，NEF 返回给 AF。流程通了，再调参数优化精度。

第五步，记录每个环节的时延。感知业务的时延敏感度比普通通信业务高，尤其是定位和跟踪。从 AF 发请求到收到感知数据，总时延要拆成几段：AF 到 NEF、NEF 到通信感知融合功能网元、通信感知融合功能网元到 AMF、AMF 到 gNB、gNB 感知处理、数据回传。哪一段时延最大，就优化哪一段。我见过一个案例，gNB 感知处理只用了 10 毫秒，但数据回传经过 UPF 绕了一圈，多花了 50 毫秒。后来把通信感知融合功能网元部署到边缘云，总时延从 120 毫秒降到了 40 毫秒。

从那以后我每次拿到类似的架构文档，都强制自己走一遍“拓扑-流程-增强点-验证场景-时延拆解”这五步。不走一遍，文档里的架构图就只是图，落不了地。希望帮到你。

本文还有配套的精品资源，点击获取