Smart Meters and IP – an Inconvenient Truth

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”.