1. doc.: IEEE 802.11-08/1268 r1 Submission November 2008 Ding Zhiming, HuaweiSlide 1 Amendment for emergency alert system notification Date: 2008-11-09 Authors:

2. doc.: IEEE 802.11-08/1268 r1 Submission November 2008 Ding Zhiming, HuaweiSlide 2 Background (CID 4186) Currently within 802.11u draft D4.0, the AP uses a EASN bit to indicate whether or not a higher layer Emergency Alert Message (EAS) is available at the AP for download. The value 1 of EASN bit indicates that a higher layer EAS is in operation, which means that at least one emergency alert message is available. Value 0 indicates that no higher layer EAS is available which means that there is no emergency alert message. When a second alert becomes available, the EASN bit is changed from 1 to 0 and for 1 minute; then changed to 1 so that the non-AP STA will be alerted to re-fetch the information of the new emergency alert.

3. doc.: IEEE 802.11-08/1268 r1 Submission November 2008 Ding Zhiming, HuaweiSlide 3 Problems According to this current EASN mechanism described in 11u draft 4.0, when a second emergency occurs, the EASN bit will change from 1 to 0 and last for 1 minute and then change to 1 indicating that the new emergency becomes available. Thus, when a new emergency takes place, the alert has to be received after 1 minute or longer. If the emergency is about a severe earthquake, then more people may be injured for this 1 minute. On other hand, if a non-AP STA misses the beacons during the period of EASN bit is changed to 0 from 1, it will still deem that no new alert message becomes available. So the mechanism is not very reliable.

4. doc.: IEEE 802.11-08/1268 r1 Submission November 2008 Ding Zhiming, HuaweiSlide 4 Solution As a solution, we suggest ： Use the EASN field to indicate if any emergencies exist, and add another optional field, called EICI (Emergency Information Change Indication) Octet, to indicate the status and the change of the emergencies. If there is no emergency, EASN is set to 0, and the EICI field does not exist; if there is an emergency(s), EASN is set to 1, and the EICI field appears and its value changes upon the change of the emergencies info. See the following figure: How the EICI field represents the change of emergencies status is further specified in next slides:

5. doc.: IEEE 802.11-08/1268 r1 Submission November 2008 Ding Zhiming, HuaweiSlide 5 Solution – EICI Field Example The first emergency occurs: EASN set to 1; EICI appears; EICI set to 1; Then, the value of EICI increment by 1 upon: a new emergency occurs; or an existing emergency disappears. If all emergencies are gone: the EICI field disappear If a new emergency occurs after all previous emergencies are gone: EICI field appears and its value is increment by 1 upon the previous value After 255 emergency status changes has been counted: the EICI restores to 1. EASNEICIDescription 0not existno emergency 111st emergency occurs 122nd emergency occurs 131st emergency disappears 0not existall emergencies disappear 143rd emergency occurs 1… any emergency status change (eg.new emergency occurs or an existing emergency disappears) 1255EICI restores to 1

6. doc.: IEEE 802.11-08/1268 r1 Submission November 2008 Ding Zhiming, HuaweiSlide 6 Further consideration Within the current mechanism, the non-AP STA doesn’t know the difference between no current alert message as opposed to never receiving an alert, when the EASN bit is 0. To give more information about the available services to the user, an additional field may be added into the Interworking Element. The new field is one bit length to indicate whether the network supports EASN mechanism: 0 for no support for EASN ; and 1 for supporting EASN. The original EASN bit (B6) may be used for this intent, and one of the optional extra octet may be used as original EASN to indicate whether any emergency alert exists or not, and the remaining bits of the octet are used as EICI described in the previous slide. The whole format of the new Interworking Element is showed as following figure.

7. doc.: IEEE 802.11-08/1268 r1 Submission November 2008 Ding Zhiming, HuaweiSlide 7 Motion 1 Move to accept the EASN solution described in submission 11-08- 1274-00-000u-Normative_Text_for_Amendment_for_EASN.doc and request the IEEE 802.11u editor to incorporate it into the IEEE 802.11u draft document. Mover: Seconder: Result: –Yes –No –Abstain

8. doc.: IEEE 802.11-08/1268 r1 Submission November 2008 Ding Zhiming, HuaweiSlide 8 Motion 2 Move to add a field into the Interworking Element to indicate whether a network supports EASN described in submission 11-08-1275-00- 000u-Normative_Text_for_Amendment_for_EASN.doc and request the IEEE 802.11u editor to incorporate it into the IEEE 802.11u draft document. Mover: Seconder: Result: –Yes –No –Abstain

9. doc.: IEEE 802.11-08/1268 r1 Submission November 2008 Ding Zhiming, HuaweiSlide 9 END