6LowPAN的适配层.docx
《6LowPAN的适配层.docx》由会员分享，可在线阅读，更多相关《6LowPAN的适配层.docx（15页珍藏版）》请在冰豆网上搜索。
6LowPAN的适配层
适配层
适配层是IPv6网络和IEEE802.15.4MAC层间的一个中间层，其向上提供IPv6对IEEE802.15.4媒介访问支持，向下则控制LowPAN网络构建、拓扑及MAC层路由。
6LowPAN的基本功能，如链路层的分片和重组、头部压缩、组播支持、网络拓扑构建和地址分配等均在适配层实现。
1.适配层基本功能
由于最大MTU、组播及MAC层路由等原因，IPv6不能直接运行在IEEE802.15.4MAC层之上，适配层将起到中间层的作用，同时提供对上下两层的支持，其主要功能如下：
●链路层的分片和重组：
IPv6规定数据链路层最小MTU为1280字节，对于不支持该MTU的链路层，协议要求必须提供对IPv6透明的链路层的分片和重组。
因此，适配层需要通过对IP报文进行分片和重组来传输超过IEEE802.15.4MAC层最大帧长（127字节）的报文。
●组播支持：
组播在IPv6中有非常重要的作用，IPv6特别是邻居发现协议的很多功能都依赖于IP层组播。
此外，WSN的一些应用也需要MAC层广播的功能。
IEEE802.15.4MAC层不支持组播，但提供有限的广播功能，适配层利用可控广播共泛的方式来在整个WSN中传播IP组播报文。
●头部压缩：
在不使用安全功能的前提下，IEEE802.15.4MAC层的最大payload为102字节，而IPv6报文头部为40字节，再除去适配层和传输层（如UDP）头部，将只有50字节左右的应用数据空间。
为了满足IPv6在IEEE802.15.4传输的MTU，一方面可以通过分片和重组来传输大于102字节的IPv6报文，另一方面也需要对IPv6报文进行压缩来提高传输效率和节省节点能量。
为了实现压缩，需要在适配层头部后增加一个头部压缩编码字段，该字段将指出IPv6头部哪些可压缩字段将被压缩，例如，传输类型和流标识符均为0时将在头部压缩编码字段被指出并且在IPv6头部中省去。
除了对IPv6头部以外，还可以对上层协议（UDP、TCP及ICMPv6）头部进行进一步压缩。
●网络拓扑构建和地址分配：
IEEE发布的标准文档IEEEStd802.15.4-2003对802.15.4协议物理层和MAC层做了详尽地描述，其中MAC层提供了功能丰富的各种原语，包括信道扫描、网络维护等。
但MAC层并不负责调用这些原语来形成网络拓扑并对拓扑进行维护，因此调用原语进行拓扑维护的工作将由适配层来完成。
另外，6LowPAN中每个节点都是使用EUI-64地址标识符，但是一般的LowPAN网络节点能力非常有限，而且通常会有大量的部署节点，若采用64-bits地址将占用大量的存储空间并增加报文长度，因此，更适合的方案是在PAN内部采用16-bits短地址来标识一个节点，这就需要在适配层来实现动态的16-bits短地址分配机制。
●MAC层路由：
现网络拓扑构建和地址分配相同，IEEE802.15.4标准并没有定义MAC层的多跳路由。
适配层将在地址分配方案的基础上提供两种基本的路由机制——树状路由和网状路由。
适配层是整个6LowPAN的基础框架，6LowPAN的其它一些功能也是基于该框架实现的。
整个适配层功能模块的示意图：
2.适配层帧格式
由于LowPAN网络有报文长度小、低带宽、低功耗的特点，为了减小报文长度，适配层帧头部分为两种格式，即不分片和分片，分别用于数据部分小于MAC层MTU（102字节）的报文和大于MAC层MTU的报文。
当IPv6报文要在802.15.4链路上传输时，IPv6报文需要封装在这两种格式的适配层报文中，即IPV6报文作为适配层的负载紧跟在适配层头部后面。
特别地，若”M”或“B”bit被置为1时，适配层头部后面将首先出现MB或Broadcast字段，IPv6报文则出现在这两个字段之后。
1）不分片报文格式
不分片头部格式的各个字段含义如下：
●LF：
链路分片（LinkFragment），占2bits。
此处应为00，表示使用不分片头部格式。
●prot_type：
协议类型，占8bits。
指出紧随在头部后的报文类型。
1表示IPv6报文，2表示头部压缩编码字段。
4表示路由错误报文。
●M：
MeshDelivery字段标志位，占1bit。
若此位置为1，则适配层头部后紧随着的是”MeshDelivery”字段。
●B：
Broadcast标志位，占1bit。
若此位置为1，则适配层头部后紧随着的是”Broadcast”字段。
●rsv：
保留字段，全部置为0。
2）分片报文格式
若一个包括适配层头部在内的完整负载报文不能够在一个单独的IEEE802.15.4帧中传输时，需要对负载报文进行分片，此时适配层使用分片头部格式封装数据。
分片头部格式如下：
分片头部格式的各个字段含义如下：
●LF：
链路分片（LinkFragment），占2bits。
当该字段不为0时，指出链路分片在整个报文中的相对位置，其中具体定义如下表所示。
LF
链路分片位置
00
不分片
01
第一个分片
10
最后一个分片
11
中间分片
●prot_type：
协议类型，占8bits，该字段只在第一个链路分片中出现。
●M：
MeshDelivery字段标志位，占1bit。
若此位置为1，则适配层头部后紧随着的是”MeshDelivery”字段。
若需要在Mesh拓扑中路由，每个分片中都应该有该字段。
●B：
Broadcast标志位，占1bit。
若此位置为1，则适配层头部后紧随着的是”Broadcast”。
若是广播帧，每个分片中都应该有该字段。
●datagram_size：
负载报文的长度，占11bits，所以支持的最大负载报文长度为2048字节，可以满足IPv6报文在IEEE802.15.4上传输的1280字节MTU的要求。
另外，在每个适配层分片中都需要携带该字段，这样能够使目的节点能在收到任何一个分片后（目的节点不一定首先收到第一个分片）确定重装后报文的大小而作一些有用的预处理，如预先分配缓冲区或者丢弃超过本节点能处理最大字节数的报文。
●datagram_tag：
分片标识符，占9bits，同一个负载报文的所有分片的datagram_tag字段应该相同。
每个节点都需要维护一个变更来记录当前的datagram_tag值，在节点初始化时应该将该值初始化为一个随机值（0~511），每发送一个完整的负载报文（而不是一个分片）该值加1，当该值达到511后翻转为0。
●fragment_offset：
报文分片偏移，8bits。
该字段只出现在第二个以及后继分片中，指出后继分片中的payload相对于原负载报文的头部的偏移。
该字段以8字节为单位，因此分片报文的payload必须以8字节为边界对齐。
另外，由于负载报文的第一个字节偏移一定为0，所以第一个分片的fragment_offset值默认为0。
3）MeshDelivery字段
4）若适配层头部（分片或不分片格式）M字段为1，则MeshDelivery字段紧随在分片或不分片的适配层头部之后，其格式如下图所示。
MeshDelivery字段的各个字段含义如下：
●O：
源地址类型标志位,占1bit，指出源地址（MAC地址）字段使用的地址是EUI-64长地址还是16-bits短地址。
若此位为0表示EUI-64地址；为1表示16-bits短地址。
●F：
最终目的地址类型标志位,占1bit，指出最终目的地址字段使用的地址是EUI-64长地址还是16-bits短地址。
若此位为0表示EUI-64地址；为1表示16-bits短地址。
●HopsLeft：
剩余跳数，占6bits。
每经过一个转发节点该值减1。
若该字段值减小到0转发节点就丢弃该帧。
●OriginatorAddress：
源链路层地址，可以为EUI-64地址，也可以为16-bits短地址。
●FinalDestinationAddress：
最终目的链路层地址，可以为EUI-64地址，也可以为16-bits短地址。
5）Broadcast字段
若适配层头部B字段为1，则Broadcast字段紧随在适配层头部之后，其格式如下所示。
Broadcast字段的各个字段含义如下：
●S：
广播源地址类型标志位，占1bit。
指出使用源地址是EUI-64长地址还是16-bits短地址。
若此位为0表示EUI-64地址；为1表示16-bits短地址。
●BroadcastRadius：
广播范围，7bits。
适配层广播帧每经过一个转发节点中继该字段值减1，若该字段减小到0转发节点停止继续转发该帧，但是本节点要将已经收到的广播帧提交给上层处理。
●SequenceNumber：
广播帧序号，8bits。
每个节点需要维护一个变量来记录当前的广播序号值，在节点初始化时将该值设为一个随机值（0~255），每发送一个广播帧时将=当前变量值填入SequenceNumber字段并将该值加1，当达到255后翻转为0。
●SourceAddress：
广播帧源链路层地址，可以为EUI-64地址，也可以为16-bits短地址。
3.分片和重组
当一个负载报文不能在一个单独的IEEE802.15.4帧中传输时，需要对负载报文进行适配层分片。
此时，适配层帧使用4字节的分片头部格式而不是2字节的不分片头部格式。
另外，适配层需要维护当前的fragment_tag值并在节点初始化时将其置为一个随机值。
1）分片
当上层下传一个超过适配层最大payload长度的报文给适配层后，适配层需要对该IP报文分片进行发送。
适配层分片的判断条件为：
负载报文长度+不分片头部长+MeshDelivery（或Broadcast）字段长度>IEEE802.15.4MAC层的最大payload长度。
在使用16-bits短地址并且不使用IEEE802.15.4安全机制的情况下，负载报文的最大长度为95（127-25（MAC头部）-2（不分片头部）-5（MD的长度））字节。
适配层分片的具体过程如下所示：
对于第一个分片：
●将分片头部的LF字段设置为01表示是第一个分片。
●Prot_type字段置为上层协议的类型。
若是IPv6协议该字段置为1。
另外，由于是第一个分片，offset必定为0，所以在在该分片中不需要fragment_offset字段。
●用当前维护的datagram_tag值来设置datagram_tag字段；datagram_size字段填写原始负载报文的总长度。
●若需要在Mesh网络中路由，MeshDelivery字段应该紧随在分片头部之后并在负载报文小分片之前。
对于后继分片：
●分片头部的LF字段设置为11或10，表示中间分片或最后一分片。
●fragment_offset字段则设置为当前报文小分片相对于原负载报文起始字节的偏移，需要注意的是这里的偏移是以8字节为单位的，因此每个分片的最大负载报文小分片长度也必须是8字节边界对齐的，也就是说负载报文小分片的最大长度实际上只有88字节。
当一个被分片报文的所有小分片都发送完成后datagram_tag加，当该值超过511后应该翻转为0。
对于适配层广播帧，由于节点能量和资源方面的限制，对于一个较大的负载报文的多个分片的广播给整个LowPAN网络带来严重的负担。
因此，适配层可以选择禁止对需要进行适配层广播报文（如IPv6组播报文）进行分片操作，适配层将丢弃超过其最大payload长度并且需要进行广播的负载报文。
2）重组
当适配层收到一个分片后，根据以下两个字段判断该分片是属于哪个负载报文的：
●源MAC地址
●适配层分片头部的datagram_tag字段
对于同一个负载报文的多个分片，适配层使用如下算法进行重组，其重组过程如下所示。
a.如果是第一次收到某负载报文的分片，节点记录下该被分片的源MAC地址和datagram_tag字段以供后继重组使用。
需要注意的是，这里的源MAC地址应该是适配层分片帧源发地址，若分片帧有MeshDelivery字段的话，源MAC地址应该是MeshDelivery字段中的OriginatorAddress字段。
b.若已经收到该报文的其它分片，则根据当前分片帧的fragment_offset字段进行重组。
若发现收到的是一个重复但不重叠的分片，应该使用新收到的分片进行替换。
若本分片和前后分片有重叠，则应该丢弃当前分片，这样的目的主要是简化处理，认为若出现这种情况一定是发送方出现了错误，不应该继续接收。
c.若成功收到所有分片，将所有分片按offset进行重组，并将重组好的原始负载报文递交给上层。
同时，还需要删除在步骤（a）中记录源MAC地址和datagram_tag字段信息。
重组一个分片的负载报文时需要使用一个重组队列来维护已经收到的分片以及其他一些信息（源MAC地址和datagram_tag字段）。
同时，为了避免长时间等待未达到的分片，节点还应该在收到第一个分片后启动一个重组定时器，重组超时时间为15s，定时器超时后节点应该删除该重组队列中的所有分片及相关信息。
3.组播支持
IPv6组播对IPv6协议特别是邻居发现协议有非常重要的作用。
此外，WSN的一些应用也需要MAC层的广播功能。
然而，IEEE802.15.4MAC层不支持组播仅提供有限的广播功能，这就需要适配层利用受控广播泛洪的方式来在整个LowPAN网络中传播IPv6组播报文。
1）适配层广播帧
6LowPAN使用适配层广播帧来封装IPv6组播报文或其它广播负载，格式如下所示。
在适配层广播帧中，适配层头部的B字段需要被置为1，并在适配层头部后添加一个Broadcast字段。
其中Broadcast字段的S标志位指出SourceAddress字段使用的是EUI-64地址还是16-bits短地址，BroadcastRadius字段设置为本网络指定的最大广播跳数，SequenceNumber字段设置为节点当前的广播序号计数值，SourceAddress设置为本源节点的MAC地址，负载报文将紧随在Broadcast字段之后。
2）受控广播泛洪算法
在介绍受控广播泛洪算法之前，需要先给出6LowPAN逻辑节点的概念。
运行IEEE802.15.4MAC协议的无线节点可以从硬件功能上分成全功能节点FFD（FullFunctionDevice）和部分功能节点RFD（ReduceFunctionDevice）两类。
为了从逻辑上划分各节点的不同协议行为，在适配层上将节点分为PANCoordinator、CommonCoordinator以及EndDevice三类逻辑节点。
●PANCoordinator：
只能是全功能节点（FFD），在硬件上有着较为丰富的资源，可以承担较为复杂的任务，是整个LowPAN网络的根节点。
●CommonCoordinator：
也只能是全功能节点（FFD）,同PANCoordinator相似，有着较为丰富的资源，可作为PAN内部在MAC层上的路由器，为其邻居节点转发数据。
●End Device：
可以使用全功能节点（FFD）也可以使用部分功能节点（RFD），但是一般考虑到EndDevice节点通常不需要太多的计算资源，因此通常从节点能耗方面考虑采用部分功能节点（RFD）。
适配层使用的受控广播泛洪算法来发送适配层广播帧，其算法描述如下：
源发节点或者中继节点转发适配层广播帧时，应该首先检查其适配层邻居缓存，并根据邻居缓存信息处理：
（1）若该节点的所有邻居均为PANCoordinator或者CommonCoordinator，且均为该节点的子节点时，直接用IEEE802.15.4MAC层广播该适配层广播帧。
特别的，若只有一个PANCoordinator或者CommonCoordinator的邻居且其为适配层广播帧的入口节点，不断转发适配层广播帧。
（2）若该节点的部分邻居为EndDevice或者为该节点的父节点，并且不为适配层广播帧的入口节点时，除了执行
（1）中的IEEE802.15.4MAC层广播以外，还要通过IEEE802.15.4MAC层广单播向该邻居发送该帧。
（3）若该节点的邻居均为EndDevice或该节点的父节点，并且不为适配层广播帧的入口节点时，只通过IEEE802.15.4MAC层单播向其每个邻居发送该帧。
下图即为使用受控广播泛洪算法时适配层广播帧在LowPAN网络中的传播过程。
需要注意的是该过程需要和广播风暴控制配合使用才能完成。
图受控广播泛洪
（1）
图受控广播泛洪
（2）
3）广播风暴控制
6LowPAN使用受控广播泛洪算法可以大大减少需要发送的适配层广播帧数量，但是若使用Mesh拓扑时，整个LowPAN网络拓扑中会存在大量环路。
在这种存在环路的网络中，中继节点对广播帧的重复转发将会造成严重的广播风暴。
为了避免广播风暴，每个节点需要记录已经转发过和适配层广播帧。
具体做法是节点维护一张广播记录表（BRT），每张广播记录表中有若干个广播记录项（BRE），每个广播记录项至少有SourceAddress、SequenceNumber和BroadcastValidTime（广播有效时间，BVT）三个字段，广播记录表的结构如下图所示。
图广播记录表（BRT）
当节点收到一个适配层广播帧后，首先检查Broadcast字段中的SourceAddress：
●若是本地节点地址，直接丢弃；
●若不是本地节点，根据Broadcast字段中的SourceAddress和SequenceNumber来检查本节点维护的BRT：
⏹若在BRT中找到匹配并且BVT不为0的BRE，则认为该帧已经被本地节点收到或者转发过，丢弃该广播帧；
⏹若没有找到，则认为是第一次收到该广播帧。
节点需要为其新建一个BRE（源发节点发送适配层广播帧时不需要在BRT中添加一个新的BRE），并根据Broadcast字段初始化BRE的SourceAddress和SequenceNumber两个字段，BroadcastValidTime设置为本网络指定的广播有效时间值。
同时，将Broadcast字段中的BroadcastRadius减1，若该值减到0则停止转发，否则使用受控广播泛洪算法继续转发该广播帧。
最后，将新收到的适配层广播帧递交给上层是。
特别的，对于EndDevice，可以选择不对收到的广播帧进行转发。
每个BRE中有一个BroadcastValidTime字段，该值表示现一个适配层广播帧在网络中传播的有效时间。
协议栈定时减小该值，若该值减小到0，则认为适配层广播帧已经过期并删除对应的BRE。
若此后再收到SourceAddress和SequenceNumber均相同的广播帧，节点将不再认为是重复的适配层广播帧，仍然需要为其新建BRE并进行比较。
4.头部压缩格式
由于LowPAN网络的特性，在实现IPv6在IEEE802.15.4上的头部压缩时应当考虑最少的预建上下文需求，也要求压缩方案尽量的简单直接。
目前适配层支持3种压缩格式，分别是LOWPAN_HC1格式，用于IPv6头部压缩；HC_UDP格式，用于UDP头部压缩;HC_ICMP压缩格式，用于ICMPv6压缩。
在对IPv6、UDP以及ICMP进行压缩时需要使用这3种特定的压缩格式以及编码字段，同时，适配层头部的prot_type字段应该设置为2，表示适配层头部后出现的是HC1编码字段。
1）LOWPAN_HC1格式
LOWPAN_HC1格式使用8-bits的HC1编码字段来对IPv6头部进行编码，其具体形式如下图所示。
由于IPv6头部中源地址和目的地址占了很大的空间，所以需要对地址域专门进行编码。
IPv6地址由前缀和接口标识两部分组成，如果是Link-local地址的话，则前缀默认是FE80:
:
/64并可以在头部中省去；而对于接口标识来说，由于IID是从MAC地址生成的，所以可以从IEEE802.15.4MAC帧头部或者MeshDelivery字段中的源、目的地址重新组成IID，因此在这种情况下接口标识也是可以省去的。
这样，就有如下四种可能的地址字段编码方式：
PI：
前缀在链路上传输（in-line）
PC：
前缀被压缩（默认是link_local前缀）
II：
接口标识符在链路上传输（in-line）
IC：
接口标识符被压缩（从相应的链路层地址获得）
对于IPv6头部的非压缩字段，将出现在HC1，编码字段（可能包括后继的HC2编码字段）之后，首先是不被压缩的HopLimit代字段，其它的未被压缩字段按HC1，编码字段中的顺序出现。
各个非压缩字段的出现顺序如下:
HopLimit（8bits）、SourceAddressPrefix（64bts）节and/orInterfaceIdentifier（64bits）、DestinationAddressPrefix（64bits）and/orInterfaceIdentifier（64bits）、Version（4bits）、Traffic Class（8bits）、FlowLabel（20bits）、NextHeader（8bits）。
2）HC_UDP
HC_UDP格式使用8bits的HC_UDP编码字段来对UDP头部进行编码，其具体格式如下图所示。
HC_UDP编码字段的具体格式如下：
●UDP Source Port（bit0）
0:
不压缩，在链路上传输；
1：
压缩到4bits。
实际的16-bit源端口号使用如下方法计算出来：
P+short_port。
其中P是双方预协商的一个基值，而short_port则在链路上传输的4-bit短端口号。
P是一个大于0的值，若使用该基值则Sourceport和Destinationport均使用这个基值P来进行压缩。
●UDPDestinationPort（bit1）
0:
不压缩，在链路上传输；
1：
压缩到4bits。
压缩方式同SourcePort
●Length（bit2）
0:
不压缩，在链路上传输；
1：
压缩，通过IPv6头部Length字段计算长度。
对于UDP头部的非压缩字段，将出现在IPv6头部及其相关字段之后，其未被压缩字段按原UDP头部中的顺序出现。
各个非压缩字段的出现顺序如下：
Sourceport（16bits）、Destinationport（16bits）、Length（16bits）、Checksum（16bits）。
3）HC_ICMP
HC_ICMP格式使用8bits的HC_ICMP编码字段来对ICMPv6进行编码，其具体形式如下所示：
●Type（bit0）
⏹0：
不压缩，在链路上传输
⏹1：
Type字段在HC_ICMP编码字段的CompressedType字段中指出
●Code（bit1）
⏹0：
不压缩，在链路上传输
⏹1：
Code字段为0
●Reserved（bit2）
⏹0：
该32位被全部或部分使用，不压缩，在链路上传输
⏹1：
ICMPv6报文头部后面的头32位是保留的，在这里被省去
●Compressed（bit3-7）
⏹bit3指出当前是错误报文还是信息报文（错误报文的最高位为0，而信息报文的最高位为1，所以bit3实际上对应ICMPv6头部Type字段的最高位）。
bit4到7则对应这ICMPv6Ty
升级会员 