Subject: [lp-wan] comments for SCHC over LoRaWAN

From: Shoichi Sakane <[email-masked]>
Date: Sat, 2 Feb 2019 16:32:31 +0900

Hi authors of draft-petrov-lpwan-ipv6-schc-over-lorawan,

I have a text which should be described in the section 5.3 Fragmentation.
The SCHC gateway needs to know the MTU size of FRMPayload.
Here is the text.  Please take a look.

Thanks,
Shoichi

----

The MAC payload of LoRaWAN is called MACPayload.  The size of MACPayload may or may not be fixed.

It depends on whether the adaptive data rate is used in operation.
The size of MACPayload also depends on the region where the LoRaWAN network is operated.
The data rate and the size of MACPayload are indicated by the index of DR.
For example, 51 bytes in DR0 of EU863-870, 11 bytes in DR0 of US902-928.

The application data is put into the FRMPayload field in the MACPayload.

   MACPayload field format.
   +------+-------+------------+
   | FHDR | FPort | FRMPayload |
   +------+-------+------------+

An application message is put into the FRMPayload field, the size of FPort is fixed of 1 byte.
The minimum size of FHDR is 7 bytes. The MAC control commands can be put into the FHDR field.
Hence, the size of FHDR fields become longer in that case and the size of FRMPayload field become shorter.

The point here is that only both the device and the network server know the size of FRMPayload.

In the SCHC fragmentation, before the sender fragments a SCHC packet, it needs to know the size of the L2 MTU in order to fit a SCHC fragment into FRMPayload field.

The software of the SCHC layer in the LoRaWAN device typically has a capability to know the current size of FRMPayload.

However, the SCHC gateway for LoRaWAN normally doesn't have a way to know the size.
If the gateway doesn't know the size, the gateway MUST use P bytes as the L2 MTU.

The size of P MUST be defined in this document.

---

From: ivaylo petrov <[email-masked]>
Date: Wed, 13 Feb 2019 14:47:16 +0100

Hi, Shoichi,

Thank you for your suggestions! I think it might be on a good path - having
a default value (P) for the case where the SCHC gateway does not know the
MTU makes sense. I am wondering if it could be reasonable to expect that
SCHC gateway will know the region where the device is in this case (this is
also a question for my co-authors). If not, we will be limiting the
downlink fragmentation quite a bit. If yes, we can have this value depend
on the regional constraints.

As for FOpts (or changing size of FHDR), I am not entirely convinced that
we need to take it into account. In theory it can take the whole payload
for some regional parameters and spreading factors, which is definitely
something that we can not handle. For me there are two factors that make
this matter less problematic:
* The LoRa Network Server (LNS) could decide to send the MAC commands in a
separate message if it can not send them with the data fragment. Given that
the FPending bit is set, this should not take too much time.
* If the LNS drops the application payload (which is worst case scenario
for me), this is equivalent to the fragment being lost, which is something
users of SCHC should also consider (i.e. choose appropriate profile). As
long as MAC commands are not sent too often, we should still be fine. What
is your opinion on this part?

Best regards,
Ivaylo

On Sat, Feb 2, 2019 at 8:32 AM Shoichi Sakane <[email-masked]> wrote:

> In the SCHC fragmentation, before the sender fragments a SCHC packet, it
> needs to know the size of the L2 MTU in order to fit a SCHC fragment into
> FRMPayload field.
>
> The software of the SCHC layer in the LoRaWAN device typically has a
> capability to know the current size of FRMPayload.
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Shoichi Sakane <[email-masked]>
Date: Tue, 19 Feb 2019 21:09:57 +0900

Hi Ivaylo,

In general, once a region is specified, the table of the maximum payload size would be decided.  If ADR is off, the SCHC gateway could use a static MTU with a static SF.  Otherwise, the gateway is not able to know the current maximum payload size.  The gateway should take a minimum MTU which is allowed by the region parameters.  This is the value P.

My assumption is that the network server doesn't have any interface to provide the SCHC gateway the current maximum payload size for the application layer as well as the region parameters.  However, the draft of SCHC over LoRaWAN should suggest that the network server has a capability to provide such information.

I also don't think to put something text about FOpts into the draft.  What I wanted to say here was the size of the field for the application payload is not fixed even it is for downlink frame.

Thanks,
Shoichi

On 2019/02/13 22:47, ivaylo petrov wrote:
> Hi, Shoichi,
> 
> Thank you for your suggestions! I think it might be on a good path - having a default value (P) for the case where the SCHC gateway does not know the MTU makes sense. I am wondering if it could be reasonable to expect that SCHC gateway will know the region where the device is in this case (this is also a question for my co-authors). If not, we will be limiting the downlink fragmentation quite a bit. If yes, we can have this value depend on the regional constraints.
> 
> As for FOpts (or changing size of FHDR), I am not entirely convinced that we need to take it into account. In theory it can take the whole payload for some regional parameters and spreading factors, which is definitely something that we can not handle. For me there are two factors that make this matter less problematic:
> * The LoRa Network Server (LNS) could decide to send the MAC commands in a separate message if it can not send them with the data fragment. Given that the FPending bit is set, this should not take too much time.
> * If the LNS drops the application payload (which is worst case scenario for me), this is equivalent to the fragment being lost, which is something users of SCHC should also consider (i.e. choose appropriate profile). As long as MAC commands are not sent too often, we should still be fine. What is your opinion on this part?
> 
> Best regards,
> Ivaylo
> 
> 
> On Sat, Feb 2, 2019 at 8:32 AM Shoichi Sakane <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>