About Paris Heng NETwork

On a recent roadtrip, I did some “wardriving” where you scan for 802.11 (wifi) access points. Today they are everywhere. The scanning program lists the network name (SSID) as well as other information like the model of access point and whether it has encryption on. Often the SSIDs are informative, with the names of families and companies. Mine is an web address that would let a neighbour contact me.

All this happens because most access points transmit a regular “beacon” packet which lists their SSID and other information needed to connect to them. Seeing that the SSIDs were sometimes interesting, I wondered if we might do much more with a special beacon.

This beacon would deliberately tell you a bit about the access or location. It would contain a mixed XML/HTML packet with a variety of useful fields and general text. These could range from simple descriptions (“This access point belongs to Joe Smith, I’m a programmer”) to information (“On this site, Paul Revere stopped on his ride to consult with local minutemen”) to street directions (“Turn right to get to highway 101, left for downtown”) to, of course, advertising (“We sell fresh fruit and have a special on plums today.”)

In other words, a replacement for signs and billboards and markers. And perhaps much more. Access points would also talk about themselves, declaring, for example, if the owner is offering open internet access for free or for fee, or has a local database of information, and what classes of information are in the main text. The local lattitude and longitude for those without a GPS could be useful, along with local map data in a compact form.

Users could quickly get a program for their laptop (such as Netstumbler) to read and display such virtual annotations to the world as they drive. Primarily for passengers to use, of course. Eventually dedicated boxes would become available, and onboard car computers and GPS units could understand the protocol. Mass market access points would include a set-up screen in their web interface to let the owner enter the information beacon text and enable it. (Today some APs have open source firmware and an energetic programmer could do this right away.)

All of this might be both useful and entertaining. Children might enjoy reading all the random bits of information that flow by and stop asking “are we there yet?” The journey can become the reward. (Of course remember to look out the window sometimes.)

I can imagine vendors making a cheap solar powered access point that, during the day at least, sends out information beacons as soon as enough power is stored in the capacitors to send one. These could operate on a small, cheap solar cell (the more power, the more frequent the beacon) and be placed anywhere. “I’m an oak tree!”

Below, I will get into some technical issues and discuss the unanswered question, which is how to avoid abuse by excessive advertisement, spam and falsehoods.Extending the 802.11 protocol to include this sort of beacon would not be too hard. One would want this beacon to be a less frequent than the typical 100ms for the protocol administration beacon. It might run every 1 to 2 seconds. It would probably be limited to a small size — a few kilobytes — and run at the 1 megabit speed for longer range. Care is needed or else a cacaphony of information beacons might use up a lot of bandwidth. The main beacon might also add a bit to say that an informational beacon is available. Alternately, endpoints might wait for the main beacon, check for a new flag in it, and then send a form of the probe packet to request the informational beacon. This would allow it to be larger as it would not be transmitted very often.

As everybody knows, most signs on the road are advertising, and I think it would be nice if there were some way to stop these beacons from being mostly spam. Beacons on actual roadside stores would be tolerable, telling you about the store and what it’s selling, but we know vendors would want to place beacons far away, on all the approaches to their store. How many would Wall Drug erect? The beacons with solar power could become so cheap as to flood the planet with virtual advertising.

Would an honour system work? Beacons would be expected to tag their type of message — local info, description, historical marker, road directions, onsite advertising, down-the-road advertising and so on. But if people selected their receivers to tune out various types of ads, would the advertisers accept that or lie about the type of message? A reputation system could help here, where both databases and other local beacons include information on who to listen to and who to ignore, but ignored folks will quickly get a new MAC address or other token unless there’s a big certifying authority that hands out IDs which I want to avoid for a whole number of reasons. I am looking for good suggestions that don’t require a certifying authority whom you must go to before you can put up a beacon people will pay attention to.

It would be nice to build a protocol that would allow a single packet from the endpoint to start a web fetch. The packet would authenticate and associate (only on open networks) and ask/demand an IP address, and include the HTTP header of a web fetch or certain other specialty requests. The response would acknowledge all of these, including the IP address.

One idea, to avoid the DHCP step, is to use an autoconfiguration protocol in the 10.0.0.0 network, and for the AP to expect this. You would send out a packet, assuming your auto-chosen IP address and get the response back right away except in the rare event you’ve chosen a colliding address. In a drive-by, a collision probably means you don’t get the data, ie. collisions are good to avoid while driving.

This would allow quick data grabs, such as web fetches, grabs of the latest news or the next 100KB of some audio stream, or even partial e-mail sync-ups for people doing mail.

In particular, APs with beacons might include URLs in the becon that can be fetched for more information. These URLs might be out on the open internet, or just served from a disconnected AP itself. Some endpoints, such as laptops, might be programmed to fetch in all the URLs noted in a beacon for storage and perusal after the car has zoomed past. Thus the basic beacon might include a historical marker, but it might trigger the fetch of a 100K of other useful data. (A protocol to bundle a set of web pages together into one stream would be handy here.)

And the commercial applications of this are not at all bad. As you zoom past a restaurant, you might receive its menu. You could certainly do so manually if you stopped next to the restaurant, even without automatic fetch.

This includes some blending of levels in the protocol stack that might make some network engineers uncomfortable. But to do useful work in the few seconds you can see an 802.11 AP while driving past it at high speed, some of this is necessary. And the result would be highly cool. I could see all sorts of good things, along with commerce. People learning more local info. Neighbours meeting neighbours with the electronic introduction.

And, to add a positive note to the advertising question, if this became popular, virtual ads might well replace the ugly signs and billboards that pollute our landscape. Some of them, anyway. The APs would be vastly cheaper than any decent sign, even with a solar panel. Pedestrians would be locked out for a while, though.

Of course, some of this could be done with a big fat database people download, combined with a GPS. And in fact, some mapping software already meets some of this need. But that’s all with central databases. I like the idea that the $40 access points people are already buying could produce a giant decentralized database of local information.

Responses to user comments.

I met one of my own neighbours because his SSID was an E-mail address. In fact, I ended up joining a group that owns a colo server with him, so it paid off for me.

There are a whole bunch of issues and solutions here. Some things (like maps and annotations) are often best served by a central geo-linked database that you update when you’re online. There are things you want central control for (and can get in a comprehensive form) and things you don’t. AP owners aren’t likely to want to support annotations negative to their location — that’s exactly where you want an external database that you trust.

Note that if APs allow you to do quick data-grabs that might include updates to your geo-based databases for the region.

Key to this idea is the drive-by. Thus the beacon (one way broadcast) and the proposals for data grabs that require close to nil or nil handshaking. Today we have a chain of probe, beacon, authenticate, associate, DHCP, TCP setup and data fetch. This doesn’t work in a quick drive-by where not only are you only nearby for a short time, you have high packet loss and can’t afford timeouts and retransmits. Even Rendezvous and other autoconfigs just remove some of this long chain of handshakes. I propose a single frame which contains all you need to associate with an autoconfigured IP address, and an embedded UDP packet using that address, and a UDP protocol to do a best-efforts web fetch proxied by the AP or another system on its network.

Anything with handshakes or assured delivery will likely have you out of range before it’s done. Of course if you know you are going slow (and your signal strength history can tell you that) you can use more robust protocols and full TCP.

As for the cost of your AP, APs are now as low as $20 in stores, I don’t see them as a big thing to steal. An AP with a solar panel strong enough to let ti broadcast frequently would be more expensive.