在物端设备或云平台上建立可互联的实体服务, 是构建面向服务的物联网应用系统的基础[1], 而实现物理实体服务的基础是在设备和网关之间以及网关和互联网设备之间建立相同的数据通信协议栈。低功耗广域网(Low Power Wide Area Network, LPWAN)是一种无线通信技术, 它能够满足大规模和广覆盖的应用需求, 如城市感知[2]、民用基础设施监测[3]、精准农业[4]等, 这些应用需要长距离地将数千个设备进行连接。越来越多的应用需要有保障的网络下行, 然而, 现有的LPWAN技术对有保障的网络下行考虑不足[5], 其主要受低功耗和低速率的影响。
在ISM(Industrial Scientific Medical Band)频段中, 现有的无线传感器网络(Wireless Sensor Network, WSN)技术, 如6LowPAN(IPv6 over IEEE 802.15.4 [6])、802.11[7]可以利用多跳技术实现大范围的覆盖, 但带来较高的能耗、成本和复杂度。基于ZigBee通信的微电网监控网络方法采用ZigBee方式实现对微电网进行监测, 然而当设备之间距离超过100 m时, 通信质量较差, 为了达到更远的传输距离, 除增加中继外, 还需使用功率放大器CC2591, 这带来了更多的能耗开销。
有保障的网络下行是WSN领域的一个挑战[5]。因此, 进一步将WSN的下行总结为网络的可靠性、可用性和时间延迟。网络下行的可靠性是指基站下行的数据能够端到端地交付给节点的收包率。网络下行的可用性是指用户在何时间段内能够使用网络的下行功能。网络下行的时间延迟是指用户从基站下发数据开始到节点成功收到数据所经过的时间。
本文提出一种LPWAN中低功耗、有保障下行的双向通信网络架构, 以此构建一个轻量级的星型网络协议栈, 研究关键的介质访问控制(Medium Access Control, MAC)层协议, 即OPEN-MAC协议, 并介绍其网络上下行原理。
1 相关工作双向通信网络架构相关工作主要包括以下3个方面:
1) LPWAN长距离的通信技术
LPWAN实现长距离通常采用Sub-GHz频段, 调制方式运用超窄带或者扩频技术[8]。LPWAN最典型代表是SigFox[9]、NB-IOT[10]、LoRa[11]。LoRa和SigFox典型拓扑结构是星型拓扑, 普通节点到基站的距离通常在1 km~20 km之间。虽然文献[9]给出SigFox、LoRa的覆盖参考范围, 但是在城市环境中部署仍具有较大挑战。LoRa的通信范围能够降低到1 km~2 km[12](都市环境), 此外LoRa的收包率也较低[13]。
基于LPWAN技术面临覆盖范围和网络密度的挑战, 已有的一些研究通过物理层技术来提高LPWAN网络性能。文献[14]使用软件无线电设备USRP, 采用分布式正交频分多路复用(D-OFDM)提高网络容量。文献[15]针对文献[14]节点每次传输数据给基站, 基站不能同时回复ACK的问题, 设计了单天线2个半双工射频的基站, 同时, 给出稳定的物理层调制方式, 提高了可靠性。通信系统Choir[16]采用商用的LoRa作为节点, 软件无线电设备作为基站, 利用频率偏移的方法实现了网络吞吐量是LoRa网络的6.84倍, 通信距离是LoRa网络的2.65倍。
与现有研究使用频分多路复用的方法提高网络上行的容量相比, OPEN-MAC网络主要关注有保障的网络下行。
2) 相关的网络下行技术
LoRaWAN[17]是一种开放的协议, 用来管理LoRa网关和终端设备之间的通信。LoRaWAN有3种设备类型:具有下行链路后接上行链路(Class A)的双向通信终端设备, 具有划定接收时隙的双向通信终端设备(Class B)和始终开启的双向通信终端设备(Class C)。Class A类设备使用纯粹的ALOHA协议, 每次上行会带有2个接收窗口, 默认RX1是在上行1 s后打开接收窗口, RX2是在上行2 s后打开接收窗口。Class A设备可以切换到Class B设备, 但是需要应用程序请求LoRaWAN协议切换到Class B。在Class B中, 为满足下行, 终端设备要周期性开启时槽接收同步帧, 如果检测到前导码(GFSK调制方式为5 Byte, LoRa调制方式为8个符号[18])射频将一直保持开启直到下行链路帧被解析。与LoRaWAN不同的是, OPEN-MAC有一个预接收过程, 设备在第1个时槽做2次CCA(Clear Channel Assessment), 用来检测是否有基站下行的唤醒数据, 如果有, 节点会在第2个时槽直接接收基站发送的数据包, 做CCA的时间要比检测前导码的时间少。
窄带物联网(Narrow Band-Internet of Things, NB-IOT)是一种新的通信技术, NB-IOT设计了扩展的不连续接收(extended Discontinuous Reception, eDRX)模式, 用来满足下行时延有要求的业务。文献[19]对NB-IOT进行了评估, 结果表明, 该网络的时间同步偏差范围为36.22 ms~581.78 ms, 但是较差的同步同样会导致传输窗口增长, 带来功耗开销。
3) 高精度的时间同步
为实现可靠的网络下行, OPEN-MAC网络采用基于收包的同步方式, 具体可以参考TSCH[20](Time Synchronization Channel Hopping)。文献[21]对TSCH的时间同步协议进行介绍, 针对TSCH时间同步协议受到网络攻击给出了安全时间同步策略。更高精度的同步方式可以参考自适应的同步[22]、VHT[23]。然而, 在低成本的晶振上做高精度同步会带来功耗开销, 另外多数的物联网应用场景要求达到毫秒级别的时间同步即可, OPEN-MAC网络默认只采用了基于收包的同步方式。
本文的主要贡献如下:给出同步和异步混合架构, 同步能够有效地减少上行冲突, 避免隐藏终端问题[24]。异步ContikiMAC[25]能够有效地降低接收数据的功耗开销。因此, OPEN-MAC借鉴同步时分多址(Time Division Multiple Access, TDMA)和异步ContikiMAC的基本思想, 实现了无冲突的网络上行和低功耗的网络下行。OPEN-MAC以同步TDMA为基础, 异步操作在TDMA时槽中实现。OPEN-MAC设计了可配置的调度器控制MAC层的行为, 用户可以实现可配置的网络规模和可配置的节点功耗。
本文在商用低成本的CC1310[26]设备上实现了50 kb/s和10 kb/s的通信速率, 并证明了OPEN-MAC网络具有适配不同速率的能力。
2 OPEN-MAC设计 2.1 OPEN-MAC星型网络协议栈由于低功耗广域网的物理层技术传输距离
远, 并且物联网的典型应用需要实现低功耗及应用场景相对简单, 因此, OPEN-MAC需保持轻量级的特点。该协议栈分为3层:物理层, MAC层和应用层。物理层能够支持多种不同低速率, 以满足应用的不同需求。MAC层实现了低功耗、可靠的网络上下行数据通信功能。其关键设计有2个部分:1)数据通信平面; 2)网络控制平面。数据通信平面完成根节点数据收集和控制消息的下发。网络控制平面完成网络的管理功能, 包括组网、同步和调度。
OPEN-MAC数据通信平面示意图如图 1所示。终端设备称为节点, 基站的无线收发设备称为根节点。在MAC层, 所有的节点都维持与根节点一致的调度, 该调度表明, 当前的时槽如果在上行阶段, 节点在已经分配的时槽内向根节点发送数据, 如果在下行阶段, 根节点就可以向节点发送数据。节点和根节点均没有接收队列, 这样可以实现快速的接收。无论是上行还是下行, 每次收发都会有ACK机制, 当数据包丢失, 调度器会在发送阶段调度重传时槽。
|
Download:
|
| 图 1 OPEN-MAC的数据通信平面示意图 | |
OPEN-MAC控制平面示意图如图 2所示。在MAC层, 需要实现自组网功能、周期性同步功能以及可配置的调度功能。在初始化时, 节点没有组网, 它会周期性地发送请求组网消息。当节点收到根节点的确认组网消息时, 节点组网成功。此后节点会周期性地收到根节点的同步消息。节点同步成功, 会重新计算自己的调度, 并在新调度的指导下工作。节点组网时不仅需要实现时间同步, 还要获取根节点的调度, 因此, 确认组网消息包含组网的同步信息和全局的调度信息。为了保证所有节点当前的同步和调度与根节点保持一致, 节点获取的同步消息中也包括同步信息和全局的调度信息。
|
Download:
|
| 图 2 OPEN-MAC网络控制平面示意图 | |
传统的6LowPAN无线网络协议栈由于支持多跳转发的功能, 节点需要实现密集的周期性侦听, 典型的ContikiMAC协议(6LowPAN网络协议栈默认的RDC层协议)以8 Hz进行侦听, 侦听的目的主要是为了转发其他节点的数据包, 但是会造成能耗的浪费。而本文中实现的OPEN-MAC协议, 由于实现精确的时间同步, 并且节点发送的信息无需其他节点转发侦听, 从而实现更低的能耗。
2.2 同步和异步的混合架构同步网络能够避免隐藏终端问题, 异步的ContikiMAC[9]则能够有效地降低接收数据的功耗开销, 因此, 本文采用同步和异步的混合方式。
OPEN-MAC网络上行示意图如图 3所示。每个节点在当前的子网中获得唯一的发送时槽, 以保证无冲突的上行。为了满足可靠性的要求, OPEN-MAC网络支持重传机制, 重传次数可在配置文件中修改。由于不同节点实时时钟的硬件差异, 导致节点本地计时走快或者走慢, 因此节点的时钟需要周期性地校时。最差的情况是不同的节点相邻2个时槽出现重叠, 导致发送数据包冲突。假设全网的所有相邻时槽的2个节点之间最大偏差为Tmax_err, 时槽的长度为Tslot, 上行的数据包最大长度为Tdata, 那么最大的同步偏差需要满足式(1)。
| $ T_{\max _{-} \mathrm{err}}+T_{\mathrm{data}} <T_{\mathrm{slot}} $ | (1) |
|
Download:
|
| 图 3 OPEN-MAC网络上行示意图 | |
OPEN-MAC网络下行分成2个阶段:第1个阶段是唤醒阶段, 第2个阶段是接收阶段。节点1在唤醒阶段检测到唤醒数据包, 在第2个阶段开启接收窗口。图 4所示为节点1接收成功、节点2接收失败的OPEN-MAC网络下行示意图。
|
Download:
|
| 图 4 OPEN-MAC网络下行示意图 | |
为了在第1阶段能够成功地检测到唤醒数据包, 需要满足关系式(2)、式(3)。其中, Tpacket_interval表示唤醒数据包之间的间隔, Tcca_sleep表示2次CCA之间的睡眠时间, Twake_data表示唤醒数据包长度, N表示唤醒数据包个数, Tslot表示一个时槽的长度。为确保至少检测到一次唤醒, 唤醒数据包间隔必须小于CCA之间的睡眠时间。CCA之间的睡眠时间要小于Twake_data, 因为如果一侧CCA落到一列唤醒包之外, 而另外一侧CCA在包间隔中, 会导致检测失败。
| $ {{T_{{\rm{packet\_interval }}}} < {T_{{\rm{ceastateep }}}} < {T_{{\rm{wate\_data }}}}} $ | (2) |
| $ {{T_{{\rm{wate\_data }}}} \times N + {T_{{\rm{packet\_interval }}}} \times (N - 1) < {T_{{\rm{stot }}}}} $ | (3) |
其中, N≥2。
为应对节点之间的走时差异, 需要确定同步偏差在什么范围内, 节点仍然能够接收根节点的数据。假设同步偏差为±Tsync_err, 为达到上述的要求, 需要满足式(4)、式(5)。
| $ {{T_{{\rm{sync\_err }}}} + {T_{{\rm{app}}{{\rm{ }}_ - }{\rm{data }}}} + {T_{{\rm{data}}{{\rm{ }}_ - }{\rm{start }}}} \le {T_{{\rm{wait}}{{\rm{ }}_ - }{\rm{data }}}} < {T_{{\rm{slot }}}}} $ | (4) |
| $ {{T_{{\rm{data}}{{\rm{ }}_ - }{\rm{start }}}} \ge {T_{{\rm{sync}}{{\rm{ }}_ - }{\rm{err }}}}} $ | (5) |
其中, Tsync_err表示节点走时偏差, Tapp_data表示根节点发送的数据包长度, Twait_data表示节点接收窗口大小, Tdata_start表示根节点发送应用数据的开始时间。理想的参数配置是根节点发送应用数据的开始时间等于节点走时偏差。例如传输速率设为10 kb/s, 时槽长度设置成500 ms, Tapp_data最大为80 ms(假设100 Byte), 那么理论上同步偏差在±210 ms内能够成功地检测并接收下行数据包。
现有的LoRaWAN协议网络完全采用同步的方式下行。LoRaWAN在网络下行分成一个个时槽, 节点与网关协商一个接收时槽, 并且在时槽中忙等待网关下发的数据。在这样的情况下会花费很多的功耗等待接收数据, 无法应对节点同步差的情况。而OPEN-MAC接收的过程是异步的, 有一个唤醒阶段, 能够应对同步差的情况。此外, 一般的LoRa节点是由SX128射频芯片和STM32处理器组成, 同步需要协调好射频模块和处理器之间的关系, 与CC1310片上系统相比难以达到精确的时间同步。
2.3 可配置的调度OPEN-MAC调度实现的基本思想是根节点维持全网唯一的数字ASN(Absolute Slot Number), 它表明当前的网络处于第几个时槽。随着时间的推移, 每走过一个时槽ASN完成加一操作。除了ASN, 完整的调度还包括上行阶段、下行阶段和睡眠阶段。在上行阶段、下行阶段和睡眠阶段均包含一个或几个同步时槽, 这取决于同步周期的长短, 图 5所示为OPEN-MAC的调度过程, 图中SYNC代表同步时槽。
|
Download:
|
| 图 5 OPEN-MAC调度 | |
业务阶段能够在应用层实现动态的配置。为更好地区别业务阶段(上行阶段、下行阶段和睡眠阶段)和同步阶段, 需要对业务阶段的时槽重新计算。设An代表随着时间移动的ASN序列, An={0, 1, …}, 设Bn代表周期性业务序列, 时间同步周期为Tsync, 业务总周期Tbus, Bn代表业务序列, 它相当于An序列中去掉第n个元素以前所有的同步阶段占用的时槽。Bn用关系式(6)求解。
| $ \begin{aligned} B_{n}=&\left(A_{n}-\left\lfloor A_{n} / T_{\text {sync }}\right\rfloor\right) \% T_{\text {bus }}=\\ &\left(A_{n}-\left(A_{n}+T_{\text {sync }}-1 / T_{\text {sync }}\right)\right) \% T_{\text {bus }} \end{aligned} $ | (6) |
通过以上的调度机制, OPEN-MAC的根节点只需要维持全局的ASN和业务变量(上行阶段时长、下行阶段时长和睡眠阶段时长), 就可以实现全网的调度更改。此外, 时槽的长度也是可以配置的, 如速率为50 kb/s的时槽长度可以设置为50 ms, 速率为10 kb/s的时槽可以设置为500 ms。
与传统的无线传感器网络协议相比, LoRaWAN和6LoWPAN只规定了网络的时序操作, 并不涉及业务配置。如果要满足不同场景低功耗, 上报次数的要求则需要单独设计, 设计相对复杂。而OPEN-MAC的设计考虑了不同物联网, 监测任务的监测周期和功耗是不同的。
3 分析与评估结果本文使用42个商用的CC1310节点来评估OPEN-MAC网络性能, 并在ContikiOS上实现了OPEN-MAC星型网络协议栈。为达到预期低功耗的效果, 对节点未使用的GPIO和外设进行低功耗预处理, 表 1给出默认的参数配置。
|
下载CSV 表 1 默认参数配置 |
本文选取了哈尔滨工业大学校园环境来评估OPEN-MAC网络上行覆盖范围。由于无线电磁波传输的特点, 电磁波在遇到障碍物会造成传输距离的降低, 因此基站越高越空旷, 传输的距离就越远。事实上, 许多无线基站也放在高处。为模拟这样的场景, 实验的基站需要放置在高处, 而节点可以放置在低处任何地方。为测试方便, 节点放在高处发送, 基站放在低处接收, 仍然可以测试上行的覆盖范围, 因为基站和节点的通信设备都是CC1310, 在通信环境相同情况下, 方向颠倒不影响通信距离。
在校园中, 节点的传输速率设置成10 kb/s, 本文在计算机学院9楼靠窗户的位置放置节点。受到场地的制约, 9楼放置节点是天线可以放在室外最高的楼层。在校园内移动基站, 基站射频处于常开状态。节点每秒发送1个数据包, 包长40 Byte。通过观察点对点稳定的收发来展示OPEN-MAC网络的覆盖范围。在室外环境中, OPEN-MAC网络采用速率为10 kb/s时具有覆盖700 m×750 m校园的能力。
3.2 时间同步OPEN-MAC采用基于收包的同步方式[20], 同步是实现无冲突上行和有保证下行的基础, 采用图 6的方式统计全网的同步偏差。节点与根节点的时间偏差如式(7)所示, 其中, Tr表示根节点发送完同步帧的结束时间, Tn表示节点MAC层收到同步帧的时间。在实际中, Tr与Tn是程序无法直接获取的, 通过估计的方式。采用CC1310的RTC(20 ppm的32.768 kHz晶振)实现OPEN-MAC。Nr表示Tr这段时间经历的RTC tick数, Nn表示Tn这段时间经历的RTC tick数, 一个RTC tick约为30.157 μs。
| $ {T_r} - {T_n} = \left( {{N_r} - {N_n}} \right) \times 30.157{\rm{ \mathsf{ μ} s}} $ | (7) |
|
Download:
|
| 图 6 同步偏差统计方式 | |
实验1共放置42个节点, 节点每10 min上报一次数据, 同步周期为30 s, 共运行350 min。节点的发送速率设置成50 kb/s, 时槽配置成50 ms。采用图 6的同步方式, 得到全网的同步偏差, 如图 7所示。全网所有的节点均在±1 000 μs以内, 表明网络长期稳定运行。此外随机选4个节点, 用逻辑分析仪测试实际偏差, 实际偏差和式(7)估计值之间的差距在62 μs之内。
|
Download:
|
| 图 7 同步周期为30 s的网络同步偏差 | |
对于网络下行, 节点需要检测数据包的到来, 因此需要设置合适的CCA阈值。在这里讨论10 kb/s传输速率下CCA阈值与误唤醒率(信道空闲时, 错误检测到信道忙的比例)之间的关系。在图 8中, CCA阈值越低误唤醒率越高, 通过实验的方式确定了该网络下行的CCA阈值(传输速率为10 kb/s)为-96 dBm。
|
Download:
|
| 图 8 CCA阈值与误唤醒率的关系 | |
本文设置OPEN-MAC网络的传输速率为50 kb/s和10 kb/s, 实验环境分别选在计算机学院(室内)和校园(室外)。OPEN-MAC的网络参数配置如表 2所示。
|
下载CSV 表 2 OPEN-MAC网络下行参数配置 |
在室内, 基站放在计算机学院最高层11楼室内, 该实验主要测试网络楼层穿透性能。基站每次发送200个数据包, 节点放在其他楼层, 统计收包率。
在室外, 基站放在计算机学院9楼靠窗位置, 主要因为场地限制, 这是天线可以放在室外最高的楼层。基站每次发送100个数据包, 节点放在室外其他地方。
本文使用网络下行端到端的收包率, 表示下行的可靠性, 图 9所示为楼层穿透与下行可靠性, 图 10表示室外环境的下行可靠性。可以看出, OPEN-MAC网络具有穿透性强, 下行覆盖范围广的特点。
|
Download:
|
| 图 9 楼层穿透与下行可靠性的关系 | |
|
Download:
|
| 图 10 室外环境的下行可靠性 | |
OPEN-MAC网络从时间上划分为上行阶段、下行阶段和睡眠阶段。为了评价网络下行可用性, 本文考虑一天24 h下行阶段能够占多长时间。在一天24 h中, 下行阶段可用时间=总时间(24 h)-上行阶段时间。上行阶段总时间=上行阶段总时槽个数×时槽长度。而上行阶段总时槽个数=(每天上报次数×上行阶段时槽个数)×时槽长度。上行阶段时槽个数=网络规模×重传次数。因此, 下行阶段可用时间=24 h-(每天上报次数×网络规模×重传次数)×时槽长度。经过计算可以得到本文的网络下行可用性。
图 11表明, OPEN-MAC网络的节点规模达到1 024个时, 下行可用时间几乎在20 h以上。
|
Download:
|
| 图 11 OPEN-MAC网络规模与下行可用性分析的关系 | |
OPEN-MAC网络下行时延主要取决于CCA周期和下行重传次数, 同时也取决于指令下发的时刻。在这里当指令下发发生在下行阶段时, 讨论时间延迟与功耗的关系, 节点的配置见表 2。基于OPEN-MAC网络行为, 进行节点占空比能耗估计。同时, 采用型号为344 01A电流表对节点的实际电流进行测量, 如图 12所示。在图 12中, 当维持节点的占空比为0.3%时, 50 kb/s配置节点电流不超过50 μA, 10 kb/s配置节点的平均电流不超过20 μA, 时延在6 s之内(假设最大重传3次)。
|
Download:
|
| 图 12 OPEN-MAC网络下行CCA周期与功耗对比 | |
在下行中, 本文根据LoRaWAN协议给出的时序图进行网络下行能耗的估计, 用占空比表示。LoRaWAN默认采用5 Byte的前导码检测。Class A设备开启2个接收窗口, Class B设备也开启2个接收窗口。为了公平, OPEN-MAC也开启2个接收窗口, 结果如图 13所示。从图 13可以看出, OPEN-MAC功耗要比LoRaWAN低。OPEN-MAC使用2个CCA检测数据包, 2次CCA的时间固定在4 ms, 不随速率降低而变长。而LoRaWAN的Class B设备忙等待接收数据包, 而且受同步影响较大。
|
Download:
|
| 图 13 OPEN-MAC与LoRaWAN功耗的对比 | |
为公平地与LoRa进行覆盖能力的对比, 本文运用与OPEN-MAC类似配置的关于LoRa网络的评估指标, 对比的内容为收包率与覆盖范围。文献[27]设LoRa网络节点SX1272速率为293 b/s, 传输功率为14 dBm, 节点大约每13 s向基站传输一个数据包。LoRa的基站海拔高24 m。测试人员携带1个LoRa节点在校园不同地方移动, LoRa不同位置的测试结果如表 3所示。
|
下载CSV 表 3 LoRa不同位置的测试结果 |
OPEN-MAC网络采10 kb/s的传输速率, 发射功率为15 dBm, 城市覆盖范围在250 m~390 m, 平均距离达320 m, 可靠性平均在99%以上。OPEN-MAC在覆盖范围和可靠性方面比LoRa网络有优势。典型的LoRa节点由STM32微控制和SX1276射频芯片构成, 而CC1310是集成射频芯片的SoC, 因此成本比LoRa节点要低。
3.7 与NB-IOT协议的对比NB-IOT下行技术是eDRX, 与LoRaWAN类似, 网络下行完全依靠时间同步。基站和根节点提前协商一个接收时槽, 在接收阶段, 节点处于忙等待状态。根据eDRX时序描述, 假设它的前导码为5 Byte和3个下行接收窗口, 根据eDRX的网络模型估计节点的占空比。
当考虑下行等待时间为6 s时(CCA周期为2 s, 开启3个下行窗口), 不同的同步偏差对2种网络的下行功耗影响如图 14(a)所示。当考虑同步偏差在5 ms不变条件下, 下行等待时间对2种网络下行功耗的影响如图 14(b)所示。
|
Download:
|
| 图 14 OPEN-MAC与NB-IOT功耗比较 | |
与NB-IOT可靠的下行相比, OPEN-MAC网络的功耗更低。NB-IOT拥有专有的下行链路, 可靠性更有保证。然而, OPEN-MAC节点CC1310是SoC, 并且使用免费频段, 因此成本比更低。
3.8 与ContikiMAC组成的多跳网络对比为了证明在能耗和上行可靠性方面的优势, 本文将OPEN-MAC网络与传统的WSN网络进行对比。在这里特别考虑6LowPAN自组织多跳网络, 使用ContikiMAC作为默认的RDC层(Radio Duty Cycling)协议。
本文在室内进行对比的实验, 将ContikiMAC节点放置在室内不同楼层中, 一共放置7个节点组成5跳近视线性的网络, 每跳之间相隔3层~4层楼。ContikiMAC节点程序采用标准的RPL+ContikiMAC, 代码来自contiki社区[28]。在ContikiMAC多跳网络中, 使每个节点30 s发送一个数据包, 有效负载46 Byte, 每个节点发送200个数据包。为了公平对比, 本文的OPEN-MAC网络采用穿透性更强的速率10 kb/s, 在不同跳数ContikiMAC节点位置放置OPEN-MAC节点。
由于OPEN-MAC网络同步的占空比开销(900 s同步一次)非常低, 这里忽略同步功耗。经过测试发现, OPEN-MAC网络在1、2、3、4跳的链路质量很好, 可靠性分别是100%、100%、100%、100%。然而OPEN-MAC节点在5跳位置的链路质量较差, 可靠性为34%。根据链路可靠性, 估计OPEN-MAC节点在1、2、3、4跳几乎不需要重传, 而节点在5跳位置重传次数会达到3次。使用收发时间/发送周期来估计OPEN-MAC节点的占空比。这种估计的方式虽然与实际情况有些偏差, 但是偏差很小。图 15所示为OPEN-MAC网络和ContikiMAC组成的多跳网络对比。从整体上看, 1、2、3、4跳位置OPEN-MAC网络的可靠性和ContikiMAC相差不多, 然而ContikiMAC节点的能耗要比OPEN-MAC节点能耗高3倍以上。
|
Download:
|
| 图 15 2种网络在可靠性和能耗对比 | |
本文提出一种新型的网络架构OPEN-MAC, 利用商用低成本的LPWAN设备, 实现网络上行以及有保障的网络下行。OPEN-MAC网络中节点一天20 h~24 h可以随时接收网络下行数据, 网络下行的最大时间延迟不超过6 s, 同时节点的功耗较低。下一步将研究CC1310更低速率的驱动方法, 实现更远的距离传输。
| [1] |
陈海明, 石海龙, 李勐, 等. 物联网服务中间件:挑战与研究进展[J]. 计算机学报, 2017, 40(8): 1725-1749. ( 0)
|
| [2] |
MURTY R N, MAINLAND G, ROSE I, et al.CitySense: an urban-scale wireless sensor network and testbed[C]//Proceedings of IEEE Conference on Technologies for Homeland Security.Washington D.C., USA: IEEE Press, 2008: 125-134.
( 0)
|
| [3] |
KIM S, PAKZAD S.Health monitoring of civil infrastructures using wireless sensor networks[C]//Proceedings of the 6th International Conference on Information Processing in Sensor Networks.New York, USA: ACM Press, 2007: 254-263. http://www.researchgate.net/publication/4289738_Health_Monitoring_of_Civil_Infrastructures_Using_Wireless_Sensor_Networks
( 0)
|
| [4] |
LANGENDOEN K, BAGGIO A, VISSER O.Murphy loves potatoes: experiences from a pilot sensor network deployment in precision agriculture[C]//Proceedings of International Conference on Parallel and Distributed Processing.[S.1.]: IEEE Computer Society, 2006: 174-174.
( 0)
|
| [5] |
ADELANTADO F, VILAJOSANA X, TUSET-PEIRO P, et al. Understanding the limits of LoRaWAN[J]. IEEE Communications Magazine, 2017, 55(9): 34-40. DOI:10.1109/MCOM.2017.1600613 ( 0)
|
| [6] |
IEEE 802.15.4[EB/OL].[2018-08-25]. http://standards.ieee.org/about/get/802/802.15.html.
( 0)
|
| [7] |
IEEE 802.11[EB/OL].[2018-08-25]. http://www.ieee802.org/11.
( 0)
|
| [8] |
RAZA U, KULKARNI P, SOORIYABANDARA M. Low power wide area networks:an overview[J]. IEEE Communications Surveys and Tutorials, 2016, 19(2): 855-873. ( 0)
|
| [9] |
Sigfox[EB/OL].[2018-08-25]. https://www.sigfox.com/en.
( 0)
|
| [10] |
Huawei Technologies Co., Ltd.NB-IOT[EB/OL].[2018-08-25]. http://developer.huawei.com/ict/cn/site-iot/product/nb-iot.
( 0)
|
| [11] |
LoRa Alliance.LoRa[EB/OL].[2018-08-25]. https://www.lora-alliance.org/.
( 0)
|
| [12] |
CENTENARO M, VANGELISTA L, ZANELLA A, et al. Long-range communications in unlicensed bands:the rising stars in the IoT and smart city scenarios[J]. IEEE Wireless Communications, 2015, 23(5): 60-67. ( 0)
|
| [13] |
DONGARE A, HESLING C, BHATIA K, et al.OpenChirp: a low-power wide-area networking architecture[C]//Proceedings of IEEE International Conference on Pervasive Computing and Communications.Washington D.C., USA: IEEE Press, 2017: 569-574.
( 0)
|
| [14] |
SAIFULLAH A, RAHMAN M, ISMAIL D, et al.SNOW: sensor network over white spaces[C]//Proceedings of ACM Conference on Embedded Network Sensor Systems Cd-Rom.New York, USA: ACM Press, 2016: 272-285.
( 0)
|
| [15] |
SAIFULLAH A, RAHMAN M, ISMAIL D, et al.Enabling reliable, asynchronous, and bidirectional communication in sensor networks over white spaces[C]//Proceedings of ACM Conference on Embedded Networked Sensor System.New York, USA: ACM Press, 2018: 1-14.
( 0)
|
| [16] |
ELETREBY R, ZHANG D, KUMAR S, et al.Empowering low-power wide area networks in urban settings[C]//Proceedings of Conference of the ACM Special Interest Group on Data Communication.New York, USA: ACM Press, 2017: 309-321. http://www.researchgate.net/publication/318917024_Empowering_Low-Power_Wide_Area_Networks_in_Urban_Settings
( 0)
|
| [17] |
LoRa Alliance.LoRaWAN specification[EB/OL].[2018-08-25]. https://www.lora-alliance.org/.
( 0)
|
| [18] |
LoRa Alliance.LoRaWAN 1.0.2 regional parameters[EB/OL].[2018-08-25]. https://www.lora-alliance.org/.
( 0)
|
| [19] |
ADHIKARY A, LIN Xingqin, WANG Y P E.Performance evaluation of NB-IoT coverage[C]//Proceedings of the 84th IEEE Vehicular Technology Conference.Washington D.C., USA: IEEE Press, 2017: 1-5.
( 0)
|
| [20] |
DUDUENNOY S, ELSTS A, NAHAS B A, et al.TSCH and 6TiSCH for Contiki: challenges, design and evaluation[C]//Proceedings of International Conference on Distributed Computing in Sensor Systems.Washington D.C., USA: IEEE Press, 2018: 11-18.
( 0)
|
| [21] |
ASHRAFUZZAMAN K, KWAK K S. On the performance analysis of the contention access period of IEEE 802.15.4 MAC[J]. IEEE Communications Letters, 2011, 15(9): 986-988. DOI:10.1109/LCOMM.2011.071211.111271 ( 0)
|
| [22] |
DUNKELS A.The ContikiMAC radio duty cycling protocol[D].[S.1.]: Swedish Institute of Computer Science, 2011.
( 0)
|
| [23] |
Texas Instruments.CC1310[EB/OL].[2018-08-25]. http://www.ti.com.cn/product/cn/cc1310.
( 0)
|
| [24] |
杨伟, 何杰, 万亚东, 等. 基于IEEE802.15.4e标准的工业物联网安全时间同步策略[J]. 计算机研究与发展, 2017, 54(9): 2032-2043. ( 0)
|
| [25] |
STANISLOWSKI D, VILAJOSANA X, WANG Qin, et al. Adaptive synchronization in IEEE802.15.4e networks[J]. IEEE Transactions on Industrial Informatics, 2013, 10(1): 795-802. ( 0)
|
| [26] |
SCHMID T, DUTTA P, SRIVASTAVA M B.High-resolution, low-power time synchronization an oxymoron no more[C]//Proceedings of International Conference on Information Processing in Sensor Networks.Stockholm, Sweden: [s.n.], 2010: 151-161.
( 0)
|
| [27] |
PETAJAJARVI J, MIKHAVLOV K, HAMALAINEN M, et al.Evaluation of LoRa LPWAN technology for remote health and wellbeing monitoring[C]//Proceedings of International Symposium on Medical Information and Communication Technology.Washington D.C., USA: IEEE Press, 2016: 1-13.
( 0)
|
| [28] |
DUNKELS A.Contiki-os[EB/OL].[2018-08-25]. https://github.com/contiki-os/contiki.
( 0)
|
2019, Vol. 45

0)