先说我看到这条消息的第一反应NTN OTA Testing Launched for 3GPP Mobile and IoT Devices这个标题放在去年可能还是实验室里的小范围预研放到现在基本等于给终端厂商的发令枪——卫星接入不再是PPT概念3GPP体系下的手机和物联网设备都要面对一套全新的空口测试标准。尤其是OTA这个词很多人第一反应是系统升级但这里说的是Over-The-Air是设备不插线、通过天线在空间中完成信号辐射和接收验证的测试方式。对NTN终端来说这几乎是从“选做项”变成“必选项”。如果你在终端厂商做射频、天线、协议测试或者正在评估IoT设备上星这篇内容应该能帮你省不少时间。我会把NTN OTA测试的背景、测什么、标准怎么定、测试环境怎么搭、出了坑怎么排一条条拆开讲尽量用做测试的人看得懂的方式把这件事说透。1. 先分清两个OTA这次说的是空口测试不是系统升级1.1 一字之差方向完全不同先花一点时间把概念掰开因为我在实际沟通中发现这个混淆比想象中严重。很多做嵌入式、车机、Android Framework的同学听到OTA第一反应是FOTA固件空中升级比如RT-Thread的OTA升级、Windows IoT的更新流程、车机的整包差分升级。这些确实是OTA但它们属于“软件传输”范畴核心是包的下载、校验、分区写入和回滚策略。而NTN OTA测试里的OTA全称是Over-The-Air指的是设备在不连接射频线缆的前提下通过天线在真实空间中完成射频信号的发射与接收测试仪器在暗室里架设参考天线在“空气”里测量设备的辐射性能、灵敏度、连接稳定性。这是两个完全不同的技术域前者看的是存储和网络协议后者看的是电磁波和天线。为什么要重点区分因为很多团队第一次接到NTN OTA测试任务时去找了一个做软件OTA的平台工程师来对接上来就聊差分升级和AB分区两边完全对不上话。我自己见过不止一次这种场面。真正做NTN OTA测试的人日常面对的是屏蔽暗室、探头、转台、信号模拟器、信道模拟器讨论的是TRP、TIS、EIRP、灵敏度、多普勒补偿这些词。还有一个容易混淆的地方蜂窝通信里传统的“传导测试”Conducted Test是拿射频线把设备接到综测仪上信号路径确定、可重复、好定位。但NTN终端不一样卫星通信的信号路径本质上是空间链路终端天线和卫星天线之间的增益、极化、波束指向、人体遮挡都会直接影响通信质量。这些效应只有在辐射状态下才存在靠一根射频线是模拟不出来的。所以3GPP做NTN测试规范时OTA成了绕不开的测试形态。1.2 NTN是什么为什么手机和IoT设备要同时上桌NTNNon-Terrestrial Network非地面网络通常指低轨卫星LEO、地球同步轨道卫星GEO以及高空平台组成的通信网络。3GPP从Release 17开始正式把它写进标准框架并且一口气分了两条线NR-NTN面向智能手机、平板等宽带终端基于NR接入。IoT-NTN面向NB-IoT、eMTC这类低速率、低功耗物联网设备基于LTE/NB-IoT架构扩展。这说明什么说明卫星通信的受众不再是“专业人士”或者“应急场景”而是普通消费者的手机和物联网络里的各种小设备。手机直连卫星、IoT设备通过卫星回传数据这两个场景是NTN商业化的关键入口。但问题也随之而来终端厂商怎么证明自己的设备在真实的卫星链路下能工作答案就是建立一套标准的、可复现的测试方法OTA测试就是这套方法里最核心的一块。为什么说OTA对NTN特别重要因为卫星链路有几个地面蜂窝没有的“硬特性”第一链路预算很紧卫星离地面几百到几千公里路径损耗远大于地面基站终端天线效率差一点整个链路就断了第二低轨卫星相对地面高速移动多普勒频偏大终端必须能捕获和补偿第三终端天线方向、极化和卫星相对位置关系直接决定了有没有信号。这些特性全部要在空口环境下才能真实评估。所以3GPP在制定NTN终端测试规范时OTA实际上承担了双重角色既要验证射频端的辐射性能又要验证终端在模拟卫星信道环境下的协议流程。这就是标题里“Mobile and IoT Devices”同时出现的根本原因——不管设备形态如何接入NTN的那一刻都要按同样的空口规则来考核。2. NTN OTA测试到底测什么三个维度的硬指标2.1 辐射性能与链路预算TRP和TIS是地基如果把NTN OTA测试拆成三个层次最底层的一定是辐射性能。这个层次核心是两个指标TRPTotal Radiated Power总辐射功率和TISTotal Isotropic Sensitivity全向灵敏度。TRP衡量的是设备在所有方向上实际辐射出去的总功率。注意它不是“功放输出功率”而是天线辐射到空间里的功率等于功放输出减去馈线损耗、匹配损耗、天线失配损耗再把整个球面上的辐射能量做加权积分。对NTN终端来说TRP直接决定了上行链路能不能把信号送到卫星。低轨卫星通常在500到1200公里高度路径损耗大如果TRP比设计值低2个dB可能就意味着终端在边缘场景完全失联。TIS则是反方向衡量设备在所有方向上接收微弱信号的极限能力。它是对整个球面各个方向的灵敏度做积分单位也是dBm。这个指标直接决定了下行链路能容忍多大的路径损耗也就是终端到底能“看多远”。对于NB-IoT这类低速率设备TIS往往比TRP更关键因为它的发射功率本身不高但接收灵敏度如果足够好还是能在很弱的信号下完成数据回传。我实际测试中的感受是TRP测起来相对直接因为发射链路相对简单TIS才是真正耗时间的项目——每个角度要找到灵敏度临界点信令掉线、误码率抬头、重传率上升都得出在合理的测量容差内一个点测完才能转下一个角度。一个完整的球面TIS扫描跑上大半天是常有的事。2.2 协议与信令在建链状态下测“卫星链路”辐射性能只是地基NTN OTA测试真正和普通蜂窝OTA拉开差距的是协议和信令层面。这个层次的测试设备不能只是“发射信号且不管”而是要在一个完整的、模拟出来的卫星通信环境里完成搜网、驻留、随机接入、数据传输、切换等操作。具体来说测试系统里需要一台卫星模拟器它会模拟一颗低轨卫星的物理层信号按照3GPP定义的NTN频点产生下行载波带上卫星广播的系统信息和定时信息。终端设备在暗室里通过天线听到这个“卫星”然后发起随机接入。但因为链路是模拟的低轨卫星会有明显的多普勒频移和传播时延所以终端必须按照3GPP规定的NTN同步机制做补偿才能正确解调下行信号、计算上行定时提前。这一步是很多终端第一次在暗室里“见真章”的地方。我见过不少设备传导测试环境下一切正常——接入、注册、握手样样都通一旦把电缆去掉放到暗室里走OTA路径问题就全冒出来了要么搜不到卫星信号要么随机接入反复超时要么入网后很快失步。原因往往是天线方向性太强或者接收机对多普勒补偿的容限不够。另外还有一个被忽视的点GNSS辅助。3GPP的NTN终端往往需要依赖GNSS全球导航卫星系统信息来预补偿多普勒和传输时延所以测试中还会涉及GNSS信号的模拟。这就意味着测试环境里除了卫星通信模拟器可能还需要一台GNSS模拟器或者一台能同时输出通信信号和导航信号的综合模拟设备。这是NTN OTA和地面蜂窝OTA一个很大的区别测试系统集成复杂度高了不少。2.3 干扰与共存多设备同时上天不能互相踩第三个层次是干扰与共存测试。这个部分很多人会忽视但恰恰是NTN IoT场景里最容易出事故的地方。想想一个典型场景一个农业物联网项目几千个NB-IoT节点在方圆几公里的农田里部署每个节点都通过卫星回传数据。这些设备工作在同一颗卫星、同一个频段彼此之间的频谱间隔又很窄。如果某个设备天线设计不佳杂散发射超出限值或者接收机抗阻塞能力差就可能把邻近信道里的其他设备“挤掉”。更麻烦的是卫星覆盖范围极大同频干扰的影响范围也会被放大。地面基站还能通过小区选择和功率控制来协调卫星链路上能做的协调机制相对有限。所以3GPP的NTN测试规范里共存测试是明确要求的一类项目。简单讲就是让DUT被测设备在正常发射/接收的同时旁边再注入一个干扰信号观察DUT的灵敏度和误码率是否明显恶化。在OTA环境下做这个测试需要额外注意暗室内的信号隔离干扰信号和有用信号如果通过空间耦合串在一起测试结果会失真你很难判断到底是设备抗干扰能力不行还是测试环境本身有问题。在IoT场景里还有一类指标值得关注带外杂散和邻道泄漏比ACLR。因为IoT设备成本敏感前端滤波器往往做得很节省如果功放的非线性导致频谱再生不仅影响本设备还会污染整片频谱。这类问题在国内很多IoT模块上出现过传导测试不一定能暴露但OTA测试配合暗室里的高灵敏度接收机很容易抓出来。3. 3GPP对NTN OTA测试的关键约束频段、信道模型与测试环境3.1 哪些频段在承担卫星接入测试说到测试第一步得知道在哪个频段上测。3GPP在Rel-17中为NTN分配了明确的频段其中与OTA测试最相关的是频段上行下行使用场景n255L频段1626.5–1660.5 MHz1525–1559 MHzNR-NTN / IoT-NTNn256S频段1980–2010 MHz2170–2200 MHzNR-NTN / IoT-NTN这两个频段的路径损耗比毫米波小很多而且产业链成熟是目前NTN终端测试的主流对象。实际项目里我看到的大部分IoT-NTN模块测试都集中在S频段的n256上因为在较低频段做卫星物联天线尺寸和射频前端设计相对容易兼顾。但不是说毫米波就完全没戏。3GPP在Rel-18之后专门讨论了NTN在毫米波频段的可行性主要用于宽带终端的更高吞吐量场景。如果你做的是毫米波NTN终端那OTA测试就不是“推荐”而是“必须”——毫米波根本无法做传导测试天线和射频前端往往封装在一起只能靠OTA来测。这带来的问题是测试环境要升级成毫米波暗室天线探头、测量距离、系统校准全都不同成本会明显上升。3.2 卫星信道模拟多普勒、时延和路径损耗三件套NTN OTA测试里最核心的“道具”是卫星信道模拟器。它干的活用一句话总结把一颗真实卫星移动产生的信道效应在暗室里“投屏”到被测设备面前。低轨卫星在地球上空的移动速度大约7.5km/s左右。以S频段2.0GHz为例按照多普勒公式f v/c * f0算一下相对速度7.5km/s时频率偏移大约在50kHz量级。这个数字对蜂窝通信来说是个巨大的挑战——地面LTE系统里终端移动速度带来的多普勒通常只有几百赫兹。所以NTN终端必须具备多普勒预补偿能力在发射前就把频率偏移算好让卫星端收到的信号频率保持准确。另外一个容易被忽略的参数是多普勒变化率。低轨卫星不是匀速直线飞过头顶的它在接近、飞越、远离过程中多普勒频偏一直在变化变化率可能达到每秒几百赫兹。这意味着信道模拟器不能只设一个固定频偏而是要实时输出一个随时间变化的频率曲线才能逼真地模拟卫星过境的全过程。传输时延同样要模拟。LEO卫星在几百到上千公里的轨道高度星地单向时延可能在几毫秒到几十毫秒不等。对NB-IoT这类同步要求严格的窄带系统来说随机接入前导、定时提前校准全都要在这个大时延下工作。信道模拟器要能精确设定并动态调整时延参数同时确保整个测试链路的时间基准一致。路径损耗的模拟更直接低轨卫星链路的路径损耗远大于地面基站但暗室里的物理距离只有几米。如果不做等效补偿DUT会认为卫星“近在眼前”信号好得离谱测出来的灵敏度和功率都不真实。标准做法是让信道模拟器在固定距离的基础上额外加上卫星链路的路径损耗和衰减模拟出“真实卫星距离”下的接收电平。实际测试中我建议对信道模拟器的配置做三层校准第一层是频率、时延、幅度的基本零值校准第二层是用标准天线做系统级校准第三层是针对具体DUT的参考电平复核。任何一层不过关后面测出来的TRP、TIS都可能带系统性偏差而且这种偏差往往很难从最终报告里看出来。3.3 标准演进Rel-17是起点Rel-18/Rel-19在追什么如果你今天才开始搭建NTN OTA测试能力一定要注意标准不是静止的测试要求也在快速演进。Rel-17是NTN的“从0到1”确定了NR-NTN和IoT-NTN的基本框架终端测试规范从无到有建立起来。这个版本的测试重点主要放在“能不能接入、能不能保持连接”上对移动性、切换的相对要求比较宽松。Rel-18开始做“从1到N”重点之一是终端移动性增强——卫星和终端都在移动小区切换、波束切换、星间链路切换的场景开始进入测试范围。这直接增加了OTA测试的复杂度因为测试里要模拟多颗卫星、多个小区还要验证终端在切换时的服务连续性。暗室里不再是“一颗星盯着一个设备”可能要模拟“一颗星掠过、另一颗星跟上”的完整过程。Rel-19以及后续版本则把更多精力放在大带宽场景、语音支持、更多物联网用例上。对测试人员来说这意味着测试用例库会持续膨胀不同Release终端之间的兼容性验证也会变成常驻任务。我个人的建议是采购测试设备时不要只看当下能跑哪些用例更要看厂商能不能在后续软件升级中跟上3GPP新版本的标准。硬件一次到位软件持续更新是控制长期成本的关键。4. 实操流程从环境准备到出报告的一次完整NTN OTA测试4.1 测试环境的硬件怎么搭理论说再多不如把环境搭起来跑一遍。一套完整的NTN OTA测试环境核心硬件包括屏蔽暗室常规的OTA暗室即可尺寸根据被测设备工作频段和测试距离要求决定。L/S频段工作波长在15到20厘米左右暗室尺寸要求不算苛刻但内壁吸波材料必须针对对应频段优化。测试转台DUT放在转台上可以控制方位角和俯仰角旋转完成整个球面的扫描。转台的精度很重要尤其在测TIS时角度偏差会导致灵敏度测量结果抖动。测量天线/探头固定位置接收DUT信号或者作为信号源向DUT注入信号。通常会用宽带双极化天线这样才能覆盖不同极化和频段需求。卫星模拟器产生符合3GPP NTN标准的物理层信号模拟卫星小区的系统信息、同步信号、参考信号并能配置频点、带宽、发射功率。信道模拟器叠加多普勒、时延、路径损耗等卫星信道效应。很多新一代综测仪已经把“卫星模拟信道模拟”集成在一起如果预算有限可以优先考虑这类一体设备。GNSS模拟器可选但强烈建议配备因为它可以模拟终端的位置和卫星导航信号验证NTN终端的GNSS辅助同步功能。软件层面还需要一套测试管理平台负责编排测试用例、控制仪表、采集数据、生成报告。市面上通用的OTA测试软件通常支持TRP/TIS自动扫描但NTN相关的协议用例比如随机接入、多普勒补偿、卫星切换等往往需要结合卫星模拟器厂商提供的专用软件来跑。所以环境搭建前先把软件兼容性搞清楚否则硬件全配齐了才发现用例跑不起来就尴尬了。4.2 测试执行步骤与关键参数环境搭好后一次标准的NTN OTA测试大致按下面几步走系统校准。这是最不能省的一步。在暗室里用标准增益天线通常是一个已知增益的喇叭天线或偶极子天线代替DUT测量从仪表端口到空间参考点的路径损耗、线缆损耗、探头增益建立完整的校准文件。校准做不好后面所有绝对值指标都是虚的。DUT安装与配置。把DUT固定在转台上。对于定向天线设备要确保天线主波束朝向预定的测量方向对于全向设备要保证DUT在旋转时不会被夹具结构遮挡。然后给DUT供电配置到预期的频点和工作模式。卫星模拟器配置。设置NTN频点比如n256的1980–2010 MHz上行、带宽、子载波间隔、信号电平、系统消息。再根据测试场景配置卫星轨道类型LEO还是GEO、多普勒频偏曲线、初始时延、路径损耗补偿值。建链验证。启动测试让DUT在暗室里通过OTA路径完成搜网、驻留、注册。这个阶段务必观察DUT能否正确解调下行信号是否能读到系统信息随机接入是否成功。如果这里都不过后面所有数据都不用测了。辐射性能测量。执行TRP扫描转台按预设的角分辨率通常是5°或10°遍历整个球面在每个角度测量DUT的等效全向辐射功率EIRP再做球面积分得到TRP。然后执行TIS扫描在每个角度上逐步降低下行信号电平找到灵敏度临界点最后整合出全向灵敏度。协议与信道场景测试。在TRP/TIS之外针对NTN特有的场景做专项验证多普勒存在时保持业务连接、切换时不断流、大时延下随机接入成功、GNSS辅助启动等。这部分用例通常要跑很多轮要有耐心。数据处理与报告。把TRP、TIS、各场景通过/失败情况汇总成报告和3GPP规范里的限值做对比给出结论。几个关键参数我在实际项目里反复确认过给大家一个参考范围角分辨率对全向小天线设备10°步进通常够用对定向波束设备建议5°甚至更细否则波束峰值边缘测不准。测量点数完整球面扫描的测量点数直接决定测试时间。10°步进大约需要600多个测量点5°步进就翻倍到2000多点。TIS测点多了测试时间会指数级上升所以要权衡。参考信号电平卫星模拟器的下行信号电平一般设置在–80 dBm到–90 dBm左右让DUT处于正常接收范围。太低会触达灵敏度边缘太高会让接收机饱和两种情况都会干扰建链。4.3 数据分析与达标判定数据拿到手第一步先做合理性检查。我会习惯把TRP和预期值比一比如果DUT的功放标称输出是23dBm天线增益3dBi那TRP大致应该在20dBm以上。如果测出来只有10dBm不要急着下“设备不合格”的结论先查暗室校准是不是丢了几个dB再查DUT是不是被功率管理模块压了发射功率。TIS的判定更微妙。卫星链路的灵敏度要求往往比地面蜂窝更严因为链路预算绷得很紧。尤其在IoT场景NB-IoT的设备灵敏度通常要做到–120dBm甚至更低OTA测量时只要环境底噪偏高或者探头本身引入额外噪声就会显著影响TIS读数。所以测TIS前我会先把暗室的底噪测一遍确保环境本身不会吃掉太多余量。另外要注意限值的标准版本。3GPP对NTN终端的射频指标要求不会永远不变。你是按Rel-17的限值判还是按Rel-18的限值判可能直接影响一个产品能不能出厂。标准版本必须写清楚记录在测试报告里这个细节能帮你少背很多锅。5. 常见问题与排查技巧实录5.1 卫星模拟器设置多普勒后DUT接不上网这是NTN OTA测试里最常见的坑几乎每个团队都会踩一次。现象是关闭多普勒模拟时一切正常一旦打开多普勒频偏DUT就搜不到卫星信号或者随机接入一直失败。排查思路有两条。第一条确认DUT是否支持3GPP规定的多普勒预补偿机制。很多NTN终端依赖GNSS定位信息来做多普勒预补偿如果测试环境没有同时提供GNSS模拟信号DUT内部的预补偿算法就得不到有效位置输入它做的频率补偿可能就是错的。这种情况下可以先打开GNSS模拟器给DUT一个模拟的位置和导航信号再测试。第二条确认信道模拟器设置的频偏曲线是否超过了DUT的设计容限。3GPP规范里对LEO场景的多普勒范围有明确要求但不同终端实现会有差异如果一时无法解决先按规范下限跑通流程再逐步增加频偏看看DUT在哪一档开始彻底失锁这会帮你定位问题出在射频前端还是基带算法。5.2 TRP测出来偏低先别急着判不合格TRP偏低是另一个高频问题。我见过一个项目工程师反复调设备、换天线TRP始终比预期低3dB最后查出来是暗室里DUT摆放位置紧挨着金属支撑柱辐射能量有一部分被反射和吸收简单调整了夹具位置后数值立刻恢复正常。所以遇到TRP偏低按这个顺序排查首先检查校准用标准天线复核暗室路径损耗校准文件是否有效其次检查DUT本身状态测量其传导输出功率排除功放异常最后检查物理位置DUT周围是否有金属物体、吸波材料是否意外脱落、转台是否存在射频谐振。还有一个容易被忽略的点功率管理策略。很多智能手机和IoT模块会通过P-MPR机制在检测到发热或靠近人体时自动降低发射功率。测试时散热条件不好设备温升上去了功率就会被偷偷压下来。所以测试中给DUT做好散热并把功率管理策略设置到测试模式往往比调仪表更有效。5.3 TIS反复波动结果不稳定TIS测出来忽高忽低是暗室测试里最让人头疼的问题。数据不稳定的原因通常集中在三个方向环境底噪。暗室屏蔽效能不够或者有干扰信号漏进来灵敏度测试必然受影响。排查方法是关闭DUT发射只让接收链路工作在频谱仪上看底噪是否抬升。角度扫描机构。转台回差或定位精度不足可能导致DUT在每个角度的真实指向有偏差。这个在低频段不太明显在S频段开始显现。测量链路的驻波。探头、线缆、放大器之间的匹配不好会在不同频率处产生驻波叠加导致灵敏度读数波动。用网络分析仪测一下从仪表端口到空间参考点的回波损耗通常能发现问题。我个人的习惯是TIS正式测试前先做一个快速验算取三个典型角度正对天线、侧向、背向各测一遍灵敏度看数据是否符合预期趋势。如果这三个点都是好的再跑全球面扫描能省下不少无效时间。5.4 一个问题速查表现象可能原因排查手段打开多普勒后无法入网未开启GNSS辅助/预补偿异常先补GNSS模拟信号再测试TRP低于预期2-3dB暗室校准失效、夹具遮挡、功放被限功率复核校准文件、调整DUT位置、监控DUT发射功率TIS读数波动大环境底噪高、转台精度不足、驻波测暗室底噪、查验转台回差、测链路回波损耗建链成功但业务瞬断切换参数/波束管理配置不合理检查多卫星场景切换配置降低测试场景复杂度逐步排查搜到信号但注册失败模拟器小区参数与DUT能力不匹配核对3GPP版本、频点、带宽、子载波间隔6. 测试之外的几点体会设备选型上我倾向于推荐“卫星模拟器和信道模拟器分体”的方案。分体设备虽然布线麻烦一点但每一级链路都清楚出了问题好隔离。一体化设备适合产线快速测试研发验证阶段还是分体更灵活。能力建设上建议团队里至少有一个人能读懂3GPP的TS 38.101-5和TS 36.101-4这类卫星接入分册并能追踪Rel-18/Rel-19的变化。市面上很多测试报告做得漂亮但限值检查依据的是旧版本审核一严就会翻车。最后分享一个实际经验NTN OTA测试的用例数量看起来不多但每个用例的执行时间比地面蜂窝测试长很多因为暗室转台扫描和信令交互都是慢活。排测试计划时一定要留出足够的buffer。如果你负责的项目也处于NTN终端开发阶段建议尽早把OTA测试环境拉起来不要让测试流程成为产品发布路径上的瓶颈。先跑通一个最简单的建链用例再逐步增加多普勒、时延、切换等复杂度这个路径会让团队少走很多弯路。