WiMinet 评说1.3：模拟式UDP中继技术缺陷

主页（http://www.pttcn.net）：WiMinet 评说1.3：模拟式UDP中继技术缺陷

1、前言

在《WiMinet 评说 1.2：多跳无线网络的现状》一文中，我们提到：在室外长距离的无线自组织网络中，由于节点之间的链路损耗较大，其链路预算相对不足，其包误码率PER会相应升高，也就是丢包概率 p 会比较大；而在一个大规模网络中，某些分支节点的通讯链路又会比较深，也就是网络跳数 n 比较大，在这种情况下其通讯成功率P_n自然也就显著下降了，人们的切身感受就是这个链路不太稳定。

此时人们的第一反应自然是上 TCP 算法，在发送节点启用 TCP Client 算法，在接收点启用 TCP Server 算法，实现端到端的控制，这样不就可以解决多跳无线通讯网络的可靠性了么？我们今天就来深入讨论一下这个问题。

2、多跳网络

很显然在一个真实的无线通讯系统中，每一个节点都是具备双向收发能力的，但是为了更加清晰的描述数据流向，我们将原始数据的发出者定义为发射机，将目标数据的接受者定义为接收机；如下图所示，我们定义左边红色的“铁塔”为发射机，右边蓝色的“锅盖”为接收机。

图1-发射机与接收机

在一个较大规模的无线通讯网络中，中继通常有两种存在形式，一种是独立的中继器，通常其硬件配置较高，性能也比较强劲，并安装有多根天线；另外一种是普通的数据节点本身承担数据转发的功能，这种节点成本较低，通常仅仅配置一根天线。无论其硬件配置和工作原理如何，它们都可以承担数据转发的功能，为了更加直观的描述中继的工作机制，我们以双天线的中继器为例。

图2-多跳无线中继

在多数情况下，负责参数通讯的还有外部的用户系统，比如连接数据库的上位机应用程序和连接现场工业传感器的嵌入式设备；通常负责发起数据请求的是上位机应用程序，二者以RJ45以太网线或者RS232电缆连接。

图3-上位机应用软件

负责采集数据并回传的是嵌入式设备，二者以RS232电缆，TTL电平的串口或者GPIO端口直接相连。

图4-下位机现场设备 

3、业务流程与运作机制

按照我们之前的约定，我们选定网络中一个具有6跳的（5个中继）分支链路，在该链路上一个标准的通讯业务流程通常如下：

(1)  上位机系统发起数据请求

(2)  数据请求通过有线电缆传递给发射机

(3)  发射机将数据发送给1号中继

(4)  数据依次在中继1→2→3→4→5之间传递，最后到达接收机

(5)  接收机将数据通过有线电缆传递给嵌入式系统

(6)  嵌入式系统采集数据

注意到，这里仅仅是数据的下行请求过程，在嵌入式系统完成了数据的采集之后，就会将其作为应答回传给上位机系统，其上行通讯流程刚好和下行传输完全相反：

(1)  嵌入式系统送出采集到的数据

(2)  数据应答通过有线电缆传送给接收机

(3)  接收机将数据发送给5号中继

(4)  数据依次在中继5→4→3→2→1之间传递，最后到达发射机

(5)  发射机将数据通过有线电缆传递给上位机系统

(6)  上位机系统完成数据的存储，计算和显示

4、UDP多跳传输模型

我们都知道，有线通讯由于在封闭的通道中运行，其错误率通常在 10^-9~10^-12，可靠性是非常高的，我们基本不用考虑丢包的问题。这里为了叙述方便，我们将上位机应用程序的功能合并到发射机中去，将连接工业传感器的嵌入式设备的功能合并到接收机中去，这样简化之后的模型就是下图。

图5-UDP多跳传输模型

在该模型中，每一个角色的基本工作原理如下：

(1)  发射机：产生数据请求，发送给中继1，然后转入接收状态，等待来自目标节点（接收机）的应答数据；如果在指定的时间之内收到了应答数据则代表通讯成功；如果没有则重新发送请求并增加计数器；当计数器到达某个限定数值则认定通讯失败。

(2)  接收机：平时处于接收等待状态，一旦从中继5接收到了来自发射机的请求数据，则立刻生成应答数据，并交给中继5。

(3)  中继器：按照报文约定的指定的传输方向，复制报文并以重新发送给下一个接收节点，包括中继，发射机和接收机。

上图是丢包概率 p = 10% 的时候的一种效果模拟图。这里设定了5次数据重传，从该图我们看出来每一次的通讯丢包情况都不同：

(1)  新数据请求，在发射机到中继1的下行链路上就丢失了

(2)  第1次重传，在中继2到中继3的下行链路上丢失了

(3)  第2次重传，下行链路各跳全部成功，接收机正确的收到了数据，并生成了应答，但是应答数据在中继5→中继4的上行链路上丢失了

(4)  第3次重传，在中继3到中继4的下行链路上丢失了

(5)  第4次重传，下行链路各跳全部成功，接收机正确的收到了数据，并生成了应答，但是应答数据在中继2→中继1的上行链路上丢失了

(6)  第5次重传，在在中继5到接收机的下行链路上丢失了

(7)  重传计数器到达极限，应用程序判定当前链路不稳定，通讯失败！

5、总结

当然有的读者心里会想，这个效果模拟图太过于极端，上述流程中有好几次差一点就通讯成功了呢，就差一口气！如果我们加大尝试的次数，说不定就成功了呢?

事实上在大多数情况下，加大尝试次数，通讯成功率的确会有一定的改善，但无法从根本上消除问题。考虑到有线链路的和无线多跳的通讯延迟，再叠加上目标设备的数据采集行为，下行或者上行链路的传输时间可能高达数百毫秒。

在真实的环境中，还要考虑到各种系统延迟和等待操作，比如Windows，Linux等主流桌面操作系统的调度延迟，各级无线节点的单片机延迟，这个时间往往还需要进一步加大，最终这个总的时间往往高达数秒甚至几十秒，在一个有几百个节点的数据采集系统中，系统整体扫描一遍，耗时将会比较长了。

从上述分析可以看出，端到端的重传机制在跳数较深的无线自组织网络中难以保证足够的可靠性，即便牺牲延时，加大重传次数，效果也不会有根本性的改善。那么问题来了！我们要怎么做才可以获得理想的可靠性与实时性呢？敬请关注后续系列文章的深入解读。