RTC Magazine

Of all the global protocol standards, IP remains the single unifying layer that enables any device anywhere to identify and communicate with another. Unfortunately IPv4, which has been serving the Internet for over three decades, has nearly exhausted its address space. At the same time, the emergence of smart sensor networks comprising the “Internet of Things” (making everyday, ordinary objects smarter and connected) is introducing millions of new IP connected Smart Objects commanding an explosion in demand for IP addresses. With a theoretical address space of 340 undecillion (or 3.4x10³⁸) and additional benefits such as stateless auto configuration, simplified header structure, inclusion of multicasting as a base capability, and mandatory support of IPsec, IPv6 is well suited to take the helm from IPv4 as the principal networking layer. Despite seeing limited deployment since its introduction in 1998, it may now be ready for prime time.

On June 8, 2011, a day commonly known as World IPv6 Day, the Internet Society organized a global scale trial of IPv6 across more than 400 forward-looking organizations including search engine companies, social network websites, Internet backbone providers and content distribution companies. Although not completely issue free, the results were promising, with major participants reporting no significant problems. Along with several examples of IPv6 network deployments on smaller scales, these results suggest that the technology is ready to support large-scale migration over the next several years. Additional information on IPv6 Day including the list of participants is available via the Internet Society and the World IPv6 Day entry on Wikipedia.

In addition to core IPv6 maturity across the Internet, the IETF and other groups are driving contributions that make IPv6 viable for resource-constrained smart objects and the low power and lossy networks (LLNs) that connect them. The IETF 6LoWPAN working group is defining mechanisms for header compression and fragmentation in support of these objects and LLNs that  are often just referred to as 6LoWPANs. Additionally, the IETF Core working group is providing a framework to enable RESTful web services to work efficiently on 6LoWPANs, and the IETF ROLL working group is defining route protocols for use in mesh-based LLNs.  Meanwhile, the IEEE 802.15 working group is defining layer 1 and layer 2 standards applicable to smart utility networks (SUNs) and 6LoWPANs. 

IPv6 for the Smart Grid

The most commonly referenced models of the Smart Grid (SG), such as those defined by the OpenSG and IEEE P2030, depict a series of interconnected networks including Field Area Networks (FAN), Advanced Metering Infrastructure (AMI), Home Area Networks (HAN), substation networks, and even the Internet. The breadth of such a network demonstrates the value of IP as the common network layer. IPv6 has emerged as the standard of choice across industry consortiums and standards bodies addressing the Smart Grid. Utilities are embracing this new direction as shown through plans to enhance their Distribution Automation (DA) and AMI networks to become IPv6-enabled SUNs, and through the identification of key new applications and services that will leverage this core technology.

Smart Grid Applications on the SUN

According to Dan Nordell of XCel Energy, we should expect IP to pave the way for utilities to create more distributed intelligence in the networks. This is in contrast to the centralized master-slave models that dominate the industry today. Peer-to-peer communications between intelligent endpoints in DA networks can enable rapid corrective action procedures to be implemented by Intelligent Electronic Devices (IEDs) in response to fault conditions. For example, a fault near the feeder relay of substation A shown in Figure 1 could trigger an IPv6 dialog on the FAN between the recloser control and tie switch control, which could effectively first isolate the fault and second restore service by enabling the secondary feed (substation B) to provide power. IED vendors have taken note and are delivering IP-enabled IEDs for remote deployment on FANs. Nordell is interested in going even further with peer-to-peer applications and envisions similar services between electric meters. 

Peer-to-peer communication is certainly not the only new application model available to utilities operating an IPv6 SUN. Applications hosted in an operations center can be designed to interact directly with smart objects on the SUN. For example, a demand response application may communicate over IP directly with a load control module to perform a load shed event or could even use IP multicast signaling to efficiently distribute a load shed event en masse. The emergence of plug-in electric vehicles (PEVs), which by nature are nomadic and could appear at any point in time on different network segments within the Smart Grid, is another prime example where applications will benefit from use of IP as a ubiquitous network layer. 

Addressing Plans for SUNs

Certainly the 128-bit address space of IPv6 appears to accommodate the vast addressing needs of the Smart Grid, Internet and private enterprise alike. IPv6 theoretically has an address space sufficient to assign hundreds of thousands of addresses to every ant in the world and still have enough left over for people to get a few thousand each too. In practice, however, IPv6 may not yield the address space expected without some tricks, and utilities will need to provide due diligence in deciding how to organize their address space.  

Consider the default organization of the IPv6 address. The 128 bits are sliced in half with the upper 64 serving as the general network prefix and the lower 64 as the interface identifier.  Of the upper 64 bits, 16 were intended to be used for subnetting with customers such as utilities typically receiving a /48 network prefix supporting as many as 65,536 subnets. In theory, a utility could assign a single subnet to a SUN and never possibly deploy enough meters, remote terminal units (RTUs) or other endpoints to consume the whole space. A potential challenge however is that endpoints on a SUN network may actually serve as IP gateways (routers) to subtended networks. An RTU may have multiple IEDs behind it while a home area network (HAN) may subtend a meter on the AMI network. In such cases, each SUN endpoint would require a subnet prefix in order to provide IPv6 routing to subtended endpoints. At one subnet per HAN then, the typical /48 address space effectively only addresses 65,536 consumers. Borrowing a few bits from the remaining 48 dramatically improves the situation, however, as a /46 offers over a million subnets and /44 over 16 million. 

At present, this addressing prefix dilemma has received little attention for a couple of reasons. For one, DA networks tend to consist of a few thousand rather than a few million endpoints. Secondly, the ZigBee Alliance Smart Energy specification, which is the prevalent model for supporting services to consumers on HANs today, does not expose individual HAN endpoints as globally routable. Instead, an energy services interface (ESI) acts as an application gateway between the HAN and the AMI network and effectively isolates the HAN from the address space of the SUN. 

The ESI-centric model for bridging the SUN and the HAN is presently well established throughout the industry. However, with end-to-end IPv6 connectivity becoming ubiquitously available across the SUN, history would suggest that competing models will emerge that embrace the end-to-end IP application philosophy. On the DA front, the introduction of cost-effective IPv6-enabled line sensing and distribution transformer monitoring devices could increase the number of endpoints by an order of magnitude. These possible evolutionary paths for HANs and DA suggest that initial addressing models may be revisited and should maintain some flexibility for future growth.

Security in the SUN

As with any Smart Grid application, security is paramount. Nordell and other industry security experts such as Sandy Bacik of EnerNex, agree that while SG Cyber security requirements are progressing and improving, we still have a long way to go to evaluate the risks and complete the security suite. While IPsec is explicitly included as a component of IPv6, it has not presently garnered much attention for securing either the HAN or the SUN. Link layer and application layer security tend to be favored presently and are sufficient for most current applications, which tend to be designed around this kind of security model. 

IPsec should not be dismissed just yet, however, as the nature of utility applications is set to evolve with the availability of globally routable IPv6 capabilities on the SUN. IPsec transport mode could become an effective way to provide two-way authentication and encryption for end-to-end IP applications that traverse several layer 2 sub networks across the Smart Grid. While the upside of the IPsec security model is compelling, challenges associated with key management and key exchange are not trivial, and to date there has not been deployment on any large scale on either IPv4 or IPv6. 

Application Protocols for the SUN

IP offers developers many choices of application protocols in delivering new services. When building new applications developers are often eager to turn to a RESTful web service approach leveraging the established web standard for applications—HTTP. Supporting HTTP on SUNs may present performance and scale challenges that must be factored into application designs. Fortunately, the IETF Constrained RESTful Environments (CORE) working group is developing an architecture and application protocol (CoAP) to extend the benefits of RESTful application development to constrained environments. Hence, it is possible for CoAP to emerge as a serious application protocol option for Smart Grid applications while preserving the benefits and practices of developing applications using HTTP tools and methods.  

There are plenty of other application protocol candidates as well, so there is no need to choose just one. For example IEC 61850, originally introduced as a substation automation protocol, has emerged as a candidate for peer-to-peer communications in DA networks. On the AMI side, C12.22, which was designed to support C12.19 table reads over network layer protocols such as IP, has shown limited success but is in demand in certain markets. DLMS-COSEM, which also supports IP as one of its transport options, is enjoying some success in Europe and is a candidate to become the smart metering application protocol standard in the UK. 

Lighting control systems are an exemplary use case for 6LoWPAN. Intelligent lighting systems are adding smart sensors as a means to monitor, report and manage energy consumption to reduce total energy usage by 20% by the year 2020. Adding daylight and proximity sensors to a lighting control system can balance the contribution of daylight to reduce the light’s lumen output or turn off the light when there is no one in the area. Until now, those sensors had to be hardwired together, which required a costly installation to pull wiring through walls, reducing the ROI for the sensor network. With the introduction of 6LoWPAN wireless systems, lights can be grouped independent of wiring, resulting in scalable, flexible control as each end device has a unique address (Figure 2). 

With the availability, maturity and stability of IPv6-enabled equipment, services and networks, and in conjunction with innovative solutions for enabling IPv6 on LLNs emerging from the IETF and other consortiums, IPv6 is indeed poised to emerge from its 13-year hibernation as the networking technology of choice for the Smart Grid, SUNS and the Internet of Things.  

Sensus NA

Raleigh, NC.

(800) 638-3748.

[www.sensus.com].

Texas Instruments

Dallas, TX.

[www.ti.com].