NTN OTA Testing Launched for 3GPP Mobile and IoT Devices前几天跟一个做卫星终端的朋友聊起来他说他们产品马上要过入网认证卡在了一件事上——NTN设备的OTA测试到底怎么做。说实话这个领域一年多前还很冷门但现在3GPP Rel-17落地、卫星直连手机的概念普及之后NTN相关的OTA验证需求一下子涌出来了。所谓NTN就是非地面网络Non-Terrestrial Networks简单说就是卫星通信和地面蜂窝网络的融合。而OTA测试指的不是手机系统“远程升级”那个OTA而是在暗室环境里对设备整机做辐射性能测试——也就是把天线和整机当成一个整体来测量。我今天要聊的就是这套面向3GPP移动终端和IoT设备的NTN OTA测试到底是怎么一回事为什么卫星场景不能直接照搬地面基站的OTA方案测试系统怎么搭流程怎么走以及我在实际项目中踩过哪些坑。这篇文章适合三类人看一是做卫星终端或直连卫星手机的天线和射频工程师二是负责蜂窝终端认证测试的实验室从业者三是准备把NB-IoT/LTE-M产品推向卫星场景的IoT方案商。1. 为什么NTN设备不能直接套用地面OTA方案很多人拿到NTN终端的第一反应是这不还是个手机吗跑个常规OTA不就行了这话放到两年前可能还说得过去但现在3GPP定义了完整的NR NTN和IoT NTN协议栈从信道模型到射频指标都跟地面蜂窝网络差异很大再拿地面的那套测试思路去套结果基本不可信。1.1 卫星链路和地面电磁环境差在哪先说最直观的差别链路预算。地面基站到手机的路径损耗宏站典型值大概140到160dB但卫星链路完全不是一个量级。拿低轨卫星LEO600公里轨道高度来算2GHz频段附近卫星到终端的自由空间路径损耗大概在155到165dB之间具体取决于仰角仰角越低斜距越长损耗越大如果换成地球静止轨道GEO高度35786公里同样频段的自由空间损耗直接干到190dB上下。这个差异意味着终端天线增益、辐射效率、波束对准能力对整机性能的影响被急剧放大OTA测试必须能复现出这种“极弱信号”场景。然后是时延和多普勒。地面蜂窝网络里手机移动带来的多普勒频移一般也就几百赫兹到一两千赫兹但LEO卫星相对地面的运动速度很快在2GHz频段下最大多普勒频移可达正负40kHz左右而且这个频移还在随时间快速变化变化率可以达到每秒几百赫兹。对比一下NB-IoT一个载波的信道带宽才180kHz如果终端不做频率预补偿卫星信号扫过来的时候接收机根本锁不住。传播时延 тоже差别很大地面基站往返时延(RTT)通常几百微秒LEO在仰角10度时单程时延约6到7毫秒往返十几毫秒左右GEO更夸张单程约119毫秒往返在270毫秒量级。这就逼着终端必须支持3GPP里定义的TATiming Advance预补偿机制而OTA测试系统必须能把这类大时延、大动态多普勒信号真实地打到被测设备上。还有一个容易忽略的点是极化方式。地面基站和手机常用线极化天线但传统卫星通信系统基本都用圆极化3GPP NTN终端的天线设计也继承了这一特点。圆极化天线的轴比、旋向、极化失配损耗在OTA测试里都要成为可量化指标这跟测地面手机的线性极化增益完全是两套逻辑。1.2 3GPP对NTN设备测试提出了哪些新要求3GPP从Rel-17开始正式把NTN写进标准分了两条线一条是NR NTN支持手机直连卫星的基础语音和数据业务工作频段包括L频段n255约1.5GHz和S频段n256约2GHz另一条是IoT NTN基于NB-IoT和LTE-M协议改造让海量低速率物联网终端也能通过卫星接入网络带宽更窄、功耗更低、覆盖要求更高。中国、欧洲、北美的主流运营商和卫星公司都在推这两个方向所以前面提到的入网认证和运营商入库测试都会逐渐把NTN OTA项目纳入必测范围。从测试角度看3GPP在TR 38.821和TR 37.901里给出了NTN信道模型和设备测试建议核心变化集中在三块第一是信道模型变了卫星信道以直射径为主多径分量少且时延扩展小典型场景是莱斯信道RicianK因子很高这跟地面城市环境那种时延扩展大、多径丰富的瑞利信道差异很大第二是射频指标多了比如上行定时预补偿精度、频率预补偿精度、闭环/开环TA调整能力等这些指标在传统OTA测试里根本没有第三是测试触发条件变了终端在接入网络之前必须先完成GNSS定位并上报位置信息所以NTN OTA暗室里必须要能注入可控的GNSS模拟信号否则设备根本进不了网络。这些标准的落地让“OTA测试”从传统意义上的天线性能测量扩展成了“天线性能卫星链路模拟终端补偿算法”三者联合验证。只测一个TRP/TRS已经远远不够了。1.3 你需要明确NTN OTA到底测什么我接触过的不少项目负责人上来就问“能不能直接跑3D远场测TRP”说明大家对NTN OTA的测试项还不够清晰。根据3GPP的框架NTN OTA测试大致分四类。天线辐射性能类包括全向辐射功率TRP、全向辐射灵敏度TRS、EIRP/EIS方向图、天线效率和轴比这是传统OTA的保留项目但在卫星场景下要覆盖低仰角比如10度、20度、30度等卫星典型入射角度不能只盯峰值。链路捕获与跟踪类包括终端在大范围多普勒频移下的同步能力、频率跟踪环路的稳定性、上下行时序预补偿的准确性这类测试必须借助信道模拟器注入动态多普勒和传播时延才能验证终端能不能在高动态环境里保持驻网。业务性能类包括VoNR/VoLTE话音质量、数据业务吞吐量、RRC状态切换时延、IoT场景下的覆盖增强等级和重复传输次数等要验证的是在极低信噪比下业务是不是还能跑得起来。GNSS协同类要验证终端在弱GNSS信号环境下的定位能力、位置上报时延、定位失败后的降级策略因为卫星接入先决条件就是定位成功这个环节如果在OTA里没有被覆盖到到了外场很容易翻车。我在项目里的经验是先把这四类测试项跟客户对齐再决定暗室和仪器配置否则后期补硬件的成本会非常高。2. NTN OTA测试系统怎么搭核心组件与选型逻辑搞清楚了要测什么下一步就是搭系统。一套完整的NTN OTA测试系统至少由暗室、卫星信道模拟器、GNSS模拟器、无线网络综合测试仪基站模拟器和被测件控制系统五部分组成。每一部分都有针对NTN场景的特殊选型考量下面逐个说。2.1 暗室类型与天线极化的选择暗室这块主流方案有三种直接远场DFF、反射面紧缩场CATR和近场扫描另外还有一套叫“辐射两阶段法”RTS的思路在一些高端测试里也会用。对NTN设备来说我更推荐CATR或高精度远场原因很简单卫星终端大量使用圆极化天线同时波束可能比较窄CATR可以提供一个相位平整度更好的准平面波对圆极化轴比和低副瓣测量的精度更友好。近场扫描也可以做但对大尺寸终端和低频段1.5到2.7GHz来说近场扫描时间会很长而且反演算法对相位误差敏感卫星场景下的高动态信号仿真也不方便实时叠加。暗室里的测量天线一般需要支持双圆极化左旋LHCP和右旋RHCP最好能一键切换。很多传统OTA暗室只配了线极化喇叭天线如果直接拿来测NTN会引入3dB左右的极化失配损耗导致测出来的TRP偏低。这个钱省不了至少得有一支覆盖L频段和S频段的双圆极化探头。还有一点容易被忽略暗室的承载转台要支持俯仰和方位双轴联动。卫星信号不是从水平方向来的而是从天上以某个仰角打下来所以被测设备要能在不同姿态角下测量方向图。普通地面OTA暗室一般只要水平转台就行但NTN场景必须考虑低仰角到高仰角的完整球面覆盖双轴转台基本是刚需。2.2 信道模拟器高动态多普勒与大时延怎么仿真信道模拟器是整个NTN OTA系统里最核心的设备也是选型时最容易出问题的环节。它的作用是把卫星信道的特征——大时延、大动态多普勒、莱斯K因子、低时延扩展——实时叠加到测试信号上。选型时有几个硬指标要特别注意。第一是最大时延范围GEO场景要求支持至少400ms以上的双向时延很多传统2x2 MIMO信道模拟器最大时延只有2到10ms完全不够用。第二是多普勒频移范围至少要能仿真正负45kHz以上覆盖LEO在2GHz频段的极端情况同时多普勒变化率多普勒斜率要能到数百Hz/s这个参数如果不支持就没法模拟卫星从地平线升起又落下的完整过程。第三是信道数量普通设备测试至少需要两路——下行网络到终端和上行终端到网络——但Iot设备有些测试会同时验证多载波建议选至少4通道以上的。在信道模型设置上不能直接用3GPP地面的CDL/TDL模型。卫星信道模型的主流做法是用3GPP TR 38.811定义的参数集它把卫星场景分成LEO和GEO再按城区/郊区/农村开阔地环境设定K因子和多径参数。城市环境下K因子可能低一些10到15dB开阔地K因子能做到20dB以上。信道模拟器里要能导入这些参数并支持动态更新才能模拟出卫星移动带来的信道参数渐变。另外信道模拟器必须支持与GNSS模拟器联动。因为卫星信道里的多普勒时延变化和终端相对卫星的位置强相关如果GNSS模拟器生成的卫星星历和信道模拟器的多普勒仿真不一致终端会检测到矛盾的频偏和位置信息接入就会失败。我用过的方案里高端设备通过精确时间同步接口比如PTP或者1PPS联动测试场景一致性才能保证。2.3 GNSS模拟器为什么是“强制项”3GPP从Rel-17开始NTN终端接入网络的前提就是上报自身位置终端必须从GNSSGPS/BDS/Galileo/GLONASS获取定位信息然后在随机接入前完成上行频率和时间的预补偿。没有GNSS信号终端根本不会发起接入整个测试无从谈起。所以NTN OTA暗室里必须有一套多星座GNSS模拟器射频信号通过暗室内部的GNSS天线注入被测设备。这里的问题在于GNSS信号频段如GPS L1在1575.42MHzBDS B1I也在1561MHz附近和NTN工作频段n255/n256在1.5到2.2GHz离得挺近暗室里需要做好信号隔离避免GNSS信号串扰到蜂窝测试链路里。GNSS模拟器本身要支持动态场景不能只发固定位置的定位信号。因为卫星终端在实际使用中是移动的GNSS模拟器要能模拟出终端在高速移动过程中的定位变化这样终端上报的速度信息才能和信道模拟器里的多普勒曲线匹配上。我习惯在测试前先用静止场景验证终端能成功定位并有稳定的位置输出再切换到动态场景去跑链路级测试排错会容易很多。2.4 网络模拟器怎么配置成一颗“卫星”终端接入的对象是“网络”在实验室里这个角色由无线网络综合测试仪也叫基站模拟器/综测仪扮演。传统综测仪配置的是地面基站小区参数但NTN场景下参数差异很大必须按照卫星场景去配置。首先是小区的频点和带宽。NR NTN通常用L频段或S频段的专门载波带宽一般5到20MHzIoT NTN的NB-IoT就是一个180kHz载波LTE-M通常用1.4MHz或5MHz带宽。综测仪要支持这些频点和带宽下发。其次是时序参数。卫星场景下TA预算很大综测仪要能接受终端上报的很大TA值并且支持网络侧对终端做时间提前量的调整命令。这个跟地面场景完全不同地面TA值一般不超过0.5ms级别但NTN场景下TA值就是几十毫秒甚至上百毫秒。如果综测仪的TA动态范围不够链路根本建立不起来。然后是RRC参数里的NTN相关字段。比如3GPP规定NTN小区要在系统消息里广播“NTN配置”包括卫星星历Ephemeris、公共TACommon TA、定时补偿默认值等。综测仪要能下发这些字段终端才会认为自己身处NTN小区。这些配置在不同厂商的综测仪里位置很隐蔽我当年第一次配的时候找了半天才发现是在“小区专用参数”的子菜单里。最后一个容易忽视的点是移动性。如果要做LEO场景的切换测试一台综测仪通常模拟一个小区是不够的需要双小区的配置让终端从一颗“卫星”切到另一颗。也就是说综合测试仪最好支持多小区同步仿真而且小区间的时偏/频偏要能独立设置这才能模拟星间切换的断链与重建过程。3. 一套标准NTN OTA测试的执行流程系统搭好之后真正跑起来的关键就是流程设计了。我把我们团队在实验室里验证过的一套流程分享出来基本覆盖从准备到出报告的完整链路。3.1 测试前准备与设备链路检查测试开始前第一步不是急着把设备放进去而是先把射频链路的损耗校准做了。NTN OTA测试的路径损耗比地面测试大校准的准确性直接决定最终TRP/TRS的绝对精度。推荐的做法是使用标准增益喇叭天线作为参考在暗室里的测量位置放好测量整个链路的系统损耗然后记录校准文件。这个校准文件要覆盖被测设备支持的所有频点和典型功率电平。注意在NTN频段1.5到2.7GHz系统损耗随频率变化很明显必须分段校准不能只测一个频点就外推。接下来检查被测设备的状态。如果是手机形态要确保终端的GNSS天线和蜂窝天线都正常软件版本切换到测试模式关闭影响测量的业务功能比如Wi-Fi、蓝牙干扰。如果是IoT模块要通过串口或调试命令确认模块已经注册到测试网络能正常上报位置。这一步很关键我在实际项目里遇到过IoT模块固件版本太旧连NTN小区都识别不了导致后面花了半天排查设备问题。然后检查各台仪器的同步。信道模拟器、GNSS模拟器、综测仪之间要建立统一的时间基准推荐使用10MHz参考时钟和1PPS同步信号串联只有这三者时间同步了才能保证后续的时延和多普勒仿真是一致且可重复的。3.2 关键参数计算多普勒、时延与TA预补偿测试场景设计时几个关键参数需要提前算明白不能拍脑袋。我以LEO 600公里轨道高度、下行2000MHz频段为例大致推一遍。先算多普勒频移。低轨卫星相对地面终端的径向速度最高可达约7.5km/s不同轨道倾角略有差异用多普勒公式 fd v_r × f / c 来算其中 v_r 是径向速度f 是工作频率c 是光速。带入 v_r 7.5km/s、f 2000MHz算出来 fd ≈ 7.5×10^3 × 2×10^9 / 3×10^8 ≈ 50kHz。这是正对运动方向的极值实际仰角受限时通常到不了这个值但3GPP TR 38.821里给出的LEO 600km在2GHz频段最大多普勒也是正负40kHz多一点所以设计信道模拟器时按正负40到50kHz预留给足余量。再算传播时延。假设终端在卫星覆盖边缘仰角按10度算斜距约为轨道高度除以 sin(10度)的近似值粗算下来接近2000km量级。单程时延约2000km / 3×10^5 km/s ≈ 6.7ms往返RTT约13.4ms。GEO场景就简单了单程约119msRTT约238ms再加设备收发处理延迟3GPP模型里按最大约270ms算。信道模拟器的最大时延参数至少要超过500ms才有余量。TA预补偿的计算逻辑是这样的终端通过GNSS定位拿到自身经纬高再根据网络下发的卫星星历算出自己到卫星的传播时延于是提前 TA 个时间量发送上行信号让上行信号到达卫星的时刻正好落在网络期望的接收窗口内。OTA测试系统要给终端提供准确的星历和位置信息然后检查终端的上行信号到达时刻是否落在目标窗口内。我做测试时一般把窗口中心设为网络期望的TA值允许偏差从几百微秒到几毫秒具体看3GPP的指标要求。3.3 测试执行从IDLE接入到业务吞吐设备放进去、参数配好之后测试执行分五个阶段。第一阶段是静态定位验证。GNSS模拟器发出静止场景的定位信号确认终端能定位成功、位置误差达到指标要求。这个阶段如果定位失败后面全不用测。第二阶段是IDLE态接入测试。综测仪发起寻呼或终端主动发起注册验证终端在冷启动后能完成小区搜索、同步、系统消息读取、随机接入和RRC连接建立。这阶段一般加扫频或灵敏度的维度慢慢降低信号电平记录能成功接入的最低电平这个值就是“接入灵敏度”指标。第三阶段是连接态业务测试。注册成功并建立RRC连接后跑上下行业务VoNR/VoLTE或TCP/UDP数据在信道模拟器上叠加动态多普勒和不同仰角下的路径损耗记录吞吐量或话音MOS分。这个阶段我会调几组不同的多普勒场景卫星过顶时多普勒接近线性变化变化率最大、卫星在边缘时多普勒较小但链路损耗最大。要验证在这些动态条件下业务不能中断掉话掉线是绝对不能接受的。第四阶段是移动性测试。如果综测仪支持双小区模拟终端从一颗卫星切到另一颗记录切换时延和切换成功率。NTN切换是硬切换先断后连终端必须先完成目标星的同步再释放源小区所以切换链路比地面要脆弱很多切失败率经常在这里暴露出来。最后是IoT专项测试。如果被测设备是NB-IoT或LTE-M还要额外验证覆盖增强等级CE level、重复传输次数、PSM/eDRX低功耗模式下的行为。IoT终端灵敏度要求特别高NB-IoT在卫星场景下的PSD功率谱密度提升很大OTA测试要精确控制信号电平和噪声底否则测试误差会淹没真实性能导致测出来的灵敏度比真实值差好几dB。3.4 结果判定与数据后处理测试结果的分析不能只看测出来的数是多少。TRP/TRS这类指标要跟参考天线和仿真模型对比确认测量偏差在合理范围内经验上辐射效率误差不要超过0.5dBTRS误差不要超过1dB。动态链路指标要回放信道模拟器记录的多普勒、时延曲线和终端日志做时间对齐确认终端上报的测量值与注入值一致。如果对不上先查时间同步再查仪器参数设置最后再怀疑终端算法。结果报告建议按场景维度组织每一个LEO/GEO场景、每一种仰角、每一档信号电平单独出图。我记得有一个项目客户一开始只给了“灵敏度”一个指标结果拿到报告后又问要不同仰角的EIS曲线重新补测了一个多星期。所以现在我一律建议客户在测试前就把场景矩阵定下来频段、轨道、仰角、动态模式、业务类型全部都列清楚测试才可复现。4. 常见问题与排查技巧实录任何一个新搭建的NTN OTA测试系统刚跑起来的时候都会遇到一堆奇奇怪怪的问题。我把实际项目中踩过的坑总结一下按“现象-原因-解决”的方式列出来方便大家对照。4.1 TRP测不准、灵敏度异常TRP测出来比预期低第一反应是检查极化失配。我遇到过整个测试过程都忘了切换探头的极化方向TE和TM两个正交分量只采了一半结果TRP低了3dB。测试前用圆极化标准天线跑一遍参考测量是最保险的验证手段。灵敏度异常还有一个常见来源是暗室干扰。NTN频段跟Wi-Fi、GNSS、其他通信频段挨得很近暗室本身做得好不好直接决定噪声底。我建议在正式测试前先跑一个“空气校准”打开综测仪发射信号、不摆被测件用频谱仪量暗室噪声底如果在NTN频段测到的底噪高于-100dBm/Hz量级就要排查暗室屏蔽和滤波器的泄露。另外地漏、线缆、转台电机都可能成为干扰源转台的步进电机经常会产生宽带噪声必要时在转台上加滤波磁环。还有一个奇怪但真实的坑IoT模块的参考时钟精度太差。NB-IoT终端对频偏要求很高卫星场景下如果终端的晶振TCXO不过关多普勒预补偿后余粮就不够了表现出来就是接收灵敏度特别差。测之前先用综测仪量一下终端的频率误差超过0.1ppm就要先让厂商调时钟别浪费时间在暗室排查。4.2 同步失败、接入不了网络终端一直驻不上网这是NTN OTA调试阶段最常见的问题。排查顺序我建议按照这样的优先级来。首先查GNSS定位。终端如果定位失败根本不会发起随机接入。在综测仪日志里看有没有终端上报位置信息如果没有先从GNSS模拟器查起看它的射频输出功率够不够、信号频点对不对、星历参数是否合理。我遇到过一次GNSS模拟器默认输出的卫星仰角太低终端收不到信号把卫星轨迹改成高仰角过顶场景就好了。其次查系统消息里的NTN配置。终端收到SIB后要能看到NTN专用字段星历、公共TA否则它就当普通地面小区处理了会按地面的TA机制去接入必然失败。很多综测仪默认关闭NTN字段要手动打开可以在系统消息解析界面里最终确认星历和TA参数真的下发下去了。最后查信道模拟器的多普勒设置。如果多普勒频率范围开得太猛超过终端的搜索范围或跟踪环路带宽终端可能通过小区搜索却一直解不了PDSCH/PDCCH。调试阶段把多普勒设为0、时延设为固定值先跑通静态接入再逐步加大动态参数这样定位问题会快很多。4.3 GNSS定位漂移导致测试中断测试跑到一半终端上报的位置突然跳了几百米然后重新发起位置更新链路直接断掉。这个问题的根源多半不在终端而是GNSS模拟器和信道模拟器之间的时间不同步或者GNSS场景与终端运动轨迹不匹配。比如信道模拟器在模拟终端高速运动时的多普勒但GNSS模拟器还停在静止场景终端算出来的预补偿频偏就是错的最终表现为定位漂移、随机接入失败。解决办法是把两台仪器接入同一个时钟基准并配置相同的场景运行时间和运动轨迹。另外GNSS模拟器的更新率也要足够高至少10Hz输出位置/速度如果更新率太低终端看到的位置就是跳跃的。我在项目里曾经用20Hz的更新率解决过定位不稳定的问题。4.4 暗室环境干扰、极化不匹配最后说一个我自己的教训在搭建系统时为了省成本我把GNSS信号直接从暗室外的功分器引到桌面开环测试没有走暗室内部天线。结果终端在暗室里始终定位失败排查了几天最后发现是GNSS馈线经过了暗室的滤波器墙1.5GHz的GNSS信号被滤波掉了。后来我把GNSS天线装进暗室内部问题立刻解决。所以从一开始就要把GNSS信号路径纳入暗室整体设计馈线、滤波器、放大器都要选支持GNSS频段的型号。极化不匹配的问题前面提过这里再补充一个实战处理办法测圆极化终端之前用两支标准圆极化喇叭做一次“极化校准”直接测量暗室系统对LHCP和RHCP的增益差把这个差值作为系统补偿因子写入测试软件。这能消除暗室本身对不同极化信号造成的不对称避免被测件的轴比测试结果失真。写在最后NTN OTA测试这个方向说实话我入行时也没有现在这么多成熟经验可以借鉴很多方法论都是边测边摸索出来的。我个人在实际操作中最大的体会是不要把NTN OTA当成传统OTA的“加一个卫星选项”而是当成一套独立的、面向极高动态和极弱链路的测试体系来设计。从暗室选型、仪器配置、参数计算到结果判定每一个环节都要重新过一遍逻辑。也因为这个原因我个人强烈建议团队里至少有一个人把3GPP TR 38.821和TR 37.901啃一遍别指望着靠仪表厂商的默认配置就能把测试跑对。最后分享一个小技巧现在很多NTN芯片平台都自带诊断模式可以通过调试口实时输出终端的GNSS定位结果、预补偿TA值、多普勒估计值。测试时把这些数据和信道模拟器注入的参考值放在同一时间轴上对比绝大多数“被测设备行为异常”的问题都能通过这个手段快速定位到是终端算法的问题还是测试系统的问题。NTN OTA测试还在快速演进中3GPP Rel-18、Rel-19还在不断补充增强场景这套能力越早建起来后面遇到新需求也就越从容。