简介《3GPP TR 38.901-e30》是3GPP RAN发布的技术报告聚焦0.5–100 GHz频段信道模型研究面向5G NR通信系统设计、标准制定与无线信道仿真人员。报告系统梳理了信道分类、多径传播、空间衰落、动态环境及信道状态信息获取等核心问题为设备制造商与研究人员校核链路级和系统级仿真提供共同框架。资源为doc单文件大小5.88MB内容完整收录V14.3.0版正文包含从低频到毫米波的信道建模参数、测量与仿真方法说明可直接作为课题参考和实验设计的依据。已有1610人学习下载适合需要深入理解5G信道特性、开展标准化研究或验证自建信道模型的工程技术人员。1. 为什么一看到 38901-e30 就知道这是一个值得复现的信道基线做 5G 无线仿真的人对 3GPP TR 38.901 应该不陌生。e30 是这份技术报告在发布体系里的一个稳定版本标识它把 0.5 GHz 到 100 GHz 的频率范围统一纳入了同一套信道建模框架覆盖城市宏站、微站、室内、车联网等主流场景。我最早接触它是在一个系统级仿真项目里当时需要评估一套大规模天线阵列在城区非视距环境下的性能直接去采集射线追踪数据既不现实也不可控最后就是用这版模型的参数生成多径信道把研发周期从两个月压缩到一周所以在标题里看到 e30我第一反应是“这套信道基线可以抄作业了”。这篇文章不是复述标准公式而是从落地角度讲清楚 38.901 怎么选场景、怎么配参数、怎么把输出接到链路级仿真里。适合三类人看做系统级仿真的算法工程师、做波束管理和定位的协议工程师以及刚开始搭信道仿真软件的研究生。新手可以按步骤复现熟手可以在参数边界和踩坑记录里对照自己的配置。2. 38.901 的建模骨架簇、射线、大尺度参数如何撑起一个信道38.901 的价值不在公式推导而在于它给了工程一个可实施的信道生成流程。你不需要人工勾勒城市三维地图只需要按场景抽取一组统计参数就能生成一条空间相关的多径信道。这一章先把骨架搭明白后面配参数时你才知道哪些能改、哪些不能乱动。2.1 从簇到射线用统计几何代替场景建模38.901 的建模对象不是具体的建筑墙面而是传播环境里的散射体几何。标准把多径分成两部分宏观的簇cluster和微观的射线ray。每个簇代表一大批不可分辨的散射路径它们功率集中、时延接近每条射线则代表簇内一条可分辨的子径标准里通常每个簇生成 20 条射线具体数值因场景选择不同。发射端到接收端的信道就用这些簇和射线在三维空间的出发角、到达角、时延、复数幅度描述出来。这种做法的核心好处是计算复杂度可控。系统级仿真里面对成百上千个终端如果逐个建筑物建模光内存和射线求交就撑不住用随机几何只需要按场景统计分布抽取时延扩展、角度扩展、阴影衰落这些参数再合成空间相关信道。代价是精度不如确定性射线追踪但对链路级和系统级评估来说这个精度足够而且可复现性更强——同一组随机种子任何人都能得到一致的结果。在具体工程里簇和射线的区分会影响信道估计和波束管理验证。簇决定多径的“大结构”比如从基站发出的一束能量经过某栋建筑反射后到达终端射线决定簇内部的细小裂变。当你做波束对准时优先对齐到簇级别的角度方向而不是逐射线处理否则计算量和开销都会失控。这也是 38.901 和早期信道白噪声模型最大的差别它保留了空间角度信息。2.2 大尺度参数路损、阴影衰落与穿损的查表与插值大尺度参数决定链路的平均接收功率。38.901 对每个场景给出一组表格和拟合曲线比如城市宏站UMa的近距离路径损耗指数、阴影衰落标准差以及不同频段下的断点距离修正。标准同时给出 O2I室外到室内穿透损耗的频段和入射角修正在评估室内用户时这一步很容易被漏掉导致整条链路的 SINR 偏高波束管理算法得出过度乐观的结果。使用这些参数时我一般会先写一个查找函数输入场景名称、载波频率、水平距离和建筑物类型输出为大尺度参数。特别注意室内/室外交界处穿透损耗的随机分布要单独做一次采样而不是简单加一个常数。38.901 对 O2I 定义了低损耗、高损耗两类建筑模型每类还有不同的入射角因子如果你所在项目既评估写字楼也评估厂房建议把这两套参数都做成配置项切换场景时自动选择而不是把两套数据混在一起。大尺度参数还有一个容易混淆的地方路径损耗公式里通常分子用了“自由空间路径损耗 额外损耗”的分段形式低频和高频下的断点距离不同。3.5 GHz 和 28 GHz 的断点可能差出一倍以上如果你直接改载波频率而不重查表格路损曲线会在断点处出现不连续的跳变。这在系统级仿真是灾难因为小区边缘的接入成功率会异常波动。2.3 小尺度参数时延、角度扩展与信道系数生成流程小尺度参数建立在簇概念之上。标准里对每个簇分配平均时延、时延扩展、出发角和到达角的扩展量然后生成簇内射线。信道系数 H 由簇乘以射线的叠加得到每一径的相位在 0 到 2π 之间随机生成幅度由簇功率谱决定。这一套流程可以拆成四步采样大尺度参数 - 生成簇-射线的延迟/角度统计量 - 根据天线阵列方向图计算每径的空间响应 - 叠加生成 H 矩阵。参数典型默认值在模型中的作用频率3.5 GHz / 28 GHz决定路损、穿透损耗、空间分辨率场景UMa / UMi / InH决定大尺度参数统计表LOS 状态LOS / NLOS决定时延扩展、角度扩展、K 因子簇数8~12决定多径簇数量影响信道稀疏度每簇射线数20决定小尺度衰落纹理和反射细节延迟缩放因子2.0~3.0控制簇间时延扩散程度表中延迟缩放因子是一个很敏感的参数。它取值偏大时时延扩展会被拉得很开在宽带系统里可能产生大量稀疏抽头取值偏小时多径挤在一起信道频率选择性下降。标准里对不同场景给过拟合值但实际工程中我经常要围着它做敏感性分析先把延迟缩放因子设成场景默认值跑一遍再上下浮动 20% 看对吞吐的影响这样能快速判断系统性能对信道时延扩展的敏感度而不是死守一个固定值。理解 H 矩阵的结构也很重要H 的维度通常是接收天线数乘以发射天线数乘以路径数部分实现还会把时延采样单独放在第 4 维。你后续做信道估计、波束扫描、MIMO 检测都要和这个维度顺序打交道。所以拿到输出后第一件事不是画图而是确认维度约定否则后面每个算法都要改序。3. 用 e30 基线生成第一组信道冲激响应配置、代码与输出解读前面把模型骨架讲完这一章进入可操作流程。我用一个最小链路示例来演示从输入配置到生成 H 矩阵再到提取功率时延谱。这里的代码是接口示意具体函数名以你使用的实现为准但主干流程在 38.901 的各个封装库中几乎一致。3.1 三个必填输入项频点、场景拓扑和天线阵列跑 38.901 之前至少要把三个输入项想清楚。第一是载波频率它直接进入路损公式和簇生成过程中的角度扩展模型3.5 GHz 的模型参数和 28 GHz 有本质区别第二是场景拓扑包括宏站/微站/室内、LOS 还是 NLOS、基站和终端的高度与水平距离这些决定你查哪张统计表第三是天线阵列38.901 支持各向同性和有向方向图如果你不配置方向图默认按各向同性点源处理波束成型的增益差异就完全看不到。这三个输入里最容易忽略的是天线阵列。很多新手第一次跑通模型时发射端和接收端都用全向天线得到的 H 矩阵用于容量分析没问题但用于波束管理就完全失真因为波束增益、天线之间的互耦、极化分量全部没有。e30 版本对天线阵列相位响应描述得相对完整建议从一开始就至少配置一个 4×4 面阵或者 8 单元线阵哪怕方向图用简单的余弦模型也比全向天线有参考价值。3.2 最小链路生成代码从配置到 H 矩阵下面这段 Python 伪代码演示了单链路信道生成的关键参数和调用方式。实际使用中你可能会用不同的封装库但结构相似。# 3GPP TR 38.901 单链路生成示意函数名为通用接口占位 from channel_model import TR38901 cfg { frequency_hz: 3.5e9, # 载波频率3.5 GHz 中频 bandwidth_hz: 100e6, # 信号带宽100 MHz scenario: UMa, # 城市宏站 los: False, # NLOS 非视距 bs_height_m: 25.0, # 基站天线高度 ut_height_m: 1.5, # 终端高度手持或车载 distance_2d_m: 100.0, # 水平覆盖距离 num_clusters: 12, # 簇数可参考场景默认 rays_per_cluster: 20, # 每簇射线数 seed: 20240517, # 随机种子保证可复现 tx_array: {type: ula, num: 8, spacing: 0.5}, # 发端 8 单元线阵 rx_array: {type: ula, num: 4, spacing: 0.5}, # 收端 4 单元线阵 } model TR38901(**cfg) h model.generate_channel_coefficients() # h 的形状按顺序为: (接收天线, 发射天线, 簇内射线路径) print(h.shape)这里的关键是每个字段不是摆设。frequency_hz 和 bandwidth_hz 要严格分开频率决定传播特性带宽决定时延分辨能力。100 MHz 带宽下时延分辨率是 10 ns而 38.901 生成簇内射线的时延间隔远小于这个值所以后续必须做抽头合并否则直接使用原始路径时延会造成过密的图样。scenario 和 los 决定查哪套统计表UMa-NLOS 和 UMi-NLOS 的参数差异很大不能混用。种子 seed 必须显式设置否则每次运行生成的簇和射线完全不同很多实验对比会失真。tx_array 和 rx_array 里的 spacing 通常按波长比例给0.5 代表半波长间隔这个值决定阵列的空间相关性和波束宽度。如果你仿真的是更大的阵列比如 64 通道建议把 num 改成 64但计算量会成倍上升可以先在 8 通道下验证流程。3.3 输出怎么读延迟谱、角度谱、信道相关拿到 H 矩阵后先不要急着送入解调器先做一个直观检查。最常见做法是计算功率时延谱PDP按所有收发天线对功率求平均得到随路径索引变化的功率分布。import numpy as np # h 形状: (rx, tx, path) pdp np.mean(np.abs(h) ** 2, axis(0, 1)) # 每条路径的平均功率 pdp_db 10 * np.log10(pdp / np.max(pdp)) # 归一化到 dB # 查看路径数和前几条主径功率 print(path count:, len(pdp_db)) print(top5 power (dB):, pdp_db[:5])这段代码的意义是快速验证信道是否合理。NLOS 场景下PDP 通常有 5 到 10 条主要路径功率从第一条开始逐步衰减如果看到所有路径功率都差不多或者只有一条主径说明簇生成参数有问题或者场景被错误设成了 LOS。之后再看角度维度对 h 在路径维上做傅里叶变换可以得到各阵元的到达角响应这是波束管理评估的基础。输出解读还有一个容易踩的坑路径索引并不直接对应抽头时延。38.901 生成的路径时延是连续值而实际系统里的信道冲击响应需要按采样间隔离散化所以中间必须做一个抽头合并步骤。常见做法是把时延落在同一个采样间隔内的多条射线功率相干叠加得到一个等效抽头。不做这步你在链路仿真里看到的频域响应会有非物理的快速抖动平坦性验证根本过不了。4. 把单链路扩展成多小区系统级场景空间一致性和种子管理单链路跑通只是开始真正需要 TR 38.901 发挥价值的是多小区、多用户的系统级仿真。这一章讲两个关键工程点空间一致性如何保证终端移动时信道平滑以及多链路之间随机种子怎么分配才能既隔离又可控。4.1 空间一致性为什么终端移动时簇参数要平滑过渡纯随机的信道模型每时隙都重新抽样会导致终端从一点移动到另一点时多径结构完全突变这在系统级仿真里是失真最严重的问题。TR 38.901 引入空间一致性机制终端移动时簇的时延和角度不是完全重采而是按照空间相关性距离在旧值和新值之间插值或随机游走。简单说如果终端每秒移动 10 米簇参数应当“继承”上一时刻的状态而不是从零开始掷骰子。工程实现上标准给出的做法是把终端位置映射到一组“中间节点”每个节点间有一段相关距离典型值从几米到几十米不等。你在实现时要把终端轨迹离散成空间采样点并为每个采样点保存簇参数状态。如果只保存当前时刻的快照下一时刻直接重新生成仿真 SNR 会在瞬间出现不可解释的跳变波束跟踪算法会误以为信道发生了剧烈的角度旋转导致切换振荡。更隐蔽的问题是簇的“生灭”。终端移动过程中旧簇可能消失新簇可能出现38.901 允许按概率管理这些事件。我建议在代码里给每个簇加一个生命周期标记稳定期、消失期、生成期。消失期不要把簇功率立刻置零而是按距离权重衰减否则突发干扰会让接收机自动增益控制乱跳。4.2 多小区链路如何分配随机种子隔离与复用系统级仿真里通常有多个基站和多个终端如果所有链路共用一个随机种子链路之间的簇结构会高度相关相当于所有信道共享同一套多径环境评估多小区干扰时结果偏乐观如果每条链路完全独立随机又会丢失真实网络里相邻用户共享大尺度环境的信息。38.901 对这个问题没有强制的种子分配规则但它要求同一场景下各链路的小尺度参数独立而大尺度参数可以共享相关性。我一般这样分配大尺度参数用一个全局场景种子生成保证同一小区内用户的阴影衰落和路径损耗满足空间相关性小尺度参数用每条链路的独立种子生成确保各用户的多径结构互不相同。具体落地时先为每个小区分配一个小区种子再对小区内每个用户计算一个派生种子比如小区种子加用户编号的哈希值。这样既保证可复现又避免所有用户完全同构。下面这张表给出一个推荐的种子分配矩阵适用于 3 个小区、每小区 10 个用户的仿真仿真对象种子生成规则目的全局场景固定常量保证整套仿真可复现小区级全局种子 小区序号共享大尺度场景用户级小尺度小区种子 用户序号独立多径结构每次重跑可加版本号避免不同实验配置互相覆盖这套规则做下来你会发现换一套天线方案时如果不改全局种子性能对比的差异可以完全归因于天线本身而不是信道重抽带来的随机性。这是系统级仿真最常见的“玄学”来源明明算法没动结果却变了。种子管理可以解决 80% 的这种问题。4.3 系统级仿真中的 LOS 概率和路径损耗切换系统级仿真里用户移动会导致其在 LOS 和 NLOS 之间切换。TR 38.901 对每个场景定义了 LOS 概率函数它随水平距离和场景类型变化。这个函数不难查表但仿真时要注意切换的平滑性如果判断状态由 LOS 变成 NLOS路径损耗不能瞬间跳变需要插入一个过渡带通常按几十米的距离做线性混合否则中断概率会凭空增加。同样LOS 状态改变后时延扩展和角度扩展的统计分布也要切换。很多实现只切换了路损公式忘记切换小尺度参数的分布这会让多径结构在 NLOS 区域仍然保持 LOS 的特性。检查方法是画一条终端轨迹下的 SINR 曲线如果在距离断点附近出现大幅度锯齿状抖动多半是切换逻辑只做了路损层没做小尺度层。把这层补全系统级吞吐曲线才会平滑可读。最后多小区下还要配置相邻小区的接收功率差异。38.901 允许不同小区使用不同的小尺度参数但对于同一个用户来自两个小区的信道都要有空间一致性否则干扰信道和有用信道在时间上不相关干扰抑制算法会被迫使用更保守的协方差估计。这里需要在用户级管理每个小区链路的簇状态建议用一个字典结构按小区索引保存避免在遍历小区时冲刷掉之前的簇参数。5. 38.901 仿真避坑5 个最容易翻车的参数与排错记录做 38.901 仿真最怕的不是公式而是那些看起来正常、结果却不合理的隐蔽参数。这一章按现象、原因、解决的顺序写 5 个高频踩坑点都是我实际配置时遇到过的状况。5.1 同一拓扑两次仿真结果差异巨大现象代码没有改动只重新运行了一遍系统级吞吐从 80 Mbps 掉到 40 Mbps找不到任何逻辑错误。原因全局随机种子没有固定每次启动时默认取系统时间导致簇、射线甚至 LOS 判断全被重新抽样。解决在配置入口强制写入全局种子并为每个链路计算派生种子重跑前对比种子值。这个坑看起来简单但多人协作时如果某人的初始化脚本漏了 seed 参数整个回归基线就废了。5.2 时延扩展出现几十微秒的离谱值现象NLOS 场景下功率时延谱里出现远超载波时隙的抽头延迟动辄 20 微秒以上。原因延迟缩放因子设置过大或者簇时延采样时没有限制最大时延范围。38.901 虽然允许长尾分布但极低概率的极端时延对典型系统没有物理意义必须截断。解决在生成簇时延后做一个范围检查超过场景最大时延扩展 3 倍的簇直接丢弃同时把延迟缩放因子从默认值向下调 10% 再看主径分布是否合理。5.3 信道增益大于 0 dB路损算成了负值现象接收功率比发射功率还高链路预算完全失真。原因路径损耗公式里距离单位没统一比如把千米和米弄混或者把 O2I 穿透损耗的负号逻辑搞反导致额外增益叠加。解决统一使用米作为距离单位在代码里显式标注每个距离变量的单位。路径损耗结果检查时直接手算一组自由空间路损对照比如 3.5 GHz、100 米的自由空间损耗约 63.3 dB如果偏差超过 0.5 dB立刻检查公式。5.4 天线阵列方向设错导致波束成型失效现象加了天线阵列后波束扫描增益反而比全向天线低。原因阵列方向图里垂直角和水平角的坐标系与 38.901 的角度定义不一致比如把到达角的方向余弦算反导致方向图增益在主瓣指向时取到了零陷。解决在阵列初始化后先打一张方向图热力图检查最大增益方向是否指向设置的指向角确认后再进入信道生成流程。这个习惯能省掉大量后来才发现的算法层排查时间。5.5 相邻小区干扰相关性失真现象系统级仿真里两个相邻小区对同一用户的干扰信道和有用信道完全独立导致干扰抑制算法性能偏高。原因每个小区使用完全独立的随机种子且没有维护用户级簇状态空间一致性丢失。38.901 在系统级应用中要求干扰链路与有用链路共享一部分大尺度环境。解决使用用户级种子生成所有相关链路的簇结构再用小区级种子为不同小区生成独立的极化/相位偏移。这样既有相关性又有独立性更接近真实场景。6. 一个进阶动作从信道冲激响应反推到达角直接验证波束指向当你的仿真链路已经能稳定输出 H 矩阵下一步就可以把 38.901 的输出用在更贴近产品的问题上验证波束指向是否对准了真实到达角。我常用的方法是对接收天线上观测到的信道系数做空间傅里叶变换得到角度功率谱然后和标准给出的簇到达角做对比这样能快速发现整个链路里到底是哪一段把角度信息弄丢了。# 假设 h 形状: (rx, tx, path)rx 为 8 单元线阵 h_path0 h[:, 0, 0] # 取第一个簇、发射端固定一根天线 space_vec np.arange(8) # 对空间维做 FFT得到角度域响应 angle_resp np.fft.fftshift(np.fft.fft(h_path0, 64)) angle_axis np.arcsin(np.linspace(-1, 1, 64)) peak_idx np.argmax(np.abs(angle_resp)) estimated_aoa angle_axis[peak_idx] print(estimated AoA (degree):, estimated_aoa)这段代码的核心是验证角度信息没有在链路中丢失。38.901 的每个簇都有真实的出发角和到达角而 H 矩阵本身经过阵列响应加权后角度信息会保留在阵元间的相位差里。如果反推出来的到达角和生成时设置的簇角度偏差超过几度说明相位旋转、极化矩阵或天线方向图的坐标系出了问题。反过来如果两者吻合就可以放心地把这套信道模型用于波束管理算法评估。我曾经在一个项目里用这个验证方法发现所有角度都偏移了 90 度原因只是坐标系定义时把 x 轴和 z 轴弄反导致方向图垂直角被当成水平角用。从那以后每到一个新仿真环境我第一件事就是跑一遍“信道生成 - AoA 反推 - 对比标准”的流程确认基础链路没问题再继续做系统级算法。这个习惯帮我避开了后面几个月的无效调试也希望帮到你。本文还有配套的精品资源点击获取