简介中国电信物联网模组需求白皮书-4G Cat1单模分册2020.v1是面向物联网模组制造商、方案集成商与测试认证人员的官方技术规范旨在统一4G Cat1单模模组的制式频段、通信能力与业务功能要求解决终端产品入网规格不一致的问题。白皮书以Cat1ONLY-xxx编号逐条定义必选/可选指标覆盖制式与频段、VoLTE、数据与短信业务、IPv4/IPv6、定位、机卡指令、APN/IMEI配置、远程升级及待机/数据功耗等模块并标注要求等级内容按功能域组织可快速定位具体需求条目。文件为单个PDF压缩包约357KB适合选型评估、协议开发或合规测试时离线查阅已有291人学习浏览对从事Cat1产品定义、软硬件实现及运营商入网测试的工程师有直接参考价值。尤其在模组选型与入网认证阶段可帮助团队减少需求理解偏差、提高研发交付效率。1. 4G Cat1 单模白皮书一张 2020 年的需求清单为什么今天还能当选型尺子如果你做过物联网模组选型大概率经历过这种场景产品定义说要“低成本中速率”你把 NB-IoT、Cat.1、Cat.4 三个方案摆在桌面上最后发现真正卡脖子的不是网速而是运营商网络策略、模组固件能力和语音方案这些藏在参数表后面的东西。这份 4G Cat1 单模白皮书恰好把这些隐性问题拆成了可以逐条对照的需求条目。它成稿于 2020 年版本停在 v1但里面定义的硬件接口、功耗档位、软件协议栈和测试方法至今仍是 Cat1 方案选型与验收的有效参照。适合三类人要给终端挑模组的硬件工程师、做协议栈联调嵌入式的软件工程师以及负责模组认证测试的测试人员。5G 模块已经满街跑的今天Cat1 反而以“够用不贵”的位置稳住了大批存量物联网场景这份白皮书正好帮你把“够用”两个字量化成指标。2. Cat1 技术选型在打开白皮书之前先算清速率、成本与覆盖的三笔账白皮书里的每一条需求本质上都是对网络能力和芯片能力的约束。不先把 Cat1 在 LTE 家族里的位置搞清楚你读到的只会是一堆零散的参数。这一章先把技术账算明白后面拆需求条目时才不会看晕。2.1 速率与成本Cat1 站在 LTE 与 NB-IoT 之间哪个位置LTE 的终端能力等级里Cat.1 常被叫做“低速 LTE”它在 FDD 模式下的典型峰值是上行 5Mbps、下行 10Mbps这个数字只有 Cat.4 的十分之一左右却比 NB-IoT 高出一到两个数量级。对绝大多数物联网业务来说真正需要的不是峰值速率而是稳定的“基线速率”像共享设备的心跳上报、定位数据的周期回传、远程设备的固件升级几十 Kbps 到几百 Kbps 就够用但要求时延可控、网络覆盖成熟。Cat1 的成本优势来自两点。一是芯片复杂度低协议栈不需要像 Cat.4 那样支持高阶 MIMO 和载波聚合基带面积和内存开销都小模组价格随之降下来。二是网络不用改造直接复用现有 LTE 基站不像 NB-IoT 早期要等运营商补覆盖。白皮书把“单模”作为分册主题本质上是把成本控制推到极致只留 LTE 一种制式砍掉 2G/3G 的兼容成本。选型时最容易犯的错误是拿 Cat1 跟 NB-IoT 比功耗、跟 Cat.4 比速率。白皮书的处理方式值得借鉴它先列应用场景再反推速率和时延需求最后才落到具体模组能力。你手上如果有一个数据上报类产品先算清楚单包大小、上报频率和可容忍时延再决定要不要为“偶尔一次大包升级”多付 Cat.4 的成本。我一般会把三个档位画成一张简表NB-IoT 适合每天几 KB 的抄表类业务Cat1 适合分钟级上报加少量下行控制的场景Cat.4 适合视频或大文件回传。白皮书的分册定位恰恰卡在中间这一档。2.2 单模的隐含代价没有 CS 域语音和短信都要换路“单模”两个字看着简单落到产品设计上会牵出一连串连锁反应。传统 2G/3G 模组有电路域CS 域语音和短信是基础能力LTE 网络从设计之初就是纯分组域语音必须走 VoLTE短信则要依赖 IMS 域。Cat1 单模模组如果不支持 VoLTE那它在网络上就是个“哑终端”——能收发数据但打不了电话、收不了短信。白皮书对语音能力的需求描述值得认真读它要求模组支持 VoLTE 相关功能包括 IMS 注册、语音呼叫和通话与数据并发。这里的关键词是“并发”。很多工程师测试 VoLTE 时只验证“能打通电话”忽略了通话过程中数据业务是否中断。白皮书的逻辑是终端在通话时可能同时在上报位置或接收指令如果语音一接通数据就断业务逻辑就得重设计。短信同样被很多人忽略。LTE 下短信走 IMS 的 SMS over IP或者回落 CSFB而单模 Cat1 没有 CS 域可回落所以只能靠 IMS。白皮书把 SMS over IP 作为需求条目列出来意味着选型时你要确认模组固件是否开启了这个功能而不是默认“短信谁家都有”。我在一个定位终端项目里就翻过这个车整机测通话、数据都正常最后验收时才发现短信收不到排查了两天才定位到模组默认配置里没开 SMS over IP。2.3 白皮书的章节骨架需求条目是怎么从场景拆到指标的打开这份白皮书你会发现它不是一份“建议”而是一份“需求条目清单”。它的组织方式是从终端形态出发把需求拆成硬件、软件、协议、安全、可靠性和测试验证六块。每块下面再按功能点列条目条目带有优先级和说明这种结构对后续选型和验收特别友好。比如硬件章节会拆出模组尺寸、封装形式、接口电平、天线接口、SIM 卡接口、电源域这些子项软件章节会拆出 AT 指令集、协议栈版本、功耗模式、网络注册、数据上报、固件升级协议部分会细化到 LTE R13/R14 的版本要求和 VoLTE 相关协议栈。每个条目都对应一种“验收动作”有的可以通过查规格书确认有的必须实测有的要等入网认证结果。这种拆法最大的好处是让需求可追溯。你拿着自己产品的需求清单和白皮书逐条核对会发现很多平时容易漏的细节——比如模组对输入电压的纹波要求、天线 VSWR 的容限、以及模组在弱信号下的发射功率回退策略。下一章开始按硬件、软件、协议三条线把白皮书里的核心需求拆开讲并给出对应的验证方法。3. 硬件需求拆解接口电平、天线参考设计与功耗验收三步走硬件需求是白皮书里最“硬”的部分也是选型时最先被对比的部分。但只看模组规格书上的标称值不够很多需求只有在终端设计语境下才有意义。这一章沿着接口电气、天线射频、功耗三块走一遍顺手给出可执行的验收方法。3.1 接口与电气需求UART、SIM、GPIO 的白皮书边界白皮书对模组接口的描述重点不在“有哪些接口”而在“接口的电气边界”。以最常见的 UART 为例涉及主串口的电平标准——1.8V 还是 3.3V、波特率范围、流控是否需要硬件 RTS/CTS、以及串口在模组休眠时的状态。如果你用 3.3V 单片机直连 1.8V 电平的模组轻则通信不稳定重则烧毁接口这是选型阶段就应消掉的隐患。SIM 卡接口的坑更多。白皮书会要求模组支持 eSIM 和可插拔 SIM 两种形态同时对 SIM 卡检测引脚、时钟频率、复位时序都给出需求。实际联调时我遇到过模组偶发读不到卡最后发现是 SIM 卡座到模组的走线太长、寄生电容超标导致卡时钟信号变形。白皮书里对 SIM 接口的需求本质上是在约束你的 PCB 设计走线长度、包地、ESD 保护器件的位置都要纳入考量。GPIO 的边界条件也值得逐条看。模组的 GPIO 大多复用功能哪些引脚支持中断唤醒、哪些支持 PWM、哪些在休眠时保持电平这些直接决定你的按键扫描和传感器供电设计。我一般会建议硬件工程师做一个接口对照表左边列白皮书需求中间列模组规格书承诺右边列实测时的勾选记录。这个习惯能帮你筛掉不少“规格书写支持、实际固件没启用”的尴尬情况。3.2 天线与射频关键项从参考设计反推验收指标白皮书会给出模组厂家的天线参考设计包括天线到模组的匹配电路、走线阻抗、以及板材和层叠建议。这一节的核心指标是 VSWR 和插入损耗。常见做法是要求天线在目标频段内 VSWR 小于 2:1回波损耗优于 -10dB传导线损控制在 0.5dB 以内。记住这些数字要放在整机环境里验证而不能只在射频测试座上测。频段方面Cat1 单模模组的需求通常覆盖 B1/B3/B5/B8 这几个 LTE 频段但对具体的终端产品不一定所有频段都要启用。白皮书的需求写法一般是“支持以下频段”然后在附表中标注各频段的收发通道和功率等级。选型时要把你目标市场的运营商频段对齐避免买了全频段模组却因为频段使能配置不对而无法入网。验收时建议按这个顺序测先用综测仪测模组传导发射功率和灵敏度确认模组本身没问题再装进整机用耦合方式测辐射性能对比白皮书给出的参考值。常见翻车点是金属结构件对天线的吸收会让灵敏度下降 3dB 以上这种情况只能靠结构调整和匹配调试解决不是模组本身的缺陷。3.3 功耗档位与实测步骤电流曲线怎么看白皮书对功耗的需求一般会按工作状态拆成几个档位PSM 休眠、Idle 寻呼、数据收发峰值以及 VoLTE 通话平均电流。不同档位的占比直接决定终端的续航所以白皮书会给出各状态下的典型电流需求上限。功率档位 | 常见典型电流参考值 | 测量时长 | 关注点 PSM 深睡 | 4~8 μA | 至少 30 秒 | 是否稳定无漂移 Idle 寻呼 | 1.5~2.5 mA | 覆盖一个寻呼周期 | 周期性电流尖峰 数据 RX 平均 | 80~120 mA | 连续下行 1 分钟 | 与信号强度相关性 数据 TX 峰值 | 200~400 mA | 按发射功率档测 | 高功率档的持续时间 VoLTE 通话平均 | 100~180 mA | 通话全程 | 与信号强度相关性实测时用高精度电流钳配合示波器记录电流曲线。先让模组附着网络并进入 PSM观察深睡电流是否平稳然后触发一次数据上报记录完整的“唤醒—驻网—发送—回落”电流波形。重点看两处一是唤醒瞬间的电流尖峰有多高二是回落到 PSM 用了多长时间。如果回落时间超过白皮书需求整机续航会被严重拖累。注意白皮书里的功耗需求是对模组单体而言整机功耗还要加上传感器和外设的贡献。如果你在实验室测得的模组 PSM 电流正常整机却仍跑不满待机时长排查方向应转向外设漏电和电源轨设计。这部分没有捷径只能逐路断开外设做排除法。4. 软件协议栈与语音方案AT 指令、openCPU、VoLTE 的分工边界硬件决定了模组的上限软件决定了它能不能在你手里跑起来。白皮书对软件需求的定义不只是“支持 AT 指令”这句话而是把指令分类、协议栈版本、二次开发方式和语音通路都做了约束。这一章拆开讲并给出一个把白皮书条目映射到模组规格书的实用脚本。4.1 AT 指令需求分类白皮书把指令拆成了四组白皮书在软件章节里会把模组必须支持的 AT 指令拆成几组网络控制类、数据业务类、语音与短信类、以及配置管理类。这种拆法和实际联调的顺序完全一致先让模组完成网络注册再建立数据连接然后跑业务最后做参数配置。网络控制类以ATCFUN、ATCOPS、ATCEREG为代表对应的是模组的射频开关、运营商选择和网络注册状态。联调时最常看的是ATCEREG返回的注册状态码0 表示未注册1 表示已注册5 表示已注册但漫游。白皮书会对“注册超时时间”和“反复网络搜索”行为做出需求约束避免模组在弱信号区频繁搜网导致功耗飙升。数据业务类核心是ATCGDCONT设置 APN以及ATCGACT激活 PDP 上下文。这里有个高频坑APN 参数跟 SIM 卡的签约信息不匹配会导致模组注册成功但ATCGACT激活失败。白皮书会把 APN 的设置方式和默认值列入需求选型时确认模组是否支持通过 AT 指令灵活配置 APN 即可。语音与短信类集中在 VoLTE 相关指令和 SMS over IP 配置配置管理类则是模组参数的上报查询和恢复出厂设置。这几组的共同特征是“可配置性”白皮书看重的是模组能否通过固件参数适配不同运营商的网络差异。我一般建议在选型时直接向模组原厂要一份完整的 AT 指令集文档与白皮书的指令分类做交叉对照别只信规格书里那句“支持标准 AT 指令”。4.2 openCPU 的适用边界什么场景必须用什么场景劝退openCPU 模式让模组直接运行你的应用代码省掉外部主控成本和功耗都能降一截。白皮书对 openCPU 的需求描述通常聚焦两点支持的开发框架和可用的外设资源。但这个模式不是免费的午餐它的代价是应用和协议栈共享同一份算力任务调度、内存溢出和异常重启都会互相影响。什么场景必须用 openCPU典型是成本极度敏感的数据透传类产品业务逻辑简单到只有“周期上报、远程配置”省一颗主控的成本非常可观。什么场景劝退只要业务里有复杂的 TLS/加密算法、本地 GUI、或者需要跟多个外设持续交互我都建议保留独立主控。白皮书对 openCPU 架构的模组会要求提供完善的异常日志和看门狗机制就是为了对冲“应用与协议栈耦合”的风险。用 openCPU 时的调试习惯和普通 MCU 开发不同。模组跑飞后不会像单片机那样容易复现你必须依赖模组原厂的 trace 工具抓取协议栈日志和应用日志。我在一个资产追踪项目里吃过教训openCPU 应用里一个内存池配置不当导致设备运行两三天后自动重启排查了整整一周才定位。从那以后凡是用 openCPU 的项目我都会强制要求原厂提供内存回收机制的说明并在压力测试阶段连续跑 72 小时再放行。4.3 VoLTE 与语音切换单模 Cat1 的通话与数据并发单模 Cat1 的语音只能走 VoLTE因此白皮书对 VoLTE 的关注集中在两个维度IMS 注册流程的稳定性和通话与数据业务的并发能力。IMS 注册失败是 VoLTE 最常见的问题原因往往是 APN 配置不对、IMS 参数缺失或者网络侧没有开通 VoLTE 权限。联调第一步应该是验证模组的 IMS 注册状态而不是直接拨号。通话与数据并发则要关注“呼叫保持”和“QCI 承载”。VoLTE 语音走 QCI1 承载数据业务走 QCI9 或 QCI8两者理论上可以并行。但实际测试时你会遇到通话中数据速率明显下降或者通话结束后数据连接无法恢复的情况。白皮书的需求写法是要求模组在通话前后保持数据会话的稳定性这就要确认模组固件是否支持多承载并行管理。测试方法建议按这个顺序走先让模组附着网络并确认 IMS 注册然后发起 VoLTE 呼叫在通话保持的状态下做一次数据上下行传输记录是否有中断或速率骤降最后挂断电话并检查数据连接是否自动恢复。这组用例应该写进你的验收清单而不是只测“语音打通”就收工。4.4 把白皮书条目映射成选型清单一个 60 行的校验脚本白皮书条目和模组规格书并不是一一对应关系逐条手动核对效率太低。我一般会写一个小脚本把白皮书的条目拆成结构化清单再跟模组规格书的关键参数做映射输出一张待验证表单。下面是一个简化示例用 CSV 输入最后生成带匹配状态的检查列表。import csv from collections import defaultdict # 白皮书条目需求编号、需求描述、需求类型、优先级 white_paper_items [ (HW-01, UART 接口电平支持 1.8V/3.3V, 硬件, P0), (HW-02, 天线 VSWR 小于 2:1, 硬件, P0), (HW-03, PSM 待机电流小于 10uA, 硬件, P1), (SW-01, 支持 ATCGDCONT 配置 APN, 软件, P0), (SW-02, 支持 SMS over IP, 软件, P1), (RF-01, 支持 B1/B3/B5/B8 频段, 射频, P0), (VO-01, 支持 VoLTE IMS 注册, 协议, P0), ] # 模组规格书参数名、承诺值、对应需求编号未匹配则留空 spec_sheet { UART 电平范围: (1.65V~3.6V, HW-01), 天线VSWR容限: (2.0:1, HW-02), PSM 典型电流: (7uA, HW-03), APN 配置指令: (ATCGDCONT, SW-01), SMS over IP: (固件2.1以上支持, SW-02), 频段列表: (B1/B3/B5/B8, RF-01), IMS 注册: (支持, VO-01), } matched [] unmatched [] for item_id, desc, item_type, prio in white_paper_items: found None for spec_name, (value, ref_id) in spec_sheet.items(): if ref_id item_id: found (spec_name, value) break if found: matched.append((item_id, desc, spec_sheet[found[0]][0], 待实测确认)) else: unmatched.append((item_id, desc, 规格书中未找到对应项, 需要联系模组原厂确认)) print(--- 已匹配需求条目 ---) for row in matched: print(f{row[0]} | {row[1]} | 规格书值: {row[2]} | 状态: {row[3]}) print(\n--- 未匹配需求条目 ---) for row in unmatched: print(f{row[0]} | {row[1]} | {row[2]} | {row[3]})这段脚本的逻辑很直接白皮书条目作为基准列表模组规格书作为参数来源通过ref_id建立关联。跑完之后已匹配的条目会进入“待实测确认”状态未匹配的条目则标记为需要向原厂核实。参数说明里的两个要点一是“未匹配”不代表模组不支持可能只是规格书没写需要找原厂确认二是脚本里的spec_sheet应该替换成你手上真实模组的规格书数据并定期维护。脚本跑出来的清单可以直接作为下一章验收测试的输入。你会发现自己对“哪些条目已经验证过、哪些还停在纸面”一目了然而不是等产品进量产才暴露问题。5. 避坑Cat1 模组验证与量产中最容易翻车的五个细节白皮书把需求写得再清楚落地时该翻的车一个都不会少。这一章整理我在 Cat1 方案调试和验收中反复遇到的五个问题每条按“现象、原因、解决”的顺序说清希望能帮你少走几趟黑匣子。5.1 现象RSRP 显示正常但模组一直附着不上网络用ATCEREG?查询状态始终是 0 或 2而同一位置手机信号满格。原因往往是模组的频段使能配置不对——模组支持全频段但出厂固件默认只开启了部分频段或者你所在网络的主载波频段恰好被禁用。解决方法是先用ATCOPS?查询可见网络再逐频段拨测确认实际覆盖最后通过 AT 指令把目标频段设为使能状态。这个问题的隐蔽性在于 RSRP 查询用的是当前服务小区而附着过程要扫描所有使能频段两者逻辑不一样。5.2 现象实验室测模组功耗达标整机续航却短了三分之一排查过程发现外设全部断开后功耗才正常接上传感器后待机电流高了 0.5mA。原因不在模组而在传感器供电和 I2C 上拉电阻传感器在“关闭”状态下仍有漏电通路I2C 上拉电阻直接挂在常电电源轨上也会持续耗电。解决方法是把传感器供电改成 GPIO 控制只在采样瞬间供电所有上拉电阻的电源域也要核查不能想当然地接常电。白皮书里的功耗需求是对模组单体整机功耗的每一微安都得自己抠。5.3 现象VoLTE 通话测完挂断数据业务一直停在“已断线”状态通话过程中数据确实保持并发但挂断后ATCGACT?显示 PDP 上下文已去激活。原因通常是网络侧的 TAU 流程和模组的多承载释放逻辑配合不好或者 APN 设置的定时器参数较短通话期间数据承载被网络侧释放后模组没有及时重建。解决方向是调整 APN 配置中的定时器参数同时升级模组固件版本并做“通话一分钟再挂断、频繁呼叫挂断”的重复性测试。这个问题靠单次拨测很难复现必须安排长时间压力脚本。5.4 现象天线接口明明是可拆卸的传导性能却比参考设计差了 2dB拿综测仪测传导功率和灵敏度数据都不如白皮书里的参考值。原因大概率在射频线缆和转接头的损耗上尤其当你用了非屏蔽射频线、转接头阻抗不匹配或已经磨损时损耗会被算进“模组性能”里。解决方法是检查测试环境射频线要用原厂推荐型号转接头要定期用校准件验证测试座的接地要可靠。这个坑最坑人的地方是它会让你误判模组本身不合格实际是测试治具在作祟。5.5 现象白皮书里写 P1 的需求模组规格书里只有“可选支持”字样跟原厂技术支持确认后得知该功能要在特定固件版本里才完整生效当前出厂固件只是预留了接口。原因是白皮书的优先级是“这份需求文档里”的优先级模组厂对功能的支持程度取决于芯片能力和固件计划。解决方法是把“可选支持”标记为“待固件版本验证”在选型评审中以原厂书面承诺为准而不是以规格书上的软性描述为准。我一般会在选型表里加一列“原厂确认人”把口头确认落到邮件或文档上。6. 把白皮书变成一张验收 check list七个用例跑完选型闭环前面五章把硬件、软件、协议和踩坑都过了一遍最后一步是把这些内容收敛成一张可以带进实验室的验收表。我习惯的做法把白皮书的章节标题映射成验收用例每个用例只跑最关键的一项七个用例跑完选型结论基本可靠。用例编号验证项对应白皮书章节通过标准TC-01频段注册射频需求目标频段ATCEREG1RSRP 优于 -110dBmTC-02数据连接数据业务需求APN 正确设置后ATCGACT1Ping 成功率 100%TC-03PSM 功耗功耗需求深睡电流低于标称上限唤醒回落时间达标TC-04天线性能射频参考设计整机耦合灵敏度不低于传导值 3dBTC-05VoLTE 注册语音需求IMS 注册成功发起呼叫时延小于 5 秒TC-06通话数据并发语音与数据需求通话中数据速率不低于平时 70%挂断后数据自动恢复TC-07固件升级软件管理需求DFOTA 升级成功率 100%升级后参数不丢失每个用例都要留一列记录实测值和结论不能只打勾。比如 TC-01 要写清当时实测的 RSRP、SINR 和注册耗时TC-03 要附上电流曲线的截图。这样就算换了批次的模组也能快速对比差异。这套 check list 的落地技巧在于白皮书是文档而你的产品需求是活的。同一颗模组用在固定位置和车载移动场景天线和功耗的验收标准完全不同。我会把白皮书条目拆成“强制”“条件”“参考”三档强制项不通过直接一票否决条件项在满足特定场景时生效参考项只用来横向对比方案。这个习惯帮我挡掉过至少两次“规格书看着没问题整机才暴露缺陷”的事故。希望这一套思路也能帮到你的 Cat1 选型项目少跑几趟冤枉路。本文还有配套的精品资源点击获取