A big focus in the 802.11 space this year will likely be on network management: getting access points, switches and clients to communicate and cooperate among themselves well enough that wireless LANs can do a pretty good job of self-tuning and adjusting to dynamic conditions. Such coordination will play a big role in reducing interference, increasing throughput and helping to improve overall Wi-Fi reliability.
A great deal of work has been done in this realm during the past
18 months or so, and all vendors have some kind of real time monitoring and management in their systems. Such features figured large in this week's announcements from Aruba and Trapeze.
For many management tasks, small vendors are ahead. Users are finding that one tool does not do everything and have to patch together incomplete and overlapping products from different vendors.
Most of the network management work has been proprietary to individual vendors, though some have done the work in software or chips, which they will license to Wi-Fi system makers. To date, you generally must use access points from a single vendor in order for the automatic management cooperation among Wi-Fi components to take place.
Standards will appear... eventually
Finally, movement is revving up on the standards front to improve the heterogeneous nature of the situation.
For example, apparently the IEEE has added yet another extension to the 802.11 laundry list, in the form of 802.11v for radio management. The 802.11v group, under the chairmanship of Harry Worstell of AT&T, is still getting underway, but submitted a Project Authorization Request (PAR - Word format) in 2004.
Early reports revive fears of duplication between standards bodies, describing 802.11v as similar in nature to the IETF standards effort already underway to develop a way for different vendors' APs to work together, called Control and Provisioning of Wireless Access Points (CAPWAP - read the CAPWAP charter).
However, 802.11v is said to also include the ability for clients to dynamically reduce and increase their own transmission levels as needed.
Meanwhile, the IETF CAPWAP Working Group has set a hard deadline of February 2005 for reaching the objectives phase of its work, according to the IETF CAPWAP Working Group's Dec. 15 posting.
The group's next goal is to have a Request for Comments (RFC) ready by May 2005. The origins of CAPWAP include an earlier effort called LWAPP - read this article for an explanation of what CAPWAP is hoping to achieve.