802.11 broadcast of local info
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.
On top of all this, it would be cool to develop an 802.11 extension to allow a "quick association" for fast grabs of data in a noisy environment. This would be meant for grabs by moving cars which will only be in range for about 5 seconds, a "drive-by tooting." Right now they must authenticate, associate, get a DHCP address and then do a TCP session (such as a web fetch) and it can be too much work in the short time.
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.
Fri, 2005-03-18 15:21
i've had my AP set up with the string ", come say hi!" since i moved in here and set it up, 7 months ago now. i live in the middle of a highly technical town (austin, tx). i've seen a neighbor using his laptop; when i brought a mac over it found a couple of other networks (sadly named "linksys" and "default"). but nobody has come by. has anyone actually visited your web link? i think this is a great idea but i don't see it catching on yet, save for wardrivers who are not, i feel, the type to coem by and say hi for the most part.
of course, a motivated thief might break in and take the AP (which is one of the more valuable things in my house which is not too big for one person to carry...)
Thu, 2008-07-17 14:49
Even Radio Amateurs' APRS nodes can/do give their locations now!
Hams using AX.25 Packet Radio based APRS (Amateur Position Reporting Sys, or similar) have connected (GPS + APRS-radios)-equipped moving vehicles & portable handhelds into loosely coupled networks.
Join one - just by wandering into coverage area - & you can get info on others' locations, comms capability & sometimes local weather, from local, semi-local or even distant stations, while sharing your attributes with others, near or far away.
Short messages can also be sent - either as broadcasts to
all, some or one node(s) in the network.
Filtering of traffic. as well as limiting of the extent to
which one's own reports get relayed to others is possible
(ie, in an effort to limit traffic on available channels;
this is NOT done in a way to insure privacy... messages
cannot, eg, be encrypted by the system).
This is useful for tracking friends or - at an emergency
incident (eg, bushfire) - even multiple vehicles or
responders, as they make there way, all on the same moving-
map computer screen(s).
Any APRS node can upload location of points NOT already
represented by a radio-equipped APRS node, and all can "see"
(in tables &/or on their moving-map displays) the newly defined
vitual nodes, in near real time (at least, when they're
located near the point of upload).
Perhaps one could link the APRS system's data stream
into one's local WiFi-based MESH network(s) & filter
(eg, using "WiFi" or similar as filter key) for the
locations of nearby WiFi nodes...?
This would seem to take just one or a few uploaders
of location data & a few reliable connections between
the two networks, possibly a one-way (eg, Amateur to
WiFi mesh) connection would suffice.
Alternatively, one could incorporate APRS-like info-
sharing into future MESH networks.
(In fact, the Amateur's application needs to be non-
commercial; so, it might be -necessary- to reverse-
engineer & implement a similar system on the WiFi
side, to use this technology for commercial ends.)
Are there any precedents or works-in-progress?
1. APRS UK White Paper (it has a few low-quality images,
but is otherwise quite comprehensive):
2. free-to-use, closed-source APRS moving-map, messaging,
data uploading application (Its author is deceased; but
cost-free registration, on-line, is managed by a few
UK-based radio amateurs, eg, for those wanting to try it
- in monitor-only mode, if not a licensed Radio Amateur):
"UI-View" (for which several add-on's have been developed,
eg, to use map CD-ROMs)
3. there are web sites that display APRS-based moving-maps
PS I think it was APRS-like applications, as well as similari-
ties of minds, that sometimes brings together Radio Amateurs &
WiFi hobbyists, eg: http://Air-Stream.org.au
Such cross-polonisation can good for both sides of the equation. ;-)
Fri, 2005-03-18 15:22
er. in my previous comment, the string was "my address", come say hi (within angle brackets) which the software here apparently eats. oops.
Sat, 2005-03-19 01:45
Why build it into Wi-Fi? I have thought for many years that you should build such a service say local.wifi.com that someone accessing a wifi network could use. While I'm not sure of the technical details of automatically capturing the AP - you could allow everybody to comment - like digital graffiti or digital breadcrumbs, and provide other services as well (e.g., reviews of restaurants local to that AP). Centralized, this information could then be aggregated for others to access who aren't on wi-fi.
Sat, 2005-03-19 04:08
Do you have any friends in the UPnP consortium? There could be a fit for this idea there.
Tue, 2005-03-22 00:58
One potential problem is advertisers (spammers) could set up a huge number of access points that do nothing but constantly blast out ads on every channel, saturating all of the available frequencies and preventing productive usage of the spectrum.
Sun, 2007-08-12 08:56
Well, there's always vigilante action...
Far from it for me to condone such action, but there's always leeway for someone with a directional sniffer and a lump hammer to 'discourage' the overplacement of such devices if they end up causing a nuisance and disrupting actual data transfer... should complaining to the party responsible not get anywhere.
Kind of like those who 'alter' billboard ads for not-so-ethical firms, or set fire to speed cameras...
Tue, 2005-03-22 01:01
It's interesting to see different variants on how wi-fi could be extended. I came up with an idea to embed the zip code + 4 of an access point, into the SSID. For example my access point has a SSID of theboxfactory:60607-3533. With this simple SSID 'tag', any application could potentially extract its location and then derive local information. You can read a little more detail about concept at this post http://theboxfactory.net/weblog/index.php?p=5
Tue, 2005-03-22 02:47
Have you seen the Wireless Ontology?
If your AP/Node has a web server, you can embed this in your splash page or (even better) announce via Rendezvous..
Not all APs run customizable web servers, but of course, a server (or small dock/tray application) on the local lan can handle this.
Your client can then listen for the Rendezvous Beacons and pick up the RDF. You can then use offline tools to visualize, map, determine services available, etc.
Wed, 2005-08-17 16:35
I have translated into Polish one of the W3C recommendations but I am not sure whether it's 100% correct. Anybody speaking Polish out there and reading this note, please review it an let me know of any mistakes. It is available at http://www.geocities.com/pan_andrew/ResourceDescriptionFramework.htm
Fri, 2005-08-26 16:42
Good work. I'm impressed by the accuracy of your translation. I have made my degree on RDF and it will be a pleasure to give you some hints to improve your translation. I'll contact you via mail.
Tue, 2005-03-22 10:54
Interesting idea. I can see how this would be useful, but I see it from another angle.
Instead of changing the current standard and using beacons, how about creating a new standard which is disassociated? Using layer 2 only, (or perhaps a new layer3 protocol) devices walking or driving by can request a frame from the AP, without negotiation, using their MACs.
The frame could be a webpage request (which the AP then NATs using it's IP), or a partial content request. Asking for a few frames of a webpage will make it load slower, but allows smooth transition across multiple APs. (Although each AP will need to fetch the page). Users walking by can request the first few frames of a webpage, and have the rest of the webpage served by another AP. Streaming music would be similar, although current streaming technology currently doesn't support it (or you would get gitters, or other problems).
The "beacon" would be a normal SSID, but expanded to include a URL and Link title. Users walking/driving by a restaurant could select to open the restaurant's webpage, or disregard it all together.
Instead of using 11 channels, these devices could use the entire public 2.4 GHz range, but implement FHSS to avoid colliding with other APs, similar to what bluetooth does.
It would be a wonderful world if you could drive around anywhere and get internet access all the way. It would make Google Maps that much more handy. Even having a wireless-enabled handheld, it would be nifty to check movie reviews and trailers while you are waiting in line at the theatre. Or give cheap handhelds to kids and tell them if they want to learn about something, just go near it, and a link will pop up, where they can click for more information.
For advertising, the advertiser can provide you a link & link title, but if they want you to visit their site, they'll need to provide you with a little bandwidth... availability would push the adoption of the technology, advertising would pay for it. Atleast until some advertiser figures out how to reverse-engineer an AP so the only pages you can get to are the advertiser's webpages.
Mon, 2005-03-21 22:55
I developed this concept as "Digital Graffiti" several years ago. A range of equipment would broadcast info via Bluetooth, infra-read, RFID, Wifi as snippets of XML. The idea was to develop a device that was cheap enough that after you loaded it with text and multimedia, you'd be free to attach it anywhere in a public space. I figured that a device with 32M of storage at a price point of $1.00 USD would be the tipping point (customers wouldn't mind creating a message and 'throwing' it away at this price). Of course, this could become extremely obnoxious as solar-powered devices might squawk for years in public venues. I assumed that some kind of filtering mechanism would be developed to select the signal from the noise.
Tue, 2005-03-22 00:09
This sounds like the next step in the evolution of a project I was loosely involved with back in 2002-3 while I was a student at the University of Central Florida. The long term project was known as "Earth Echoes". The idea of that research project was to discuss a future protocol for broadcasting useful location-specific information to wireless devices. We were kicking around ideas about what type of information people would want. Ideas included the background of historical hotspots in the area, the best restaurants within a few blocks, and directional data. This project was entirely hypothetical as the infrastructure for such a project did not exist.
The short term fruit of this project was an entirely different project called Cultural Byways - http://sfdm.ucf.edu/heritagealliance/byways.html Funded by the Lynx bus system, and with the help of the history center, the Digital Media department at UCF created a database of location specific, cultural/historical video clips to be displayed on the tv screens of the downtown Orlando loops of the Lynx bus system. The buses had just been equipped at the time with computers and GPS receivers. The 1-2 minute videos were stored on each bus' hard drive and triggered when the bus came within a set perimeter of each GPS location.
Wed, 2005-08-17 18:15
GPS is good
And is the right means to tell you about more static local information which fits in central databases. Indeed, it's what you want for your road maps, something you can trust. Wireless broadcast has downsides but the decentralization has upsides, and things will develop that the central planners had no concept of.
Sun, 2005-10-23 06:45
Kyle Hamilton's thoughts on the topic
Why force things to higher-layer protocols when they don't need to be? A DHCPOFFER occurs at the MAC level, and can contain several text fields, including URLs for more information. Get rid of the requirement for a DHCPREQUEST, and anyone who wants more information can get it. [Hell, NETBIOS would be perfect for this, if it didn't involve its own complex set of handshakes.]
What we need is a UDP-like protocol built directly atop MAC... like, say, bootp or dhcp. Why should we worry about TCP/IP until it's necessary?
Sun, 2005-10-23 10:55
The whys of protocols
Mainly if you can look like udp or tcp, a whole lot of software can use you or be easily modified to use you more easily and more directly. However, all datagram protocols are pretty similar in the end, use they mac addresses or UDP addresses and ports.
Thu, 2005-12-15 06:33
It's (almost) been done already by us good old boys, the Ham's...
Do a web search for APRS and you'll see far more can be done too. Trouble is, at the moment we are hampered by the use of low bit rate's at HF and VHF, but we have satelites too!...
Keep coming up with the ideas.
Thu, 2005-12-22 23:03
This is a very cool idea that I'd love to see implemented.
I worked as part of a team to create a (hypothetical) municipal wireless system for New York. In any city with a muni wireless (Philadelphia, San Francisco, London, and others), emergency and other government messages (traffic info, school closings, etc.) could be broadcast over such a network. Even real-time driving directions. For example, in the frame, you add information such as target address, and since the AP knows (approximately) where you are, it can direct you to, at the very least, the next AP.
Streaming music would also be very nice to have. The many free streaming radio stations on the internet would applaud you.
I think that wifi is the perfect platform for this because of its high bitrate, lowering price, and open standard. I programmed my router to run an rc car server. It's mounted on a modified RC car so you can drive it around. A platform like this could... umm... i dunno.. do something very interesting, at the least. A network of open wifis would guarantee control over long distances.
I really would like to see this implemented. A start would be to create an ipkg for OpenWrt ( www.openwrt.org ) so that owners of Linksys and many other routers can begin to implement this. Client software for laptops, PDAs, and Wifi-enabled smart phones would be the next step. The hardware already exists; let's get to implementing it!
With OpenWrt and PDA and laptop readers, this can be implementented, well, now!
P.S. For more on my wificar, see: http://yasha.okshtein.net/wrt54g/ . My email is there, too.
Fri, 2007-09-28 23:50
WIFI broadcast frames
I was just wondering if anyone has done this.
I've been searching the net for a WIFI frame broadcaster and have only run across "rfakeap, a program that emulates IEEE 802.11 access points thanks to wireless raw injection."
It looks like a good start but, what I'd like to do is add GPS to the wifi beacon. Maybe just put another SSID out like
POS?I=MRDVT92;P=38.8659,-77.1087 #The SSID must be no more than 32 bytes but should we stick to that particular frame broadcast?
POS is the key for position report
? is the key separator (like query string)
I is the ID of the device (we have MAC as well?)
P is position in Lat, Lon WGS-84
The first few characters could be registered to provide for consistent data decoders.
Let me know what you think?
Add new comment