Design Article
Comment
electronix79
electronix79
It is obvious that AES is not used for Authentication, but in the created ...
Bluetooth low energy and proprietary RF for HID applications—A comparison
Anitha TG, Cypress Semiconductors
1/5/2012 1:45 PM EST
With the increasing variety of wireless technologies available, more sophisticated human interface devices (HID) are coming to market with integrated wireless technology (wireless keyboards, wireless mice, etc). While wireless standards provide the benefit of interoperability, they also introduce complexity and overhead that an application may not require, resulting in a higher system cost. On the other hand, proprietary protocols give developers flexibility to customize applications at the expense of requiring developers to take on the development process. This article compares the Bluetooth Low Energy technology with the proprietary protocols in the HID market.
The key RF requirements for selecting a PC HID are cost, power consumption, reliability/security, speed/throughput, and ease-of-design. In general, standards win in the market over proprietary implementations because of interoperability between devices. However, in case of PC HIDs until 2009, only proprietary protocols have dominated the market. This can be attributed to the lack of any wireless standard optimized for the PC HID market in terms of cost, power, and efficiency.
Enter Bluetooth Low Energy, aimed at low power applications and the PC HID market. Both Basic Rate (BR) and Low Energy (LE) Bluetooth support device discovery, connection establishment, and connection mechanisms. Bluetooth LE also includes features designed to enable products that require lower current consumption, lower complexity, and lower cost than BR.
Cost
The wireless HID market is extremely cost-sensitive, and the MCU serving as the RF baseband controller needs to have enough Flash to hold the wireless protocol stack. As Bluetooth LE is a standard, stack code size is far greater than for proprietary protocols, thereby requiring more Flash and increasing cost. The wireless HID market has been dominated by proprietary protocols because of their light-weight protocol stacks.
Proprietary networks, however, require an external bridge to be connected to the PC/Host so that they can talk to the other devices in the network. As Bluetooth is in most of the PCs and mobile phones, these devices will have an integrated Bluetooth bridge with dual mode support (BR and LE) in the future which eliminates the need for an external bridge.
Power Consumption
Unlike Basic Rate Bluetooth, Bluetooth LE is an “always-off” technology and specifies that an application should not consume more than 20mA of peak current and 15mA in coin cell applications for a maximum of 3 ms data transfer. This allows small devices like watches and sports sensors to achieve years of battery life through the use of small coin-cell batteries. Dual-mode implementations supporting Bluetooth and Bluetooth LE, however, will share the existing Bluetooth physical radio and antenna and so maintain the same power consumption as classic Bluetooth technology.
Comparing power consumption can be challenging, given that proprietary RF chip manufacturers typically do not disclose power consumption on datasheets. Developers must therefore obtain their own power consumption data using experimental board set-ups and their respective firmware test environments.
Reliability and Security
Robustness to interference in the 2.4-GHz world means the ability to reliably co-exist with 802.11b/g, Bluetooth, Wireless USB, and a host of cordless phones and microwave ovens. While some proprietary radio devices like the CYRF6936 can employ DSSS (Direct-Sequence Spread Spectrum) along with FHSS (Frequency-Hopping Spread Spectrum) transmission schemes, Bluetooth LE uses only adaptive frequency hopping technology common to all versions of Bluetooth technology. DSSS ensures data robustness while FHSS allows the wireless signal to hop to new channels once interference becomes too great. Lack of DSSS in Bluetooth is also a drawback compared to proprietary protocols as proprietary RF can co-exist in noisy environments without having to hop to a quieter channel. Bluetooth LE offers full AES-128 encryption to provide strong encryption and authentication of data packets. At the same time, this consumes a considerable amount of packet overhead. To ensure a reliable and secure system, it is the developer’s discretion to adopt an existing proprietary protocol or a standard like Bluetooth based on the hardware capabilities of the device and the security level requirements of the application. For applications such as wireless mice, for example, little if any security is required.
Speed/Throughput
Bluetooth LE supports an over-the-air data rate of 1Mbps which is sufficient for wireless HID applications. However, application throughput is only 256kbps due to overhead. Proprietary protocols have lower packet overhead and may be able to support higher throughput. For applications requiring higher effective throughput, Bluetooth LE will fall short of proprietary standards.
Certification
Certification is required for any Bluetooth-compliant device and is a pre-condition of the intellectual property license for Bluetooth technology. The certification process increases the product design cycle as well as introduces addition costs and potential delays. In the case of proprietary protocols, many manufacturers provide their qualification specification nearly free of cost so that product developers can qualify the protocol at their end to minimize development expense and time.
Applications
Any application can easily make use of a proprietary RF given the ease of modifying the protocol. In this way, applications can be modified to adapt to their environment by changing power output levels, activating a more robust means of communication, or by moving to a quieter environment to communicate.
In a market full of narrow, local, proprietary connectivity solutions, Bluetooth LE technology differentiates itself through its:
* Ease of implementation and multi-vendor interoperability
* Ultra-low peak, average and idle mode power consumption
* Low cost of integration
* Power handling
* Resistance to interference
Though Bluetooth LE looks like a promising technology for many applications, there are certain concerns that the industry needs to address before adopting this technology for HID applications. Certainly there is the advantage of eliminating the need for an external bridge. However, there is the pertinent question of when the electronics industry will be ready with integrated dual mode Bluetooth radios. Integrating a dual mode/single mode Bluetooth radio into hosts also raises the question of co-existence with Wi-Fi, WiMax Classic Bluetooth, and other 2.4 GHz technologies. This could be a major challenge for developers, and until chips are available, a short-term solution could be having an external bridge shipped with PCs. As Bluetooth LE is still in the development phase, the profiles for all applications are still not finalized. This will impact the penetration of Bluetooth LE into the wireless HID domain for a considerable length of time.
Although Bluetooth is a standard protocol, it is not free from drawbacks in its binding methodologies. For example, imagine a classroom environment where many students are using Bluetooth mice and all of them try to get their mice bound at the same time to their respective PCs. Cross binding may occur with one mouse talking to another PC instead of the one to which it is intended to bind. Proprietary protocols like the ones offered by Cypress Semiconductors avoid these issues by using KISS (Keep It Simple Solution) bind, Manufacturing bind, and Auto binding techniques. Developers need to implement similar binding methodologies if they are targeting Bluetooth LE for these sorts of HID applications.
Like any product, adaptation is a vital component to success. With its low cost and low energy usage, Bluetooth LE seems to be a good competitor in the wireless HID market. However, while Bluetooth LE is enticing many companies to enter the wireless HID market, Bluetooth LE cannot succeed until it competes and implements better features than what proprietary protocols have been successfully implementing over the past decade.
About the Author
Anitha TG is an Applications Engineer at Cypress Semiconductors, Bangalore, India. Her expertise is with USB microcontrollers and wireless HID devices. She holds a Bachelors degree in Electronics and Communication from Model Engineering College, India. Anitha can be reached at antg@cypress.com.
|
|
|
|
|
electronix79
1/6/2012 5:37 AM EST
I think this is more advertisement for Cypress RF modules, but the more right approach for this will be if you provide a real example with some block diagrams and comparison and support what you say. For me this article is fine because I am specialize in Wireless technology but when you try to sell the product you should be very careful what you compare.
My personal opinion is that the wireless communication should have strong security such as AES which BLE support it and also support strong Athentication where secure Link Keys are creates and updates during communication in order to protect from Man in the middle attack.
Also I am on the side of the standard protocol which is monitoring by organization and updated for detect bugs rather from using proprietary protocols which may have many weakness.
It will be much better if you mention where you want to use the proprietary RF protocols with Cypress product, because few application are not sensitive to attack. The simplicity is not always the key point for selection, especially when you want to use Mesh network and not just peer to peer connection. Mesh network require intelligent wireless stack and also well secure communication.
Sign in to Reply
mema
1/6/2012 6:59 AM EST
I write as one who works with several wireless systems, including Cypress.
Ble and 802.15.4 are good initiatives, and they will help in many applications. There is also (less) room for proprietary systems, but of course Ble and 802.15.4 are taking some market shares away!
This c ould be a concern for firms that only have proprietary systems. It seems to me that this article reflects that fear.
When will the industry be ready?
Right now, I have several mobile phones in my lab that implement Ble.
Of certain things will take time. Profiles will also take time to be ready. That is the case with ALL new technologies. You can make your own stuff with Ble HW if you want. With proprietary systems, you also need time!!
....Binding.
Your example is quite extreme!! I will suggest you give more realistic cases.
You will need to have students who are sooooo synchronised that they manage to push buttons within hundred of millisecs.
The Cypress devices have interesting features such as DSSS+ FHSS, but these features are not always needed.
They also have weaknesses, compared to Ble or 802.15.4
http://www.ines.zhaw.ch/
Sign in to Reply
t.alex
1/14/2012 7:32 PM EST
I think the 'binding' issue in th classroom will happen with any protocol isn't it?
Sign in to Reply
Luis Sanchez
1/18/2012 1:36 AM EST
Good to read this article. Though I would like to add my two cents by saying...
The AES engine in a BLE chip isn´t used for authentication, only for encryption. Authentication is identifying or confirming the peer device is trusted or not. The AES engine applies a code to the data being transmitted so that third parties can't listen or decode.
In regards the example of binding several BLE devices at the same time I doubt this would happen. One reason for this is that BLE allows for filtering devices by using a "white list", this way a mouse vendor can match the peripheral mouse and the BLE USB adapter together and this way avoid or reduce the devices that can connect.
And finally I think comparing BLE to a specific and named propietary wireless technology would be better.
Sign in to Reply
electronix79
1/19/2012 10:57 AM EST
It is obvious that AES is not used for Authentication, but in the created wireless link. The usually standard procedure in exchange of Key is through the Asymmetric Cryptography and generally to my knowledge the ECC (Elliptic Curve Cryptography) is used. The common key exchange algorithm is ECDH. Where:
A - device generate the pair keys (public and private), then send to B - device the Ka * P, where P is the point in Elliptic curve.
B - device do the similar and send Kb * P to A device.
And finally the created secure Key is defined as
C = Ka * Kb * P
This C Key not can be used with AES in created wireless link, which is also can be automatically updated in BT v2.1 and over, depend how you setup the parameter for the updated the link Keys.
Sign in to Reply
electronix79
1/19/2012 11:00 AM EST
Small fix (correct not to now) :)
This C Key *now* can be used with AES in created wireless link, which is also can be automatically updated in BT v2.1 and over, depend how you setup the parameter for the updated the link Keys.
Sign in to Reply