从需求出发浅谈传感网络的底层

引言

一个采集系统,采集部分由单片机控制传感器进行,数据需要存储到数据库,那么中间就需要进行传输,关于传输,如何传输,本次文章就是为了解决这个问题。

需求分析

首先假设一下需求,

需求 指标
场景 矿井
传感器数量 240
上报周期 < 30s
稳定性 尽可能高
成本 尽可能低

其中的传感器数量和上报周期是在《凤凰山矿井下多参数测量传感器技术研究》1这篇论文里找到的,仅供参考。

物理层

物理层技术

要解决数据传输的问题,首先就要从物理层考虑,物理层的选择也有很多种,首先最传统的有线的比如铜缆、光缆之类的,稳定,可靠,但是成本高,需要铺设大量线缆,并且终端设备无法移动。除此以外还有或者使用电力线通信,比如电力猫这种设备,还有就是远程抄表,是很有前景的技术,不过我了解不多,可能是因为电力线的作为信道的性能比较差,可用带宽比较窄、噪声比较多,好像不是特别热点的技术。但相比于无线通信,有线通信的成本就太高了。无线的技术很多,分远近两种:短距离的比如ZigBee、蓝牙、WiFi、RFID、UWB等,流行的很多,比较容易实现局域网的覆盖;长距离的比如LoRa、NB-IoT等,这种都是冲着构建新的广域网去的,具有非常大的覆盖范围。这里提一下,上面说的指的都是这些技术所规定的物理层,不涉及上层,比如WiFi的802.11,蓝牙的802.15等,当然你用有线网络去运行WiFi的协议栈也没有什么问题,标准是死的,人是活的,不过通常协议栈还是成套开发的。

技术 优点 缺点
有线传输 稳定可靠 成本高
短距离无线传输 成本相对较低 需要多跳,网络结构复杂,可靠性相对较低
长距离无线传输 成本相对较低,网络结构简单 速率相对较低

首先从本系统入手,节点数不多,采样频率要求不高,需要覆盖比较大的范围,对数据的可靠性有一点要求。那么要不采用有线的方式,要么就利用短距离无线通信加以多跳方式传输,要么采取长距离的无线通信方式。在降低成本且最大程度保证可靠性的情况下,长距离无线通信是比较适合的。NB-IoT需要连接到现有的蜂窝移动网络,使用起来比较复杂,在矿井下使用外部的蜂窝移动网络也不是那么可靠,那么最后就落到了LoRa技术上。

那LoRa技术能不能满足上述要求呢。

指标 性能
功耗 平均电流几十微安2
通信距离 煤矿井下2km左右3
速率 最高至300kbs4

几十微安级功耗的功耗是什么概念呢,可以大致用普通1200mAh的AA电池来估算
\frac{1200 \times 1000 }{30 \times 24 \times 365} =4.57 \ 𝑦𝑒𝑎𝑟𝑠
用个几年是没太大问题的。
考虑LoRa的速率,和其传输距离是负相关的,通常km级传输距离空中速率会低于5kbps。如果假设每信道点50节点,每段数据50字节,使用2.4kbps,按照常见的25%协议开销计算的话,一个周期大约是
50 \times 50 \div \frac{2400}{8} \div 75\% = 26.67s
通过多信道分组的话完全可以实现几百个节点的网络。

MAC层的构建

由于物理层共享介质,那么所有数据在物理层上都是广播信息,为了收发能正常进行,同一时间就只能有一个设备占用物理介质,想要实现共享就必须考虑冲突或者叫碰撞的问题。什么是冲突呢,如下图。

冲突

当两个以上的设备同时使用共享介质,那么就会导致接收方无法收到正确的信息,图中黑色部分就是发送冲突导致了数据的损坏,避免冲突的核心就是要知道当前共享的介质是否被占用。

从信道访问模式的角度,MAC协议通常划分为三种:基于竞争的、基于调度的、混合与事件驱动的。5

基于竞争的MAC协议

最早的基于竞争的MAC协议就是ALOHA协议。

ALOHA协议

工作模式很简单发送方有需要就发,接受方收到了就回发ACK帧,发送方收到ACK说明此次通信成功,没有收到ACK说明发送了冲突,例如图DATA2和DATA3,那么进行随机退避后继续发送。很容易想象对于低负载的网络还好,负载一高大家就都撞在一起了。

而后继者CSMA协议,相比ALOHA发送方在发之前多了一个侦听的动作,强化的协议有两种CSMA/CD和CSMA/CA。

CSMA/CD协议

CSMA/CD以太网里就用到这种,在发的时候同时收,收到和发的不一样就停,然后发送一段阻塞信号来增强冲突,退避后再尝试发送。例如图DATA2和DATA3,1和3同时发送,都发现了有其他设备在使用信道,然后都发送一段增强冲突的信号。

另一种CSMA/CA,无线通信里比较常用,先侦听,然后再发送,发送时有两种特殊的短帧,RTS和CTS帧用于三方握手。发送方发RTS,接收方发送CTS,其中包含了发送方将会占用的时间,第三方在收到后在这段时间就不会发送数据。除此之外,这种预约信道的工作模式还可以缓解隐藏终端的问题。

隐藏终端问题

那么什么是隐藏终端问题呢,比如此时A和B都要给C发送信息,但是AB都不在彼此的信号覆盖范围内,这个时候如果仅采用信号检测的方法,AB是无法得知对方在发送信息的。如果使用CSMA/CA,当A或者B要给C发送了RTS后,AB均能C所回复的CTS帧,收到CTS后,预约失败的设备就会进行退避。

基于调度的MAC协议

基于调度的协议有一个很关键的概念就是时隙,时间被预先切分成一个一个时隙,这些时隙被分配给网络中的各个设备。设备可以提前知道什么时候需要进行收发,其余时间都可以关闭射频端,这相比基于竞争的MAC这种需要一直开启射频段的协议可以有效降低设备功耗。时隙的分配通常分两种:静态分配和动态分配。

静态时隙划分

静态分配就是网络中的设备固定,每个设备分配长度固定的时隙,只能在其被分配到的时隙进行发送。这种协议工作非常稳定,对于数据采样这种非常固定的任务来说是很合适的,但是当网络变大后,设备发送数据的延迟也会相应提高。

动态时隙划分

动态分配需要有一个调度的中心,这个特殊的节点会根据当前的情况将一段时间的时隙分配广播给其下辖的节点。这里举的例子是LoRaWAN里面的class B类型6。每隔一段时间gateway会下发信标帧,在接收到信标帧后其下属设备End-device会定期唤醒,就是图中黄色的部分,两次唤醒之间也就是一个时隙。在设备唤醒期间,如果有需要gateway会给相应的End-device下发ping帧,对应设备在接收到ping帧后会打开一个上行窗口和一个下行窗口与gateway进行数据交换。通过gateway动态调度,可以实现有针对性地与End-device通信。

混合和事件驱动的MAC协议

第三种混合型的,指的就是用不同的方式把前面说到的两种方式的协议糅合在一起,比如Z-MAC,低流量时使用CSMA,提高信道的使用率减小延迟,高流量时用TDMA来减小冲突。

MAC协议所面临的问题

在对比各种类型之后,结合需求,就很容易定下需要怎样的MAC协议了。还记得最开始我们的需求吗,需要确保数据传输的稳定性,在保障延迟的情况下,选择基于调度的协议就足够了,简单易开发。可以移植现有的协议,比如LoRaWAN协议,也可以自己写一个其实并不是特别复杂。不过这里还遗漏了一些细节上的问题,下面会进行补充。

时间同步

可以注意到,基于调度的MAC协议和时间是息息相关的,因为它涉及到比较严格的时隙对齐,对偏了,就会发生冲突。各设备之间完全隔离,使用的是不同时钟源,其时间一定会出现偏差,因此需要隔一段时间就进行一次时间同步。因为这里面向的是低功耗的系统,GPS授时就不提了,只简单讲一下网络时间同步。有同学可能会觉得这个不容易吗,把直接告诉其他设备不就行了。当然如果在误差允许的情况下,这是可以的。
那么问题在哪里呢,先看一张图片

两种时间同步的方法

两根轴是绝对的时间时间,上面的标记是两个设备的本地时钟的时间,红色虚线连接的是两个设备的时钟值相同的地方,图中描述了两种时间同步的方法,其中下属设备的时间比中心设备慢 \Delta t 信号传输过程会需要 td 的时间。
信息在网络中传输是需要时间的,这个时间由于网络状况的不同是会发生变化的,这里会产生比较大的误差。所以核心的问题就是要知道这个传输延迟,只借助网络自身的话,这个延迟只能估计,这里用到了一个假设,假设由于短时间内网络状况相对稳定,两设备之间的双向传输的延迟是相同的。通过发送时携带本地的时钟值,通过两个帧的交换,下属节点可以得到T1~T4四个值,由图可以列出如下方程组
\begin{cases}
T2=T1+td+\Delta t\\
T4=T3+td-\Delta t
\end{cases}

通过方程组计算出信道的延迟和两设备相差的时间。
\begin{cases}
td=\frac{\left(T2-T1\right)+\left(T4-T3\right)}{2}\\
\Delta t=\frac{\left(T2-T1\right)-\left(T4-T3\right)}{2}
\end{cases}

得到这两个值后下属设备就可以计算出当前时间中心设备的时钟值。

设备发现

前面说到的基于调度的MAC协议,其运行的前提就是网络中的设备是固定的,负责调度的设备在一开始就要知道其下辖所有的设备。那么如果我中途想要增加一个设备怎么办呢,没办法,只能在修改后重启网络。这种情况是很麻烦的,尤其是一些重要的网络是不能随便重启的,那么在调度协议上怎么实现新设备的发现呢,如果仅依靠中心设备进行时隙划分,这在逻辑上是行不通的,调度协议中,下属设备只有在被中心设备分配到的时隙才能发送,但是中心设备想要发现新设备,那么新设备就必须告诉中心设备自己需要加入网络,一旦新设备想要主动发送,就会出现冲突,所有想要实现设备发现的功能,必须要跳出仅仅对在网设备做时隙分配的思想。做一些小小的修改,比如增加一段允许随机接入的时隙。

ZigBee信标模式

例如ZigBee里面就有信标使能模式7,它的时隙分配是图片这样的,CAP区使用基于时隙CSMA/CA,CFP区就是分配好的时隙,这其实就是一种混合型的MAC协议了,这种协议足够简单,但也能够实现足够的功能了。

法律规范

虽然LoRa工作在ISM频段,但在国内LoRa前景其实不是特别明朗,在2019年底工信部无管局发布了2019年52号公告8,其中对于民用计量仪表的限制对LoRa设备造成了影响。

无管局新规

其中明确限制了LoRa的使用范围,只能工作在470-510MHz的频段,并按照相关规范进行收发。

民用计量仪表规范

这份规范还是在国内各大LoRa厂商争取了一年后无管局才进行妥协的,最初的征求意见稿里甚至不允许LoRa进行组网。这其实也是可以理解的,现在LoRa设备越来越多,信道也会逐渐变得拥堵,增加相关规范是有助于行业发展的。另外,LoRa是能够独立构建广域网的技术,而且核心专利还是国外,任由这种不受管控的技术发展也不是什么好事。如果涉及到这方面应用的同学可能需要注意一下。

当然本文这里只考虑了单跳的网络拓扑,如果是多跳网络,那么MAC层的编写难度又会提高。不过这涉及到上层的网络层。上层的路由和流量控制也是非常值得说道的技术,不过限于篇幅并且资料也没收集齐全,所以之后再说。


知识共享许可协议
本作品由yellowko采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据