SIP: The Clear Choice for Smart Grid Communications
Jun 23, 2009
by Joe DiAdamo
Editor’s note: In an in-depth position paper available at Smart Grid Central (see link at bottom), Joe DiAdamo of Siemens Enterprise Communications makes the case for employing the Session Initiation Protocol (SIP) for Smart Grid communications. The following is a summary of that paper. See the link at the bottom for a copy of the full report.
Today’s solutions for Smart Grid communications are proprietary and vertically integrated.Although this is to be expected for a market in the innovation phase, an open, standards-based architecture for Smart Grid communication is now needed for the market to cross the chasm to mainstream acceptance and deployment. Governments and power authorities have recognized this need and are moving quickly to provide funding for those companies and projects whose products and technologies are open and based on standards that allow interoperability, especially Internet technologies.
The recently enacted American Recovery and Reinvestment Act of 2009 (ARRA) mandates an open, standards-based approach for Smart Grid communication. Similarly, the Ontario Smart Grid Forum, a group of industry leaders in
Ontario,
Canada, recommended a communications system that is (1) flexible enough for both current and future Smart Grid equipment, (2) based on open standards, and (3) designed with interoperability.
The telecommunications industry had an almost identical set of requirements for its technological revolution some decades ago. The Session Initiation Protocol (SIP) emerged as the leading solution for these requirements. SIP further evolved to create a new generation of multimedia, unified communication that has proven to be the real revolution.
SIP is an application-level communication protocol conceived using Internet concepts and provides all the openness, standardization and interoperability required by the Smart Grid architects. As SIP is based on internet protocol (IP), it leverages much of the functionality provided by an IP network (e.g. TCP, UDP, QoS, routing). Not surprisingly, communications giant Cisco Systems recently threw its weight behind an IP-based communication infrastructure for the Smart Grid.
SIP has everything that is needed to be the application-layer protocol for Smart Grid communications. Consider the following arguments in its favor:
Maturity. SIP is a mature protocol and has proven to be reliable, secure, and scalable. SIP has also proven to be easily extensible and, by definition, independent of the specific data exchange requirements of the communicating devices.The implementation of SIP in the enterprise and carrier markets has resulted in the creation of network elements such as proxy servers, device registration servers and session border control servers that have made widespread deployment easy and secure. These same network elements are required for the Smart Grid and can be readily adapted for rapid implementation.
Consistent with current standards. SIP is consistent with all current standards and architecture initiatives for the SmartGrid, filling many of the device communication requirements specified by the technical committees. For example, the American National Standards Institute (ANSI) standard C12.22 defines interfaces and network elements for two-way metering communication systems. Many of the network element concepts defined in ANSI C12.22 are already developed and verified for SIP networks.
Broad device and application support. SIP can provide the communication semantics to support device-to-device, device-to-back-office and back-office-to-device communication, while allowing the use of data models such as the International Electrotechnical Commission’s (IEC’s) Common Information Model CIM for the device-specific data exchange protocol.SIP’s payload-independent design allows a payload such as ANSI C12.19 tables to be transported exactly as they are defined in the standard, providing automatic compatibility at the syntax level with existing applications.
Support for mobile metering. A key element of many Smart Grid initiatives is support for Plug-in Electric Vehicles (PEVs). PEV batteries need to be charged from the grid, of course, but they can also contribute energy to the grid during peak usage times. Both of these operations require sophisticated metering to support the debiting and crediting of energy accounts associated with the using of and feeding to the grid.Further, as PEVs are automobiles, they will require support for mobile metering. For example, the owner of a PEV who needs to charge the battery when away from home will want to have the cost of that energy debited to their account, not to the account of the owner of the home they happen to be visiting.SIP’s location register provides native support for device and user mobility.A SIP user can be found independent of the location and network connection. This functionality is critical to support of mobile metering where the PEV, for example, needs to connect to a back-office energy system different than the one used by the local fixed meter.
Flexible security design. Security is very important in Smart Grid communications and must address, among other things, device identification, intrusion prevention, data integrity and privacy. SIP supports all modern security mechanisms for Internet communication, including IPSec, Secure MIME and TLS. Further, SIP’s extensible design allows for support of new security mechanisms as they emerge and evolve. This flexible security design allows for implementation in high-security environments such as those involving a substation as well as less stringent environments such collection of usage data from smart meters.
Multimedia and advanced communication options. Finally, SIP brings native voice, video, and text communication to the Smart Grid, as well as advanced communication concepts such as presence and location. Enabling a mobile workforce is a key business driver for many utility companies and an architecture that supports both Smart Grid and mobile communication is a compelling advantage.
It’s clear that the aggressive evolution and development of the Smart Grid requires the use of open, standards-based technologies. But this is not enough. It also requires the use of protocols and solutions that have been proven to be functional, scalable, secure and of high performance. The use of SIP for Smart Grid device communication provides an opportunity to jump-start Smart Grid deployment while supporting existing standards and architecture evolution. Additionally, SIP brings a robust unified communication capability to the Smart Grid, which no other protocol can provide. This allows the Smart Grid infrastructure to be used to enable a mobile workforce and automate many other business processes, an important addition to the business case for Smart Grid.
Joe DiAdamo is a 25-year veteran of the Telecommunications industry, having held the roles of designer, system architect, VP of engineering and CTO at large multi-national corporations. Joe is currently Chief Technologist, Smart Grid Solutions for Siemens Enterprise Communications.
I'm a big fan of SIP, have been for many, many years. However, the pipes in the smart grid would make early dial up look fat. SIP is rather verbose. How does one account for that aspect?
Michaela Barnes - 06/23/2009 - 17:55
SIP doesn't need to be verbose
Michaela, I have prepared a protocol description showing how SIP for a meter can be implemented. Very limited number of messages required. Please let me know if you would like a copy of the document.
Joe DiAdamo
joe.diadamo.ext@siemens-enterprise.com
Joe DiAdamo - 06/24/2009 - 06:48
I have my doubts
I think you have to have a crystal-clear definiton of the communications requirements before you can get excited about a protocol. I'm not getting a consistent answer even on what the endpoints of the exchange will be. Clearly IP Ethernet is a great base to build on and I have no argument there. As someone who has managed a large SIP based phone network, I would be very worried about forcing SIP on to the SmartGrid. SIP is fat, complex, and unfriendly. I would prefer a much simpler protocol and one that actually allows multiple protocols to share data and interface. I think SIP would be a grave mistake here.
Jeff WIlson - 06/24/2009 - 07:33
Doubts are expected...
Jeff, SIP for telephony and video can indeed be "fat" in order to deal with the complexities of codecs, multi-party scenarios, 3rd-party call control, etc. but none of this is needed for the kind of device communication I see in the Smart Grid.
The protocol description I mentioned above shows how simple it need be for a meter, for example.
I'm not sure I understand your point about a protocol that allows multiple protocols to share data and interface. SIP message bodies can transport any number of MIME types / payloads. Perhaps we can discuss this via e-mail?
Joe DiAdamo - 06/24/2009 - 08:13
Is SIP versatile?
Joe,
I agree that SIP has a number of merits. Are you assuming that all homes have broadband or would it work over the various smart-meter data-gathering mechanisms being deployed by utilities: WiMax, RF, PowerLine communications, Broadband over Powerline, cellular, etc.?
Also, would it support entertainment (such as streaming media) should the home area network begin to take off as the platform for entertainment and other home uses (security, appliance control, etc.)?
Joe Eyre - 06/24/2009 - 10:03
XMPP more suitable
XMPP is another IETF standards-based protocol ideal for P2P communication in the smart grid. Indeed, the Jingle extension for streaming is compatible with SIP.
Whilst initially aimed at IM, XMPP is finding itself in many applications now.
Robert Cragie - 06/24/2009 - 10:43
how about HTTP?
Interesting thoughts, what about this:
why not simple HTTP which has been used to wire up the WWW? Then any resource of interest can be addressed with URIs and data can be encoded using MIME types. It allows the smart grid to become a large RESTful web of resources.
Plus anything used for smart grid, should ideally work well over 6LoWPAN (which requires decent compression, ideally with payloads of < 80 bytes). A compressed version of HTTP with its caching model could work quite well for this.
Brian Frank - 06/24/2009 - 11:00
Why not HTTP?
Brian, SIP provides the needed session management semantics as well as location registration, proxy functions and network border control / traversal. Since SIP borrows much from HTTP, it's just as easy to compress as HTTP.
There are also many extensions to SIP that will benefit the Smart Grid. For example, Location Conveyance for SIP (currently an IETF draft) can be used to convey the geographical position of field devices.
Joe DiAdamo
Joe DiAdamo - 06/24/2009 - 11:44
Requirements first, technology second - Part 1
It appears that the NIST smart grid roadmap effort has kicked off a standards war of sorts and the media is gobbling up the opportunity to cover the front lines and report on these apparent revelations of how the perfect answer has just been offered up on a silver platter. It seems that proponents of specific technologies are all vying to be “the one” when it comes to smart grid communications standard. This is fundamentally a flawed concept – let me explain.
The EPRI IntelliGrid program began an effort to change the way energy industry engineers designed systems and applied technology. Historically, many utility industry engineers would see a nifty new technology at a trade show or one that their favorite vendor showed him, bought it, brought it back to the office, and then tried and figure out what they could do with it. What business applications might they be able to support with this thing? If the application represented a round hole and the technology was a square peg, a bigger hammer to force it to fit would be brought to bear.
EPRI IntelliGrid challenged this insanity. IntelliGrid proposed and refined an approach long used in other industries – a rigorous yet not onerous systems engineering based approach that focused on through requirements development based on application scenarios. Only at the very end of this process would those requirements be analyzed to develop conceptual, then logical, then component architecture. And then after that, map component architecture elements to specific technologies that meet the requirements. Fancy that – actually selecting technologies that meet the business and technical requirements rather than picking up a cool looking widget in your favorite color and then trying to figure out what you can do with it!
The EPRI/NIST team chose to use the more sane approach. We recognized that we have a system of systems engineering problem. There are far too many domains with disparate functional and non-functional requirements for any one technology or standard to be able to address them all. To think otherwise is foolhardy and contrary to a long history of complex systems of systems engineering best practices.
Erich W. Gunther - 06/24/2009 - 13:42
Requirements first, technology second - Part 2
So, when I see a headline such as “SIP: The Clear Choice for Smart Grid Communications” – it makes me cringe with the thought that after all of the hard work we put into IntelliGrid and the GWAC principles that some people still want to promote their favorite standard. Damn those pesky requirements and full speed ahead!
I could probably write several pages of an article on “TCAS: The Clear Choice for Smart Grid Communications” describing how TCAS was simple, has a long history of implementations, is cheap and easy to integrate, and requires little expertise to implement – before anyone realized that I was talking about Tin Cans And String (TCAS) and thought about issues of meeting latency, bandwidth, and reliability requirements.
With regard to SIP itself. It is an interesting technology and has served many of the applications it was originally designed for well. But it hasn’t served all of the applications it was designed for well and some of those flaws make it problematic for many smart grid applications.
The most significant issue with SIP is mentioned in the article but the depth of the problem may not be clear – the problem with firewalls and Network Address Translating (NAT) devices. Inside a single, monolithic addressing environment SIP can work well although its fundamental complexity still has configuration issues that hamper interoperability. If you need to traverse a firewall and/or a NAT device however, you will face a major challenge and no single solution. Just ask anyone who has tried to get a Cisco 79xx VOIP phone operating in SIP mode to work with an Asterisk based PBX in a multi subnet, NATed network. Not fun – I speak from personal experience. Microsoft’s firewall product (Internet Acceleration Server) still doesn’t have native support for SIP.
Erich W. Gunther - 06/24/2009 - 13:43
Requirements first, technology second - Part 3 of 3
SIP itself isn’t the issue however. The issue is the tendency for engineers and technologists who should know better to pick a technology first and then try to fit the applications around it. We cannot build a smarter grid – already the largest and most complex machine ever created – without the application of sound systems of systems engineering principles. EPRI IntelliGrid lead the way, others like DOE Modern Grid Initiative, the GridWise Architecture Council, and NIST have followed and extended those principles. Now it is time for vendors, implementors, system owners and operators to take advantage of these concepts to build a smarter grid that leverages appropriate technologies that meet the business and technical requirements of the applications we must implement in a cost effective and extensible manner.
It would also be time for EPRI to open up the IntelliGrid and its testbench to the rest of the industry, not only to the insiders like your company.
The argument about validity of SIP, XMPP and HTTP (the latter two without the NAT problems you mention) is very valid in my opinion and very applicable to the smart grid.
Thanks though for lecturing us about the beauty of proper system engineering.
Marco Graziano - 06/24/2009 - 14:37
Requirements and system design methodology
Eric, first let me say that I know there is no single silver bullet - the title of the news article was the editor's, not mine.
Regarding requirements, I did in fact do an in-depth study before writing the paper. The many volumes of the IntelliGrid architecture (including the use cases and requirements), the SBC use cases, all the GridWise architecture council documents, the ANSI C12.xx standards and both NIST workshops paint a pretty good picture of the requirements.
I know SIP can play a big part in addressing the requirements for specific domains of the Smart Grid. It's also the only solution that can concurrently provide the needed multimedia functionality for field-force automation, video surveillance, etc. I'm not just pushing my favorite standard.
Regarding NAT, you most likely know that it is an IPv4 issue, not a SIP issue. There are existing solutions for this in SIP: STUN, TLS session reuse to mention two. And there any number of SIP-enabled firewalls and session border controllers on the market.
Eric, with all due respect to the extraordinary work done by the EPRI team, the market and our legislators are moving forward as we speak and aren't waiting for the perfect system design. You just have to look at the continuing proliferation of incompatible AMI solutions for evidence of this.
Thanks ... joe
Joe DiAdamo - 06/24/2009 - 21:16
SIP vs lightweigt solutions
SIP is a heavyweight solution that is not likely to be appropriate here; it's not often carried end-to-end, but translated by the time it reaches interior parts of the network. Something lighter in weight, like a combination of Diffserv, SCTP and IPv6, could provide the complex of mechanisms for control, security and service differentiation needed--while not limiting communication across/through system boundaries.
George Wayne - 06/25/2009 - 10:46
XMPP deserves consideration
The Internet of Things (the likely outcome of the Smart Grid) will most likely opt for XMPP as its common language. Who knows what the Grid side will choose? But, the consumer-owned HAN due to market forces, price and convenience will be dominated by XMPP with some Semantic Web. In a Twitter-influenced world, short bursts of natural language will be the most efficient form of communication between humans as well as machines. If the Grid wants to communicate with people in a scalable yet personal manner, maybe a Grid-Side SIP with Home-Side XMPP makes some sense.
Ishak Kang - 06/26/2009 - 07:29
SIP vs JXTA / SIP Vulnerabilites
Another protocol with strong location tracking capabilties is JXTA. It is also mature, extensible, and has been increasingly used in military communications architectures to handle Size, Weight and Power (SWAP) constraints.
SIP is a viable protocol, but it does have some recently identified vulnerabilities, primarily a vulnerability that allows legitimate requests to be amplified causing distributed denial of service attacks.
Bruce Rosenthal - 06/26/2009 - 07:48
SIP/NAT/IPV6
Hello All
Interesting topic. By way of full disclosure I work for Siemens Enterprise as well. My comment has to do mainly with the questions around NAT. It would seem to me that a capability such as ICE-Lite or ICE would be a suitable answer for that NATTING issue. THere are also some IETF specs out there for peering across multiple domains. As for the example of a Cisco device trying to NAT through a firewall, I have to say this is a straight forward proposition with a session border controller today. I would also play the other side of the coin in this discussion. Whenever a new project/initiative comes out why is it we think we have to reinvent the wheel. Im sure SIP isnt perfect for smartgrid but its certainly has many atrributes that are favorable and can be adapted to the grid. Great discussion for the most part.
Paul McMillan - 06/27/2009 - 21:33
I don't like the VOIP baggage
The VOIP baggage that comes with SIP is an issue for me. Please take a look at this posting on my blog:
http://visiblenergy.wordpress.com/2009/06/28/108/
Marco Graziano - 06/28/2009 - 20:06
IntelliGrid Document Availability
In response to Marco's comment
"It would also be time for EPRI to open up the IntelliGrid and its testbench to the rest of the industry, not only to the insiders like your company."
All IntelliGrid Architecture work products have always been avaialble freely in the public domain during their original development and to this day. The full suite of reports mentioned by Joe, use cases, and other collateral can be downloaded from multiple sites. Check out http://www.intelligrid.info/ and http://intelligrid.epri.com/technical_results.html
Individual implementations of IntelliGrid and roadmaps for specific utilities are the only items that have been kept private within those specific utilities.
I love finding opportunities to lecture on proper systems engineering!
Erich
Erich W. Gunther - 06/29/2009 - 07:32
Requirements and system design methodology
Joe,
Thanks again for your thought provoking piece. As I note in my response, I am simply very sensitive to promoting a single specific technology (including a protocol) for an entire domain without considering the application specific requirements. I have seen our industry make that mistake before and we can't afford to do it again.
We also cannot let expediency and political drivers interfere with a sound engineering solution to smart grid application integration and interoperability.
If we had a universal IPV6 infrastructure, and we didn't have those pesky legacy systems, and if we didn't have requiremetns where IPV4 or IPV6 can't be used due to specific application requirements, then SIP would have a lot more application possibilities. However that situation does not exist. We have legacy, we have NAT, we have situations where routed IP just can't be used. There are in fact other solutions available that are standards based and that can be interoperable with the IP protocol suite and other protocols with the appropriate definition of implementaiton profiles as recommended by the interim NIST roadmap.
IMHO!
Erich
Erich W. Gunther - 06/29/2009 - 07:41
Marco's blog ...
Marco, I get "404 Not Found" when trying to open the URL you listed.
... joe
Joe DiAdamo - 06/30/2009 - 15:11
NIST Interim roadmap
Erich, I don't quite understand your point about NAT and IPv4. Yes, it would be much better if we could implement the new Smart Grid networks without IPv4, but there is no technical barrier to supporting both IPv4 and IPv6 in the short term.
Providing a bridge from existing (legacy) systems to the new Smart Grid networks will be required regardless of the technology and protocol selected. That is, it is not an issue specific to IP or SIP.
I know that the use of IP for the Smart Grid is still open for discussion. If IP *is* approved by NIST for the Smart Grid, I think it makes a lot of sense to use application protocols that exploit it, rather than tolerate it. For example, I know C12.22 can be used with IP, but it doesn't exploit naming, routing, traversal of domains, etc.
Thanks in return to you for your insight and comments.
... joe
Joe DiAdamo - 06/30/2009 - 15:30
SIP and XMPP
I agree with previous posters that SIP and XMPP are both mature and open messaging protocols. Both are fine for broadband applications. In the domain I am familiar, residential applications and AMI networks, neither of these are appropriate since they are heavy weight and verbose text/XML based protocols.
Alan Keister - 07/01/2009 - 08:00
What is troubling about the NIST effort
Is its not been open to the larger Internet Community in order to test its principals specifically security. SIP could be interesting since it is still a Session INITIATION protocol etc. There is a good argument about XMPP as well.
Richard Shockey Board of Directors SIPforum
Richard Shockey - 07/01/2009 - 12:32
Solution ?
Mr. Gunther,
When do you think you and others at:
Chairman and CTO, EnerNex Corporation,IntelliGrid Team member,GridWise Architecture Council member,
EPRI/NIST Roadmap team member, et al ...
will have a proposed solution. 1 year, 2 years 5 years, ...?
With economies of scale, it would seem some of these problems could be solved with current technologies (instead of inventing something) and use gateways or "bridges" where necessary to interface an older technology that cannot be upgraded (legacy) to a newer infrastructure (IP6, SIP, etc...)? I don't claim to be an expert, just looking for tbe best solution that we can implement in the near term.
We're getting mixed signals about the vitality of the smart grid market. On the one hand, the recent DistribuTECH conference was one of the most successful ever. On the other, a well-known Wall Street analyst recently told his clients that the smart metering sector is "facing several headwinds," including weak regulatory support in the U.S. and delays in European adoption. Taking the pulse of the smart grid industry is this week's Tuesday Topic.
Twitter
Facebook
Linkedin
RSS
