# SCHC over LoRaWAN Efficiency: Evaluation and Experimental Performance of Packet Fragmentation
## 3 SCHC over LoRaWAN
### SCHC Fragmentation Concepts  
In LPWAN technologies, the Maximum Link-Layer Transmission Unit or MTU is of the order of 100s bytes. The small MTU size coupled with the lack of a fragmentation mechanism prevents the transport of protocols based on the Internet protocol, but the SCHC specification includes a fragmentation mechanism that allows for the transport of IPv6 packets. It also defines elements of the fragmentation mechanism, including tiles, windows, messages, and fields. Tiles are the segments that SCHC Packets are fragmented into. A group of tiles compose a window. Figure 3 illustrates this concept.  
In order to successfully transmit the tiles from the transmitter to the receiver, SCHC uses five types of messages:  
* SCHC Regular Fragments: are generally used to carry tiles that are not the last one of a SCHC Packet;
- All-1 SCHC Fragments: are used to carry the last tile of the SCHC Packet;
* SCHC ACK: message sent from the receiver to the transmitter. It is used to confirm or not confirm the reception of one or more tiles;
* SCHC ACK REQ: message sent from the transmitter to the receiver requesting the confirmation of one or more tiles through a SCHC ACK;
* SCHC Sender-Abort: message sent from the transmitter to the receiver indicating that the transmitter has canceled the transmission of fragments;
* SCHC Receiver-Abort: message sent from the receiver to the transmitter indicating to cancel the transmission of fragments.  
All messages listed above can contain one or more fields or headers. The fields or headers are the following:  
* **Rule ID**: This field is present in all messages and is used to identify whether or not a message is a SCHC Fragment;
* **Datagram Tag (DTag)**: This field uniquely identifies two fragments that belong to two different SCHC Packets. It has a length of T bits;
* **W**: When the transmitted SCHC Fragments are grouped into windows, this field carries the number of the window to which the fragment belongs. It has a length of M bits;
* **Fragment Compressed Number (FCN)**: This field indicates the sequence number of the tiles. It has a length of N bits;
* **Reassembly Check Sequence (RCS)**: This field only appears in All-1 SCHC Fragment messages. It transports the error detection code based on the CRC32 polynomial. It has a length of U bits;
* **C (Integrity Check)**: This field is 1 bit in size and is used in the SCHC ACK message to report the integrity check of the reassembled SCHC Packet. A value of 1 indicates that the integrity check was performed and was successful. A value of 0 indicates that the integrity check was not performed or that it was an error;  
Figure 3: Representation of a SCHC Packet being split into tiles and windows within the fragmentation sublayer.  
* **Compressed Bitmap**: This field appears in the SCHC ACK message to report on the receiver bitmap. The bitmap indicates which tiles were received correctly and which were not. Figure 4 shows the types of messages and headers used for the fragmentation and transmission of a SCHC Packet.  
Figure 4: Five types of SCHC messages. The SCHC Fragment is subdivided into two subtypes of messages (Regular SCHC Fragment and All-1 SCHC Fragment).