| 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
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.
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 (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 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.
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 that can beneficially be used in the deployment of low-power, wide-area networks (LPWANs).
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
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:
Taken as a whole, these characteristics support consideration of WiSUN protocol solution as an implementation choice for LPWAN.
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 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.
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.
+-+
|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.
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 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
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 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.
_____________________________________________
| |
| |
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
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.
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].
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 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.
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 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.
Mesh-under L2 routing is based on MHDS, as defined in [ANSITIA-4957.210].
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.
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].
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].
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 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:
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:
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.
IANA need not assign anything for this document. RFC editor: please remove this section before publication.
| [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. |
| [RFC6282] | Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011. |
| [RFC6550] | Winter, T., Thubert, P., 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. |