* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Lpwan Status Pages

IPv6 over Low Power Wide-Area Networks (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2016-Oct-14 —  
Chairs
 
 


IETF-102 lpwan minutes

Session 2018-07-19 0930-1200: Centre Ville - Audio stream - lpwan chatroom

Minutes

minutes-102-lpwan-00 minute



          Meeting        :   IETF 102 Thursday July 19th, 2018
          Time           :   9:30-12:00 Montreal Time Morning session I (2H30min)
          Location       :   Room Centre Ville, Fairmont The Queen Elizabeth,
          Montreal
          Agenda         :
          https://datatracker.ietf.org/meeting/102/materials/agenda-102-lpwan
          Meeting Slides :   https://datatracker.ietf.org/meeting/102/materials.html
          
          Etherpad       :
          http://etherpad.tools.ietf.org/p/notes-ietf-102-lpwan?useMonospaceFont=true
          
          Meetecho       :   http://www.meetecho.com/ietf102/lpwan/
          Audio stream   :   http://ietf102streaming.dnsalias.net/ietf/ietf1021.m3u
          
          Chairs         :   Pascal Thubert
                             Alexander Pelov
          Responsible AD :   Suresh Krishnan
          
          WG URLs        :   http://tools.ietf.org/wg/lpwan/
                             https://datatracker.ietf.org/wg/lpwan/
                             https://www.ietf.org/mailman/listinfo/lpwan
          
          Minute takers & Jabber Scribe
          
          Francesca on Jabber
          Ivaylo and Dominique taking notes on Etherpad
          ------
          
          Agenda
          ------
          
          *    [09:30] Administrivia
          [15min]
              o    Note-Well, Scribes, Agenda Bashing
              o    Status of drafts (WGLC / forthcoming WGLC)
              o    Presenters: The Chairs
          
          *    [09:45] draft-ietf-lpwan-ipv6-static-context-hc-16
          [45min]
              o    Presenters: Dominique Barthel, Carles Gomez and Ana Minaburo
              o    Goal: info on WGLC conclusion, submit for publication
          
          *    [10:30] draft-ietf-lpwan-coap-static-context-hc-04
          [45min]
              o    Presenter: Laurent Toutain -- Ricardo Andreasen
              o    Goal: WGLC; SCHC/OSCORE presentation
          
          *    [11:15] draft-petrov-lpwan-ipv6-schc-over-lorawan-02
          [10min]
              o    Presenters: Nicolas Sornin (remote)
              o    Goal: present advancement
              o          call for adoption ?
          
          *    [11:25] draft-zuniga-lpwan-schc-over-sigfox-03
          [15min]
              o    Presenters: Juan-Carlos Zuniga
              o    Goal: draft update and discussion about ACK-on-Error mode
              o          call for adoption ?
          
          *    [11:40] draft-minaburo-lpwan-nbiot-hc-01
          [5min]
              o    Presenter: Edgar Ramos
              o    Goal: discuss NB-IoT entities with SCHC
          
          *    [11:45] draft-toutain-core-time-scale-00
          [5min]
              o    Presenter: Laurent Toutain
              o    Goal: Get support from LPWAN to request attention from CORE
          
          *    [11:50] draft-authors-lpwan-schc-802154
          [5min]
              o    Presenters: Charlie Perkins
              o    Goal: ?
          
          *    [11:55] AOB (Charlie Perkins on IEEE)                          [
          5min]
          
          ---
          *    [09:30] Administrivia
          [15min]
              o    Note-Well, Scribes, Agenda Bashing
                  * Francesca on Jabber
                  * Ivaylo and Dominique taking notes on Etherpad, others invited
                  to join in
              o    Status of drafts (WGLC / forthcoming WGLC)
                  * baseline tech document DONE.
                  * UDP/IPv6/SCHC on 2nd WGLC
                  * Rechartering will happen as soon as the IP/UDP compression is
                  submitted to IESG
                    - new items - SCHC over CoAP, tech specific documents, ...
          
                  * Milestones, cleared most of which was listed. today will be
                  diving into IP/UDP
          
                * Hackathons short overview - an open source SCHC implementation
                and a lot of feedback
          
                Dominique about the Hackathon:
                    * long term goal to have open source plan for new comers to
                    play with.
                    * non developers are also invited to read the draft and
                    understand.
                    * Two new comers at this hackathon:
                        - micropython on linux for next time
                    * One of the goals was to merge a number or pieces that are
                    already available - not fully finished
          
          *    [09:42] draft-ietf-lpwan-ipv6-static-context-hc-16
          [45min]
              o    Presenters: Dominique Barthel, Carles Gomez and Ana Minaburo
              o    Goal: info on WGLC conclusion, submit for publication
          
          Mini-agenda: 20 min for tickets - comments received WGLC2 - 25min
          
              Since IETF101, 5 inter-meetings
          
              version 10 -16
          
              10 includes , first 10 tickets from wiki.
          
              11 improved Fig3. Answered more comments about the DTag size on all
              the figures
          
              12 how to compress variable length field. decided to remove y in LSB
          
              last 3 versions, continued working on remaining tickets.
          
               - boundary, l2words, padding at most once. Same ruleID in the ACK
          
              Changed the UDP checksum text. Fixed the SM of ACK always from
              comments in mailing list and CBit bump.
          
              Second last call initiated on June 29th 2018, supposed to be closed
              today
          
              reviewed the comments from Pascal,
          
              WGLC to be extended by a week for Charlie and Juan Carlos to review
              and comment
          
              Tickets status
          
              Resolution for each Ticket are tracked:
              https://trac.ietf.org/trac/lpwan/report
          
              Dominique explains how the ticket system works and that the
              information when a ticket is created, how is was closed, etc.
          
              Single padding
          
              Discussed much during the interim meeting.
          
              Idea floated by Laurent.
          
              6 positive responses with no objection.
          
              first appeared in draft-14
          
              untill draft-13,
          
               - header compression turns IPv6 to bunch of bits. SCHC here is bit
               oriented. So before sending, padding needs to be done.
          
               - fragmentation, adds padding in the last fragment. Hence there
               are 2 paddings done.
          
               - atmost 7 bits in the first and second padding. hence overall 14
               bits.
          
               - why padding not done at each fragment :? as raised in most
               hackathons.
          
                  - because, we use the appropriate number of bits from the rest
                  of the payload instead of padding bits.
          
               - reassembly, extra bits removed since the SCHC compressed packet
               is byte aligned.
          
              in 14:
          
              - only need padding while sent of layer 2.
          
              - don't pad on the compression level if there is fragmentation
          
              - how the padding gets removed.
          
               - extra bits are ignored or removed at the decompression (based on
               the rule)
          
              Appendix-D (ticket 15)
          
              Text is still rough.
          
              Restructuring the list is required.
          
              Use-case, deployment
          
              Mapping of architectural elements
          
              L2 integrety
          
              RuleID numbering
          
              L2 word
          
              * If you don't use some parameters, you just state why and you don't
              specify them
          
              * Question: do we structure the list or we leave it as it is?
          
              Pascal: If the list is not normative, no need to put a lot of effort
              to structure it.
          
              Dominique: We received feedback that this list is needed from Suresh
          
              Pascal: The spec would work exactly the same whether this appendix
              is there or not, it's just a helper, right, so don't put a
          
              WGLC2 comments
          
              Comments from Lars, on Traffic Class.
          
               - Pascal: don't force the user to use the MO as Ignore. we could
               include it in, but since there is no transport we can not reflect
               out.
          
              But later if you have the tcp , then including ECN bits would be
              useful.
          
              Traffic class field contains ECN bits. If you use the "ignore"
              MO will bleach. LPWAN devices usually don't required ECN bits
          
              Laurent: The ECN bits are used for upper layers
          
              Pascal: If we do not mandate ignore we can leave it. Just make sure
              the text does not say that the field MUST be ignored.
          
              Dominique: OK
          
              * Dominique on Soichi feedback: All the libraries that compute CRC
              are byte aligned, so bit arrays make implementation difficult
          
              Arun: I agree
          
              Nicolas Sornin: I also agree
          
              * Review from Pascal: not fully filled all-0 window is complex and
              most readers jump to this conclusion anyway
          
              * Legal to have parial filling in all windows as of now, which makes
              the implementation a bit more unclear and takes longer.
          
              * Could mandate that the windows are full (generally the prefered
              way)
          
              * Could mandate that after the retransmission there is a new all-0
          
              * Could mandate ...
          
              Got 5 supports on the ML, no objection.
          
              JCZ: That is fine for the sender, for the receiver we should add
              extra text
          
              Pascal: The text is already there
          
              Pascal: Todo for Juan Carlos - check if the text addresses his
              question (should be the case already)
          
              * Pascal feedback: There are cases when the receiver does not know
              what to expect w=0 or w=1. In the given example, both are possible,
              but they represent different situations
          
              Comment #3 on fragmentation, text is hard to read. Suggestion is to
              move the state machine up.
          
              Ana: we could move the state machine  from the Appendix to the text
              as it is more clear than the text.
          
              Pascal: We could do that, but we would need to redo the WGLC.
          
              !!! THE ETHERPAD SERVER IS QUITTING INTERMITTENTLY, almost every 5
              mins :( yeah... down half the time...
          
              Laurent: Silently IGNORE, but if we send the ABORT when there is
              window+2 sequence, it could be dangerous because the Queue manitained
              by the network Gateway. (Needs to be discussed detailed)
          
              Dominique: has been in the discussion for quite some years. so this
              has to be defined somewhere properly.
          
              Alex: Having the statemachine makes the draft more readable and
              improves the quality of the draft.
          
              Pascal: to Charlie, need more time for the whole document or for
              the fragmentation ? Are you happy with SCHC-compression?
          
              Charlie: 3 weeks needed. fragmentation is the most complicated part
              of the document. How close of a review you want ? what was being
              mandated when Layer 2 is already doing fragmentation? (Pascal:
              ask Edgar for this)
          
              Pascal: Suggests to re-open the WGLC only for comments on
              fragmentation
          
              // my notes while I was offline
          
              Dominique: We should make this simple. Full windows is one issue,
              another one is ack-on-error and the dangerous situation is when
              there is a misalignment between sender and receiver.
          
              the text is hard to read and maybe pseudo-code will be easier
              to read. Laurent said that this is the reason to have the state
              machine. The
          
              Pascal: No reason not to, we just need to redo the WG last call
          
              Ana: In the state machine if you don't expect the current window,
              you drop
          
              Carles: I look forward to any form that better expresses our
              intent. The issue I see is that the reviewers have reviewed the text
              so far, so we might need more time
          
              Pascal: That is why we need the WG last call. People should review
              the SM and see if it matches well the text, even if we say - check
              only the fragmentation
          
              Alex: We need to produce a good-quality standard and the load on
              the reviewers should not be that big
          
              Pascal: Charlie, do you need to review the whole draft or just the
              fragmentation. Do you agree - are you happy with the compression
          
              Charlie: the fragmentation is the most complex part. The comments
              for the compression should be easily resolved. A question is - how
              close a review do you want? I had some concerns when the L2 already
              supports fragmentation.
          
              Pascal: The proposal is to reopen the WGLC only for the fragmentation
          
              // end of notes during offline period
          
              Charlie: I am sure some people are reading some parts in a slightly
              different way and they point to examples in the appendix that support
              their understanding
          
              Pascal: If we are pointed to errors, we need to fix them of course
          
              Juan Carlos: focus only on the fragmentation is okay. I would rather
              have the text being the normative side and the state machine being
              there to help implementers. I didn't go through the SM last night
          
              Pascal: The point is that the SM is very concise.  Without text,
              the state machine is hard to understand.
          
              Dominique: Yes, we need text and names for states in order to make
              it understandable
          
              Edgar: I support JCZ and - for an implementor it is very nice to have
              SM as I can just mirror it in my code. For understaing the standard,
              it is not that intuitive. I would prefer pseudo-code. Another point -
              if the SM is normative, I will need to mirror this in other documents
              and that might be very difficult if there are parts that are not used,
              if there are special cases, etc. Sometimes the why is very important
              as well - why you send an abort in a given case.
          
              Alex: A very nice point. 1) we need to improve the textual
              description. Maybe what we can do is to give some more time to
              the reviewers to review the text. Even if the SM is not normative,
              we need to review it again.
          
              Dominique: Suggestion, you have a three-way choice.
          
              1. use text as normative and SM in the appendix
          
              2. have a normative pseudo-code
          
              3. bring the SM as the normative and match with the text.
          
              Pascal: I totally agree with you. If we extend the WGLC, we will need
              to ask people to check the SM. But we will not have to go through
              a few months to redo the text.
          
              Juan Carlos: I would go for option 1. We still have to look at the
              SM. SM should support the text. that we would like to make more
              clear anyway
          
              Carles: My first choice is also option 1.
          
              Pascal: Then there is no need to redo the WGLC and we just can notify
              the WG
          
              Dominique: Option 3
          
              Abdussalam Baryun(From Jabber): Make the SM normative or remove it
              completely
          
              Alex: Dominique, my impression is that in any case we will need to
              write something like a pseudo-code
          
              Dominique: Yes, in the text it is very difficult to explain what is
              happening or we name the states and we explain things, which will
              be like pseudo-code
          
              Pascal: The text is already there and we need to just structure a
              bit in order to have what you explained.
          
              Dominique: if we want the text to be crystal-clear, it has to
              paraphrase the State Machine.
          
              Charlie: I strongly agree, this is the only way to remove
              ambiguity. Label states and arcs. Yet, I would not want to have the
              SM drawing as normative.
          
              Edgar: I have a similar concern. I understand that it will make it
              a lot of text in order to explain it, but that will make it a whole
              sequence that is easy to understand. It shouldn't be so mixed as
              it is right now. I think the text could be much better structured,
              so that it depicts the SM in a much better way. I don't know if
              the restructuring is option 1 or option 2. egIt is therefore a bit
              confusing for me what to vote for.
          
              Pascal: You need text to
          
              Patrick (jabber): if the text is to be normative, it must be correct
              and non-ambiguous, therefore the state machine is not necessary nor
              warranted
          
              Juan Carlos: Suggestion to have one command by paragraph
          
              Alex: It didn't take to a long time to restructure this, right.
          
              JCZ: it took me a while but...
          
              Alex: Option 1) SM is non-normative and we restructure the text that
              we have / 11
          
              Option 2) We have the text, but we need to put some pseudo-code
              around it /1
          
              Option 3) We make the SM normative and some text around it. / 8
          
              Jabber: option 1
          
                           option 2
          
              Alex: Option 1 is the most supported, option 2 - only one voice,
              option 3, some support. Let's take it to the WG
          
              Pascal: I saw some authors voting for both 1 and 3, but yeah, there
              is no clear concensus.
          
              Alex: I hear the point that Edgar made that the SM might complicate
              other technologies. We need to improve the text and we need to check
              now the SM maps with the text
          
              Pascal: Most of the work is exactly the same as the text needs to
              match it and be understandable. The only thing that I am afraid
              of is that if a tech needs only a subset, the SM will complicate
              it. Let's review the SM as if we will make it normative.
          
              JCZ: This might make us rethink the technology specific documents
          
              * Charlie suggested that some wording could be improved. If we don't
              fragment, can we still elide the UDP checksum
          
              Pascal: don't agree with it. Strength of using UDP (2) and L2 CRC(2)
              would be 4Bytes.
          
              Dominique: Still send the checksum.
          
              Pascal: the question is whether we
          
              Comment #3
          
              In no Ack mode N = 1 in current draft. JCZ proposes to allow N >
              1 in No-Ack mode
          
              JCZ: using non MAX_WIND_FCN value in FCN for transmitting in NoACK
              mode. This way the receiver would have the idea of how much fragments
              to expect ??
          
              Dominique: This is two separate changes. One is that N>1 be
              allowed in No-Ack mode. Another one is that FCN does not start at
              WIND_MAX_FCN. The latter one may have implications in other modes. We
              need time to discuss it
          
          (20 min)
          
              *    [11:07 (10:30)] draft-ietf-lpwan-coap-static-context-hc-04
              [45min]
          
              o    Presenter: Laurent Toutain -- Ricardo Andreasen
              o    Goal: WGLC; SCHC/OSCORE presentation
          
              Change text to explain the difference between CoAP and UDP/IPv6
          
              Add OSCORE implementation - has two parts - one for inner header
              compression and one for the outer one.
          
              * Reminder - the communication is not symetrical, so a better
              compression can be achieved in some cases using this.
          
              * We recommend to use a proxy in some cases to shorten the message
              ID and the token. Message ID, 16 bytes. MSB allows to compress it
              for LPWAN.
          
              * Token has a variable length. one way is to use the length given
              by the token length field of the coap. impose a new function for
              the token length.
          
              * URI query repeated, thats why we needed position.
          
              For Uri-path if we could combine multiple positions in some field
              combined in order to achieve better compression. This is would lead
              to complex implementation. We expect feedback from implementers.
          
              Define a matching list for a bunch of paths that shall be combined
              and use 1bit to compress two path fields instead of 2bit (if they
              were listed as separate fields).
          
              We have a discussion on the ML about coap blocks - whether we need
              it as we have fragmentation. No answer so far.
          
              To do: language revisions to make it more permissive/liberal, add
              some examples (CoMI ?)
          
              Ricardo Andreasen
          
              * Explains how OSCORE works
          
              * The ideas is to compress the inner-header before it is encrypted
              by OSCORE and compress the outer-header after the encryption
          
              Inner compression, as the same compression as a regular CoAP message
          
              The only change is that we need to handle the OSCORE option. We
              split that into 3 parts, because this way we can mask-out the MSB
              and just send the part that changes the most. There are 2 parameters
              that change a lot and usually the rest we can mask-out.
          
              We compared the compression with and without the protection and we
              saw a difference of around 10 bytes comming mostly from the PIV and
              ... The cost of 10 bytes is fairly consistent.
          
              Goran: I like to thank the authors, it is very nice. There is a slight
              confusion about the term cyphered text. The authentication-... can
              not be compressed. I point newcommers to this presentation as it is
              one of the best introductions we have.
          
              Francesca: it will be good the text to mandate the need of two
              rules....... You include the flag bit - maybe a bit obscure - ...
          
              Alex: You have 1 more min, so please send your feedback on the
              mailing list
          
              Francesca: You need to re-key if you run out of sequence number
          
          *    [11:25 (11:15)] draft-petrov-lpwan-ipv6-schc-over-lorawan-02
          [10min]
              o    Presenters: Nicolas Sornin (remote)
              o    Goal: present advancement
          
                  o          call for adoption ?
          
              Nicolas: 3 classes of device,
          
              class A: opens Tx whenever it wants. Provides two opportunities for
              reception after each transmission.
          
              class B: opens synchronous Rx windows, in addition to the mechanism
              described for Class A.
          
              class C: the device is listening all the time when it is
              not transmitting, it has the lowest latency, but is the most
              power-consuming one. The diffrent classes impact the way fragmentation
              is done
          
              Have to define parameters for each classes of devices.
          
              Proposed first set of parameters for fragmentation on 3 classes of
              devices. Needs feedback on this from the group regarding the trade
              off considered in the proposal.
          
              Presents the proposed parameters for fragmentations: different for
              uplinks and downlinks as uplink capacity is much more than downlink
              one.
          
              - Uplink: ruleID is 3 bits, DTag is 1 bit, 1 bit window, FCN 3 bits
          
              Every single downlink is ack'ed from the device, hence fcn size is
              1bit.
          
              We have implemented some examples with 3 rules, so feedback could
              be appreciated.
          
              Alex (Chair heat off): Have a prefix for pre-defined rules and have
              device specific rules
          
              Nicolas: Is it possible to have a variable length rule ID
          
              Alex: Yes, yes, it is possible.Variable length rule ID is allowed
              as per the current draft.
          
              Nicolas: What is the spirit of the IETF about default rules
          
              Alex: We should discuss this on the ML, but my feeling is that we
              should have some common rules to facilitate the implementations.
          
              Laurent: I also agree that having pre-defined rules to bootstrap
              could be useful. If the rule ID is 0, specify on how much bits it
              is represented.
          
              Nicolas: more things as to be done :
          
              * discuss and describe security model
          
              * describe specificities of 3 devices classes (A/B/C).
          
              * provide detailed frame exchange examples
          
              Feedback on SCHC, find a way for device to send rules to SCHC gtw
              (rule provisionning).
          
              we should have a way to provision in-band the context, as otherwise
              it will be a nightmare
          
              Pascal: We will look into that when we finish the SCHC draft and we
              are rechartered, but for sure that will be a very important part.
          
              Pascal: as soon as SCH draft is out, we recharter and intend to
              introduce work on provisioning.
          
              Nicolas : other suggestion is to have introductory rule and conclusion
              rule. Allows to interface legacy devices.
          
              Pascal: will discuss it on the mailing list.
          
              [Note enterd here by Dominique after the meeting: this suggestion
              was made earlier, captured as Ticket #14 and closed. We need to
              dicuss about it again].
          
              Nicolas: I am not familiar with the process, but I think it will be
              good if this document could become an official WG document
          
              Pascal: Yes, as there is no opposition in the hall, we will call
              for adoption on the ML and as soon as the WG is chartered for it,
              we will do it
          
          (10 min)
          *    [11:35 (11:25)] draft-zuniga-lpwan-schc-over-sigfox-03
          [15min]
              o    Presenters: Juan-Carlos Zuniga
              o    Goal: draft update and discussion about ACK-on-Error mode
              o          call for adoption ?
          
              Juan Carlos: SCHC OVER Sigox
          
              Added values on timers, values for fragmentation.
          
              needed some clarification on noack , presenting in next slides.
          
              Proposal: relax the specification, higher than 1 fcn size is
              allowed. If we didn't start at the MAX_WIND_FCN value, the receiver
              knows the number of fragments that it needs to expect.
          
              Proposal on ACK-error: Allow ACK-Error to track last 2 windows. The
              reason is that if we lose a single all-0 or it's ack means an abort
              and total loss of session. Receiver can request lost fragment from
              the previous window. there is some risk involved in managing the
              window bit.
          
              Pascal: ... the discussion earlier about the SM, with this proposal
              will make it much more complicated.
          
              Alex: I think you need to have an error in order to have a problem
          
              Ana: You are choosing Ack-on-error as you want to save your downlink
              and you use ack-always if you want to be able to handle this type
              of situations without abort.
          
              Alex: Let's discuss this on the ML
          
              Laurent: I understood that you have test results. Could you share
              the diference in the performance.
          
          *    [11:48 (11:40)] draft-minaburo-lpwan-nbiot-hc-01
          [5min]
              o    Presenter: Edgar Ramos
              o    Goal: discuss NB-IoT entities with SCHC
          
              Disucss what are the possibilities to continue further with the
              draft.
          
              2 ways of trasnmitting data:
          
               using contrl plane: stack included the control plane protocol
          
               using user plane. basically IP, using PDCP.
          
              conclusion for SCHC: using 3GPP standard interfaces, Non IP traffic.
          
              replace RoHC with alternative that could be SCHC. needs to take care
              of provisioning the parameters and functionality remains same.
          
              interest exist with 3GPP once SCHC becomes standard.
          
              There are 2 places where SCHC could be. In the NAS level or on
              Connected mode. In one of the case(Connected mode) the security has
              been established and in the other(NAS) it is not. That should be
              considered especially iff it is possible to reuse context...
          
              SCHC as application layer packets doesn't need 3GPP
              standardisation. It would be considered as NonIP traffic.
          
              implications is that intermediate hops cannot understand compressed
              IP headers.
          
              Pascal: if we are on the non-IP path, do we have guarantee that the
              packets are in order.
          
              Edgar: From the core network to the device they are in order. In
              the middle before I don't know if something could happen
          
              Pascal: In the core maybe there are multiple paths accross tunnels
              and if UDP is used, there might be reordering, sequencing needed.
          
              Edgar: This is something to check, but it depends also on the
              deployment
          
              Improve the document, missed the deadline for submission, have the
              newer version in the github.
          
              Alex: Thank you and I see the advancement
          
          (X)
          *    [SKIP - 11:45] draft-toutain-core-time-scale-00
          [5min]
              o    Presenter: Laurent Toutain
              o    Goal: Get support from LPWAN to request attention from CORE
          
          *    [11:56 (11:50)] draft-authors-lpwan-schc-802154
          [5min]
              o    Presenters: Charlie Perkins
              o    Goal: ?
          
              -  submitted the draft earlier this week.
          
              - 802.15.4w dealing with lowpower wide area. not official
              publication.
          
              - SCHC parameters specified. ruleID size = 3 bits,
          
               - padding to byte boundaries.
          
               - either CRC32 or CRC16.
          
               - already does fragmentation at 802.15.4 so not needed. But it is
               yet not analyzed whether the SCHC fragmenetation is better than
               the existing one, so this is something to be done.
          
              - Other 802.15.4w status. 4 MAC layer proposals. 2 PHY proposals.
          
              would love to hear any concerns to be forwarded to 802154 group.
          
          *    [11:55] AOB (Charlie Perkins on IEEE)                          [
          5min]
          
          



Generated from PyHt script /wg/lpwan/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -