< draft-ietf-lpwan-schc-over-sigfox-00.txt   draft-ietf-lpwan-schc-over-sigfox-01.txt >
lpwan Working Group JC. Zuniga lpwan Working Group JC. Zuniga
Internet-Draft SIGFOX Internet-Draft SIGFOX
Intended status: Informational C. Gomez Intended status: Informational C. Gomez
Expires: October 26, 2019 Universitat Politecnica de Catalunya Expires: May 7, 2020 Universitat Politecnica de Catalunya
L. Toutain L. Toutain
IMT-Atlantique IMT-Atlantique
April 24, 2019 November 4, 2019
SCHC over Sigfox LPWAN SCHC over Sigfox LPWAN
draft-ietf-lpwan-schc-over-sigfox-00 draft-ietf-lpwan-schc-over-sigfox-01
Abstract Abstract
The Static Context Header Compression (SCHC) specification describes The Static Context Header Compression (SCHC) specification describes
a header compression scheme and a fragmentation functionality for Low a header compression scheme and a fragmentation functionality for Low
Power Wide Area Network (LPWAN) technologies. SCHC offers a great Power Wide Area Network (LPWAN) technologies. SCHC offers a great
level of flexibility that can be tailored for different LPWAN level of flexibility that can be tailored for different LPWAN
technologies. technologies.
The present document provides the optimal parameters and modes of The present document provides the optimal parameters and modes of
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 26, 2019. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Static Context Header Compression . . . . . . . . . . . . . . 3 3. Static Context Header Compression . . . . . . . . . . . . . . 3
4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 4 4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 4
4.1. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Packet processing . . . . . . . . . . . . . . . . . . . . 4 4.2. Packet processing . . . . . . . . . . . . . . . . . . . . 5
5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Fragmentation headers . . . . . . . . . . . . . . . . . . 5 5.1. Fragmentation headers . . . . . . . . . . . . . . . . . . 5
5.2. Uplink fragment transmissions . . . . . . . . . . . . . . 5 5.2. Uplink fragment transmissions . . . . . . . . . . . . . . 5
5.2.1. Uplink No-ACK mode . . . . . . . . . . . . . . . . . 5 5.2.1. Uplink No-ACK mode . . . . . . . . . . . . . . . . . 5
5.2.2. Uplink ACK-Always mode . . . . . . . . . . . . . . . 6 5.2.2. Uplink ACK-Always mode . . . . . . . . . . . . . . . 6
5.2.3. Uplink ACK-on-Error mode . . . . . . . . . . . . . . 6 5.2.3. Uplink ACK-on-Error mode . . . . . . . . . . . . . . 6
5.3. Downlink fragment transmissions . . . . . . . . . . . . . 6 5.3. Downlink fragment transmissions . . . . . . . . . . . . . 8
6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security considerations . . . . . . . . . . . . . . . . . . . 8 7. Security considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . 8 9. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The Static Context Header Compression (SCHC) specification The Static Context Header Compression (SCHC) specification
[I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression [I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression
scheme and a fragmentation functionality. Both can be used on top of scheme and a fragmentation functionality. Both can be used on top of
all the LWPAN systems defined in [RFC8376] . These LPWAN systems have all the LWPAN systems defined in [RFC8376] . These LPWAN systems have
similar characteristics such as star-oriented topologies, network similar characteristics such as star-oriented topologies, network
architecture, connected devices with built-in applications, etc. architecture, connected devices with built-in applications, etc.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
network) is a single entity that connects to all Sigfox base stations network) is a single entity that connects to all Sigfox base stations
in the world. in the world.
Uplink Sigfox transmissions occur in repetitions over different times Uplink Sigfox transmissions occur in repetitions over different times
and frequencies. Besides these time and frequency diversities, the and frequencies. Besides these time and frequency diversities, the
Sigfox network also provides space diversity, as potentially an Sigfox network also provides space diversity, as potentially an
uplink message will be received by several base stations. Since all uplink message will be received by several base stations. Since all
messages are self-contained and base stations forward them all back messages are self-contained and base stations forward them all back
to the same Core network (NGW), multiple input copies can be combined to the same Core network (NGW), multiple input copies can be combined
at the NGW and hence provide for extra reliability based on the at the NGW and hence provide for extra reliability based on the
triple diversity (i.e. time, space and frequency). A detailed triple diversity (i.e. time, space and frequency).
description of the Sigfox Radio Protocol can be found in
Downlink transmissions can only take place after an uplink
communication. A device willing to receive downlink messages
indicates so to the network in the uplink message and opens a fixed
window for reception after the uplink transmission. The delay and
duration of this reception window have fixed values. If there is a
downlink message to be sent for this given device (e.g. a response to
the uplink message or queued information), the network transmits it
during the reception window.
A detailed description of the Sigfox Radio Protocol can be found in
[sigfox-spec]. [sigfox-spec].
The NGW communicates with the Network SCHC C/D for compression/ The NGW communicates with the Network SCHC C/D + F/R for compression/
decompression and/or for fragmentation/reassembly. The Network SCHC decompression and/or for fragmentation/reassembly. The Network SCHC
C/D shares the same set of rules as the Dev SCHC C/D. The Network C/D + F/R share the same set of rules as the Dev SCHC C/D + F/R. The
SCHC C/D can be collocated with the NGW or it could be in another Network SCHC C/D + F/R can be collocated with the NGW or it could be
place, as long as a tunnel is established between the NGW and the in another place, as long as a tunnel is established between the NGW
SCHC C/D. After decompression and/or reassembly, the packet can be and the SCHC C/D + F/R functions. After decompression and/or
forwarded over the Internet to one (or several) LPWAN Application reassembly, the packet can be forwarded over the Internet to one (or
Server(s) (App). several) LPWAN Application Server(s) (App).
The SCHC C/D process is bidirectional, so the same principles can be The SCHC C/D + F/R processes are bidirectional, so the same
applied on both uplink and downlink. principles can be applied on both uplink and downlink.
4.1. SCHC Rules 4.1. SCHC Rules
The RuleID MUST be sent at the beginning of the SCHC header. The The RuleID MUST be sent at the beginning of the SCHC header. The
total number of rules to be used affects directly the Rule ID field total number of rules to be used affects directly the Rule ID field
size, and therefore the total size of the fragmentation header. For size, and therefore the total size of the fragmentation header. For
this reason, it is recommended to keep the number of rules that are this reason, it is recommended to keep the number of rules that are
defined for a specific device to the minimum possible. defined for a specific device to the minimum possible.
4.2. Packet processing 4.2. Packet processing
TBD TBD
5. Fragmentation 5. Fragmentation
The SCHC specification [I-D.ietf-lpwan-ipv6-static-context-hc] The SCHC specification [I-D.ietf-lpwan-ipv6-static-context-hc]
defines a generic fragmentation functionality that allows sending defines a generic fragmentation functionality that allows sending
data packets larger than the maximum size of a Sigfox data frame. data packets or files larger than the maximum size of a Sigfox data
frame. The functionality also defines a mechanism to send reliably
The functionality also defines a mechanism to send reliably multiple multiple messages, by allowing to resend selectively any lost
frames, by allowing to resend selectively any lost frames. fragments.
The SCHC fragmentation supports several modes of operation. These The SCHC fragmentation supports several modes of operation. These
modes have different advantages and disadvantages depending on the modes have different advantages and disadvantages depending on the
specifics of the underlying LPWAN technology and Use Case. This specifics of the underlying LPWAN technology and Use Case. This
section describes how the SCHC fragmentation functionality should section describes how the SCHC fragmentation functionality should
optimally be implemented when used over a Sigfox LPWAN for the most optimally be implemented when used over a Sigfox LPWAN for the most
typical use case applications. typical use case applications.
5.1. Fragmentation headers 5.1. Fragmentation headers
skipping to change at page 5, line 38 skipping to change at page 5, line 48
attachment, synchronization, or other procedure before transmitting a attachment, synchronization, or other procedure before transmitting a
data packet. All data packets are self contained with all the data packet. All data packets are self contained with all the
required information for the network to process them accordingly. required information for the network to process them accordingly.
Since uplink transmissions occur asynchronously, an SCHC fragment can Since uplink transmissions occur asynchronously, an SCHC fragment can
be transmitted at any given time by the Dev. be transmitted at any given time by the Dev.
5.2.1. Uplink No-ACK mode 5.2.1. Uplink No-ACK mode
No-ACK is RECOMMENDED to be used for transmitting short, non-critical No-ACK is RECOMMENDED to be used for transmitting short, non-critical
packets that require fragmentation. packets that require fragmentation and do not require full
reliability. This mode can be used by uplink-only devices that do
not support downlink communications, or by bidirectional devices when
they send non-critical data.
The recommended Fragmentation Header size is 8 bits, and it is The recommended Fragmentation Header size is 8 bits, and it is
composed as follows: composed as follows:
The recommended Rule ID size is: 2 bits The recommended Rule ID size is: 2 bits
The recommended DTag size (T) is: 2 bits The recommended DTag size (T) is: 2 bits
Fragment Compressed Number (FCN) size (N): 4 bits Fragment Compressed Number (FCN) size (N): 4 bits
As per [I-D.ietf-lpwan-ipv6-static-context-hc], in the No-ACK mode As per [I-D.ietf-lpwan-ipv6-static-context-hc], in the No-ACK mode
the W (window) field is not present. the W (window) field is not present.
When fragmentation is used to transport IP frames, the Message When fragmentation is used to transport IP frames, the Message
Integrity Check (MIC) size, M: TBD bits Integrity Check (MIC) size, M: TBD bits
When fragmentation is used to transport non-IP frames, the Message
Integrity Check (MIC) size, M: TBD bits
The algorithm for computing the MIC field MUST be TBD. The algorithm for computing the MIC field MUST be TBD.
5.2.2. Uplink ACK-Always mode 5.2.2. Uplink ACK-Always mode
TBD TBD
5.2.3. Uplink ACK-on-Error mode 5.2.3. Uplink ACK-on-Error mode
ACK-on-Error is RECOMMENDED for larger packets that need to be sent ACK-on-Error is RECOMMENDED for larger packets that need to be sent
reliably, since it leads to a reduced number of ACKs in the lower reliably. This mode is optimal for Sigfox transmissions, since it
capacity downlink channel. leads to a reduced number of ACKs in the lower capacity downlink
channel and downlink messages can be sent asynchronously and
opportunistically.
In the most generic case, the Fragmentation Header size is 8 bits and o Single-byte SCHC UL header
it is composed as follows:
The recommended Rule ID size is: 2 bits. In the most generic case, and allowing transmission of packets/files
up to 300 bytes long, the SCHC uplink Fragmentation Header size is
RECOMMENDED to be 8 bits in size and composed as follows:
The recommended DTag size (T) is: 1 bit. Rule ID size is: 2 bits.
The recommended Window (W) size is: 2 bits. DTag size (T) is: 1 bit.
Fragment Compressed Number (FCN) size (N): 3 bits. Window (W) size is: 2 bits.
For the ACK-on-Error fragmentation mode(s), a single window size is Fragment Compressed Number (FCN) size (N): 3 bits.
RECOMMENDED.
The value of MAX_ACK_REQUESTS SHOULD be 2, and the value of For the ACK-on-Error fragmentation mode(s), a single window size
MAX_WIND_FCN SHOULD be 6 (or 0b110, which allows a maximum window is RECOMMENDED.
size of 7 fragments).
When fragmentation is used to transport IP frames, the Message MAX_ACK_REQUESTS: 3.
Integrity Check (MIC) size, M: TBD bits
The algorithm for computing the MIC field MUST be TBD. MAX_WIND_FCN: 6 (or 0b110, which allows a maximum window size of 7
fragments).
Retransmission Timer: 45 sec.
Inactivity Timer: [use case dependent].
When fragmentation is used to transport IP frames, the Message
Integrity Check (MIC) size, M: TBD bits
The algorithm for computing the MIC field MUST be TBD.
The correspondent SCHC ACK in the downlink is 13 bits long, so
padding is needed to complete the required 64 bits of Sigfox payload.
o Two-byte SCHC UL header
In order to allow transmission of very large packets/files up to 2250
bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED
to be 16 bits in size and composed as follows:
Rule ID size is: 4 bits.
DTag size (T) is: 4 bit.
Window (W) size is: 3 bits.
Fragment Compressed Number (FCN) size (N): 5 bits.
For the ACK-on-Error fragmentation mode(s), a single window size
is RECOMMENDED.
MAX_ACK_REQUESTS: 3.
Retransmission Timer: 45 sec.
Inactivity Timer: [use case dependent].
When fragmentation is used to transport IP frames, the Message
Integrity Check (MIC) size, M: TBD bits
The algorithm for computing the MIC field MUST be TBD.
The correspondent SCHC ACK in the downlink is 43 bits long, so
padding is needed to complete the required 64 bits of Sigfox payload.
5.3. Downlink fragment transmissions 5.3. Downlink fragment transmissions
In some LPWAN technologies, as part of energy-saving techniques, In some LPWAN technologies, as part of energy-saving techniques,
downlink transmission is only possible immediately after an uplink downlink transmission is only possible immediately after an uplink
transmission. This allows the device to go in a very deep sleep mode transmission. This allows the device to go in a very deep sleep mode
and preserve battery, without the need to listen to any information and preserve battery, without the need to listen to any information
from the network. This is the case for Sigfox-enabled devices, which from the network. This is the case for Sigfox-enabled devices, which
can only listen to downlink communications after performing an uplink can only listen to downlink communications after performing an uplink
transmission and requesting a downlink. transmission and requesting a downlink.
skipping to change at page 9, line 11 skipping to change at page 10, line 20
and fragmentation for IPv6 and UDP", draft-ietf-lpwan- and fragmentation for IPv6 and UDP", draft-ietf-lpwan-
ipv6-static-context-hc-17 (work in progress), October ipv6-static-context-hc-17 (work in progress), October
2018. 2018.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>. <https://www.rfc-editor.org/info/rfc8376>.
[sigfox-spec] [sigfox-spec]
Sigfox, "Sigfox Radio Specifications", Sigfox, "Sigfox Radio Specifications",
<https://build.sigfox.com/ <https://build.sigfox.com/sigfox-device-radio-
sigfox-device-radio-specifications>. specifications>.
Authors' Addresses Authors' Addresses
Juan Carlos Zuniga Juan Carlos Zuniga
SIGFOX SIGFOX
425 rue Jean Rostand 425 rue Jean Rostand
Labege 31670 Labege 31670
France France
Email: JuanCarlos.Zuniga@sigfox.com Email: JuanCarlos.Zuniga@sigfox.com
 End of changes. 24 change blocks. 
46 lines changed or deleted 106 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/