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

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sat, 4 Aug 2012 03:56:35 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf
Of ext
> Gilman Tolle (gtolle)
> Sent: Tuesday, July 31, 2012 5:10 PM
> To: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coman

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 22 Aug 2012 15:09:17 -0700

Hi Gilman,

I think this use case is very important and I like the suggested text. Some
comments inline:

On Tue, Jul 31, 2012 at 5:10 PM, Gilman Tolle (gtolle) <[email-masked]>wrote:

> 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.
>
> 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.
>
> effort via the mailing list.
>
> Gil
>
> 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.
>
> 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)

I am not sure this term is clearly differentiating these devices, since you
mention above that all meters may also serve as routers. I am not sure
which term is best to use... maybe "gateway"/"border gateway"? I think that
later in the text you use "headend".

> 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.
>

Yes, indeed. I wonder if that is not too specific for this use case draft.

> 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.

I would suggest to change "will" to "may", as this depends on the routing
protocol that is used. The meter could also be more "dumb" and just use a
single default route.

> As a result of this continuous optimization, PAN membership can change
> frequently throughout the life of the network.
>
> confidentiality for all data traffic within the PAN.

There could be other means of establishing confidentiality than a shared
key (e.g. using x509 certificates, ...).

> This key may be obtained by a meter only after an end-to-end
> authentication process based on certificates,

or by manual distribution (not that this is what I suggest, but I think we
should not restrict too much how the AMI network is set up).

> ensuring that only authorized and authenticated meters are allowed to join
> the PAN, and by extension, the mesh network as a whole.
>
> address that enables end-to-end communication between the headend systems
> and each meter.

Why "private" IPv6 address? I believe that in many deployments addresses
are statically assigned (because of the lack of standardized
autoconfiguration mechanisms).

> In this use case, the meters are always "on",

What does that mean? Does that consider duty-cycle?

> and should have a ping round trip time of roughly 200ms per hop.

That depends on the link layer. I would suggest to avoid using precise
numbers.

> But, due to lossy links and network optimization, not every meter will be
> immediately ping-able,

I would prefer to not use the word "ping", since this is just an
application name.

> though eventually every meter will be able to exchange data with the
> headend.
>
> 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.
>

That seems to preclude deployments with hop counts of 21.

>
> 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.
>
> 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.
>

I think we may indeed need some discussion if the first two items fit into
this draft (and COMAN in general). It may be better fitting in the new IETF
discussion group SOLACE.

> attempt to join the network at the link layer, and check those devices
> against a master list of authorized devices.
>
> 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.
>
> 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.
>
> monitoring, and firmware update functionality for multiple device classes
> within a single network, including constrained mesh endpoints and less
> constrained routers.
>

Best
Ulrich