## 4 IETF 6 LoWPAN Working Group (IPv6)
### Implementation and Evaluation
#### 4.2.2 Evaluation  
Very few performance evaluations of the 6 LoWPAN adaptation layer have been published thus far. The most notable performance evaluation of the 6 LoWPAN protocol was made by [23] in which the author qualitatively and quantitatively explains the advantages of 6 LoWPAN as compared to different industry standards. According to [23], in terms of memory footprint, ease of deployment, scalability, energy efficiency and other features, 6 LoWPAN has significant advantage over other standards, such as Zigbee. When analyzing 6 LoWPAN in detail, it can be seen that the adaptation layer solves many of the issue relating to supporting IPv6 on constrained devices and LLNs. One of the functions of the adaptation layer is fragmentation and reassembly. In order to fit large IPv6 packets into the small MTU of IEEE 802.15.4 networks and improve efficiency of communication, packets must be fragmented at the adaptation layer before it is passed on to the 802.15.4's MAC sublayer. Similarly, during reception, \begin{table}
\begin{tabular}{l l l l l l} \hline \hline
**Implementation** & **Operating System** & **License** & **RFC** & **RFC** & **RFC** \\  & **/Simulator** & & **4944** & **6282** & **6775** \\ \hline \hline
**SICSLOWPAN** & ContikiOS/Cooja & Open Source & X & x & x \\  & Simulator & & & & \\ \hline
**BLIP (Berkley Low-power IP)** & TinyOS & Open Source & X & & \\
**Arch Rock 6 LoWPAN** & TinyOS & Open Source & X & & \\ \hline
**NanoStack 6 lowpan** & FreeRTOS & Open Source & X & x & x \\
**Hitachi** & - & Commercial & X & & \\ \hline
**NS-3** & Simulator & Open Source & X & & \\ \hline \hline \end{tabular}
\end{table} 
Table 3: 6 LoWPAN implementations. these fragments should be reassembled at the same layer before passing them onto upper layer protocols. This approach has enabled smart objects to participate in any IPv6 based communication with some extra processing overhead. In [24], the authors attempted to test performance of 6 LoWPAN on TelosB and MikaZ motes. The authors tried to measure the impact of packet size on RTT and packet loss by increasing the packet size. As expected, the RTT increased for larger packets due to fragmentation and reassembly of packets. Both route-over and mesh-under routing mechanisms can be used in 6 LoWPAN networks. Due to fragmentation and header compression at the 6 LoWPAN adaptation layer, packets in a network that uses route-over routing have to be reassembled at every intermediate node to get the destination IP address for determining the next hop. These fragments have to go through compression and fragmentation processes before they are forwarded to the next hop router. This approach requires extra buffer space to store all fragments of a particular packet at each intermediate node. As memory is one of the constrained resources, this may not be an optimal solution for Internet of Things nodes. On the other hand, mesh-under routing may solve the issue of reassembly and fragmentation by routing the fragments independently. To the best of our knowledge, there is no performance comparison of the two routing approaches in literature. Also, no standardized solution for mesh-under routing has been proposed; as opposed to the RPL route-over routing protocol that is being defined in the IETF ROLL working group. However, examples of mesh-under routing can be found in literature, e.g., in [25]. IPv6 headers have a minimal length of 40 bytes. This is a too large overhead for the 127 byte MTU of IEEE 802.15.4 networks. 6 LoWPAN uses different mechanisms to compress IPv6 headers by removing redundant information from the headers and inferring values from the link layer information. The original compression mechanism proposed in RFC 4944, called HC1, compresses source and destination addresses by assuming that they are link local addresses. If addresses are global, they have to be sent uncompressed. This makes HC1 compression less efficient for IoT solutions which mostly involve global IPv6 addresses.