最近手头在调研3GPP LTE Release 16的eMTC增强特性重点把GWUSGroup Wake-Up Signal的方案逻辑翻了一遍。R16不算一个“大秀肌肉”的版本隔壁NR、URLLC、V2X都抢了风头但GWUS对海量低成本物联网终端的省电和网络接入灵活性来说价值一点不小。这篇就把我梳理的协议思路、参数逻辑、实现要点和排查心得整理出来算是一个简版方案解析同时也会结合R15 WUS做对比方便大家理解R16到底多做了什么。想了解eMTC终端如何进一步省电、网络侧如何做组唤醒调度的朋友这篇应该能帮你省不少翻提案的时间。先说结论GWUS的本质是把R15里那个“一喊全起”的WUS唤醒信号变成“按组点名”的唤醒信号。它让UE只有在被属于自己的唤醒序列“点名”时才去监听MPDCCH其余时间踏踏实实睡觉。听起来简单但涉及物理层序列设计、RRC配置、与DRX/eDRX的时序协同还有终端功耗和网络容量的平衡水比想象中深。1. 为什么eMTC需要GWUS功耗与调度的双重压力1.1 eMTC设备的省电逻辑和WUS的由来eMTCLTE-M从一开始就是奔着海量物联网来的。这类终端一般要求电池能用五年甚至十年成本还要压到很低很多还部署在地下室、井盖、仓库这些无线环境不友好的位置。为了省电LTE从R12/R13开始陆续引入了PSMPower Saving Mode、eDRXExtended DRX这些机制。PSM最狠可以让终端睡眠非常久但代价是网络不能随时联系到终端eDRX可以拉长寻呼周期但终端为了能收到寻呼还是必须在每个周期醒来一次。这里的关键在于终端醒来主要是为了监听MPDCCH看看有没有下行调度或寻呼消息。即使网络当前没有数据要发送UE也要把整个on-duration窗口听完不然可能漏掉非常重要的上行授权或者寻呼。问题就在这——很多业务流量是稀疏的比如水表一天上报一次凌晨大部分时间网络根本没数据要下发但UE还得按DRX周期定时醒来监听白白耗电。于是R15引入了WUSWake-Up Signal。原理特别朴素网络在DRX的on-duration到来之前先发一个非常短的信号。如果UE检测到了WUS才按原计划醒来听MPDCCH如果没检测到WUSUE直接跳过整个on-duration继续睡。你可以理解成闹钟变了——以前每天都要按时起床去门口看有没有快递现在有快递时门铃先响一声没听到门铃就安心睡。WUS本身占用资源少、检测功耗低对省电贡献很明显。但R15的WUS有个天然限制它是一个小区级、所有配置了WUS的UE共享的信号。只要这个信号发送了小区内所有支持WUS的eMTC UE都会被唤醒然后全部去监听MPDCCH。哪怕这些UE分属不同业务、不同时延要求、不同数据到达周期网络也没法只唤醒其中一部分。对早期小规模试点来说这种“一喊全起”问题不大。但当小区里终端数量成千上万时一个寻呼周期内真正有数据到达的可能只是少数几个UE。大多数UE被白白拉起又睡回去不仅浪费终端电池还放大了MPDCCH上的盲检压力。1.2 R15 WUS的局限只能全唤醒缺乏分组维度为了说明R16 GWUS的价值我们把R15 WUS的局限拆细一点。第一是唤醒粒度太粗。只要业务达到网络必须唤醒整个小区哪怕只有一个UE要接收数据。这对那些“每几分钟唤醒一次”的小流量业务群体尤其不友好因为每次唤醒都会把低时延需求的终端和高时延容忍的终端一起拉起来后者被动牺牲了睡眠时间。第二是虚警和漏检的影响被放大。WUS检测本身有概率误差如果虚警率高UE本来不该醒却被唤醒省电效果打折如果漏检率高UE该醒的时候还在睡业务时延就上去了。小区级WUS设计经常要为了兼顾边缘覆盖和大小区半径把信号强度和重复次数调得很高这就增加了资源和功耗开销。第三是调度灵活性不足。不同业务的分组策略通常是业务层的需求R15 WUS无法在物理层区分。比如同一小区里有几万台表计分属不同类型的服务计划有的需要高实时性有的只需要隔天上报。网络侧如果想精细控制就得靠别的节电参数配合比如把不同UE配置到不同的DRX周期或者寻呼组里但DRX周期资源有限寻呼组又受限于寻呼机会数量配置起来非常僵硬。所以R16做GWUS与其说是一个全新发明不如说是在WUS这个节能框架上补上了“组粒度”这块关键拼图。它不破坏R15的节电基本盘但是把唤醒的选择权从小区粒度减小到组粒度。2. GWUS方案核心设计拆解2.1 组唤醒基本思路从“一喊全起”到“按组点名”GWUS的中文直译是“组唤醒信号”思路其实很简单给不同的UE组分配不同的唤醒信号或者说是同一套物理资源上叠加不同的正交序列。网络侧在某个DRX周期的on-duration之前只发送目标组的唤醒信号。每个UE只检测属于自己的那个序列检测到了就正常醒来检测不到就继续睡。这样网络中一个小区可以同时配置多个GWUS资源或序列每个序列对应一组UE。比如业务高优级的一组业务低优先级的一组覆盖较差需要更多重复的一组通过配置就能分开管理。组里的UE数量不是固定死的网络侧可以灵活调整。要注意的是GWUS并不是每个UE发一个单独的配置。如果真要做到“一一点名”每个UE都要有一个独立的序列那物理层资源根本不够用。所以标准化的方式是“组”一组内所有UE共享同一个序列。这跟寻呼组的概念类似粒度可以划分但不是无限细化。实际规划时一组几十到几百个终端比较常见。2.2 序列与物理资源映射正交设计是关键从物理层角度看GWUS要解决的核心问题是如何在有限的资源内生成足够多、好检测、互不干扰的组序列。R15 eMTC WUS本身是基序base sequence生成的具体生成公式和长度不少资料都有讨论。R16做GWUS时常见思路是在基础WUS序列之上叠加不同的正交覆盖码OCC或相位旋转得到一组互相正交或准正交的序列。正交性越好不同组之间的干扰越低UE盲检的虚警率就越小。时频资源上一个GWUS资源块通常占一个PRB对映射在MPDCCH的搜索空间附近。具体起始PRB、时域起始位置、重复次数都是由RRC参数下发。重复次数这个参数特别关键因为eMTC覆盖等级差异很大。深埋的终端可能需要8次甚至16次重复才能可靠检测GWUS地面上的终端可能1次重复就够了。网络侧可以把重复次数放大但代价是占用更多时域资源和功耗所以规划时要按覆盖等级分组。还有一个容易被忽略的设计点GWUS的序列设计要避免和CRS小区参考信号、MPDCCH DMRS等信号产生强相关。一旦GWUS和参考信号发生碰撞检测可靠性会明显下降。所以网络配置时通常要把GWUS的PRB位置固定在MPDCCH搜索空间范围内同时避开PCFICH和PHICH资源。2.3 与MPDCCH和DRX周期的协同关系GWUS不是独立工作的它必须嵌入到UE现有的DRX/eDRX流程中。简单画一下时间线DRX周期开始前网络先发送GWUSUE检测GWUS如果成功检测到且序列匹配UE就进入on-duration监听MPDCCH如果没检测到UE跳过这个DRX周期直到下一个周期的GWUS时刻再醒来。时序上要注意GWUS与on-duration之间必须留出足够的“唤醒窗口”。UE检测完GWUS后需要时间打开接收机、做自动增益控制、同步、准备MPDCCH盲检。如果GP间隙给得太短UE还没准备好即使检测到了GWUS也无法正常监听后续调度给得太长则白白浪费睡眠时间。这个值并不是标准里硬性规定的很多是厂商根据基带处理时间自行处理但网络配置的时域偏移参数会影响实际间隔。对于eDRX场景GWUS一般配置在eDRX周期内的寻呼时间窗口PTW之前。UE在整个eDRX周期的大部分时间里处于长睡眠只有在PTW内醒来。GWUS可以进一步优化PTW内的行为——如果PTW开始时没有检测到GWUSUE可以晚点再醒来甚至跳过整个PTW里的部分监听。R16还考虑了与寻呼窄带PNB的配合确保GWUS所在载波和UE后续监听MPDCCH的窄带一致避免跨调度带来的额外切换开销。3. 协议配置与参数落地3.1 关键配置项与RRC信令GWUS相关配置在高层通过RRC信令下发涉及的标准文档主要是36.331RRC、36.213物理层过程和36.211物理信道。实际工程中不需要去背每个IE的字节码但至少要理解几个核心参数的含义。我把常见的配置项整理成一张速查表方便现场查问题配置项主要作用规划建议GWUS使能开关是否启用GWUS功能通常按小区配置低版本UE或终端能力不支持时需关闭载波指示指定GWUS所在载波避免多载波时找错位置与寻呼载波保持一致PRB起始位置决定GWUS时频资源起点避开PDCCH/PHICH避免与MPDCCH搜索空间冲突时域偏移控制GWUS相对DRX on-duration的提前量留足UE处理时间一般至少1个子帧重复次数控制GWUS的发射覆盖加强程度按覆盖等级分组不要全局用最大重复序列索引区分不同组的关键参数相邻小区和小区内组间需错开组标识/组掩码确定UE属于哪个唤醒组结合业务需求细化但不要过碎这些参数配置在一起最终会映射到UE侧检测的“序列假设集”里。UE不知道网络这轮实际发了哪个序列只能对假设集里的序列做相关性检测。因此配置的序列越多UE盲检计算量越大功耗也会相应增加。不能为了分组粒度无限加序列。3.2 组配置与覆盖等级、业务需求的映射GWUS组划分没有固定公式但我在实际规划中会遵循三个原则。第一个原则是“覆盖等级优先”。不同覆盖等级下GWUS需要的重复次数不同。如果把一个覆盖等级很好的UE和一个深埋井盖下方的UE划到同一组网络发WUS时重复次数至少要满足边缘UE这会让好覆盖UE白白多听很多重复。好办法是按CECoverage Enhancement等级分组重复次数相同的UE放一起。第二个原则是“业务时延对齐”。即时通信类业务、定期上报类业务、告警类业务最好分开。这样高优先级组可以更频繁地被唤醒低优先级组别老被误伤。第三个原则是“组不要太多”。组多了序列资源占用、盲检复杂度、相邻小区干扰协调都会变难。一般一个小区配置4到8个组就够用了除非有非常明确的业务分层需求。3.3 与eDRX/PSM的联动配置很多工程朋友会问GWUS和PSM能不能一起用答案是GWUS主要作用在DRX/eDRX的寻呼监听阶段PSM期间终端彻底不监听网络GWUS自然不会在PSM阶段生效。所以两者是前后关系不是叠加关系。配置eDRX时GWUS的周期与eDRX周期是绑定的。网络会在每个eDRX周期的寻呼窗口前发送GWUS。此时要特别留意PTW的长度和GWUS的位置。PTW是一段较长的时间窗UE可以在其中监听寻呼但不可能持续醒来而是按内部DRX周期监听。GWUS应放在PTW开端之前让UE在PTW最初阶段就快速判断“这轮有没有我的事”然后决定一个PTW周期内是否要继续监听这样可以节省很大一部分PTW监听功耗。实际工程配置中我见过一种比较有效的做法是将PTW设计成“先听GWUS再按需监听”的两段结构。PTW开始时UE只开很短的接收窗口检测GWUS只要没检测到自己的组序列后面的DRX on-duration全部跳过。这对超长eDRX周期比如5.12秒甚至10.24秒的终端来说省电效果极其明显。4. 功耗增益与容量影响值得部署吗4.1 功耗节省的量化逻辑我们拿一个典型配置来算账。假设一个eMTC UE的DRX周期为1.28秒on-duration长度为20毫秒没有WUS时UE每周期必须监听MPDCCH约20毫秒。加入WUS后UE只需要在on-duration前检测一个很短的信号假设检测耗时1毫秒如果30%的周期有数据到达那么平均监听时长大约变为1 0.3 * 20 7毫秒相比20毫秒节省了65%。如果用GWUS进一步分组把原本30%唤醒概率降为10%——因为唤醒粒度变细非目标组不会跟着醒来——平均监听时长约为1 0.1 * 20 3毫秒比R15 WUS的7毫秒再节省57%。这还不是全部收益因为GWUS检测本身通常比MPDCCH盲检更节能RF开启时间也更短。具体到实测不同厂家的UE因为射频和基带架构差异数据会不同。但整体趋势是清楚的GWUS能将“空听”时间压到极低尤其适合业务到达率很低的海量终端。4.2 对网络容量的影响与资源开销省电不是天上掉下来的GWUS也需要付出网络侧的资源和调度代价。每多一个GWUS资源就占用一定的PRB和时间。但相比它节省的MPDCCH监听资源这笔账通常是划算的。关键要控制的是“虚警率放大效应”。如果GWUS组序列之间的正交性不够好或者网络配置了过多序列导致检测门限变低UE就更容易“误判”。一旦误判UE被唤醒后MPDCCH上没有自己的数据这种空耗会抵消GWUS带来的收益。因此组数量与检测可靠性的平衡非常重要。另外多小区间的干扰协调也必须考虑。GWUS的序列如果与邻小区同频、同时隙、同PRB且序列相关性高就会出现一个终端不停被邻区GWUS唤醒的诡异现象。配置时要么错开PRB要么错开序列要么错开时域位置。这个在中小型验证网里可能感觉不到到了大规模组网阶段就是头号暗坑。4.3 哪些场景真正需要GWUS不是所有eMTC场景都需要GWUS。如果你的小区只有几十个终端业务到达率也很低直接配R15 WUS就够了。但如果是以下场景GWUS带来的价值会非常明显大规模表计类业务燃气表、水表、电表集中在一个小区数量常常上万。分组后可以做到“不同批次、不同优先级”的差异化唤醒。智慧停车/资产追踪终端移动性较低但业务到达时间随机且希望告警能被秒级响应。通过高优先级组单独配置较短周期可以兼顾省电和时延。工业传感器网络传感器数据上报周期不同有的每分钟一次有的每小时一次。按周期分组唤醒网络能更精确地匹配业务特征。更直接地说GWUS解决的是“既要省电又要保持可到达性”这个核心矛盾。终端数量越多、业务越不均匀GWUS的收益越明显。5. 实操实现中的常见问题与排查5.1 UE实现时容易踩的坑我这几年摸过的UE侧问题大部分集中在三个地方。第一个是序列假设集过大导致盲检功耗不降反升。很多协议分析工具只告诉你“支持GWUS”就行但支持多少个序列假设往往被忽略。UE面世的资料里如果写着支持全部序列集合硬件实现时功耗很可能压不下来。所以芯片设计时要有取舍按典型组数裁剪假设集并留出可配置空间。第二个是时域同步余量不足。GWUS检测要求UE在睡眠前已经掌握粗略同步否则醒来后需要重新做时频同步那点省电工夫全白费了。好一点的UE会维护一个“轻量级同步缓存”在睡眠期间保持时间基准漂移估算这样醒来后可以直接检测GWUS。实际测试时可以人为注入频率偏差观察检测性能的跌落这也是衡量UE实现水平的好方法。第三个是漏检和虚警的判决门限设置。这个门限跟覆盖、噪声、重复次数都有关系。边缘场景下门限太严容易漏检UE错过寻呼门限太松容易虚警白醒一场。好的实现应该根据RSRP或重复次数自适应调整门限。5.2 网络配置错误与故障排查实录我在验证过程中遇到过几个很典型的配置错误列出来给大家参考。一是GWUS时域偏移配置与on-duration重叠导致UE还没来得及处理GWUSMPDCCH就已经开始发了。这种故障的表现是UE上报的功耗电流曲线非常平滑但总是收不到寻呼。排查方法很简单把RRC配置里的时域偏移量和UE基带的处理时延对比一下算清余量就行。二是GWUS所在PRB和MPDCCH搜索空间不在同一窄带。eMTC工作带宽窄UE很可能在同一时刻只能监听一个窄带。如果GWUS被配置在窄带A而后续MPDCCH在窄带BUE要么来不及切换要么必须额外打开接收通道功耗又会上去。排查时看IMSI寻呼记录和RRC测量报告里的窄带索引就能定位。三是重复次数配置过大把整个时域资源撑爆。有些现场为了保证覆盖把GWUS重复次数设成最大结果一个GWUS就占了20个子帧。这会让网络每周期用于GWUS的资源超过MPDCCH本身而且终端要在大段时间内保持接收状态省电目标全破。实际上覆盖较差的组可以分开发送避免拖累全小区。四是在多载波场景下GWUS发在A载波而寻呼监听在B载波。终端睡眠时只守在B载波GWUS根本没收到自然无法激活。排查时抓一下物理信道配置确认载波指示字段是否和寻呼配置一致。5.3 现场测试与验证心得测试GWUS不能只看网络侧信令强烈建议用功耗分析仪观察终端实际电流曲线。标准流程我一般分三步。第一步单UE功能验证配置一个UE关闭业务数据在DRX周期内观察电流波形。理想情况下UE只有一个很窄的检测峰值然后继续睡眠。如果出现较宽的监听窗口说明WUS/GWUS没有起作用。第二步多UE分组验证配置两组终端网络只唤醒A组观察B组是否保持睡眠。这一步是验证GWUS“组粒度”的核心很多实现上的问题都在这里暴露。第三步覆盖边界与重复次数验证把UE放到弱场环境逐步降低RSRP观察漏检情况和误唤醒情况。记录下不同重复次数下的误帧率数据作为后续网络优化的依据。测试时建议同步抓取RRC信令和物理层日志把“网络发了什么”和“UE检测到了什么”对应起来。只靠仪表统计会掩盖很多细节。6. 从R16 GWUS到后续演进的一点想法R17、R18之后3GPP在物联网这边的关注点有一部分转移到了NTN非地面网络和侧行链路sidelink等新方向上。比如大家现在经常搜“3GPP卫星相关的协议”“LTE侧行链路资源池”说明行业侧的兴趣已经从单一的地面蜂窝覆盖扩展到了天地一体和设备直连通信。但在这些新场景里终端电池受限的问题依然存在GWUS这种“极低功耗的唤醒候选”思想仍然有参考价值。对于NTN场景星地传播时延大卫星小区覆盖范围非常大一个波束下可能有海量终端如果用传统寻呼方式终端要频繁醒来听漫长的寻呼窗口功耗会很吃亏。类似GWUS的组唤醒机制有机会帮助NTN终端在长传播时延下保持“低成本可达性”。当然NTN的定时关系和多普勒补偿会更复杂直接照搬地面方案不现实但分组唤醒的底层思路是相通的。在侧行链路方面资源池的设计更多是解决UE间通信的资源复用和干扰协调。但如果有中继UE需要同时监听网络和侧行链路功耗问题也会凸显。未来会不会在sidelink场景引入类似Group Wake-Up的机制值得继续关注。回到现在R16 GWUS已经是一项可以落地的协议特性。对存量LTE eMTC网络来说升级部署成本并不高主要工作量在网络参数规划和终端版本适配。如果你们的网络里已经有R15 WUS在跑把GWUS作为下一步优化项会非常自然。我个人实际做完这轮调研后的体会是协议规范只是骨架真正的难度在参数规划和终端行为验证。GWUS不是简单加个序列就行它要求网络侧对终端的业务模型、覆盖等级、移动性、DRX配置有非常清楚的认识。建议做物联网网络优化的朋友抽时间把R15/R16阶段RAN1和RAN2相关的讨论记录翻一翻很多比最终协议文本更细颗粒度的取舍能帮你理解现场看到的各种怪现象。最后分享一个小技巧在3GPP FTP和E2E门户上下载提案可以用“RAN2-xxxx GWUS”“R15 WUS eMTC”这类关键词组合去筛比光看最新版本RL36.331反而更容易找到功能来历与设计初衷。