文章目录

Challenges for Transport Layer
- End-to-End Measures
- Application-Dependent Operation
- Energy Consumption
- Constrained Routing/Addressing
- Biased Implementation
Reliable Multi-Segment Transport (RMST) Protocol
Pump Slowly, Fetch Quickly (PSFQ) Protocol
- Pump Operation
- Fetch Operation
- Status Reporting
Congestion Detection and Avoidance (CODA) Protocol
Event-to-Sink Reliable Transport (ESRT) Protocol
References

WSN 的成功和效率直接取决于传感器节点和 sink 之间的可靠通信。WSNs 传输层协议的主要功能有：

Congestion control：网络拥塞会导致丢包，因此需要拥塞控制来提高网络的可靠性，并节省本就不富裕的传感器资源
Reliable transport：确保传感器节点发送的数据到达了 sink，或者 sink 的数据到达了节点
(De)multiplexing：通过使用适当的多路复用和解复用技术来桥接应用层和网络层，通过同一WSN 为多个应用服务

为传统的无线网络设计的传输层解决方案可能在 WSN 中并不适用，主要有以下三点原因：

严格的端到端可靠性，基于确认和重传的机制，会在 WSN 中的部署中带来巨大的开销；
相邻传感器节点之间的数据具有高度相关性，会使这些机制的能源效率大大降低；
需要相当大的内存容量来缓冲传输的数据包，直到它们被接收器确认，但传感器节点的缓冲空间和处理能力有限。

Challenges for Transport Layer

在这里插入图片描述

End-to-End Measures

传统的传输层解决方案提供端到端和点到点的可靠性以及拥塞控制，数据包丢失和拥塞缓解是通过源和目的地之间的通信进行的，没有任何中间方的参与，且每个流量都被独立考虑，以提供一个点对点的通信解决方案。但在 WSN 中，来自一组传感器的整体信息比来自每个传感器节点的个别信息要重要得多，传统的这种点对点方案会造成大量传感器资源的浪费。

因此，在 WSN 中通常利用局部的可靠性和拥塞控制来提高传输层协议的能源效率，我们控制的是来自一组传感器的整体信息的可靠性，而不是来自单独传感器节点的信息的可靠性。

Application-Dependent Operation

WSN 通常部署在跟应用需求相关的环境中，没有哪一种通用的方案可以适用于所有场合。

因此，传输层协议的设计要立足于当前应用，并考虑到具体部署方案的设计要求和限制条件。

Energy Consumption

能源效率是 WSN 设计中最重要的关注点之一。为传统网络设计的一些协议通常需要在多跳网络中消耗大量能源，并不适合 WSN。

传输层协议应该 energy aware，即必须以尽可能少的能源支出来实现差错和拥塞控制目标。且传输层协议的设计可以使我们通过局部的可靠性措施来换取能源消耗的减少。如果 sink 发现接收到的信息大多都是对的，比我们期望的可靠性要求还高，那就可以让发送方悠着点，节省点能量，或者干脆直接关闭电源。

Constrained Routing/Addressing

正如我们在《无线传感器网络：网络层》讨论的那样，WSN 中为每个节点赋一个全局唯一标识是不太现实的，因此，传输层的协议不能基于全局的寻址机制，而是要利用像 data centric 这样的路由机制。

Biased Implementation

WSN 由许多资源有限的传感器节点和资源较为丰富的 sink 组成，因此较为复杂的算法并不能在这些传感器节点上运行。且网络中的流量在不同方向上表现出不同的特征。从节点到 sink 的流量可能要求及时交付且有必要的容错机制，而从 sink 到节点的流量则要求高交付率。

因此，传输层协议的设计应使大部分功能集中在 sink，而对传感器节点的功能要求降到最低。此外，也要考虑到不同方向流量的要求特征。

基于这几个挑战，我们介绍几个传输层协议。

在这里插入图片描述

Reliable Multi-Segment Transport (RMST) Protocol

我们在开篇提到过 WSN 中传输层协议的 3 个主要功能，RMST 实现了其中的两个：

Reliable transport：
- 提供机制来处理整个网络中的错误
- 利用网络缓存，保证数据包能够顺利交付
Multiplexing/demultiplexing：
- 在传感器节点复用，在 sink 处解复用

RMST 是建立在定向扩展（directed diffusion）路由协议基础之上的，并且使用了它的部分功能。RMST 有两种运行模式：

Non caching mode：与传统的传输层协议类似；只有源和目的地在提供可靠性方面起作用而不涉及到中间节点。在 sink 检测到数据包丢失，并通过 NACK 包以端到端方式向源节点提出重传请求。
Caching mode：强化路径上的中间节点对传输的数据包进行缓存，以减少端到端重传的开销。

RMST 具体是如何提供可靠性的呢？

每个数据包都会被一个唯一的序列数字标识（例如 0，1，2…），如果当前收到的包的数字标识与之前收到的包的标识没有连续上，就说明出错了。这时 sink 沿着相同但方向相反的路径（定向扩展的 gradients）回传一个 NACK 来要求节点重传。下面我们看看这个流程在两种不同运行模式下具体是怎么实现的。

在 Non caching 模式下，NACK 会一直传回到源节点，然后源节点再进行重传：

在这里插入图片描述

而在 Caching 模式下，某些节点会被设置为缓冲节点来缓存传输的数据包。数据包的丢失检测会也会在缓冲节点进行。下图中，在最后一个缓冲节点检测到丢包后，它直接回传 NACK，而上一个缓冲节点正好缓存有丢失的数据包，该数据包接下来就会再逐步传到 sink。当然，如果缓冲节点都没有丢失的数据包，那么 NACK 会一直回传到源节点。

在这里插入图片描述

Pump Slowly, Fetch Quickly (PSFQ) Protocol

与许多专注于传感器节点到 sink 路径的传输层方法相反，PSFQ 协议被用来解决从 sink 到传感器节点的路径问题。这是因为，反向路径通常用于网络管理任务，因此可靠性也十分重要。传感器节点到 sink 的路径可能可以容忍一定的信息损失，因为传感器产生的数据高度相关，但反向路径需要一对一的通信支持，以可靠地传播由 sink 发送给每个传感器节点的控制信息。

PFSQ 协议主要提供了 3 个功能：

Pump operation：PSFQ 采用一个叫作 slow pump 的机制，将数据包缓慢地注入网络。在这种情况下，通往目的地的路线上的每个节点在转发信息之前都要等待一定的时间
Fetch operation：在发生数据包错误的情况下，每个节点执行积极的逐跳恢复，期望尽快从邻居节点获取丢失的数据包
Status reporting：PSFQ 还提供了一个报告功能，在传感器和 sink 之间建立了闭环通信。通过这个功能，sink 可以收集与网络运行有关的信息

我们逐一的来看一下这三个功能的实现。

Pump Operation

在这里插入图片描述
我们有两个计时器 $T_{min}$ 和 $T_{max}$ ，一个传感器节点每过 $T_{min}$ 就会向它的邻居节点广播数据包。邻居节点等待随机时间后，会转发该数据包，等待时间的范围为 [ $T_{min}$ , $T_{max}$ ]。转发时的随即等待在一定程度上减少了同一数据包的广播次数，如果数据包已经被某一个邻居节点所转发，那么其它邻居节点就不再进行转发了。

Fetch Operation

在这里插入图片描述

当某个节点检测到丢包后，它会立即向它的邻居节点广播 NACK，如果节点在 $T_r$ （ $T_r<T_{max}$ ）时间内没有收到回应，那么它继续广播 NACK。

如果某个收到 NACK 的邻居节点缓存有该数据包，那么它就会在 [ $0.25T_r$ , $0.5T_r$ ] 时间段内发送该数据包。（fast fetch！）

Status Reporting

报告操作是由 sink 通过设置数据包头中的报告位（report bit）发起的。这个数据包通过网络被发送到预定的各个节点上。在收到报告请求后，传感器节点立即通过发送一个报告信息做出响应，沿着通往 sink 的路径的每个节点通过捎带（ piggybacking）将其状态信息添加到该报告中。如果上游路径上的节点没有在 $T_{report}$ 时间内收到报告响应，它就会直接创建自己的报告包并将其沿路径传回 sink。