# 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 Alexander Pelov 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