干了十几年通信最明显的感觉是打电话的人越来越少问能不能帮我把这个箱子里的定位数据传回来的人越来越多。物联网这个概念被炒了很多年别人看到的是智能家居、智慧城市、大风口我看到的是另一件事——每一个物联网设备的背后本质上都在问同一个问题这条数据从设备到云端走哪条路、怎么走、要花多少钱。作为通信人我对物联网发展的观察从来不是从商业模式开始的而是从信号、频段、功耗、覆盖、并发这些最基础的东西开始的。这篇文章就想以一个通信老兵的身份聊聊物联网这二十年的发展脉络、接入技术的真实取舍、以及我在各种物联网项目里踩过的坑和摸出来的规律。不管你是做硬件、做平台、做运营还是刚入行的新人只要能理解连接这件事在物联网里到底有多重后面的路就会顺很多。1. 从M2M到IoT通信人看到的二十年演进脉络1.1 物联网不是凭空冒出来的它是M2M的互联网化改造很多人以为物联网是智能手机普及之后才有的东西其实不是。早在电话线还横行的时候工业界就有一种叫M2MMachine to Machine机器对机器通信的玩法工厂里的PLC通过串口、RS-485、甚至拨号Modem把数据传到控制中心电力公司用电力线载波读取远程电表油田上有人用卫星终端回传油井的压力数据。那时候没有物联网这个名词但做的事情和今天的物联网一模一样让机器开口说话。区别在于传统M2M是封闭的。设备对设备、设备对专网协议私有数据出不去客户也基本局限在电力、工业、石油这些重型行业里。真正让物联网成为大众话题的是互联网基础设施的蔓延和成本下降。当2G/3G蜂窝模组的价格从几百块跌到几十块当云平台开始提供便宜的设备接入服务M2M这个封闭体系就被彻底打开了——每个设备都能直接连上互联网数据不再是躺在某个工控机硬盘里的死数据而是能流向云端、被分析、被可视化、被做成业务。我管这个阶段叫M2M的互联网化改造。它看起来只是换了传输通道实际上改变了整个产业链结构原来一个项目要自己架设通信链路现在只需要买一张卡、一个模组、一个云账号。门槛降低的直接后果是物联网从工业专属变成了万业皆可试。1.2 物联网和消费互联网的本质区别连接对象决定了一切做了这么多年通信我最大的体会是物联网和消费互联网在通信需求上的差异不是设备多了一点这么简单而是整个思维模式的倒转。消费互联网的核心连接对象是人。人的特点是愿意为体验付费、手机没电了会主动充电、Wi-Fi断了会自己去重启路由器。人是整个通信链路的自适应补偿单元。物联网的连接对象是机器。机器没有耐心没有判断力没有主动修复故障的能力。一个放在地下车库的水表不会因为信号不好就自己挪个位置一个装在电线杆上的环境传感器不会主动告诉你我的天线被鸟啄歪了一个部署在偏远牧场的定位项圈如果三天没上报不是它在偷懒是你的网络链路已经断了只是没人知道。通信行业为了人设计了几十年的网络——高带宽、低时延、移动性切换、无缝覆盖。但物联网反着来它更在乎覆盖率、低功耗、海量连接、深度覆盖而对速率和时延的敏感度反而没那么高。这个基本矛盾贯穿了物联网发展的全过程也是后面所有接入技术分化、演进的根本动力。2. 连接的真相物联网比我们想象的更挑食2.1 物联网没有万能接入技术先把候选清单摊开每次有人问我物联网用哪种通信技术好我都想说你这个问题本身就问错了。物联网的接入技术和人的饮食一样讲究营养均衡更讲究对症下菜。不存在一种绝对好的技术只存在在这个场景下最合适的技术。我把主流的物联网接入技术按覆盖半径和传输能力分成几类大家在选型时通常是这么挑的短距离局域类Wi-Fi、蓝牙、ZigBee。适合设备集中在室内或局域范围的场景比如智能家居、办公区资产盘点。优点是完全自主可控、流量不花钱缺点是覆盖半径小、穿墙能力有限。蜂窝广域类2G/3G/4G/5G以及专门为物联网设计的NB-IoT、LTE-M。适合跨城市、跨省的广域连接比如共享单车、车联网、物流追踪。优点是覆盖范围大、移动性管理成熟缺点是模组和资费成本相对高。低功耗广域非授权类LoRa、Sigfox这类技术。适合私网专用、自建网络的场景比如园区、农场、矿区。优点是单站覆盖远、设备功耗极低、不依赖运营商网络缺点是需要自己建网关、频段有管制风险、数据速率非常低。卫星类适合海上、荒漠、极地这些地面网络无法到达的区域。以前成本高企现在低轨卫星开始介入但功耗和资费依然不是常规物联网项目能随便用的。很多人纠结于蜂窝和LoRa谁更好这是没有意义的。一个连锁便利店公司的温湿度监控门店铺在城市里用4G/NB-IoT最省事一个几千亩的种植基地要布置土壤墒情站运营商覆盖可能只有村口那一格信号那自建LoRa网关反而更靠谱。接入技术选型的本质是对覆盖、功耗、成本、速率四个要素做加权打分谁的分数高用谁。2.2 链路预算才是物联网选型的生死线很多物联网项目的通信选型失败不是因为不懂技术而是因为不明白一个最基础的概念链路预算。链路预算说白了就是算一笔账发射端发出的信号功率经过天线增益、路径损耗、穿透损耗到最后接收端还能剩多少。这笔账的最后结果如果不是正的那设备不管怎么调永远都是信号满格但连不上或者时好时坏。我见过一个典型的失败案例某项目要在老旧小区楼道里安装智能烟感选了NB-IoT。宣传手册上说NB-IoT比2G覆盖能力强20dB能深入地下。但实际部署时发现烟感装在每层楼道靠近电梯厅的位置电梯井的钢筋混凝土结构加上周围密集的住户隔墙信号从室外宏站打进来到设备位置时损耗大得不忍直视。结果就是一两层楼有信号往上几层直接失联最后不得不加装室内分布系统成本翻了好几倍。问题出在哪里出在大家把覆盖增强理解成了无限穿透。NB-IoT的覆盖增强确实是真的比2G强很多但20dB的提升也扛不住连续的金属水箱、多层钢筋结构的损耗。钢筋混凝土的穿透损耗通常在15~25dB一层玻璃幕墙稍微好一点但也得算5~10dB。链路预算的时候如果只按空旷场景估算不做实地勘察后面一定会被现实打脸。老实说我后来做任何物联网项目的网络评估第一件事永远是拿模组和天线到现场做信号测试测完再谈选型。没有实测数据支撑的链路预算在纸面上算得再精确也只是一张废纸。2.3 一个共享单车定位器的通信选型复盘说一个我参与过的、看起来很简单但很能说明问题的案例某共享单车项目要给车辆装定位器要求是待机时间长、定位数据能实时回传、成本要低。第一版方案用的是4G Cat.1模组。为什么用Cat.1因为共享单车需要实时上报车辆位置还要支持远程开关锁用户扫码后指令必须在几秒内到达LoRa和NB-IoT都达不到这个交互速度。4G Cat.1在速率上够用资费比传统4G低一些网络成熟度高在某城市实测下来市区内覆盖很好基本没出过状况。但问题出在停放范围上。共享单车最容易被停放的几个地方是什么地下停车场入口的缓冲区、写字楼连廊、地铁站附近的天桥底下。这些地方恰恰是蜂窝信号最容易出问题的区域。项目上线第一个月后台就频繁出现车辆状态逾期未更新的告警排查了一圈定位器硬件没问题、平台没问题、SIM卡没问题最后带着设备去现场一测才知道天桥底下、地库坡道上信号强度直接掉到临界值以下。这个案例告诉我们三件事。第一物联网设备的移动性比想象中复杂不是车在哪信号就在哪而是车会被停到信号最差的地方。第二通信选型必须考虑业务的实际分布地图而不是看运营商的覆盖地图。第三必要的时候要舍得用外置天线或者双模方案——后来这个项目在部分区域加了蓝牙辅助定位让手机上报车辆位置再回传平台才算把覆盖率补上去。3. 五张网络一张床物联网的体系架构与通信协议栈3.1 从感知到平台一条数据要过几道门聊物联网通信最容易被忽略的是体系架构。很多人以为物联网就是传感器网络服务器但实际上一套完整的物联网系统要过好几道门。感知层是数据的源头。温度、湿度、位置、振动、电流、图像……各种传感器先把物理世界的状态转换成电信号再由模组封装成数据包。网络层负责把这数据包送到目的地。这一层最复杂因为它可能是通过Wi-Fi到路由器再走宽带可能是通过NB-IoT直接上运营商核心网可能是通过LoRa到网关再由网关用4G或光纤转发到云端。物联网的通信设计一半的功夫都花在这一层的路径选择和协议转换上。平台层负责设备管理、数据存储、规则引擎和API输出。设备接入平台后才谈得上远程控制、告警触发、数据可视化。应用层就是最终的业务呈现可能是手机App上的一个浇水按钮也可能是大屏上跳动的工厂能耗曲线。这个五层结构里最容易被项目团队低估的是平台层和网络层之间的协议对接。很多人觉得模组能ping通云服务器就行了但实际上从设备端的数据编码、到MQTT的Topic设计、再到平台侧的解析规则任何一环不匹配数据都只能在中间某段路上静默丢失。3.2 MQTT为什么成了物联网的事实标准物联网的通信协议有很多但MQTT几乎成了事实标准这不是没有原因的。MQTT是一个基于发布/订阅模式的消息协议体积小、开销低专门为低带宽、高延迟、不可靠环境设计。它的核心逻辑就是一台Broker消息服务器在中间转信设备往某个Topic上发布消息订阅了这个Topic的其他设备或平台就能收到。用一个生活化的类比MQTT像一个大楼里的中央快递柜。发件人不需要知道收件人具体在哪间房只需要把包裹投到指定的柜子里收件人也不需要守着收件口只需要告诉快递柜我订阅了某个柜号包裹一到就会被通知。这种解耦方式在物联网里太重要了因为设备端的IP地址经常变、网络经常断线重连如果你用传统的点对点HTTP请求设备一换网络就找不着了而MQTT通过一条长连接保持在线状态断线了会自动重连消息在离线期间还能攒在Broker上等设备回来取。另一个关键点是MQTT的QoS分级。QoS 0是尽力而为、丢了就丢了QoS 1保证至少一次送达但可能有重复QoS 2保证恰好一次。在抄表类业务里数据重复一份无伤大雅用QoS 1性价比最高在支付和远程控制这类高可靠性场景才需要QoS 2。很多人一上来就全部用QoS 2结果Broker压力大、效率低纯属自己给自己挖坑。3.3 协议选型失败的典型场景MQTT再受欢迎也不代表它是万能的。我见过一个做车联网的公司把车载终端的CAN总线数据全量打包成JSON通过MQTT每隔100毫秒往平台推。结果一台车一天产生几个GB的数据平台侧的带宽和存储费用飙升最后不得不推翻重来改成本地缓存加按需上传的模式。还有一类项目栽在HTTP上。设备端用HTTP定时上报数据看起来简单但HTTP是请求-响应模型服务器没法主动往设备推指令实现远程控制时只能用设备轮询的方式延迟大、功耗高。为了等指令设备得定期唤醒请求一次服务器结果功耗全耗在空转上了。这类项目我一看到就想摇头明明用MQTT一条长连接就能解决的问题非要用HTTP把自己折腾死。协议选型的核心原则只有一句话从业务需求倒推而不是从技术偏好正推。搞清楚你的数据多大多小、上报频率多快、时延要求多少、需不需要服务器主动下发再来选协议基本不会跑偏。4. 蜂窝物联网的前世今生NB-IoT和LTE-M的崛起逻辑4.1 2G退网倒逼出来的窄带革命蜂窝物联网这步棋很大程度上是被2G退网倒逼出来的。2G网络曾是物联网的主力。一个2G模组十几块钱功耗低覆盖好资费便宜很多智能水表、烟感、定位器都是2G的。但随着运营商陆续关停2G网络大量存量物联网设备面临断网而4G的功耗和成本又让很多低速场景用不起。这就形成了一个很尴尬的局面低功耗低成本的需求摆在面前但传统的蜂窝网络给不出答案。于是专门为物联网设计的窄带蜂窝技术出现了。NB-IoT的带宽只有200kHz专门为极小数据包、极低速率、大量连接、深度覆盖设计。它在覆盖增强、功耗、成本这三点上做出了非常大胆的取舍速率低到只有几十kbps但一个小区能容纳数万设备信号能比传统LTE强20dB左右模组成本也远低于4G。4.2 PSM与eDRX为了省电通信标准做出了哪些妥协NB-IoT最让人震撼的不是覆盖而是功耗控制。为了把一块电池的寿命撑到五年十年通信标准在设备和网络之间做了一笔不小的交易核心就是PSM和eDRX两种省电机制。PSMPower Saving Mode省电模式的逻辑是设备上报完数据后直接进入深度睡眠状态网络暂时保留它的注册上下文但当有下行数据要下发时设备并不能被实时唤醒只能等它下一次主动醒来。这就像你睡觉时把手机关成飞行模式别人发的消息只能等你睡醒了再看。对于抄表类业务这完全没问题但对于需要随时响应的远程控制类业务PSM就不能用了。eDRXExtended Discontinuous Reception扩展非连续接收则是让设备每隔一段较长的时间窗口去监听一次寻呼信道从而实现省电但依然能被找到的效果。听监听的周期越长越省电但下行指令的到达延迟就越长。这就像一个人每隔几分钟才瞄一眼手机消息平时手机处于静默状态。实际项目里经常有人把这两个机制搞混或者不向客户解释清楚就擅自用了PSM结果就是远程阀门能开但不能实时关客户半夜打电话来质问为什么我控制指令发出去十分钟了还没执行。这个坑是真的坑而且是坑哭人的坑。4.3 NB-IoT实测中我踩过的坑我在NB-IoT项目上踩过的坑不少挑三个常见的说。第一个坑是基站侧的配置不统一。NB-IoT虽然号称覆盖好但不同片区基站的功率配置、频点布局、TAC区划分都可能不一样。同一个模组在A区一切正常移到B区就频繁掉线重连查来查去才发现是B区的TAC配置有问题导致网络侧认为设备位置异常。这种问题终端开发人员搞不定必须让网络侧配合排查。第二个坑是信号好的时候功耗反而高。印象很深的一个项目设备装在高楼层NB-IoT信号极好RSRP值很高但电池掉电特别快。查了很久才明白信号太好导致设备始终选择最优的发射参数而发射功率等级差异会直接影响电流消耗。你以为信号好是好事实际上可能让设备以较高功率工作耗电反而不如信号一般时理想。第三个坑是模组固件版本差异。两个不同批次、不同固件版本的NB-IoT模组在同样位置、同样的网络条件下附着的时延和设备上报的成功率有明显差异。升级固件就像抽卡不是每个版本都是稳定版。后来我养成了习惯任何蜂窝物联网项目都要先锁定某一批固件版本做整机老化测试确认没问题再批量铺开。5. 应用场景的通信需求拆解不是所有物联网都要快5.1 高频低时延的典型场景工业控制和车联网物联网里有相当一批场景对实时性要求极高典型的是工业控制、车联网和远程手术设备。工业控制类物联网比如工厂里的机器人协同、AGV调度、PLC远程监控要求通信链路近乎实时。指令从平台下发到设备中间的网络时延如果超过几十毫秒机械臂的动作就会出现肉眼可见的卡顿严重的甚至引发安全事故。这类场景下Wi-Fi的稳定性不够运营商公网的时延波动又无法预测最稳妥的方案其实是本地私有网络边缘计算把控制逻辑放在工厂内部的边缘节点上而不是把每条指令都绕到云端再绕回来。很多人觉得5G专网是工业物联网的唯一解其实大多数工厂用有线工业以太网加上本地Wi-Fi 6覆盖就足够5G专网的性价比未必扛得住。车联网有点特殊。车联网通信不只是V2X车与一切通信还包括车内的设备互联和远程诊断。真正对时延敏感的是紧急刹车预警、路口碰撞避免这一类消息它们要求在极短时间内到达通常需要专用短距通信或者5G的低时延切片。但这一类系统的部署不是单车厂能决定的它需要路侧设施、交通管理系统和网络协同推进属于典型的技术跑得比生态快的领域。5.2 低频小包水表烟感的通信设计不能只看速率与工业控制完全相反的另一端是大量低频小数据包场景智能水表、电表、燃气表、烟感、地磁车位检测器。这些设备的共同点是一年上报不了几次数据每次可能只有几个字节但对功耗要求极为苛刻而且很多安装在信号很差的地方。这些场景下速率毫无意义真正起决定作用的是三个数据日平均流量、占空比、功耗预算。一个智能水表如果每天上报一次读数加上每天的定期心跳数据量极小NB-IoT完全够用但如果这里还要求平台每5分钟采集一次并实时展示那NB-IoT的容量和功耗模型就得重新算。这类项目最容易犯的通信设计错误有两个。一是把数据包的发送频率定得太高生怕数据不够实时结果电池一年就没电了。二是把所有设备都默认设定在同样的上报周期上没有考虑错峰上报。几万台水表如果同时整点上报虽然NB-IoT小区容量大但汇聚网关和平台侧的瞬时分流压力还是会突然飙高卡顿、丢失、重传全来了。我的建议是对于低频采集场景通信设计的第一目标是保证每个设备都能活满设计寿命而不是追求数据的秒级新鲜度。上报周期宁可长一点也要留有足够的功耗余量给后期的远程升级和诊断留出空间。5.3 视频大带宽AI视觉物联网的接入风暴再往高速率走就轮到视频类物联网了。过去几年AI摄像头看农田、看工地、看森林防火这类项目多了起来。视频物联网的通信需求和之前的传感器物联网完全不同——它的数据量太大了一条1080P摄像头实时码流动辄几Mbps几十路摄像头下来回传链路就成了瓶颈。视频物联网的接入核心不是模组选型而是边缘计算选择性回传。聪明的方案是在摄像头端就做AI识别只回传有事件的关键帧或短视频片段而不是把连续视频流全量上传。比如看一个工地是否有人没戴安全帽摄像机本地做识别只有检测到违规时才截取几秒视频回传平台这样传输带宽和存储成本都能降一个数量级。如果非要传输连续视频流那就要认真核算上行带宽并考虑在本地或边缘节点做视频存储。用5G切片来承载视频物联网技术上当然可行但商业账要算清楚一次性的覆盖改造费用、持续的流量费用对比项目本身的收益是否划算。很多项目最后发现把一部分视频在边缘处理后只回传metadata成本立刻就从不可行变成真香。5.4 一张表看懂场景与接入的对应关系把上面几类场景放到一张表里接入选型的思路会清晰很多场景类型典型业务数据特征优先接入方案核心约束高频低时延类工业控制、车路协同毫秒级响应、小数据包有线工业网 / 5G专网 / 短距直通时延、可靠性中速率移动类共享单车、物流追踪、车载终端频次中等、数据量中等4G Cat.1 / Cat.4移动性、资费低频小包类水表、烟感、地磁、农业墒情每次几字节~几十字节NB-IoT / LoRa功耗、深度覆盖海量低速类路灯、井盖、环境监测周期上报、容忍延迟NB-IoT / LoRa / 无源标签容量、成本连续大带宽类视频监控、AR巡检持续码流或事件片段有线宽带 / 5G / Wi-Fi 6 边缘上行带宽、存储成本偏远盲区类海上浮标、山地监测极低频次、极小数据卫星物联网 / LoRa中继覆盖可达性这张表不是标准答案但至少能帮你把业务需求翻译成通信语言再去做选型就会少踩很多坑。6. 我见过的物联网项目失败原因八成输在通信上6.1 信号穿透算少了地库、井盖、配电柜的三重考验我见过的物联网项目中死在信号穿透上的比重最大。很多场景都发生在你以为有信号其实没有的地方地下车库、下水道井盖、金属配电柜、电梯井道、冷冻仓库。地库的问题在于建筑结构复杂车道坡道会形成射频阴影区井盖的问题在于井体深度和钢筋混凝土盖板配电柜的问题是金属外壳完全屏蔽信号除非做好外部天线引出冷库的问题更绝大量金属货架和密集堆放的货物直接改变了室内电磁环境。处理这一类问题的标准动作是先勘察、再选型、最后施工。勘察时要用实际模组做场强测试记录关键点位的RSRP和SINR数值而不是凭经验拍脑袋。如果现场确实没有蜂窝信号就要果断考虑LoRa网关、室内分布系统或者外置高增益天线。别为了省几千块的钱换来永久的网络焦虑。6.2 并发灾难设备一上线基站先崩溃物联网项目做完小批量测试后最怕的就是大批量上线时出现并发风暴。说个真实经历某项目前期只部署了200台设备测试一切正常然后一次性上线了1万台。结果平台在上午整点收到上万条同时上报的数据消息队列直接堵死Broker CPU打满后面的数据越积越多重启一次崩一次。这类问题的根源是上线即风暴——设备在出厂配置后往往会在同一时间首次联网同时接入网络、同时附着造成基站侧的信号风暴同时大量设备又抢着往平台发注册消息造成平台侧的流量雪崩。解决并发问题要双管齐下。网络侧要合理设计TAC和附着参数让设备在时间上打散接入平台侧要做削峰填谷引入消息队列、限流措施、批量注册的分批放行机制。有一家做智慧停车地磁的项目就很聪明设备每天凌晨3点到5点随机错峰上报心跳把峰值流量拉平一夜之间几万个地磁的并发压力被削成了一个平稳的曲线。6.3 重连机制的蝴蝶效应物联网设备的网络不可能永远稳定。基站升级、网络割接、信号波动、模组异常都会导致设备掉线。掉线本身不可怕可怕的是大量设备掉线后同时重连在网络恢复的瞬间又把网络打瘫。我管这个叫重连风暴。有一次某城市大面积断网恢复后几十万台NB-IoT电表同时发起附着请求结果网络侧的MME过载导致恢复时间反而比故障时间还长。事后复盘发现厂商没有做退避算法——设备应该在连接失败后按随机退避时间重试而不是所有设备都死脑筋地隔几秒重试一次。现在我做物联网方案时必查一项设备端有没有实现指数退避和随机抖动机制。如果没有就算项目还没上线我也敢提前给它判个缓刑。6.4 网络覆盖与实际业务区的错位最后一种失败模式最隐蔽覆盖地图上满格业务现场没网。运营商的覆盖地图是按室外宏站的覆盖半径画出来的但物联网设备的实际部署位置是在室内、地下、设备内部、铁皮箱子里。两者之间的差值就是所谓覆盖假象。有次接了一个农产品冷链车队的项目运输路线横跨几个省运营商覆盖地图显示沿途都有信号但车队一进农产品批发市场信号就掉到无法上传数据。原因是市场里的冷库群和钢结构大棚密集把室外信号挡得干干净净。后来我们给每台冷藏车装了外置天线并增加了车载本地缓存功能——没网时先存着有网了再补传。于是问题被巧妙化解。这类问题的核心教训是做物联网方案时任何网络覆盖的结论都必须来自实地测试而不是来自PPT上的覆盖图。信号这件事只有到了现场才算数。7. 从连接到数据物联网下半场的通信演进方向7.1 5G与RedCap给中速率物联网的下一剂药物联网的中速率场景摄像头、车载终端、工业手持终端一直是接入方案的夹缝地带用4G感觉有点浪费用NB-IoT又跑不动。5G的RedCap就是冲着这个空档来的。RedCap把5G模组的复杂度和成本大幅压低去掉了毫米波、超高带宽等高端特性保留5G核心能力带宽刚好够中速率物联网使用功耗和成本却明显低于完整版5G模组。这意味着未来会有大量针对中速率场景的5G物联网设备出现尤其适合需要高可靠、低时延特性的工业物联网和车联网场景。不过RedCap还不是当下的主流选择。模组价格、网络部署成熟度都需要时间沉淀目前更稳的方案依然是4G Cat.1/Cat.4。我的建议是新项目现在可以多关注RedCap但主力选型还是按当前的成熟度和成本来定别为了追新让自己变成小白鼠。7.2 无源物联网没有电池也要通信物联网设备大规模铺开之后换电池成了最大的运维负担。一颗电池几块钱不算贵但几十万台分布在各处的设备换一次电池的人工成本和调度成本就非常可观了。所以行业里一直在探索无源物联网这条路不用电池而是通过射频能量采集、环境能量收集太阳能、温差、振动为设备供电再配合低功耗通信协议实现工作。这种设备在物流追踪、冷链监测、资产管理领域很有想象空间。不过目前无源物联网的通信距离、数据速率和可靠性还没达到大规模商用的程度短期看更像是特定场景的补充方案而不是全面替代者。7.3 通信人的角色转变从卖卡的人到数据管道架构师最后我想聊聊通信人自己。我在这个行业里看得很清楚以前我们出门见客户谈的是流量套餐、模组价格、信号亮点现在的客户问的是设备的数据怎么到我手里掉线了怎么办数据上传失败能不能自动补。通信人的角色正在转变从卖卡卖设备的人变成数据管道的架构师。这不意味着要抛弃通信基础技能恰恰相反只有真正理解链路预算、协议栈、功耗模型、网络容灾这套老本行的人才有能力在物联网项目里把连接这个词拆成可执行的方案。物联网发展的下半场连接不再是稀缺资源但高质量、高可靠、低成本的连接规划和设计能力会越来越稀缺。我自己的体会是做物联网项目最大的乐趣不是看到平台大屏上的各种酷炫图表而是跑到一个信号死角通过天线调整、协议优化、缓存补传这些手段让一个原本连不上网的设备稳稳地开始上报数据。那一刻你才真正理解物联网的本质——它不是一堆传感器和云平台的堆积木而是一张张精心设计、不停优化、最终把数据精准送达的网络编织起来的。
