Minutes interim-2017-lpwan-08: Tue 17:00

Meeting Minutes IPv6 over Low Power Wide-Area Networks (lpwan) WG
Title Minutes interim-2017-lpwan-08: Tue 17:00
State Active
Other versions plain text
Last updated 2017-09-26

Meeting Minutes

   Connection details

*    Date: September 26, 2007
*    Time: 8-9AM DST, 17:00 CEST:
*    Webex Link:
*    Meeting number: 208 224 943

*    Meeting password: d5bBrqTZ (35227789 from phones)
*    Join from a video conferencing system or application
*    Dial 208224943@cisco.webex.com
*    Join by phone
*    +1-866-432-9903 Call-in toll-free number (US/Canada)
*    +1-408-525-6800 Call-in toll number (US/Canada)
*    Access code: 208 224 943


*    [17:00] Administrivia                                           [10min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts (WGLC / forthcoming WGLC)

*    [17:10] LPWAN Overview - WGLC status and updates                [ 5min]
*    [17:15] Fragmentation optimization       (Laurent/Ana)          [10min]
*    [17:25] Finite State Machine Discussion  (Laurent)              [20min]
*    [17:45] Update on adding a length field for rules (Arun)        [ 5min]
*    [17:50] Update on SCHC fragmentation (Carles)                   [10min]
*    [18:00] AOB                                                     [ 0min]

Action Items

* Pascal to send an email for IPR on the overview doc
* Laurent to reformat his FSM in 16*9 with just W=X

Minute takers

*    Ana minaburo
*    Arunprabhu Kandasamy
*    Pascal Thubert


*    Alex Pelov
*    Ana minaburo
*    Arunprabhu Kandasamy
*    Dominique Barthel
*    Julien Catalano
*    Carles Gomez
*    Pascal Thubert
*    Laurent Toutain
*    Vincent Audebert
*    Ivaylo Petrov


*    [17:00] Administrivia                                           [10min]
    o    Note-Well, Scribes, Agenda Bashing

    * Read the note well, presence is logged and meeting is not recorded
    *  The Actions Items have been done
       Stephen will publish doc tomorrow including Alper's comments
    * Please to the conflict list to see if you want to modify it
    * Alex: Include action for us to check that is ok for the IETF
    * Pascal: The only thing we need to check is the conflict list, the request
    is done in the IETF website o    Status of drafts (WGLC / forthcoming WGLC)

*    [17:10] LPWAN Overview - WGLC status and updates                [ 5min]
* Pascal: Document in LC
* Pascal: Alper sent the last modifications
* Pascal: We need to send to the ML if there is not an IPR for this document
=> Pascal to send an E-mail for the IPR

*    [17:15] Fragmentation optimization       (Laurent/Ana)          [10min]

* Laurent: When designing the rule we need to take into account is how the
things are sent. data is multiple of 8 bits, and when sending the bit map we
know how to read the information and e can optimize the functions * Laurent: we
can optimize the frame for the Ack to the bitmap. The optimization of the
bitmap with the bits that will be used for the state machine. An oscillation
between W1 to W0 and windown bit oscilate between 1 and 0. * Pascal and Carles:
It is clear

*    [17:25] Finite State Machine Discussion  (Laurent)              [20min]

* Laurent: The state machine can be collpased in several state, but I would to
show the oscillation until the end of the transmission
   - When the receiver starts receiveing from W0 anything from W1 we discarded
   - When the frame is in W0 we mark the bitmap tp say that it is received
   - When we receive alll the frames in window0 we send the bitmap and we go to
   the state wait W1 - In wait W1 we stay here during the lost frames are
   received, and when we receive a W=1 we go to the rcv window1
Suppose we are waiting the next window, we can also recve the frame with all 1
for the next window and we check MIC, but if MIC is not correct some frames are
lost until the MIC becomes correct we go to Ends states. To go to the End state
all 1 or all 0 * Dominique: This state machine is "per DTAG", since we can
receive fragments with several differents Dtags in parallel, isn't it? *
Laurent: Yes, when bitmap is lost, the sender will resend all 1 to ask for the
bitmap so you know you need to resend the bitmap because it was lost * Pascal:
W0 is the one of 0's packets, and W1 for all 1's packets, so next  new packet
arrive, how do we avoid to get lost between the last frame of the previous
packet? * Laurent: The initial state is receive W0 If we want to avoid DTAG for
size reason: we have the retransmission timer how many times we can send a
frame * Pascal: * Laurent: If we loose all the first window, we do not go to
window 1 because we need an ACK to go to the window 1, so we can avoid timer
when DTAG is not present * Laurent: we can reduce the state machine because the
RCV-window and wait window are the same but of different window, * Laurent:
Next slide, this the sender state machine, it starts in send window0 and it
stay there until all the fragment are left * Dominique: When the receiver has a
wrong MIC how the sender knows? * Laurent: The MIC is for the receiver and not
for the sender, the sender will only wait for the bitmap * Laurent: we can also
send how many fragmets have been sent and if the number match you know there
were no error, but you need to check that the fragment are correct. * Laurent:
we can do both but I thik this can be define in the specific draft for each
technology * Laurent: in the wait window we have the optimization when the
local bitmap(FCN) etc you send the ACK and the sender is synchronized with this
event and we avoid send all this ack just to send a bitmap * Pascal: Do you
want to use this optimization for all the case when the MIC is rigth * Laurent:
I expect to receive a ack to know if the mic is correct and there is some lost
for the bitmap * Carles on chat: On the FSM: maybe replace "send bitmap" with
"send ACK", since an ACK that confirms all frags received has no bitmap

*    [17:45] Update on adding a length field for rules (Arun)        [ 5min]

* Arun: Discussion about adding the length for the Rule, Laurent propose to
have a column for  the length to know the information of the field, for Ana's
e-mail said that adding this column use alot of memory so she propose to create
a new MO name check-length to be used for the variable fields to know the
length and optimize memory But some questions araised there: how can we use
both MSB and check length? the sencond one is should the number of rules will
increase so the end device is Ana: the important thing is the length for LSB,
the description says if the field is variable or not. The length is carried
before the LSB. Ana: we can add a new matching operator containing the MSB and
ck_len parameters. Alex: how the operator are represented in memory, JSON
cannot be sent other the radio. Alex: in Yang 2 columns one for the function
and one for the parameters. Laurent: in Yang we can define a list for
parameters. Ana: adding a columns is a lot of memory, Alex: in favor of adding
a column, Arun: I will send a summary of all propositions for a vote.

[18:05] Meeting times out

*    [17:50] Update on SCHC fragmentation (Carles)                   [10min]
*    [18:00] AOB                                                     [ 0min]

Action Items from last time

* Chairs to book the meeting for IETF 100, 80 people, 2:30Hours
* Alper to send an email to the list with proposed editorials
* Chairs to Ask Stephen to publish the doc with Alper's comment
* Arun to resend his mail asking for the length indication in the rule
* chairs to ask the group to review the FSM in today's material posted on the