Subject: [lp-wan] #20 Byte Boundary - Answer needed!

From: ana minaburo <[email-masked]>
Date: Fri, 1 Jun 2018 12:17:42 +0200

Hello,

During the last Interim meeting, we discussed the best term to be used to
define the boundary in the definition of the format frames. The idea is to
align the fragment format to an integer number of bytes, so when doing
bitmap encoding it may be easier to know what is sent because we will send
the bitmap until next byte boundary of the last error.

|     Rule ID     |     DTag     |W|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|
|-INTEGER NUMBER OF BYTES-| 1 next byte  |  1 next byte  |

=> By Byte Boundary, we didn't mean 1 byte but an INTEGER NUMBER OF BYTES

* Bitmap, encoded for transmission, we send until the first error, or the
next boundary to complete the alignment

+---- ... ---+--...--+-+-+-+
|   Rule  ID  | DTag |W|1|0|
+---- ... ---+--...--+-+-+-+
|--Integer Number of Bytes-|

So clarifying what we want to say, we have two propositions:

Option 1: Use the next byte boundary and only put the right arrow

|<------ byte boundary ------->|

 Replaced with

|         next byte boundary ->|

Option 2: Use the L2 Word. Which will usually be a Byte, but can be
one-bit,  so padding adds strictly less than an L2 Word and If L2 Word == 1
bit, then padding adds 0 bit. This will Simplify description: one single
mechanism and SCHC ACK Bitmap shortened to L2 Word boundary.

We need to have a consensus about this and we need to know which option you
prefer.

Thanks
Ana

---

From: Laurent Toutain <[email-masked]>
Date: Fri, 1 Jun 2018 14:29:14 +0200

Hi,

I prefer option 2, with L2 word, this introduce this new concept, but after
that the explanations are much more simpler.

Laurent

On Fri, Jun 1, 2018 at 12:18 PM ana minaburo <[email-masked]> wrote:

> We need to have a consensus about this and we need to know which option
> you prefer.
>
> Thanks
> Ana
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 1 Jun 2018 14:55:04 +0200

+1

Introducing the "L2 word" term allows a generic approach, independent of
the features of the underlying LPWAN technology.

If the term is to be used in the document (which I strongly support),
option 2 would be consistent with the new term.

Cheers,

Carles

---

From: ana minaburo <[email-masked]>
Date: Tue, 5 Jun 2018 09:17:18 +0200

Hello,

+1 to the use of option 2, the term L2 Word will clarify many details in
the description of the document.

Ana

---

From: <[email-masked]>
Date: Tue, 5 Jun 2018 07:25:14 +0000

Hello all,

Unsurprisingly, I'm in favor of L2 word and the arrow with a single pointed head.

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of ana minaburo <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 5 June 2018 09:17
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] #20 Byte Boundary - Answer needed!

Hello,

+1 to the use of option 2, the term L2 Word will clarify many details in the description of the document.

Ana

On Fri, Jun 1, 2018 at 12:17 PM, ana minaburo <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

During the last Interim meeting, we discussed the best term to be used to define the boundary in the definition of the format frames. The idea is to align the fragment format to an integer number of bytes, so when doing bitmap encoding it may be easier to know what is sent because we will send the bitmap until next byte boundary of the last error.

* Bitmap, encoded for transmission, we send until the first error, or the next boundary to complete the alignment

 Replaced with

|         next byte boundary ->|

Option 2: Use the L2 Word. Which will usually be a Byte, but can be one-bit,  so padding adds strictly less than an L2 Word and If L2 Word == 1 bit, then padding adds 0 bit. This will Simplify description: one single mechanism and SCHC ACK Bitmap shortened to L2 Word boundary.

We need to have a consensus about this and we need to know which option you prefer.

Thanks
Ana

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.