Static Context Header Compression and Fragmentation ARQ/FEC mode

SCHC ARQ-FEC Fragmentation Mode The ARQ-FEC mode uses channel coding to protect fragments from errors and losses. ARQ-FEC mode performs data delivery without retransmitting the lost tiles if the number of lost tiles is not higher than a configurable threshold. ARQ-FEC mode is based on a Type II Hybrid ARQ/FEC mechanism and consists of two main processes: encoding and fragmentation. shows both processes in the sender and the receiver. The SCHC packet coming from the compression sublayer is first encoded into a coded data structure and then fragmented. At the receiver, the process is reversed. The reassembler first reconstructs the coded data structure from the received tiles and then decodes it to recover the SCHC packet. The format of the coded data structure depends on the selected encoding geometry. This specification defines two encoding geometries: a matrix-based encoding geometry ("C-matrix") and a streaming encoding geometry ("C-Stream").

Protocol Elements This subsection outlines the various components used to support the ARQ-FEC mode functionality defined in this document. SCHC Packet size: The size in bits of the data packet received from the compression sublayer (see Figure 24 in ). In this document the SCHC Packet size is called "P". Each profile MUST define the maximum size of a SCHC packet that can be fragmented in ARQ-FEC mode. This maximum size is called "P_max". Symbol: A data unit handled by the encoding process. Each symbol is treated as an indivisible unit, meaning it is either fully received or entirely lost. A symbol has "m" bits. Source Symbol: A unit of data used during the encoding process. A source symbol contains information from the original SCHC packet. Source Block: A subset of source symbols. A source block has "k" symbols. Encoding Geometry: The method used to arrange data from the SCHC Packet and to organize both source and encoded symbols into either a matrix or a stream data structure. Coded Data Structure: The arrangement of symbols resulting from the FEC encoding process, as defined by the selected encoding geometry. It serves as the input to the fragmentation process and is represented either as a C-Matrix or a C-Stream. D-matrix (Data Matrix): The conceptual two-dimensional arrangement of the source symbols derived from the SCHC Packet prior to FEC encoding. Each row of the D-matrix is a Source Block. D-Stream: The conceptual sequential arrangement of the source symbols derived from the SCHC Packet prior to FEC encoding. A Source Block is a group of sequential source symbols. Encoded Symbol: A symbol containing information generated by the Forward Error Correction (FEC) code which can be used to recover lost source symbols. Encoded Block: An encoded block consists of all the encoded symbols resulting from the FEC encoding of a single source block. An encoded block has "n" symbols. C-matrix (Coded Matrix): The conceptual two-dimensional arrangement of encoded symbols produced by applying the selected FEC scheme to each row of the D-matrix. Each row of the C-matrix is an Encoded Block corresponding to the associated D-matrix row. C-Stream: The conceptual sequential arrangement of encoded symbols produced by applying the selected FEC scheme to the D-Stream. Encoded symbols are generated and organized as a stream corresponding to the source blocks. Residual coding bits: These are the left over bits resulting from dividing a SCHC packet into a D-matrix. Residual fragmentation bits: These are the bits left over from dividing a C-matrix into tiles of a given size.

Encoding and Decoding Processes At the sender, the encoding process creates the coded data structure from a SCHC packet, according to the selected encoding geometry. At the receiver, the decoding process works in reverse, i.e., it creates a SCHC packet from the coded data structure.

Encoding Geometries The encoding and decoding processes support two distinct encoding geometries, which define how symbols are to be organized, and how repair information is generated and applied. The selected encoding geometry impacts both the performance of the FEC mechanism and the resource requirements of the system. This specification defines the following encoding geometries: Matrix-based geometry: Symbols are arranged in a two-dimensional structure, enabling flexible FEC strategies such as structured interleaving, configurable parity coverage, and repeated multi-pass decoding. This geometry supports more robust error correction capabilities. Stream geometry: Symbols are organized as a sequential stream, where repair symbols are generated over a sliding or sequential set of symbols (block). This geometry enables simpler encoding and decoding operations. The choice of encoding geometry reflects a trade-off between reliability and resource consumption. The matrix-based geometry provides stronger recovery capabilities and are suited for use cases requiring high reliability under significant loss conditions. The stream geometry, on the other hand, is designed for environments with constrained processing or memory resources, providing lightweight protection against losses at a lower implementation cost. The selection of the encoding geometry is configured within the SCHC fragmentation rule and determines the encoding and decoding procedures described in the following sections.

Sender Behavior Upon reception of a SCHC packet from the compression sublayer, the sender divides the SCHC packet into source blocks. Each source block has "k" source symbols, and each source symbol has "m" bits. The encoding process consists of applying an FEC algorithm to each source block. Thus, the FEC (n,k) algorithm encodes a source block of k source symbols into an encoded block of n symbols.

Matrix-Based Encoding The steps for dividing the SCHC packet and creating a C-Matrix is as follows: Divide the SCHC packet into S source blocks of k symbols. Each symbol has m bits. S is calculated as floor(P/(k * m)) If (P mod (k * m)) equals zero, then there are no remaining bits. If (P mod (k * m)) is not equal to zero, then there should be (P mod (k * m)) remaining bits. The remaining bits are called residual coding bits. Arrange the source blocks in a grid pattern or matrix. This will be the D-matrix. Each element of the D-matrix is a source symbol. Each row of the D-matrix will be a source block. The D-matrix has S rows and k columns. The residual coding bits MUST NOT be placed in the D-matrix. shows an example of the arrangement.

^ SS(1,1) SS(1,2)... SS(1,k) Source block 1 | SS(2,1) SS(2,2)... SS(2,k) Source block 2 S rows | : : : | : : : v SS(S,1) SS(S,2)... SS(S,k) Source block S SS: Source Symbol ]]> Apply the FEC algorithm to each source block. The FEC algorithm encodes k symbols from the source block and generates an encoded block with n symbols. Arrange the encoded blocks in a grid pattern or matrix, this will be the C-matrix. Each element of the C-matrix is an encoded symbol. Each row of the C-matrix will be an encoded block. The C-matrix has S rows and n columns. shows an example of the arrangement.

^ ES(1,1) ES(1,2)... ES(1,n) Encoded block 1 | ES(2,1) ES(2,2)... ES(2,n) Encoded block 2 S rows | : : : | : : : v ES(S,1) ES(S,2)... ES(S,n) Encoded block S ES: Encoded symbol ]]>

Stream Encoding In the stream encoding geometry, the encoding process is performed as a sequence of steps applied to the SCHC Packet. First, the SCHC Packet is partitioned into source symbols of size "m" bits. Each symbol is treated as an indivisible unit by the encoding process. The resulting sequence of source symbols is then grouped into source blocks, each containing "k" source symbols. The number of source blocks depends on the size of the SCHC Packet and is not fixed a priori. Next, the FEC encoding is applied independently to each source block. For each source block, the encoding process generates the corresponding encoded symbols, forming an encoded block of "n" symbols. Finally, the encoded blocks are arranged sequentially to form the C-Stream. The encoded symbols are ordered according to the sequence of their corresponding source blocks, producing a continuous stream of symbols that constitutes the coded data structure.

Receiver Behavior In the receiver, the decoding process MUST create a SCHC packet from the coded data structure with enough encoded symbols. The number of encoded symbols required depends on the forward error correction code used. The decoding process begins when the defragmentation process indicates that there are enough encoded symbols in the coded data structure to obtain a SCHC packet.

Matrix-Based Decoding The steps for decoding a C-matrix and creating a SCHC packet is as follows: Decode the encoded block in the first row of C-matrix. The generated source block contains the k symbols corresponding to the first row of matrix D. Decode the encoded block in the second row of C-matrix. The generated source block contains the k symbols corresponding to the second row of matrix D. Continue with the encoded block in the next row of the C-matrix. Decode all rows of the C-matrix. The result is the D-matrix with all symbols decoded. Once the D-matrix has been generated, reconstruct the SCHC packet by following these steps: Select the k symbols from the first row of the D-matrix. These will be the first (k * m) bits of the SCHC packet. Select the k symbols from the second row of the D-matrix. These symbols will be the next (k * m) bits of the SCHC packet. Continue selecting the k-symbols from each row until the last row of the D-matrix. Add the residual coding bits and padding bits to the end of the SCHC packet. The residual coding bits and padding bits are provided by the defragmentation process.

Stream Decoding In the stream encoding geometry, the decoding process operates on the received C-Stream and is performed on a per-block basis. The receiver processes the C-Stream as a sequence of encoded blocks, each containing "n" symbols. For each encoded block, the decoding process interprets the received symbols according to the selected FEC scheme. Based on this interpretation, the decoding process determines which source symbols are available, which are missing, and how the available symbols can be used to recover missing information. The decoding process then applies the FEC decoding algorithm to recover any missing source symbols within the block. Once all source symbols of an encoded block have been recovered, any symbols that are not required for reconstructing the original data are discarded. The recovered source symbols are then placed in their original order within the stream. After all encoded blocks have been processed, the sequence of recovered source symbols is reassembled to reconstruct the SCHC Packet.

Fragmentation and Defragmentation Processes The fragmentation and defragmentation processes are responsible for transporting the FEC-encoded data from the sender to the receiver. Unlike the other fragmentation processes defined in , the fragmentation and defragmentation processes of ARQ-FEC mode are divided into two sub-processes: the assembler sub-process and the transporter sub-process. shows the architecture of the fragmentation and defragmentation processes at the sender and receiver. At the sender, the fragmentation process receives from the Encoding process the coded data structure and the residual coding bits separately. The C-matrix is processed by the assembler sub-process. The assembler sub-process converts the C-matrix in an encoded SCHC packet that is passed to the transporter sub-process. The transporter sub-process divides the encoded SCHC packet in tiles. The tiles are sent to the receiver via Regular SCHC fragment messages. At the receiver, the defragmentation process works in reverse. The transporter sub-process receives the tiles that are then passed to the assembler sub-process. The assembler subprocess constructs the coded data structure using the received tiles. Once the assembler sub-process has collected sufficient symbols to enable decoding, the transporter sub-process terminates the fragmentation session and forwards the coded data structure to the decoding process.

Assembler Sub-Process

Sender Behavior On the sender side, the assembler sub-process is responsible for transforming the coded data structure into an encoded SCHC packet. To do this, the assembler sub-process reads the encoded symbols from the coded data structure according to the selected encoding geometry and arranges them into a sequential buffer. This buffer forms the encoded SCHC packet that is passed to the transporter sub-process. The arrangement of symbols in the encoded SCHC packet is determined by the encoding geometry.

Important: Residual encoding bits MUST NOT be included in the encoded SCHC packet. Residual coding bits MUST be included in the last tile.

C-Matrix Assembly In the matrix-based encoding geometry, the assembler sub-process constructs the encoded SCHC packet column by column. It first selects the S symbols of the first column of the C-matrix, which form the beginning of the encoded SCHC packet. It then selects the S symbols of the second column, which are appended to the encoded SCHC packet, and continues this process for all columns. shows how the encoded SCHC packet is constructed from the C-matrix.

C(1,1) C(2,1)...C(S,1) C(1,2) C(2,2)...C(S,2)...C(1,cwl)...C(S,cwl) ]]>

C-Stream Assembly In the stream encoding geometry, the assembler sub-process constructs the encoded SCHC packet from the C-Stream. The assembler sub-process reads the encoded symbols sequentially from the C-Stream and arranges them into a continuous buffer. This buffer is then partitioned into tiles according to the tile size defined by the fragmentation rule. The tiles are grouped into windows of a priori known size. The mapping of symbols to tiles and windows is determined by the order in which symbols are read from the C-Stream. The assembler sub-process MAY apply an interleaving pattern to the encoded symbols, as specified by the fragmentation rule, resulting in a reordering of the window and tile numbering sequence. This reordering is used to distribute symbols originating from different encoded blocks across multiple windows, improving robustness to losses. When such reordering is applied, the relative position of symbols within each encoded block is preserved, while their placement within the encoded SCHC packet is modified according to a deterministic pattern known to both sender and receiver. The resulting sequence of tiles forms the encoded SCHC packet, which is passed to the transporter sub-process for transmission.

Receiver Behavior In the receiver, the assembler sub-process is responsible for three tasks: placing each tile in the coded data structure, verifying whether there are enough symbols to successfully decode the SCHC Packet, and indicating to the transporter sub-process which tiles need to be retransmitted.

Placing Tiles in the Coded Data Structure When the transporter sub-process receives a regular SCHC fragment, the transporter sub-process delivers the tiles to the assembler sub-process to place them in the coded data structure.

C-Matrix Tile Placement

If the receiver has not received parameter S, then the following steps cannot be executed and the receiver must wait to receive parameter S before continuing with the verification process. Parameter S is transported in the first tile of the first fragment of the first window.

The procedure for placing a tile in the C-matrix is as follows: Convert the FCN and W of each tile in a correlative tile number (ctn). The correlative tile number starts at zero. For example, tile 62 of window 0 (FCN=62, W=0) corresponds to ctn=0. Tile 61 of window 0 (FCN=61, W=0) corresponds to ctn=1, and so on. To determine the correlative tile number (ctn), use the following equation:

where WINDOW_SIZE is defined by each profile. FCN is the Fragment Compressed Number of each tile. W is the field that indicates the window to which the tile belongs. Convert the correlative tile number (ctn) into a position (row, column) within the matrix. To determine the row, use the following equation:

To determine the column, use the following equation:

where ts is the tile size in symbols. S is the number for row in the C-matrix. The tile must be placed vertically in the matrix. This means that the first symbol on the tile is placed in the position (row, column) determined in the previous point. Each subsequent symbol of the tile is placed in the same column and the next row in increasing order. If the last row of the matrix is reached and unplaced symbols remain in the tile, placement shall continue at the first row of the next column. For example, assume a tile contains 4 symbols and the C-matrix has 7 rows (S = 7). If placement begins at row 5, column 1, the symbols are placed at positions (5,1), (6,1), (7,1), and (1,2), respectively.

C-Stream Tile Placement When operating on a C-Stream, the assembler sub-process places received tiles into the sequential block structure of the C-Stream. For each received tile, the assembler sub-process determines its position in the C-Stream based on the Window (W) and Tile (T) fields carried in the SCHC fragment. The tile is then stored at the corresponding position in the structure. The placement of tiles in the C-Stream is independent of the order in which they are received. In particular, when interleaving has been applied at the sender, tiles may be received in an order that does not correspond to their original sequence in the C-Stream. By placing each tile according to its W and T values, the assembler sub-process reconstructs the original ordering of the encoded symbols within the C-Stream. Missing tiles remain uninitialized or marked absent in the C-Stream; if the C-Stream as a whole becomes decodable, it is passed to the decoding process even if some tiles were never received.

Checking if There Are Enough Symbols In ARQ-FEC mode, the decoding process does not need to have the n encoded symbols in each Encoded Block to recover the original k symbols. Therefore, the assembler process only needs to have k encoded symbols in each Encoded Block to pass the coded data structure to the decoding process. If the coded data structure has enough symbols, the sender can stop transmitting tiles and the receiver can start the decoding process. When the receiver receives a SCHC regular fragment, the transporter sub-process extracts the tiles from the message and sends them to the assembler sub-process. The assembler sub-process places the tiles in the coded data structure, as explained in section . Once the tiles are in place, the task of checking whether there are enough symbols in each Encoded Block can begin. The verification task must review all encoded blocks in the coded data structure and check its present symbol count; if a block contains at least k symbols it is marked as decodeable, otherwise, not decodeable. If a block is already marked as decodeable, the task skips it and continues until all encoded blocks have been reviewed. If at any point the verification task detects that all encoded blocks of the coded data structure are decodable, then the assembler sub-process MUST indicate to the transporter sub-process that the coded data structure has sufficient symbols.

Selecting the Tiles to Retransmit If the receiver receives a SCHC All-1 fragment message, the transporter subprocess must indicate to the assembler subprocess that it has received a SCHC All-1 fragment along with the last tile. The assembler subprocess obtains the residual fragmentation bits from the last tile and adds them to coded data structure. When the assembler sub-process adds the residual fragmentation bits, two outcomes are possible: If all blocks are marked as decodeable, the assembler sub-process must notify the signaling sub-process that the coded data structure contains enough symbols and the fragmentation session may end. If one or more encoded blocks within the coded data structure were marked as undecodable, the assembler sub-process must follow the retransmission selection steps for the chosen encoding geometry.

C-Matrix Tile Retransmission Selection Select a row marked as undecodable. Consider that the row has m received symbols, select the (k-m) lost symbols, where k is the number of symbols in each row of D-matrix (see ). Convert the position of the missing symbol into a correlative tile number (ctn). The position of a missing symbol is defined by the row and column to which it belongs. To obtain the correlative tile number (ctn), use the following equation:

where ts is the tile size in symbols. S is the number for row in the C-matrix. To obtain the Fragment Compressed Number (FCN) of the correlative tile number (ctn), use the following equation:

where WINDOW_SIZE is defined by each profile. ctn is the correlative tile number. To obtain the window to which a tile (w) belongs from the correlative tile number (ctn), use the following equation:

Pass the list of missing tiles to the transporter subprocess. A tile is defined by its Fragment Compressed Number (FCN) and the window to which it belongs.

C-Stream Tile Retransmission Selection When the assembler process determines that an encoded block cannot be successfully decoded due to missing data, the assembler sub-process identifies the corresponding missing tiles within the C-Stream. The identification of missing tiles is based on the position of tiles within the C-Stream, as determined by their Window (W) and Tile (T) values. This identification is independent of whether interleaving has been applied at the sender, as each tile retains a unique position within the C-Stream. The assembler sub-process indicates the set of missing tiles to the transporter sub-process using the bitmap format defined for SCHC Compound ACK messages.

Transporter Sub-Process ARQ-FEC mode supports the following features: the mode works with L2 technologies that have a variable MTU and may deliver packets out of order. the mode requires the L2 layer to provide a feedback channel from the reassembler back to the fragmenter. the mode uses window. all tiles except the last one MUST be of the same size. These tiles are called regular tiles. A SCHC Fragment message carries one or several contiguous regular tiles, which may span multiple windows. Unlike ACK-on-Error and ACK-Always modes, the success of the transfer of tiles in ARQ-FEC mode is associated with successful decoding of the coded data structure. If some tiles are lost during fragmentation and reassembly, the coded data can still be decoded, the SCHC packet obtained, and the fragmentation declared successful. Therefore, the receiver responds with a SCHC Compound ACK when there are enough symbols to decode the received data, or at the end of the transmission if there are insufficient symbols. For this reason, the SCHC Compound ACK MUST NOT be sent after each window. The sender may advance to subsequent windows even before confirming that all tiles from previous windows have been correctly received. The SCHC Compound ACK message is defined in . The ARQ-FEC mode in the receiver MUST send a SCHC Compound ACK only in these four situations: If the receiver receives a SCHC regular fragment message with the S parameter (matrix-based geometry), if the receiver receives a SCHC regular fragment message and the assembler sub-process verify that there are enough symbols to decode the coded data structure, if the receiver receives a SCHC All-1 message and the assembler sub-process verify that there are enough symbols to decode the coded data structure, if the receiver receives a SCHC All-1 message and the assembler subprocess verifies that there are not enough symbols to recover the SCHC packet. The fragmented encoded SCHC Packet transmission concludes when: the receiver verify that there are enough symbols to decode the coded data structure. too many retransmission attempts were made, or the receiver determines that the transmission of this fragmented SCHC Packet has been inactive for too long. Each Profile MUST specify which RuleID value(s) corresponds to SCHC F/R messages operating in this mode. The W field MUST be present in the SCHC F/R messages. Each Profile, for each RuleID value, MUST define: * the tile size (a tile must be a multiple of a symbol and MUST be at least the size of an L2 word.), * the encoded geometry choice, * the value of M (Symbol size in bits), * the value of N (Encoded block size), * the value of WINDOW_SIZE, which MUST be strictly less than 2^N, * the size and algorithm for the RCS field, * the value of T, * the value of MAX_ACK_REQUESTS, * the expiration time of the Retransmission Timer, * the expiration time of the Inactivity Timer, * the expiration time of the S Timer, For each active pair of RuleID and DTag values, the sender MUST maintain: * one Attempts counter, * one Retransmission Timer, * one S Attempts counter, and * one S Timer For each active pair of RuleID and DTag values, the receiver MUST maintain: * one Inactivity Timer, and * one Attempts counter.

Sender Behavior At the beginning of the fragmentation of a encoded SCHC packet, the sender MUST select the values for RuleID and DTag for this encoded SCHC packet. In addition, the sender MUST initialise the Attempts counter and the S Attempts counter to 0 for these RuleID and DTag values. To fragment an encoded SCHC packet, the sender MUST split the encoded SCHC packet into tiles of the same size. These tiles are called "regular tiles". The remaining part of the division will be the residual fragmentation bits. A Regular SCHC Fragment message carries in its payload one or several contiguous tiles. If more than one tile is carried in one Regular SCHC Fragment: The selected tiles MUST be contiguous in the original encoded SCHC Packet, and the selected tiles MUST be placed in the SCHC fragment payload next to each other, in the same order as they appear in the encoded SCHC packet, and the FCN field MUST contain the tile index of the first tile sent in that SCHC Fragment, and the sender MUST fill the W field with the window number of the first tile sent in that SCHC Fragment. The last tile consists of the residual coding bits and the residual fragmentation bits. The last tile MUST be sent in an All-1 SCHC message. In an All-1 SCHC Fragment message, the sender MUST fill the W field with the window number of the last tile of the encoded SCHC Packet. The sender must wait for the reception of a SCHC ACK after sending an All-1 SCHC. In this case, two situations may occur: If the sender receives a SCHC ACK containing the field W=11 and C=1, then the All-1 SCHC was successfully received, the receiver has enough symbols, and the sender can terminate the fragmentation session. If the sender receives a SCHC ACK containing the C=0 field, then the All-1 was successfully received, the receiver does not have enough symbols, and the bitmap contains the tiles that must be retransmitted. At this point, the sender must retransmit all lost tiles and wait for a SCHC ACK confirming the end of the session. At any time, after receiving confirmation of successful receipt of parameter S, if the sender receives a SCHC ACK with parameters W=01 and C=1, this means that the receiver has enough symbols to decode matrix C. The sender must respond with an All-1 SCHC and wait for confirmation. In brief, the fragment sender MUST listen for SCHC Compound ACK messages after having sent: a SCHC Regular Fragment, or an All-1 SCHC Fragment, or a SCHC ACK REQ. Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC ACK REQ: it MUST increment the Attempts counter, and it MUST reset the Retransmission Timer. On Retransmission Timer expiration: if the Attempts counter is strictly less than MAX_ACK_REQUESTS, the fragment sender MUST send either the All-1 SCHC Fragment or a SCHC ACK REQ with the W field equal to zero. otherwise, the fragment sender MUST send a SCHC Sender-Abort, and it MAY exit with an error condition. Each time a fragment sender sends a Regular SCHC Fragment with the S parameter: it MUST increment the S Attempts counter, and it MUST reset the S Timer. On S Timer expiration: if the S Attempts counter is strictly less than MAX_ACK_REQUESTS, the fragment sender MUST send a Regular SCHC Fragment with the S parameter in the first tile. otherwise, the fragment sender MUST send a SCHC Sender-Abort, and it MAY exit with an error condition. On receiving a SCHC Compound ACK: if the W field is set to 00 and the C bit is set to 1, the sender MUST assume that the receiver already knows the S parameter. If field W is set to 01 and bit C is set to 1, the sender MUST assume that the receiver has enough symbols to recover the SCHC packet. The sender MUST send an All-1 SCHC and wait for a SCHC ACK confirming receipt of the All-1 SCHC. If the W field is set to 11 and the C bit is set to 1, the sender MUST terminate the fragmentation session. if the C bit is set to 0, the fragment sender MUST send SCHC Fragment messages containing all the tiles that are reported missing in the SCHC Compound ACK.

Matrix-Specific Behavior In the matrix-based encoding geometry, the receiver needs to obtain the S parameter to know how many rows the C-matrix should have. With the C-matrix constructed, the receiver can know when there are enough symbols to decode an encoded SCHC packet. The sender sends the S parameter in the first tile of the first window. This means that the encoded SCHC packet will go from the second tile of the first window onwards. In summary: * the first tile (FCN=WINDOW_SIZE-1) of the first window (W=0) contains the parameter S. The parameter S indicates the number of rows in the C-matrix, and * the first tile of the encoded SCHC packet MUST be transported in the fragment with FCN = WINDOW_SIZE-2 of the first window (W=0). The sender must wait for the reception of a SCHC Compound ACK to the tile carrying parameter S. The SCHC Compound ACK must contain the field W=00, C=1, and without bitmap.

Receiver Behavior When the reassembler receives a SCHC fragment with a RuleID that is not currently being processed, then: The receiver MUST start a process to assemble a new encoded SCHC Packet with that RuleID, the receiver MUST start an Inactivity Timer and an Attempts counter to 0 for that RuleID, and if the receiver is under-resourced to do this, it MUST respond to the sender with a SCHC Receiver-Abort. Whenever a SCHC F/R message arrives for the current RuleID, the receiver MUST reset the corresponding Inactivity Timer. On receiving a SCHC Fragment message, the receiver determines what tiles were received, based on the payload length and on the FCN field of the SCHC Fragment. When the receiver receives a SCHC Fragment message, the following situations may occur: The behavior of the transporter sub-process depends on the type of SCHC fragment received and the decoding status as indicated by the assembler sub-process. When a Regular SCHC Fragment is received, the transporter sub-process extracts the tiles based on the a priori known tile size and delivers them to the assembler sub-process. The transporter sub-process then awaits a response from the assembler sub-process. If the assembler sub-process indicates that sufficient symbols have been collected to enable decoding, the transporter sub-process MUST send a SCHC Compound ACK with the W field set to 1 and the C field set to 1, and wait for an All-1 SCHC fragment. Otherwise, the transporter sub-process SHOULD take no action. When an All-1 SCHC fragment is received, the transporter sub-process delivers the remaining tile(s) to the assembler sub-process and awaits a response. If the assembler sub-process indicates that sufficient symbols have been collected to enable decoding, the transporter sub-process MUST send a SCHC Compound ACK with the W field set to 3 and the C field set to 1, and terminate the fragmentation session. Otherwise, the transporter sub-process MUST send a SCHC Compound ACK with the C field set to 0, including bitmaps indicating the missing tiles. Upon sending a SCHC Compound ACK, the receiver MUST increase the Attempts counter. Upon receiving a SCHC Sender-Abort, the receiver MAY exit with an error condition. Upon expiration of the Inactivity Timer, the receiver MUST send a SCHC Receiver-Abort, and it MAY exit with an error condition. On the Attempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST send a SCHC Receiver-Abort, and it MAY exit with an error condition. Fragmentation session concludes when: a Sender-Abort has been received, or the Inactivity Timer has expired, or the Attempts counter has exceeded MAX_ACK_REQUESTS, or an All-1 SCHC message is sent with the W field set to 3 and the C field set to 1.

Matrix-Specific Behavior When the first SCHC fragment of a fragmentation session is received, the first tile carries the S parameter. This parameter is extracted by the transporter sub-process and provided to the assembler sub-process.