1. doc.: IEEE 802.11-yy/xxxxr0 Submission May 2005 John Klein, Symbol TechnologiesSlide 1 Firmware Updates Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-May-17 Authors:

2. doc.: IEEE 802.11-yy/xxxxr0 Submission May 2005 John Klein, Symbol TechnologiesSlide 2 Abstract Ideas for the Firmware upgrade requirements in TGv.

3. doc.: IEEE 802.11-yy/xxxxr0 Submission May 2005 John Klein, Symbol TechnologiesSlide 3 Contents Purpose / Motivation General Requirements Overview Client STA scenarios Infrastructure scenarios Possible Implementation

4. doc.: IEEE 802.11-yy/xxxxr0 Submission May 2005 John Klein, Symbol TechnologiesSlide 4 Purpose / Motivation As 802.11 continues to mature, new services and features continue to be deployed in the MAC. Frequent upgrades require that devices be upgraded with new firmware from the OEM vendor to enable new services or fix bugs. Ensuring the latest FW deployments in the enterprise WLAN devices helps the IT Administrator keep tight control of the network. Few vendors are provide firmware updates over the air today and automatically upgrade devices easily and securely. Proliferation of devices from many OEM vendors makes manually upgrading firmware to 802.11 devices difficult and time consuming. The logistics quickly become unmanageable for large enterprise networks. Automating firmware upgrades over a secure wireless interface eliminates the manual hassle factor and saves time and money for the enterprise IT department.

5. doc.: IEEE 802.11-yy/xxxxr0 Submission May 2005 John Klein, Symbol TechnologiesSlide 5 Client Scenario IT Department has 10K clients on campus representing 12 different 802.11 hardware vendors and 36 different platforms. They have new firmware for 6 of their HW platforms representing 2300 client devices they need to upgrade. They want to distribute the new FW to the client devices with a minimum of disruption to the overall network and to the users that are affected. The IT department publishes the FW images on an internal server and issues policies for the wireless network that informs client devices that the FW is available and allows the client devices to download the FW at non-peak periods and locations around campus for the first 3 days. After the first 3 days or after 75% of all devices have been updated, the FW can be downloaded at anytime and from any location. Per the policy, devices are directed to upgrade the firmware in the actual device after the next system boot to avoid service disruption. Devices that refuse to accept the FW directive are logged for notification and manual upgrade.

6. doc.: IEEE 802.11-yy/xxxxr0 Submission May 2005 John Klein, Symbol TechnologiesSlide 6 Infrastructure Scenario IT Department has 2000 APs spread around campus representing 3 different HW vendors. Some are stand alone (FAT) APs from one vendor, and some systems are connected to Wireless Switching (WS) Infrastructures from two different vendors. All APs or WSs are (as well as the clients) managed using a TGv compatible NMS system over the campus wired infrastructure. They have new FW to upgrade one of the WS systems as well as the APs connected to those WSs. In addition, they have FW for the Stand Alone APs. The IT department publishes the FW images on an internal server and issues policies for the wireless network that informs AP and WS devices that the FW is available and allows the infrastructure devices to download the FW immediately. Per the policy, devices are directed to upgrade the firmware in the actual devices at a pre-determined late-night schedule to minimize service disruption. Devices that refuse to accept the FW directive are logged for manual inspection.

7. doc.: IEEE 802.11-yy/xxxxr0 Submission May 2005 John Klein, Symbol TechnologiesSlide 7 General Requirements Overview Must operate over the air or over the wire Must be secure –Any TGv frames used must be secure to ensure the management entity sending the TGv frame is authentic. Must be deniable by the recipient –Since devices visit many different networks, the recipient must be able to refuse FW from say… Starbucks while accepting FW from the employer’s IT department. Must be reliable. Can’t render device unusable. –Must preserve current network settings (profiles) such that the device can return to normal operation the network once the FW has been upgraded. Must be compatible with CAPWAP with regard to WS and APs connected to WS infrastructures.

8. doc.: IEEE 802.11-yy/xxxxr0 Submission May 2005 John Klein, Symbol TechnologiesSlide 8 One Possible Suggestion TGv Firmware Upgrade Management Message –An L2 message from a TGv management station that alerts upper layer software that a firmware upgrade for the device is available. –Provides information and policies so the 802.11 device or upper layer application can locate and download the firmware image for the device. –Might include server IP/Name, protocol(s) to use, required security credentials, for higher level app to obtain and download the firmware. –Could be a location or time based service. (I.e. only upgrade devices that are associated to the APs in the control room, only after 6PM) –Does not specify the how the firmware image is programmed into the 802.11 OEM device itself. Beyond scope of TGv.

9. doc.: IEEE 802.11-yy/xxxxr0 Submission May 2005 John Klein, Symbol TechnologiesSlide 9 Another Possible Suggestion TGv Firmware Upgrade image download –An L2 protocol built into the 802.11 MAC for downloading the actual firmware image to the targeted device. –Low level packet TLV w/ packet ids and ack. –Does not require that the target device have any upper layer network services over 802.11 (i.e. UDP/IP services) –Does not require an “Agent” utility on any device. –Does not specify the how the firmware image is programmed into the 802.11 OEM device itself. Beyond scope of TGv.

10. doc.: IEEE 802.11-yy/xxxxr0 Submission May 2005 John Klein, Symbol TechnologiesSlide 10 Questions?