Once it is agreed that the Internet Protocol (IP) is an appropriate architectural model for the Smart Grid, there is the question of choosing an appropriate version of IP.  Today, the Internet runs over IP version 4 (IPv4), but with only 5% of the public IPv4 address space left, the Internet faces a major transition [OECD*] due to the predicted exhaustion of addresses by late 2011. With little existing networking legacy in areas of Field Area Networks (FANs) and Neighborhood Area Networks (NANs), there is an opportunity to validate and deploy IP version 6 (IPv6) as the de facto IP version for the Smart Grid. The industry has been testing IPv6 for nearly 15 years, and the rapid adoption of IPv6 - which provides the same IP services as IPv4 (see figure below) - would be fully aligned with numerous recommendations, such as:

• U.S. OMB and FAR
• European Commission IPv6 recommendations
• Regional Internet Registry recommendations
• IPv4 address depletion countdown

Use of IPv6 for the Smart Grid benefits from:

• A huge address space accommodating millions of deployed sensors, smart meters and new networked devices such as expected in FANs, NANs and HANs
• “Plug and play” capabilities such as IPv6 protocol suite enhanced provisioning mechanisms suitable to low-power devices. In fact, it must be highlighted that IPv6 is already the de facto IP version when “smart objects” communicate over IEEE 802.15.4 radio networks through the implementation of IETF 6LoWPAN standards (RFC 4944). No IPv4 standard equivalent has been developed.
• Future growth potential, as standardization activities across various areas will enhance the capabilities of IPv6, offering a broad landscape of opportunities for new feature development. For example, the IETF Routing over Low Power and Lossy Networks (RoLL) working group charter indicates an IPv6-only routing architectural framework for the application scenarios. This means that the Routing Protocol for Low Power and Lossy Networks (RPL) is an IPv6-only protocol.
• If and when they are needed, IPv6-to-IPv4 translation mechanisms can be deployed when FAN or NAN subnets communicate with legacy back-end systems not supporting IPv6. It should be noted that all recent operating systems do support IPV6, so translation likely will be needed only for legacy purposes.

These factors make IPv6 the obvious IP version on which to build the foundations of the IP Smart Grid.

*Reference: Organisation for Economic Co-operation and Development (OECD): http://www.oecd.org/dataoecd/7/1/40605942.pdf

With tens of standards, hundreds of products and thousands of security experts working on vulnerabilities analysis and protection assessment for the Internet and now the Smart Grid, we can’t hope to provide a comprehensive examination of smart grid security threats - and the technologies than combat them - in this space.  However, the “De-mystifying the Smart Grid” series would be incomplete without an overview of operational best practices and associated standards devoted to security.

Coupling data communications capabilities with the power transmission, distribution and consumption infrastructures will doubtless increase the power grid’s efficiency but will also create a long list of operational challenges.  Security tops that list. Some even claim that the use of open TCP/IP standards and protocols may itself represent a security issue.  But this will be overcome by the largest possible community effort and knowledge database for monitoring, analyzing and fixing flaws and threats - something no closed and proprietary system could ever achieve.

To truly comprehend the multi-layer security challenge, one must have or acquire a good understanding of network security. The detailed theory, practical analysis, assessment and discussion of the operational monitoring of the protection mechanisms mentioned below is beyond the scope of this communication.

Global connectivity, not universal access!  The adoption of the TCP/IP architecture and associated standards by the Smart Grid industry does NOT mean that a utility’s private resources will be exposed to all Internet users. Even today, the Internet is a collection of public and private networking infrastructures running IP everywhere, with each organization free to decide how to set its level of security by publicly exposing no, few or all parts of its networked resources.  For example:

• Highest Security - no exposure for critical networked resources from banks, healthcare organizations, or government agencies such as the Department of Defense, NSA, Treasury, etc.
• Standard Security - controlled exposure for some or all networked resources through well-managed Internet connecting points from enterprises, Internet service providers and public administration

Similarly, Smart Grid infrastructures should be a mix of highest and standard secure networked resources.  Certain challenges clearly will require more investigation, such as the security rules for communication in the Neighbor Area Networks (NANs) between utility devices such as smart meters and end-user devices in Home Area Networks (HAN). But this is more relevant to desired business models and products implementation than to IP standards.

Smart Grid infrastructures may have their own set of security requirements pertinent to each utility, but the expertise amassed on the following topics through the Internet’s 30- year history certainly apply.

• Security tools - years of experience have led to the development of effective IP security standards, security products and solutions (e.g., firewall, intrusion prevention, encryption), best practices and policies (access control, traffic filtering, security zones, virtual private networks) and their adoption by all organizations connecting to the Internet. These clearly apply to the Smart Grid infrastructure, although standards and products may require enhancements to cope with this new environment.
• Global cooperation - open standards and protocols have driven cooperation on security, enabling global teams to identify, inform and fix security issues, and making “security through obscurity” clearly inappropriate. Organizations such as Computer Emergency Response Team (CERT), CERT Coordination Center (CERT/CC) and Computer Security Incident Response Team (CSIRT) are collaborating with vendors. Utilities deploying Smart Grid infrastructures can leverage and benefit from this collaboration, leading the way to further standards and regulation evolution.
• Physical security - although it is generally not a protocol problem, there are many known technologies and solutions to enforce physical security. These include proper education of on-site workers about networking equipment and adequate policies such as no passwords left on remote sites, secured keys for wireless infrastructure not displayed on equipment, etc. In addition, intrusion detection services may be deployed to identify rogue devices or malicious activities.

To conclude, let’s review specific security standards to enable shared security to protect a 6LoWPAN wireless mesh network, as well as end-to-end security between each meter and the head-end to ensure data confidentiality and authenticity.

• Authentication and Integrity
  • EAP-PPP (RFC 3748 & 5247) at the link-layer can secure the link between the NIC in the meter and the meter itself.
  • EAP-TLS (RFC 5216) authenticates nodes wishing to join an encrypted network and securely distributes the link-layer key.
  • Both EAP mechanisms are based on Public Key Infrastructure (PKI) with x.509 certificates.
  • AES-128 wireless link-layer authentication and encryption according to the IEEE 802.15.4 standard ensure NAN IP wireless sensor network integrity.
  • RADIUS (RFC 2865, 2869, 3579 & 5080) allows communication between the authenticating neighbor and the head-end authentication-authorization-accounting (AAA) server.
  • Software image signatures use the head-end’s private key.
  • Networking devices management access through SSH.

• End-to-end security
  • Once the secure link is joined, end-to-end security is established between nodes and the head-end using the Datagram Transport Layer Security (DTLS) protocol (RFC 4347).
  • When securing the data, DTLS is used with RSA public/private keys, signed by a Certificate Authority (CA) at the head-end for authentication so each node opens up an end-to-end secure DTLS session with the head-end.
  • An IP-over-UDP tunnel within a session allows multiple protocols (CoAP or EBHTTP, RADIUS, firmware update) to be securely transported.
  • Firewalling on the NAN edge router restricts traffic between the meters and the head-end so that, even if a meter is compromised, only the valid protocols will be passed through the head-end’s tunnel server.
  • Individual control message signatures using the head-end’s private key enable a meter to check for validity even though the messages are going over a secure tunnel. This provides additional protection against a compromise within the head-end network.

Several other security standards exist and could be used, for example IPsec provides the mechanisms to protect all communications at the IP layer. As demonstrated by NIST efforts, it is now a good time for an infrastructure design session engaging utility companies, vendors and security experts to define what are the most pertinent security mechanisms and policies for the Smart Grid industry.

Reference

• NIST IR-7628 - Draft Smart Grid Cyber Security Strategy and Requirements

The selection of open standards by the smart grid industry rightly includes protocols derived from the World Wide Web (WWW) and the IETF TCP/IP architecture. However, many of the smart meters, sensors, actuators, relays and other devices that will be deployed in the various parts of a smart grid infrastructure fall under the definition of “constrained node”.  This means one or more of such devices’ characteristics, such as CPU power, RAM or ROM memory size, communication throughput or available energy consumption, is limited and a candidate for any kind of optimization guaranteeing appropriate lifetime and functionality.

Constrained devices have data exchange requirements  that fall close to the “Internet of Things” or machine-to-machine (m2m) models.  Standards bodies are now working on improving protocols that would better suit these  constrainted nodes. Let’s have a look at two promising standardization efforts coming from the World Wide Web consortium (W3C) and Internet Engineering Task Force (IETF) working groups.

Efficient XML Interchange (EXI)

Conceived as a markup language for data and documents independent of any particular application area, the eXtended Markup Language (XML), along with the wide experience obtained through its implementations, deployments and use, make it an obvious choice for smart grid application developers. However, because XML’s text format was not optimum for constrained devices, the W3C studied the requirements in the XML Binary Characterization WG and developed an alternate encoding format of the XML Information Set.

To improve performance significantly and reduce bandwidth requirements, the Efficient XML Interchange (EXI) format uses a grammar-driven approach that achieves very efficient encoding using a straightforward encoding algorithm and a small set of data type representations.  This allows programming modules to be enhanced to encode their structured data into EXI streams and/or to decode EXI streams to make the structured data better adapted to constraint nodes.

Constrained RESTful Environments (CoRE)

More a web services architecture than a standard per se, REpresentational State Transfer (REST) describes the usage of web standards.  A RESTful service is thus based on the HTTP protocol, URLs and XML.

Some months ago, a new IETF working group - Constrained RESTful Environments (CoRE) WG - was created to design a Constrained Application Protocol (CoAP) addressing the specific requirements of constrained environments.  CoAP is specified for fulfilling M2M requirements through the following key features:

• Operation by default over UDP but also potentially over other transports such as TCP or SCTP
  • Simple stop-and-wait retransmission reliability with exponential back-off
  • Transaction ID for response matching
  • Multicast support
• Asynchronous transaction support
• Low header overhead and parsing complexity
• URI (coap://[2001:DB8::CAFE]/s/temp) and content-type support
• Stateless HTTP mapping, allowing proxies to be built providing access to CoAP resources via HTTP in a uniform way or for HTTP simple interfaces to be realized alternatively over CoAP
• Built-in resource discovery, enabling both unicast and multicast discovery of resources including filtering on attributes of resource descriptions; can also be used to discover HTTP resources

Candidate Recommendation 1.0 of the EXI format specification was published in December 2009, while CoRE draft-01 was made available for the July 2010 IETF-78 meeting. Both demonstrate the benefits of open standards when transitioning small-footprint devices to IP and provide a way to implement a set of optimization mechanisms in constrained smart grid devices such as those deployed on Advanced Metering Infrastructures or Home Area Networks.

References

• http://www.w3.org/XML/EXI/
• http://www.w3.org/TR/exi/
• https://datatracker.ietf.org/wg/core/charter/
• https://datatracker.ietf.org/doc/draft-ietf-core-coap/

Among the applications that fall under the “Smart Grid” umbrella, “metering” is without doubt a central piece that has garnered considerable attention from both the industry and consumers. Evolving from classic electromechanical foundations, the next generation of electricity/gas/water meters – referred to as “smart meters” –offer bi-directional communications using an open-standards IP-based stack and associated communication interfaces such as IEEE 802.15.4g.

Utilities can offer new classes of business and operational services as defined by the IEC 61968 standard through the deployment of smart meters and an Advanced Metering Infrastructure (AMI), in conjunction with new Meter Data Management System (MDMS) software. Enabling these services requires that the exchange of information between the smart meters and the business functions within a distribution management system (DMS), be standardized.  This is the objective of the IEC 61968-9 standard, called “Interfaces for meter reading and control”.

Leveraging the real-time bi-directional communication capabilities for meter reading and writing (control), IEC 61968-9 defines a list of functionalities – metrology, communications, connect/disconnect, load control, demand response and relays – and the related set of XML-based key message payload structures:

• CustomerMeterDataSet
• MeterAsset
• MeterAssetReading
• EndDeviceControls
• EndDeviceEvents
• MeterReadings
• MeterReadSchedule
• MeterServiceRequest
• MeterSystemEvents
• EndDeviceFirmware

Smart meters can implement these functions if each device:

• has a unique identity
• is managed as a physical asset
• can issue events
• can receive control requests
• can collect and report measured values
• can participate in utility business processes

Focused on “metering”, IEC 61698-9 also specifies the data flow between the following logical components and sub-components of a smart metering system and the other IEC 61968 business functions:

• Metering system
  • Data collection
  • End point controls
  • End point reconfiguration
  • Disconnect/reconnect
  • Demand reset
  • On request read
  • Point of sale
  • Outage detection and restoration verification
  • Power reliability and quality events
  • Metering system events
• Meter data management
  • Meter data repository
  • Usage history
  • Validation, estimation and editing
  • Customer billing data
• Meter maintenance and asset management
  • End point install, configure, remove, repair, disconnect, reconnect
  • End point asset history
  • End point reconfiguration
  • Special read
  • Meter service request
  • Tariffs
• Load management
  • Load analysis
  • Load control
  • Demand response
  • Performance measurements
  • Risk management

By way of illustration, this screenshot shows an IEC 61698-9 XML message of meter readings.

If a utility Common Information Model (CIM) is essential for guaranteeing true end-to-end open standards-based Smart Grid communications, a major challenge is the requirement that it cover all domains and data exchanges in electrical networks.  (Similar challenges exist for water and gas networks.)

The disparate and distributed applications a utility runs to manage electrical distribution networks range from distribution management to system outage-management, planning, metering, work management, geographic information, asset management, customer information and enterprise resource planning systems.  Obviously a set of interfaces and a common language must be defined under a Distribution Management System (DMS) framework.

Toward this end, the International Electrotechnical Commission (IEC) is actively developing the IEC 61968 standard series, which defines the architecture and interface reference model facilitating the implementation of middleware services that broker messages among applications within a distribution management domain.

The IEC 61968 series of standards - not all of them yet published - consists of:

• IEC 61968-1 - Interface architecture and general requirements
• IEC 61968-2 - Glossary
• IEC 61968-3 - Interface for network operations
• IEC 61968-4 - Interfaces for records and asset management
• IEC 61968-5 - Interfaces for operational planning & optimization
• IEC 61968-6 - Interfaces for maintenance & construction
• IEC 61968-7 - Interfaces for network extension planning
• IEC 61968-8 - Interfaces for customer support
• IEC 61968-9 - Interfaces for meter reading & control
• IEC 61968-10 - Interfaces for business functions external to distribution management
• IEC 61968-11 - CIM extensions for distribution maintenance
• IEC 61968-12 - CIM use cases for 61968
• IEC 61968-13 - CIM Resource Description Framework (RDF) Model exchange format for distribution maintenance
• IEC 61968-14-1-3 to 14-1-10 - Proposed IEC standards to map IEC61968 and MultiSpeak standards
• IEC 61968-14-2-3 to 14-2-10 - Proposed IEC standards to create a CIM profile to implement MultiSpeak functionality

It is important to highlight the adoption of the eXtensible Markup Language (XML) - an open enterprise web standards and data format - as the common language for all IEC 61968  interfaces.  This represents a  powerful acknowledgement that the industry is moving toward the adoption of end-to-end IP-based stacks such as Arch Rock PhyNet-Grid.

The “De-mystifying Smart Grid Standards” series started by reviewing new networking specifications - IEEE 802.15.4g, 15.4e, RoLL - part of the end-to-end Smart Grid communications architecture. The adoption of a TCP/IP-based framework for network communications enables Smart Grid applications to develop independently of the lower layers’ evolution and to leverage the standards-based two-way communications capabilities for important benefits such as:

• Load control
• Dynamic pricing
• Outage detection
• Distributed energy resource (DER) control signals
• On-demand read

But TCP/IP does not address the challenges of data representation and exchange within and between Distribution Management Systems such as these Smart Grid domain/sub-domain examples:

• Customer domains
  • Business/building Area Networks (BAN)
  • Home Area Networks (HAN)
  • Industrial Area Networks (IAN)
• Operation domains
  • Monitoring
  • Control
  • Fault management

Considering the Smart Grid’s wide-scale deployment and interoperability requirements, it becomes obvious that the transition from closed or proprietary implementations to open standards must be achieved using the Common Information Model (CIM) to enable better reliability and efficiency. This can be done by:

• Adopting specific standards per element such as ANSI C12.19 - an established standard that defines an electric meter data model and application-layer message format.
• Converging to Common Information Model specifications applicable to multiple domains such as IEC 61968 - open interfaces and messaging standard becoming widely implemented for application-level energy management systems.

Therefore, by choosing to use

• IEC 61968 XML messages as the native format for interchange between head-end and the rest of the utility systems
• A compressed version of those same IEC61968 XML messages as the native format for communication between the head-end and the smart meters themselves.
• Similar IEC 61968 concepts in Smart Energy Profile 2.0 for HAN, carried over the same TCP/IP stack

A complete alignment of stacks in and between domains is now possible for true end-to-end open standards-based Smart Grid communications .

At the upcoming IETF 78 meeting, the Routing over Low power and Lossy Networks (RoLL) Working Group – co-chaired by Arch Rock CTO Dr. David Culler – will review the IPv6 Routing Protocol for Low power and Lossy Networks (RPL) core draft prior to an expected “last call.” Acceptance – after potential modifications – will mean the protocol specifications would be published as a Request for Comment (RFC) and be implemented by vendors.

IP routing is a key feature for the Smart Grid industry. By implementing RPL, the Advanced Metering Infrastructure (AMI) will benefit from basic IP routing characteristics such as:

• Dynamic discovery of network paths and destination “reachability”
• Ability to adapt to logical network topology changes, equipment failures or network outages “on the fly”
• Independence from data-link-layer technologies
• Different AMI networks’ exit paths through multiple edge routers for high availability and load balancing

Why is a new routing protocol necessary when several protocols – RIP, OSPF and IS-IS – have already been specified, implemented and deployed? Because smart meters are a typical example of “constrained” nodes as defined by the RoLL WG routing requirements documents (RFC 5548, 5673, 5826 and 5867). Constrained nodes are those

• Built with limited processing power, memory and sometimes energy when operating on batteries
• Interconnected through a low-data-rate network interface and potentially vulnerable to communication instability and low packet delivery rates
• Potentially having a mix of roles, being able to act as “host” (generating traffic) and “router” (both forwarding and generating RPL traffic).

Considering the wide variety of use cases, link types and metrics, RPL has been designed to separate packet processing and forwarding in the generic RPL core document from routing optimization objectives in the Routing Metrics and Objective Functions documents.

Some useful RPL terminology:

• Directed Acyclic Graph (DAG): A directed graph with all its edges oriented in such a way that no cycles exist. All edges are contained in paths oriented toward and terminating at one or more root nodes.
• DAG root: A DAG root is a node within the DAG that has no outgoing edge. Because the graph is acyclic, by definition all DAGs must have at least one DAG root and all paths must terminate at a DAG root.
• Destination Oriented DAG (DODAG): A DAG rooted at a single destination - i.e., at a single DAG root (the DODAG root) with no outgoing edges.
• DODAG root: the DAG root of a DODAG.

Key RPL characteristics:

• Upward routes – a node running RPL will join a DODAG by discovering neighbors that are members of the DODAG of interest, identifying a set of parents and maintaining upward routes to the DAG root.
• Downward routes – a node running RPL will discover and maintain downward routes. Downward routes support P2MP flows from the DODAG roots toward the leaves. Downward routes also support P2P flows: P2P messages can flow to a DODAG root through an upward route, then away from the DODAG Root to a destination through a downward route.The RPL specification describes the two modes an RPL instance may choose for maintaining downward routes. In the first mode, called “storing,” nodes store downward routing tables for their sub-DODAG. Each hop on a downward route in a storing network examines its routing table to decide on the next hop. In the second mode, called “non-storing,” nodes do not store downward routing tables. Downward packets are routed with source routes populated by a DODAG Root.
• Loop avoidance – rank-based data path validation mechanisms for detecting loops when they do occur, avoiding problems such as count-to-infinity
• Data-path validation using a new IPv6 Hop-by-Hop Option to detect possible loops within a
  DODAG.
• Trickle timer to manage advertisement transmissions, allowing new information to spread on the scale of link-layer transmission times while sending only a few messages per hour when information does not change.
• Objective Functions – defines how RPL nodes select and optimize routes within an RPL instance to honor a given deployment’s particular routing objective or constraint. Objective Function design leverages the routing metrics. An Objective Function 0 uses the abstract properties exposed in RPL messages to maximize connectivity.
• Routing metrics used to compute the best or shortest constrained path
  A routing metric can be additive or multiplicative, and reports the following:
  • Node state and attribute – information on node characteristics such as CPU overload, lack of memory and other conditions
  • Node energy – determining if a “longer” path that traverses mains-powered nodes or nodes equipped with energy scavenging is preferable to a “shorter” path through battery-operated nodes
  • Hop count – the number of nodes traversed along the path
  • Link throughput – the range of throughput that the link can handle in addition to the currently available throughput
  • Link latency – similar to throughput but for latency
  • Link quality level – link reliability from unknown to highest link quality level
  • Link ETX – the number of transmissions a node expects to make to a destination to successfully deliver a packet
  • Link color – an administrative 10-bit static link constraint used to avoid or attract specific links for specific traffic types

The IPv6 Routing Protocol for Low power and Lossy Networks (RPL) represents a powerful tool for scalable deployment of Advanced Metering Infrastructures. In addition, AMI Edge Router(s) will insure connectivity with the IP infrastructure from utilities or Internet service providers though one of the following methods:

• Root node on the infrastructure side in a larger RPL domain
• Route redistribution between RPL and other routing protocols running in the infrastructure
• Secure tunnel’s end-point to constrain access through a single aggregation point

We will monitor and report later on what happens at IETF 78.

Reference:
RoLL documents: http://datatracker.ietf.org/wg/roll/

Very often, standards bodies have to cope with different requirements from various application domains. Such challenges are solved by defining standard options when conflicts exist between the applications’ requirements. In the case of IEEE 802.15.4, a worldwide standard for wireless and low-power transmission of sensor data, adopted by industrial solutions such as 6LoWPAN, IEC 62591 (WirelessHART), ISA100.11a, and ZigBee, MAC amendments to the original IEEE 802.15.4 specifications have been proposed by the 802.15.4e Task Group.

Here, we review the two main proposed IEEE 802.15.4e enhanced mechanisms suitable for Smart Grid applications and developed in close relationship with the 15.4g Task Group.

Low-energy MAC extension

The optimization of energy consumption in Smart Metering matters when considering requirements such as:

• Water and gas metering applications – battery-operated, multi-year lifetime
• Electricity metering applications – battery-operated to cope with power outages
• All IP metering applications – illusion of being “always on” for applications
• Reduced impact on mesh network convergence in case of power outages

The 15.4e Task Group selected two low-energy mechanisms.  One – Coordinated Sampled Listening (CSL) – is suitable for applications with relatively low latency requirements (< 1 second), making it a de-facto choice for IP-based smart metering applications.  The other - Receiver Initiated Transmission (RIT) – applies to applications with higher latency tolerance (tens of seconds).

CSL allows receiving devices to periodically sample channel(s) for incoming transmissions to a fraction of 1% duty cycles – guaranteeing multi-year battery life while being IP-friendly by presenting an illusion of being “always on”.

Channel Diversity

Smart metering deployments will occur in urban and rural environments where radio interference is a fact of life (i.e., because of the need to co-exist with IEEE 802.11 (WiFi) and the large numbers of nodes in proximity). To overcome the poor signal quality resulting from wide receiver channel variations, 15.4e provides two types of channel diversity methods:  Channel adaptation (a channel in use does not change until the received signal quality drops below a threshold value) and channel hopping.

Channel hopping is well suited to the new IEEE 802.15.4 PHY added in 15.4g (Smart Utility Networks Task Group).  It enforces channel switching at specific time slots, and at most according to a predefined channel-hopping pattern.  The channel hopping pattern, or sequence, is set by the Next Higher Layer (NHL).  If the receiver channel capacity is expanded to exploit the entire available RF channel spectrum, signal quality should be significantly improved, becoming less subject to interference and delivering higher throughput.

Utility companies, metering vendors, smart grid designers and architects can now leverage the MAC enhancements proposed by IEEE 802.15.4e TG as implemented by Arch Rock in PhyNet-Grid.

Last week, the Maryland Public Services Commission rejected the Baltimore Gas and Electric company’s proposal to implement smart meters in its service territory^[1],[2].  BGE’s proposal would have passed on the cost of the new meters to the rate-payers.  This, along with the potential for early obsolescence of the technology, were among the reasons cited by the MPSC for the rejection, which  came as shock to the advanced metering infrastructure (AMI) industry.

The MPSC is very rightly concerned about the evolving nature of the technology and its implications for the consumer.  In its role as state utility watchdog, the MPSC is simply rejecting the possibility of the rate-payer’s being charged twice as smart meter technology goes from proprietary to standards-based in the next few years, as the National Institute for Standards and Technology (NIST) is requiring.

The MPSC ruling noted that the technology on which the proposed meters are based is “dominant in the AMI market” yet has not yet been adopted by any appliance manufacturers^[3].  This apparent contradiction simply reflects the fact that the AMI industry has been developed by a few pioneering vendors and industry organizations that have developed proprietary technology and communications protocols; and a few early-adopter utilities that have deployed it.  This is always the case with innovative new technologies.

But in order to lower the cost of AMI and thus promote the rapid growth of the Smart Grid with all attendant benefits to consumers and the economy, we need open standards.  Standards that have powered the growth of the Internet and associated data links such as 802.3 (Ethernet), 802.11 (WiFi) and 802.15.4 (used by 6LoWPAN) — established by IETF and IEEE - are now being mandated for AMI by NIST.  (A previous blog entry^[4] has outlined these new standards.)

The MPSC’s ruling is a reminder to us all that open and durable standards are a must for the AMI and Smart Grid to move forward.

Notes:

1. MPSC ruling: http://webapp.psc.state.md.us/Intranet/Casenum/NewIndex3_VOpenFile.cfm?ServerFilePath=C:\Casenum\9200-9299\9208\\59.pdf
2. NY Times commentary: http://www.nytimes.com/cwire/2010/06/23/23climatewire-mds-veto-of-advanced-meter-deployment-stuns-95998.html
3. MPSC Ruling. Page 39.
4. Arch Rock blog on Smart Grid standards: http://www.archrock.com/blog/2010/06/07/from-phynet-architecture-to-smart-grid-standards/

One of the recognized benefits of the adoption of the TCP/IP architecture for Smart Grid is its ability to run over any kind of physical and data link layers by adapting to all wired and wireless communications technologies.  In the absence of a standard like TCP/IP, Smart Grid vendors have put a number of non-interoperable communications protocols and technologies forward.  However, to meet the specific regional and national regulations in a global Smart Grid deployment environment in a scalable and cost-effective way, these current technologies will need to evolve to IETF and IEEE standards.

This is what led the Institute of Electrical and Electronics Engineers (IEEE) to assign a Task Group – IEEE 802.15.4g, also known as the Smart Utility Networks (SUN) Task Group – to review the IEEE 802.15.4-2006 standards, proposing amendments principally for outdoor low data rate, wireless, smart metering utility networks.

Let’s review the alternate PHY layers and related MAC modifications done under IEEE 802.15.4g and now integrated under the 802.15.4/6LoWPAN sub-layer of the Arch Rock PhyNet-Grid framework.

• IEEE 802.15.4g adds five new Physical layers with three of them targeting smart utility network (SUN).
• SUN 802.15.4g-compliant devices shall at least implement one of these three new PHYs modes:  a multi-rate and multi-regional frequency shift keying (MR-FSK) PHY, a scalable orthogonal frequency division multiplexing (OFDM) PHY, and a multi-rate and multi-regional offset quadrature phase-shift keying (MR-O-QPSK) PHY.
• 15.4g addresses regional regulations – North America, Europe, Japan, Korea and China – by adding support for new frequencies including sub-GHz frequency bands. IEEE 802.15.4 radio can now operate at one of the dedicated use or unlicensed band.
  • 400–430 MHz (Japan)
  • 450–470 MHz (United States)
  • 470–510 MHz (People’s Republic of China)
  • 863–870 MHz (Europe)
  • 896–901 MHz (United States)
  • 901–902 MHz (United States)
  • 902–928 MHz (e.g., North America)
  • 922 MHz (Korea)
  • 928–960 MHz (United States)
  • 1427–15181 MHz (United States, Canada)
  • 2400–2483.5 MHz (worldwide)
• Over-the-air data rate throughputs – dependent from the radio frequency and coding of each PHY – now ranging from 5kb/s to 851kb/s.
• Given the environmental conditions of principally outdoor communications encountered in Smart Metering deployments, 802.15.4g devices will be designed to operate in very large-scale process control applications. The new PHY deliver an optimal energy efficient link margin in order to use the maximum power available under applicable regulations, enabling all kind of deployments from geographically widespread communications to a large number of outdoor devices.
• A Multi-PHY Mode management scheme is specified to enable inter-PHY mode co-existence. It will help to mitigate interference due to networks with different PHY modes operating in the same location.
• Three device classes have been defined considering an expected volume of data that could be transmitted over 24H00 periods. It is based on the capability of utilizing the most efficient methods of data transmission to maximize overall system performance.
  • Class A – capable of efficiently supporting data throughput for an average greater than 10,000,000 symbols per 24 hours
  • Class B – capable of efficiently supporting data transfer for an average range of 10,000 symbols through 10,000,000 symbols per 24 hours
  • Class C – capable of efficiently supporting data transfer on an average of less than 10,000 symbols per 24 hours
• New channels assignments resulting from the introduction of the SUN PHY specifications which exceed the channel numbering capability defined in IEEE 802.15.4-2006.
• PHY frame sizes can now be up to 1500 bytes
• Enhanced Data integrity through a 32 bits CRC
  With a final IEEE 802.15.4g document expected end of 2010, a new and open ecosystem for large volume of standards-based semiconductors, including management tools, protocol analyzers and diagnostics tools can appear, helping to meet Smart Grid market expectations.