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
Abstract
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.
Status of This Memo
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 Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Minaburo & Toutain Expires January 8, 2017 [Page 1]
Internet-Draft RoHC Applicability in LPWAN July 2016
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.
1. Introduction
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.
2. RoHC Compression
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
Minaburo & Toutain Expires January 8, 2017 [Page 2]
Internet-Draft RoHC Applicability in LPWAN July 2016
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.
2.1. Unidirectional 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
Minaburo & Toutain Expires January 8, 2017 [Page 3]
Internet-Draft RoHC Applicability in LPWAN July 2016
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.
3. Applicability
3.1. Connection
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.
3.2. The IP address compression
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.
3.3. Framework
3.3.1. Contexts
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.
Minaburo & Toutain Expires January 8, 2017 [Page 4]
Internet-Draft RoHC Applicability in LPWAN July 2016
3.3.2. Header format packets
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.
3.3.3. Context Synchronisation
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.
3.3.4. Complexity
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.
3.3.5. L variable or optimistic approach
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
Minaburo & Toutain Expires January 8, 2017 [Page 5]
Internet-Draft RoHC Applicability in LPWAN July 2016
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.
3.3.6. Sequence Number (SN)
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.
3.3.7. LSB Window (W-LSB)
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.
3.4. Resources Usability
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.
3.5. Flow
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
Minaburo & Toutain Expires January 8, 2017 [Page 6]
Internet-Draft RoHC Applicability in LPWAN July 2016
reduce the header, like the behaviour of the: sequence number and
timestamp.
3.6. Packet loss and reordering
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.
4. Acknowledgements
We would like also to thanks Alexander Pelov for the positive
discussions
5. Annex A -- Example
ToDo
6. Normative References
[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, <http://www.rfc-editor.org/info/rfc3095>.
[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust
Header Compression (ROHC) Framework", RFC 4995,
DOI 10.17487/RFC4995, July 2007,
<http://www.rfc-editor.org/info/rfc4995>.
Minaburo & Toutain Expires January 8, 2017 [Page 7]
Internet-Draft RoHC Applicability in LPWAN July 2016
[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,
<http://www.rfc-editor.org/info/rfc5225>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
Authors' Addresses
Ana Minaburo
Acklio
2bis rue de la Chataigneraie
35510 Cesson-Sevigne Cedex
France
Email: ana@ackl.io
Laurent Toutain
Institut MINES TELECOM ; TELECOM Bretagne
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
Email: Laurent.Toutain@telecom-bretagne.eu
Minaburo & Toutain Expires January 8, 2017 [Page 8]