1 / 35

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [ SC Report for July 2016 Session ] Date Submitted: [ 23 July 2016 ] Source: [ Patrick Kinney ] Company [ Kinney Consulting LLC ] Address [ Chicago area, IL, USA ]

claral
Download Presentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title:[SC Report for July 2016 Session] Date Submitted: [23 July 2016] Source: [Patrick Kinney] Company [Kinney Consulting LLC] Address [Chicago area, IL, USA] Voice:[+1.847.960.3715], E-Mail:[pat.kinney@kinneyconsultingllc.org] Re:[SC Report for July 2016 Session.] Abstract:[Report for the July 2016 Session] Purpose:[] Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15. <Pat Kinney>, <Kinney Consulting LLC>

  2. Instructions for the WG Chair The IEEE-SA strongly recommends that at each WG meeting the chair or a designee: • Show slides #1 through #4 of this presentation • Advise the WG attendees that: • The IEEE’s patent policy is described in Clause 6 of the IEEE-SA Standards Board Bylaws; • Early identification of patent claims which may be essential for the use of standards under development is strongly encouraged; • There may be Essential Patent Claims of which the IEEE is not aware. Additionally, neither the IEEE, the WG, nor the WG chair can ensure the accuracy or completeness of any assurance or whether any such assurance is, in fact, of a Patent Claim that is essential for the use of the standard under development. • Instruct the WG Secretary to record in the minutes of the relevant WG meeting: • That the foregoing information was provided and that slides 1 through 4 (and this slide 0, if applicable) were shown; • That the chair or designee provided an opportunity for participants to identify patent claim(s)/patent application claim(s) and/or the holder of patent claim(s)/patent application claim(s) of which the participant is personally aware and that may be essential for the use of that standard • Any responses that were given, specifically the patent claim(s)/patent application claim(s) and/or the holder of the patent claim(s)/patent application claim(s) that were identified (if any) and by whom. • The WG Chair shall ensure that a request is made to any identified holders of potential essential patent claim(s) to complete and submit a Letter of Assurance. • It is recommended that the WG chair review the guidance in IEEE-SA Standards Board Operations Manual 6.3.5 and in FAQs 14 and 15 on inclusion of potential Essential Patent Claims by incorporation or by reference. Note: WG includes Working Groups, Task Groups, and other standards-developing committees with a PAR approved by the IEEE-SA Standards Board. <Pat Kinney>, <Kinney Consulting LLC>

  3. Participants, Patents, and Duty to Inform All participants in this meeting have certain obligations under the IEEE-SA Patent Policy. • Participants [Note: Quoted text excerpted from IEEE-SA Standards Board Bylaws subclause 6.2]: • “Shall inform the IEEE (or cause the IEEE to be informed)” of the identity of each “holder of any potential Essential Patent Claims of which they are personally aware” if the claims are owned or controlled by the participant or the entity the participant is from, employed by, or otherwise represents • “Should inform the IEEE (or cause the IEEE to be informed)” of the identity of “any other holders of potential Essential Patent Claims” (that is, third parties that are not affiliated with the participant, with the participant’s employer, or with anyone else that the participant is from or otherwise represents) • The above does not apply if the patent claim is already the subject of an Accepted Letter of Assurance that applies to the proposed standard(s) under consideration by this group • Early identification of holders of potential Essential Patent Claims is strongly encouraged • No duty to perform a patent search Slide #1 <Pat Kinney>, <Kinney Consulting LLC>

  4. Patent Related Links All participants should be familiar with their obligations under the IEEE-SA Policies & Procedures for standards development. Patent Policy is stated in these sources: IEEE-SA Standards Boards Bylaws http://standards.ieee.org/develop/policies/bylaws/sect6-7.html#6 IEEE-SA Standards Board Operations Manual http://standards.ieee.org/develop/policies/opman/sect6.html#6.3 Material about the patent policy is available at http://standards.ieee.org/about/sasb/patcom/materials.html If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at patcom@ieee.org or visit http://standards.ieee.org/about/sasb/patcom/index.html This slide set is available at https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.ppt Slide #2 <Pat Kinney>, <Kinney Consulting LLC>

  5. Call for Potentially Essential Patents • If anyone in this meeting is personally aware of the holder of any patent claims that are potentially essential to implementation of the proposed standard(s) under consideration by this group and that are not already the subject of an Accepted Letter of Assurance: • Either speak up now or • Provide the chair of this group with the identity of the holder(s) of any and all such claims as soon as possible or • Cause an LOA to be submitted Slide #3 <Pat Kinney>, <Kinney Consulting LLC>

  6. Other Guidelines for IEEE WG Meetings • All IEEE-SA standards meetings shall be conducted in compliance with all applicable laws, including antitrust and competition laws. • Don’t discuss the interpretation, validity, or essentiality of patents/patent claims. • Don’t discuss specific license rates, terms, or conditions. • Relative costs, including licensing costs of essential patent claims, of different technical approaches may be discussed in standards development meetings. • Technical considerations remain primary focus • Don’t discuss or engage in the fixing of product prices, allocation of customers, or division of sales markets. • Don’t discuss the status or substance of ongoing or threatened litigation. • Don’t be silent if inappropriate topics are discussed … do formally object. --------------------------------------------------------------- See IEEE-SA Standards Board Operations Manual, clause 5.3.10 and “Promoting Competition and Innovation: What You Need to Know about the IEEE Standards Association's Antitrust and Competition Policy” for more details. Slide #4 <Pat Kinney>, <Kinney Consulting LLC>

  7. SCmaintenance/SCwng Officer Chair: Patrick Kinney Vice Chair Ben Rolfe Secretary Slide 7 <Pat Kinney>, <Kinney Consulting LLC>

  8. Chair’s Role http://ieee802.org/Mike_Spring_Article_on_Stds_Process.pdf …the chairperson of the working group is key to what and how fast a standard is produced. The chair of the committee acts as a facilitator with little power to legislate. The chair must be knowledgeable about the subject but also know how a standard may be used by various segments of the industry. A chairperson should be a leader-diplomat-observer, in equal proportions. Also, the chairperson should not be a doer, perfectionist or obstructionist. This is consistent with the view of the chairperson as a skilled leader with strong negotiation skills who delegates. Slide 8 <Pat Kinney>, <Kinney Consulting LLC>

  9. SC Meeting Goals (Agenda 15-16-0455-02) • SC Maintenance Monday 26 July, PM2 • Approve agenda, approve minutes, • Discuss any issues with published standards • Discuss any issues with the Operations Manual • SC IETF Tuesday 26 July, AM1 • Status Update: 6tisch, Core, 6lo, Roll, Detnet, and lp-wan • Liaison communications requests/discussions • Joint Meeting between 802.15 and 802.1 Tuesday 26 July, PM3 • WiFi liaison stating a perceived market need to interwork between 802.11ah and 802.15.4g at layer 2 • 802.15 TG status reports • 802.1 efforts that should be considered by 802.15 • SC WNG Wednesday 27 July, AM2 • "History and Implementation of the IEEE 802 Security Architecture” • “IEEE Standards for Low Power Wide Area Networks” Slide 9 <Pat Kinney>, <Kinney Consulting LLC>

  10. SC Maintenance • Agenda approval (15-16-0455-01) • Approve previous minutes(15-16-0250-00) • Discussion on any issues with published standards • ? • Discussion on any issues with the Operations Manual • ? Slide 10 <Pat Kinney>, <Kinney Consulting LLC>

  11. SC IETF • Agenda approval • Status Updates • 6tisch • Core • 6lo • Roll • Detnet • lp-wan (bof) • IEEE 802.15 and IETF liaison communications <Pat Kinney>, <Kinney Consulting LLC>

  12. SC IETF 6tisch • Draft-ietf-6tisch-minimal • Rev16 published, now in AD follow-up • Draft-ietf-6tisch-6top-protocol • Rev 1 published, tested at ETSI plugtest • Draft-ietf-6tisch-6top-sf0 • Rev 1 published, tested at ETSI plugtest • Draft-ietf-6tisch-architecture • Rev 10 published • Next Step • Submission of Draft-ietf-6tisch-6top-sublayer to IESG <Pat Kinney>, <Kinney Consulting LLC>

  13. SC IETF Core • draft-ietf-core-coap-tcp-tls-03 • changes required to use CoAP over TCP, TLS, and WebSockets transports • draft-ietf-core-resource-directory-08 • direct discovery of resources is not practical due to sleeping nodes, dispersed networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. • tutorial of above starts at page 13 of http://ipj.dreamhosters.com/wp-content/uploads/issues/2016/ipj19-2.pdf • draft-ietf-core-links-json-06 • represent collections of Web links in JSON for outside of constrained environments, and in CBOR for inside constrained environments. This specification defines a common format for this. • In last WGLC • Roadmap • relationship to LWM2M; should COMI and LWM2M converge, and, if yes, how? <Pat Kinney>, <Kinney Consulting LLC>

  14. SC IETF Core(Tuesday 2016-07-19) • draft-ietf-core-block-21.txt is in the RFC editor queue. • draft-ietf-core-etch–01: WGLC is completed, issues discussed. To be determined: 4.12 vs. 4.09.  When that is settled, updated version to be submitted to IESG. • draft-ietf-core-links-json–06 is in the middle of WGLC and was briefly discussed.  There are some claims in the document that it considers a larger world of JSON-LD etc.; the intention however is to be a simple RFC 6690 mapping and those claims will be cut down. • draft-ietf-core-coap-tcp-tls–03: The merge of TCP/TLS, Websockets, Signaling, and BERT was completed in this version.  Several issues discussed.  In particular, there was in-room consensus to follow the lead of RFC 7252 and make the use of TLS mandatory to implement with the larger number of transport schemes now available • draft-silverajan-core-coap-protocol-negotiation-03 was discussed. There is good interest in this ongoing work, some of which is also related to other ongoing work in T2TRG. • draft-ietf-core-resource-directory–08 is nearing WGLC; reviewers have been identified. • Brief introductions were made for •  draft-gomez-core-tcp-constrained-node-networks–00, •  draft-groves-coap-webrtcdc–00, •  draft-zheng-core-coap-lantency-evaluation–00. • For draft-bormann-core-cocoa-04, there was in-room consensus for working-group adoption; to be confirmed on the list. <Pat Kinney>, <Kinney Consulting LLC>

  15. SC IETF Core(Thursday 2016-07-21) • draft-ietf-core-http-mapping-13 took some minor fixes and has been submitted to IESG • For the core-interfaces draft, the split was confirmed into draft-ietf-core-interfaces–05 and draft-groves-core-dynlink–00 (plus some material that was removed and maybe can be picked up by T2TRG); as not enough people had read the split-off draft-groves, we will take the otherwise obvious adoption to the list. • draft-ietf-core-yang-cbor–02: target is to do some additional validation with the NetMod experts and check again by end of September. There are a couple of implementations ongoing. • draft-somaraju-core-sid–01. One suggestion was to use an OID subtree. Too few people had read the newest version for room consensus on working-group adoption, but no one against; to be taken to the list. • draft-veillette-core-cool & draft-vanderstok-comi: around 6 people read the draft, agreement on splitting out the more advanced features so a basic specification can be completed by the end of the year. Work ongoing on mapping YANG and LWM2M/IPSO objects. Some concerns about the diagnostic value of SIDs in debugging and possible problems with YANG "choice", work needs to continue. • draft-hartke-core-e2e-security-reqs–01: good rewrite; further requirements are being identified, discussion to be taken to the mailing list. • draft-selander-ace-object-security–05: room consensus to adopt as WG item, to be confirmed on the mailing list. • draft-ietf-core-senml–02: good ongoing discussion that should be completed on the mailing list. • draft-koster-core-coap-pubsub–05: brokerlesspubsub has been added. Take adoption to mailing list but clear room consensus already (~10 people), reviewers identified. <Pat Kinney>, <Kinney Consulting LLC>

  16. SC IETF 6lo • draft-ietf-6lo-dispatch-iana-registry-03 • This document updates RFC4944 and RFC6282 by defining the ESC extension byte code points including registration of entries for known use-cases at the time of writing of this document • Ready for IESG submission after draft edits • draft-ietf-6lo-paging-dispatch-02 • introduces a new context switch mechanism for 6LoWPAN compression, expressed in terms of Pages and signaled by a new Paging Dispatch • Passed last call but missing Shepard Review • draft-thubert-6lo-rfc6775-update-00 • update to 6LoWPAN Neighbor Discoveryto clarify the role of the protocol as a registration technique, and provide enhancements to the registration capabilities, in particular for the registration to a backbone router for proxy ND operations • draft-ietf-6lo-privacy-considerations-01 • how a number of privacy threats apply to technologies designed for IPv6 over networks of resource-constrained nodes, and provides advice to protocol designers on how to address such threats in adaptation layer specifications for IPv6 over such links. <Pat Kinney>, <Kinney Consulting LLC>

  17. SC IETF ROLL • When to use RFC 6553, 6554 and IPv6-in-IPv6 • draft-ietf-roll-useofrplinfo • Presenter noted that ‘draft-ietf-6man-rfc2460bis-05’ could have a positive impact on routing and presented three scenarios with and without 2460bis • Source-Routed Multicast for RPL • draft-bergmann-bier-ccast • Use of Bloom filter concept • Concept uses a hash function, noting that although false positives create spurious transmissions wasting energy, the behavior is still functionally correct. Question as to how bad is energy waste compared to the energy saved by sending less packets. • Presented a numerical analysis with up to 100 forwarders • Introduces MLAO. Might use a 6LoRH header. • Noted that this was implemented in Contiki in 2013 (along with a non-storing mode) <Pat Kinney>, <Kinney Consulting LLC>

  18. SC IETF ROLL • DIS modifications • draft-gundogan-roll-dis-modifications-00 • desiring to make it quieter, there are 3 behaviors to modify: • DIS type and Trickle timer: Proposes DIS flags to have better control on responses, and response spreading in time if collisions are expected. • Selectivity of DIS requests: described current behavior of selectivity of multicast DIS messages and proposed improved behavior. • Information carried by DIO. Desired: be able to tell in the DIS which information should be included in DIO response; proposed R flag and TLV to do that. • MPL Forwarder Select • draft-vanderstok-roll-mpl-forw-select • dense network with MPL forwarding creates lots of forwarding. • to reduce the number of forwarders an algorithm that automatically selects the forwarders could be advantageous. Assumption used is net is relatively stable. • AODV-RPL • draft-satish-roll-aodv-rp • No-Path DAO Problem Statement • draft-jadhav-roll-no-path-dao-ps-00 <Pat Kinney>, <Kinney Consulting LLC>

  19. SC IETF Detnet • Use cases – update • draft-ietf-detnet-use-cases-10 • Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-1.pptx • DetNet Architecture • draft-finn-detnet-architecture-06 • DetNet Data Plane Protocol and Solution Alternative • draft-dt-detnet-dp-alt-01 • DetNet service model • draft-varga-detnet-service-model-00 • DetNet flow information model • draft-zha-detnet-flow-info-model-00 <Pat Kinney>, <Kinney Consulting LLC>

  20. SC IETF lp-wan (bof) • Applicability and Gap analysis • draft-minaburo-lp-wan-gap-analysis • draft-gomez-lpwan-ipv6-analysis (Analysis of IPv6 over LPWA: design space and challenges) • Technology slot 1: 3GPP LPWA (NB-IoT / EC-GSM-IoT / Cat-M1) • draft-ratilainen-lpwan-nb-iot-00 • use licensed band from already deployed networks instead of unlicensed bands such as sigfox • three operation modes: use one gsm band, use the guard band (whitespace) in band using LTE band • receiver sensitivity -141dBm, QPSK, 180 kHz bandwidth. • Packet data convergence protocol (PDCP) right below IP, 1600 bytes. Use all the already existing mechanisms (NAS: Non access stratum and AS: Access Stratum) • Mutual authentication. Shared secrets on the user. <Pat Kinney>, <Kinney Consulting LLC>

  21. SC IETF lp-wan (bof) • Technology slot 2: IEEE LPWA (Wi-SUN, IEEE 802.15.4g) • https://www.ietf.org/proceedings/96/slides/slides-96-lpwan-8.pdf • LPWAN’s target is narrower than the domain covered by IEEE802.15.4 • 802.15.4 is highly flexible with a range of different capabilities • Allows for optimized L1/L2 approaches depending on application (in-building, Industrial IoT, Field Area Networks of various classes, etc) • Supports both structured and ad hoc, self forming network architectures • Technology slot 3: LoRa • draft-vilajosana-lpwan-lora-hc-00 • Modulation - LoRa(spread spectrum), Frequency - Sub-GHz ISM • Channel bandwidth - 125-500 KHz, Data rate - 300 bps – 50 kbps • Gateway sensitivity -142 dBm/300bps, Range 10+ km, deep indoor coverage • Payload size 11 – 242 bytes (variable) • Battery consumption 10mA RX / 32mA (14dBm) TX -- 10+ year • Communication type Bidirectional unicast, network multicast <Pat Kinney>, <Kinney Consulting LLC>

  22. SC IETF lp-wan (bof) • Technology slot 4: SIGFOX • draft-zuniga-lpwan-sigfox-system-description-00 • Uplink • Channelization mask: 100 Hz (600 Hz in the USA) • Uplink baud rate: 100 baud (600 baud in the USA), Modulation scheme: DBPSK • Link budget: 155 dB (or better) • In Europe, the UNB uplink frequency band is limited to 868,00 to 868,60 MHz, with a maximum output power of 25 mW and a maximum mean transmission time of 1% • Downlink • Channelization mask: 1.5 kHz, Downlink baud rate: 600 baud Modulation: GFSK • TX power: 500 mW (4W in the USA), Link budget: 153 dB (or better) • In Europe, the UNB downlink frequency band is limited to 869.40 to 869.65 MHz, with a maximum output power of 500 mW with 10% duty cycle • Unicast asynchronous communications • Max limitation: 140 Uplink vs. 4 Downlink messages per day • Limitations can be slightly relaxed depending on system conditions • Fragmentation and encryption at application layer • L2 security • Message authentication code and unique device ID • Key management: pre-provisioned <Pat Kinney>, <Kinney Consulting LLC>

  23. SC IETF lp-wan (bof) Charter Point 1 • Produce an Informational document describing and relating some selected LPWA technologies. This work will document the common characteristics and highlight actual needs that the IETF could serve; but it is not an intention to provide a competitive analysis. It is expected that the information contained therein originates from and is reviewed by LPWA stakeholders, and that this WG may leverage the resulting document to suggest new activity in other WGs Charter Point 2 • Produce best practice documents highlighting potential areas where IETF technologies may be leveraged; these documents may eventually be published as Informational RFCs. It is an expectation that the resulting document(s) may contribute to the interaction with LPWA stakeholders and lead to additional work in the future. Envisioned topics include security, management, and cross-layer optimizations. <Pat Kinney>, <Kinney Consulting LLC>

  24. SC IETF lp-wan (bof) Charter Point 3 • Produce Standard Track documents to enable the compression of a CoAP/UDP/IPv6 packet over LPWA. Considering the extreme constraints, the work will focus on a generic YANG data model to describe the compression, and protocols to install the related state at the compression end-points; the work will also include, for the selected technologies, specific Standard Track documents to describe how the fields relevant to the decompression are encoded over the air, if any Charter Point 4 • Produce a document to enable the fragmentation of larger packets over LPWA, either as a Best Practice leveraging existing technology, or as new Standard Track document if that is deemed necessary. <Pat Kinney>, <Kinney Consulting LLC>

  25. SC IETF IEEE 802.15 and IETF liaison communications • 6lo: Neighbor discovery (RFC6775) could be further optimized to reduce neighbor discovery traffic. SC IETF will define edits to RFC6775 to show possible optimization. • lp-wan: SC IETF can identify solutions to numerous problems stated for lp-wan. SC IETF could produce a document describing the behaviors in 802.15.4 (LECIM) and 802.15.9 (KMP) that address the noted problems. • 6lo: SC IETF could identify header compression methods that apply to IP but could be extended to MAC and PHY by IEEE 802.15. <Pat Kinney>, <Kinney Consulting LLC>

  26. Joint Meeting between 802.15 and 802.1 • Agenda approval • WiFi liaison stating a perceived market need to interwork between 802.11ah and 802.15.4g at layer 2 • 802.15 Relevant TG status reports • Update on 802.15.10: L2R status • Update on 802.15.12: ULI status • Update on 802.15.3 • 802.15.3m: Revision • 802.15.3d: 100 Gbit/s Wireless • 802.15.3e: High Rate Close Proximity • 802.1 efforts that should be considered by 802.15 Slide 26 <Pat Kinney>, <Kinney Consulting LLC>

  27. Joint Meeting between 802.15 and 802.1 • WiFi liaison stating a perceived market need to interwork between 802.11ah and 802.15.4g at layer 2 Slide 27 <Pat Kinney>, <Kinney Consulting LLC>

  28. Joint Meeting between 802.15 and 802.1 • Update on 802.15.12: ULI status • Working on Deliverables and Architecture • Deliverable items: • Define ULI architecture to provide extensibility • 802.15.4 device configuration (MAC & PHY) • Regulatory configuration, e.g. PHY Configuration as per country of operation, Device class, Duty cycle constraints, CCA settings (time, threshold, mode) • Protocol differentiation (dispatch) via EtherType • Align IEEE 802.15.9 and IEEE 802.15.10 with ULI • L2 protocol extensions from other organizations, e.g. IETF 6tisch 6top, et al Slide 28 <Pat Kinney>, <Kinney Consulting LLC>

  29. Joint Meeting between 802.15 and 802.1 • Update on 802.15.12: Architecture proposal Slide 29 <Pat Kinney>, <Kinney Consulting LLC>

  30. Joint Meeting between 802.15 and 802.1 • Update on 802.15.10: L2R status • Sponsor Ballot Results • RESPONSE RATE • 111 eligible people in this ballot group. • 84 votes received = 75% returned (meets 75% min. return rate) • 76 affirmative votes • 3 total negative votes with comments • 3 negative votes with new comments • 0 negative votes without comments • 5 abstention votes: (Lack of time: 5) • APPROVAL RATE • The 75% affirmation requirement is being met. • 76 affirmative votes • 3 negative votes with comments •  79 votes = 96% affirmative • COMMENTS • 136 (53 must be satisfied) Slide 30 <Pat Kinney>, <Kinney Consulting LLC>

  31. Joint Meeting between 802.15 and 802.1 • Update on 802.15.3 • 802.15.3m: Revision • done and published, now uses a 48-bit MAC address • 802.15.3d: 100 Gbit/s Wireless • Preliminary proposals have been presented and are discussed at the July 2016 plenary meeting • 802.15.3e: High Rate Close Proximity • 802.15.3e has completed letter ballot and plans to start sponsor ballot at the end of this week (by 30 July). Slide 31 <Pat Kinney>, <Kinney Consulting LLC>

  32. Joint Meeting between 802.15 and 802.1 • 802.1 efforts that should be considered by 802.15 • ? Slide 32 <Pat Kinney>, <Kinney Consulting LLC>

  33. SC WNG • Two presentations: • "History and Implementation of the IEEE 802 Security Architecture” byMearegAbreha • IEEE Standards for Low Power Wide Area Networksby Jörg Robert <Pat Kinney>, <Kinney Consulting LLC>

  34. SC Accomplishments • Joint Meeting between 802.15 and 802.1 • WiFi liaison stating a perceived market need to interwork between 802.11ah and 802.15.4g at layer 2 • 802.15 TG status was reported • Maintenance • No Standards issues reported • No issues with Operations Manual reported Slide 34 <Pat Kinney>, <Kinney Consulting LLC>

  35. SC Accomplishments • IETF • Status Update: 6tisch, Core, 6lo, Roll, Detnet, and lp-wan • Next session add Ace and T2TRG reports • Three liaison communications were requested • 6lo: Neighbor discovery (RFC6775) could be further optimized to reduce neighbor discovery traffic. SC IETF will define edits to RFC6775 to show possible optimization. • lp-wan: SC IETF can identify solutions to numerous problems stated for lp-wan. SC IETF could produce a document describing the behaviors in 802.15.4 (LECIM) and 802.15.9 (KMP) that address the noted problems. • 6lo: SC IETF could identify header compression methods that apply to IP but could be extended to MAC and PHY by IEEE 802.15. • WNG presentations • "History and Implementation of the IEEE 802 Security Architecture” byMearegAbreha • “IEEE Standards for Low Power Wide Area Networks” by JörgRoberts Slide 35 <Pat Kinney>, <Kinney Consulting LLC>

More Related