Subject: [lp-wan] SCHC fragmentation on NB-IoT

From: Ana Minaburo <[email-masked]>
Date: Thu, 11 Jun 2020 21:31:16 +0200

Dear LPWANers,

I would like to see your point of view about the following possible use of
SCHC, in the control plane, the use of SCHC fragmentation before SCHC C/D.
Let me explain it with more details.

In the NB-IoT architecture, we can send data in the control plane, where
the transfer block is between 16 bits and 1000 bits, the use of SCHC is
beneficial not only for header compression but also for data fragmentation.
In these circuits, we can send IP or non-IP packets (see figure 4 of NB-IoT
draft).

One application is a packet containing the update of firmware, that
correspond to a Non-IP packet because it only contains data, it has a
considerable size (some Gbytes) compared to the transfer block. It will
probably be encapsulated in an IP packet on the lower layers. Still, they
are transparent for the application; the use of SCHC fragmentation on layer
seven may be very useful. It will bring better performance for the
transmission of this kind of data.

Which will be the inconvenience of doing fragmentation before compression?

Ana

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 12 Jun 2020 09:10:34 +0200

Hello Ana,

> transmission of this kind of data.

If I understand your scenario correctly, I assume that the performance
improvement will come from using one of the reliable SCHC fragmentation
modes, right?

This idea sounds good to me.

In terms of how SCHC is defined in RFC 8724, your large non-IP packet can
still be considered a "SCHC Packet". I guess you may need to either take
the following into account to be RFC 8724-compliant:

            "If the header compression process is
            unable to actually compress the packet header, the packet
            with the uncompressed header is still called a SCHC Packet
            (in this case, a RuleID is used to indicate that the packet
            header has not been compressed)."

... or perhaps some related update might be needed in the SCHC over NB-IoT
draft.

> Which will be the inconvenience of doing fragmentation before compression?

I am curious: do you mean *before* compression or *without* compression?

For example, in Figure 4 of the SCHC over NB-IoT draft, once the firmware
update has been delivered to the device, is compression applied at all?

Thanks,

Carles

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 16 Jun 2020 13:01:00 +0200

Hello Ana,

(CC'ing the list.)

Thanks for all your responses!

Cheers,

Carles

> Hello Carles,
>
> thank you for your input, see my comments below
>
>
> On Fri, Jun 12, 2020 at 9:10 AM Carles Gomez Montenegro <
> [email-masked]> wrote:
>
>> Hello Ana,
>>
>> > Dear LPWANers,
>> >
>> > I would like to see your point of view about the following possible
>> use
>> of
> Yes, I was thinking about ACK-on-Error with regular tiles
>
>>
>> Good input, thanks, I will put a link to this.
>
>
> Yes and no, I mean for the application point of view there is only
> fragmentation without compression because the lower layers are
> transparent;
> for L2 point of view, you will do fragmentation in layer 7 and compression
> in layer 2,5 in the PDCP layer. So you do fragmentation before
> compression,
> but as both part are independent I think that finally, it does not matter
> because they are managed differently.
>
>>
>> Thanks,
>>
>> Carles
>>
>>
>> > Ana
>>
>
> Ana
>