重庆邮电大学 6LoWPAN调研报告
各个字段分析：
(1)版本号Version (4 位):取值为6，可以省略，因为所有节点都运行IPv6 协议
(2)流类型Traffic class (8 位)：可以通过压缩编码压缩； (3)流标识Flow label (20 位)：可以通过压缩编码压缩；
(4)载荷长度Payload Length (16 位)：可以省略，因为IP 头长度可以通过MAC 头中的载荷长度字段计算出来；
(5)下一个头Next Header (8 位)：可以通过压缩编码压缩，假设下一个头是UDP,ICMP, TCP或者扩展头的一种；
(6)跳极限Hop Limit (8 位)：唯一不能够进行压缩的信息；
(7)源地址Source Address(128 位)：可以进行压缩，省略掉前缀或者IID； (8)目标地址Destination Address (128 位)：可以进行压缩，省略掉前缀或者IID。 具体的压缩格式如下：
12301234567890123456789012345678901HC1 encoding[HC2 encoding(if exists)]+Non-compressed Field...图4.8
IPv6 Source IPv6 Destination V_T_FNext HeaderHC2 EncodingNon-Compressed FieldAddress(2bits)Address(2 bits) (1 bit)(2 bit) (1 bit)图4.9
综合以上分析，一个使用HC1 编码压缩的IPv6 报头由一个8 bits的HC1 编码域组成，共由五部分组成：IPv6 Source Address(2 bits)，IPv6Destination Address(2 bits)，V_T_F 整合字段(1 bit)，Next Header(2 bit)，HC2encoding(1 bit)。
由于IPv6 头部中源地址和目的地址占了很大空间，所以需要对地址域专门 进行编码。IPv6 地址由前缀和接口标识两部分组成，如果是Link-Local 地址的 话，则前缀默认是FE80::/64 并可以在头部中省去；而对于接口标识来说，由于 IID(Interface ID)是从MAC 地址生成的，所以可以从IEEE802.15.4 MAC 帧头部 或者Mesh Delivery 字段中的源、目的MAC 地址重新生成IID，因此在这种情况下接口标识也是可以省去的。这样，就有如下四种可能的地址字段编码方式: ?? PI：（Prefix carried In-line）前缀在链路(in-line)上传输
28
重庆邮电大学 6LoWPAN调研报告
?? PC：（Prefix Compressed）前缀被压缩(默认是link-local 前缀) ?? II：（Interface carried In-line）接口标识在链路上传输
?? IC：（Interface Compressed）接口标识被压缩(从相应的链路层地址获得) HC1 编码字段的具体编码格式如下： ?? IPv6 Source Address (bits 0,1) ??00：PI，II ·01：PI，IC ·10：PC，II ??11：PC，IC
?? IPv6 Destination Address (bits 2,3) ??00：PI，II ??01：PI，IC ??10：PC，II ??11：PC，IC
?? V_T_F 整合字段（Version、Traffic Class 与Flow Label 整合）(bit 4) ??0：不压缩，4 bits 的Version，8 bits 的Traffic Class 和20 bits 的
FlowLabel 都在链路上传输。将Version 与Traffic Class 和Flow Label 放在一起压缩主要是考虑到字节对齐的需要，避免出现不必要的半字节填充情况。
??1：Traffic Class 和Flow Label 均为0。 ??Next Header (bits 5, 6)
??00：不压缩，8 bits 的Next Header 在链路上传输。 ??01：UDP ??10：ICMP ??11：TCP
??HC2 Encoding (bit 7)
??0：没有后继的头部压缩编码字段。
??1：HC1 编码字段后紧跟着其它的HC2 编码字段，具体的HC2 编
码字段类型由bits 5 和6 决定。
通常在HC1 编码域之后为未压缩域。如果使用了HC2压缩编码则未压缩域位于HC2 编码之后；否则它们就位于HC1 编码域之后。在未压缩域中，以Hop Limit 为起始，如果还存在其他未压缩域都应紧跟在Hop Limit域之后。这些域的排列顺序必须与它们在HC1 编码域中相应位的顺序相同，其顺序如下所示：
01 跳数限制Hop Limit (8 bits)
29
重庆邮电大学 6LoWPAN调研报告
02 源地址前缀Source Address Prefix (64 bits) 03 源地址接口标识符Interface Identifier (64 bits) 04 目的地址前缀Destination Address Prefix (64 bits) 05 目的地址接口标识符Interface Identifier (64 bits) 06 版本号Version (4 bits)
07 通信等级Traffic Class (8 bits) 08 流量标签Flow Label (20 bits) 09 下一个报头Next Header (8 bits)
如果没有使用HC2 压缩编码，在这些未压缩域之后紧跟着的就是由原始的IPv6 报头中的Next Header 域所指示的实际下一个报头，如UDP、TCP 或者ICMP报头。按照这种压缩方式，在理想状态下使用HC1 编码能够将普通的IPv6 报头从40 字节压缩到2 字节，其中一个字节用于HC1 编码域，另一个则用于HopLimit 域。 4.4.2、HC2-UDP报头压缩
6LoWPAN 草案在对IPv6 报头使用HC1 编码压缩的同时，也为ICMP，UDP，TCP 以及将来可能出现的其它协议报头提供了HC2 编码压缩，这些协议类型由HC1 的Next Header 域指定。本实现的HC2 压缩仅支持UDP 报文。仅当HC1编码的第7 位指示后续报文使用了HC2 编码，并且其第5-6 位指示其后续报文为UDP 时才会调用HC2 编码压缩进行处理。
Source PortLengthDestination PortChecksumPayload 图4.10 UDP基本报头
位于UDP 报头中的以下域可以被压缩：源端口，目的端口和长度。UDP 的校验和字段始终都必须完整地传输。UDP 报文的长度域可以从其它报头的信息中推断，而端口域必须进行链路传输，无论其是否被压缩。 具体压缩格式如下：
12301234567890123456789012345678901HC2 encodingField carried in-line图4.11
30
重庆邮电大学 6LoWPAN调研报告
UDP Source UDP Destination LengthPort(1 bit)Port(1 bit)(1 bit)图4.12
res(5 bit)Field carried in-line紧跟在HC1 编码域之后的HC2 编码长度也为8 bits，如图所示，也由四个部分组成：UDP Source Port (1 bit)，UDP Destination Port (1 bit)，Length (1 bit)，保留字段(5 bits)。 HC2 编码的具体格式如下：
★ UDP Source Port (bit 0) ??0：不压缩，在链路上传输。
??1：压缩到4 bits。实际的16-bit 源端口号使用如下方法计算出来：
P+short_port。其中P 是双方预协商的一个基值，而short-port 则是在链路上传输的4-bit 短端口号。P 是一个大于0 的值，如果使用该基值则Source port 和Destination port 均使用这个基值P 来进行压缩。
★ UDP Destination Port (bit 1) ??0：不压缩，在链路上传输。
??1：压缩到4 bits，压缩方式同Source Port。
★ Length (bit 2) ??0：不压缩，在链路上传输
??1：压缩，通过IPv6 头部Length 字段计算长度。 ??保留字段(bit3-7)
如果设置了HC2 编码域的第0 位表示UDP 的源端口被压缩到4bit。实际 的16bit 端口号通过P+short_port 进行计算。此处P 为61616（0xF0B0）。第3-7位为保留位。
与HC1 压缩编码的处理方法类似，对于UDP 头部的非压缩字段，将出现在IPv6 头部及其相关字段之后，其未被压缩字段按其在原UDP 头部中的顺序出现。各个非压缩字段的出现顺序如下：
01 UDP 源端口号Source port（4 或16 bits） 02 UDP 目的端口号Destination port(4 或16 bits) 03 长度Length（16bist） 04 校验和Checksum（16bist）
在理想情况下，HC2 机制能够将8 字节的UDP 报头压缩到4 字节。 4.4.3、ICMP报头压缩
31
重庆邮电大学 6LoWPAN调研报告
如图4.13所示是ICMP基本报头的格式:
TypeencodingChecksumPayload 图4.13
各个字段分析： (1)
TYPE：类型字段，我们只用到4bit，就能取得所需的报文类型，可以满足本项目的报文类型要求，具体如下所示： 0000=128(PING请求) 0001=129(PING回应) 0010=133(路由器请求) 0011=134 (路由器通告) 0100-135(邻居请求) 0101=136(邻居通告) 0110保留
0111表示属于其它类型未压缩
(2)CODE：进一步区分报文的类型，在每一个TYPE类型中，继续区分子报 文类型
(3)ICMP checksum：校验和字段
因此，位于ICMP报头中的以下域可以被压缩：类型、编码。ICMP的校验和字段始终都必须完整地传输。 ICMPv6压缩报头的格式如下：
12301234567890123456789012345678901HC_ICMP encodingNon-compressed or in-line Field...图4.14
Type(4 bit)Code(4 bit)Non-compressed or in-line Field... 图4.15
32