Re: [coman] Automated Metering Infrastructure (AMI) use case

["Ersue, Mehmet (NSN - DE/Munich)" <[e-mail]>]

Hi Gilman,

thank you for your contribution. AMI and smart metering are important
use cases. 
We partly addressed this in section 3.6. We probably should separate
Energy Management and Smart Grid and merge Smart Grid with AMI.

Cheers, 
Mehmet 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of ext
> Gilman Tolle (gtolle)
> Sent: Tuesday, July 31, 2012 5:10 PM
> To: [e-mail]
> Subject: [coman] Automated Metering Infrastructure (AMI) use case
> 
> Hi all,
> 
> I've been developing a constrained device network management
application for my
> customers, and I've been following the COMAN list.
> 
> I support the work that's happening here, and am ready to help improve
it.
> 
> Automated Metering Infrastructure (AMI) is one use case that should be
added to the
> requirements document. Here is some text that describes this use case,
as well as
> some constrained network management requirements derived from it.
> 
> I'm not at the IETF this week, but will be participating in the COMAN
effort via the
> mailing list.
> 
> Gil
> 
> Automated Metering Infrastructure (AMI) Use Case
> ------------------------------------------------
> 
> An AMI network enables an electric utility to retrieve frequent
electric usage data from
> each electric meter installed at a customer's home or business. With
an AMI network, a
> utility can also receive immediate notification of power outages when
they occur,
> directly from the electric meters that are experiencing those outages.
In addition, if the
> AMI network is designed to be open and extensible, it could serve as
the backbone for
> communicating with other distribution automation devices besides
meters, which could
> include transformers and reclosers.
> 
> In this use case, each meter in the AMI network contains a constrained
device. These
> devices are typically Class 2 devices. Each meter connects to a
constrained mesh
> network with a low-bandwidth radio. These radios can be 50, 150, or
200 kbps at raw
> link speed, but actual network throughput may be significantly lower
due to forward
> error correction, multihop delays, MAC delays, lossy links, and
protocol overhead.
> 
> The constrained devices are used to connect the metering logic with
the network, so
> that usage data and outage notifications can be sent back to the
utility's headend
> systems over the network. These headend systems are installed in a
data center
> managed by the utility, and may include meter data collection systems,
meter data
> management systems, and outage management systems.
> 
> The meters are connected to a mesh network, and each meter can act as
both a
> source of traffic and as a router for other meters' traffic. In a
typical AMI application,
> smaller amounts of traffic (read requests, configuration) flow
"downstream" from the
> headend to the mesh, and larger amounts of traffic flow "upstream"
from the mesh to
> the headend. But, during a firmware update operation, larger amounts
of traffic might
> flow downstream while smaller amounts flow upstream. Other
applications that make
> use of the AMI network may have their own distinct traffic flows.
> 
> The mesh network is anchored by a collection of higher-end devices
which contain a
> mesh radio that connects to the constrained network as well as a
backhaul link that
> connects to a less-constrained network. The backhaul link could be
cellular, WiMAX, or
> Ethernet, depending on the backhaul networking technology that the
utility has chosen.
> These higher-end devices (termed "routers" in this use case) are
typically installed on
> utility poles throughout the service territory. Router devices are
typically less
> constrained than meters, and often contain the full routing table for
all the endpoints
> routing through them, but this may vary depending on the routing
protocol in use.
> 
> In this use case, the utility typically installs on the order of 1000
meters per router.
> The collection of meters that are routing through a specific router is
called a "PAN".
> When powered on, each meter is designed to discover the nearby PANs,
select the
> optimal PAN to join, and select the optimal meters in that PAN to
route through when
> sending data to the headend. After joining the PAN, the meter is
designed to
> continuously monitor and optimize its connection to the PAN, and it
will change routes
> and change PANs as needed. As a result of this continuous
optimization, PAN
> membership can change frequently throughout the life of the network.
> 
> Each PAN may be configured to share an encryption key, providing
confidentiality for
> all data traffic within the PAN. This key may be obtained by a meter
only after an end-
> to-end authentication process based on certificates, ensuring that
only authorized and
> authenticated meters are allowed to join the PAN, and by extension,
the mesh network
> as a whole.
> 
> After joining the PAN, each endpoint obtains a private routable IPv6
address that
> enables end-to-end communication between the headend systems and each
meter. In
> this use case, the meters are always "on", and should have a ping
round trip time of
> roughly 200ms per hop. But, due to lossy links and network
optimization, not every
> meter will be immediately ping-able, though eventually every meter
will be able to
> exchange data with the headend.
> 
> In a large AMI deployment, there may be 10 million meters supported by
10,000
> routers, spread across a very large geographic area. Within a single
PAN, the meters
> may range between 1 and 20 hops from the router.
> 
> During the deployment process, these meters are installed and turned
on in large
> batches, and those meters must be authenticated, given addresses, and
provisioned
> with any configuration information necessary for their operation.
During deployment
> and after deployment is finished, the network must be monitored
continuously and
> failures must be handled. Configuration parameters may need to be
changed on large
> numbers of devices, but most of the devices will be running the same
configuration.
> And, eventually, the firmware in those meters will need to be
upgraded, and this must
> also be done in large batches because most of the devices will be
running the same
> firmware image.
> 
> Because there may be thousands of routers, this operational model
(batch deployment,
> automatic provisioning, continuous monitoring, batch reconfiguration,
batch firmware
> update) should also apply to the routers as well as the constrained
devices. The scale is
> different (thousands instead of millions) but still large enough to
make individual
> management impractical for routers as well.
> 
> AMI Management Requirements
> ---------------------------
> 
> To support the use case above, the headend must contain a set of
management
> systems that meet the following requirements. The first two
requirements may fall
> outside the typical definition of "network management system" and into
authentication
> and provisioning systems (e.g. RADIUS, DHCPv6), but the full use case
does require all
> six.
> 
> 1. Securely authenticate a large number of constrained devices as they
attempt to join
> the network at the link layer, and check those devices against a
master list of
> authorized devices.
> 
> 2. Provide routable IPv6 addresses for a large number of constrained
devices after
> they have joined the network.
> 
> 3. Support group-based provisioning and coordinated reconfiguration of
a large-scale
> network of constrained devices with automatic synchronization and
eventual
> consistency to handle lossy links and temporarily unavailable devices.
> 
> 4. Collect network status, performance metrics, and fault event
information for a
> large-scale network of constrained devices into a central location
with user interfaces
> that enable monitoring and troubleshooting of large networks (millions
of devices) by a
> single person or small team.
> 
> 5. Support group-based firmware update of those constrained devices,
with eventual
> consistency and coordinated reload times.
> 
> 6. Support this kind of group-based provisioning, configuration,
monitoring, and
> firmware update functionality for multiple device classes within a
single network,
> including constrained mesh endpoints and less constrained routers.
> 
> 
> _______________________________________________
> coman mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/coman