1. 先把这三个词从论文里拽到地面上做无线网络这行久了最怕别人问一句“5G到底比4G强在哪”。这个问题不好答因为答案取决于问的人是谁做手机的人关心峰值速率做工控的人关心抖动做水表电表的人关心一颗电池能撑几年。这三个方向对应的就是5G 网络 eMBB、uRLLC、mMTC这三大应用场景——增强移动宽带、超可靠低时延通信、海量机器类通信。我刚接触这三个词的时候也觉得它们是写在标准白皮书里的东西离现场很远。后来做网规网优、做行业专网交付、做切片参数配置才发现所有的工程争论最后都会绕回这三条线这条业务到底该塞进哪条车道塞进去之后要动哪些参数动了参数会不会把旁边那条车道挤坏。我在几个模拟项目里反复折腾过这三类场景的共存问题踩的坑比看过的文档多这篇就把这套东西按我自己的理解捋一遍。适合谁看做无线网络规划与优化的、做行业专网和切片交付的、做终端模组与边缘计算的、以及需要给业务方解释“为什么你的需求我现在给不了”的售前和产品。不需要你懂 3GPP 的协议栈细节但最好知道 RB、子载波间隔、QoS 流这些基本概念不知道也没关系我会用类比把关键的点讲明白。2. 三大场景的定位与设计逻辑拆解2.1 为什么要把一张网切成三块4G 时代的设计目标很单纯给人用把下行速率做上去把覆盖做稳。人上网的行为是统计复用的忙时挤一挤闲时松一松网络按“平均体验”去规划就行。5G 面对的东西变了同样是空口一头要接 VR 头显和 4K 回传另一头要接产线上的机械臂控制器还有一头要接几十万只埋在井盖下面的传感器。这三类业务的诉求向量完全不在一个方向上——一个要带宽一个要确定性一个要连接数和低成本。香农公式摆在那里带宽、信噪比、时间三者互相牵扯。你想把时延压到 1ms就得把调度粒度切碎切碎就意味着控制信令开销占比上升频谱效率往下掉你想让终端便宜省电就得把射频带宽做窄、把接收机做简单窄带就意味着峰值速率上不去。一个优化目标不可能同时讨好三拨人这是物理规律不是工程能力问题。所以标准组织的做法是“聚类”把上百种业务按速率、时延、可靠性、连接密度、移动性、功耗这几个维度打分最后收敛成三个包络。这个思路很像物流快递要快、货运要便宜、公交要覆盖广你不可能用同一辆车同时满足三者只能分车型、分线路、分时段。理解了这一层后面所有的参数取舍就都有了解释——不是标准写得啰嗦是它必须给三类业务各留一套可调的旋钮。2.2 三个场景的量化指标与真实业务边界把 ITU 给的目标值和现网能摸到的水平放一起对比很多争论会瞬间消停。维度eMBBuRLLCmMTC典型峰值速率下行 20Gbps / 上行 10Gbps不追求极低单终端 Kbps 级用户体验速率100Mbps 量级按业务定常见几十 Kbps 到几 Mbps几 Kbps 到几十 Kbps用户面时延几毫秒到几十毫秒1ms 量级空口侧秒级到分钟级都能接受可靠性1-10⁻³ 量级1-10⁻⁵ 量级一般要求连接密度按容量算按容量算10⁶ 连接/km² 量级移动性高速移动可用500km/h 场景有要求基本静止或低速终端成本与功耗不计较不计较极敏感电池要撑数年这张表要重点看最后一列。很多人做方案时喜欢拿 eMBB 的指标去套所有业务结果给一个抄表业务配了百兆带宽的切片成本直接翻几倍甲方看一眼预算就散了。反过来把 uRLLC 业务的时延承诺按 eMBB 的调度周期去配标称 20ms 实际跑出 60ms验收必挂。我个人的经验是把这张表当成“包络”看不要当“承诺”看。包络是标准给的上限现网能兑现多少取决于频宽、站间距、终端能力和核心网部署位置。同样是标称 1ms 用户面时延核心网下沉到园区机房和放在城市核心机房实测能差出三到五毫秒。给业务方汇报时把这句话说在前面后面能省掉很多解释成本。2.3 场景之间的冲突点抢的不只是带宽三大场景共存最容易被低估的是“调度粒度”和“信令开销”之间的对抗。eMBB 喜欢大包、长调度、少信令一个 TB 块塞满 273 个 RB调度器一次决策覆盖 0.5msuRLLC 喜欢小包、短调度、快反馈两个符号就得把包发出去控制信道占比一下就上来了。同一载波里这两种需求打架调度器只能按优先级抢资源抢的结果就是 eMBB 用户在忙时速率掉一截。第二个冲突点是 mMTC 带来的信令风暴。几十万个终端在同一时刻发起接入前导码只有 64 个竞争碰撞概率会飙升大量终端进入退避重试接入时延从几百毫秒涨到几秒甚至几十秒。这时候 eMBB 用户会感觉到“网还在但很卡”因为 PRACH 资源和上行调度机会被抢走了。第三个冲突点更隐蔽TDD 帧结构的时隙配比。eMBB 下行吃重希望下行符号多uRLLC 希望上行反馈快需要更多的上行机会和更短的上下行转换周期。一根天线、一段频谱配比只能有一个这就是网络切片存在的根本理由——把冲突从“同一载波内抢”变成“不同切片间隔离”。3. eMBB把带宽做厚账要一笔一笔算3.1 峰值速率的账本怎么算出来的很多方案会把“理论峰值”挂嘴边我习惯现场给人算一遍算完大家就冷静了。以常见的 100MHz 带宽、30kHz 子载波间隔为例这个配置对应 273 个 RB每个 RB 一个时隙里是 12 个子载波乘 14 个符号共 168 个资源粒子一个时隙 0.5ms273 个 RB 合计 45864 个资源粒子。下行用 256QAM每个资源粒子 8 比特四层空间复用那么一个时隙能装 45864 × 8 × 4 1,467,648 比特除以 0.5ms理论峰值约 2.94Gbps。这还没扣开销。实际要扣掉 PDCCH 占用的符号、DMRS 导频、CSI-RS、SSB 的周期性摊薄、保护间隔综合开销系数我一般按 0.75 到 0.85 取那么单载波单用户的空口峰值就落在 2.2 到 2.5Gbps。现网实测呢我参与过的几个模拟项目里单用户近点RSRP 好于 -80dBm、SINR 大于 25dB能跑到 1.2 到 1.8Gbps中点在 600 到 900Mbps远点掉到 100 到 200Mbps 是常态。差距来自三块导频和信令开销比理论估算更重、调度不可能每次都给你满 RB、终端自身处理能力有瓶颈。上行更明显100MHz 上行即使上 256QAM 双层理论也就 0.7Gbps 出头实测常见 300 到 500Mbps。注意谈峰值速率必须同时给三件事——带宽、层数、调制阶数。只报一个数字的方案八成是把理论值当实测值写进 PPT 了。3.2 大规模天线与波束赋形的落地细节eMBB 的带宽之外另一半功夫在天线上。64 发 64 收的 AAU 是现在的主流配置它带来的不只是阵列增益更重要的是空分复用和多用户配对。但天线一多参数就变得敏感我见过太多站点把波束配歪了速率上不去还查不出原因。第一个要盯的是 SSB 波束配置。SSB 是终端找网用的常见配置是 8 个窄波束扫一圈加一个宽波束兜底。窄波束增益高但覆盖缝隙明显宽波束覆盖稳但增益低。高层楼宇场景我一般会加大垂直方向的波束数不然楼上的用户天天挂在“波束边缘”SINR 上不去MCS 爬不起来用户感受就是“信号满格但网很慢”。第二个是业务波束与 SSB 波束的匹配。终端做完波束测量上报网络侧要按 CSI-RS 做精细波束赋形如果权值表配错或者 CSI-RS 周期太长业务波束就会指向偏移方向。实测表现是终端位置不动速率周期性抖动抖动周期和 CSI-RS 周期对得上——这时候去查权值表和 CSI 上报配置基本一抓一个准。第三个是 SRS 轮发与单双流判决。多用户 MIMO 依赖上行信道探测SRS 周期配长了信道老化调度器不敢给你双流速率就卡在单流水平。我一般的经验是中低移动性场景 SRS 周期配 10 到 20ms高速场景适当拉长但要同步调高外环收敛速度。3.3 eMBB 优化里最容易踩的几个坑坑一外环链路自适应收敛太慢。终端从小区边缘往中心走SINR 快速上升但 MCS 爬升慢半拍用户感觉“明明走近了网还是慢”。这时候要看外环调整的步长和上报周期把上行/下行外环的调整粒度调细同时确认 CQI 上报没有被过滤得太狠。坑二上下行交叉时隙干扰。TDD 制式下相邻小区帧结构配比不一致或者时隙对齐有偏差基站间就会互相打。表现是上行底噪抬高、随机接入成功率下降、用户上行速率腰斩。排查方法是看上行干扰的时域分布如果干扰集中在特定符号位置基本就是交叉时隙问题需要统一配比或者加保护间隔。坑三远距离同频干扰。平原、水域、高层楼顶这些场景信号能传几十公里远处的基站信号在特定气象条件下压过来抬升底噪。这种干扰是阵发性的白天没有晚上有晴天没有阴天有很容易被误判成设备故障。处理办法是调整下倾角、压功率、换频点或者干脆把受扰小区的上行功控参数单独调一档。坑四把载波聚合当成万能药。聚合能提峰值但会带来切换门限、辅载波激活时延、终端发热和耗电问题。我见过为了追峰值把三个载波全开结果终端发热降频实测速率还不如单载波。聚合的收益要按业务场景算不是越多越好。4. uRLLC低时延和高可靠是抠出来的4.1 端到端时延预算怎么拆uRLLC 最容易犯的错是只盯空口。空口那 1ms 确实难做但真正让项目翻车的是端到端链路上那些“看起来不重要”的环节。我一般拿一张预算表跟甲方对齐把每一段都摆出来。环节典型耗时压缩手段终端应用处理与编码0.5~5ms应用侧优化减少缓冲空口传输含调度0.5~3ms短调度、免调度、短帧结构基站基带处理0.3~1ms硬件加速、减少处理流水线回传传输0.2~2ms光纤直连、减少跳数核心网用户面0.5~5ms用户面下沉到边缘应用服务器处理1~10ms服务器就近部署这张表一摆很多争执就没了。业务方要 10ms 端到端空口给你做到 1ms核心网在城市机房来回一趟 5ms服务器在总部机房再加 6ms怎么算都不够。解决办法不是让无线侧再抠 0.5ms而是把用户面和服务器一起下沉到园区。这也是为什么 uRLLC 项目里“边缘计算”不是可选项是前置条件。具体到空口1ms 用户面时延的实现路径大致是子载波间隔用 30kHz符号长度约 33 微秒调度粒度用 2 符号或 4 符号的 mini-slot配合免调度传输省掉调度请求和上行授予的往返。我算过一笔账2 符号 mini-slot 的传输时间约 67 微秒加上终端和基站的基带处理单次传输可以压到 0.3 到 0.5ms 量级剩下的预算留给重传和网络侧。4.2 免调度、重复传输和可靠性数字的真相uRLLC 的可靠性目标常被写成“99.999%”也就是误包率 10⁻⁵。这个数字单靠一次传输是做不到的必须靠编码增益、HARQ 重传、重复传输、双连接复制这几层叠加。免调度传输配置授予是我最常用的手段。它把“终端申请—网络授予”这个往返直接省掉终端按预配的周期和资源直接发。配置上有两个关键参数周期和重复次数。周期要跟业务包到达的节奏匹配配太密浪费资源配太疏终端要等下一个机会重复次数决定可靠性冗余常见 2 到 4 次。我在模拟项目里做过对比同样 10ms 时延预算下免调度加两次重复的成功率比纯动态调度高一个数量级。但要提醒一句重复传输不是“发得越多越可靠”。重复次数增加会占用更多时频资源在负载高的时候反而拉高碰撞概率。而且多次重复之间如果信道相关性很强增益是打折的。合理的做法是按信道质量和负载动态调整而不是写死一个最大值。另一个常被忽略的是 PDCP 复制。它把同一个包在两条路径上同时发接收端取先到的那个。这个方案对可靠性的提升很直接代价是资源翻倍而且两条路径的时延差要控制住差太多等于白做。做双连接复制时我一般会先测两条路径的时延分布差值超过 2ms 就要重新考虑路径选择。4.3 99.999% 怎么测别自己骗自己这是我最想强调的一节。可靠性指标不是“跑一次 iperf 不丢包”就算达标。10⁻⁵ 的误包率你需要足够大的样本量才能有统计意义——至少百万级的数据包置信度才站得住。实操上我一般这么干固定包长比如 200 字节贴近工控业务、固定发送速率、持续灌包 30 分钟以上统计丢包率、时延的 P99 和最大值、抖动分布而不是只看平均值。平均值好看、P99 爆炸在工控场景就是不合格。# 用 UDP 灌包固定包长和速率统计端到端表现 iperf3 -c server_ip -u -b 20M -l 200 -t 1800 --logfile urllc_test.log # 同时用 ping 观察时延抖动分布 ping -i 0.005 -c 200000 server_ip | tail -5跑测试的时候有几个坑必须提前排掉。一是时间同步两端时钟不同步测出来的单向时延全是错的至少要做秒级对齐并记录偏差。二是终端能力很多模组默认不支持短调度和免调度特性你不去查能力上报测出来的其实是“普通模式下的时延”。三是后台流量测试机上跑着系统更新或者日志上传数据全废。四是核心网选路用户面如果绕了一圈才到服务器你在空口上再怎么优化都是白费。5. mMTC连接数背后是成本与功耗的硬仗5.1 连接密度和信令风暴的真实关系标准里写的是每平方公里百万连接。这个数字是容量口径不是“一个小区塞一百万台”。实际规划时我按每小区几万台去估算还要看这些终端的上报频次。算一笔账假设一个小区覆盖 5 万台终端每台每小时上报一次平均下来每秒约 14 次接入请求。听起来不多但 mMTC 的特点是“潮汐式”——早晚上报高峰可能集中在十分钟内那一瞬间每秒就是上百次接入。前导码只有 64 个竞争碰撞概率迅速上升大量终端退避重试接入时延从几百毫秒涨到几秒。这里的工程手段有三层。第一层是错峰把上报时间打散加随机偏移这一层最便宜也最有效。第二层是减少状态转换用非激活态承载小包传输避免每次都走完整的连接建立和释放流程。第三层才是扩容加载波、加前导码资源、加接入机会。提示很多 mMTC 项目“接不上去”的根因不在无线侧而在平台侧。终端批量上电同时注册平台连接数被打满、认证接口被压垮表现出来和网络拥塞一模一样。排查时先看核心网信令和平台日志别一上来就调无线参数。5.2 省电和覆盖增强一颗电池要撑五年mMTC 终端的成本敏感度极高很多场景装上去就不打算再维护电池要撑三到五年。这决定了它的射频和协议栈必须做减法带宽窄、发射功率低、接收机简单、大部分时间在睡觉。省电的核心是“睡得久、醒得快”。非连续接收的周期可以配到分钟级甚至更长终端在睡眠期间几乎不耗电醒来后快速同步、发一个小包、再睡回去。这里的关键参数是睡眠周期和唤醒窗口的长度周期越长越省电但下行可达性越差业务要能接受“叫醒要等几分钟”。覆盖增强靠的是重复传输和功率谱密度。窄带把能量集中在一个很小的带宽上同样的发射功率功率谱密度能抬高十几 dB这就是为什么 mMTC 的覆盖能比普通业务多穿透一两堵墙。再加上时域重复链路预算能再挤出一些余量。代价是速率低、时延大所以它只适合“不着急的小包”。手段收益代价窄带传输功率谱密度提升覆盖增强峰值速率低时域重复链路预算增加时延增大、资源占用多长睡眠周期功耗大幅下降下行可达性变差小包免连接传输省信令、省电包长受限、可靠性一般5.3 大规模接入的现场经验我在一个模拟的抄表类项目里遇到过典型问题五千台终端在凌晨集中上报前两千台很顺后面三千台大量超时重试几次后平台侧积压。排查下来是三个原因叠加——上报时间没打散、前导码资源被普通业务共用、平台侧的并发处理能力不足。处理顺序很重要先在上报策略里加随机抖动比如五分钟窗口内随机再看接入资源是否给 mMTC 单独划了一块最后才动无线参数。加完抖动之后成功率从六成上到九成五剩下的靠资源隔离解决。这个案例告诉我的道理是mMTC 的问题八成是“节奏问题”不是“能力问题”调度策略比堆硬件便宜得多。另一个坑是终端模组的休眠唤醒行为不一致。不同批次的模组唤醒后的同步时间差很多有的几十毫秒有的几百毫秒。批量部署时如果混批次接入行为会变得很难预测。我的做法是尽量统一模组型号和固件版本把同步时间纳入出厂测试项。6. 三场景共存切片配置与协同调度怎么落地6.1 从业务 SLA 到切片参数的映射切片不是玄学它的本质是把业务需求翻译成一组 QoS 参数和资源策略。翻译的第一步是选 5QI这个值决定了调度优先级、时延预算、丢包率目标和是否保障速率。业务类型5QI 取值参考保障类型时延预算会话类语音1保障速率100ms实时游戏/交互3保障速率50ms视频流非保障类常见 6/7/8/9非保障100~300ms低时延非保障79/80非保障50ms 量级工业控制类82/83/84/85时延敏感保障5~30ms 量级选完 5QI再往上叠切片标识、调度优先级、资源预留比例。下面这段是我常用的切片配置模板字段做了脱敏逻辑是通用的sliceProfile: sliceId: 1 serviceType: uRLLC qosFlows: - qfi: 1 fiveQi: 82 arp: 3 # 抢占优先级数值越小越优先 preemptionCapability: true preemptionVulnerability: false resourcePolicy: prbReserveRatio: 20 # 为该切片预留 20% 物理资源 schedulingWeight: 8 # 调度权重高于普通切片 transport: upfPlacement: edge # 用户面下沉 n3LatencyBudget: 2ms这份配置里我最在意的是抢占能力和预留比例两个字段。预留太少uRLLC 在忙时抢不到资源预留太多eMBB 的可用容量被白白锁死。我的经验是从 15% 到 20% 起步跑一段时间的并发压测再调。6.2 边缘计算对时延的实际贡献用户面下沉到底能省多少拿光纤传输做个粗算光在光纤里的传播速度约每毫秒 200 公里含绕路系数来回一趟 100 公里大约贡献 1ms。这还没算中间的路由器、防火墙、承载设备。所以把用户面从城市机房下沉到园区省下来的通常是 3 到 8ms具体取决于原来的路径有多绕。这个数字对 eMBB 意义不大对 uRLLC 是生死线。我在几个项目里做过对比同一套空口参数用户面不下沉端到端时延稳定在 18 到 25ms下沉到园区机房后稳定在 8 到 12ms。差异几乎全部来自传输段。所以做 uRLLC 方案先问清楚用户面放哪再谈空口优化顺序不能反。6.3 隔离与并发压测才是照妖镜切片做完了单业务测试一切正常这不代表交付完成。真正的问题是当 eMBB 用户把带宽跑满时uRLLC 的时延还稳不稳我的验证方法是并发压测一边用大流量灌 eMBB 切片一边对 uRLLC 切片做固定速率的小包测试观察时延 P99 和丢包率。如果 uRLLC 的时延曲线在大流量起来之后明显上翘说明隔离没做到位要么预留不够要么调度权重不够要么两类业务还在同一套资源池里抢。验证项方法合格判据时延隔离背景流量 80% 负载下测 uRLLC P99相对空载恶化不超过 30%速率隔离多切片并发看各自达成率保障类切片达成率不低于 95%接入隔离mMTC 潮汐接入时测 eMBB 接入时延不出现明显劣化故障隔离单切片异常观察其他切片不扩散、不雪崩这张表我每次交付都会跑一遍。压测不过关就上线后面一定会出问题而且是那种“平时好好的、一到忙时就不行”的问题排查成本极高。7. 常见问题与排查路径实录7.1 典型现象怎么定位现象一uRLLC 时延偶发尖峰。先看尖峰出现的时刻是否和某些周期性行为对齐——测量上报、系统消息广播、邻区测量。如果对齐多半是终端在测量间隙里错过了调度机会。再看核心网侧有没有周期性任务。最后才怀疑空口。现象二eMBB 速率上不去但信号很好。顺序是查调度 RB 数是不是只给了一部分、查 MCS 分布是不是卡在低阶、查单双流占比是不是一直单流、查外环收敛、查是否有邻区干扰。这个顺序能覆盖八成情况。现象三mMTC 批量接入失败。先看平台连接数和认证接口再看前导码碰撞统计再看接入资源是否被其他业务挤占最后看终端侧的发射功率和同步行为。现象四切片配了但没生效。这类问题最常见的原因是终端侧没有把业务流映射到正确的 QoS 流上。网络侧配得再对终端把包塞进默认承载切片就是摆设。排查时抓包看 DSCP 标记和 QoS 流标识一看便知。7.2 速查表现象优先排查常见根因处理方向时延 P99 超标核心网路径、用户面位置用户面绕路、传输跳数多下沉用户面、缩短路径上行速率低上行干扰、功控参数交叉时隙干扰、远距离同频统一配比、调下倾、换频接入成功率低前导码碰撞、接入资源潮汐接入、资源被挤占加随机偏移、资源隔离切换频繁波束配置、切换门限波束过窄、门限过松调宽波束、加迟滞终端耗电快睡眠周期、唤醒窗口周期太短、下行寻呼频繁拉长周期、优化寻呼切片速率不达标预留比例、调度权重预留不足、权重太低调高预留、加权重7.3 几条用经验换来的心得第一指标要成对看。只看速率不看时延、只看时延不看抖动结论一定是偏的。我习惯把速率、时延 P99、丢包率、抖动四个数放一张表里缺一个都不下结论。第二先怀疑配置再怀疑设备。我经手的“设备故障”里超过一半最后是参数配错或者能力没开。终端不支持短调度、切片标识没映射、QoS 流配错方向这些都是配置层面的事。第三测试环境要和现网同构。在实验室里跑得再好现网的用户面路径、传输设备、终端型号一变结果就全变。能下沉的用户面一定下沉能统一的模组型号一定统一。第四给业务方留余量。标称 10ms 的时延方案里按 15ms 设计实测留 20% 余量。这不是保守是给后续扩容、加业务、换终端留出空间。我见过太多按标称值卡着设计的方案上线三个月就开始天天处理投诉。第五别迷信新特性。标准里写的能力很多现网支持程度参差不齐。上一个特性之前先在目标区域做小规模验证确认终端、基站、核心网三段都支持再批量推。这个领域往后还有得折腾RedCap 把 mMTC 和 eMBB 之间的空白填了一块确定性子网络把 uRLLC 从“低时延”往“可承诺的时延”推了一步。但底层那套逻辑没变先把业务归到正确的场景里再按场景去算账最后用压测验证隔离。这三步走扎实了方案基本不会翻车。