Doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 1 Advanced Event Request and...
22
Jiyoung et al. Slide 1 doc.: IEEE 802.11-07/2155r0 Submission May 2007 Advanced Event Request and Event Advanced Event Request and Event Report 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 < http:// ieee802.org/guides/bylaws/sb-bylaws.pdf >, 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 <[email protected] > 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 Date: 2007-7-17 Name Compay Address Phone E-mail Jiyoung Huh LG Electronics [email protected]
-
Upload
carmel-simon -
Category
Documents
-
view
217 -
download
0
Transcript of Doc.: IEEE 802.11-07/2155r0 Submission May 2007 Jiyoung et al.Slide 1 Advanced Event Request and...
Jiyoung et al.Slide 1
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Advanced Event Request and Event ReportAdvanced 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 <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, 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 <[email protected]> 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 <[email protected]>.
Date: 2007-7-17
Name Compay Address Phone E-mail
Jiyoung Huh LG Electronics [email protected]
Jiyoung et al.Slide 2
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
AbstractAbstractThis 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.
Jiyoung et al.Slide 3
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Existing Event Request & Report MechanismExisting 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
Jiyoung et al.Slide 4
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Existing Event Report FormatExisting Event Report Format
Source BSSID
Target BSSID
Transition Time
Transition Reason
Transition Result
Source RCPI
Source RSNI
Target RCPI
Target RSNI
Element ID Length Event Token Event Type StatusEvent
TimestampEvent Report
Target BSSID
Authentication Type
EAP Method
RSNA Result
RSN Element
Peer STA Address
Channel Number
Regulatory Class
STA Tx Power
Connection Time
Syslog Msg
Octets: 1 1 1 1 1 8 variable
Octets: 6 6 2 1 2 1 1 1 1
Transition Event
Octets: 6 4 1 1 variable
RSNA Event
Octets: 6 1 1 1 2
Peer-to-Peer Link Event
Octets: variable
Syslog Event
Event Report frame
Event Report Element
Jiyoung et al.Slide 5
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Existing Event Request & Report MechanismExisting 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+2 32 1 0 0 100
Transition Time
Target RSNI
Target RCPI
Source RSNI
Source RCPI
Transition Result
Transition Reason
Target BSSID
Source BSSID
Octets: 6 6 2 1 2 1 1 1 1
X+2 32 1 0 0 200
: Redundant Part (5 Octets)
Jiyoung et al.Slide 6
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Existing Event Request & Report MechanismExisting 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: 6 6 2 1 2 1 1 1 1
X+2 32 1 0 0 100 X+2 32 1 0 0 200
…
3 Event Report Elements
: Redundant Part (5 Octets)
Jiyoung et al.Slide 7
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Suggestion 1Suggestion 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.
Jiyoung et al.Slide 8
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Proposing Event Report Element FormatProposing 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
LengthEvent Token
Event Type
StatusEvent Report
Octets: 1 1 1 1 1 variable
Transition Event
RSNA Event
Peer-to-Peer Link Event
Syslog Event
Event Count (n)
Event Timestam
p
Source BSSID
Target BSSID
Transition Time
Transition
Reason
Transition Result
Source RCPI
Source RSNI
Target RCPI
Target RSNI
Event Count
(n)
Length
Event Timestam
p
Target BSSID
Authentication Type
EAP Method
RSNA Result
RSN Element
Event Count
(n)
Event Timesta
mp
Peer STA Address
Channel Number
Regulatory Class
STA Tx Power
Connection Time
Event Count
(n)Length
Event Timestamp
Syslog Msg
n repetition
n repetition
n repetition
n repetition
Octets: 6 6 2 1 2 1 1 1 11 8
Octets: 8 6 4 1 1 variable1 1
Octets: 8 variable1 1
Octets: 6 1 1 1 21 8
Jiyoung et al.Slide 9
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Comparison of two schemesComparison 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.
1 2 3 4 5
Old New Old New Old New Old New Old New
Transition 34 35 68 64 102 93 136 122 170 151
RSNA25
+var27 + var
50 + 2var
s
48 + 2var
s
75 + 3var
s
69 + 3var
s
100+4vars
90 + 4var
s
125+5vars
111+5vars
Peer-to-Peer
24 25 48 44 72 63 96 82 120 101
Syslog13
+var15 + var
26 + 2var
s
24 + 2var
s
39 + 3var
s
33 + 3var
s
52 + 4var
s
42 + 4var
s
65 + 5var
s
51 + 5var
s
Gain -1 ~ -2 +2 ~ +4 +6 ~ +9 +10 ~ +14 +14 ~ +19
Event
Entry #
Unit: Octet
Jiyoung et al.Slide 10
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Existing Event Request & Report MechanismExisting 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.
Jiyoung et al.Slide 11
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Suggestion 2Suggestion 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.
Jiyoung et al.Slide 12
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Proposed Scheme 1Proposed 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
Length
Event Token
Event Type
Event Count
Event Request
Octets: 1 1 1 1 variable1
Jiyoung et al.Slide 13
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Proposed Scheme 2Proposed Scheme 2
Element ID
Length
Event Token
Event Type
Event Request
Octets: 1 1 1 1 variable
Sub-element
IDLength
Event Count
Frequent Transition Count
Threshold
Time Interval
Octets: 1 1 1 21
Frequent Transition sub-element
Sub-element ID
Length Event Count Target BSSIDOctets: 1 1 1 6
Target BSSID Transition sub-element
Sub-element ID
Length Event Count Source BSSIDOctets: 1 1 1 6
Source BSSID Transition sub-element
Sub-element ID Length Event CountTransition Time
ThresholdOctets: 1 1 1 2
Transition Time sub-element
Sub-element ID
Length Event Count Match ValueOctets: 1 1 1 1
Transition Result sub-element
Jiyoung et al.Slide 14
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Existing Event Request & Report MechanismExisting 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.
STA2
STA1
STA3
1. Event Request
2. Event Request3. Event Report
This STA can’t
receive the report
Jiyoung et al.Slide 15
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Suggestion 3Suggestion 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.
Jiyoung et al.Slide 16
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Existing Event Request & Report MechanismExisting 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.
STA2STA1
Event Request (Dialog Token: 1) including2 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) including2 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.
Jiyoung et al.Slide 17
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Suggestion 4Suggestion 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.
Jiyoung et al.Slide 18
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
STA APEvent 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 4Examples for Suggestion 4
Jiyoung et al.Slide 19
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Straw Poll 1Straw Poll 1
• Do you support the use of the proposed Event Report Element format in the first suggestion?
– YES: – No:– Abstain:
Jiyoung et al.Slide 20
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Straw Poll 2Straw 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
Jiyoung et al.Slide 21
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Straw Poll 3Straw Poll 3
• Do you support the use of the 3rd suggestion?
– YES: – No:– Abstain:
Jiyoung et al.Slide 22
doc.: IEEE 802.11-07/2155r0
Submission
May 2007
Straw Poll 4Straw Poll 4
• Do you support the use of the 4rd suggestion?
– YES: – No:– Abstain:
![Engineering Notes - aancl.snu.ac.kraancl.snu.ac.kr/aancl/research/International Journal/[2008] Jiyoung... · the Korean BERP (British Experimental Rotor Program) blade (KBERP) and](https://static.fdocuments.net/doc/165x107/5b33445a7f8b9aa0238ce71d/engineering-notes-aanclsnuac-journal2008-jiyoung-the-korean-berp.jpg)
