The Role of the Internet Protocol (IP) in AMI Networks for Smart Grid

NIST PAP 01 – The Role of IP in the Smart Grid

The Role of the Internet Protocol (IP) inAMI Networks for Smart Grid

NIST PAP 01October 24th 2009

1. Background.................................................................................................................12. Smart Grid Architecture Layers..................................................................................33. The Smart Grid Communications Architecture...........................................................44. The End-to-End Smart Grid IP Architecture...............................................................7

4.1 Smart Grid IP Last Mile............................................................................................74.1.1. C.12.22 (full protocol) over UDP and TCP over IP in Advanced Metering Infrastructure (AMI)........................................................................................................9C12.22 IP Networking Components.............................................................................10C12.22 IP Communications Architecture.....................................................................124.1.2. C.12.22 (light version) over UDP and TCP IP in Advanced Metering Infrastructure (AMI)......................................................................................................134.1.3 C.12.18/C12.19 (no C12.22) over UDP and TCP IP in Advanced Metering Infrastructure (AMI)......................................................................................................144.2 Other AMI communications standards...................................................................144.3 Interaction with Other IP Networks.........................................................................14

5. Summary..................................................................................................................14References.......................................................................................................................15

1. Background

The Internet Protocol (IP) is rapidly becoming a more popular for interoperable End-to-End Smart Grid Networks. Therefore, it is important to understand the different uses of the IP suite in Internet networking technologies for existing and emerging Smart Grid applications. This document gives the basis for understanding the IP protocol use in Smart Grid and how interoperability can be achieved today using existing open and standards-based protocols and how these protocols can evolve to create more interoperable Smart Grid systems. This work is intended to support the NIST Priority Action Plans (PAP 01) – The Role of IP in Smart Grid [1,2]

The Internet Protocol (IP) suite is defined as (i) a set of network and transport data message protocols, using IP packets, and (ii) a set of routing, IP address mapping and device management protocols. This IP suite enables end-to-end Smart Grid applications to communicate over a set of interconnected network segments (defined in Figure 3), using various networking technologies (MAC/PHY lower layer protocol). It also allows for end-to-end session and transaction-based security mechanisms.

The structure of the Internet Protocol suite with its OSI layers and the key open standard-based upper layer protocols, used in the Smart Grid, should be considered critical for the integration of Smart Grid devices and networks into an IP-based infrastructure. The IETF has recently identified and addressed some of these protocols for Smart Grid in some of the IETF work in progress drafts and other related work [3-10]. It has been identified that there are several options of an IP protocol suite, such as TCP,

1


SCTP, DCCP, UDP [3] and other protocols that could be used in any particular combination for the purpose one intends. As proposed by [3], for an end-to-end Smart Grid interoperability purpose, the set of IP protocol suite defined for Smart Grid shall focus on end devices (hosts). The Smart Grid IP end devices/nodes are defined as any IP-enabled device used in an Smart Grid such as smart meters, sensors, relays, actuators, intelligent electronic devices (IEDs), or any box with embedded and enhanced data-gathering and reporting functionality that can be connected to an IP transport layer. These end devices can leverage well-proven IP infrastructure with a well-defined IP protocol suite implementation to achieve end-to-end networking interoperability [3].

Open and standards-based protocols provides the basis for an end-to-end interoperable IP network, which allows utilities to evolve their system overtime by enabling new technology to interoperate with existing infrastructure. For instance, utilities can utilize multiple communication networks and end devices (different vendor’s solutions) or change communications technologies while maintaining their investment in end devices (e.g. smart meters, IEDs, etc), where several of these combinations are possible.

The key consideration in evaluating IP in AMI is related to defining a functional IP architecture. That is to say that suitable addressing and routing schemes can be identified. When it comes down to it, once a routable IP network is in place all of the application services supported by IP become available – either directly or through remote devices – including the possibility of providing gateways to dissimilar network architectures.

Figure 1. AMI Use Case Actors and Interfaces

2


In terms of identifying network architecture elements, the diagram in Figure 1, created by EPRI for the Report to NIST on the Smart Grid Interoperability Standards Roadmap1 is useful to establish a basic understanding of the variety and number of connections that take place between the various utility entities and the customer (including the PEV and the Meter). As a possible networking diagram, if you let each of the colored boxes in the background represent a network for that portion of the electrical supply chain – essentially an interior routing domain – then the red communications lines indicate some form of inter-domain routing requirement. For the purpose of establishing an IP architecture in Smart Grid, we will make three assumptions about this diagram:

1. The entire collection of routing domains in this diagram represents a single Autonomous System (AS). This is necessarily the routing domain for the electric utility serving this customer. The implication here is that the IP address assigned to the customer’s meter comes from the electric utility.

2. The “Customer” network represented by the green box in the lower right hand corner could use non-routable addressing space.

3. It is accepted that there could be an additional IP network connection, provided by the customer’s ISP (and is thus a different AS number), that also connects somewhere in the Customer network.

The Smart Grid interoperability roadmap proposed by NIST should consider the existing today’s IP suite and other higher layer open standard-based protocols, which can be testable and interoperable in a short time frame. During these tests, interoperability gaps and the need to optimize protocol mappings on top of the OSI stack will be identified and recommendations to improve existing standards will be proposed to Standards Development Organizations (SDOs). This will not only ensure that the combination of different protocol mapping alternatives can meet today’s requirements, but it will also pave the way for the evolution of more interoperable and optimized Smart Grid systems.

A final note is that this document will not make the distinction between IP version 4 or version 6 for the purpose of analysis or standardization. The point is simply to support IP with the version number left to be an implementation detail determined by the utility or service provider that would install the AMI network. That being said, any competent network planner can easily do the math – many investor-owned utilities have literally millions of electric meters installed (a distinct challenge in a version 4 environment), with this “volume problem” being compounded by the presence of other devices including some quantity of electric vehicles as potential roaming users in the future. That means the utility would either have to use IPv4 very judiciously and replicate private IP space over and over again, or move to IPv6 and address a greater number of devices uniquely.

2. Smart Grid Architecture Layers

Figure 2 shows different Smart Grid architecture layers proposed today. The additional layers defining the Smart Grid Communications Architecture, particularly focused on an “End-to-End Smart Grid IP Architecture” are covered in this document. This figure shows the NIST Conceptual Model as defined in [1] and the NIST Smart Grid System Architecture as defined in [2].

The Smart Grid Communications Architecture building blocks (Figure 3) and, particularly in a more specific level, the End-to-End Smart Grid IP Communications Architecture 1 Contract No. SB1341-09-CN-0031—Deliverable 7, dated June 17, 2009

3


sub-set is defined in this document as an one-level down and more specific Smart Grid Communications reference architectures from the NIST generic Smart Grid System Architecture published in [2]. The Smart Grid IP Architecture considers the IP suite as the underlying and converging protocol layer for end-to-end Smart Grid interoperability.

Figure 2. Smart Grid Architecture Layers

3. The Smart Grid Communications Architecture

This section defines the Smart Grid Communications Architecture Framework with its key segments and constituent elements (Figure 3). It is a refinement of the NIST Smart Grid System Architecture of [2], i.e. an one-level down architecture layer, as was shown previously. This figure shows the building blocks of an End-to-End Smart Grid Communications system, including the terminologies used to define the multiple network segments and demarcation points (boundaries) for proper interoperability and “Service Level Agreement (SLA)” performance metrics compliance at the interfaces boundaries. This segmentation and demarcation offers a modular and flexible approach to define interoperable segments, interfaces and elements and ensures that service performance and end-to-end network management is met all the way across multiple interoperable network segments, according to the best practices of the telecommunications industry.

The Smart Grid is a system of system and a combination of multiple different technologies and layers, which require interfaces between these segments to be properly defined and harmonized with the existing standards. The end goal is to create an “Information Superhighway” or “IP bus” that communicates at the upper layer with all

4


these sub-layers and cut across all these segments, transporting the end-to-end applications intra or inter-domains.

Figure 3. Smart Grid Communications Architecture Mapping

There are a myriad of standards-based and proprietary network technology options available in each Smart Grid segment and a combinations between these options is also possible. They all interoperate and work (or should) at the lower layers (PHY/MAC). As we will see in the next section, most likely the upper protocol layers are the ones that should be harmonized around the IP protocol suite to create an IP communications bus that cut across several Smart Grid network segments and are optimized at the OSI protocol stack. This will ensure end-to-end and interoperable Smart Grid IP Communications from the bulk power generation all the way down to the consumer end devices, and vice-versa.

The basic building blocks of this Smart Grid Communications Architecture are identified and defined below. It defines the key segments and maps each segment onto each associated power and energy system layer.

Wide Area Networks (WAN) – It is comprised of (i) the core network/backbone that connects to major service provider backbone or inter-utility backbones (either using utility owned OPGW (Optical Fiber Composite Overhead Ground Wire) - along the high power electric transmission lines - or wireless radios), (ii) regional and/or Metropolitan Area Network (MAN) (metro fiber rings or wireless networks). The WAN could be either a utility owned or a public service provider network

5


(major telcos or CLEC-Competitive Local Exchange Company). The WAN also interconnects to the public Internet network (at peering access points), transmission substations and utility control and enterprise/IT networks using secure communications. See the description for “Backhaul” below to identify special cases for Wide Area Networks.

Utility Local Area Network (LAN) – It is comprised of utility operations and enterprise LANs to manage operations, control and enterprise processes and services (billing and automation, meter reading, outage management, demand response, load control, etc). It interconnects to the WAN through secure wireline or wireless communications. It also interconnects to the public Internet to exchange customer data to third party providers.

Backhaul – It is the spur that connects the WAN (major POPs – point-of-presence) to the last mile network. The backhaul can be owned by the utilities or provided by third party service providers (telcos, CLECs, cables, etc). It aggregates and transport customers smart grid telemetry data, substations automation critical parameters data, distribution plant intelligent devices data field information, mobile workforce information to/from the utility head end to/from the last mile network. (It should be noted that in certain network architectures a backhaul segment may exist with no actual WAN. Legacy connections consisting of point-to-point or multi-point data circuits are just such examples.)

Last Mile –The last mile is a two-way wireless or wireline communications network overlaid on top of the power distribution system. It is usually named as Neighborhood Area Network (NAN), Field Area Networks (FAN), or Advanced Metering Infrastructure (AMI) depending on the utility network system characteristics, services offered, network topology and demographics and the vendor technology utilized. The last mile could be an integrated and multi-purpose network technology alternative for AMI (smart meters, Demand Response, etc) services, Distribution Automation (IEDs in the field) and substation automation. Alternatively, the last mile could be comprised of individual networks technologies with different purpose and network characteristics (performance, security, management, etc) for each particular application. In one end it interfaces with the smart meters - at the customer premise edges, the field IED devices and sometimes the distribution substation hotspots. In another end, its network Access Point (AP) interfaces with the backhaul network, where the data is collected/aggregated to be transported to/from the backhaul to the WAN. The last mile may also provide communications to the Distributed Resources (DR) - renewable and non-renewable energy sources - connected to the distribution grid.

Customer Premise – It is comprised of the residential or Home Area Network (HAN), Business/building Area Network (BAN), and Industrial Area Network (IAN). These networks are also connected to the ancillary elements outside the customer premises like the Plug-in Vehicle (PEV), solar/wind energy (microgrids) sources and storage devices. It can also be connected to the public Internet network through a “service provider-provided energy management gateways” or Energy Services Interfaces (ESI).

6


4. The End-to-End Smart Grid IP Architecture

A more specific case of the Smart Grid Communications Architecture of Figure 3 is the End-to-End Smart Grid IP Architecture, where the Internet Protocol (IP) is used the underlying and unifying protocol for multi protocol, intra and inter-network segment interoperability.

Today the Internet Protocol is a mature and dominant protocol at most core/WAN telecom networks (including the IP backhaul segment). IP is still in its infancy of adoption in Smart Grid Communications networks and several issues need to be addressed before full adoption or recommendation of an end-to-end IP layer convergence. The best practice of the telecom industry shall be brought into the Smart Grid industry to speed up the full development of IP over Smart Grid system. However, the main challenges still remain, such as (i) the coexistence and harmonization of the IP suite with existing Smart Grid/smart meter specific protocol stacks, such the ones developed by ANSI C12.22 and others (IEC 61850, DNP3, etc) – which are specific to the utility industries – and (ii) the adoption of IPv6 as the addressing mechanism of choice for the new Smart Grid IP network.

On the other hand, at the edges of the Smart Grid network, it is also known that most of the current customer premises network standards (ZigBee, HomePlug, 6LoWPan and others [8-10]) have or are in the process of defining the IP layer in their protocol stack. Therefore, the ultimate challenge remains on the decisions to fully extend the IP as a unifying protocol layer all the way to the NAN/FAN and AMI networks and its end devices, knowing that full implementation of proprietary system are at full speed today by the utilities and that the “ideal” open-standard C12.22/IP protocol suite or alternatives of this approach are not available today. This document identifies and discusses all these issues and point out possible alternative solutions to be addressed by the standards bodies.

The first part of this section introduces the Smart Grid IP Last Mile and its relevance to the overall Smart Grid Communications system and addresses the Last Mile open standard IP protocol challenges and possible alternative solutions.

4.1 Smart Grid IP Last Mile

The Last Mile is where most of the power distribution system elements and sub-systems of the Smart Grid are located. It contains the smart meters, the intelligent field devices (IEDs), the workforce mobility/field automation, the distributed resources and the distribution substations. Also, the Smart Grid Last Mile, particularly for AMI applications (meter reading, load control, demand response, etc) is the one driving most of Smart Grid deployment today. Therefore this segment is currently considered the most important of the Smart Grid and special attention must be given to the IP protocol mapping and its conformance to existing standards for interoperability purposes.

This section introduces the ANSI C12.22 standard [11] as one of the most important open and interoperable protocol standard for the Smart Grid Last Mile (particularly for AMI applications), mainly based on references [4,5], which define and describe a special case of C12.22 for IP communications.

7


This document provides the C12.22 over IP key components, architecture and alternatives approaches to map C12.22 messages (C12.19 table data) onto IP (UDP/TCP). It shows the architecture framework to transport C12.22 messages to/from Last Mile IP segment to/from the utility head end/enterprise data center. These data communications paths between C12.22 IP Nodes and the C12.22 control units (Master Relays) – located at the Smart Grid head end – cut across several Smart Grid communications network segment (WAN, backhaul, last mile, customer premises, etc), as defined in the previous section. Hence it may pose different network requirements for AMI/ C12.22 applications within each or across multiple network segments.

Currently there are three options to evolve the C12.22 mapping onto IP (not considering other proprietary protocols today), as shown in Figure 4. They are:

a) Full C12.22 onto TCP or UDP over IPb) Light or optimized version of C12.22 onto TCP or UDP over IPc) C12.19 table data directly onto TCP or UDP over IP. No use of C12.22

It might be possible that the next stage of Smart Grid protocol mapping interoperability requires either a gradual transition from (a) into (b) with the adaptation and optimization of C12.22 to work specifically with the IP layer, creating a lighter version of C12.22 without its full functionalities, or a more disruptive transition from (a) into (c) with the complete elimination of C12.22 transport layer from the OSI protocol stack. In this case, C12.19 table data is mapped directly onto TCP or UDP as a payload. In both cases, it requires the ANSI standards and the IETF to come together and create this common ground.

Figure 4. The Smart Grid IP Protocol Suite for C12.22/C12.19 over UDP/TCP

8


The next section discusses these three alternatives, focusing on mapping ANSI C12.22 over IP as the converging layer for end-to-end interoperability across several Smart Grid network segments.

4.1.1. C.12.22 (full protocol) over UDP and TCP over IP in Advanced Metering Infrastructure (AMI)

The ANSI C12.22 open standard [11] basically defines at its core a transport independent application-level messaging protocol for exchanging standardized C12.19-formated table data between its nodes (smart meters and other intelligent field devices) and a physical and data link protocol for connecting these nodes over any underlying, heterogeneous, reliable data communications network using the Open System Interconnect (OSI) model. For instance, a C12.22-compliant message can travel across a RF mesh network to reach an access point (AP), and then use GSM/CDMA 3G or Wimax network backhaul and metro fiber networks WAN to move data from end devices to utility control center/head ends.

It provides a set of application-layer messaging services that are applicable for the enterprise and end device components of an Advanced Metering Infrastructure (AMI).The messaging services are tailored for, but not limited to, the exchange of the data Table Elements defined and co-published in ANSI C12.19, IEEE P1377/D1, and MC1219. It also provides enhanced security (encryption), reliability and speed for transferring end-device data over heterogeneous networks.

The main advantage of the ANSI C12.22 open standards is that it enables interoperability among smart meters, intelligent field devices and others devices so that smart meter data can be collected, analyzed and C12.22 devices controlled over any NAN/AMI/Backhaul/WAN communication networks (network independent) as long as the message conforms to the ANSI protocol.

More specifically, C12.22 can be transported over IP for Smart Grid Last Mile (NAN, FAN, AMI) and other network segments. Combining the strengths of two standards based, open-standards transport protocols (IP and C12.22) will ensure that C12.22-compliant system insulates utilities from the risk of single AMI/NAN network and smart meter technologies lock-in. It provides adaptation to a rapidly changing communications landscape regardless of the communications technology utilities choose to communicate with their end devices since C12.22 network interfaces at an application level protocol layer, enabling both session and sessionless-based communications directly to the smart meter register. Here, if the meter or the network changes, the overall end-to-end communication system is not affected, as long as the new solution provides interoperability at the C12.22/IP layer. This is also important role regarding the implementation of an end-to-end security from master relays to end nodes.

C12.22 IP Networking can also be extended to provide IP communications for Distribution Automation (to connect Intelligent Electronic Devices (IEDs) in the field) as well as smart meters. For instance, real-time fault detector indicators equipped with C12.22 communications (C12.22 IP Node or using non-C12.22 devices/C12.22 Gateway) can provide outage and restoration notification the feeder and lateral level of the distribution network. C12.22 can also provide the communications protocol for

9


capacitor bank monitoring and others. It also provides for interoperability among third-party non-compliant C12.22 end devices and C12.22-compliant communications networks through the use adaptation gateways.

In brief, C12.22 over IP defines how IP nodes (smart meters, IEDs, etc) and its communications device (communication module) will interface and connect to a C12.22 IP (TCP or UDP) Network. This allows much greater flexibility for interoperability as utilities implement their Smart Grid Last Mile network. Therefore it plays a vital role in unifying the information collected from AMI while allowing utilities to select the communications technologies and end devices (meters, IEDs, etc) that make the most sense for them.

This section focuses specifically on the C12.22 IP Node’s usage of the connection-oriented (TCP) and connectionless (UDP) transport layer protocols IP suite used in C12.22 IP Networking, as defined by the framework and requirements for governing the transport of ANSI C12.22/IEEE 1703/MC1222 Advanced Metering Infrastructure (AMI) application layer messages on an IP network, particularly via TCP and UDP transports, in the IETF draft [4] and others [5].

C12.22 IP Networking Components

The key elements of a C12.22 IP Communications System and its functionalities are described below [4,5].

The C12.22 IP Node comprises of C12.22 Communications Module and a C12.22 Device and it is located within a C12.22 IP Network Segment. Each C12.22 IP Node has one or more C12.22 applications (and possibly C12.19 data table structure), a Native Address, which is the IP address plus the associated port number used in communications by a C12.22 IP Node on the C12.22 IP Network Segment. The C12.22 Node also interconnects one or more C12.22 Network Segments through routers, gateways or bridges. The C12.22 IP Nodes are located within the Smart Grid Last Mile Network, overlaid on the power distribution grid. The C12.22 IP Node communicates with other C12.22 IP Nodes, via its C12.22 Communications Module, over UDP and TCP IP protocols. The C12.22 Communications Module of the C12.22 IP Node can support different types of PHY/MAC network interfaces. One key desirable characteristic of an IP-enabled Smart Grid device is and easy and modular or “plug-n-play” installation process.

The C12.22 IP Network Segment is a collection of all C12.22 IP Nodes that implement the IP-based protocols, employs the same IP address encoding scheme and the same network protocols and can communicate with each other Segment using gateways such as IP routers, switches, and bridges. The C12.22 IP Segments communicate directly between themselves, without forwarding C12.22 messages through a C12.22 Relay. It comprises C12.22 IP Nodes and the network infrastructure that enables any one node to reach all other nodes on the same segment. A C12.22 IP Network Segment can be a private LAN, small single LAN or subnet and can also include connectivity with public Internet or numerous heterogeneous LANs and WANs through routers, bridges and switches.

10


The C12.22 IP Network is C12.22 IP communications infrastructure composed of C12.22 IP Network Segments, interconnected using C12.22 IP Relays. The C12.22 IP Network shall include at least one C12.22 Master Relay.

The C12.22 IP Relay is a C12.22 Node that performs the function of a relay such as address resolution, datagram segmentation and optional message forwarding services to other C12.22 Nodes. The C12.22 IP Relay acts as a bridge between the C12.22 IP Network Segment and an adjacent, C12.22 Network Segment. It exchanges C12.22 messages between the C12.22 IP Master Relay and the C12.22 IP Nodes using TCP/IP or UDP/IP protocols over the Last Mile network. The C12.22 IP Relay is located at the demarcation point between the Backhaul and the Last Mile Smart Grid Networks and it supports a variety of different Backhaul communications options. The C12.22 Communications Modules of the C12.22 IP Relay supports a variety of different PHY/MAC interfaces at the Backhaul side (e.g. GSM or Wimax radio modules, etc) and Last Mile side (e.g. RF Mesh, Wimax, etc). In some configurations, the C12.22 IP Relay is housed in a lower compartment inside the smart meter.

The C12.22 IP Master Relay is located within the utility enterprise data center premises (head end). They operate at the top of the C12.22 Relay hierarchy and provide registration and re-registration services to all C12.22 devices in its domain. It can also acts as a C12.22 Host. The C12.22 IP Master Relay contains routing information to all accessible devices in the hierarchy and a list of notification hosts whereas the C12.22 IP Relay maintain only routing information of devices under them (e.g. C12.22 IP Nodes, C12.22 Gateways)

The C12.22 Communications Module is a communication module (hardware) that attaches a C12.22 Device to a C12.22 Network Segment. It can be physically located inside or outside the C12.22 device enclosure.

The C12.22 Device host a C12.22 application (which may also contains C12.19 data table structure) and interfaces to a C12.22 Communications Module.

The C12.22 IP Host is a C12.22 Node, which contains a C12.22 application. They can also be qualified as C12.22 Authentication Host or as C12.22 Notification Host.

o The C12.22 Authentication Host provides registration and de-registration of C12.22 Nodes in the C12.22 Master Relay domain. It can be embedded inside a C12.22 Master Relay or it can be a separate C12.22 Node on the network.

o The C12.22 Notification Host keeps track of C12.22 Nodes that are activated or de-activated in the network.

The C12.22 Gateway is required when the C12.22 Node needs to communicate with non-C12.22 Nodes, e.g. Distribution Automation devices (DNP3) such as IEDs, field devices, etc. A C12.22 Gateway translates the ANSI C12.22 to and from other non-C12.22 protocols (even on the same C12.22 Network Segment).

11


It can be attached directly to a non-C12.22 Device or can provide translation services through any network segment.

The AC12.22 Gateway is a C12.22 Node that translates the ANSI C12.22 protocol to/from other protocols and is used to communicate with non-C12.22 nodes (e.g.). It can be attached directly to the non-C12.22 or can provide translation services through any network segment.

Other important characteristics of the C12.22 IP Networking elements and its functionalities:

TCP bidirectional traffic flow is the recommended default mode operation for C12.22 IP Node communication to send and receive ANSI C12.22 Messages (APDUs).

To ensure C12.22 communications interoperability over IP between C12.22 IP Nodes, port 1153 is assigned as the default C12.22 IP Node destination port number for UDP and TCP C12.22 IP Node to send all C12.22 message requests. In addition to that, all C12.22 IP Relays and Master Relays shall monitor and accept UDP and TCP messages destined to port 1153.

At least one Unicast TCP or UDP operating capability shall be supported by every C12.22 IP Node

Multi-channel UDP and TCP shall be supported by all C12.22 IP Relays. Multi-channel UDP and TCP is recommended for all other C12.22 IP Nodes

Quality of service (QoS) tags can be provided by C12.22, under a configuration parameter, to mark urgent messages, which in turn can be mapped onto IP protocols to enable enhanced levels of message delivery and QoS across an end-to-end Smart Grid IP networking. For instance, the QoS engine could be placed at some point of the last mile network, whenever the Access Points (APs) (C12.22 IP Relay) require more distributed processing intelligence, to differentiate and prioritize Demand Response (DR) signals from meter reading and other non-critical telemetry applications.

All C12.22 IP Relays and Master Relays shall support IP Multicast message delivery service or message request from the network that reaches all C12.22 IP Nodes on the C12.22 IP Network Segment.

The C12.22 protocol also includes AES-128 security mechanisms. Additional IP transport security protocols may be provided to enhance and preserve the upper layer security provisions but not as a substitute of such.

C12.22 IP Communications Architecture

The C12.22 IP Communications Architecture is shown in Figure 5. The end-to-end IP connectivity between the utility enterprise data center (at the head end) and the end Smart Grid devices is shown here. It shows an example of the C12.22 Master Relay connecting to a C12.22 IP Node at the edge of the network. It also shows the multiple

12


network segments (Enterprise Network, MAN/Regional, Backhaul, Last Mile) and C12.22 elements (C12.22 IP Relay) it transverses to connect to the end devices (smart meters and/or DA field devices) and establish the end-to-end IP communications path between them. In this case the C12.22 Master Relay/Host could be the Head End/ AMI Meter Data Management System (MDMS) and the C12.22 IP Nodes the Smart Meter, for instance. The C12.22 IP Nodes could communicate to other C12.22 Nodes, located in another C12.22 IP Network Segment (another LAN or WAN) through a Gateway (router, bridge or switch) as shown in Figure 5. The non-C12.22 Nodes (e.g. IEDs) could also be connected to a C12.22 IP Network through an adaptation C12.22 Gateway that translates and adapts the non-C12.22 protocol to conform to an ANSI C12.22 standard.

Figure 5. C12.22 IP Communication Network Architecture

4.1.2. C.12.22 (light version) over UDP and TCP IP in Advanced Metering Infrastructure (AMI)

Another alternative and evolution of the C12.22 (full protocol) over IP is a lighter and optimized version of C12.22 for UDP/TCP, where it can be reduced to the optimum configuration to be mapped onto UDP or TCP (Figure 4b). Some existing networking provisions of the C12.22 (full protocol) can be considered redundant when mapped onto TCP or UDP as these IP suite already have similar provisions, which may be redundant to the ones present on C12.22.

13


4.1.3 C.12.18/C12.19 (no C12.22) over UDP and TCP IP in Advanced Metering Infrastructure (AMI)

Another alternative and more disruptive solution proposes a complete elimination of the C12.22 protocol from the OSI stack and the use only of the C12.19 table data messages as a payload to be transported over UDP or TCP.

The pros and cons of these non-standard based mapping schemes must be verified during the NIST Phase 3 interoperability tests and the recommendations to address existing gaps and needs for improvement must be put forward to the standards organizations as a possible standard development roadmap for the IP suite over Last Mile Smart Grid networks.

4.2 Other AMI communications standardsFor the purpose of this document, the C12.22 example is very applicable because of the inclusion of references to TCP/IP in the standard itself, as well as being the first such standard for which an RFC was submitted to the IETF in [4]. The breakdown of the method to deploy C12.22 over IP network architectures as described above is illustrative of the method that meter manufacturers and Internet Engineers can use for other operational standards in AMI, such as those utilities that have deployed meter networks based on IEC 61968. Regardless of the standard, the actors and actions in this use case remain the same; meters, data tables, head-ends, etc.

4.3 Interaction with Other IP NetworksThrough the promotion of IP in Smart Grid, it is possible to create a networking problem, primarily for the residential consumer, in the form of interactions with other IP networks. In the ideal networking scheme, the true end-to-end IP network would extend from the point of electricity generation all the way to the end device in the home. With an architecture that extensive, it becomes very likely that other devices in the home will have IP addresses on other networks. Internet routers connected to cable and satellite systems are electricity users, as is the homeowner’s PC. This may be further complicated by the fact that the homeowner would also desire to use their PC to host their energy management application. Although it’s beyond the scope of this document, it is a future consideration that bears mentioning.

5. SummaryThis document establishes the guideline principles for an End-to-End Smart Grid Communications system, particularly focused on an End-to-End Smart Grid IP Networking framework. It defines the Smart Grid Communications architecture framework, classifies and identifies the key network segments and how they can be combined to provide the interoperability framework defined by NIST [1,2]. It provides a contribution to the NIST Priority Action Plan (PAP) 01 – The Role of IP in the Smart Grid.

The key scope defined in this document is around the Smart Grid Last Mile network definitions since this is the most important and a key enabler of all other Smart Grid networking technologies being deployed today. It is also a very controversial Smart Grid network segment with all sorts of vendor solutions, technologies and protocol mapping alternatives. Particularly, the protocol interoperability mechanisms is a segment that

14


must be prioritized and addressed by the Standards Organizations to completely define an interoperability roadmap and framework around open standards protocols. For this reason, the attention of this work has been on the issues and benefits of an end-to-end solution for transporting C12.19 table data messages, to/from the end users to/from the head end, over the Internet Protocol. Different options on how to efficiently map these C12.19 messages over an IP network were presented and discussed. Considerations has been drawn on the use of existing open standards solutions, such as mapping the C12.22 (full protocol) over UDP/IP or TCP/IP as a short-term alternative for the NIST Phase 3 upcoming interoperability testing and certification process. The need for others and more optimized protocol mapping alternatives to evolve from the existing approach is also identified and discussed. This document addresses some of these issues so that the standards development community and IETF can make recommendations to come up with open and interoperable standard solutions to meet medium term NIST interoperability needs.

Today there are only a handful of standards and recommendation addressing the Smart Grid Last Mile protocol mapping and interoperability challenges since this is a recent subject and has just been identified by NIST in September 2009 under their Priority Action Plans (PAP). On the other hand, it is also acknowledged that:

(i) Several standards bodies are aware of these gaps and are and will be working towards meeting these challenges to develop a full IP protocol suite optimized for Smart Grid that is interoperable at the most important layers and network segments, and that;

(ii) Vendors and technology providers are willing to take these recommendations and make the necessary changes in their products and develop a better and interoperable solution to create a better interoperable end-to-end Smart Grid communications system.

It is reasonable to say that this is a very controversial matter as it affects several stakeholders, particularly the utilities already deploying technologies based on vendor’s proprietary solutions. However, it is also important to identify these challenges and consider the alternative solutions that need to be addressed by the standards organizations and vendors to implement an open and fully interoperable IP suite in Smart Grid

References

[1] NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0 (Draft), July 2009[2] NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0, September 2009 [3] F. Baker, “Core Protocols in the Internet Protocol Suite”, IETF draft baker-ietf-core-01, September 2009[4] A. Moise and J. Brodkin, “ANSI C12.22, IEEE 1703 and MC1222 Transport over IP”, IETF draft-c1222-transport-over-ip-01.tx, March 2009.

15


[5] A. Moise, “ANSI C12.22 Terminology”, Jan 2004.[6] IEEE, “Draft Standard for Utility Industry Metering Communication Protocol Application Layer (End Device Data Tables)”, IEEE P1377/D1, June 2009.[7] Measurement Canada, “Specification for Utility Industry Metering Communication Protocol Application Layer (End Device Data Tables)”, MC1219, 2009.[8] E.Kim et all, “Design and Application Spaces for 6LoWPNs”, IETF draft-ietf-6lowpan- usecases-04.txt, October 2009.[9] D.Sturek, “Service Discovery for 6LoWPAN”, IETF draft-ietf-6lowpan-servicediscovery- 00.txt, October 2009.[10] D.Sturek et all, “Smart Energy Requirements for 6LoWPAN”, IETF draft-ietf-6lowpan- smartenergy-00.txt, October 2009.[11] ANSI, “Protocol Specification for Interfacing to Data Communications Networks”, ANSI C12.22-2008, approved January 9, 2009.

16

Documents

The Role of the Internet Protocol (IP) in AMI Networks for Smart Grid