[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

lpwan                                                           B. Heile
Internet-Draft                                           Wi-SUN Alliance
Intended status: Informational                                    B. Liu
Expires: January 4, 2018                                        M. Zhang
                                                     Huawei Technologies
                                                              C. Perkins
                                                               Futurewei
                                                            July 3, 2017


                          Wi-SUN FAN Overview
                  draft-heile-lpwan-wisun-overview-00

Abstract

   This draft presents an informational overview of the Wi-SUN
   technology, which gives the principal characteristics of the
   protocols that have been adopted.  The objective is to provide
   overview information for the IETF LPWAN working group.  We also
   identify relevant characteristics of Wi-SUN that make it suitable for
   deployment in LPWWANs.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 4, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Heile, et al.            Expires January 4, 2018                [Page 1]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Characteristics . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Protocol Stack  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Topologies  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Star Topology . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Cluster Tree  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Discovery . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Addressing  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Unicast Addressing  . . . . . . . . . . . . . . . . . . .   9
     7.2.  Multicast Addressing  . . . . . . . . . . . . . . . . . .   9
   8.  Routing . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Layer-3 routing: Route-Over . . . . . . . . . . . . . . .  10
     8.2.  L2 routing: Mesh-Under  . . . . . . . . . . . . . . . . .  11
   9.  Encapsulation . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Frame Formats . . . . . . . . . . . . . . . . . . . . . .  11
     9.2.  Information Elements  . . . . . . . . . . . . . . . . . .  11
   10. Wi-SUN Alliance . . . . . . . . . . . . . . . . . . . . . . .  11
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     13.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Wi-SUN is a wireless communication technology designed for Utilities,
   Smart Cities and IoT.  Wi-SUN is based on various IEEE, IETF, and
   ANSI/TIA standards supporting low power and lossy networks.  Use
   cases for Wi-SUN that are relevant for LPWAN may be found in a
   companion document [draft-wisun-use-cases].

   This document provides an overview of the Wi-SUN FAN technology,
   based on the FAN Technical Profile Specification [FANTPS].  The FAN
   technical profile is a product of the Wi-SUN Alliance (see
   Section 10).

   The remainder of this document describes the Wi-SUN FAN profile in
   more detail to support the inclusion of Wi-SUN as a technology choice



Heile, et al.            Expires January 4, 2018                [Page 2]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


   that can beneficially be used in the deployment of low-power, wide-
   area networks (LPWANs).

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   Additionally, this document uses the following terms:

   Border Router: a node that provides WAN connectivity to the FAN,
   maintains source routing tables, provides node authentication and key
   management services, and disseminates PAN wide information.

   DAO: DODAG Destination Advertisement Object [RFC6550]

   DIO: DODAG Information Object

   DIS: DODAG Information Solicitation

   DODAG: Destination oriented Directed Acyclic Graph

   IE: Information Element

   FAN: Field Area Network, containing one or more PANs

   FFD: A Full-Function Device, which can act as a Border Router, a
   Router Node, or a Leaf Node.

   Leaf Node: a node that offers minimum capabilities such as
   discovering and joining a PAN, sending/receiving IPv6 packets, etc.

   PAN: Personal Area Network

   RFD: A Reduced-Function Device.  A RFD does not allow other devices
   to associate, and can only act as Leaf Node.

   Router Node: a node that provides upward and downward packet
   forwarding, as well as security and address management protocols
   relaying.

   Wi-SUN: Wireless Smart Ubiquitous Network







Heile, et al.            Expires January 4, 2018                [Page 3]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


3.  Characteristics

   WiSUN [FANTPS] is an established suite of IoT technologies that is
   based on IEEE 802.15.4, TCP/IP, and related standard protocols as
   detailed in the following sections.  Important characteristics of
   WiSUN include the following:

   Coverage
      Range measured in kilometers

   Development Ecosystem
      WiSUN Alliance with task groups for targeted use cases and assured
      interoperability (see Section 10)

   High Bandwidth
      Up to 300 kbps

   Low Latency
      0.02 seconds

   Mesh Routing
      Resilient and scalable

   Power Efficiency
      less than 2 uA when resting; 8 mA when listening

   Scalability
      Networks to 5,000 devices; 10 million endpoints worldwide

   Security
      Public key certificates, AES, HMAC, dynamic key refresh, hardened
      crypto

   Taken as a whole, these characteristics support consideration of
   WiSUN protocol solution as an implementation choice for LPWAN.

4.  Protocol Stack

   The stack overview of Wi-SUN FAN is illustrated in Figure 1.  The PHY
   layer is based on IEEE 802.15.4g, which provides bi-directional
   communication with high data rate (up to 300kbps) and low latency.
   The low power consumption permits a battery-powered FAN device to
   listen frequently while maintaining a lifetime measured in years.
   The MAC sub-layer is based on IEEE 802.15.4e along with Wi-SUN
   defined Information Extensions (IEs).  The network layer is IPv6 with
   6LoWPAN [RFC6282] adaptation.  The Wi-SUN FAN supports star and mesh
   topologies, as well as hybrid star/mesh deployments.  Two methods are
   available for packet routing: RPL [RFC6550] non-storing mode is



Heile, et al.            Expires January 4, 2018                [Page 4]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


   mandatory at the network layer, and MHDS [ANSITIA-4957.200] is
   optional at the Logical Link Control (LLC) sub-layer.  The transport
   layer provides both UDP and TCP services.

           +--------------------------------------+
           |             Application              |
           +------------+-------------------------+ +---------+
           |  Transport |        UDP/TCP          | |Security |
           +------------+-------------------------+ +---------+
           |   Network  | IPv6/ICMPv6/RPL/6LoWPAN | | 802.1X  |
           +------------+-------------------------+ | EAP-TLS |
           |            |      LLC Sub-Layer      | | 802.1fi |
           |            |        +-------+        | |         |
           |            |        |L2 MESH|        | |+-------+|
           |  Data Link +--------+-------+--------+ || ETSI- ||
           |            |      MAC Sub-Layer      | ||TS-102-||
           |            |     IEEE 802.15.4e      | || 887-2 ||
           |            |      IE extensions      | |+-------+|
           +------------+-------------------------+ +---------+
           |     PHY    |     IEEE 802.15.4g      |
           +------------+-------------------------+

                         Figure 1: Stack Overview

   A Wi-SUN FAN node can operate in any of the regional frequency bands
   defined in [PHYSPEC], i.e. 470-510MHz, 779-787MHz and 920.5-924.5MHz
   in China, 863-870MHz and 870-876MHz in Europe, or 920-928MHz in USA,
   Canada and Japan.  The radio interface is also compliant with local
   regulations of India, Mexico, Brazil, Australia, New Zealand, Korea,
   Philippines, Malaysia, Hong Kong, Singapore, Thailand, and Vietnam.

   The MAC layer supports channel hopping for both unicast and broadcast
   frame transmission.  The total number of channels available is
   determined by the regional band and the channel spacing.  A node can
   also choose to exclude a set of channels from its hopping sequence.
   A channel function defines a method used to determine, from the list
   of available PHY channels, the specific channel upon which a node is
   operating at a given time [FANTPS].  The resulting hopping schedule
   is advertised to the neighbors.  A variety of channel functions can
   be implemented, including TR51 [ANSITIA-4957.200], direct hash
   [FANTPS], fixed channel and vendor defined channel functions.
   Related information is encapsulated in the unicast/broadcast schedule
   IE.

   Wi-SUN FAN's PHY layer supports data rates ranging from 50-300kbps.
   Wi-SUN devices support low latency (0.02s) and frequent (as often as
   every 10 seconds) communications.




Heile, et al.            Expires January 4, 2018                [Page 5]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


5.  Topologies

   The Wi-SUN FAN can operate in a star topology or a peer-to-peer mesh
   topology.  Either way, the FAN should include at least one FFD which
   acts as the PAN coordinator.  The coordinator is the primary
   controller of the PAN and is often mains powered.  In a star
   topology, communication is established between the devices and the
   PAN coordinator.  In a peer-to-peer topology, any two devices can
   communicate with another if they are in the range of other mesh
   nodes, and multi-hop forwarding is enabled.

5.1.  Star Topology

                              +-+
                              |R|                 C: PAN Coordinator
                     +-+      +-+      +-+        F: FFD
                     |R|****   *   ****|F|        R: RFD
                     +-+    *  *  *    +-+
                             * * *
                              +-+
                              |C|
                              +-+
                             * * *
                     +-+    *  *  *    +-+
                     |F|****   *   ****|F|
                     +-+      +-+      +-+
                              |R|
                              +-+

                          Figure 2: Star topology

   The topology of a star network is illustrated in Figure 2.  When the
   first FFD is activated, it chooses a PAN identifier that is not used
   by any other PAN in its range.  Then it becomes the coordinator and
   allows both FFD and RFD to join the star PAN.

5.2.  Cluster Tree

   An example peer-to-peer topology is the cluster tree, which can be
   regarded as a tree of PANs (clusters) as illustrated in Figure 3.  In
   a cluster tree, several of the nodes are FFDs, and one of them
   operates as the overall coordinator.  This coordinator forms the
   first cluster by choosing an unused PAN identifier and broadcasting
   beacon frames to discover its neighbors.  A candidate device
   receiving a beacon frame can request to join the network at the PAN
   coordinator.  If the PAN coordinator agrees on this requirement, it
   adds this new devices as a child in its neighbor list.  Once the
   requirements are met, the first coordinator can appoint FFDs to be



Heile, et al.            Expires January 4, 2018                [Page 6]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


   coordinators of new clusters which are adjacent to the first cluster.
   These appointed coordinators may continue to appoint coordinators of
   their adjacent clusters, until all devices have joined in the cluster
   tree.

                            +----+
         +------------+ ****|PAN4|          C: PAN Coordinator
         |PAN1        |*    +----+          F: FFD
         |         +-+*                     R: RFD
         |      ***|F||
         |     *   +-+*
         |    *       |*    +----+
         | +-+     +-+| ****|PAN3|
         | |C|*****|R||     +----+
         | +-+     +-+|     +-----------------+
         |    *       |     |      +-+        |
         |     *   +-+|     |      |R|        |
         |      ***|F||     |     *+-+        |
         |         +-+*     |    *            |
         +------------+*    |+-+*             |
                        ****||F|              |
                            |+-+*          +-+|    +----+
                            |    *     ****|F|*****|PAN5|
                            |     *+-+*    +-+|    +----+
                            |      |F|        |
                            |      +-+*    +-+|
                            |          ****|F||
                            |PAN2          +-+|
                            +-----------------+

                          Figure 3: Cluster Tree

6.  Discovery

   In this section we describe the method by which new Wi-SUN devices
   may securely discover and join an existing Wi-SUN network.  For this
   purpose Wi-SUN relies on EAP and 802.1x security standards.  Trickle
   timers are used to reduce interference and battery consumption while
   still maintaining responsive connectivity.

   A node is at Join State 1 with no information of the PAN when it
   first is powered up.  It MUST transmit PAN Advertisement Solicit
   (PAS) Frames as triggered by the Advertisement Solicit trickle timer.
   A received PAN Advertisement (PA) frame is accepted if information
   carried in the frame matches the factory preset information (e.g. the
   Network Name and Routing Method).  Both PAS and PA are transmitted as
   cleartext.  During the Advertisement Solicit trickle interval, a node
   may receive several PA frames, and it MUST select the node which



Heile, et al.            Expires January 4, 2018                [Page 7]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


   advertises the lowest PAN Cost [FANTPS] as its EAPOL (Extensible
   Authentication Protocol over LAN) target node.

   After selecting an EAPOL target node, the node is in Join State 2.
   It MUST perform the 802.1x/802.11i security flow via the selected
   EAPOL target node, to authenticate itself to the network and obtain
   its GTKs (group transient keys) from the PAN Border Router.  If the
   authentication succeeds, the node MUST set its PAN ID to be that of
   the EAPOL target node, and then proceeds to Join State 3.  Otherwise
   the node returns to Join State 1.

   At Join State 3, a node transmits PAN Configuration Solicit (PCS)
   frames as triggered by the Configuration Solicit trickle timer.  When
   a PAN configuration (PC) frame is received and decrypted
   successfully, the node MUST select the source of the PC frame as its
   initial source of broadcast transmissions.  Then the node enters to
   Join State 4.  Otherwise, if a node fails to receive and decrypt a PC
   frame after several retries, it returns to Join State 1.

   In Join State 4, the node has been configured with its channel-
   hopping schedule and active group keys.  The node is then a secured
   member of the PAN.





























Heile, et al.            Expires January 4, 2018                [Page 8]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


                 _____________________________________________
                |                                             |
                |                                             |
                v          EAPOL Target                       |
        +--------------+     Selected      +--------------+   |
        | Join State 1 |------------------>| Join State 2 |   |
        |              |                   |              |   |
        |    No PAN    |<------------------| Acquire Keys |   |
        +--------------+   EAPOL Fails     +--------------+   |
                                                  |           |
                                                  |           |
                                            GTKs Acquired     |
                                                  |           |
                                                  |           |
                                                  v           |
        +--------------+                   +--------------+   |
        | Join State 4 |                   | Join State 3 |   |
        |              |<------------------|              |   |
        |   Secured    |   RX and Decrypt  | PAN Selected |   |
        +--------------+        PAN        +--------------+   |
                            Configuration         |           |
                                                  |___________|
                                                   Unsuccessful
                                                PAN Configuration

                         Figure 4: FAN Join States

7.  Addressing

   The short addressing of 16 bit is not used in Wi-SUN, which means
   that all the related addressing and header compression mechanisms
   defined in IEEE 802.15.4 and the 6LoWPAN are not applied.

7.1.  Unicast Addressing

   The link local IPv6 address of a FAN node is auto configured
   according to [RFC4291].  The address combines the well-known link
   local prefix FE80::0 and the modified EUI-64 Interface Identifier.
   The node's Global and Unique Local Addresses (GUA and ULA) are
   managed via DHCPv6 [RFC3315].

7.2.  Multicast Addressing

   For both L2 and L3 routing networks, a FAN node MUST join the all-
   nodes group (ff02::1) and all-routers group (ff02::2) in link scope
   [RFC4291].  The realm for IEEE 802.15.4 is defined as all the
   interfaces which share a common PAN ID [RFC7346].  In realm scope, a
   FAN node MUST join the all-nodes group (ff03::1) and all-routers



Heile, et al.            Expires January 4, 2018                [Page 9]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


   group (ff03::2).  A FAN node SHOULD subscribe to the unicast-prefix-
   based IPv6 multicast group [RFC3306] to support MPL [RFC7731].

   For L3 routing networks, a FAN node MUST also join the all-nodes
   group (ff02::1a)[RFC6550] in link scope and the all-mpl-forwarders
   group (ff03::fc) in realm scope.

8.  Routing

8.1.  Layer-3 routing: Route-Over

   For Layer-3 routing, Wi-SUN FAN adopts the non-storing mode of RPL
   [RFC6550].  RPL requires the construction and maintenance of DODAGs.
   A DODAG rooted at the Border Router is called a "grounded DODAG".
   After a link failure, some nodes may lose connection to the Border
   Router; then they can form a "floating DODAG".  A node's rank is
   defined by its relative position to the root; the rank strictly
   increases after every link from the root to the leaves.

   To build a DODAG, the Border Router multicasts a DIO message to its
   immediate neighbors.  Each neighbor decides whether or not to join
   the DODAG or not cccording to the objective function and other
   criteria.  If so, the Border Router is noted as their parent.  Each
   node in the DODAG sets trickle timers [RFC6206] for DIO message
   transmission.  Upon receiving a DIO, if the node is the Border Router
   or the source node has a higher rank, the message is ignored; if not,
   in case that the node decides to join in this DODAG, the source of
   the DIO can be included in the node's DODAG parent set; the node that
   has the best objective function value is marked as the most preferred
   parent, which provides the default upward route from the child node.
   Thus the upward packets can be routed hop-by-hop to the root.  A
   neighbor can send a DIS message to solicit the transmission of a DIO
   message.

   According to the non-storing mode of RPL, downward packets are routed
   using source routing from the root.  Each node, except the Border
   Router, sends DAO messages to the Border Router indicating its route
   to its DODAG parents.  When the Border Router receives DAO messages
   from all node, it scan construct source routes to any node in the
   DODAG.

   For communication between two peers, in the non-storing mode, the
   packet goes up to the Border Router at first then sent to the
   destination node via source routing [RFC6997].

   When a link failure happens (e.g. by temporary obstruction), if a
   node has no alternative parent it becomes the root of a floating
   DODAG and sends DIO to its neighbors to advertise this change.  Each



Heile, et al.            Expires January 4, 2018               [Page 10]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


   child node switches to an alternative parents if possible, but
   otherwise stays in the floating DODAG.  When receiving the DIO
   messages from the nodes in the grounded DODAG, a node in the floating
   DODAG tries to find a new preferred DODAG parent.  Once the
   connection is recovered at this node, the other nodes in the floating
   DODAG can join the grounded DODAG through this new link.  The
   topology of the floating DODAG might be changed during this local
   redirection process.

8.2.  L2 routing: Mesh-Under

   Mesh-under L2 routing is based on MHDS, as defined in
   [ANSITIA-4957.210].

9.  Encapsulation

   The Wi-SUN MAC MTU is 2047 bytes as defined in IEEE802.15.4g,
   satisfying the IPv6 packet length requirement.  The header
   compression and fragmentation in 6LoWPAN [RFC6282] can be applied.
   Besides 6LoWPAN fragmentation, Wi-SUN FAN supports an optional L2
   fragmentation.

9.1.  Frame Formats

   Wi-SUN FAN defines 7 frame formats, including PAN Advertisement
   frame, PAN Advertisement Solicit frame, PAN Configuration frame, PAN
   Configuration Solicit frame, Upper Layer Application Data frame,
   Acknowledgment frame and EAPOL frame.  Detailed information can be
   found in [FANTPS].

9.2.  Information Elements

   Wi-SUN FAN defines its own Information Elements (IEs) to support
   certain operations.  Depending on where the MAC management
   information is encapsulated, IEs defined in Wi-SUN can be divided
   into two categories: Wi-SUN header IEs, and Wi-SUN payload IEs.  A
   payload IE can be longer than a header IE, and can be encrypted as a
   part of the payload.  Wi-SUN FAN also adopts the MP-IE defined in
   IEEE802.15.9 to carry the MAC payload.

   Detailed definitions and the inclusion relation of the IEs for Wi-SUN
   frame types can be found in [FANTPS].

10.  Wi-SUN Alliance

   The Wi-SUN Alliance consists of more than 130 member companies
   including product vendors, silicon vendors, software companies,
   utilities, government institutions and universities.  Each member



Heile, et al.            Expires January 4, 2018               [Page 11]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


   company contributes to the Wi-SUN ecosystem as the Wi-SUN Alliance
   has defined testing and certification programs for multi-vendor
   interoperability.  Wi-SUN networks have been deployed for more than
   10 years in mixed-vendor environments, demonstrating ongoing
   commitments from a wide variety of organizations.

   The mission of the Wi-SUN Alliance is to advance seamless
   connectivity by promoting IEEE 802.15.4g standard-based
   interoperability for regional markets worldwide.  Key activities of
   the Wi-SUN Alliance include the following:

      Promotion of wireless Smart Ubiquitous Networks and related
      applications as defined by international and regional standards
      development organizations.

      Advancement of wireless Smart Ubiquitous Networks worldwide

      Interoperability and compliance certification programs.

      User education

      Industry outreach and other support programs

      Lobbying regional regulatory bodies for spectrum allocation to be
      used in the support of smart grid services

      Provide a forum for global collaboration to achieve Smart City and
      Smart Ubiquitous Communications Network Interoperability

   In January 2015, the Wi-SUN Alliance released its "Technical Profile
   Specification for IEEE 802.15.4g Standard-Based Field Area Networks"
   (FANs) [FANTPS].  That specification integrates:

      A 802.15.4g physical layer compatible with the existing Wi-SUN
      Alliance PHY Certification Program

      Frequency hopping, network discovery/join and protocol dispatch

      The IPv6 protocol suite, including 6LoWPAN, address management,
      routing using RPL, unicast and multicast forwarding

      A standards-based multi-layer security specification encompassing
      authentication, authorization, encryption.








Heile, et al.            Expires January 4, 2018               [Page 12]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


11.  Security Considerations

   FAN access control is based on IEEE802.1x and EAP-TLS [RFC5216].  If
   the supplicant is not able to reach the Authenticator directly, the
   EAPOL Datagram can be forwarded by multiple routing nodes.  FAN nodes
   also support Node Pairwise (N2NP) Authentication [ETSI-TS-102-887-2]
   between one-hop neighbors in the mesh.

   FAN nodes MUST implement Frame Security policy based on AES-CCM* as
   defined in IEEE802.15.4.  The derivation of the Group AES Key and
   Pairwise AES Key is described in [FANTPS].  A node MUST maintain a
   frame counter for each GTK.  The frame counter is set to 0 initially,
   and increases with each transmission using this GTK.  It is
   recommended to replace a GTK which has been used for 30 days.

12.  IANA Considerations

   IANA need not assign anything for this document.  RFC editor: please
   remove this section before publication.

13.  References

13.1.  Normative References

   [ANSITIA-4957.210]
              ANSI, "Multi-Hop Delivery Specification of a Data Link
              Sub-Layer", February 2013.

   [draft-wisun-use-cases]
              Liu, B., Zhang, M., and C. Perkins, "WiSUN use cases",
              July 2017.

   [FANTPS]   Wi-SUN Alliance, "Technical Profile Specification Field
              Area Network", May 2016.

   [PHYSPEC]  Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March
              2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <http://www.rfc-editor.org/info/rfc6282>.




Heile, et al.            Expires January 4, 2018               [Page 13]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <http://www.rfc-editor.org/info/rfc6550>.

13.2.  Informative References

   [ANSITIA-4957.200]
              ANSI, "Layer 2 Standard Specification for the Smart
              Utility Network", January 2013.

   [ETSI-TS-102-887-2]
              ETSI, "Smart Metering Wireless Access Protocol; Part 2:
              Data Link Layer (MAC Sub-layer)", September 2013.

   [RFC3306]  Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
              Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
              August 2002, <http://www.rfc-editor.org/info/rfc3306>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
              March 2008, <http://www.rfc-editor.org/info/rfc5216>.

   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
              "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
              March 2011, <http://www.rfc-editor.org/info/rfc6206>.

   [RFC6997]  Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
              J. Martocci, "Reactive Discovery of Point-to-Point Routes
              in Low-Power and Lossy Networks", RFC 6997,
              DOI 10.17487/RFC6997, August 2013,
              <http://www.rfc-editor.org/info/rfc6997>.

   [RFC7346]  Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
              DOI 10.17487/RFC7346, August 2014,
              <http://www.rfc-editor.org/info/rfc7346>.




Heile, et al.            Expires January 4, 2018               [Page 14]


Internet-Draft       draft-liu-lpwan-wisun-overview            July 2017


   [RFC7731]  Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
              and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
              February 2016, <http://www.rfc-editor.org/info/rfc7731>.

Authors' Addresses

   Bob Heile
   Wi-SUN Alliance
   11 Robert Toner Blvd, Suite 5-301
   North Attleboro  MA 02763
   USA

   Email: bheile@ieee.org


   Bing Liu (Remy)
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District
   Beijing  100095
   China

   Email: remy.liubing@huawei.com


   Mingui Zhang
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District
   Beijing  100095
   China

   Email: zhangmingui@huawei.com


   Charles E. Perkins
   Futurewei
   2330 Central Expressway
   Santa Clara  95050
   United States

   Email: charliep@computer.org











Heile, et al.            Expires January 4, 2018               [Page 15]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/