draft-ietf-lpwan-schc-over-sigfox-02.txt   draft-ietf-lpwan-schc-over-sigfox-03.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: November 16, 2020 Universitat Politecnica de Catalunya Expires: January 14, 2021 Universitat Politecnica de Catalunya
L. Toutain L. Toutain
IMT-Atlantique IMT-Atlantique
May 15, 2020 July 13, 2020
SCHC over Sigfox LPWAN SCHC over Sigfox LPWAN
draft-ietf-lpwan-schc-over-sigfox-02 draft-ietf-lpwan-schc-over-sigfox-03
Abstract Abstract
The Generic Framework for Static Context Header Compression and The Generic Framework for Static Context Header Compression and
Fragmentation (SCHC) specification describes both, an application Fragmentation (SCHC) specification describes both, an application
header compression scheme, and a frame fragmentation and loss header compression scheme, and a frame fragmentation and loss
recovery functionality for Low Power Wide Area Network (LPWAN) recovery functionality for Low Power Wide Area Network (LPWAN)
technologies. SCHC offers a great level of flexibility that can be technologies. SCHC offers a great level of flexibility that can be
tailored for different LPWAN technologies. tailored for different LPWAN technologies.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 November 16, 2020. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 31 skipping to change at page 2, line 31
4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3 4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Network Architecture . . . . . . . . . . . . . . . . . . 3 4.1. Network Architecture . . . . . . . . . . . . . . . . . . 3
4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 6
4.5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7 4.5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7
4.5.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 7 4.5.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 7
4.5.2. Downlink Fragmentation . . . . . . . . . . . . . . . 10 4.5.2. Downlink Fragmentation . . . . . . . . . . . . . . . 10
4.6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security considerations . . . . . . . . . . . . . . . . . . . 11 5. Security considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Generic Framework for Static Context Header Compression and The Generic Framework for Static Context Header Compression and
Fragmentation (SCHC) specification [RFC8724] defines both, a higher Fragmentation (SCHC) specification [RFC8724] defines both, a higher
layer header compression scheme and a fragmentation and loss recovery layer header compression scheme and a fragmentation and loss recovery
skipping to change at page 6, line 18 skipping to change at page 6, line 18
+---------------+-----------------+ +---------------+-----------------+
| Sigfox Header | Sigfox payload | | Sigfox Header | Sigfox payload |
+---------------+---------------- + +---------------+---------------- +
| SCHC message | | SCHC message |
+-----------------+ +-----------------+
Figure 2: SCHC Message in Sigfox Figure 2: SCHC Message in Sigfox
Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC
Message could be a SCHC Packet (e.g. compressed) or a SCHC Fragment Message could be a full SCHC Packet (e.g. compressed) or a SCHC
(e.g. a piece of a bigger SCHC Packet). Fragment (e.g. a piece of a bigger SCHC Packet).
4.3. Downlink 4.3. Downlink
Downlink transmissions are Device-driven and can only take place Downlink transmissions are Device-driven and can only take place
following an uplink communication. Hence, a Device willing to following an uplink communication. Hence, a Device willing to
receive downlink messages indicates so to the network in the receive downlink messages indicates so to the network in the
preceding uplink message with a downlink request flag, and then it preceding uplink message with a downlink request flag, and then it
opens a fixed window for downlink reception after the uplink opens a fixed window for downlink reception after the uplink
transmission. The delay and duration of the reception window have transmission. The delay and duration of the reception window have
fixed values. If there is a downlink message to be sent for this fixed values. If there is a downlink message to be sent for this
skipping to change at page 7, line 5 skipping to change at page 7, line 5
can be found in [sigfox-callbacks]. can be found in [sigfox-callbacks].
4.4. SCHC Rules 4.4. SCHC Rules
The RuleID MUST be included in the SCHC header. The total number of The RuleID MUST be included in the SCHC header. The total number of
rules to be used affects directly the Rule ID field size, and rules to be used affects directly the Rule ID field size, and
therefore the total size of the fragmentation header. For this therefore the total size of the fragmentation header. For this
reason, it is recommended to keep the number of rules that are 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.
RuleIDs can be used to differenciate data traffic classes (e.g. QoS,
control vs. data, etc.), and data sessions. They can also be used to
interleave simultaneous fragmentation sessions between a Device and
the Network.
4.5. Fragmentation 4.5. Fragmentation
The SCHC specification [RFC8724] defines a generic fragmentation The SCHC specification [RFC8724] defines a generic fragmentation
functionality that allows sending data packets or files larger than functionality that allows sending data packets or files larger than
the maximum size of a Sigfox data frame. The functionality also the maximum size of a Sigfox data frame. The functionality also
defines a mechanism to send reliably multiple messages, by allowing defines a mechanism to send reliably multiple messages, by allowing
to resend selectively any lost fragments. to resend selectively any lost 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 application Use specifics of the underlying LPWAN technology and application Use
Case. This section describes how the SCHC fragmentation Case. This section describes how the SCHC fragmentation
functionality should optimally be implemented when used over a Sigfox functionality should optimally be implemented when used over a Sigfox
LPWAN for the most typical Use Case applications. LPWAN for the most typical Use Case applications.
The L2 Word Size used by Sigfox is 1 byte (8 bits).
4.5.1. Uplink Fragmentation 4.5.1. Uplink Fragmentation
Sigfox uplink transmissions are completely asynchronous and can take Sigfox uplink transmissions are completely asynchronous and can take
place in any random frequency of the allowed uplink bandwidth place in any random frequency of the allowed uplink bandwidth
allocation. Hence, devices can go to deep sleep mode, and then wake allocation. Hence, devices can go to deep sleep mode, and then wake
up and transmit whenever there is a need to send any information to up and transmit whenever there is a need to send any information to
the network. In that way, there is no need to perform any network the network. In that way, there is no need to perform any network
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.
skipping to change at page 7, line 46 skipping to change at page 8, line 5
Tile. Tile.
4.5.1.1. Uplink No-ACK Mode 4.5.1.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 and do not require full packets that require fragmentation and do not require full
reliability. This mode can be used by uplink-only devices that do reliability. This mode can be used by uplink-only devices that do
not support downlink communications, or by bidirectional devices when not support downlink communications, or by bidirectional devices when
they send non-critical data. they send non-critical data.
Since there are no multiple windows in the No-ACK mode, the W bit is
not present. However it is RECOMMENDED to use FCN to indicate the
size of the data packet. In this sense, the data packet would need
to be splitted into X fragments and, similarly to the other
fragmentation modes, the first transmitted fragment would need to be
marked with FCN = X-1. Consecutive fragments MUST be marked with
decreasing FCN values, having the last fragment marked with FCN =
(All-1). Hence, even though the No-ACK mode does not allow
recovering missing fragments, it allows indicating implicitly to the
Network the size of the expected packet and whether all fragments
have been received or not.
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:
o RuleID size: 4 bits o RuleID size: 4 bits
o DTag size (T): 0 bits o DTag size (T): 0 bits
o Fragment Compressed Number (FCN) size (N): 4 bits o Fragment Compressed Number (FCN) size (N): 4 bits
o As per [RFC8724], in the No-ACK mode the W (window) field is not o As per [RFC8724], in the No-ACK mode the W (window) field is not
present. present.
o RCS: Not used o RCS: Not used
4.5.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header 4.5.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header
ACK-on-Error with single-byte header is RECOMMENDED for medium-large ACK-on-Error with single-byte header is RECOMMENDED for medium-large
 End of changes. 10 change blocks. 
7 lines changed or deleted 27 lines changed or added

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