As part of my COMP414 study at uni, and for nzwired, I'm working on a time-slot system for 802.11 networks, which I've called ChatStick. It's currently in development, but if you're interested, get in touch and I'll tell you all about it!
Basically it's a solution to defeat hidden node problems and enforce fair sharing of bandwidth in point-to-multipoint configurations where every node is a "hidden node" but they can all see a common access point. Unlike some systems, like Frottle, it isn't a centralised system with a coordinating node. It's a distributed system, and uses broadcast Ethernet frames to tunnel data in a point-to-multipoint way. The point of broadcast was initially to prevent MAC-level acknowledgements, which are a feature of 802.11, but slow things down when you're trying to share resources on a timeslot basis like I'm doing. 802.11's Point Coordination Function (PCF) does something similar by definining contention-free periods where clients are polled for data by the access point, but it's not commonly available in current implementations. The other point of broadcast is so each client can listen in on the data passing (most 802.11 cards cannot enter promiscuous mode for security reasons) which allows them to adjust their timeslot based on observed traffic from other nodes, a key feature of ChatStick.
Basically, there are two types of service: Bulk data transfer, and real-time applications like VoIP. VoIP favours short frames that are frequent, whereas bulk transfer is fine with long packets and high latency. By flagging ethernet frames with 802.1Q tags to differentiate them, ChatStick knows to expedite short frames. When other stations notice these short frames tagged as such, they will reduce the amount of data (basically shorten their timeslot) so that on average the timeslots will pass around the ring faster and observed latency of the transmitting/receiving station will improve.
As the name implies, ChatStick uses a kind of "talking stick" system to arbitrate access to the medium. Instead of central contol, each station holds the stick for a certain amount of time, which it self-determines based on the load it's observing on the network. Each node has a next-in-line MAC address to pass the stick to when it's finished. Special Ethernet control frames are used to pass the stick around at the end of each transmission. Of course the stick may get lost if the next-in-line node goes down, which ChatStick can't really deal with. A trigger signal needs to pass the stick to the first node when the network is first brought up. Stick passing is reliable, with an acknowledgement sytem.
That's about it. It's not nearly finished yet, currently exists as a set of C programs that use the Linux tun/tap driver to create a virtual ethertap interface in userspace, and proxies data between that and the wireless interface. It was designed from the ground up to run on the Linksys WRT54G embedded Linux access point, so is compiled to run on MIPS, uClibc and kernel 2.4. It also runs on x86 kernel 2.6, tested on a real Ethernet network.
If you like, you can read my research paper that I wrote for COMP414 on hidden node issues, and an introduction to the ChatStick concepts.
If this sounds interesting to you, please get in touch. See my contact page (link up the top) for my details.
