Neighborhood Area Network Requirements for MPL
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.
CoAp Management Interfaces
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.
Smart Grid Network System Requirements Specification
This document are based on discussions with ZigBee NAN working group
members and detailed documents from UCAIug.