企业官网建设流程全解析

简介：《通感一体化系统架构与关键技术》白皮书聚焦第六代移动通信中的通信感知一体化方向，面向移动通信研究者、标准制定者及无线网络工程师，系统梳理通感融合的业务分类、性能指标、标准组织进展与端到端技术方案。全文以单个 PDF 文件收录，压缩包约 11.23 MB，内容完整、便于存档与按需查阅，适合作为 6G 前沿方向的参考书。目前已有 74 人学习浏览，对希望快速建立通感一体化体系化认知的读者而言，具备良好的参考价值。内容覆盖系统架构中的融合层级与服务模型，并重点剖析一体化波形设计、多天线感知、网络协作通感、感知非理想因素消除、多频点协作感知、移动性管理以及智能超表面辅助通感等空口关键技术，既能呈现宏观框架，也能落到具体技术难点，有助于读者把握 6G 通感研究脉络。

1. 通感一体化到底在做什么：基站从“传数据”到“看环境”

通感一体化（ISAC，Integrated Sensing and Communication）这名字听起来很轻巧，好像让基站同时传数据、看环境，但真按系统架构去推一遍，你会发现它其实是把通信和感知硬塞进同一套射频通道、同一段时频资源里。通信要的是高吞吐、低时延，感知要的是距离分辨率、多普勒分辨率和检测概率，两边不是白送的，是在同一个硬件上互相挤出来的。这一轮 5G 关键技术演进里，5G-A 和 6G 都把它当候选能力，落地场景集中在智慧路口、低空监测、周界安防这些“要覆盖但不方便再架雷达”的地方。

这篇笔记不聊 PPT，直接拆两件事：系统架构怎么分层，关键技术怎么选型。我会沿用做预研项目时的口径，给出可落地的处理链、参数建议和踩坑记录，适合正在做通感预研、现网改造评估和系统集成的工程师参考。

2. 系统架构的四层参考模型：从射频通道到感知数据上送的每个节点

2.1 架构出发点：通信网络不是加了一个雷达，而是加了一个感知维度

做通感一体化系统架构时最常见的一个误区，是把雷达当作一个独立子系统，跟基站拼在一起。天线共用、基带各跑各的，这只能叫收发共存，不是一体化。ISAC 的出发点是在已有的通信网元上增加一个感知维度：基站本来就具备发射、接收、波束赋形、资源调度的能力，这些能力在通信视角下的产物是吞吐率和时延，在感知视角下的产物就是距离、速度、角度和检测概率。

这个定位决定了架构长什么样。不需要发明新的网元，需要改造的是基站侧的处理链路、资源管理层，以及上层的协同数据服务。做预研时我一般先把“感知维度”落到一张图上，标注每一层通信任务和感知任务分别占用什么资源、产出什么数据、往哪个接口送。先画完这张图再讨论算法，否则后续很容易出现“算法很漂亮、数据拿不到”的尴尬局面。

2.2 四层参考模型的职责划分与接口

我目前比较常用的通感系统架构是四层模型，分别覆盖射频、信号处理、资源管理和网络协同。下面表格是架构的核心内容，做方案评审时可以直接拿去对齐：

L1 层最容易翻车的是自发自收问题：基站自己发射的通信信号功率高，回波信号通常比它低 60dB 以上，接收通道如果没做隔离和干扰对消，感知处理看到的全是自己发射信号的影子。L2 层是四层里工作量最大的，后面专门用一章讲信号处理链。L3 层容易被忽略，但它直接决定通信和感知怎么分资源：感知任务不能跟普通用户业务抢物理资源块，否则调度一忙感知延迟就乱跳，这部分在第 5 章会展开。L4 层决定业务方拿到的数据是什么形态，是点迹还是航迹，是原始 IQ 还是已经聚合好的目标列表，直接影响到 MEC 侧应用的开发复杂度。

2.3 MEC 与核心网侧的“接得住”问题

架构推到 L4 层，遇到的实际问题不再是信号处理，而是数据上送。感知数据有三种交付级别：点迹级、航迹级、特征级。点迹级是单次扫描的目标测量结果，适合做多站融合和跨站跟踪；航迹级是经过跟踪滤波后的连续轨迹，时延低但信息量少；特征级则是目标的 RCS、微多普勒这类扩展属性，适合做目标识别。

现网改造方案里我一般建议 MEC 侧接收点迹级数据，原因有两条。一是点迹级数据保留的信息最多，跟踪算法放在 MEC 侧跑，不占用基站算力；二是点迹级上报天然解耦，基站这一帧没检测到目标就少上送几条记录，不会像航迹级那样出现“前后航迹跳变”的坑。上报链路建议直接走 HTTP/2 或 gRPC，不建议走传统北向网管接口，因为感知数据是高频小包，网管协议包的封装开销太大。时延预算上，从回波采集到点迹到达 MEC，端到端 100ms 以内，超过这个量级很多应用就失去意义了。

3. 波形与信号处理链：三种实现路线和必须先定的四个参数

3.1 三种波形路线怎么选

波形选型是通感一体化里第一个要拍板的技术决策，它同时决定感知性能和通信兼容性。业内主流路线有三条，各有利弊，不能只盯着论文里的感知指标。

现网项目我一般建议选 OFDM 透传作为起点。理由很实际：不需要动终端，不需要改帧结构，基站内部加一路回波接收和处理模块就能出原型。它的问题是感知性能受制于通信波形的随机性，特别是数据负载部分不能直接做相干积累，只能依赖导频和参考信号。赋能可行性的做法是，把某些 CSI-RS 资源在时域上做重复强化，提高感知积增益。预研性质、追求最优感知性能的项目，再上专用感知帧，这条路是目前学术界往 6G 推的主要方向，但协议改动太大，短期内进不了存量网络。

3.2 “一张资源网格变成目标点迹”的处理链

不管选哪种波形，从基带拿到 IQ 数据到输出目标点迹，处理链是相对固定的。以 OFDM 透传为例，处理链分五步：

第一步，从接收信号中做 OFDM 解调，去掉循环前缀后做 FFT，得到频域接收符号。这里要注意，感知用的频域数据要拿已知导频位置的数据做归一化，消除发射信号本身幅度和相位的影响。

第二步，沿子载波维做 IFFT，得到距离维的时延剖面，每个峰对应一个反射路径。OFDM 在这里天然类似 FMCW 雷达，子载波间隔对应距离不模糊范围，占用带宽决定距离分辨率。100MHz 带宽下距离分辨率大约 1.5m，想分辨更近的目标就要宽带和载波聚合。

第三步，沿慢时间维做 FFT，得到多普勒维速度信息。慢时间维就是连续多个 OFDM 符号在同一个子载波上的相位变化，目标运动会让相位线性变化，FFT 后的峰值位置对应多普勒频移。子载波间隔越高，最大不模糊多普勒越大，但代价是覆盖距离缩短。

第四步，把二维热图送进 CFAR（恒虚警检测）模块，按噪声水平自适应地找峰值。CFAR 里最常用的是 CA-CFAR（单元平均），先在被检测单元周围取一组参考单元估计噪声功率，再乘一个门限因子得到判决门限。虚警概率一般设置在 1e-6 量级，门限因子在 10~15 之间，具体值要看现场噪声环境。

第五步，对检测出的峰值做角度估计。常见做法是数字波束形成，扫描天线阵列的各个指向看哪个方向能量最大；高精度场景可以上子空间类算法，但计算量会明显升高，基站侧做实时处理时要提前评估算力余量。

3.3 四个必须先定的参数

处理链跑通之前，有四个参数是我每次都会被问到、也是调试时最容易反复试的：

这几个参数里，感知时频资源占比是最容易拍脑袋的地方。我的经验是不要一开始就追求感知指标，先把通信和感知的资源边界画出来，用最小资源跑通全链路，再逐步加大感知资源占比。加到 10% 以上时一定要同步看通信吞吐的实测值，很多项目最后停下来不是因为感知做不出来，而是通信指标被压得太难看，整个方案被否决了。

4. 基于 5G 现网的最小通感改造：把感知点迹从基站送到 MEC

4.1 最小改造路径：只动基站和 MEC，不动终端

通感一体化在存量 5G 网络上的最小可行改造，是复用基站已发射的下行参考信号做环境感知，终端完全不感知自己正在“被环境探测”。基站利用 CSI-RS 的时频位置持续发射探测信号，这些信号经过周围物体反射后，由基站新增的回波接收通道采集，再在基带侧按第 3 章的处理链生成目标点迹。

工程上这一路改造需要动三个点。第一，射频侧加回波接收通道，从环形器或定向耦合器引出信号，注意回波信号远弱于发射信号，接收通道的动态范围要足够高。第二，基带侧加一个感知处理模块，接收频域数据后做距离-多普勒成像和 CFAR 检测，输出结构化点迹。第三，MEC 侧加一个感知数据订阅服务，接收基站上报的点迹数据，做汇聚、关联和应用分发。

这里有个原则要守住：感知处理模块不要物理上拆成一个独立板卡。放在基带内部、共享内存交换，可以避免额外的拷贝时延；独立板卡虽然调试方便，但多一次数据搬运，端到端时延很难控制在 100ms 以内。

4.2 MEC 上报通道怎么搭

你需要在基站侧提供一个点迹上报服务，而不是让感知数据往核心网的旧接口塞。下面是一个上报记录的示例：

{ "sensor_id": "cell_001_beam_3", "timestamp": "2025-06-18T10:30:15.120Z", "frame_id": 2048, "target_list": [ { "track_id": 0, "range_m": 23.5, "doppler_hz": 12.6, "angle_deg": 32.1, "rcs_sm": 1.2 }, { "track_id": 1, "range_m": 47.8, "doppler_hz": -5.4, "angle_deg": -12.7, "rcs_sm": 0.8 } ] }

上报数据结构里最容易被忽略的是sensor_id和frame_id。sensor_id要包含小区标识和波束编号，因为同一个小区多个波束会各自上报点迹，没有波束标识就没法判断点迹来自哪个覆盖方向；frame_id则用于多站融合时的时序对齐。那些“检测好好的，融合出来的轨迹却乱七八糟”的案例，多半是这两个字段在设计阶段被省掉了。

MEC 侧接收服务建议做成无状态接口，订阅方只通过 HTTP/2 或 gRPC 拉取数据，不要在基站侧维护订阅关系。MEC 单节点服务目标数量不超过 100 个点迹时，这个架构足够支撑智慧路口级别的场景。

4.3 算力放基站还是放 MEC

感知处理算法放哪一级执行，是通感架构里另一个争议比较大的点。放基站好处是时延低，原始数据不用出基站就能变成点迹；缺点是基站算力不足，特别是大规模天线阵列和多个波束同时感知时，距离-多普勒热图很大，基带侧无法持续全速跑。放 MEC 好处是算力弹性大，缺点是原始 IQ 数据上送带宽大，且默认 100ms 时延预算会进一步收紧。

我一般用两条规则划分任务：处理链里每一步的输入数据量如果超过输出数据量的 10 倍，就尽量往基站侧放；每一条点迹的生成时延要求如果低于 50ms，则必须在基站侧完成，不能上送原始数据。按这个规则，距离-多普勒成像和 CFAR 放基站，目标特征提取和跨站融合放 MEC，基站与 MEC 之间只流动目标点迹，既不浪费纤芯带宽，也能保住时延预算。

5. 通感一体化落地避坑：5 个让原型系统翻车的高频问题

5.1 感知距离总是比通信覆盖短一截

现象是通信扇区能覆盖到 500 米外，感知在 100 米左右就开始丢目标，再远就只剩噪声。

原因是感知回波按距离的四次方衰减，而通信信号只要从基站到终端单程一次衰减。同样发射功率下，感知的有效距离天然远小于通信覆盖，这不是射频硬件坏了。另外接收通道增益往往按通信信号幅度做自动增益控制，回波信号太弱直接被压低，进一步压缩感知距离。

解决方法是两条腿走路：接收通道做两路增益管理，通信链路和感知链路分别独立自动增益控制；然后用已知位置的标准反射体做标定，校准系统损耗后反推有效感知距离。如果标定完还是短，再考虑加大感知符号的积累时间，把相干积累增益提上去。

5.2 网络一忙，感知延迟就乱跳

现象是空闲时段感知点迹 30ms 出一帧，话务高峰变成 300ms 一帧，且没有任何规律。

原因是感知任务在资源调度器里的优先级太低。通信业务调度是现网的命脉，感知任务默认排在后续队列里，基站忙时感知资源块被全部抢走，感知模块只能反复等待空窗。

解决办法是在资源管理层给感知任务设独立资源预留池，比如预留 5% 的物理资源块，感知专用，通信业务不允许抢占。预留池大小要按最坏场景评估，不能只按平均话务量算，否则忙时照样被挤掉。另一个配套措施是感知任务按帧周期运行，比如每 20ms 必须跑一次，调度器把感知任务排在周期任务队列里，不参与普通队列的优先级竞争。

5.3 点迹坐标和现场地图对不上

现象是目标明明在马路上走，点迹却偏到路边建筑物里，或者站着一个静止的点迹会缓慢漂移。

原因是坐标系没对齐。基站天线测量出来的角度是以天线法向为基准的本地极坐标，地图用的是经纬度或平面直角坐标，两个坐标系之间有平移、旋转和尺度变化。很多团队一开始只做了一个简单角度偏移修正，没做完整坐标转换，点迹越远偏差越大。

正确做法是设三个标定点：用已知位置的三处反射体（楼角、灯杆、标志牌）在感知图像里找到对应点迹，用最小二乘估计坐标系变换矩阵，至少 6 个自由度全解开。标定点选取要覆盖近、中、远三个距离段，只做近距离标定会导致远距离外推误差偏大。

5.4 高速目标突然就丢，多普勒模糊和栅瓣作祟

现象是低速目标很稳，一旦目标速度超过某个阈值，点迹就消失或者跳到错误的角度。

原因是快时间维采样对应的是相参积累周期，多普勒频移超过采样率一半时发生模糊，目标折叠到低速区；而天线阵列阵元间距大于半波长时，波束扫描会出现栅瓣，目标真实角度会被栅瓣峰值掩盖，CFAR 检测时两个峰值打架。

解决办法是多普勒解模糊用多重重复频率：同一个感知任务交替采用两种慢时间采样间隔，两组间隔对应的最大不模糊速度不同，比对两轮结果就能解出真实速度。栅瓣问题要在天线设计阶段解决，阵元间距必须控制在半波长以内；如果硬件已经定了，就在数字波束形成阶段加窗抑制副瓣，但栅瓣位置是物理决定的，加窗只能减弱不能消除，必要时得放弃全向扫描只做有限扇区扫描。

5.5 回波太弱，室内小目标根本看不见

现象是同样的链路在室外百米能检测到行人，在室内十几米却经常漏检，尤其是墙角、金属门这类反射面积小的目标。

原因是室内环境存在大量多径，直射径和反射径混杂，目标回波被淹没在多径尾巴里；加上室内目标多为人体这种非理想反射体，RCS 比室外汽车小很多，信噪比根本不够。

解决手段按性价比排序：先加相干积累，增加慢时间维的积累符号数，把有效积分时间从一帧扩展到多帧，这一步能把信噪比抬升 10dB 以上；再做杂波图处理，对静止背景做动态背景相消，把墙、门、家具这些固定反射体从热图里抠掉，这样运动目标就露出来了。如果还不行，才是换高增益天线或加发射功率。

6. 验证与验收：室内场景把通感链路跑出可复现指标

6.1 最小验证场景怎么搭

验证通感链路不需要先搭一个完整的宏基站环境。我常做的最小验证场景是：一台安装了通感处理软件的信号处理平台，一条收发射频链路，一个可移动的金属反射板当作标定目标，在室内走廊里跑。发射信号直接复用平台生成的 OFDM 波形，接收通道采集回波数据，处理后输出点迹。目标沿着走廊缓慢移动，观察点迹是否连续跟随。

这个场景能验证的边界是：链路是否打通、点迹是否可重复、参数设置是否合理。它不能验证的是：室外远距离覆盖、多目标区分、真实目标识别。标定目标不要选金属板，选角反射器会更好，因为角反射器的 RCS 在宽角度范围内都稳定，测量到的距离和角度不会随目标转动而剧烈抖动。

6.2 距离-多普勒热图的 Python 参考实现

处理链里最核心的一段逻辑可以直接用 Python 跑通，方便实测时快速判断链路状态：

import numpy as np # iq: 二维数组 [num_symbols, num_subcarriers] # 每一行是一个 OFDM 符号，每一列是一个子载波的频域响应（已完成导频校正） def compute_range_doppler(iq, range_fft_len=256, doppler_fft_len=256): # 距离维：对每个符号沿子载波做 IFFT，得到时延剖面 range_profile = np.fft.fftshift( np.fft.ifft(iq, range_fft_len, axis=1), axes=1 ) # 多普勒维：对同一子载波位置沿慢时间做 FFT，得到多普勒 range_doppler = np.fft.fftshift( np.fft.fft(range_profile, doppler_fft_len, axis=0), axes=0 ) return np.abs(range_doppler) # 使用示例：100 个符号，64 个子载波的实测数据 result = compute_range_doppler(np.random.randn(100, 64)) # 输出热图后，用峰值搜索函数找目标，再对比标定位置

这段代码做了两个 FFT/IFFT 操作，对应处理链里的距离维和多普勒维。range_fft_len和doppler_fft_len之所以可以大于原始维数，是因为补零后热图像素更细，峰值定位精度更高，但要记住补零只做插值，不增加真实分辨率。找到峰值之后，把峰值位置换算成距离和速度，公式是距离等于时延索引乘光速再除两倍子载波间隔，速度则从多普勒频移反推。

这个参考实现的价值在于快速验证链路：如果一帧数据的距离-多普勒热图上能看到预期位置的峰值，说明射频、基带、同步整条链路是通的；如果热图是一片噪声，先查同步是不是拿通信信号同步去解感知回波，这是最常犯的错。

6.3 验收时看三个数

验证做完要能给出可复现的指标，而不是“看起来能检测到”。验收时主要看三个数：

这三个数对应的坑分别是：检测概率太低查积累时间和 CFAR 门限；虚警率压不下来大概率是噪声非平稳，需要加杂波图；吞吐损失超标则在资源预留池上做减配。我自己做这个方向的习惯是先把这三个数钉在测试报告里，每调一次参数都重新跑一遍，测出来的结果比代码本身更容易暴露架构问题——很多时候不是算法不行，是架构里某一层的数据没接住。希望帮到你。

我最后想补一句血泪经验：任何通感系统在做完架构设计后，第一优先级永远是“让数据从天线流到 MEC 界面”，而不是“让检测算法先跑到最好”。先跑通再优化，是这个方向带给我最大的推进效率提升。希望这条笔记能帮你少走几趟弯路。

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