If we seek to add Real-Time Location Systems data to in-building wireless tracking systems using the WiFi standards, we run into similar interoperability issues. While we can all connect via laptops to wireless networks anywhere in the world, the minute we ask "where" a device is using the 802.11b in-building wireless protocol, we are restricted to proprietary triangulation algorithms that restrict interoperability of active RFID tags. In ad hoc networks such as 802.15.4, we have the same difficulty of connecting higher level functions of the protocol with devices from different manufacturers.
As a result of this lack of interoperability, every time we add a new telemetry device to a wireless network, we have the n2 problem of having to customize interfaces to every other device on the network.
US hospitals adopting electronic health records feel the negative effects of such fragmentation. In order to comply with government requirements, they must find ways to import data from hundreds of different proprietary medical devices. The only way to accomplish this today is to purchase connectivity middleware from third parties.
One way to address this issue is to create a lightweight, low-power layered network protocol, similar to IP, for granular data transmission and overlay protocols for control signals on it. 6LoWPAN, Z-Wave, and Ant represent attempts at gathering manufacturers together around such a common architecture.
Another approach is to create a lightweight set of API's for sensors. Kang Lee, who leads sensor research at NIST, proposed in a 2009 book (RFID Technology and Applications by Cambridge University Press) using the IEEE 1451 specifications for a common set of commands for all sensors, with little industry uptake.
In response to my previous blog, Laurent Liscia, president of OASIS, suggested that group's Message Queuing Telemetry Transport (MQTT) "might provide a lightweight publish/subscribe reliable messaging transport protocol suitable for communication in M2M/IoT contexts where a small code footprint is required and/or network bandwidth is at a premium."
What promising developments for unlocking data from remote wireless sensors do you see?