6LowPAN的适配层Word文档格式.docx

1、适配层是整个6LowPAN的基础框架，6LowPAN的其它一些功能也是基于该框架实现的。整个适配层功能模块的示意图：2. 适配层帧格式由于LowPAN网络有报文长度小、低带宽、低功耗的特点，为了减小报文长度，适配层帧头部分为两种格式，即不分片和分片，分别用于数据部分小于MAC层MTU（102字节）的报文和大于MAC层MTU的报文。当IPv6报文要在802.15.4链路上传输时，IPv6报文需要封装在这两种格式的适配层报文中，即IPV6报文作为适配层的负载紧跟在适配层头部后面。特别地，若”M”或“B”bit被置为1时，适配层头部后面将首先出现MB或Broadcast字段，IPv6报文则出现在这两

2、个字段之后。1） 不分片报文格式不分片头部格式的各个字段含义如下： LF：链路分片（Link Fragment），占2bits。此处应为00，表示使用不分片头部格式。 prot_type：协议类型，占8bits。指出紧随在头部后的报文类型。1表示IPv6报文，2表示头部压缩编码字段。4表示路由错误报文。 M：Mesh Delivery字段标志位，占1 bit。若此位置为1，则适配层头部后紧随着的是”Mesh Delivery”字段。 B：Broadcast标志位，占1 bit。若此位置为1，则适配层头部后紧随着的是”Broadcast”字段。 rsv：保留字段，全部置为0。2） 分片报文格式若

3、一个包括适配层头部在内的完整负载报文不能够在一个单独的 IEEE 802.15.4帧中传输时，需要对负载报文进行分片，此时适配层使用分片头部格式封装数据。分片头部格式如下：分片头部格式的各个字段含义如下：当该字段不为0时，指出链路分片在整个报文中的相对位置，其中具体定义如下表所示。LF链路分片位置00不分片01第一个分片10最后一个分片11中间分片协议类型，占8 bits，该字段只在第一个链路分片中出现。 Mesh Delivery字段标志位，占1 bit。若需要在Mesh拓扑中路由，每个分片中都应该有该字段。若此位置为1，则适配层头部后紧随着的是”Broadcast”。若是广播帧，每个分片中

4、都应该有该字段。 datagram_size：负载报文的长度，占11 bits，所以支持的最大负载报文长度为2048字节，可以满足IPv6报文在IEEE 802.15.4上传输的1280字节MTU的要求。另外，在每个适配层分片中都需要携带该字段，这样能够使目的节点能在收到任何一个分片后（目的节点不一定首先收到第一个分片）确定重装后报文的大小而作一些有用的预处理，如预先分配缓冲区或者丢弃超过本节点能处理 最大字节数的报文。 datagram_tag：分片标识符，占9 bits，同一个负载报文的所有分片的datagram_tag字段应该相同。每个节点都需要维护一个变更来记录当前的datagram_

5、tag值，在节点初始化时应该将该值初始化为一个随机值（0511），每发送一个完整的负载报文（而不是一个分片）该值加1，当该值达到511后翻转为0。 fragment_offset：报文分片偏移，8 bits。该字段只出现在第二个以及后继分片中，指出后继分片中的payload相对于原负载报文的头部的偏移。该字段以8字节为单位，因此分片报文的payload必须以8字节为边界对齐。另外，由于负载报文的第一个字节偏移一定为0，所以第一个分片的fragment_offset值默认为0。3） Mesh Delivery字段4） 若适配层头部（分片或不分片格式）M字段为1，则Mesh Delivery字段紧

6、随在分片或不分片的适配层头部之后，其格式如下图所示。Mesh Delivery字段的各个字段含义如下： O：源地址类型标志位, 占1 bit，指出源地址（MAC地址）字段使用的地址是EUI-64长地址还是16-bits短地址。若此位为0表示EUI-64地址；为1表示16-bits短地址。 F：最终目的地址类型标志位, 占1 bit，指出最终目的地址字段使用的地址是EUI-64长地址还是16-bits短地址。 Hops Left：剩余跳数，占6 bits。每经过一个转发节点该值减1。若该字段值减小到0转发节点就丢弃该帧。 Originator Address：源链路层地址，可以为EUI-64地址

7、，也可以为16-bits短地址。 Final Destination Address：最终目的链路层地址，可以为EUI-64地址，也可以为16-bits短地址。5） Broadcast字段若适配层头部B字段为1，则Broadcast字段紧随在适配层头部之后，其格式如下所示。Broadcast字段的各个字段含义如下： S：广播源地址类型标志位，占1 bit。指出使用源地址是EUI-64长地址还是16-bits短地址。 Broadcast Radius：广播范围，7 bits。适配层广播帧每经过一个转发节点中继该字段值减1，若该字段减小到0转发节点停止继续转发该帧，但是本节点要将已经收到的广播帧提

8、交给上层处理。 Sequence Number：广播帧序号，8 bits。每个节点需要维护一个变量来记录当前的广播序号值，在节点初始化时将该值设为一个随机值（0255），每发送一个广播帧时将=当前变量值填入Sequence Number字段并将该值加1，当达到255后翻转为0。 Source Address：广播帧源链路层地址，可以为EUI-64地址，也可以为16-bits短地址。3.分片和重组当一个负载报文不能在一个单独的IEEE 802.15.4帧中传输时，需要对负载报文进行适配层分片。此时，适配层帧使用4字节的分片头部格式而不是2字节的不分片头部格式。另外，适配层需要维护当前的fragm

9、ent_tag值并在节点初始化时将其置为一个随机值。1） 分片当上层下传一个超过适配层最大payload长度的报文给适配层后，适配层需要对该IP报文分片进行发送。适配层分片的判断条件为：负载报文长度+不分片头部长+Mesh Delivery（或Broadcast）字段长度 IEEE 802.15.4 MAC层的最大payload长度。在使用16-bits短地址并且不使用IEEE 802.15.4安全机制的情况下，负载报文的最大长度为95（127-25（MAC头部）-2（不分片头部）-5（MD的长度）字节。适配层分片的具体过程如下所示：对于第一个分片： 将分片头部的LF字段设置为01表示是第一个

10、分片。 Prot_type字段置为上层协议的类型。若是IPv6协议该字段置为1。另外，由于是第一个分片，offset必定为0，所以在在该分片中不需要fragment_offset字段。 用当前维护的datagram_tag值来设置datagram_tag字段；datagram_size字段填写原始负载报文的总长度。 若需要在Mesh网络中路由，Mesh Delivery字段应该紧随在分片头部之后并在负载报文小分片之前。对于后继分片： 分片头部的LF字段设置为11或10，表示中间分片或最后一分片。 fragment_offset 字段则设置为当前报文小分片相对于原负载报文起始字节的偏移，需要注意

11、的是这里的偏移是以8字节为单位的，因此每个分片的最大负载报文小分片长度也必须是8字节边界对齐的，也就是说负载报文小分片的最大长度实际上只有88字节。当一个被分片报文的所有小分片都发送完成后datagram_tag加，当该值超过511后应该翻转为0。对于适配层广播帧，由于节点能量和资源方面的限制，对于一个较大的负载报文的多个分片的广播给整个LowPAN网络带来严重的负担。因此，适配层可以选择禁止对需要进行适配层广播报文（如IPv6组播报文）进行分片操作，适配层将丢弃超过其最大payload长度并且需要进行广播的负载报文。2） 重组当适配层收到一个分片后，根据以下两个字段判断该分片是属于哪个负载报

12、文的： 源MAC地址 适配层分片头部的datagram_tag字段对于同一个负载报文的多个分片，适配层使用如下算法进行重组，其重组过程如下所示。a. 如果是第一次收到某负载报文的分片，节点记录下该被分片的源MAC地址和datagram_tag字段以供后继重组使用。需要注意的是，这里的源MAC地址应该是适配层分片帧源发地址，若分片帧有Mesh Delivery字段的话，源MAC地址应该是Mesh Delivery字段中的Originator Address字段。b. 若已经收到该报文的其它分片，则根据当前分片帧的fragment_offset字段进行重组。若发现收到的是一个重复但不重叠的分片，应

13、该使用新收到的分片进行替换。若本分片和前后分片有重叠，则应该丢弃当前分片，这样的目的主要是简化处理，认为若出现这种情况一定是发送方出现了错误，不应该继续接收。c. 若成功收到所有分片，将所有分片按offset进行重组，并将重组好的原始负载报文递交给上层。同时，还需要删除在步骤（a）中记录源MAC地址和datagram_tag字段信息。重组一个分片的负载报文时需要使用一个重组队列来维护已经收到的分片以及其他一些信息（源MAC地址和datagram_tag字段）。同时，为了避免长时间等待未达到的分片，节点还应该在收到第一个分片后启动一个重组定时器，重组超时时间为15s，定时器超时后节点应该删除该重

14、组队列中的所有分片及相关信息。3. 组播支持IPv6组播对IPv6协议特别是邻居发现协议有非常重要的作用。此外，WSN的一些应用也需要MAC层的广播功能。然而，IEEE 802.15.4 MAC层不支持组播仅提供有限的广播功能，这就需要适配层利用受控广播泛洪的方式来在整个LowPAN网络中传播IPv6组播报文。1） 适配层广播帧6LowPAN使用适配层广播帧来封装IPv6组播报文或其它广播负载，格式如下所示。在适配层广播帧中，适配层头部的B字段需要被置为1，并在适配层头部后添加一个Broadcast字段。其中Broadcast字段的S标志位指出Source Address字段使用的是EUI-6

15、4地址还是16-bits短地址，Broadcast Radius字段设置为本网络指定的最大广播跳数，Sequence Number字段设置为节点当前的广播序号计数值，Source Address设置为本源节点的MAC地址，负载报文将紧随在Broadcast字段之后。2） 受控广播泛洪算法在介绍受控广播泛洪算法之前，需要先给出6LowPAN逻辑节点的概念。运行IEEE 802.15.4 MAC协议的无线节点可以从硬件功能上分成全功能节点FFD（Full Function Device）和部分功能节点RFD（Reduce Function Device）两类。为了从逻辑上划分各节点的不同协议行为，

16、在适配层上将节点分为PAN Coordinator、Common Coordinator以及End Device三类逻辑节点。 PANCoordinator：只能是全功能节点（FFD），在硬件上有着较为丰富的资源，可以承担较为复杂的任务，是整个LowPAN网络的根节点。 Common Coordinator：也只能是全功能节点（FFD）,同PAN Coordinator相似，有着较为丰富的资源，可作为PAN内部在MAC层上的路由器，为其邻居节点转发数据。 EndDevice：可以使用全功能节点（FFD）也可以使用部分功能节点（RFD），但是一般考虑到End Device节点通常不需要太多的计算

17、资源，因此通常从节点能耗方面考虑采用部分功能节点（RFD）。适配层使用的受控广播泛洪算法来发送适配层广播帧，其算法描述如下：源发节点或者中继节点转发适配层广播帧时，应该首先检查其适配层邻居缓存，并根据邻居缓存信息处理：（1） 若该节点的所有邻居均为PAN Coordinator或者Common Coordinator，且均为该节点的子节点时，直接用IEEE 802.15.4 MAC层广播该适配层广播帧。特别的，若只有一个PAN Coordinator或者Common Coordinator的邻居且其为适配层广播帧的入口节点，不断转发适配层广播帧。（2） 若该节点的部分邻居为End Device

18、或者为该节点的父节点，并且不为适配层广播帧的入口节点时，除了执行（1）中的IEEE 802.15.4 MAC层广播以外，还要通过IEEE 802.15.4 MAC层广单播向该邻居发送该帧。（3） 若该节点的邻居均为End Device或该节点的父节点，并且不为适配层广播帧的入口节点时，只通过IEEE 802.15.4 MAC层单播向其每个邻居发送该帧。下图即为使用受控广播泛洪算法时适配层广播帧在LowPAN网络中的传播过程。需要注意的是该过程需要和广播风暴控制配合使用才能完成。图 受控广播泛洪（1）图 受控广播泛洪（2）3） 广播风暴控制6LowPAN使用受控广播泛洪算法可以大大减少需要发送的

19、适配层广播帧数量，但是若使用Mesh拓扑时，整个LowPAN网络拓扑中会存在大量环路。在这种存在环路的网络中，中继节点对广播帧的重复转发将会造成严重的广播风暴。为了避免广播风暴，每个节点需要记录已经转发过和适配层广播帧。具体做法是节点维护一张广播记录表（BRT），每张广播记录表中有若干个广播记录项（BRE），每个广播记录项至少有Source Address、Sequence Number和Broadcast Valid Time（广播有效时间，BVT）三个字段，广播记录表的结构如下图所示。图 广播记录表（BRT）当节点收到一个适配层广播帧后，首先检查Broadcast字段中的Source Ad

20、dress： 若是本地节点地址，直接丢弃； 若不是本地节点，根据Broadcast字段中的Source Address和Sequence Number来检查本节点维护的BRT： 若在BRT中找到匹配并且BVT不为0的BRE，则认为该帧已经被本地节点收到或者转发过，丢弃该广播帧； 若没有找到，则认为是第一次收到该广播帧。节点需要为其新建一个BRE（源发节点发送适配层广播帧时不需要在BRT中添加一个新的BRE），并根据Broadcast字段初始化BRE的Source Address和Sequence Number两个字段，Broadcast Valid Time设置为本网络指定的广播有效时间值。同

21、时，将Broadcast字段中的Broadcast Radius减1，若该值减到0则停止转发，否则使用受控广播泛洪算法继续转发该广播帧。最后，将新收到的适配层广播帧递交给上层是。特别的，对于End Device，可以选择不对收到的广播帧进行转发。每个BRE中有一个Broadcast Valid Time字段，该值表示现一个适配层广播帧在网络中传播的有效时间。协议栈定时减小该值，若该值减小到0，则认为适配层广播帧已经过期并删除对应的BRE。若此后再收到Source Address和Sequence Number均相同的广播帧，节点将不再认为是重复的适配层广播帧，仍然需要为其新建BRE并进行比较。

22、4. 头部压缩格式由于LowPAN网络的特性，在实现IPv6在IEEE 802.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编码字段来对IP

23、v6头部进行编码，其具体形式如下图所示。由于IPv6头部中源地址和目的地址占了很大的空间，所以需要对地址域专门进行编码。IPv6地址由前缀和接口标识两部分组成，如果是Link-local地址的话，则前缀默认是FE80:/64并可以在头部中省去；而对于接口标识来说，由于IID是从MAC地址生成的，所以可以从IEEE 802.15.4MAC帧头部或者MeshDelivery字段中的源、目的地址重新组成IID，因此在这种情况下接口标识也是可以省去的。这样，就有如下四种可能的地址字段编码方式：PI：前缀在链路上传输（in-line）PC：前缀被压缩（默认是link_local前缀）II：接口标识符在链

24、路上传输（in-line）IC：接口标识符被压缩（从相应的链路层地址获得）对于IPv6头部的非压缩字段，将出现在HC1，编码字段 （可能包括后继的HC2编码字段）之后，首先是不被压缩的Hop Limit代字段，其它的未被压缩字段按HC1，编码字段中的顺序出现。各个非压缩字段的出现顺序如下:Hop Limit（8 bits）、Source Address Prefix（64bts） 节and/or Interface Identifier（64 bits）、Destination Address Prefix（64 bits） and/or Interface Identifier（64 bit

25、s）、Version（4 bits）、TrafficClass（8 bits）、Flow Label（20 bits）、Next Header（8 bits）。2） HC_UDPHC_UDP格式使用 8 bits的HC_UDP编码字段来对UDP头部进行编码，其具体格式如下图所示。HC_UDP编码字段的具体格式如下： UDPSourcePort（bit 0）0:不压缩，在链路上传输；1：压缩到4 bits。实际的16-bit源端口号使用如下方法计算出来：P+short_port。其中P是双方预协商的一个基值，而short_port则在链路上传输的4-bit短端口号。P是一个大于0的值，若使用该基

26、值则Source port和Destination port均使用这个基值P来进行压缩。 UDP Destination Port（bit 1）压缩方式同Source Port Length（bit 2）压缩，通过IPv6头部Length字段计算长度。对于UDP头部的非压缩字段，将出现在IPv6头部及其相关字段之后，其未被压缩字段按原UDP头部中的顺序出现。各个非压缩字段的出现顺序如下：Source port（16 bits）、Destination port（16 bits）、Length（16 bits）、Checksum（16 bits）。3） HC_ICMPHC_ICMP格式使用8 b

27、its的HC_ICMP编码字段来对ICMPv6进行编码，其具体形式如下所示： Type（bit 0） 0：不压缩，在链路上传输 1：Type字段在HC_ICMP编码字段的Compressed Type字段中指出 Code（bit 1）Code字段为0 Reserved（bit 2）该32位被全部或部分使用，不压缩，在链路上传输ICMPv6报文头部后面的头32位是保留的，在这里被省去 Compressed（bit 3-7） bit 3指出当前是错误报文还是信息报文（错误报文的最高位为0，而信息报文的最高位为1，所以bit 3实际上对应ICMPv6头部Type字段的最高位）。bit 4到7则对应这ICMPv6 Ty