在《评说 1.2：多跳无线网络的现状》一文中，我们提到：在室外长距离的无线自组织网络中，由于节点之间的链路损耗较大，其链路预算相对不足，其包误码率PER会相应升高，也就是丢包概率 p 会比较大；而在一个大规模网络中，某些分支节点的通讯链路又会比较深，也就是网络跳数 n 比较大，在这种情况下其通讯成功率Pn自然也就显著下降了，人们的切身感受就是这个链路不太稳定。
此时人们的第一反应自然是上 TCP 算法，在发送节点启用 TCP Client 算法，在接收点启用 TCP Server 算法，实现端到端的控制，这样不就可以解决多跳无线通讯网络的可靠性了么？我们今天就来深入讨论一下这个问题。
很显然在一个真实的无线通讯系统中，每一个节点都是具备双向收发能力的，但是为了更加清晰的描述数据流向，我们将原始数据的发出者定义为发射机，将目标数据的接受者定义为接收机；如下图所示，我们定义左边红色的“铁塔”为发射机，右边蓝色的“锅盖”为接收机。
图1-发射机与接收机
在一个较大规模的无线通讯网络中，中继通常有两种存在形式，一种是独立的中继器，通常其硬件配置较高，性能也比较强劲，并安装有多根天线；另外一种是普通的数据节点本身承担数据转发的功能，这种节点成本较低，通常仅仅配置一根天线。无论其硬件配置和工作原理如何，它们都可以承担数据转发的功能，为了更加直观的描述中继的工作机制，我们以双天线的中继器为例。
图2-多跳无线中继
在多数情况下，负责参数通讯的还有外部的用户系统，比如连接数据库的上位机应用程序和连接现场工业传感器的嵌入式设备；通常负责发起数据请求的是上位机应用程序，二者以RJ45以太网线或者RS232电缆连接。
图3-上位机应用软件
负责采集数据并回传的是嵌入式设备，二者以RS232电缆，TTL电平的串口或者GPIO端口直接相连。
图4-下位机现场设备
按照我们之前的约定，我们选定网络中一个具有6跳的（5个中继）分支链路，在该链路上一个标准的通讯业务流程通常如下：
注意到，这里仅仅是数据的下行请求过程，在嵌入式系统完成了数据的采集之后，就会将其作为应答回传给上位机系统，其上行通讯流程刚好和下行传输完全相反：
我们都知道，有线通讯由于在封闭的通道中运行，其错误率通常在 10-9~10-12，可靠性是非常高的，我们基本不用考虑丢包的问题。这里为了叙述方便，我们将上位机应用程序的功能合并到发射机中去，将连接工业传感器的嵌入式设备的功能合并到接收机中去，这样简化之后的模型就是下图。
图5-UDP多跳传输模型
在该模型中，每一个角色的基本工作原理如下：
上图是丢包概率 p = 10% 的时候的一种效果模拟图。这里设定了5次数据重传，从该图我们看出来每一次的通讯丢包情况都不同：
当然有的读者心里会想，这个效果模拟图太过于极端，上述流程中有好几次差一点就通讯成功了呢，就差一口气！如果我们加大尝试的次数，说不定就成功了呢?
事实上在大多数情况下，加大尝试次数，通讯成功率的确会有一定的改善，但无法从根本上消除问题。考虑到有线链路的和无线多跳的通讯延迟，再叠加上目标设备的数据采集行为，下行或者上行链路的传输时间可能高达数百毫秒；在真实的环境中，还要考虑到各种系统延迟和等待操作，比如Windows，Linux等主流桌面操作系统的调度延迟，各级无线节点的单片机延迟，这个时间往往还需要进一步加大，最终这个总的时间往往高达数秒甚至几十秒，在一个有几百个节点的数据采集系统中，系统整体扫描一遍，耗时将会比较长了。
从上述分析可以看出，端到端的重传机制在跳数较深的无线自组织网络中难以保证足够的可靠性，即便牺牲延时，加大重传次数，效果也不会有根本性的改善。那么问题来了！我们要怎么做才可以获得理想的可靠性与实时性呢？敬请关注后续系列文章的深入解读。
京公网安备 11010802033920号
