TOSHIBA Corporation

Komukai Toshiba Cho 1 Saiwai-Ku Kawasaki Kanagawa 2128582 JAPAN +81-45-342-7230 yusuke.doi@toshiba.co.jp

Rtg roll MPL, NAN Neighborhood area networks (NAN) is expected to use MPL to distribute information over wireless mesh network with 6lowpan/802.15.4. This document is to describe expected use case and requirements of NAN, based on OpenSG requirements.

Neighborhood area networks (NAN), mainly for smart meters, is expected to use MPL to distribute information over wireless mesh network with 6lowpan/802.15.4. This document is to describe expected use case and requirements of NAN, based on public requirements. This document describes what's included in the requirement, how the requirements for a network and multicast are extracted, and some analysis on them.

(SG Network Requirement) is a public document from UCAIug, and summarizes network communication requirements over smart grid network. There are various components and communications described in the document. Among them, use cases relates to multicast (one-to-many) communication over neighborhood area can be categorized to following two classes. Commanding Firmware Update / File Transfer Typical commanding usecases are Pricing and DR-DLC. Typical pricing usecase is distribution of price information of energy from devices managed by utility company (data aggregation point). DR-DLC stands for demand response and direct load control, and this includes critical peak pricing to reduce peak energy consumption (DR) and shut off of unnecessary devices on customer's side (DLC). These commanding use case has short message with shorter end-to-end latency requirement. Firmware update and other file transfer is also required by NAN. This usecase does not impose shorter deadline, but usually the amount of data is far larger than commanding. 100 or few thousands of frames are required to accomplish file transfer task.

In this section, we describe multicast-related use cases defined in SG Network Requirements.

A mesh network may consist of up to 10,000 nodes within 10 hops at most. This is an assumption made by this document.

According to SG Network Requirements, commanding use cases requires a message with average of 100 bytes. They should be delivered to 98% of nodes in a NAN within 5 seconds.

5 seconds in 10 hops means 500 milliseconds per hop is allowed. This includes encoding/decoding, trickle timers wait, etc. In MPL, data packets are sent after update of control information base. If PROACTIVE_FORWARDING is false, data message transmission occurs after control message transmission and detection of inconsistency. If it's true, data transmission will occur without control message transmission. Hence, If PROACTIVE_FORWARDING is false, sum of minimal intervals of control and data messages should be lower than 500ms. If PROACTIVE_FORWARDING is true, minimal interval of data messages should be lower than 500ms.

Following two cases are defined for file transfer. Case 1: Transmission of 2MB to 98% of nodes within 7 days (Firmware updates) Case 2: Transmission of 50kB to 98% of nodes within 3 days (File transfers) Assuming MTU=1500, we can estimate how many bytes we need to transfer to satisfy the use cases. approx 1400 packets in 7 days for firmware updates (case 1) approx 100 packets in 3 days for file transfers (case 2)

Case 1: - 2MB/7 days = 3.5 bytes per second - 1500 octet payload => approx 1 data packet in 7 minutes - approx 1400 packets in 7 days (1 packet in 432 seconds) Case 2: - 50KB/3 days = 0.19 bytes per second - 1500 octet payload => approx 1 data packet in 2 hour 20 min. - approx 100 packets in 3 days (1 packet in 2592 seconds)

This section accommodates other topics for manageable multicast over mesh networks.

Smart meter networks are likely to start from small network around a data aggregation point (DAP) and grows as normal meters replaced by smart meters. Hence, network size shall change time to time. In such use cases, some default set of parameters may not appropriate for lifetime of a network. Hence, a method (management interface) to update MPL parameters in a network is required. Candidates are SNMP, netconf, DHCPv6, or CoMI. Requirements for management interface are as follows: Simple and short packet Updateable Can work without per-device configuration prior to install Be able to 'broadcast' the configuration

This document does not make any request to IANA.

No new security threat is identified by this requirement.

The draft describes an interface based on CoAP to manage constrained devices. Access to existing MIBs is included. The proposed integration of CoAP with SNMP reduces the code size by removing an important part of the SNMP code. The draft lists a set of CoMI objects that describe the operational settings of the applications on the device. A majority of them is taken over from other drafts to provide one uniform CoMI based access. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org.

This document are based on discussions with ZigBee NAN working group members and detailed documents from UCAIug.