Wireless M-Bus: Part 1, an overview

When one hears: Smart Meter, the picture that immediately comes to mind is an electricity meter which can measure the energy consumption of a household, where there optionally are installed PVs at the roof. Somewhere between electricity meters, and sensors (in the broad term) in a sensor network, we have a device that is typically overseen in the smart metering context: a Water Meter. One of the reasons why we do not see these devices as anything even close to smart is because they, in general, are not “smart”.

In the recent years, things have changed a lot though. The meters are being extended with wireless capabilities, either in the form of a module attached directly on top of a plain old meter, “reading” the display and relay its values, or inherently build into the meter itself, as for the Kamstrup Multical 21. Also larger cities are buying into this type of technology. This mainly to cut labor cost, but also for the more advanced meters, to get more fine grained insight into the installation state with leak alarms, etc. One example is New York City [1].

 

But what language do these devices speak? At least in EU, the answer is: Wireless M-Bus, a wireless extension of the original M-Bus protocol developed back in the nineties. Wireless M-Bus is specifically designed for battery powered meters. This is seen in the lifetime for these devices: The Multical 21 for example guarantees 16 years, with a broadcast transmission every 16 seconds [2]. That is a total of 1.973.062 transmissions – impressive. No matter how low-power Bluetooth, LTE, Zig-Bee, or any other more general protocol ever becomes, they will hardly be able to beat these numbers. The protocol is not specifically designed for water meters, and other (mainly battery powered) product types within metering also uses the protocol, for example gas meters, or even district heating meters.

Wireless M-Bus is a three-layered protocol: PHL, DLL and APL, and these layers will be analyzed separately in future posts, so stay tuned.

[1] http://cityroom.blogs.nytimes.com/2009/03/24/city-turns-to-wireless-for-water-bills/

[2] http://multical21.com

ETSI M2M Workshop 2012: Day 2 Sony Keynote Highlights

We would like to briefly summarize the keynote given by Sony Limited Europe about Low Cost LTE Devices. The objective of Sony regarding M2M is to integrate in most of their devices some sort of M2M communication technology in the near future. Moreover they want to use the same technology to cover all kind of devices from TVs, cameras, videogame consoles, etc. However this suppose a great challenge due to the wide range of requirements for each of the applications in terms of delay, power and data rates. The question made by the presenter was:

“Is there any technology that encompasses all the varying M2M requirements?”

Nowadays we have a large variety of wireless technologies that could be used such as, ZigBee WiFi, GPRS, LTE, etc.

According to Sony point of view the LTE should be the one. Without going into detail, the overall idea is to develop a LTE Low cost device (approx. 10$ per module) that could be easily integrated in most of the their products.  Sony is not alone in the field of Low cost LTE device, in fact there is a on-going study in 3GPP since September 2011.

How to decrease the cost of LTE?

The main approaches are:

  • Reduction of the bandwidth
  • Hardware simplification
  • Reduction of TX power
  • Reduction of the peak rate

A 59% of cost reduction is expected from these simplifications.

However, the chip development of such Low cost LTE will not take place in the short-term, but in the year 2017.

One of the questions made in regards to this presentation was about using GSM/GPRS technology, which is currently available. According to Sony point of view, GSM may disappear and therefore the longevity of the solutions cannot be guaranteed.

In another post we will try to cover the one million dollar question: which technology will be available ten years or more from the current cellular networks GSM/GPRS, 3G(UMTS) or LTE?