1. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile The management requirement for embedded remote reboot Date: 2008-07-14 Authors : 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.ok-brit.compatcom@ieee.org

2. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Topics Background Problem Proposal

3. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Background China Mobile has deployed amounts of APs in the hot spots mainly covering those important business/entertainment places. –Including airports, railway stations, business plazas, and coliseums For example, now we have amounts of APs installed in the Olympic Park to fulfill the potentially huge requirements for wireless high-speed surfing on internet during the 2008 Olympic Games. From network deployment and maintenance point of view, it is very important to keep each AP always in a good state.

4. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Problem Most of the places with APs installed are often hard to get close to without professional facilities, or special permissions. –such as tackle, or administrative license Meanwhile, the experiences tell us that the most efficient way to recovery a bad AP is to hard reboot it with off-on the power. –Rather than to know how to deal with why When the number of APs is large enough, it is very ineffective to go and manually reboot the bad APs one by one. –which is often limited by facilities and licenses yet

5. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Problem For example, some of APs in the Olympic Park are on the roof of coliseums. Once an AP breaks down for some unexpected causes, it is usually impossible to deal with it in time.

6. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Proposal Alternative Solution at present Proposed Solution –Preferred Solution –Proposed Solution

7. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Alternative Solution at present Currently, we have adopted a kind of power switch controller, which has an Ethernet port. The power on-off controller is inserted between the power and the AP. Once an AP doesn't work well enough, we will send a command to the corresponded power on-off controller and hard reboot the AP More than half of AP problems can be resolved in this way. It is efficient and cost effective. Current Solution: external power switch controller

8. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Proposed Solution Preferred Solution –Remote hard reboot function can be built into AP directly. Proposed Solution –Different architectures shall have different demands.

9. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Preferred Solution In this solution, a power switch module is embedded into AP, which can listen to the commands via a certain network protocol, such as Telnet / SSL. In this way, the maintenance costs will be reduced. More importantly, it enables more stable services and more controllable networks. Preferred solution: built-in remote power switch controller

10. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Proposed Solution However, in reality, there are four possible WLAN architectures: –unified AP + centralized AC, –unified AP + decentralized AC, –stand-alone AP + centralized AC, –and stand-alone AP + decentralized AC. Different architectures shall have different demands.

11. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Proposed Solution Unified AP has simple hardware structure and protocol stack compared with stand-alone AP. All products of unified AP support (passive / active) soft reboot. –Except for certain extreme scenarios, soft reboot can resolve most of the performance problems encountered by AP.

12. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Proposed Solution Most decentralized ACs are far away from network operation & maintenance centre too. –It is necessary for decentralized AC to support remote reboot Actually, the software system and protocol stack in AC are either very simple or much more complex. –so hard reboot is a better choice compared with soft reboot for some hardware mistakes recovery. Active reboot is useful for AP & AC to recovery themselves beforehand, besides remote reboot (a kind of passive reboot), –if they can find their own serious problems in time.

13. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Proposed Solution A recommended summarization of reboot functions for AP & AC Centralized ACDecentralized AC Stand-alone AP Unified AP Stand-alone AP Unified APAC Active hard reboot MOMOM Remote hard reboot MOMOM Active soft reboot MMMMO Remote soft reboot MMMMO

14. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Proposed Solution Before any kind of reboot happens, APs, whose AC will be rebooted, shall send some specific frame to inform all the connected stations to re-associate with other possible APs, so that the service continuity can be guaranteed. Informing stations before rebooted

15. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Proposed Solutions Discussion on alternative implementations of remote hard /soft reboot –Direct Command Control through Telnet / SSL –Periodical Auto Reboot Set

16. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Direct Command Control through Telenet / SSL A standard command format is suggested as : –rmreboot –m h|s [–t time] – “m” means the type of reboot, h is hard reboot and s is soft reboo –“t” means the seconds, after which the device will be rebooted. Once NMS draws a conclusion that some AP / AC is not in a good state, it can directly send the command to them for rebooting.

17. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Periodical Auto Reboot Set we need five new MIB objects as listed in the following table. NameTypeDescription IsRemoteRebootO n BooleanWhether to use remote reboot function or not. True means “ to use ” ; False means “ not to use ”. Reboot MannerInteger1 is hard reboot, 2 is soft reboot, and 3 is reboot whatever soft reboot or hard reboot. IdleTimeDurationString To show the idle time duration of AP. Format is “ hhhh ”. The first two “ h ” means the start hour and the last two means the end hour. For example, 22:00-6:00 is always the idle time of business plaza. Then, IdleTimeDuration= “ 2206 ”. PeriodRemoteRebo ot IntegerThe period of power off-on since the last reboot. Unit: day. ThroughputThresh old IntegerOnly if the current throughput of AP is lower than ThroughputThreshold, the power of AP can be shut down. Unit: M.

18. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Periodical Auto Reboot Set Once an AP/AC has been running for a period, then it will check the throughputs of itself frequently at the idle time. The AP/AC will (hard / soft) reboot automatically, when the throughput of AP/AC is lower than a specified value. –Periods here is approximate and need further evaluation.

19. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Straw Poll #1 Do you think it meaningful to add the embedded reboot and related notification parameters to keep the network recovery more quickly? - Yes - No - Don ’ t know

20. doc.: IEEE 802.11-08/0788r1 Submission July 2008 Ruijun Feng, China Mobile Straw Poll #2 If you are interested in this feature, which way do you prefer to support? - Direct Command Control through Telnet/SSL - Periodical Auto Reboot Set - None of them