Miscellaneous D2.1 issues
Subjects for next LB comments:
Intention:
•	Address issues remaining in draft D2.1 after the current round of Letter Ballot comment resolution.
•	Discuss validity of the subjects addressed.
•	And discuss the recommendations made in this paper.

•	Text changes for the recommendations are not currently provided, but will be included in the next Letter Ballot comments.
•	People are encouraged to reference this paper and include these subjects in their Letter Ballot.
Reassociation Request Frame format:
•	The Field definition has changed, such that “Current_AP_Address has been moved to the end.
–	This does not follow the rules that fixed length fields will be earlier in the frame then the variable length fields.
–	Background is apparently that a reassociation frame is identical to an Association frame, with the difference being in the last field.
•	Recommendation:
–	Change it back such that the general rule is followed that fixed fields come before variable length fields. 
Not all fields are at Word boundaries:
•	It has been a design assumption that fields are alligned to word boundaries.
•	Changes have been made in the last update to affect that, but not all field definitions do follow that.
–	Reason code is only 1 octet.
–	And the variable length fields are not following this rule.
•	Recommendation:
–	Make the Reason code 2 octets.
–	And specify Variable length fields such that they end on Word Boundaries, by specifying a pad Byte with content 0 where needed.
Capability Field issues:
•	Capability Fields are present in:
–	Beacon, Probe, Probe Responce, (Re)Association request and responce frames.
•	ESS bit and an IBSS bit are defined to distinguish between Infrastructure and Ad-Hoc.
–	This assumes that an IBSS is not part of an ESS although it has an ESSID.
–	Change ESS bit into “Infrastructure BSS” bit as before.
–	Infrastructure BSS and IBSS bits have no meaning (should be 0) in all but Beacon, Probe and Probe Response frames.
»	This one seems OK 
»	So in Association and Reassociation (Req+Resp) the bits are 0.
Capability Information Field.
•	CF-Aware only defined in (Re)_Association request frames.
–	This allows the station to make it known to the AP that it is capable to participate in a PCF.
•	Stations can conclude whether a PCF is active when a CF_Parameter_Set field is present in the Beacon or Probe Response.
–	This tells all stations to set their NAV at the TBTT to CFP_Max_Duration.
•	However a station needs to know whether the PCF does indeed provide a polling mechanism.
–	Because the implementation of a PCF for transfering “Down traffic” without a polling list is valid.
–	However this mechanism can be used for all traffic to all stations regardless whether the station is CF_Aware.
Capability Information (cont’d):
•	CF-Polling bit only defined in (RE)-Association Request frames for CF-Aware stations.
–	Stations can request to use the polling mechanism when it is there.
–	However confirmation that the station can depend on the polling mechanism in (RE)-Association Response frames would be usefull.
•	Recommendation:
–	A “Polling_PCF” bit is needed in the “Capability Information” field of an AP, or in a separate field in the CF_Parameter_Set field.
–	Acknowledge CF_Polling mechanism availability in the (RE)-Association Response frames 
Capability Information (Cont’d):
•	How does a Station or AP know whether the other side does support WEP.
–	Currently there is no way to know that, sinse everything in the Beacon will be send in the clear.
–	Furthermore if WEP is being used, but the other side does not support it, it will still be Acked, and the sending station does not get any feedback that the frame gets lost.
–	Furthermore an AP can be configured so that it does not accept any data frames that were not encrypted, to protect the DS.
•	Recommendation:
–	Define a “WEP supported”, and a “WEP mandatory” bit (only setable in AP) in the capability information field, which is set accordingly in at least the Beacon, Probe response, (Re)-Association Request and Response frames.
Synchronisation: 
•	If station is to synchronise to a BSS it needs to copy the TSF Timestamp, the Beacon_Interval.
•	It also needs to be able to determine when the next TBTT occurs, and all subsequent TBTTs (by adding Beacon_Period every Beacon time).
•	Currently a station needs to calculate TSF_Time modulo (Beacon_Period), and calculate the remainder.
–	This can be a rather complex function that needs to be performed on the full 64 bit TSF at every synchronisation event.
•	This can be prevented by adding a “Next TBTT” parameter in the Beacon and Probe response frames.
–	This can be a 16 bit field which represent bit 11 till 26 of the TSF timer.
–	Because the TBTT will be on a Kusec boundary.