Is it time to standardize Bluetooth API?
Bluetooth has shown remarkable growth over the last 10+ years, now shipping in the order of billion devices and chipsets. Bluetooth, once synonymous with a wireless headset, thankfully, has broken out of the typecast. No decent mobile phone can be imagined today without Bluetooth, or a tablet, or a laptop. Then there are Bluetooth speakerphones, media players, photo frames. The technology has seen adaptation in the automotive segment, too, with factory-fitted car kits, after-market products, and navigation devices. Bluetooth has taken a leap with its low-energy avatar and is making interesting and swift inroads into health, fitness, and sports.
The technology owes much of its success to the Bluetooth Special Interest Group (SIG). The SIG, among other things, looks at systematizing Bluetooth as a technical standard with its mammoth and detailed specification documents. These specifications are at architecture and protocol granularity defining the packet format, request-response flows, and so on.
A Bluetooth stack provider may choose to implement the stack in any way as long as the implementation conforms to the protocol definitions. The implementation is certified to be compliant and interoperable on the basis of the protocol exchange.
From a range of such compliant stack providers, a product manufacturer or system integrator chooses one that suits his or her needs--platform, competitive features, memory footprint, supporting documentation, ease of integration, and ease of application development being the influencers. However, the product application is now tightly coupled to the vendor's specific application programming interface (API). Should the product manufacturer desire to introduce another vendor into their future version for business or competitive differentiation, it is not easy. The engineering inertia overshadows the business reasons. In fact, legacy comfort is a dominant decision criterion during "vendor evaluations." This is also a reason why many product manufacturers prefer (or, in some cases, are compelled) to have a captive or in-house stack IP and resources.
Has the time come to take the Bluetooth standardization to the next level--the API?
Such an attempt was made in Bluetooth SIG in 2007 by forming Bluetooth Embedded Controller (BECI) working group. However, the group did not produce any adopted specifications and was dissolved in 2010. What could have been the reasons?
There have been similar initiatives outside the SIG, albeit in the Java world.
In the early 2000s, JSR-82 evolved as a standard JABWT (Java API for Bluetooth Wireless Technology). This standard defined for J2ME platform came through the Java Community Process. JSR-82 enjoyed a fair amount of success and acceptance as it went on to become a regular feature on Symbian and BlackBerry phones. A major drawback of JSR-82 was that it remained as stack API and didn't evolve to support profiles. Profiles are the endpoints of Bluetooth stack that finally enable useful applications to be built.
About the same time, Bluecove emerged to provide the JSR-82 compliant API on J2SE platform. Bluecove is open-source software that builds the JSR-82 compatibility over a platform native stack. Thus, one can write a Bluetooth application that runs virtually on any platform that supports Java.
A point to note: Bluecove is not legally referred to as JSR-82 implementation as such a tag requires an official compliance test. Bluecove does not pass a few cases, which its developers justify as the limitations in the native stacks it builds upon.
What's out there
Here is a short round up of the stacks in use on popular platforms and operating systems. Some of these have a higher acceptance by the industry and developer community and have gained a de facto status.
BlueZ has been around for several years now for Linux OS. Beyond the plain "Bluetooth sockets" and "C API", BlueZ integrates with D-BUS to render a decoupled, language-independent interface.
Windows has a native stack with its own API. There are also numerous vendors with their own API for Windows and Linux OS.
On the mobile platforms, Android has its own Java Bluetooth Java API. Interestingly, Android developers chose to ignore JSR-82 to define a new set of API. Had they retained and enhanced the JSR-82 standard, all older applications could have found a home on the new phones. With Android emerging as the largest deployed smartphone platform today, we could say there is a degree of API portability across phone makes.
The other major mobile player, iOS has compatible API for its phone and tablet devices.
Outside the desktops and mobiles, Bluetooth sees a larger use in embedded world--sensors, headsets, etc. There are several vendors in this space, again each with their own API.
With such variety, common API would help, certainly?
Every product idea starts with precisely that--an idea. The idea needs to be vetted and put through a feasibility gate. Typically, resources are limited at this stage with no serious investments and stack licensing forthcoming. Imagine a reference (read, free) implementation available for a standard profile with defined API. With the reference implementation, the idea takes a tangible shape, passes through the business-marketing gates, and emerges as a product at a faster pace. While in production, the engineering throws out the reference implementation to bring in a more stable, licensed (read, paid) stack--all done with no changes to application. For next product version, you are not happy with your stack vendor? No problem, throw it out again and bring in a new vendor.
Why not a common API?
What could be the arguments against common API?
One argument might be the diversity of stack implementations makes the common API impossible. Some stacks provide blocking calls while others follow a non-blocking, event-driven design. Inherently all stacks provide the same profile features. If the Bluetooth community could agree on such complex specifications, surely we can agree on common minimum interfaces?
Another argument might be the loss of implementation flexibility and optimizations possible while adhering to the defined API--a valid argument where optimization matter on the severely resource constrained embedded devices. The challenge here is the value addition we can offer while sticking to the API. When all stacks offer same interface and profile features, how does one stand out? Can our stack be the world's smallest implementation while still adhering to the standard? What else is our value add? Speed? Ease of integration? The stack vendors will need to compete at a different level than legacy continuity. The Bluetooth competitive landscape will see a radical shift.
Here are a couple of examples how the industry and developers have gained from common API.
Every embedded engineer worth his salt is familiar with POSIX. POSIX is a family of IEEE standards that defines API for operating services such as file and directory operations, threads, synchronization mechanisms, and several others. Practically, all major operating systems in use today, fully or mostly, natively or with translation packs, comply with the POSIX API. This has simplified the development process by reusing knowledge, reducing the learning curve, and providing high-level application portability.
An example a bit far removed from our embedded world--in enterprise applications, Java Web Services (JAX-WS, JSR 224) is a specification that not only defines the messaging protocol (SOAP-XML) but also the API available for use by client and server implementations. A web-service developer may use any of the compliant open-source or proprietary implementations, including the freely available Metro Reference Implementation. The JAX-WS is part of the larger JEE suite driven by an expert group of organizations, similar to the Bluetooth SIG working group. These organizations are fierce competitors out in the market and yet can sit together debate, vote, and arrive at the standard, where portability and avoiding vendor lock-in are some of the primary objectives. Java EE is a very widely deployed enterprise technology today as customers can learn, embrace, and adapt the technology without initial capital costs and tie-in fears.
Are we, the Bluetooth community, convinced? Will this be the idea that will take the technology into its next decade of existence? What should we do?
Girish Managoli is technical director at Mindtree Limited. Over 14+ years of experience, Girish has contributed to, led and delivered Mindtree's EtherMind and BlueLitE Bluetooth suites for several customer products. He is particularly proud of being part of one of the world's first JSR-82 implementations. Girish holds a bachelor's degree in electronics and communications engineering from University of Mysore, India.