NB-lot与LoRa并非你死我活关系

工信部发布的新规明确了433MHz不属于中国ISM频段,引起业界对LoRa技术未来走向的讨论。尽管有观点认为LoRa被判死刑,但实际上LoRa并未受影响,仍可使用470-510MHz频段。LoRa与NB-lot并非竞争对手,而是各有市场,LoRa受互联网公司青睐,NB-lot依赖运营商支持。物联网市场发展需要时间,LoRa与NB-lot将共存。

2019年11月28日,工信部发布第52号公告。公告的主要内容,涉及微功率设备的范畴定义、无线频率的使用限制等要求,还有一些管理规定和举措,一共10条内容。而其中第7条,非常关键。原文内容有点长,简单来说,就是国家明确规定,433MHz不属于中国的ISM频段。这条消息被网络热议,有观点认为该文件彻底封杀了LoRa,还有观点认为是政府力图扶持NB-lot。小编认为,NB-lot与LoRa并非你死我活关系。两者会形成楚河汉界,互不侵犯。
  在这里插入图片描述
  LoRa并没被判死刑
  ISM频段,就是(工业、科学及医疗)频段。全球各国为了让一些工业、科学及医疗领域的公共设备不用都专门申请频段,就设置了一些频段,作为无需授权即可使用的频段,就是ISM频段,也就是我们常说的免费频段。像Wi-Fi、蓝牙,都是用的ISM频段。
  本次工信部文件,则意味着433MHz频段被国家收回。而LoRa作为一项物联网通信技术,会用到433MHz频段。LoRa没有自己的专属频段,所以一直使用免费频段(ISM频段)。目前,国内LoRa用的是470-510MHz。因此,LoRa被判死刑是误传。
  LoRa与NB-lot并非你死我活关系
  LoRa是Long Range的缩写,属于物联网技术的一种,由一家法国公司开发,后来被美国公司Semtech收购。LoRa与NB-lot存在一定程度上的竞争。不过,两者并非你死我活关系,而是存在一定程度上的互补。LoRa与NB-lot的关系有点像4G和WIFI的关系,NB-lot需要经过运营商部署的网络,而LoRa像WIFI一样,企业自己就可以建。
  由于NB-lot当下收费比较高,加上一些其他因素,以互联网公司为代表的大企业对于NB-lot并不热衷,NB-lot的闲置率居高不下。而LoRa则比较受以阿里、腾讯为代表的大公司的青睐,因为自建网络比租用NB-lot运营成本更低,且数据不需要经过运营商的网络,这对于信息掌控非常看重的互联网公司而言,是非常有吸引力的。
  因此,LoRa与NB-lot未来的格局会类似于4G和WIFI,各自都有一块自己的市场,NB-lot可以依托运营商的支持生存,LoRa会在互联网大企业的支持下建立自己的根据地,两者并非你死我活的关系。
  物联网市场是绵绵秋雨 而非疾风暴雨
  物联网应用虽然被炒的很火,但从实践上看,只在经济较发达的省份,比如浙、粤两省,NB-IoT有规模应用,但在内陆地区,NB-IoT网络激活率降低,某省某运营商的激活率只有5%,也就是说95%的节点还处于闲置状态。
  造成这种现象的主要上费用问题,除非资费大幅降低,否则除了不差钱的土豪单位,走量的民营行业恐怕会缺乏应有的动力。毕竟,一个项目部署成千上万个的设备,就是闲置不运维每年都要十几万、几十万,费用太高,缺乏性价比。一些公司恐怕会优先选择免费的或者基本没什么成本的部署模式。
  即便上行业应用,NB-IoT也遭遇滑铁卢,比如电力行业。电力公司和某省某运营商合作建设了NB-IOT抄表网,但经过运营后发现,NB-IoT缺乏定制性,维护费用也比较贵,之后电力公司干脆自己建电力通信专网了。
  因此,物联网市场虽然前景广阔,但市场的成长需要时间,这个市场是绵绵秋雨,而非疾风暴雨。在这个过程中,LoRa与NB-lot都有各自的机会。

<think>嗯,用户的问题聚焦在NB-IoTLoRa这两种物联网通信协议上,还特别提到它们水文行业标准SL651、SL/T427规约的技术关联。看来用户可能从事水利信息化或物联网设备开发工作,需要具体的协议对接方案。 从用户引用的资料来看,有几个关键点需要覆盖:首先是NB-IoTLoRa的核心特性对比,尤其是终端成本、功耗这些工程实施敏感的参数;其次是这些无线协议如何适配水文行业规约的数据传输要求,比如SL651的报文结构;最后可能需要给出实际部署建议。 注意到用户提到SL/T427这个水库通信规约,这其实是SL651的补充规范,专门针对小型水库监测场景。结合引用[4]里湖南省的技术指南,显然用户关心的是如何用无线技术替代传统有线传输,同时满足水文数据上报的强制性要求。 技术细节上需要解释清楚几个关键环节: 1. 物理层差异:NB-IoT工作在授权频段需要SIM卡,LoRa用免授权频段但受发射功率限制 2. 数据封装:水文规约的十六进制报文如何通过MQTT/CoAP这些应用层协议传输 3. 心跳机制:SL651要求5分钟上报间隔NB-IoT的PSM模式如何协调 4. 安全校验:规约里的CRC校验无线传输的AES加密如何分层实现 用户没有明确说应用场景,但引用[2][4]都提到水库监测,所以案例部分可以侧重雨量计、水位计这些典型水文传感器。有趣的是引用[3]提到LoRa模块成本优势,这在实际项目选型中确实是关键因素,需要量化对比。 最后生成的延伸问题要覆盖协议选型决策因素,比如在偏远水库没有蜂窝网络覆盖时,LoRa+北斗的混合方案如何实现,这类问题能帮助用户解决实际痛点。</think>以下是对NB-IoT/LoRa无线通信协议及其SL651、SL/T427规约关联的技术详解: --- ### 一、NB-IoTLoRa核心特性对比 | **特性** | **NB-IoT** | **LoRa** | |------------------|-----------------------------------------|-----------------------------------------| | **频谱类型** | 授权频段(运营商网络) | 免授权频段(ISM频段) | | **传输距离** | 10-15km(郊区)[^1] | 2-5km(城市),15km(郊区)[^3] | | **功耗** | PSM/eDRX模式(待机电流<5μA) | 接收电流10mA,休眠电流<1μA[^1] | | **数据速率** | 20-250kbps | 0.3-50kbps | | **网络架构** | 蜂窝网络(需SIM卡) | 自组网(LoRaWAN网关) | | **成本优势** | 模块成本较高,网络覆盖依赖运营商 | 终端模块成本低($2-5),开发简单[^1] | --- ### 二、水文规约的适配技术 #### 1. **SL651-2014规约核心要求** ```mermaid graph TD A[数据上报] --> B[帧结构] B --> C[固定帧长格式] B --> D[可变帧长格式] C --> E[起始符+站址+密码+功能码+数据+校验] D --> F[起始符+长度+站址...] ``` - **数据校验**:采用CRC16循环冗余校验(多项式:$x^{16}+x^{15}+x^2+1$) - **实时性**:自报式需≤5分钟响应,查询式需≤30秒响应[^2][^4] #### 2. **协议栈适配方案** | **层级** | **NB-IoT实现** | **LoRa实现** | |----------------|----------------------------|---------------------------| | **应用层** | 直接封装SL651报文 | LoRaWAN payload承载规约数据 | | **传输层** | UDP/CoAP(低开销) | 自定义透传模式 | | **网络层** | IPv6(6LoWPAN压缩) | 无IP(网关做协议转换) | | **物理层** | 3GPP Release 13窄带调制 | CSS线性调频扩频[^3] | **典型数据流**(以水位上报为例): ``` NB-IoT终端 → 基站 → 核心网 → 规约解析服务器 LoRa终端 → 网关 → 网络服务器 → (MQTT) → 规约解析服务器 ``` --- ### 三、关键技术细节 #### 1. **低功耗设计** - **NB-IoT**:通过PSM(Power Saving Mode)实现: $$ T_{active} = T_{TX} + T_{RX} + T_{Processing} $$ 休眠时电流低至$3\mu A$,电池寿命可达10年[^1] - **LoRa**:采用ADR(自适应速率)算法: $$ SF = 12 \times \log_2\left(\frac{4R_b}{B}\right) $$ 动态调整扩频因子(SF7-SF12),降低发射功耗 #### 2. **SL/T427规约特殊要求** - **多信道备份**:需支持4G/北斗/LoRa混合传输[^4] - **唤醒机制**:当数据超阈值(如水位突变≥10cm)时立即唤醒 - **协议兼容**:需同时支持《SZY206-2016》《HJ/T212-2017》[^2] --- ### 四、典型应用场景(以水库监测为例) ```python # 伪代码:SL651报文通过LoRa发送 def build_sl651_frame(sensor_data): header = b'\xF0' # 起始符 station_id = b'\x01\x02\x03' # 测站地址 password = b'\xAA\xBB' # 密码 data = struct.pack('>f', sensor_data) # 4字节浮点数 crc = calc_crc16(header + station_id + password + data) return header + station_id + password + data + crc lora.send(build_sl651_frame(water_level)) ``` --- ### 五、部署建议 1. **NB-IoT适用场景**: - 运营商网络覆盖区域 - 需高可靠传输的关键站点(如大坝安全监测) - 需远程固件升级的设备 2. **LoRa适用场景**: - 无蜂窝信号的偏远水库 - 低成本传感器网络(雨量站、水质浮标) - 需自建私有网络的保密项目 > **混合组网方案**:核心站点用NB-IoT+4G双通道,边缘站点用LoRa中继,通过MQTT协议统一接入省级平台[^4] --- ### 相关问题 1. **SL651规约中CRC16校验如何实现?能否给出代码示例?** 2. **NB-IoT的PSM模式如何SL651的5分钟上报周期协同?** 3. **LoRaWAN的ADR机制如何影响水文数据传输可靠性?** 4. **在混合组网中如何实现SL/T427要求的多协议自动切换?** 5. **如何解决LoRa在山区水库的多径衰落问题?** > 参考资料: > [^1]: LoRa模块成本兼容性优势 > [^2]: 水文监测多协议支持要求 > [^3]: LoRa物理层调制原理 > [^4]: 混合通信规约适配技术
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值