What should designers consider when choosing between Bluetooth and Bluetooth Smart?

The Bluetooth SIG established the technology to meet multiple requirements, including: • the replacement of cables and connectors • support for voice and data transfer • robust and secure transmission • spontaneous links between different devices • harmless to the environment • working in the unlimited worldwide 2.4GHz band • very low power consumption • small chip size and cost Many of these requirements have been met and are some of the key reasons why Bluetooth has been so successful. However, for some applications, power consumption was still too high. With pressure coming from existing users, but also from upcoming technologies like ZigBee, the SIG decided to create a standard based on Bluetooth Classic which had lower power consumption and which could make spontaneous connections more readily. However compromises have to be made, such as: no support for voice and audio transfer; slower data transmission; and smaller networks – most applications would be point to point. This was the birth of Bluetooth Low Energy, now called Bluetooth Smart. What are the differences? The underlying technology features of Bluetooth 2.1 are the use of a spread spectrum frequency hopping, full duplex signal at a nominal rate of 1600 hop/s with 79 channels. The protocol implements confidentiality, authentication and key derivation, with all data encrypted during transmission. These features make Bluetooth robust and secure. But there are also three different power classes, support for a piconet topology, with one master and up to seven slaves and, before establishing connections, all devices are in 'standby' mode. Here, they listen passively to the frequency bands every 1.28s and monitor a list of 32 defined hop frequencies. Already, differences can be seen in Bluetooth Smart. Due to the overall design goal of low power consumption, complexity has had to be reduced, hence it uses a different PHY and only supports three advertising channels in order to establish connections faster. A further difference is the use of 37 data channels, each 2MHz wide, instead of the 1MHz channels in Bluetooth 2.1. It also uses much simpler encryption. Hence there is a greater environmental influence on Bluetooth Smart and it is not as robust as Bluetooth Classic. Establishing a connection is faster; because there are fewer advertising channels and fewer security features, a connection can be established within 3ms, compared with 150ms for Classic. The network topology is also different, with support no longer available for the role switching of masters and slaves. Power classes are no longer available and the maximum output power is specified at +10dbm. A comparison of the features can be seen in table 1. The software stacks are also different. The features in Bluetooth Classic are intended to support full devices, like headsets, mobiles and printers. This means the protocol stack is complicated, supporting a lot of features with 'profiles' describing different device classes and guaranteeing interoperability. A typical Bluetooth V2.1 stack is shown in fig 1. Many of these protocols support special features, like SDP (Service Discovery Protocol), which looks for other devices and services, and OBEX, which allows objects to be exchanged. In addition, the complex but fundamental Logical Link Adaption Layer – required to guarantee a secure connection – makes the protocol complicated and large. As a result, it consumes more power. However, this complexity does mean it can support more features. Fig 2 shows the much simpler structure of the Bluetooth Smart 'Low Energy' stack. Complicated middleware protocols like OBEX or TCP/IP and the main protocol RFCOMM for communication are no longer available, with communication handled more simply. The stack itself is specified to be much leaner. No longer are complex profiles available that describe devices like Hands Free. Only services – small functions of devices – are specified within the Adopted GATT Profiles and Services. This means Bluetooth and Bluetooth Smart devices use different hardware and software stacks! In order to combine both technologies, for example in a smartphone, chip and software designers have had to create devices which could handle both the 'Classic' World and the 'Low Energy' functionality. These devices are called Bluetooth Smart ready. MSC is supplying a range of modules from Panasonic Industrial Devices as well as software stacks from ARS Software which might be required either in Bluetooth or Bluetooth Smart applications. Misleading users A large smartphone manufacturer has implemented some special features into its devices and uses a crypto chip to ensure that not every device is compatible. Designers who want their products to be fully compatible with these 'special' smartphones need to join a special partner program in order to receive information about the crypto chip which needs to be incorporated into their design. However the company did not implement the same feature into Bluetooth Smart, hence some suppliers suggested using Bluetooth Smart instead of Bluetooth V2.1 devices to overcome the need for the crypto chip. Customers also thought that V4.0 would be fully downwards compatible to V2.1. However, this is not the case, due to the different hardware and software implementations. In addition a number of features required in its new application, including audio streaming, cannot be supported by Bluetooth SMART. It is clear that all designers must check: • what features are required in their new application/device • what data transfer speed is needed • what security is needed • what compatibility is needed with mobile devices like smartphones, tablets and more, and • what are the target customer/user devices After creating a matrix during this process, electronic engineers and product managers will be able to decide which route to go. Those designing a product which should be compatible with all smartphones – perhaps supporting voice in addition to data transfer – may have no other choice than to apply to join the partner program described above. Another company – perhaps developing an in house application for their service personnel – may decide to target a specific smartphone without this kind of restriction and which does not require any kind of crypto chip. In applications requiring limited functionality – for example, where small amounts of data are sent periodically and where power consumption is critical – designers don't need to think too hard; they can use Bluetooth Low Energy without any restrictions. However, they will have the problem that older smartphones or mobile phones will not support the Low Energy technology. It is not an easy decision for the engineering and product marketing teams, but one which becomes clearer after understanding the different Bluetooth technologies available. We can be sure that, in the future, with more and more Bluetooth Smart Ready products being designed and perhaps without any restrictions from some smartphone suppliers, the successful growth path of Bluetooth Classic and Bluetooth Smart devices will continue in parallel. Walter Puhl is rf product group manager for MSC (www.msc-ge.com). Rudi Latuske is managing director of ARS Software (www.ars2000.com).