1. 这次新闻的真正看点Senet手里的专利解决了什么这条消息在物联网圈子里刷屏的时候不少人的第一反应是Senet是谁或者物联网组网专利有什么好稀罕的。说句实话物联网领域的专利新闻几乎每天都有但Senet这次拿下的专利值得单独拿出来聊因为它指向的是LoRaWAN网络从能用走向好用过程中、最卡脖子的那一层技术。先介绍一下这家公司的基本盘。Senet是北美做LoRaWAN公共网络运营的老牌玩家业务模式跟移动通信运营商非常像它不生产终端传感器也不做应用平台而是负责把一张覆盖一定区域的低功耗广域网络LPWAN建起来、运营好然后以网络服务的形式开放给企业客户。打个比方如果LoRaWAN终端设备是手机那Senet做的事情就相当于基站加核心网管的是数据从设备侧到云端这条完整链路的网络基础设施。这次被授予的专利公开信息里聚焦在网络管理、射频资源协调以及多租户架构下的动态调度这些方向。说得直白一些就是解决了一个非常头疼的现实问题当一张网络上有成千上万个来自不同客户的设备同时上报数据网关怎么分配信道、怎么避免互相干扰、怎么保证每个客户的数据既不串线也不丢包。这个问题的复杂度远不是搭几个网关、写一段频率规划脚本就能搞定的。我自己这几年接触了不少LoRaWAN项目从几台网关的小规模试点到几百台网关的区域性覆盖都经历过可以负责任地说单网关演示和公共网络运营是两种完全不同的物种。绝大多数团队在demo阶段跑得很顺一到批量部署阶段就各种翻车问题几乎都出在我后面要展开讲的网络协调层面。所以这篇博文不打算只复述一遍新闻而是想借着Senet这批专利的技术方向把LoRaWAN公共网络背后那套隐形但极其关键的机制拆开讲清楚它到底解决了什么、为什么难解决、以及对我们这些做实际项目的人有什么参考价值。2. 从单网关到公共网络小规模demo和运营商级网络之间的鸿沟2.1 单网关时代看起来一切都简单先回忆一下最常见的起步路径。很多团队第一次接触LoRaWAN是买了两个开发板加一台室内网关在办公室或者厂区里做温度、湿度、电表数据的采集demo。这个阶段的技术栈非常简单传感器通过LoRa无线协议把数据发给网关网关通过以太网或者4G把数据推送到云端应用服务器解析后再展示到看板上。单网关模式下组网几乎不涉及网络优化这个概念。网关只有一个上行链路用哪个频率、扩频因子设多少基本靠经验或者官方默认参数就行。即使设备分布不太均匀只要距离不是特别远、障碍物不是特别多空口丢包率一般都在可接受范围内。出了问题也就那么几种可能距离超了、天线没接好、服务器地址配错了。排错路径非常短。但这一阶段的顺利很容易给人造成错觉让人以为LoRaWAN组网就是这么个事。等到设备规模扩大、网关数量增加、多客户共享网络的时候原来被隐藏起来的问题会集中爆发而且爆发的形式非常致命——不是单个设备连不上而是整个网络的吞吐量骤降、丢包率飙升表现出一种哪里都没坏但就是不好用的诡异状态。2.2 网关数量上去了问题跟着就来了网关数量增加带来的第一层变化是覆盖重叠。在真实部署场景里为了保证信号盲区尽量少相邻网关的覆盖范围必然会有交叠。这本来是为了增强冗余但在LoRaWAN的网络机制下覆盖交叠意味着同一台设备发出来的上行数据包可能被多个网关同时收到。LoRaWAN协议本身是允许这种多网关接收的网络服务器会做去重处理只保留先到达的那一份。这个机制在数据可靠性上有很大好处但如果网络服务器不做额外的射频资源协调多网关接收就会带来一个副作用信道占用翻倍。同一份数据占了两个甚至三个网关的空口资源网络总容量被白白消耗掉了。设备数量继续往上加进入第二个阶段的问题信道容量见顶。LoRaWAN在一个区域能用的频率资源、信道数量是固定的比如国内常用的470MHz到510MHz频段能规划的上下行信道数目终究有限。假设一台网关可以承载几千个节点的低频率上报但当每台设备的发送频率提高或者节点密度继续增大整个区域内的空口冲突概率会指数级上升。那时候你会看到数据采集率从99%掉到95%、90%、80%而且无论怎么加大发射功率都救不回来。第三层变化来自多租户隔离。公共网络运营模式下一张物理网络要同时服务多个客户的设备例如同一个区域内有一批是智慧农业的水位传感器另一批是市政井盖的状态监测器。不同的客户可能有不同的服务质量要求、不同的数据优先级、不同的上报频次。如果网络服务器不做租户级别的资源隔离一个客户的大流量上报比如一批每秒钟上报一次的设备可能直接把其他客户的低频高价值设备饿死。这就是为什么Senet这类运营商必须做射频协调的原因。LoRaWAN空口层看起来是随机接入的但随机接入不等于不能管理。通过集中式的网络服务器实时掌握每台网关的负载、每个终端的信号质量、每个租户的业务优先级然后动态地给设备分配信道、调整扩频因子、控制发射时机才能在有限频谱资源下压榨出最大吞吐量。2.3 一个容易被忽视的问题上下行链路的容量瓶颈很多资料在讲LoRaWAN的时候会强调它的低功耗、长距离、高穿透能力但很少提它的一个先天短板下行链路容量极其有限。LoRaWAN终端的接收窗口是短时打开的只有在上行发送之后才会短暂监听下行应答这意味着设备大部分时间都在睡觉网络侧想主动找一台设备聊天几乎做不到。这种设计对电池供电的传感器设备非常友好但对网络运营来说是个不小的考验。尤其是固件升级、远程配置、指令下发这些需要下行通信的场景如果网关和设备之间没有很好的调度配合很容易出现指令发了几遍设备都没收到的情况。公共网络运营商必须在网络服务器层面做精细的调度策略什么时候允许下行占用、什么时候优先保证上行采集、下行队列怎么排队、超时重传怎么控制。这些策略的复杂度和单网关场景完全不在一个量级而Senet的专利体系里有很大一部分就是在保护这些调度算法和网络管理方法的实现。3. 射频协同与干扰控制公共LoRaWAN网络最硬核的技术壁垒3.1 LoRa的抗干扰并不等于可共存很多人对LoRa技术的第一印象是抗干扰能力强。这确实是LoRa物理层的优势之一它基于Chirp扩频调制技术通过把数据信号扩展到一个较宽的频带上让接收端能够在信噪比很低的情况下解调出有用信号。但是抗干扰能力强有一个前提条件那就是干扰信号的扩频因子或者说调制参数跟有用信号不同。LoRa设备使用不同的扩频因子SF7到SF12时信号之间具备一定的正交性理论上可以在同一信道上并行传输而互不干扰。然而这个正交性不是完美无缺的当两个信号强度差距过大时强的信号还是会压死弱的信号这就是所谓的远近效应。实际网络里更常见的干扰场景是同频同扩频因子冲突。当大量设备使用相同扩频因子、在同一信道上并发发送时数据包碰撞的概率会迅速上升。整个网络的吞吐量取决于冲突概率而不取决于设备本身的发送能力。LoRaWAN的MAC层采用类似ALOHA的随机接入机制设备想发就发没有监听机制不像Wi-Fi有CSMA/CA信道利用率天然受限。这一层机制决定了公共网络运营者必须做集中式的资源协调。设备不能自己想用哪个信道就用哪个信道、想用什么扩频因子就什么扩频因子必须由网络服务器根据设备所处的信号环境、网关的负载情况、业务优先级动态下发参数配置。Senet的专利很大概率就覆盖了这类集中式射频资源分配算法包括信道的动态规划、扩频因子的自适应选择、发射功率的闭环控制等。3.2 从设备随机撞到网络主动管调度算法的价值用一个生活化的类比来解释这个过程。老式食堂开饭时间几百个人同时涌进一个打饭窗口谁先挤到谁先打秩序混乱效率低下这就是无管理的ALOHA机制。如果改成每个窗口安排一个引导员提前统计各窗口排队人数动态引导人员分流、错峰打饭整体效率会提升不少。LoRaWAN公共网络的射频调度做的就是引导员的工作。具体到技术实现这套调度系统需要解决几个问题第一如何感知网络负载。网关需要实时上报每个信道当前的空闲率和占用率网络服务器汇总之后形成全网负载热力图。负载高的区域和信道在分配新任务时要主动避让。第二如何感知设备信号质量。终端每次上行时网关会记录接收信号强度RSSI和信噪比SNR这些数据上传到网络服务器后可以被用来估计设备到周边网关的链路质量从而决定用什么扩频因子最合适。信号好的设备用SF7提高速率、缩短空口占用时间信号弱的设备用SF12保证传输成功率但代价是空口占用时间成倍增长必须控制这类设备的数据量。第三如何做信道公平性保障。多租户场景下不能让某个大流量客户把信道全部占满。网络服务器需要按租户的SLA策略对每个租户的信道占用率做配额管理超出部分可以排队或者限制速率。这套机制运行得好不好直接决定了一张LoRaWAN公共网络能支撑多少设备、多少个客户。Senet能拿到专利说明它在这些算法上确实有自研的独到之处而不是简单套用LoRaWAN协议栈的默认实现。3.3 实际项目中会遇到的核心瓶颈和数据我接触过的一个区域级智慧城市项目真实数据是这样的规划覆盖面积大约20平方公里部署了约80台室外网关计划接入4.5万台水表和1.2万台燃气表。测试阶段设备数量不到5000台一切正常。但当设备数量突破2万台后问题开始出现数据上报成功率从99.6%一路掉到93%而且掉得毫无规律有些片区正常有些片区数据大量丢失。排查下来发现问题出在信道分配策略上。所有设备出厂时用的都是默认的八个上行信道2万台设备每天集中在几个固定时段低速率上报很多水表默认配置是SF10/SF11特定时段相同信道上的碰撞率达到了惊人的35%。网关本身的射频能力没有问题瓶颈在空口冲突。后来我们参照公共网络运营的思路改造了节点配置策略把设备分摊到全部可用信道上根据信号质量给不同片区配不同的扩频因子再按上报时段做了一定的错峰。改完之后上报成功率恢复到了98.8%以上。这个案例让我深切体会到网络侧的主动调度不是优化项而是大规模LoRaWAN部署的必需品。4. 多租户架构下的网络隔离公共物联网服务的房东逻辑4.1 多租户隔离决定了一台网关能服务多少客户做公共LoRaWAN网络运营跟做写字楼出租很像。物理层面的网络基础设施网关、频率、服务器就是写字楼本身各个企业客户就是租户。租户之间可以有各自的装修风格应用平台、数据格式但大楼的承重结构、水电管路网络核心架构、频谱资源必须是统一规划、集中管理的。多租户隔离要做的事情包括几个层面数据层面的隔离、控制层面的隔离、资源层面的配额管理。数据隔离是最基础的要求。客户A的设备上报数据不能出现在客户B的应用服务器上。这套机制在LoRaWAN协议里已有体现每个设备的Join Server和应用服务器之间通过AppKey和AppSKey进行端到端加密网络服务器只能看到路由信息无法解密应用数据。然而加密只是保证了看不到还保证不了不互相影响。控制隔离和资源配额才是网络层真正难的地方。客户A的设备如果大规模上线或者集中上报会占用水表和燃气表附近的空口资源网络服务器需要及时发现这种流量风暴限制客户A设备的发送速率或者把部分设备引导到其他信道减少对客户B的影响。更进一步如果客户A的SLA服务水平协议里写的是高优先级比如消防监控设备的告警网络服务器还要保证这类设备的数据在拥塞时优先传输甚至可以抢占低频设备的信道资源。4.2 运营商级网络服务器与开源服务器的差异很多团队在做LoRaWAN项目时用的还是开源网络服务器方案比如ChirpStack或者The Things Network的部署版本。这些开源方案作为单租户或者小规模多租户场景下的网络服务器完全够用。但当租户数量、设备规模上升之后开源方案的短板会逐渐暴露。最明显的问题在资源调度。开源方案的大部分调度逻辑是先到先得没有做复杂的优先级抢占和全局负载均衡。在设备规模较小、上报频率较低的时候这种策略问题不大但设备规模大了以后就会出现前面章节提到的信道冲突和流量饿死现象。其次是网络参数的动态调整能力。开源方案虽然也支持ADR自适应数据速率但ADR的触发策略和调整幅度通常是保守的而且很少能结合多网关的全局信息做联动调整。运营商级的网络服务器则会把设备所在的地理位置、周边网关负载、历史链路质量、当前信道占用率都作为输入综合计算最优参数组合。这也是为什么Senet这类公司能靠网络运营赚钱的原因——它卖的不是网关硬件而是这套精细化的资源管理和调度能力。物联网项目如果只需要几十台网关自己折腾开源方案完全可行但如果目标是数百台网关、数十万个终端、多个客户共享网络的规模运营商级网络平台的价值就会体现得非常明显。4.3 案例代入一个典型的公共物联网服务平台长什么样设想一个省级的智慧农业平台要服务几百个农场的土壤墒情传感器、气象站、虫情测报设备。每个农场是一个独立租户可能有几百到几千个终端节点。平台方自己建一张全省覆盖的LoRaWAN网络对外开放连接能力。这种场景对网络平台的要求是每个租户登录后只能看到自己的设备、自己的数据每个租户的设备上报频次和报文大小可以独立配置每个租户可以设置告警规则网络平台要能保证告警消息的低时延投递当某个农场临时有大规模数据上报需求时网络平台要有能力为其临时扩容信道配额同时保证其他农场的正常服务。做一个对比表会更直观维度单网关/私有网络多网关公共运营网络网络规模几台到几十台网关几百台到上千台网关租户支持单租户多租户SLA差异化管理信道分配固定配置动态分配全局负载均衡冲突控制依赖设备自律集中调度优先级抢占故障恢复手动排查自动切换冗余路由扩容方式加网关重新规划按区域动态调整参数在公共运营模式下网络管理是一个持续动态的过程不是部署完成就一劳永逸。这可能也是Senet能做深、能形成专利壁垒的根本原因。5. 海量数据采集场景的启示物联网项目真正该关注的网络层细节5.1 设备规模上量之后最先崩的往往不是平台而是网络物联网项目里最典型的一个误区是把精力全放在传感器选型、数据平台建设、业务应用开发上网络层想当然地认为用LoRaWAN就是连上就行。等设备数量真正上到规模第一个出问题的就是网络层。我见过一个真实案例某个做配电房监测的项目一期部署了3000个监测终端网络架构是每个配电房装一台网关设备直连网关。因为配电房分布在一个城市的不同区域网关数量达到了一百多台。前期测试没问题但在一次集中运维升级中运维团队需要同时升级一批终端的配置参数导致大量设备在同一时段内集中上报结果多个区域的网关同时出现信道拥堵部分终端的数据积压严重整个系统的数据新鲜度被拖垮。这个案例暴露出的问题是项目团队在设计网络架构时完全没考虑突发流量下的弹性。LoRaWAN的频谱资源是稀缺资源设备的发送频率、发送时段、信道分配如果不由网络服务器统一调度一旦出现需求高峰整个网络就会进入无序竞争状态。5.2 如何提高LoRaWAN网络在数据采集场景中的承载能力结合前面讲的原理给实际项目几个可落地的建议。建议一不要使用设备出厂默认频率参数。几乎所有LoRaWAN设备出厂时都使用相同的默认信道表和发射参数。如果几百上千台设备全部直连默认信道相当于把所有人都引导到同一个入口排队。正确做法是根据网络服务器规划的全局信道表批量修改设备配置让设备均匀分布在各个信道上。建议二合理利用ADR功能。ADR自适应数据速率是LoRaWAN协议的标配功能目标是在保证链路质量的前提下尽可能让设备使用更高数据速率、更短的空口时间。但ADR的生效需要网络服务器的配合如果网络服务器没有开启ADR计算或者配置不当设备就会一直停留在低速率的保守状态。一个经验数值是同一区域设备从SF10批量优化到SF7之后空口占用时间可以缩短到原来的五分之一左右网络承载能力因此大幅提升。建议三为不同的业务类型设计不同的上报策略。高频率数据采集设备例如每分钟上报一次和低频告警设备例如一天上报一次应该走不同的信道策略和优先级策略。低频高价值设备尽量使用较慢的扩频因子以保证穿透性和覆盖范围高频设备集中使用较高扩频因子以提高信道利用率。这个策略看起来简单在设备规模大了以后收益非常明显。建议四网关部署要留出冗余容量。很多项目按设备数量除以单网关接入能力来规划网关数量但这个逻辑忽视了无线网络的时变性和非均匀性。合理的规划方式应该是先做覆盖仿真和现场测试然后按仿真容量的70%到80%来建设实际网络预留出突发流量和未来扩容的空间。5.3 应用层需要配合网络层做的几件事网络性能不是网络服务器单方面能决定的应用层的数据策略对网络健康度也有很大影响。首先应用服务器要设计好数据重传机制。LoRaWAN本身有确认机制Confirmed上行但确认会占用下行信道资源如果所有数据都使用Confirmed模式下行信道会迅速饱和。合理做法是重要数据用Confirmed普通采集数据用Unconfirmed配合应用层的业务补偿逻辑比如隔天补采缺失数据来保证整体数据完整性。其次应用层要具备数据批量下发的能力但要控制下发的并发度。固件升级、参数批量修改这类操作要设计好分批次执行比如每批500台设备、批次间隔15分钟避免瞬间触发全网下行风暴。另外数据采集时间的错峰也很重要。很多项目的设备默认在整点或者半点上报这会导致整点和半点时刻网络的瞬时负载远高于平均值。在设计上报策略时可以根据设备编号或区域人为地引入0到10分钟的随机偏移让流量在时间轴上更均匀地分布。6. 从Senet专利看LoRaWAN生态的走向运营商级网络能力将成为基础设施6.1 物联网网络从自建自用走向租用共享Senet这批专利背后体现的产业趋势是物联网网络正在从早期的项目制自建走向公共基础设施运营。打个比方早期的电力系统是每个工厂自己建发电机后来才发展成集中发电、电网输电、按需用电的模式。物联网网络也在经历类似的演变。对于大多数物联网应用企业来说自建一套覆盖范围足够大的LoRaWAN网络并维护其持续运营是一件投入产出比很低的事情。频谱规划、网关运维、射频优化、故障排查每一项都需要专业团队和持续投入。相比之下租用公共物联网网络服务按设备量或数据流量付费省掉了网络建设成本还能借助运营商的网络优化能力获得更稳定的连接质量显然是更经济的选择。当然自建网络的场景会长期存在。对数据安全要求极高、完全内网化运行、网络覆盖范围特殊的企业仍会选择私有化部署方案。公共网络和私有网络会长期共存满足不同客户的实际需求。6.2 网络运营能力的专利化对产业意味着什么专利的意义不只是保护技术研发的成果更重要的是在产业生态中构筑出标准制定者和服务提供者的分工格局。Senet在射频协调、网络调度这些领域获得专利本质上是在宣告公共LoRaWAN网络的运营能力是一项需要专业积累的硬核技术而不是搭好网关就能自动获得的通用能力。这对产业生态其实是一件好事。专利保护会吸引更多资本投入到网络调度算法、自动运维平台、网络性能优化这类深水区技术上而不是全都涌去卷低价的网关硬件。长期来看网络基础设施越稳定上层应用才能跑得越好整个物联网产业才能从能做demo进化到能支撑生产级运营。6.3 做项目选型时需要重新思考的问题看完Senet的新闻再做实际项目的技术选型时有几个问题值得重新思考一是网络方案商的选择标准。以前选型关注单网关的覆盖能力、终端模块的价格、云平台的界面功能但现在应该把网络侧的管理和调度能力也纳入核心评估维度。方案商能不能提供信道规划的指导能不能在设备规模增长后做网络参数的整体调优有没有处理突发流量的应急预案这些问题直接关系到项目上线之后能不能稳定运行。二是终端侧的配置管理。设备入网只是起点后续的参数管理、资源优化、固件升级才是长期运营的核心工作。项目选型时要关注终端是否支持远程参数下发、是否支持通过网络服务器做批量配置。不支持远程配置的终端在规模化运营中会是非常痛苦的运维负担。三是网络数据资产的价值挖掘。公共网络运营模式下网络服务器沉淀了海量的链路质量数据、信号覆盖数据、设备行为数据。这些数据对网络优化、故障预测、业务决策都有很高价值。选择网络方案时要考虑到这些数据能不能完整地导出、可不可用于自己的数据分析体系而不是被封闭在厂商平台里。7. 一点个人体会7. 一点个人体会从最早接触LoRaWAN到现在我有一个很深的感受物联网项目的成败很多时候不取决于选用了多先进的传感器也不取决于云平台功能多花哨而是取决于底层网络有没有被认真设计和持续运营。Senet这次的专利新闻表面上是一家公司的技术护城河加高本质上是在提醒整个行业——网络侧的价值远比我们想象中要大。如果你正在规划一个LoRaWAN项目我建议在动手之前先花一点时间把网络层的容量规划、信道策略、故障应急预案这3件事写在需求文档里而不是等设备铺完之后再回头补课。我在实际项目中踩过不少网络层的坑几乎每一个都是规模上来之后才暴露的隐藏问题越早重视后面越省心。另外对于准备把业务规模做大的团队建议多关注公共LoRaWAN网络服务的发展动态。自建网络和租用网络不是对立关系完全可以混合使用核心区域自建、广域覆盖租用既保证关键业务的自主可控又降低大规模覆盖的成本。未来的物联网接入方式一定会越来越多、越来越灵活保持对网络层新方案的敏感度比守着旧架构埋头苦干有价值得多。