Sunday, January 25, 2009

Useful Wi-Fi extension: add user-programmable field for access points

I was doing a little research into Wi-Fi positioning systems (like Skyhook), and it occurred to me we're missing out on huge opportunities in the Wi-Fi space. Skyhook can tell you within excellent resolution where you are, based on a combination of an extensive access point address to physical location database and signal strength information (now even assisted by GPS and cellular radio).

But there's another way to look at this problem, which would give a more democratized and rich solution, however with attendant noise and error. Many access points (APs) are programmed to send out periodic "beacon" packets (unless programmed not to announce their networks). These packets are designed to allow devices to discover Wi-Fi networks before attaching to them, so no transmit capabilities are needed to receive them. Why not allow an extension of the IEEE 802.11 protocols such that a given AP can introduce a programmable payload of data into an extended field in the beacon (or other such) packet? GPS coordinates would be an obvious payload component.

While researching this, I came across interesting suggestions to use XML to encapsulate the data. Of course, packet length is important, so either payloads would have to be short, or perhaps have critical fields (GPS coordinates for example) and a reference URL to the rest online. There are many possible useful bits of info which could be in the XML payload, such as those in one related suggestion:
Perhaps they could also provide hints such as, "quiet area: devices should switch to vibrate mode here."
In any case, what I like about offering user configurable data is that the packet fields only need to be extended once and the XML format can evolve independently. And perhaps as importantly, devices can glean information without having to ever transmit information. Receive-only or lower power devices could use this data, opening up a whole new world of opportunity! Maybe we'll see a pair of shoes which gather a whole stream of information as we walk about cities, all self powered by our walking...

Disclosure: no positions

3 comments:

abnerg said...

This reminds me a bit of the old WiFi vs. 3G debate that relied on ad hoc coordination among network owners to create network "lily pads" Coordination on a mass scale or even inclusion of GPS in an AP (although the metro mesh guys do it today) is tough to place any bets on.

decius said...

Technically 802.11 beacon frames are extensible. "Device specific" fields can be added to the end of the packets and devices that don't understand those fields will just ignore them. However, I don't know if the firmware designers usually expose an interface that allows drivers to set these extensions. The standard doesn't imply that these fields would be accessed by software, but a smart designer would have exposed them. The place to start is by digging into some of the open source wifi drivers...

But why not just build your standard at layer 3 - if you seen an SSID called "xmlinfo" then connect, get an IP, and make an HTTP connection to a server indicated in the DHCP message to download an xml file with data on it. Access points with this SSID are presumed to only serve up this XML file and do not normally provide internet access...

abnerg said...

I have no doubt you *could* embedd some very cool info in the beacon that *could* enable some very interesting applications. What I doubt is the ability to coordinate network owners on a grand scale. I'm actually surprised the enterprise WLAN location/asset tracking types haven't made more out of this, although they seem to be ok with the data they are able to pull off the APs today.