1. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 1 Advanced Event Request and Event Report 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: 2007-7-17 NameCompayAddressPhoneE-mail Jiyoung HuhLG Electronicsjyhuh@lge.com

2. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 2 Abstract This document indicates the concerns or problems of the Event Request and Report mechanism. And we propose 4 suggestions that solve the problems of the existing scheme and make the current Event Request and Report mechanism more efficiently.

3. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 3 Existing Event Request & Report Mechanism Event Request frame Event Request Element Event Type Definitions for Event Requests/Reports STA2STA1 Event Request frame including 1 Event Request Element (Event Type: 0, Event Request: Target BSSID sub- element & Source BSSID sub-element) Example Event report frame including Event Request Elements which meet the condition. That is, the Event Report frame shall include zero or more Event Report entries for 1 Event Request Element

4. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 4 Existing Event Report Format Source BSSID Target BSSID Transition Time Transition Reason Transition Result Source RCPI Source RSNI Target RCPI Target RSNI Element IDLengthEvent TokenEvent TypeStatusEvent TimestampEvent Report Target BSSIDAuthentication TypeEAP MethodRSNA ResultRSN Element Peer STA Address Channel Number Regulatory Class STA Tx Power Connection Time Syslog Msg Octets:111118variable Octets:662121111 Transition Event Octets:6411variable RSNA Event Octets:61112 Peer-to-Peer Link Event Octets:variable Syslog Event Event Report frame Event Report Element

5. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 5 Existing Event Request & Report Mechanism Example 1 –STA1 sends an Event Request frame including 1 Event Request Element. Element ID: x+1, Length: 10, Event Token: 1, Event Type: 0(Transition Event) Event Request field – Target BSSID: 1 –STA2 receives the Event Request frame and finds the two matched Event Report entries. –STA2 sends an Event Report frame including the following 2 Event Report Elements. (5 Octet Overhead) X+232 1 0 0100 Transition Time Target RSNI Target RCPI Source RSNI Source RCPI Transition Result Transition Reason Target BSSID Source BSSID Octets:662121111 X+232 1 0 0200 : Redundant Part (5 Octets)

6. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 6 Existing Event Request & Report Mechanism Example 2 –STA1 sends an Event Request frame including an Event Request Element without Event Request field. Element ID: x+1, Length: 10, Event Token: 1, Event Type: 0(Transition Event) –STA2 receives the Event Request frame and sends all available Event Report Element. (Assume that STA2 has 5 available Event Report Element) –This case has 20 octets overhead. Transition Time Target RSNI Target RCPI Source RSNI Source RCPI Transition Result Transition Reason Target BSSID Source BSSID Octets:662121111 X+232 1 0 0100 X+232 1 0 0200 … 3 Event Report Elements : Redundant Part (5 Octets)

7. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 7 Suggestion 1 This proposal allows an Event Report Element to include zero or more Event Report Entries by adding Event Count field and, if necessary, Event Timestamp and Event Length in the Event Report Entry.

8. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 8 Proposing Event Report Element Format Event Timestamp field is included in Event Report entry instead of in Event Report Element. Add Event Count field in Event Report entry to inform the number of Event Report field. Length field in RSNA & Syslog Event Report entry because they include variable length field. Element ID Length Event Token Event Type Status Event Report Octets:11111variable Transition Event RSNA Event Peer-to-Peer Link Event Syslog Event Event Count (n) Event Timestamp Source BSSID Target BSSID Transition Time Transition Reason Transition Result Source RCPI Source RSNI Target RCPI Target RSNI Event Count (n) Length Event Timestamp Target BSSID Authentication Type EAP Method RSNA Result RSN Element Event Count (n) Event Timestamp Peer STA Address Channel Number Regulatory Class STA Tx Power Connection Time Event Count (n) Length Event Timestamp Syslog Msg n repetition Octets:66212111118 86411variable11 Octets:8variable11 Octets:6111218

9. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 9 Comparison of two schemes A STA supporting all events except for Syslog shall record up to and including the last 5 events occurring for each event since the STA associated to the ESS. Therefore, the reporting frame can include up to maximum 5 Event Report Entries for one Event Request Element. 12345 OldNewOldNewOldNewOldNewOldNew Transition3435686410293136122170151 RSNA 25 +var 27 + var 50 + 2vars 48 + 2vars 75 + 3vars 69 + 3vars 100+ 4vars 90 + 4vars 125+ 5vars 111+ 5vars Peer-to-Peer2425484472639682120101 Syslog 13 +var 15 + var 26 + 2vars 24 + 2vars 39 + 3vars 33 + 3vars 52 + 4vars 42 + 4vars 65 + 5vars 51 + 5vars Gain-1 ~ -2+2 ~ +4+6 ~ +9+10 ~ +14+14 ~ +19 Event Entry # Unit: Octet

10. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 10 Existing Event Request & Report Mechanism The requested STA shall send all available Event Report Elements which meet condition. But, the requesting STA may need only some of them.

11. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 11 Suggestion 2 A requesting STA informs the number of receiving Event Report Entries by including the Event Count in the Event Request frame. If a requested STA has Event Report Entries less than requested, it can send just all available Event Report Entries it has. If a requesting STA set the Event Count to zero, the requested STA sends all available Event Report Entries which meet condition.

12. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 12 Proposed Scheme 1 The Event Request Element includes one “Event Count” field. The “Event Count” field indicates total number of Event Report Entries for the Event Type. Therefore, the number of Event Report Entries for each sub-element is not specified. Element ID LengthEvent TokenEvent Type Event Count Event Request Octets:1 111variable 1

13. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 13 Proposed Scheme 2 Element IDLengthEvent TokenEvent TypeEvent Request Octets:1 111variable Sub- element ID Length Event Count Frequent Transition Count Threshold Time Interval Octets:1 1121 Frequent Transition sub-element Sub-element IDLengthEvent CountTarget BSSID Octets:1 11 6 Target BSSID Transition sub-element Sub-element IDLengthEvent CountSource BSSID Octets:1 11 6 Source BSSID Transition sub-element Sub-element IDLengthEvent CountTransition Time Threshold Octets:1 11 2 Transition Time sub-element Sub-element IDLengthEvent CountMatch Value Octets:1 11 1 Transition Result sub-element

14. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 14 Existing Event Request & Report Mechanism Only a single Event Request frame shall be outstanding at a given STA at any time. And a STA shall respond only to the most recent request when it receives a sub-sequent Event Request frame with a different Dialog Token before completing a previous request. STA2STA1STA3 1. Event Request 2. Event Request 3. Event Report This STA can’t receive the report

15. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 15 Suggestion 3 A STA shall respond to each request from different STAs regardless of the dialog token. Therefore, a STA shall respond only to the most recent request when it receives a sub-sequent Event Request frame with a different Dialog Token before completing a previous request from the requesting STA.

16. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 16 Existing Event Request & Report Mechanism The current draft allows a STA to respond only to the most recent request even though it receives several Event Request frames with a different Dialog Token. The current draft has no mechanism which adds and updates (or modifies) only parts of Event Request Elements. STA2 STA1 Event Request (Dialog Token: 1) including 2 Event Request Elements (Event Token: 1,2, Event Type: 0,1) In this case, the STA1 shall wait the report for previous Event Request The STA1 wants to send Event Request Element for new Event Type (Event Type: 2). Event Request (Dialog Token: 2) including 2 Event Request Elements (Event Token: 1,2, Event Type: 0,1) In this case, the STA1 shall retransmit the request with all Event Request Elements like previous Event Request, or retransmit the request with the modified Event Request Element just after receiving the report for the previous request. The STA1 wants to modify Event Request Element for only 0 Event Token.

17. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 17 Suggestion 4 This suggestion keeps the existing draft, which a STA shall respond only to the most recent request when it receives several Event Request frames with a different Dialog Token The same Dialog Token and Event Token is used for these cases, such as addition and modification. –2 Event Request frame with same Dialog Token is considered as same request. –If a Event Request Element in a new Event Request frame has the same Event Token as one in a previous Event Request frame, a requested STA shall respond only for the Event Request Element in new Event Request frame.

18. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 18 STA AP Event Request (Dialog Token: 3) including 3 Event Request Elements (Event Token: 6,7,8, Event Type: 0,1,2) Processing Request (Dialog Token:3) Event Request (Dialog Token: 3) including 2 Event Request Elements (Event Token: 7,8, Event Type: 1,2) Event Report (Dialog Token: 3) including 2 Event Report Elements (Event Token: 6,7,8, Event Type: 0,1,2) Event Request (Dialog Token: 4) including 3 Event Request Elements (Event Token: 9,10,11, Event Type: 0,1,2) Processing Request (Dialog Token:4) Event Request (Dialog Token: 4) including 2 Event Request Elements (Event Token: 12, Event Type: 3) Event Report (Dialog Token: 4) including 2 Event Report Elements (Event Token: 9,10,11,12, Event Type: 0,1,2,3) Receiving the Event Request with same Dialog Token, the STA shall respond to all request. If there are new Event Request Elements with same Event Token as previous one, the STA shall ignore the previous one and report the recent one (It can be used to update the previous Event Request Element). And If there are new Event Request Elements with different Event Token as previous one, the STA shall report all Event Request Elements (It can be used to add new Event Request Element). Examples for Suggestion 4

19. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 19 Straw Poll 1 Do you support the use of the proposed Event Report Element format in the first suggestion? –YES: –No: –Abstain:

20. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 20 Straw Poll 2 Do you support the use of the proposed Event Request format in the second suggestion? –YES: –No: –Abstain: If supporting, which scheme do you prefer? –First Scheme: –Second Scheme: –Abstain

21. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 21 Straw Poll 3 Do you support the use of the 3rd suggestion? –YES: –No: –Abstain:

22. doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 22 Straw Poll 4 Do you support the use of the 4rd suggestion? –YES: –No: –Abstain: