This is the second part of the writeup on the Bluetooth Low Energy event and should get into the meat and bones of the spec. I dropped the timestamps since I think they don’t mean that much after a certain point. I'm also holding off on the pictures, mostly because I'm too lazy to upload them. Sorry, but it's going to be a text fest.

Consumer Health
Tsutomu Miyoshi, Tanita

After the Casio presentation, Tsutomu Miyoshi started discussing Bluetooth Low Energy’s application to consumer health devices. You probably haven’t heard of Tanita too much if you’re not from Japan. Japan has, in my opinion, some of the world’s most sophisticated body scales (as well as toilet seats). If you want to know where the innovation from this country goes, I suspect a good deal of it ends up here. That being said, Tanita is one of the main manufacturers of consumer scales in Japan.
He started off by discussing Tanita’s move to consumer scales that connect to an online website where people can share their body weight, fat percentage, and loads of other things that I’d probably not want to know much about. There are two methods of transferring the data to a PC or gateway (yes, there’s a body scale gateway available through NTT): infrared and RF. The infrared is the cheapest method to use, and although the data rate is low, it is good for both battery life and cost. The problem is that it requires a line of sight connection.

The RF uses a 400 MHz low power radio and sends the data to a router provided by NTT for the Hikari (light) diet system. Once the data is uploaded, you can share it with others within your social groups, or diet groups I guess, and do other social things that you’d do with that kind of information. The site is also used to organize group walking events and each individual user can track the amount of steps taken, calories burned, and before and after weight.

He then went on to discuss how BLE can improve on the existing products and systems that Tanita is producing. The interoperability would allow other manufacturers to add to the Tanita health ecosystem. Then, he went into his grand plan which really freaked me out.

In Japan, there is currently a movement by the government to eradicate obesity due to the costs to the public insurance system. Before I continue, here’s some background info. In Japan, employees and students, or anyone under the public health insurance plan is required to take a physical checkup once a year. The idea that was proposed by the government was that if the doctor giving the physical determined that you were obese, they will insist that you meet with a nutrition advisor. The advisor will recommend a diet plan and equipment to monitor your weight, body fat, fitness, and progress. The data would be uploaded to a centralized database via the internet and the advisor will be automatically alerted if there are any problems with the diet plan. I can only assume that that phrase means that you’re not losing any weight. In the US, I’d be able to hear the privacy groups sharpening their legal axes, but for some reason, in Japan, I don’t think there is any opposition to this. Tanita’s proposal was that using Bluetooth Low Energy would facilitate the communication between the health monitoring devices and the centralized database via the phone or a BLE router.

I think that I now realize why some people are concerned about wireless sensor networks and privacy. It wasn’t exactly the best example he could have used to put BLE in a positive light, however there is a cultural difference in how Japanese people think vs Western cultures (ie: US, Europe) so I don’t think it struck him as invasive and horrifying.

Aside from that, he then went into details of what he wanted to see out of BLE:

  •    A very low cost single-mode RF chip
  •    Power consumption that would allow operation on a coin cell for long periods of time
  •    Usability issues addressed such as easy pairing between devices


BLE Technical Overview
Robin Heydon, Cambridge Silicon Radio

I had expected this guy to come out with horns and fangs, since he’s such a Zigbee and 802.15.4 basher. He was the one behind the blog I pointed out a few weeks ago that bashed both protocols, while he kept himself anonymous. I removed his name from that post because I didn’t want it to get picked up by the search engines (also the reason I’m not mentioning the blog name…you’d be surprised how efficient the Google bots are).

Well, other than looking like the comic book store guy from the Simpsons, he was a soft spoken man that was very passionate about his work with BLE. I must say that my image of him changed after watching him talk, however I still think its cowardly to bash other protocols anonymously.

His presentation, however was probably the most interesting out of all the other ones because he was one of the people that was getting his hands dirty in it. He’s writing the spec for BLE and addressed a lot of the differences between Bluetooth and BLE. Here is my quick one-minute summary:

  • BLE uses GMSK modulation instead of GFSK for Bluetooth with a modulation index of 0.5.
  • BLE only uses 40 channels as opposed to a much larger number of channels for Bluetooth. 37 data channels are for adaptive frequency hopping (AFH) and three channels are used for advertising and discovery.
  • Link layer has four states: scanning, advertising, initiating, and connected
  • BLE now only has one fixed packet structure with two types of packets: advertising and data. FYI, this is similar to 802.15.4 with command and data frame types, but 802.15.4 also uses two extra types: beacon and ACK.
  • BLE has a feature called a “lazy ACK” where the ACK arrives within the next data frame. I’m not sure how they would handle ACKs if only one frame was transmitted though since they only have two frame types.
  • BLE has simplified link messages: 8 link layer control messages vs 75 messages for normal Bluetooth
  • Application level protocols only use attributes. Bluetooth uses 9 different protocols to implement different device functionality.
  • Security management handled by the host. The slave can receive a long term key from the host along with a diversifier. The actual key is made by combining the long term key with the diversifier. Don’t ask me about any more details than that.
  • AES-128 is used for security and to derive the long term key for the slave.
Okay, so that was most of the protocol stack up to the application layer in a nutshell. I wanted to save the discussion of the application layer as a separate topic because I found it quite interesting.

The application layer uses a concept called attributes which is a generic data structure. Each attribute has a:

  • Unique attribute handle to identify itself
  • A data type field to identify the type of data
  • Access parameter, ie: read/write/set/discover

Also, attributes with similar functionality can be grouped together into services and profiles.

For those that are familiar with Zigbee, this sounds very similar to the Zigbee Cluster Library. Each cluster in the library is composed of attributes which have an attribute ID, a data type identifier, access parameter, and of course the actual data. Similar attributes are grouped into clusters and these clusters are re-used in the Zigbee Cluster Library among the different device profiles.

I think it’s not a coincidence that many protocols are realizing the need for something similar to generic attributes and groupings to standardize device behavior. To be honest, I hated the concept of the ZCL when I first encountered it and tried to understand how to implement it. However I can see now that it’s probably one of the best features that Zigbee has to offer and I think that’s why we seem to be seeing a lot of other protocols that are adopting a similar approach.

I think that’s about it for the BLE technical presentation. I can’t remember too much more than that, which may mean that it was too technical to sink deep into my head.

Enabling Innovation
Karl Tormark, Texas Instruments

This guy talked about Bluetooth Low Energy being used for refrigerator magnets. I automatically tuned him out.

Making Internet Connected Products Easy
Nick Hunn, WiFore

This was the last presentation I attended. I was already suffering from Powerpoint fatigue, but made it to the technical info which was really what I was after. To be honest, Nick Hunn scares me more than Robin Heydon who gave the technical presentation. Robert Heydon is basically a geek with an opinion, something that I completely understand. Nick Hunn is something completely different.

On his blog, he bills himself as a wireless evangelist and is also part of the Bluetooth Low Energy Evangelisation (shouldn’t that be with an ‘z’?) Working Group . That is just totally, fucking weird. Hearing him give his presentation, I can see that he’s a nice guy, soft-spoken, etc…but the scary thing is that he’s a technology optimist.

If you’ve been in the industry for a while, and are somehow involved with actual implementation, then you’re most likely a technology pessimist or a skeptic. That means that when I hear people making pie in the sky assessments about Zigbee like they’re going to sell a zillion 802.15.4 radios and Zigbee will take over the world by the end of the year, I just roll my eyes and continue to work.

Technology optimists are the guys in Silicon Valley or some other tech hub that believes that the next big thing will be location aware social networking where you can leave online messages at a café so your friends going there later will know that you’ve been there. You might as well just pee in the corner instead.

Anyways, his presentation was about internet enabling your products and he started off his presentation with a slide on the definition of an internet connected product…that’s when he hit everyone with the words: “Consumer Electronics 2.0”. He then continued on about how Bluetooth Low Energy will enable devices to communicate with phones while throwing out multi-bonus Scrabble buzzwords like "revolutionary as opposed to evolutionary" and "disruptive innovation". The phones will support BLE Gateway functionality which provides a pipe to the internet. Middleware would then be able to access the device directly (via the phone). The data collected from the devices will be uploaded to some web application via a web service. All this will be provided by Bluetooth Low Energy. “Any gateway will be able to work with any device”.

Yowzah…that’s the kind of talk that makes me cringe. You should avoid anyone that tells you stuff like that for any technology. He just spanned something like a half decade of spec development, multi-million dollar research and development, and probably a couple of thousand man-months of coding with a wave of his hands. Is it possible? Sure. Is it possible within five years? Hmmm….

Conclusion
Well, my venture out into the world of BLE was quite interesting and informative. I wanted to check it out firsthand because there’s so much shit-slinging between the different protocol camps including Zigbee. Since I cover news on all different WSN topics, I’m naturally curious about the reality of the strengths and weaknesses of any protocol. There’s no one protocol that can cover everything.

My final conclusion is that Bluetooth Low Energy is a spec that is being developed to extend the functionality of mobile phones. They aren’t looking at real wireless sensor networking, in the vein of multi-hop systems and monitoring and control applications. Instead, they seem to be trying to connect different peripherals to phones, with a bizarre emphasis on watches. In my opinion, they’re trying to be the USB of a mobile phone, where you have an easy interface that provides access to the wealth of functions that a mobile phone can perform. Since mobile phones are becoming like mini-computers that everyone carries with them, this is probably a good choice from a commercial perspective. Many new devices can be created to connect with a phone and the market is already there. However it’s most likely going to enable a new generation of gimmicky gadgets geared towards yuppies and techno-freaks.

From a WSN point of view, I think a big weakness is that the mobile phone plays such a dominant role. Many important WSN applications won’t be in the proximity of a mobile phone and will most likely be autonomous, just collecting data or with someone remotely controlling valves and switches. This might have the unintended effect of relegating BLE into a single-hop universal gateway interface to a phone rather than a serious wireless sensor networking protocol.

One of the big issues I had was that the Bluetooth profiles won't work with BLE. This means that all the work that went into the Bluetooth Health Device profile won't be able to be carried over to BLE. This was a major disappointment and I need to retract my old blog post about BLE and Continua. I don't think the BLE spec is ready for medical devices and I think that it's going to be a quite some time before they can have a real spec dedicated to them. 

Updated 2009-04-21: Just got an email saying that the BLE presentations were uploaded. I'm not sure if you need to register to view them, but they can be found here .

You have no rights to post comments