Internet-Draft SCHC Streaming Mode May 2023
Aguilar & Gomez Expires 12 November 2023 [Page]
Workgroup:
schc Working Group
Internet-Draft:
draft-aguilar-schc-streaming-00
Updates:
8724 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
S. Aguilar
Universitat Politecnica de Catalunya
C. Gomez
Universitat Politecnica de Catalunya

SCHC Streaming Mode

Abstract

This documents presents an update of SCHC [RFC8724] by providing a new F/R mode called SCHC Streaming mode.

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 https://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 12 November 2023.

▲

Table of Contents

1. Introduction

SCHC [RFC8724] provides Fragmentation/Reassembly (F/R) modes, i.e., No-ACK, ACK-Always and ACK-on-Error. These modes allow for SCHC Packets larger than the Maximum Transmission Unit (MTU) of the underlying Layer 2 (L2) to be transferred between the sender and receiver with a range of reliability options, including SCHC Fragment retransmissions, over delay tolerant networks. The available F/R modes allow transmitting non-fragmented SCHC Packets concurrently with fragmented SCHC Fragments, and SCHC Packet interleaving. However, SCHC does not provide an optimal F/R mode for a continuous transmission of un-fragmented SCHC Packets, i.e, streaming of SCHC Packets smaller than, or of the same size as, the L2 MTU.

The streaming of SCHC Packets can be used to send, e.g., sensor measurements or the location coordinates of an asset tracker, which are sent every number of minutes and are optimized to fit in only one SCHC Fragment, with or without SCHC Compression. These SCHC Packets may not require fragmentation but require reliability, as some fragment losses may be incurred due to intermittent connectivity (e.g., vehicles going into tunnels, no coverage areas) or opportunistic coverage (e.g., coverage is available for certain time windows, of duration and frequency that might not be deterministic). With current SCHC F/R modes, each sensor measurement or location information can be sent as a compressed or un-compressed SCHC Packet, with different reliability options, however, each SCHC Packet will require a SCHC ACK, even if it is of only one SCHC Fragment in size. In networks, e.g., LPWANs [RFC8376], the downlink traffic or network capacity may be limited. [I.D.Compound ACK] provides an optimization in the ACK traffic by grouping the feedback of several windows of tiles in the same ACK message, providing flexibility on when the receiver sends feedback.

The present document extends [RFC8724] with a new F/R mode called SCHC Streaming. This F/R mode optimized the overhead of current F/R modes for a contiuos streaming of compressed or un-compressed SCHC Packets which require one SCHC Fragment to be transferred. The SCHC Streaming mode provides different configuration option on when the receiver can provide feedback, therefore adapting to the specifics of each network, e.g., the amount of ACK traffic that can be supported, application delay tolerance, L2 MTU size and the maximum number of window bitmaps that can be carried in a SCHC Compound ACK.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

It is assumed that the reader is familiar with the terms and mechanisms defined in [RFC8376] and in [RFC8724], specially Section 8.

3. SCHC Streaming

The SCHC Streaming mode supports L2 technologies that have variable MTU and out-of-order delivery (to some extent). It requires an L2 that provides a feedback path from the reassembler to the fragmenter.

SCHC Streaming mode uses windows, with all tiles, except for the last one, of equal size (regular size). The last tile MAY be smaller or equal to a regular tile.

A SCHC Fragment carries one or several contiguous tiles, which may span multiple windows from the same DTag value. A SCHC Compound ACK reports on the reception of one window of tiles or several windows of tiles, each one identified by its window number and corresponding to the same DTag value.

Each Profile, for each RuleID value, MUST define:

For each active RuleID value, the sender MUST maintain:

For each active RuleID value, the receiver MUST maintain:

3.1. Transfer Cycles

In SCHC Streaming mode the flow of tiles is continuous and it is divided into cycles. There are two cycles, the Window Cycle and the DTag Cycle (see Figure 1). To uniquely identify each tile, a combination of DTag, Window Number and FCN is used in each DTag Cycle.



              +---------------------------------------------...-----------....----...
              |               SCHC Streaming flow of SCHC Packets
              +---------------------------------------------...-----------...-----...

Tile#         | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | ... | 0 | 4 | ... | 0 |...
Window#       |-------- 0 --------|-------- 1 --------|- 0  ...  1 -|- 0  ...  1 -|...
DTag#         |-------------------- 0 ----------------|----- 1 -----|----- 0 -----|...

Window Cycle# |---------------------0-----------------|------1------|------0------|...
DTag Cycle#   |-------------------------------0---------------------|------1------|...
              ^                                       ^             ^
              |                                       |             |
             Window Cycle 0 start            Window Cycle 0 ends    |
              ^                                                     |
              |                                                     |
             DTag Cycle 0 start                              DTag Cycle 0 ends
Figure 1: SCHC Packets streaming carried in Tiles and Windows using the SCHC Streaming Mode. M = 1 bit (Window Cycle of 2 Windows) and DTag = 1 bit (DTag Cycle of 2 Window Cycles, i.e., 4 Windows)

The sender will begin the first DTag and Window Cycle by sending tiles using DTag = 0 and Window Number = 0 (the tile index, i.e., the FCN, MUST be decremented by 1 from WINDOW_SIZE - 1 downward). After each window of tiles, the Window Number is increased. Current Window Cycle ends once the Window Number reaches its maximum value and the last fragment of this window is sent. Next Window Cycle will begin by increasing the DTag value by one, and resetting the Window Number and FCN values. The number of Window Cycles without repeating the same DTag, Window Number and FCN value depends on the size of the DTag field, which determines the DTag Cycle. After the DTag reaches its maximum value, and therefore the end of the DTag Cycle, it MUST be reset. To manage the receiver feedback, the Receiver MUST send at least one SCHC Compound ACK per DTag Cycle, i.e., before the DTag is reset, indicating tiles losses in any of previous Window Cycles corresponding to this DTag Cycle. Only one Window Cycle MUST be reported per SCHC Compound ACK. The SCHC Compound ACK MUST be sent before the start of a new DTag Cycle. SCHC Fragments MAY be delivered out-of-order in each DTag Cycle, but all tiles MUST be received before advancing to the next DTag Cycle.

The SCHC All-1 message is used to finalize current SCHC Streaming session in case it is needed.

3.2. ACK Behaviour

A SCHC Compound ACK MAY be sent after the All-0 SCHC Fragment message and MUST be sent after the All-1 SCHC Fragment message. This allows the receiver to provide feedback after any window of tiles. The Profile MUST specify when the sender should listen for a SCHC Compound ACK, specially in networks which require the sender to enable reception of incoming SCHC ACKs. The sender MAY listen after each complete window of tiles (the All-0 message in each window), after the All-0 of the last window of each Window Cycle or after the All-0 of the last window of each DTag Cycle.

The receiver can send SCHC Compound ACKs:

  • at the end of each Window Cycle, in the last window (with the maximum window number), an All-0 message indicates the end of current window, and as it is the last window of current Window Cycle, it indicates the end of current Window Cycle. The receiver MAY send a SCHC Compound ACK. Note that after this Window Cycle ends, the receiver MAY request fragments of previous DTag values (before the DTag Cycle ends).
  • A success SCHC ACK MUST be sent by the receiver at the end of each DTag Cycle, to acknowledge all SCHC Fragment before continuing to next DTag Cycle. Note that after a new DTag Cycle begins, it is not possible to recover SCHC Fragment from previous DTag Cycles, as the combination of DTag, Window Number and FCN is repeated.

4. SCHC Streaming mode examples

This section provides examples of the SCHC Streaming mode. The configuration used in these examples is as follows:

In Figure 2, a SCHC Streaming transmission example is shown. In this transmission, the first 3 windows have fragment losses. The fourth window has no fragment losses. The receiver sends a SCHC Compound ACK reporting on the fragment losses of the first 3 windows, after receiving the All-0 message that signal the end of current Window Cycle, i.e., the All-0 message of the fourth window. The sender resends the missing fragments and continues to next Window Cycle by increasing the DTag value.

Next Window Cycle present fragment losses that are recovered at the end of the cycle, as the receiver sends a SCHC Compound ACK message after receiving the All-0 message. The sender resends the missing fragment, and as it is the end of the DTag Cycle, a success ACK is sent by the receiver to continue the transmission in the next DTag Cycle.

  Sender                         Receiver
  |-----DTag= 0, W=0, FCN=6 ----->|
  |-----DTag= 0, W=0, FCN=5 ----->|
  |-----DTag= 0, W=0, FCN=4 ----->|
  |-----DTag= 0, W=0, FCN=3 ----->|
  |-----DTag= 0, W=0, FCN=2 --X   |
  |-----DTag= 0, W=0, FCN=1 ----->|
  |-----DTag= 0, W=0, FCN=0 ----->| Bitmap: 1111011
(no ACK)
  |-----DTag= 0, W=1, FCN=6 ----->|
  |-----DTag= 0, W=1, FCN=5 ----->|
  |-----DTag= 0, W=1, FCN=4 ----->|
  |-----DTag= 0, W=1, FCN=3 ----->|
  |-----DTag= 0, W=1, FCN=2 ----->|
  |-----DTag= 0, W=1, FCN=1 --X   |
  |-----DTag= 0, W=1, FCN=0 ----->| Bitmap: 1111101
(no ACK)
  |-----DTag= 0, W=2, FCN=6 ----->|
  |-----DTag= 0, W=2, FCN=5 --X   |
  |-----DTag= 0, W=2, FCN=4 ----->|
  |-----DTag= 0, W=2, FCN=3 ----->|
  |-----DTag= 0, W=2, FCN=2 ----->|
  |-----DTag= 0, W=2, FCN=1 ----->|
  |-----DTag= 0, W=2, FCN=0 ----->| Bitmap: 1011111
(no ACK)
  |-----DTag= 0, W=3, FCN=6 ----->|
  |-----DTag= 0, W=3, FCN=5 ----->|
  |-----DTag= 0, W=3, FCN=4 ----->|
  |-----DTag= 0, W=3, FCN=3 ----->|
  |-----DTag= 0, W=3, FCN=2 ----->|
  |-----DTag= 0, W=3, FCN=1 ----->|
  |-----DTag= 0, W=2, FCN=0 ----->| Bitmap: 1111111
  |<--- DTag= 0, Compound ACK ----| [C=0, W=0 - Bitmap:1111011, W=1 - Bitmap:1111101, W=2 - Bitmap:1011111]
  |-----DTag= 0, W=0, FCN=2 ----->|
  |-----DTag= 0, W=1, FCN=1 ----->|
  |-----DTag= 0, W=2, FCN=5 ----->|
(next Window Cycle)
  |-----DTag= 1, W=0, FCN=6 ----->|
  |-----DTag= 1, W=0, FCN=5 ----->|
  |-----DTag= 1, W=0, FCN=4 ----->|
  |-----DTag= 1, W=0, FCN=3 ----->|
  |-----DTag= 1, W=0, FCN=2 --X   |
  |-----DTag= 1, W=0, FCN=1 ----->|
  |-----DTag= 1, W=0, FCN=0 ----->| Bitmap: 1111011
(no ACK)
  |-----DTag= 1, W=1, FCN=6 ----->|
  |-----DTag= 1, W=1, FCN=5 ----->|
  |-----DTag= 1, W=1, FCN=4 ----->|
  |-----DTag= 1, W=1, FCN=3 ----->|
  |-----DTag= 1, W=1, FCN=2 ----->|
  |-----DTag= 1, W=1, FCN=1 --X   |
  |-----DTag= 1, W=1, FCN=0 ----->| Bitmap: 1111101
(no ACK)
  |-----DTag= 1, W=2, FCN=6 ----->|
  |-----DTag= 1, W=2, FCN=5 --X   |
  |-----DTag= 1, W=2, FCN=4 ----->|
  |-----DTag= 1, W=2, FCN=3 ----->|
  |-----DTag= 1, W=2, FCN=2 ----->|
  |-----DTag= 1, W=2, FCN=1 ----->|
  |-----DTag= 1, W=2, FCN=0 ----->| Bitmap: 1011111
(no ACK)
  |-----DTag= 1, W=3, FCN=6 ----->|
  |-----DTag= 1, W=3, FCN=5 ----->|
  |-----DTag= 1, W=3, FCN=4 ----->|
  |-----DTag= 1, W=3, FCN=3 ----->|
  |-----DTag= 1, W=3, FCN=2 ----->|
  |-----DTag= 1, W=3, FCN=1 ----->|
  |-----DTag= 1, W=3, FCN=0 ----->| Bitmap: 1011111
  |<--- DTag= 1, Compound ACK ----| [C=0, W=0 - Bitmap:1111011, W=1 - Bitmap:1111101, W=2 - Bitmap:1011111]
  |-----DTag= 1, W=0, FCN=2 ----->|
  |-----DTag= 1, W=1, FCN=1 ----->|
  |-----DTag= 1, W=2, FCN=5 ----->|
  |<--- DTag= 1, ACK, W=3, C=1 ---| C=1 [success ACK is needed before moving to next DTag cycle]
(next Window and DTag Cycle)
Figure 2: SCHC Streaming mode sequence example 1

Figure 3 shows another example of SCHC Streaming mode where a SCHC Compound ACK is sent at the ending of the DTag Cycle, recovering SCHC Fragment losses of previous windows of the DTag Cycle. As both Window Cycles present SCHC Fragment losses, two SCHC Compound ACKs are sent by the receiver at the end of the DTag Cycle.

    Sender                         Receiver
    |-----DTag= 0, W=0, FCN=6 ----->|
    |-----DTag= 0, W=0, FCN=5 ----->|
    |-----DTag= 0, W=0, FCN=4 ----->|
    |-----DTag= 0, W=0, FCN=3 ----->|
    |-----DTag= 0, W=0, FCN=2 --X   |
    |-----DTag= 0, W=0, FCN=1 ----->|
    |-----DTag= 0, W=0, FCN=0 ----->| Bitmap: 1111011
(no ACK)
    |-----DTag= 0, W=1, FCN=6 ----->|
    |-----DTag= 0, W=1, FCN=5 ----->|
    |-----DTag= 0, W=1, FCN=4 ----->|
    |-----DTag= 0, W=1, FCN=3 ----->|
    |-----DTag= 0, W=1, FCN=2 ----->|
    |-----DTag= 0, W=1, FCN=1 --X   |
    |-----DTag= 0, W=1, FCN=0 ----->| Bitmap: 1111101
(no ACK)
    |-----DTag= 0, W=2, FCN=6 ----->|
    |-----DTag= 0, W=2, FCN=5 --X   |
    |-----DTag= 0, W=2, FCN=4 ----->|
    |-----DTag= 0, W=2, FCN=3 ----->|
    |-----DTag= 0, W=2, FCN=2 ----->|
    |-----DTag= 0, W=2, FCN=1 ----->|
    |-----DTag= 0, W=2, FCN=0 ----->| Bitmap: 1011111
(no ACK)
    |-----DTag= 0, W=3, FCN=6 ----->|
    |-----DTag= 0, W=3, FCN=5 ----->|
    |-----DTag= 0, W=3, FCN=4 ----->|
    |-----DTag= 0, W=3, FCN=3 ----->|
    |-----DTag= 0, W=3, FCN=2 ----->|
    |-----DTag= 0, W=3, FCN=1 ----->|
    |-----DTag= 0, W=2, FCN=0 ----->| Bitmap: 1011111
(no ACK)

(next Window Cycle)
    |-----DTag= 1, W=0, FCN=6 ----->|
    |-----DTag= 1, W=0, FCN=5 ----->|
    |-----DTag= 1, W=0, FCN=4 ----->|
    |-----DTag= 1, W=0, FCN=3 ----->|
    |-----DTag= 1, W=0, FCN=2 --X   |
    |-----DTag= 1, W=0, FCN=1 ----->|
    |-----DTag= 1, W=0, FCN=0 ----->| Bitmap: 1111011
(no ACK)
    |-----DTag= 1, W=1, FCN=6 ----->|
    |-----DTag= 1, W=1, FCN=5 ----->|
    |-----DTag= 1, W=1, FCN=4 ----->|
    |-----DTag= 1, W=1, FCN=3 ----->|
    |-----DTag= 1, W=1, FCN=2 ----->|
    |-----DTag= 1, W=1, FCN=1 --X   |
    |-----DTag= 1, W=1, FCN=0 ----->| Bitmap: 1111101
(no ACK)
    |-----DTag= 1, W=2, FCN=6 ----->|
    |-----DTag= 1, W=2, FCN=5 --X   |
    |-----DTag= 1, W=2, FCN=4 ----->|
    |-----DTag= 1, W=2, FCN=3 ----->|
    |-----DTag= 1, W=2, FCN=2 ----->|
    |-----DTag= 1, W=2, FCN=1 ----->|
    |-----DTag= 1, W=2, FCN=0 ----->| Bitmap: 1011111
(no ACK)
    |-----DTag= 1, W=3, FCN=6 ----->|
    |-----DTag= 1, W=3, FCN=5 ----->|
    |-----DTag= 1, W=3, FCN=4 ----->|
    |-----DTag= 1, W=3, FCN=3 ----->|
    |-----DTag= 1, W=3, FCN=2 ----->|
    |-----DTag= 1, W=3, FCN=1 ----->|
    |-----DTag= 1, W=3, FCN=0 ----->| Bitmap: 1111111

    |<--- DTag= 0, Compound ACK ----| [C=0, W=0 - Bitmap:1111011, W=1 - Bitmap:1111101, W=2 - Bitmap:1011111]
    |-----DTag= 0, W=0, FCN=2 ----->|
    |-----DTag= 0, W=1, FCN=1 ----->|
    |-----DTag= 0, W=2, FCN=5 ----->|

    |<--- DTag= 1, Compound ACK ----| [C=0, W=0 - Bitmap:1111011, W=1 - Bitmap:1111101, W=2 - Bitmap:1011111]
    |-----DTag= 1, W=0, FCN=2 ----->|
    |-----DTag= 1, W=1, FCN=1 ----->|
    |-----DTag= 1, W=2, FCN=5 ----->|

    |<--- DTag= 1, ACK, W=3, C=1 ---| C=1 success ACK is needed before moving to next DTag cycle
(next Window and DTag Cycle)
Figure 3: SCHC Streaming mode sequence example 2

Figure 4 presents a SCHC Streaming transmission that is closed by the sender using an All-1 message. After the All-1 message, the receiver sends a SCHC Compound ACKs for missing fragments. The sender resends missing fragments and waits for a success SCHC ACK indicating that all SCHC Fragments were correctly received and that current SCHC Streaming transmission can be closed.

      Sender                         Receiver
      |-----DTag= 0, W=0, FCN=6 ----->|
      |-----DTag= 0, W=0, FCN=5 ----->|
      |-----DTag= 0, W=0, FCN=4 ----->|
      |-----DTag= 0, W=0, FCN=3 ----->|
      |-----DTag= 0, W=0, FCN=2 --X   |
      |-----DTag= 0, W=0, FCN=1 ----->|
      |-----DTag= 0, W=0, FCN=0 ----->| Bitmap: 1111011
  (no ACK)
      |-----DTag= 0, W=1, FCN=6 ----->|
      |-----DTag= 0, W=1, FCN=5 ----->|
      |-----DTag= 0, W=1, FCN=4 ----->|
      |-----DTag= 0, W=1, FCN=3 ----->|
      |-----DTag= 0, W=1, FCN=2 ----->|
      |-----DTag= 0, W=1, FCN=1 --X   |
      |-----DTag= 0, W=1, FCN=0 ----->| Bitmap: 1111101
  (no ACK)
      |-----DTag= 0, W=2, FCN=6 ----->|
      |-----DTag= 0, W=2, FCN=5 --X   |
      |-----DTag= 0, W=2, FCN=4 ----->|
      |-----DTag= 0, W=2, FCN=3 ----->|
      |-----DTag= 0, W=2, FCN=2 ----->|
      |-----DTag= 0, W=2, FCN=1 ----->|
      |-----DTag= 0, W=2, FCN=0 ----->| Bitmap: 1011111
  (no ACK)
      |-----DTag= 0, W=3, FCN=6 ----->|
      |-----DTag= 0, W=3, FCN=5 ----->|
      |-----DTag= 0, W=3, FCN=4 ----->|
      |-----DTag= 0, W=3, FCN=3 ----->|
      |-----DTag= 0, W=3, FCN=2 ----->|
      |-----DTag= 0, W=3, FCN=1 ----->|
      |-----DTag= 0, W=2, FCN=0 ----->| Bitmap: 1011111
  (no ACK)

  (next Window Cycle)
      |-----DTag= 1, W=0, FCN=6 ----->|
      |-----DTag= 1, W=0, FCN=5 ----->|
      |-----DTag= 1, W=0, FCN=4 ----->|
      |-----DTag= 1, W=0, FCN=3 ----->|
      |-----DTag= 1, W=0, FCN=2 --X   |
      |-----DTag= 1, W=0, FCN=1 ----->|
      |-----DTag= 1, W=0, FCN=0 ----->| Bitmap: 1111011
  (no ACK)
      |-----DTag= 1, W=1, FCN=6 ----->|
      |-----DTag= 1, W=1, FCN=5 ----->|
      |-----DTag= 1, W=1, FCN=4 ----->|
      |-----DTag= 1, W=1, FCN=3 ----->|
      |-----DTag= 1, W=1, FCN=2 ----->|
      |-----DTag= 1, W=1, FCN=1 --X   |
      |-----DTag= 1, W=1, FCN=0 ----->| Bitmap: 1111101
  (no ACK)
      |-----DTag= 1, W=2, FCN=6 ----->|
      |-----DTag= 1, W=2, FCN=5 --X   |
      |-----DTag= 1, W=2, FCN=4 ----->|
      |-----DTag= 1, W=2, FCN=3 ----->|
      |-----DTag= 1, W=2, FCN=2 ----->|
      |-----DTag= 1, W=2, FCN=1 ----->|
      |-----DTag= 1, W=2, FCN=0 ----->| Bitmap: 1011111
  (no ACK)
      |-----DTag= 1, W=3, FCN=6 ----->|
      |--DTag= 1, W=3, FCN=7, RCS --->| All-1, Bitmap: 1011111

      |<--- DTag= 0, Compound ACK ----| [C=0, W=0 - Bitmap:1111011, W=1 - Bitmap:1111101, W=2 - Bitmap:1011111]
      |-----DTag= 0, W=0, FCN=2 ----->|
      |-----DTag= 0, W=1, FCN=1 ----->|
      |-----DTag= 0, W=2, FCN=5 ----->|

      |<--- DTag= 1, Compound ACK ----| [C=0, W=0 - Bitmap:1111011, W=1 - Bitmap:1111101, W=2 - Bitmap:1011111]
      |-----DTag= 1, W=0, FCN=2 ----->|
      |-----DTag= 1, W=1, FCN=1 ----->|
      |-----DTag= 1, W=2, FCN=5 ----->|

      |<--- DTag= 1, ACK, W=3, C=1 ---| C=1
Figure 4: SCHC Streaming mode sequence example 3 - Closed by sender

Figure 5 shows a SCHC Streaming example where the receiver aborts current transmission.

  Sender                         Receiver
  |-----DTag= 0, W=0, FCN=6 ----->|
  |-----DTag= 0, W=0, FCN=5 ----->|
  |-----DTag= 0, W=0, FCN=4 ----->|
  |-----DTag= 0, W=0, FCN=3 ----->|
  |-----DTag= 0, W=0, FCN=2 --X   |
  |-----DTag= 0, W=0, FCN=1 ----->|
  |-----DTag= 0, W=0, FCN=0 ----->| Bitmap: 1111011
(no ACK)
  |-----DTag= 0, W=1, FCN=6 ----->|
  |-----DTag= 0, W=1, FCN=5 ----->|
  |-----DTag= 0, W=1, FCN=4 ----->|
  |-----DTag= 0, W=1, FCN=3 ----->|
  |-----DTag= 0, W=1, FCN=2 ----->|
  |-----DTag= 0, W=1, FCN=1 --X   |
  |-----DTag= 0, W=1, FCN=0 ----->| Bitmap: 1111101
(no ACK)
  |-----DTag= 0, W=2, FCN=6 ----->|
  |-----DTag= 0, W=2, FCN=5 --X   |
  |-----DTag= 0, W=2, FCN=4 ----->|
  |-----DTag= 0, W=2, FCN=3 ----->|
  |-----DTag= 0, W=2, FCN=2 ----->|
  |-----DTag= 0, W=2, FCN=1 ----->|
  |-----DTag= 0, W=2, FCN=0 ----->| Bitmap: 1011111
(no ACK)
  |-----DTag= 0, W=3, FCN=6 ----->|
  |-----DTag= 0, W=3, FCN=5 ----->|
  |-----DTag= 0, W=3, FCN=4 ----->|
  |-----DTag= 0, W=3, FCN=3 ----->|
  |-----DTag= 0, W=3, FCN=2 ----->|
  |-----DTag= 0, W=3, FCN=1 ----->|
  |-----DTag= 0, W=2, FCN=0 ----->| Bitmap: 1011111
(no ACK)

(next Window Cycle)
  |-----DTag= 1, W=0, FCN=6 ----->|
  |-----DTag= 1, W=0, FCN=5 ----->|
  |-----DTag= 1, W=0, FCN=4 ----->|
  |-----DTag= 1, W=0, FCN=3 ----->|
  |-----DTag= 1, W=0, FCN=2 --X   |
  |-----DTag= 1, W=0, FCN=1 ----->|
  |-----DTag= 1, W=0, FCN=0 ----->| Bitmap: 1111011
(no ACK)
  |-----DTag= 1, W=1, FCN=6 ----->|
  |-----DTag= 1, W=1, FCN=5 ----->|
  |-----DTag= 1, W=1, FCN=4 ----->|
  |-----DTag= 1, W=1, FCN=3 ----->|
  |-----DTag= 1, W=1, FCN=2 ----->|
  |-----DTag= 1, W=1, FCN=1 --X   |
  |-----DTag= 1, W=1, FCN=0 ----->| Bitmap: 1111101
(no ACK)
  |-----DTag= 1, W=2, FCN=6 ----->|
  |-----DTag= 1, W=2, FCN=5 --X   |
  |-----DTag= 1, W=2, FCN=4 ----->|
  |-----DTag= 1, W=2, FCN=3 ----->|
  |-----DTag= 1, W=2, FCN=2 ----->|
  |-----DTag= 1, W=2, FCN=1 ----->|
  |-----DTag= 1, W=2, FCN=0 ----->| Bitmap: 1011111
(no ACK)
  |<--------- RECV ABORT ---------|
Figure 5: SCHC Streaming mode sequence example 4 - Aborted by receiver

5. SCHC Streaming mode YANG Data Model

The present document also extends the SCHC YANG data model defined in [RFC9363] by including a new identity in the fragmentation mode type.

6. Security considerations

TBD

7. IANA Considerations

This document has no IANA actions.

8. Acknowledgements

Carles Gomez has been funded in part by the Spanish Government through the TEC2016-79988-P grant, and the PID2019-106808RA-I00 grant (funded by MCIN / AEI / 10.13039/501100011033), and by Secretaria d'Universitats i Recerca del Departament d'Empresa i Coneixement de la Generalitat de Catalunya 2017 through grant SGR 376.

Sergio Aguilar has been funded by the ERDF and the Spanish Government through project TEC2016-79988-P and project PID2019-106808RA-I00, AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033).

9. References

9.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8724]
Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, , <https://www.rfc-editor.org/info/rfc8724>.
[RFC9363]
Minaburo, A. and L. Toutain, "A YANG Data Model for Static Context Header Compression (SCHC)", RFC 9363, DOI 10.17487/RFC9363, , <https://www.rfc-editor.org/info/rfc9363>.

9.2. Informative References

[RFC8376]
Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, , <https://www.rfc-editor.org/info/rfc8376>.

Authors' Addresses

Sergio Aguilar
Universitat Politecnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Carles Gomez
Universitat Politecnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain