通感一体化融合架构及关键技术：5G-A与6G部署方案与选型指南

简介：这份文档资料聚焦5G-A与6G阶段的通感一体化融合架构及关键技术，面向通信领域研究人员、标准化工作者及高校相关专业师生，帮助读者系统理解通感融合的网络架构设计思路与技术难点。资源为单个docx文档，压缩包约141KB，内容围绕5G-A广域与局域场景的通感融合架构、6G高低频协作及算力网络两种架构建议展开，并深入分析新型一体化波形、全双工等关键技术。文档结合3GPP、IMT2020等标准化进展，梳理了通感融合从初步融合到通信感知共赢的演进路径，配有架构图辅助理解。目前已有834人学习，适合需要把握通感融合研究方向、为后续网络部署提供技术参考的读者研读。

1. 通感一体化融合架构及关键技术：一份能直接落地的技术文档拆解

做无线网络规划的工程师最近大概率会被同一个问题卡住：5G-A 和 6G 里反复提的“通感融合”到底怎么落到现网架构上？我拿到这份《通感一体化融合架构及关键技术》文档时，第一反应是把它当成一份“架构选型参考手册”来拆——它不是科普，而是把 5G-A 广域/局域两套部署方案、6G 高低频协同与算力网络两套架构建议，以及波形、全双工、超大规模天线三类关键技术一次性摊开讲清楚。适合谁看？做 5G-A 演进规划、6G 预研、网络架构设计，以及需要给团队做通感技术选型汇报的人。文档的核心价值在于：它没有停留在“通感很重要”这种层面，而是给出了可继承现有 5G 网元的改造路径，以及 6G 阶段两种可推演的架构方向。

2. 5G-A 通感融合架构：广域与局域两套部署方案怎么选

5G-A 阶段的通感融合有一个硬约束：架构稳定性和可继承性优先。文档明确说这个阶段不考虑改变原有网络架构和通信波形，更多是用现有频率和设备架构做高精度定位、非高精度成像这类业务。这意味着如果你现在做规划，不需要推翻现有 5G 核心网，而是在网元层面做增强或新增。

2.1 广域场景：感知网元放在 AMF 还是更靠后的核心网

广域场景的核心诉求是大范围覆盖加移动性兼顾。文档给出的方案是把感知处理网元部署在 AMF，或者放在 AMF 后面的核心网网元上。这个思路和 5G 定位模块的部署逻辑类似——不改变无线侧架构，只在核心网侧做功能增强。

具体到落地，无线侧有两种选择：新增感知接口，或者复用原有 Uu 口接收感知数据。核心网侧则根据感知处理网元是否合设，决定是否设置专有感知接口。我一般会建议先走复用 Uu 口的路线，因为改造成本低，现网设备基本不需要动硬件。

下面这张表把广域场景的关键决策点列清楚：

注意：广域场景下感知数据的回传会占用空口资源，规划时要预留上行带宽余量，否则通信业务会被感知数据挤占。

2.2 局域场景：核心网下沉与 UPF 部署的取舍

局域场景主要面向园区这类封闭环境，文档强调两个约束：与现有本地化网络的衔接性，以及信息保密性要求。方案是在局域网范围内设置感知处理网元，同时可以按需与公网协作。

这里的关键操作是核心网网元下沉。文档明确提到可以按需求将 UPF 等网元或整个局域核心网一起下沉，目的是实现低延时高可靠。我拆解下来的落地步骤是这样的：

第一步，确认园区业务对时延的容忍度。如果感知数据需要在本地闭环处理，UPF 必须下沉；如果只是采集后回传公网处理，UPF 可以留在核心网。

第二步，确定感知处理网元的位置。局域场景建议独立设置，因为园区业务往往有数据不出园区的合规要求。

第三步，设计公网协作接口。文档提到“按照需求与公网进行协作”，这个接口的带宽和协议要在规划阶段就定好，不然后期扩容很被动。

# 局域场景核心网下沉的规划检查清单（以 UPF 下沉为例） # 1. 确认园区侧机房条件：机柜空间、供电、散热 # 2. 确认回传链路带宽：感知数据上行 + 通信业务上行 # 3. 确认 UPF 下沉后的 N4 接口走向：本地 SMF 还是公网 SMF # 4. 确认感知处理网元与 UPF 的连接方式：同机房直连还是跨机房 # 5. 确认数据不出园区的合规边界：哪些数据必须本地处理

这段清单不是命令，而是规划阶段必须逐项确认的参数。第 2 项的回传带宽最容易翻车——很多人只算了通信业务带宽，忘了感知数据是持续回传的，尤其是成像类业务，上行占用比定位类高一个数量级。

2.3 两套架构的共性约束与差异对比

广域和局域两套架构虽然场景不同，但共享同一个设计原则：不改变现有 5G 网络架构，只做网元功能增强或新增。差异在于感知处理网元的位置和核心网下沉程度。

广域场景优先考虑移动性，所以感知网元放在核心网较高层级；局域场景优先考虑时延和保密，所以核心网下沉、感知网元本地化。如果你在做混合场景规划，比如城市级广域覆盖加园区级局域增强，建议把两套架构的接口对齐，避免后期融合时出现协议不兼容。

3. 6G 通感融合架构：高低频协同与算力网络两种推演

6G 的网络架构目前尚未明确，文档对 6G 通感融合的讨论是“架构建议”而非“标准方案”。它抓住两个 6G 较为明确的特征——多频谱和算力网络——提出了两种架构方向。这一章对做 6G 预研的人价值最大，因为它是从 5G-A 的“不改架构”往前推了一步，开始动频谱和算力了。

3.1 高低频协同：低频触发感知、高频精细成像

文档对高低频的分工说得很直白：低频覆盖广但带宽小、波束资源少，感知能力有限；高频带宽大、多径丰富，成像和定位效果好，但覆盖小、对障碍物敏感。所以 6G 通感融合的一个自然选择是高低频联合部署。

具体架构设计是这样的：低频基站内添加简单的感知多径变化判别功能模块和感知触发识别功能，完成初次感知和特发情况触发；高频基站上添加感知功能，实现通信不间断、感知随机应变；另外设置感知服务器做综合处理。

这个分工的逻辑是：低频基站先做粗粒度感知，发现目标或异常后触发高频基站做精细感知。这样既发挥了低频的覆盖优势，又避免了高频一直开机带来的能耗和资源浪费。

落地时要注意几个参数边界：

注意：低频触发门限设得太低会导致高频频繁启动，能耗和干扰都上去了；设得太高又会漏检。这个门限没有理论最优值，必须根据现场多径环境实测调整。

3.2 算力网络：感知数据的分级分层处理

文档对算力网络的定义是“根据业务需求，在云、网、边之间按需分配和灵活调度计算资源、存储资源以及网络资源”。放到通感融合架构里，核心思路是在终端、基站和核心网等网元分别做力所能及的感知数据处理，分级分层把处理结果叠加，完成感知数据集约化，节省空口资源。

这个思路解决的是一个很实际的问题：感知数据量太大，全部回传核心网会压垮回传链路。所以要在靠近数据源的地方先做一轮处理，只把中间结果往上送。

我一般会按这个原则划分处理层级：

终端侧：做最简单的信号强度判断和初步滤波，只上报超过门限的感知事件，不上报原始数据。

基站侧：做多径特征提取和目标粗定位，把原始回波转成结构化数据，数据量能降一个数量级。

核心网侧：做多基站数据融合和最终定位/成像输出，这里才需要完整算力。

# 感知数据分级处理的伪代码逻辑（用于规划阶段估算回传带宽） # 假设：原始回波数据量 = 100%，终端滤波后 = 30%，基站特征提取后 = 5% def estimate_backhaul(raw_data_rate_mbps, terminal_filter_ratio=0.3, base_station_extract_ratio=0.05): """ raw_data_rate_mbps: 原始感知回波数据速率 terminal_filter_ratio: 终端滤波后保留比例 base_station_extract_ratio: 基站特征提取后保留比例 """ after_terminal = raw_data_rate_mbps * terminal_filter_ratio after_base_station = raw_data_rate_mbps * base_station_extract_ratio return { "原始数据速率": raw_data_rate_mbps, "终端滤波后": after_terminal, "基站提取后": after_base_station, "回传节省比例": 1 - after_base_station / raw_data_rate_mbps } # 示例：原始 1000Mbps 回波，基站提取后只剩 50Mbps，回传节省 95% result = estimate_backhaul(1000) print(result)

这段代码不是实际部署用的，而是规划阶段用来估算回传带宽的。关键参数是terminal_filter_ratio和base_station_extract_ratio，这两个值取决于感知业务类型——定位类业务提取后数据量小，成像类业务提取后仍然较大。我一般会按最坏情况估算，留 30% 余量。

3.3 两种 6G 架构的适用边界

高低频协同架构适合频谱资源丰富、可以高低频混合部署的场景，核心难点是触发门限和站址协同。算力网络架构适合算力资源分布不均、回传带宽受限的场景，核心难点是分级处理的接口标准化。

两种架构并不互斥。文档在 6G 部分把它们并列提出，实际部署中完全可以叠加——高低频做感知分层，算力网络做数据处理分层。如果你在做 6G 预研汇报，建议把这两条线分开讲，因为它们的依赖条件不同：高低频协同依赖频谱政策，算力网络依赖算力基础设施。

4. 通感融合三大关键技术：波形、全双工、超大规模天线的参数边界

文档第 3 章列了三类关键技术：新型一体化波形、面向通感融合的全双工技术、超大规模天线与智能化天线阵列。这三项决定了通感融合的可行性上限，也是做技术选型时绕不开的硬骨头。

4.1 新型一体化波形：OFDM 折中还是全新设计

波形设计有两个方向：一是采用现有波形的折中选择，二是采用全新波形。文档对 OFDM 的评价是“可以满足一定的通信和感知需求，但是需要进行带宽和帧结构的改变”。全新波形则是要把雷达波形更深层次地融入通信波形。

这里的关键参数是带宽和帧结构。通信追求频谱效率，感知追求距离分辨率，两者对帧结构的要求不同。OFDM 折中方案的本质是在帧结构里插入感知专用符号或调整子载波间隔，代价是通信吞吐量会下降。

我一般会按这个顺序做波形选型判断：

第一，确认感知业务类型。定位类业务对波形要求低，OFDM 折中方案基本够用；成像类业务需要大带宽和特定波形，可能要等全新波形成熟。

第二，确认频谱资源。如果可用带宽本来就紧张，折中方案会进一步压缩通信容量，需要算清楚账。

第三，确认设备能力。全新波形意味着基带和射频都要换，现网设备能不能升级是硬约束。

注意：波形选型不是纯技术问题，它直接决定设备投资规模。折中方案可以复用现有设备，全新波形基本等于新建网络。

4.2 全双工技术：回环干扰是最大拦路虎

文档对全双工的评价很高：高频谱利用率、高安全性，理想情况下频谱利用率比半双工提升一倍。但它也明确指出最大的问题是回环干扰噪声——同时接收和发送同频信号，发送信号被自身接收天线接收，而且有用信号和回环干扰的强度差别很大，导致难以直接解码。

全双工在通感融合里的价值在于：感知需要同时且连续地发送和接收，TDD 模式做不到同时接收，FDD 可以用但仅限低频且资源利用率低。所以全双工是解决高效能通信和高精度感知的较优技术路线。

但落地难度在于干扰消除。文档提到非理想干扰消除和用户间干扰增强两个问题。我拆解下来的排查思路是：

现象：全双工节点接收端信噪比恶化，有用信号无法解码。 原因：回环干扰噪声强度远高于有用信号，且干扰消除不理想。 解决：先做天线隔离度优化，再上射频干扰消除，最后做数字域消除。三级消除后如果还不够，说明设备能力到顶了，需要换方案。

这个排查顺序不能反。很多人一上来就调数字消除算法，但天线隔离度不够的话，数字域根本救不回来。

4.3 超大规模天线：从信道建模到智能波束

文档列了超大规模天线的五个研究方向：超大规模信道建模与低复杂度信道估计、以用户为中心的分布式大规模天线、新型天线材料与系统架构融合、智能化超大规模天线、空间精准定位与感知。

对做通感融合的人来说，最直接相关的是第五项——空间精准定位与感知。文档提到超大规模天线可以把波束调整到尽量高的强度，窄带部署可以在感知中获得更强的回波信息，对感知物体的位置和外形做较精度的感知。

这里的参数边界在于波束宽度和扫描周期的权衡。波束越窄，感知精度越高，但扫描同样空域需要的时间越长。如果感知目标是移动的，扫描周期太长会导致目标丢失。

我一般会建议先用宽波束做全域粗扫，发现目标后再切换到窄波束做精细感知。这个逻辑和高低频协同里的“低频触发、高频精细”是一致的，只是从频段维度换到了波束维度。

5. 通感融合方案落地避坑：五条血泪经验

这一章把前面架构和技术里容易翻车的地方集中列出来。每条都按“现象→原因→解决”写，方便你直接对照排查。

现象一：广域场景下感知数据回传挤占通信业务，上行速率明显下降。原因：复用 Uu 口接收感知数据时，没有为感知数据预留独立的调度资源，感知和通信抢同一块上行带宽。 解决：在 MAC 层为感知数据配置独立的逻辑信道和调度优先级，或者规划阶段就预留 20% 以上的上行余量。如果现网已经出现挤占，先限流感知数据上报频率，再补做资源预留。

现象二：局域场景核心网下沉后，园区内感知业务正常，但跨园区协作失败。原因：下沉的 UPF 和感知处理网元只配了本地路由，没有规划与公网的协作接口，或者接口协议不兼容。 解决：在规划阶段就定义好公网协作接口的协议栈和带宽，下沉网元预留 N6 或专用接口。已经部署的，通过新增接口板或软件升级补上。

现象三：6G 高低频协同架构中，高频基站频繁启动，能耗和干扰都超标。原因：低频触发门限设得太低，或者低频感知的多径判别算法过于敏感，把噪声当成了目标。 解决：先抓一段低频感知的原始数据，看触发事件的时间分布。如果是密集触发，把门限往上调；如果是误触发，优化多径判别算法，增加确认机制。

现象四：全双工节点干扰消除后，通信质量恢复但感知精度下降。原因：干扰消除算法把有用信号的一部分也消掉了，尤其是当有用信号和回环干扰在时域上重叠时。 解决：调整干扰消除的参考信号设计，让消除算法能区分回环干扰和有用信号。如果设备不支持，只能在通信和感知之间做折中，降低全双工同时收发的占空比。

现象五：超大规模天线窄波束扫描时，移动目标丢失。原因：窄波束扫描周期太长，目标在扫描间隙移出了波束覆盖范围。 解决：改用宽波束粗扫加窄波束精扫的分级扫描策略，或者根据目标移动速度动态调整波束宽度和扫描周期。高速目标用宽波束跟踪，低速目标用窄波束精测。

注意：这五条里，前两条是规划阶段可以避免的，后三条是技术选型阶段需要权衡的。规划阶段的坑最好在方案评审时就排掉，技术选型的坑要在设备选型测试时验证。

6. 从文档到方案：把架构图转成可评审的技术选型表

文档里的架构图是静态的，但实际方案评审时，评审专家不会只看架构图，他们会追问每个网元的功能边界、接口协议、参数取值。我一般会把文档里的架构描述转成一张技术选型表，逐项填参数，填不出来的就是方案缺口。

以 5G-A 广域场景为例，转出来的选型表长这样：

填这张表的过程，就是把文档里的“可以”“建议”变成“必须”“具体数值”的过程。填不出来的项，就是方案评审时会被追问的项，也是你提前要准备答案的项。

再以 6G 算力网络架构为例，选型表要加上算力分层：

这张表的关键参数是“回传数据量”和“时延要求”。终端到基站的回传时延要求极低，因为感知事件需要快速触发；基站到核心网的时延要求相对宽松，因为融合处理可以稍慢。如果时延要求填不出来，说明感知业务的服务质量等级还没定义清楚，需要先补业务定义。

最后说一个我自己的习惯：每次拿到这类架构文档，我不会直接开始写方案，而是先画一张“网元-接口-参数”的三列表，把文档里提到的每个网元、每个接口、每个参数都填进去。填完之后，缺口一目了然，评审时也不会被问住。从那以后我每次做通感融合方案都强制走一遍这张表，省了很多返工。希望帮到你。

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