Minutes IETF98: lpwan
minutes-98-lpwan-00

# Minutes, IETF 98 LPWAN WG Meeting #

Note: this document is formatted using Markdown
(https://daringfireball.net/projects/markdown/)

Agenda and Meeting information
==============================

    Meeting        :   IETF98 Wednesday, March 29, 2017 (CTZ)
    Time           :   13:00-15:00 Monday Afternoon session I (120min)
    Location       :   Zurich C, Swissotel
    Chairs         :   Pascal Thubert <pthubert@cisco.com>
                       Alexander Pelov <a@ackl.io>
    Responsible AD :   Suresh Krishnan
    URLs           :   http://tools.ietf.org/wg/lpwan
                       https://datatracker.ietf.org/wg/lpwan/
                       https://www.ietf.org/mailman/listinfo/lp-wan
                       http://etherpad.tools.ietf.org:9000/p/notes-ietf-98-lpwan

* Opening, agenda bashing [5 min] (Alexander, Pascal)
* LPWAN Overview Presentation and Discussion [15 min] (Stephen Farrell)
* LoRaWAN overview [15 min + 5mn Q&A] (Alper Yegin)
* SCHC LPWAN Fragmentation Header [15 min] (Carles Gomez)
* LPWAN Static Context Header Compression (SCHC) for IPv6 and UDP [10 min + 5mn
Q&A] (Ivaylo Petrov stepping in for Ana Minaburo) * LPWAN SCHC for CoAP [20
min] (Laurent Toutain) * SCHC Implementation [5 min] (Tomas Lagos) *
Implementation of SCHC over Sigfox [5 min] (Juan Carlos Zuniga) * Overview of
802.15.LPWA Interest Group Activities [10 min] (Charlie Perkins) * Possible
future work items [10 min] (Sri Gundavelli)

Resources
=========

* Agenda: https://datatracker.ietf.org/meeting/98/agenda/lpwan
* Links to audio streams, meetecho and jabber:
https://tools.ietf.org/agenda/98/#98-wed-1300-lpwan * Presented slides:
https://datatracker.ietf.org/meeting/98/session/lpwan/

Summary
=======

WG meeting lasted 1:55 hours.

This was the second meeting of the group after its forming. The room was full,
with many people standing or sitting on the floor. The progress from the last
meeting was presented, with a number of milestones reached ahead of time. The
creation, and the work of the Design Team (who's work is now over) surrounding
the compression and fragmentation were outlined. The changes in the main
documents were discussed in details. Two implementations were presented. More
outreach to the IEEE was also discussed, and ideas of topics of interest not
currently covered by the charter.

The first charter item - the LPWAN technology outline is in a stable shape. A
couple of options on how to orient the document were asked by the editor and
were confirmed. There is a part which needs more elaborated input from one of
the baseline technology providers. We expect the draft to be complete on time.

The second charter item is covered by two documents, which are also on track
and are expected to be delivered generally on time. The structure of the
documents fulfilling this item was also discussed, with the options to go with
four documents (framework, IP/UDP compression, fragmentation, CoAP
compression), three documents (framework+IP/UDP, fragmentation, CoAP
compression) or keeping the current structure of two documents
(framework+IP/UDP compression+fragmentation, CoAP compression). The decision
was to keep the current structure.

The SCHC compression for IPv6/UDP was presented. Slight changes in the
terminology. The main difference is the inclusion of the fragmentation part,
which had a dedicated presentation slot. The fragmentation is loosely based on
previous work presented in the previous session, significantly improved through
its coupling with the SCHC compression and taking special care of LPWAN
constraints. Two feedback modes - ACK and NACK - issued per fragment, per
window, or in non-reliable mode (e.g. no feedback) provide the technology
providers with a straightforward and rich way of complying with the min MTU
requirements of IP. The fragmentation section uses parameters, which can be
tuned by each technology provider, and which is not mandatory (e.g. a
technology which already has L2 fragmentation may choose not to mandate its
use). Many examples were provided. Some questions remain to be addressed, among
which how to address L2 MTU change between fragments, the downlink
fragmentation, and some questions related to the windowing counters in the rare
cases special fragments are lost.

The SCHC compression for CoAP was presented, with its new developments. A new
field is added to the context to indicate the direction of the rule, as
requests and responses may vary significantly (but are part of the same flow).
A new indication of the position of an option was also added (e.g. the order in
which options appear), which is necessary for the cases when an option is
repeated (for example URI-Path). The use of a CoAP proxy to improve the
compression was also described, where the proxy can handle some of the advanced
features suggested during the last session (e.g. statefully mapping an 8B token
with a 1B). Open questions include ways to enhance Observe- and Block- related
compression (e.g. delta-encoded values or proxy). Block-transfer is
complementary to the fragmentation, as Block supports a minimal size of 16
bytes, which is larger of the values of some of the baseline technologies.
Other questions of advanced CoAP compression were also discussed, such as the
possibility to compress, when there is variable number of options (e.g. prefix
URI-path, with variable suffix), as well as questions regarding the
compatibility with security mechanisms such as OSCOAP. An additional and
important question is also to reconsider the timers defined for CoAP, which are
not suitable for the types of delays we're observing in LPWANs, and would need
to be redefined to be orders of magnitude larger. Reviewers volunteered for the
document and feedback is expected to profile the compression approach (e.g.
some of the open issues may be non-essential, and some may be of great
importance depending on the trafic). All in all, the draft in its form is a
solid base and the first implementations' feedbacks, and additional
contributors will allow to fine-tune it.

In addition to the charter-item related documents, there were two
implementation-oriented presentations, three technology-related ones, and an
indication of problems which could be considered in the future. The Lora
document was also presented in details. Other technologies were presented for
information, as requested by IEEE members, to provide update on the work of
802.15. LPWAN interest group and the possible future works in this direction.
An implementation on top of 6lo was presented, along with an implementation of
SCHC running on top of the live Sigfox network. Finally, the possibility of
working on the protocols used for managing the LPWAN infrastructure was
presented as a problem that may need to be considered in the future.

Action items
============

Announce decision of SCHC IP/UDP/CoAP document structure.
Follow-up on the WI-SUN contribution for the LPWAN overview document.
Follow-up on the reviewers who volunteered to review the SCHC CoAP draft.
Identify reviewers for the IP/UDP draft.

Volunteers
==========

* Scribes
    * Dominique Barthel
* Jabber
    * Diego Dujovne

Minutes
=======

13:00> Opening, agenda bashing (5 min, Alexander, Pascal)
    * Note Well, Bleu Sheets, note takers, Jabber scribe.
    * Agenda? Charlie's presentation will be complemented with other slides by
    Pat Kenney * Alex reminds the history, status of the WG. * Review of
    milestones. All achieved so far. Coming-up: 3 milestones before next IETF
    meeting. * Design team formed in Dec, ran until beg March. Everything on
    the mailing list, documents are out. * Read and comment
13:04> LPWAN Overview Presentation and Discussion (15 min)
  Presenter: Stephen Farrell
  https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/
    * draft edited on GitHub.
    * goal is to provide background info to IETF community on the 4
    technologies of choice. * Issue #1: how much text in this doc vs. in the
    individual drafts. * Issue #2: loose terminology vs. full architecture
    description? * who read the draft? about 10-12. * Pascal: this is probably
    the only doc that will end up as an RFC. Put here whatever is needed *
    Suresh: on Issue 2, prefer to go with Option 1 for "well-known" reasons. *
    Pascal: also missing WiSun material, to be added. * Pat: Bob Heile will do
    it :-)
13:09> LoRaWAN overview (15 min + 5mn Q&A)
  Presenter: Alper Yegin
  https://datatracker.ietf.org/doc/draft-farrell-lpwan-lora-overview/
    * not presented at Seoul because could not attend.
    * draft describes LoRaWAN technoloogy.
    * has bidirect unicast and downlink multicast.
    * Join Server equivalent to AAA server, holds keys.
    * star topology, no mesh *in the LoRaWAN Alliance*
    * datarate and tx power can be adjusted dynamically to reduce air time and
    energy * duty cyle limitations, continent- and subband-specific. * in Class
    A, only opportunity to do downlink is right after uplink transmission. Best
    for sensors. * Class B has periodic listening, Class C has receiver
    permanently on (but when transitting). * Mac commands are available for
    carrying information for network optimization such as signal to noise ratio
    as seen from the end-device, configuring channels, etc. * The Mac commands
    can be piggybacked on regular data frames. * most implementations have
    proprietary app stack. Some experimenting with Zigbee, etc. IP would go
    there. * 24 bit Net-ID assigned by LoRa Alliance. * AES 128 crypto. In
    OTAA, sessions keys generated out of master key. Session keys can be
    refreshed. * MAC commands can be encrypted if placed in payload instead of
    piggybacking them as options in the MAC header (which are not encrypted). *
    Some roaming in 1.0. Better roaming in upcoming LoRaWAN 1.1 * Behcet: why
    roaming? Alper: pets, container tracking, ...
13:20> SCHC LPWAN Fragmentation Header (15 min)
  Presenter: Carles Gomez
  https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/
    * short frag header size. Also various options for reliability provided.
    * LPWAN technologies have typical payload 10-100s bytes, needs
    fragmentation. * Unreliable mode, Reliable per packet, per window of
    fragments. * positive and negative Acks. * packet is identified by a rule
    ID followed by a CFN (Compressed Fragment Number) * CFN is decreasing order
    from (2^N)-2 to 0 * fragment number : last segment has special value to
    signal end of packet * ACK: has a rule ID to identify the ACK. bitmap if
    loss detected. Bit in map is 0 if fragment lost. * Last fragment has a MIC
    computed before the fragmentation. * star topology: no out of order arrival
    expected from the network. * Pascal: NACK more than ACK. ??? * examples:
        * example 2: in the right hand case, NACK only transmitted back after
        all fragments have been sent
          fragment renumbering: since "holes" in assembly buffer are in
          sequence, retransmitted fragments can use 6,5 and 4 as numbers
        * example 3: reliable per packet
        * example 4: reliable per window.
        * example 5: positive ack behaviour at end of window.
    * Carsten: why would choose window reliability mode? Why not fix the
    per-packet mode instead? Can be fixed such that is not ambiguous. * Carles:
    were different proposal in the design team. Will revisit * Gabriel: MAY
    implies advise people (nodes) not to send the NACK. * Carles: will make
    sure the text is inline with intention. * JCZ: clarify if node can change
    mode during session. * Carles: within packet, certainly not. Between
    packets, maybe. * Pascal: wrt 6LoWPAN, this addresses different
    technologies with different needs. We could have profiles that make some
    choices. * Laurent: sender is not listening every time. Some rendez-vous
    point to receive the acks is good. * todos and discussion: currently, no
    NACK for lost frag with CFN=0 or CFN=11..1 * disccuss the behavior when the
    MTU change during the transmission, define a mechanism or drop the packet.
         * for technologies that have downlink after uplink, ack at each uplink?
    * Alex: who has read the draft? about 10.
    * Alex: please provide comments. Discuss the options on the mailing list.
    * Gabriel (modifying previous comment): this is not meant to be normative.
    Could also remove all normative language.
13:40> LPWAN Static Context Header Compression (SCHC) for IPv6 and UDP (10 min
+ 5mn Q&A)
  Presenter: Ivaylo Petrov (for Ana Minaburo)
  https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/
    * SCHC pronounced chic.
    * Explains how SCHC works: context consists of a set of rules. Compressor
    matched packet against rules. Send rule ID (and complementary data)
      instead of packet.
    * To choose a Rule the information on the header needs to match exactly the
    information on the rule. * compresses IP header and possibly upper layer
    header at same time * The description of the header is made on the rule, it
    is made in order of the header format. * The SCHC layer is between L2 and
    the L3 * In the previous draft field_ID was not included in the rule, but
    it is used to match the header fields between the Rule and the header to be
    compressed * We put all the MO from the both draft CoAP and SCHC in this
    draft in order to give all the specification of SCHC in this draft. * We
    create a new MO to iclude a list of options more for CoAP but it could be
    used for IP@. * matching list coming previouslu from the SCHC CoAP draft as
    been moved to SCHC IPv6 * Matching list allows to reduce the size of a
    large filed * matching operators unchange wrt previous version of draft. *
    Change of matching* to matching-length and matching-checksum * Pascal:
    notice how different this is from 6LoWPAN. Context to be installed in the
    device. Much more stateful.
13:55> LPWAN SCHC for CoAP (20 min)
  Presenter: Laurent Toutain, Ana Minaburo
  https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/
    * moved mechanism into above draft (IPv6 and UDP), only behavior described
    here. * CoAP Token are large but few values actually used if the "thing" is
    the client. (We believe that for LPWAN the token may be smaller). Not true
    if "thing" is server and client is onthe Internet * CoAP has variable parts
    of the header that can have a different order on URI * Use a proxy to
    translate the token values. * URI compression. Strings may appear at
    different hierarchical postions. Distinguish position of appearance within
    the tree. * Asymmetry between the request and the response. Introduced
    direction entry in the rule. Use the same rule for request and response by
    using the direction in order to get the correct information of the header.
    In IPv6 and UDP the default will be bidirectional because these protocols
    are symmetrics. * can be merged with IPv6 and UDP rules. * doubling the
    number of rules amounts to one extra bit to be transmitted over the radio.
    * Suresh: Values equals X or Y * Laurent:Serialisation is very heavy, the
    point is to decide if we create 2 rules or we ignore and send this
    information * need to check if not breaking end-to-end security, like
    OSCOAP * time constants for CoAP may need to be adjusted * Ana (over
    Jabber): Can we compress only IP, UDP and CoAP or all the stack? * Laurent:
    can have different set of rules for CoAP and UDP/IPv6, or combined. * Alex:
    how many have read the draft? 7-8. We need input for this work * Alex:
    still being improved, but works as is. Time for review. * Pascal: in-depth
    review. * Diego, Juan-Carlos, Michel V, one more Carsten Borman * Pascal:
    question to Suresh. Reviewing one big draft would be difficult. Split in 2,
    3? * Suresh: which would be the parts? Pascal: technique, application to
    protocols. * Suresh: fold the technique into another document. No
    deliverable that is not useful by itself. * Laurent: would rather have a
    document that describes the mechanism, other documents to apply to IPv6,
    CoAP etc. * Suresh: but document not useful by itself. * Alex (chair hat
    off): agree with on document with technique and IPv6+UDP. As it is right
    now. * Kerry: if split the way Laurent suggests, might get more reviewers
    from CoRE. * Suresh: already promised there will be reviewers in CoRE.
    Don't want "working group artifacts". Seems far fetched that somebody
      would want to do CoAP compression without IPv6 and UDP.
    * JCZ: keep the split in mind, have clear sections, but in the same
    document. So CoAP document can refer to section. * Alex: will announce
    decision on mailing list and ask for feedback.
14:20> SCHC Implementation (5 mn)
  Presenter: Tomas Lagos
    * implements IPv6 over LoRa, with header compression and ND.
    * first tried with 6LoWPAN: header reduced to 4 bytes
    * with SCHC on 6LoWPAN header: implementation mistake to be fixed (did I
    get this right???) * describes setup. * with link-local addresses on Nodes
    and Gateway, ICMPv6 Req/Reply, SCHC over 6LoWPAN. * next, will apply SCHC
    directly to IPv6, not 6LoWPAN.
14:27> Implementation of SCHC over Sigfox (5 mn)
  Presenter: Juan Carlos Zuniga
    * SCHCago ;)
    * demo at Bits-n-Bytes, on Sigfox live network here in Chicago.
    * one device is Raspberry PI, does both cellular and Sigfox. Another device
    is regular "dumb" Sigfox device * in Sigfox, downlink only shortly after
    uplink.
14:32> 15.4k and 15.4g Pat Kenney
    * 15.4k
        * critical imfrastructure monitoring. Star topology. Changing
        propagation. Asymmetric links. * frame size 12- for DSSS.
    * 15.4g
        * 3 different PHY layers, datarates 4.8-400kbps
        * focusses on mesh, has channel hopping, FEC, common signalling mode to
        facilite multi-PHY management
    * Alex: look forward to seeing the 4.k part go into Stephen's draft.
14:40> Overview of 802.15.LPWA Interest Group Activities (10 min)
  Presenter: Charlie Perkins
    * Interest Group assembled to see of interest to do work, then Study Group,
    then Task Group. * re-iterates distinguishing characteristics fo LP-WAN. *
    Joerg Robert referred to in the slides is the chair of Interest Group *
    report due in July that will summarize use cases, regulatory constraints,
    channel models. * Conclusion: mostly for monitoring applications. Send
    additional use-cases that you want considered. * Pascal: 15.4k not in the
    original charter of this group. Any document readily available on
    applicability? * Pat: 4k and 4g come close to the mark. * Pascal: will put
    information together and make it available to this group.
14:50> Possible future work items (10 mn)
  Presenter: Sri Gundavelli
    * key gaps: agents on the gateway talking to the network server. No
    standardized intrface between network server and application layer *  2
    interfaces manage all the objects on the network * list of parameters to
    configure objects, statistics, * summary: stadardization of interface
    between NS and GW, NS and AS, radio resource managmeent on gateways
14:53> meeting ends