简介《通感一体化系统架构与关键技术》白皮书聚焦第六代移动通信中的通信感知一体化方向面向移动通信研究者、标准制定者及无线网络工程师系统梳理通感融合的业务分类、性能指标、标准组织进展与端到端技术方案。全文以单个 PDF 文件收录压缩包约 11.23 MB内容完整、便于存档与按需查阅适合作为 6G 前沿方向的参考书。目前已有 74 人学习浏览对希望快速建立通感一体化体系化认知的读者而言具备良好的参考价值。内容覆盖系统架构中的融合层级与服务模型并重点剖析一体化波形设计、多天线感知、网络协作通感、感知非理想因素消除、多频点协作感知、移动性管理以及智能超表面辅助通感等空口关键技术既能呈现宏观框架也能落到具体技术难点有助于读者把握 6G 通感研究脉络。1. 通感一体化到底在做什么基站从“传数据”到“看环境”通感一体化ISACIntegrated Sensing and Communication这名字听起来很轻巧好像让基站同时传数据、看环境但真按系统架构去推一遍你会发现它其实是把通信和感知硬塞进同一套射频通道、同一段时频资源里。通信要的是高吞吐、低时延感知要的是距离分辨率、多普勒分辨率和检测概率两边不是白送的是在同一个硬件上互相挤出来的。这一轮 5G 关键技术演进里5G-A 和 6G 都把它当候选能力落地场景集中在智慧路口、低空监测、周界安防这些“要覆盖但不方便再架雷达”的地方。这篇笔记不聊 PPT直接拆两件事系统架构怎么分层关键技术怎么选型。我会沿用做预研项目时的口径给出可落地的处理链、参数建议和踩坑记录适合正在做通感预研、现网改造评估和系统集成的工程师参考。2. 系统架构的四层参考模型从射频通道到感知数据上送的每个节点2.1 架构出发点通信网络不是加了一个雷达而是加了一个感知维度做通感一体化系统架构时最常见的一个误区是把雷达当作一个独立子系统跟基站拼在一起。天线共用、基带各跑各的这只能叫收发共存不是一体化。ISAC 的出发点是在已有的通信网元上增加一个感知维度基站本来就具备发射、接收、波束赋形、资源调度的能力这些能力在通信视角下的产物是吞吐率和时延在感知视角下的产物就是距离、速度、角度和检测概率。这个定位决定了架构长什么样。不需要发明新的网元需要改造的是基站侧的处理链路、资源管理层以及上层的协同数据服务。做预研时我一般先把“感知维度”落到一张图上标注每一层通信任务和感知任务分别占用什么资源、产出什么数据、往哪个接口送。先画完这张图再讨论算法否则后续很容易出现“算法很漂亮、数据拿不到”的尴尬局面。2.2 四层参考模型的职责划分与接口我目前比较常用的通感系统架构是四层模型分别覆盖射频、信号处理、资源管理和网络协同。下面表格是架构的核心内容做方案评审时可以直接拿去对齐层级通信侧职责感知侧职责对外接口与数据交付L1 射频与天线层收发波束赋形、射频通道校准回波接收通道、自发自收隔离数字 IQ 数据送往基带处理单元L2 感知信号处理层OFDM 解调、信道估计、MIMO 检测距离-多普勒热图生成、CFAR 检测、DOA 估计目标点迹距离、速度、角度、RCS 特征L3 资源与任务管理层时频资源分配、波束调度、优先级管理感知任务周期管理、感知 QoS 保障感知任务调度请求与资源占用反馈L4 网络协同与数据层与核心网交互、移动性管理多站感知数据融合、跨站跟踪点迹/航迹数据上报至 MEC 或应用平台L1 层最容易翻车的是自发自收问题基站自己发射的通信信号功率高回波信号通常比它低 60dB 以上接收通道如果没做隔离和干扰对消感知处理看到的全是自己发射信号的影子。L2 层是四层里工作量最大的后面专门用一章讲信号处理链。L3 层容易被忽略但它直接决定通信和感知怎么分资源感知任务不能跟普通用户业务抢物理资源块否则调度一忙感知延迟就乱跳这部分在第 5 章会展开。L4 层决定业务方拿到的数据是什么形态是点迹还是航迹是原始 IQ 还是已经聚合好的目标列表直接影响到 MEC 侧应用的开发复杂度。2.3 MEC 与核心网侧的“接得住”问题架构推到 L4 层遇到的实际问题不再是信号处理而是数据上送。感知数据有三种交付级别点迹级、航迹级、特征级。点迹级是单次扫描的目标测量结果适合做多站融合和跨站跟踪航迹级是经过跟踪滤波后的连续轨迹时延低但信息量少特征级则是目标的 RCS、微多普勒这类扩展属性适合做目标识别。现网改造方案里我一般建议 MEC 侧接收点迹级数据原因有两条。一是点迹级数据保留的信息最多跟踪算法放在 MEC 侧跑不占用基站算力二是点迹级上报天然解耦基站这一帧没检测到目标就少上送几条记录不会像航迹级那样出现“前后航迹跳变”的坑。上报链路建议直接走 HTTP/2 或 gRPC不建议走传统北向网管接口因为感知数据是高频小包网管协议包的封装开销太大。时延预算上从回波采集到点迹到达 MEC端到端 100ms 以内超过这个量级很多应用就失去意义了。3. 波形与信号处理链三种实现路线和必须先定的四个参数3.1 三种波形路线怎么选波形选型是通感一体化里第一个要拍板的技术决策它同时决定感知性能和通信兼容性。业内主流路线有三条各有利弊不能只盯着论文里的感知指标。波形方案实现思路感知性能通信开销商用落地难度OFDM 透传直接复用通信 OFDM 波形用导频或参考信号做感知中模糊函数受数据随机性影响低占用少量导频资源低现网改动最小时分复用在帧结构里划分专门的感知时隙感知时隙发专用探测波形高波形可自由设计高占用下行时隙中需要改帧结构专用感知帧引入新波形如 OTFS 方向在同一帧内服务于双任务高时延-多普勒分辨能力突出低到中高协议和终端都要动现网项目我一般建议选 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 四个必须先定的参数处理链跑通之前有四个参数是我每次都会被问到、也是调试时最容易反复试的参数建议取值范围设置依据感知时频资源占比3%~10%从 5% 起步通信吞吐损失可控制在可接受范围导频/参考信号密度每隔 4~8 个资源块保留一个感知导频块密度太低感知分辨率不够太高挤占业务数据波束数量8~32 个目标覆盖范围和单波束刷新率之间取平衡CFAR 门限因子10~15门限太低虚警多太高漏检多需结合虚警概率指标反推这几个参数里感知时频资源占比是最容易拍脑袋的地方。我的经验是不要一开始就追求感知指标先把通信和感知的资源边界画出来用最小资源跑通全链路再逐步加大感知资源占比。加到 10% 以上时一定要同步看通信吞吐的实测值很多项目最后停下来不是因为感知做不出来而是通信指标被压得太难看整个方案被否决了。4. 基于 5G 现网的最小通感改造把感知点迹从基站送到 MEC4.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_len256, doppler_fft_len256): # 距离维对每个符号沿子载波做 IFFT得到时延剖面 range_profile np.fft.fftshift( np.fft.ifft(iq, range_fft_len, axis1), axes1 ) # 多普勒维对同一子载波位置沿慢时间做 FFT得到多普勒 range_doppler np.fft.fftshift( np.fft.fft(range_profile, doppler_fft_len, axis0), axes0 ) 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 验收时看三个数验证做完要能给出可复现的指标而不是“看起来能检测到”。验收时主要看三个数指标建议阈值测试方法检测概率标称距离内 ≥ 90%目标在设定位置移动 100 次统计检出次数虚警率≤ 1e-6无目标场景运行 10 分钟统计错误点迹数通信吞吐损失≤ 10%开启感知功能前后分别测峰值吞吐率这三个数对应的坑分别是检测概率太低查积累时间和 CFAR 门限虚警率压不下来大概率是噪声非平稳需要加杂波图吞吐损失超标则在资源预留池上做减配。我自己做这个方向的习惯是先把这三个数钉在测试报告里每调一次参数都重新跑一遍测出来的结果比代码本身更容易暴露架构问题——很多时候不是算法不行是架构里某一层的数据没接住。希望帮到你。我最后想补一句血泪经验任何通感系统在做完架构设计后第一优先级永远是“让数据从天线流到 MEC 界面”而不是“让检测算法先跑到最好”。先跑通再优化是这个方向带给我最大的推进效率提升。希望这条笔记能帮你少走几趟弯路。本文还有配套的精品资源点击获取