There seems to be great concern about battery life in these meters. In the case of electric meters, why not just harvest the relatively miniscule amount of energy required from the power being metered? The old fashioned disk type meters do just this to mechanically advance the gear train. For water or gas metering, a somewhat different energy harvester could be designed. Perhaps a turbine or positive displacement meter can do both the metering and energy extraction. However, this would not allow completely shutting off service for an extended time as the harvester would have no way to replenish it's energy source while flow is zero.
@boblespam wrote "400 and 900 MHz ISM bands are not international."
it's interesting you say that - the particular competitor to the SE2 based meters I'm thinking of is (originally) European and uses an "open standard" in both 400/900 bands (so, maybe not ISM as such, but I was pretty sure 433 was available in Europe).
Incidentally, these units *just* cope in less dense housing situations as are found in places like North America.
My point was that the propagation of 2.4GHz Zigbee doesn't meet the requirements of the job; I know for sure there are a couple of devices that do Zigbee protocol on 900MHz bands (ie: only difference is the radio)
I realise this is a "branding" issue for Zigbee group - how do you make devices labelled "Zigbee" and differentiate between radios; not my problem.
All I'm saying is that it doesn't meet the requirements in the field for this task, and that successfully doing so would mean a market of what, several hundred million units?
(oh, and as a bonus, 900 or 400 would, afiak, mean less tx power and perhaps fewer retries so better battery performance)
The adaptation of TCP/IP is a good news. It is very important that smart meter consume less energy otherwise it wouldn't make too much sense. I don't quite believe TCP will consume significant more energy than UDP unless the smart meter has to listen to a TCP port consistently. Even so, energy use in listening to a UDP port and a TCP port shall not be much difference. The reliability of TCP will require the smart meter to send more bits than UDP. The chance of consuming more energy. To my experience, it shall never be significant though.
Adaptation of IP no doubt poses security challenges. Does anyone have further information w.r.t. security works done by NIST?
@Sanjib the exact reduction in transmitter power required is not easy to calculate, but if you look at a diagram for a TCP "conversation" you will see that it is dependant on data length, errors and timing. The UDP version (I haven't seen the revisions to SE2) could at a minimum issue a single packet in a given time window once or twice a day.
As I mentioned, there is "plenty of time" to get any given meters data out, since a week of readings is a trivial amount of memory these days. The utility side software that I have seen has the ability to "catch up" on a meter that has been unavailable for a while.
Either way, the 15 years thing is all a projection from power consumption and battery life estimates. It assumes lots of things that may not actually be achievable in the real world.
The 15 years number also does not take into account "home displays" that directly query the meter (which will, IMHO, never work for battery-only gas or water meters).
Thank you and Rick for addressing my questions! From the 2nd sentence of the 2nd para of this article, I understand 15 years battery life could not be achieved with TCP and hence there is a requirement to change to UDP. Is it because UDP is less detailed than TCP. Could you please provide any numerical example to illustrate (20%/30% etc.)?
The smart energy profile is also intended for water and gas utilities - hence the requirement for battery power (ie: not usual and possibly illegal to have mains connection, cabinets and other installation requirements make alternatives such as a solar panel difficult).
The usual operational life of a meter in a domestic or small business situation is 12 years (+/-); hence the 10-15 year battery requirement.
TCP is implemented using UDP; and UDP datagrams in themselves are checksummed. UDP is far less "chatty" than TCP. Guarantee of delivery (where TCP comes in) is not necessarily a requirement when the transmission can be retried periodically; provided there is no loss of data these systems are tolerant of a few hours of delay (ie: monthly or quarterly billing cycles).
@kinnar Zigbee has several provisions for encryption etc (it's effectively IPv6). That's not to say the system is totally secure (none is).
Although I am a fan of Zigbee, I really do think that they should also have a look at officially adopting support for Zigbee on 400 and 900 MHz ISM bands; 2.4GHz is really inadequate for metering... the currently deployed commercial alternatives use a blend of 400/900MHz and are successful in places a 2.4GHz solution would not work.
@Sanjib. I was told the requirement for some meters (a small subset of the smart meter group) is they can run 10-15 years on a battery, but I do not have more details. As for the software stack, the specifics of the stack were much more detailed than TCP and UDP, but at a high level that as one of the distinguishing features. I was told the UDP version allowed for less frequesnt updates or listening to the net and thus a less demanding battery workload.
@Rick, I've a couple of questions, might sound silly. Why is the requirement that the smart meters shall have 15 years battery life? Why not 10 or less?
Secondly, what is causing the TCP protocol being less energy efficient compared to UDP?
I believe data integrity is more reliable for TCP compared to UDP which, I think, should have higher priority compared to higher battery life.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.