Smart Meters and IP – an Inconvenient Truth
- in Smart Energy
Around a hundred years ago, George Bernard Shaw quipped that England and America were two countries divided by a common language. Today there is a similar, very evident gulf growing between them in their attitude to smart metering standards. That gulf is increasingly becoming an ideological one, with the difference focussing on whether to take IP to the meter. It’s a difference of opinion that has little to do with those involved in metering or even the grid itself, but by others who want to impose their vision and their technologies upon its future.
The whole concept of bringing Internet Protocol to battery powered devices in this new era of the Internet of Things is not confined to smart metering – it’s a question that is being wrestled with by many standards groups who are trying to balance issues of accessibility, interoperability and power consumption. In general, the closer a product is to commercial deployment, the less sway the IP proponents have. But they have the US power industry in their sights.
I don’t believe that their arguments add up. If smart metering is to work it needs to look at the whole picture and make pragmatic decisions. The UK approach seems far more sensible, which may be why it’s making far better progress. In contrast, there’s a distinct feeling of banana skin about the IP advocates and their promotion of ZigBee Smart Energy Profile 2.0. As time goes on it looks like an approach that is having to conceal more and more inconvenient truths behind a veil of smoke and mirrors.
The argument has nothing to do with the potential benefits of smart metering (albeit they still need to be proven), or the basics of ZigBee’s Smart Energy Profile. Most in the industry would agree that they are the only way to go for smart metering at the moment. The question is how to address smart meters and individual devices that are connected to it over the Home Area Network? There are two schools of thought. Those using Version 1.0 of the Smart Energy Profile typically connect to meters via a gateway device which is located on the Internet. This means that the gateway has an IP address, so that it can be found by other internet devices. The smart meter and other devices in the home don’t have their own individual IP addresses. Instead they can be accessed via the gateway, which knows what they are, and can direct messages to them. That’s the same way most people are accessed. The gateway is like our home or office, which has a unique address, and we have our individual names so that we can be located at these addresses. The important point to recognise is that our names aren’t normally unique.
The IP advocates claim that this is not good enough and that every device should have its own individual, unique 128 bit IPv6 address. (Intriguingly, I don’t know any of these advocates who have changed their personal names to a unique 128 bit address, so their IP preaching has a slight ring of “don’t do as I do, do as I say”.)
On the surface this makes some kind of sense. But when you start looking at what needs to be done to make a truly low power wireless device that logic starts to peel away.
When you design a battery powered wireless product you put a lot of thought into how to make the battery last as long as possible, especially if needs to have an extended battery life. There are a number of techniques to achieve this. You want the device to stay asleep, consuming minimal power for as much of its life as possible. When it does wake up to send something you want it to be awake and powering the radio for as short a time as possible, and to be able to go back to sleep again as quickly as possible. It doesn’t matter what wireless standard you’re using – these are universal principles.
To minimise the time they are on, low power wireless protocols are designed to use very short packets of information, which can be sent very quickly. ZigBee has a maximum packet size of 127 bytes. Bluetooth low energy is even more frugal at just 47. Each packet needs to contain a destination and source address, which is a necessary overhead for any wireless protocol. With IPv6 (which is what the IP lobby wants to use to accommodate all of the anticipated devices), that takes up a minimum of 32 bytes. In many cases it takes double that. In contrast the data being sent in the same packet usually requires only a few bytes. Which means supporting an IP address on these devices may increase the packet length by an order of magnitude.
A useful analogy is to look at packing in the supermarket. An efficient radio protocol is like a banana – it comes ready packaged. If we were just to add an old IPv4 address it would be like wrapping it in cellophane. IPv6 adds a presentation box, a bow and a carrier bag to take it home in. In the eyes of a low power designer, it’s the wireless equivalent of landfill.
Everybody who works with IP it knows it’s bloated. That’s not a problem for products that use cables and have power supplies, but it’s anathema for low power wireless devices. Recognition of the bloat is why we have 6LoWPAN, which is an attempt to shave the problem down from supersized to merely clinically obese. But it’s still too big. Yet this is what the ZigBee SEP 2.0 proponents are clamouring for.
It’s not the only problem with taking IP to a low power wireless device. The TCP or UDP protocols above it are not designed for link layer acknowledgments. As I indicated above, efficient low power wireless devices want to transmit the minimum amount of data as quickly as possible and then go back to sleep. But most want an acknowledgement that the data was received before they go back to sleep. That’s most efficient when it can happen low down in the protocol stack, which is what happens with well designed radio protocols. Add TCP or UDP and the acknowledgments happen higher up the stack, which means the radio has to stay awake longer before it gets the acknowledgment back and can turn off. This highlights the major difference between radio protocol designers and the IP protagonists. Efficient radio protocols are designed from the bottom up. In contrast the IP zealots are trying to impose their view from the top down. And that doesn’t lead to an efficient radio.
Which brings us back to the UK – US divide. Both countries started with the same Zigbee SEP 1.0 standard. In the US, NIST, who became involved in the smart energy standards, decreed that IPv6 must be supported by every device, so the whole industry upped stumps and started developing SEP 2.0, which will include 6LoWPAN. In contrast the UK evolved the standard to SEP 1.1. Having completed that, they’re moving on to enhance it with SEP 1.2. And there’s already talk of an SEP 1.3. Most of Europe is following the UK lead – it’s pragmatic and it’s working. The industry is working to add features to the 1.x SEP standards that are relevant to the evolution of smart metering, not engaging in an orgy of technical masturbation.
While the SEP 1.x activity is moving steadily forwards, the SEP 2.0 efforts continue to slip. Despite the issues, the believers are still worshipping their sandals and gourds and brandishing the scourges to drive their followers faster. In a move reminiscent of Napoleon in George Orwell’s Animal Farm, NIST recently published an edict for the loyal congregation to work harder to finish the great task before them. It is frighteningly evangelical in its approach. And in pushing its vision, it’s promoting another rather inconvenient truth. Which is that the route between the two visions may be illusory.
The fact that is rarely spoken is that an SEP 1.x device cannot talk to an SEP 2.0 device. That’s because of the simple reason that they use different networking layers. One uses IP and the other does not. That worried many utilities who wanted to start their deployments with SEP 1.0, as SEP 2.0 is still a fair way out into the future. They didn’t want to install meters which would end up as stranded assets. So in SEP 1.1, the ZigBee Alliance added an “Over The Air” Upgrade cluster. This allows new firmware to be propagated down through a mesh of SEP 1.1 or higher devices, which, once installed will upgrade themselves to support SEP 2.0. (I personally think there are some interesting topological inconsistencies with this theory, but that’s another story.)
What we’re now seeing is that the SEP 2.0 firmware is growing. It looks as if it is growing to such a size that most of the chips in current 1.0 and 1.1 devices will not have the resources to store and run the new 2.0 firmware that they receive. So the industry is selling a story and convincing itself of the efficacy of an upgrade that is unlikely to work. We don’t yet know the extent of that problem, but it probably means that many utilities that had planned to migrate from 1.1 to 2.0 may discover that their only option, once they have installed a 1.1 meter is to upgrade it and all of the associated devices around it, to 1.x.
The bigger stack also means that we’ll need more processor power and more memory, so implementations will be more expensive. And reports are starting to come in that, with the bigger stack, power consumption in early test devices is significantly higher than had been forecast and a lot more than SEP 1.x. That’s a major concern for battery powered devices like IHDs and gas meters, as they may not be able to support SEP 2.0. For consumers it means they’ll either have to waste power by plugging their IHD into the mains, or work their way through a mountain of batteries, neither of which are very true to the spirit of saving energy.
The main reason that the UK has not gone down this route is because it’s included the energy industry in making the important decisions about the technology. In the US, the industry has been led by technology startups and standards bodies, who have other agendas. Some of them are already exhibiting their normal attention span deficit and suggesting we need a Smart Energy Profile 2.1, which uses CoAP on top of 6LoWPAN. That’s moving the protocol goalposts rather than refining the features, and has the potential to add another chapter of confusion and interoperability issues.
It places the US smart metering community in an “Alice through the Looking Glass” world of always waiting for jam tomorrow. With stimulus finding dwindling and VC interest waning, there’s a good argument that it would make better sense to step back and consider what it really wants? To follow the pragmatic approach from the UK, or continue living on promises?
A week after writing this, there was a vote within the ZigBee Alliance which appears to show that I am not alone in having these doubts. This is covered by Rick Merritt of EE Times in his report that “Vote delays smart grid software”.
Zigbee SEP 1.1 uses Elliptical Curve Sect163k1 which is 163 bit and provides 80 bit security.
According NIST – SP 800-57, Minimum security strength should be 112 bit after 2011.
As per NIST guideline,
2007-2010 : 80 Bit
2011-2030 : 112 Bit
>2030: 128 bit
SEP 2.0 fulfils this requirement as it uses NIST P-256 ECC prime curve
Ok then I would suggest the following way to do it:
– Meters work on very low power protocols
– One adds an aggregator that is plugged to electricity that does all the IP staff
o The aggregator could be just the energy meter that has anyway access to electricity
Problem solved… Other country disputes where I can be of assistance?
>> It could be hardwired blurt out a single UDP packet and do nothing else.
>Do you think this could be done in a secure manner?
I know security is a high concern for SE 2.0 and the SmartGrid in general.
Yes, but you would need to load an encryption key into the device. Loading these keys is the complication that leads to a lot of expense. How much time and effort are you willing to spend to protect the output of a temperature sensor?
> It could be hardwired blurt out a single UDP packet and do nothing else.
Do you think this could be done in a secure manner?
I know security is a high concern for SE 2.0 and the SmartGrid in general.
TCP and UDP are unaware of link level ACKs so it is perfectly fine for a link to do them. They were used quite commonly in the early days of TCP and analog modems. Battery devices should blurt out a UDP packet and get a link level ACK. The status of these devices can be tracked by a proxy if you choose.
I don’t know what SEP 2.0 says about this, but a basic battery power device does not need a full 6lowpan stack. It could be hardwired blurt out a single UDP packet and do nothing else.
The network protocol war has been fought and TCP won. It has been consuming other networking protocols for over 40 years and shows no signs of stopping. Protocol gateways are never reliable and they get designed out.
SEP2.0 could be deployed on IPv4 but why? Asia ran out of IPv4 addresses yesterday. The switch from IPv4 to IPv6 is being caused by forces that have nothing to do with smart energy. The switch is going to happen and there is no point in fighting it. It will probably be a bumpy ride but embrace it and get used to your IPv6 future.
If Enocean devices are going to participate in the network you’re pretty much forced to have a gateway for them. The means you pick up the problems associated with gateways.
My biggest wish is that the Zigbee people would remove licensing restrictions on the technical standards preventing them from being freely used. They could instead assert control by licensing use of the trademark/logo like the Wifi and Bluetooth people do. Note that there is support for Wifi and Bluetooth in the Linux kernel and there is none for Zigbee. Wouldn’t cheap Linux based Wifi routers with 802.15.4 radios in them be useful? Restricting the technical documents is a great way to prevent wide spread code sharing.
This is another one of the misconceptions that the industry has been sold. It is possible to make little radios that harvest power from the environment. EnOcean is a good example of a company that is already doing that very succesfully. However, it becomes critical that the protocol is optimised so that the radio can stay asleep for most of its life. Today’s basic ZigBee radios can just about manage to run off scavenged power. Adding SEP 1.x and the underlying ZigBee PRO stack puts a lot more burden on them, but it might still be possible if we optimise them. Adding SEP 2.0 is the straw that breaks the camel’s back. All of the IP protocol stack, plus the increased time the radio needs to be awake means it won’t happen.
One reason this isn’t noticed is that today most of the focus is on electricity meters and gateways, both of which have power available. The problem is in the future with gas and water meters and all of the displays and sensors that we might want around the home. For these devices, SEP2.0 means a lifetime of changing batteries, which is a lousy way of engaging customers and getting them to use them.
If these little radios would just inductively energy harvest from the very power line (or water line, with a turbine) they meter this would not be an issue.
Which does not sound like good news for any batteries in those devices. But it’s very good news for battery manufacturers. Buy lithium…
And over the HTTP/TCP/IPv6/6LoWPAN/802.15.4 layers, I think SE2.1 will send XML (hopefully compressed):