RuBee is the basis for a new IEEE standards effort, P1902.1, also known as "IEEE Standard for Long Wavelength Wireless Network Protocol." Ah, such wonderful names; please pardon me throughout the rest of this post for referring to it simply as RuBee. The IEEE announced this new standardization activity on Thursday, June 8th, on their website, but it apparently took the weekend for the mainstream RFID media to pickup on it, another day for everyone read it, and another to email me about it (it was a Tuesday, hence the title - coincidentally I found out that the protocol was actually named after the Rolling Stones' song because 'it just sounded good'). Unfortunately it took me the better part of a month to post a response, and even more unfortunately is that this wasn’t due to massive amounts of detailed research on my part, but rather the massive amount of other tasks I’ve had on my plate recently.
My first inclination about RuBee, without a true in-depth analysis, is that it is a mixed blessing right now. SAP is very interested in the success of Real World Awareness (RWA). SAP’s Auto-ID Infrastructure was designed and built to further RWA in the enterprise; not just because of the excitement around RFID. If our customers want to use RuBee, then the SAP Auto-ID Infrastructure will support it, allowing customers to take advantage of the RWA capabilities that RuBee has that RFID lacks. On the other hand, RFID has gained and is gaining significant traction for RWA, and this new protocol may cause confusion and/or slow RWA adoption overall. I believe that education of the market place and proper stewardship of the technology are the key points for RuBee to succeed, and more importantly, to be successful for our customers.
The Right Tools
The fact of the matter is that RuBee is different from RFID. It has different strengths and different weaknesses, and therefore lends itself better to certain situations than others. RuBee sounds great (at least, from the press release) for those situations for which RFID isn’t well suited, e.g. the metal and water read accuracy dilemma, and RFID is better suited for faster read rates, which is useful for products on fast conveyor belts. For end users, this is potentially a Good Thing. Rather than try to jam square peg into a round hole, they now have two types of pegs: square ones for square holes and round ones for round holes.
Although having the right tools for the job is generally good, there is a slight catch. What happens when you have metal objects that need to be tagged and read quickly on a conveyor belt? One answer is that you simply use both technologies. An RFID tag and a RuBee ‘tag’ can both be affixed to the object, similar to the way that we currently have RFID tags with bar codes and plain text descriptions. It may cost more, but it would also work, and it would provide a more effective solution to such a situation than currently exists.
From an enterprise perspective, the important thing is the use of the right tool for the job. However, RWA in the enterprise is a relatively recent concept and RFID has gained widespread traction for the RWA cause. The emergence of the sensing technology market has companies scrambling to figure out how to best capture a (bigger) piece of the pie, which includes starting new technology efforts like RuBee. I don't think it's a coincidence that the chair of the standardization effort is also chairman of Visible Assets, a company that specializes in this technology. I think that there is definitely a place for new efforts like this, but I worry that too many options may confuse the market and slow adoption, especially if RuBee diverges from the software standards arising in this area.
RuBee is simply another wireless sensing protocol. It will be handled by hardware, and there will be RuBee ‘tag-like things’ and RuBee ‘reader-like things’ and they will be used in a manner very similar to RFID. I would even imagine that the cost difference between RuBee and RFID hardware won’t be substantial, but that’s pure speculation on my part right now. If companies have use cases like the one mentioned above, they are free to invest in one, the other, or both types of hardware if it fits their needs. The data produced by both hardware solutions will still need to be processed by a software system in order for them to be truly valuable to an enterprise.
Software Standards Support
From the software perspective, there is a danger that the RuBee technology stewards will go in their own direction and define different data standards or higher level protocols on top of RuBee. Doing so would harm infrastructures interested in the more generic concept of RWA, causing, in the worst case scenario, two completely parallel technology stacks. Given the traction behind RFID I think that this would be especially unwise, as it would likely impede adoption of RuBee significantly and potentially RFID slightly, as enterprise software vendors would be forced to focus on their own ROI.
Instead, if RuBee is designed to support the higher level protocols defined by the software specifications in the RFID world (e.g. ALE) and carry EPC encoded data, then I would assert that there is enough room for peaceful co-existence and even a symbiotic relationship between the two technologies. RuBee can ride the coat-tails of RFID’s popularity to gain adoption, while RFID vendors don’t have to try to be the be-all end-all and can focus on the scenarios to which they are best suited. I would support such a move as it would allow customers to use the appropriate technology for their scenarios straight out of the box with enterprise software solutions like the Auto-ID Infrastructure that already support the software standards.
