| Network Working Group | A. Minaburo |
| Internet-Draft | Acklio |
| Intended status: Informational | L. Toutain |
| Expires: January 8, 2017 | Institut MINES TELECOM ; TELECOM Bretagne |
| July 7, 2016 |
RoHC applicability in LPWAN
draft-minaburo-lpwan-rohc-applicability-00
This document makes a survey of the way to adapt the RoHC mechanisms to the LPWAN networks. It aims to show that RoHC header compression is not adapted for the constrained LPWAN networks. RoHC was defined to reduce the overhead over point-to-point connections for multimedia flows, which does not correspond to the LPWAN traffic description. RoHC is not able to reduce the use of battery and optimize the energy lifetime. If RoHC is used it will need a big effort to be adapted, there would be some problems to preserve a good transmission and packet lost will cause a context desynchronisation which implies a transmission of a complete header. LP-WAN's are different technologies covering different applications based on long range, low bandwidth and low power operation.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 8, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
LPWA (Low-Power Wide Area Network) technologies are a kind of constrained and challenged networks [RFC7228] based on a star topology where the device communicates directly with the gateway. The use of the Internet Protocol to communicate, specially the IPv6/UDP protocol stack creates a big overhead since the packet size of the LPWA technologies is no more than 200 bytes and in some technologies no more than 60 bytes. So the use of a header compression adapted to this very constrained networks is important. But RoHC as defined in [RFC4995] and [RFC5225]are not adapted to the constrained characteristics of the LPWAN networks. The adaptation will modify RoHC in such manner that it will not be compatible with the older versions, it will be so different that only the name will be the same. This document wants to show that it is better to think in a new solution than trying to adapt the older solution.
ROHC mechanism reduces the size of transmitted header by removing redundancy. ROHC mechanisms starts by classifying header fields in different classes according to their changing pattern [RFC3095]. Those fields, which are classified as inferred, are not sent, those, which are static, are sent initially and then they are not sent at all and those, which are changing, are always sent. ROHC mechanism is based on a context, which is maintained, by both ends, the compressor and the decompressor. Context keeps the entire header and ROHC’s information. Each context has a context identifier (CID), which identifies the flows. ROHC defines some profiles, which define the protocol encapsulation that will be compressed. ROHC has three operation modes: Unidirectional mode (U), Optimistic mode (O) and Reliable mode (R). The U-mode is used when the link is unidirectional or when feedback is not possible. For bi-directional links, O-mode uses positive feedback packets (ACK) and R-mode use positive and negative feedback packets (ACK and NACK). ROHC always starts header compression using U-mode even if it is used in a bi-directional link. ROHC does not make retransmission when an error occurs the wrong packet is dropped. The ROHC feedback is used only to indicate to the compressor side that there were an error and probably the context is damaged. After receiving a negative feedback compressor always reduces its compression level, which means increase the header size. ROHC compressor has three compression levels [3]: Initialization and Refresh (IR), First Order (FO) and Second Order (SO). Each compression level uses different header format packets to send the header information. In the IR compression level, it establishes the context, which contains static and dynamic header information, it is bigger than the entire header. The FO compression level gives the change pattern of dynamic fields. And, in the last compression level, SO, it sends encoded values of Sequence Number (SN) and Timestamp (TS), forming the minimal size packets. With the use of this header format packet all header fields can be generated at the other end of the link using the previously established change pattern. When some updates or errors are there, the compressor goes back to upper compression levels. It only returns to the SO compression level after retransmitting the updated information and establishing again the change pattern in the decompressor. In U-mode, the feedback channel is not used. To increase the compression level an optimistic approach is used for compressor to be sure that the context has been established at decompressor side. This means that compressor uses the same header format packet for a number of packets. As compressor does not know if context is lost it also uses two timers, to come back to FO and IR compression levels. The decompressor works at the receiving end of the link [1] and decompresses the headers based on the header fields' information of the context. Both the compressor and the decompressor use a context to store all the information about the header fields. To ensure correct decompression, the context should be always synchronized. The decompressor has three states: the first, No Context (NC), is used when there is no context synchronization, the second, Static Context (SC), is reached if the dynamic information of the context has been lost. The third, Full Context (FC), is reached when the decompressor has all the information about header fields. In FC state, the decompressor moves to the initial states as soon as it detects context damage. Decompressor uses the ‘k out of n’ rule by looking at the last n packets with CRC failures. If k CRC failures have occurred then it assumes context damage and transits backward to an initial state (SC or NC). The decompressor also sends feedback according to the operation mode.
U-mode is not only the mode where RoHC compression is initialised, it is also the only way to use RoHC in links where downlink is not available. The U-mode of RoHC is not as efficiency as the others mode of operation, because context synchronisation has to be done frequently in order to be sure that the decompressor has all the information to reestablish the header. The decompressor state machine has three states No-Context, Static-Context and Full-Context. In the beginning the state machine initialise in No-Context state where it accepts only the IR packets, once the IR packet has arrive he goes to the Full Context state where it decompresses all the format packets. When there is an error or a packet lost and the decompressor is not able to decompress the packet he goes back to Static-context state where SO packets are dropped and only FO or IR packets are decompressed. This is because when error or lost the W-LSB for the Sequence number is lost and as in the SO header format the W-LSB SN is the only information sent, so it is not capable to find the good value. So the compressor has to refresh context as soon as it believes is needed based on error rate and parameters negotiated in the link before compression.
RoHC uses a point-to-point communication with a negotiation to define the characteristics of the channel (error rate,...) and some RoHC parameters such as the size of the context identifiers, and the profiles (the header stack) will be supported for the compression in this channel. This implies to have a connection from one side to the other. The LPWAN networks do not create a channel or connection, there is not negotiation before sending any packet. Of course, RoHC accepted to do an out-of-line negotiation but in all the cases this represents a connection.
In RoHC compression transmission is done in point-to-point connection then the IP addresses could be elided in the header compression processes and it is not sent in the different RoHC's packets, this implies that the packet cannot be routed or forwarded between the 2 entities.
RoHC framework uses contexts, they are synchronised by the transmission information. So, sometimes the compression will send a complete header packet which also contains RoHC information doing the overhead larger than the one already generated by the IP stack.
The RoHC framework works with at least 15 different header formats making the average header size around 2 bytes. But in reality you will have larger packets. The RoHC framework add some compression information needed to identify the flow is sent in the packet as Padding (1 byte), Context ID (from 1 to 3 bytes), Profile (1 byte), RoHC format packet type (5 bits to 1 byte), CRC (from 3 bits to 1 byte) Therefore, in order to get the littlest header format the channel need to be stable and with a small error transmission, in order to keep the compressor in the SO of compression and that decompression does not send a negative acknowledgement in order to detect lost packets and reduce compression.
In case of error, the decompressor will send a negative acknowledge when possible and he will drop packets until he receives a complete header. This waste of energy and compression effort is very expensive for the LPWAN node which will not be enable all the time and that expects that its information arrives without confirmation.
RoHC is a very complex header compression mechanism, it was defined for wireless networks (2.5 and 3G) which use expensive radio spectrum resource and have a long RTT. The main problem solved is the use of bandwidth for multimedia applications as VoIP or VoD. in specific channels (point-to-point), where a circuit is created. The RoHC framework defines the possibility to reduce different protocols, but to be reliable, it adds a lot of 'RoHC' signalling in order to keep the context updated at both sizes (Compressor and Decompressor). To be robust it refresh information of the context regularly or when needed as the result of receiving a negative feedback. So the problem it solves is clear different from IoT. In RoHC the power and the memory are not a problem, the only important thing is to reduce the use of bandwidth that is expensive even if the node needs a lot of resources.
RoHC uses in the Unidirectional and Optimistic mode of operation a variable to bring robustness, this approach reuses the same packet format L times in order to be sure that the Decompressor has received the information. The value of this variable is not defined, it is based on the RTT, and for 3G networks it is recommended to be 3, this means that the compressor will use 3 times each format header of each compression level before augmenting the compression rate. Then each time the Decompressor lost the context or as periodically as timmers are triggered the IR packets will be sent. Creating a big overhead for the LPWAN networks.
RoHC use the RTP sequence number to control the missing packets and to reduce the header size. When there is no RTP header, RoHC generates a 16 bit Sequence Number to guarantee robustness. The sequence number is reduced by the W-LSB algorithm which manages the number of packets lost before the context needs to be synchronised. It also manages the number of SN bits to be sent, this corresponds to the packet format so the W-LSB can reduce compression in order to slight the window and continue working.
It is a function of a reference value (vref) and 'k' (number of bits in the format packet). The LSB interpretation interval function is f(vref , k) = [vref − p, vref + (2k − 1) − p]; for any 'k', the 'k' LSBs must uniquely identify a value in f(vref,k). 'p' is a shifting parameters that may be tuned for efficiency.
When RoHC was defined there were no requirements concerning the use of battery and sporadic transmission (sleeping nodes). These two LPWAN characteristics are not taking into account in the RoHC solution. The concerning was to reduce the header overhead and to adapt the robustness of the header information to the multimedia applications where most of the time they prefer to receive erroneous information than nothing at all, that's the reason why the CRC is reduced and the UDP checksum eliminate. The concern was to keep the context synchronised to loose as less as possible the application information for reducing the use of bandwidth. RoHC is not concerned for sleepy nodes or sporadic transmission, with a very little mtu's and power optimimsation.
One based characteristics of the RoHC compression is the use of flow (sequence of packets from a source to a destination), larger the flow is, better the RoHC compression performs. The RoHC mechanisms have a worse compression when there is a short flows, problems were presented for the TCP profile with shortest flows were RoHC average header size is larger than in a largest flow. The concept of flow is very important in RoHC because it takes some flow parameters to reduce the header, like the behaviour of the: sequence number and timestamp.
RoHC does not support disordering in the compressed packets. The packets need to be ordered before the compression. In reality the RoHCv1 supports 'p' packets in disordered, 'p' is the parameter of the W-LSB algorithm, in practice this represents 2 packets in advanced before enlarging the window in SO of compression and any in advance with a worst performance in the other levels of compression but only 1 packet late in the SO level of compression and no sequentially late packets at all in the other levels. RoHCv2 handles disordering because the mechanisms have flexible format packets where the needed information is sent. In the case of packet loss, RoHC reacts very different depending on the Mode of Operation used. In the Unidirectional mode any loss does not affect the compression but the decompressor could drop all the packets until an IR packet arrives when timmer is trigger. In the Optimistic and Reliable Modes, the RoHC feedback is very helpful in order to keep robustness. When needed the decompressor will ask through a feedback the synchronisation of the context.
We would like also to thanks Alexander Pelov for the positive discussions
ToDo
| [RFC3095] | Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, July 2001. |
| [RFC4995] | Jonsson, L-E., Pelletier, G. and K. Sandlund, "The RObust Header Compression (ROHC) Framework", RFC 4995, DOI 10.17487/RFC4995, July 2007. |
| [RFC5225] | Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008. |
| [RFC7228] | Bormann, C., Ersue, M. and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014. |