| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 ARC Reflector ---
Overall, I agree that the current proposed changes should be incorporated into REVmc and that it will enhance the 802.11 standard to make these changes. So I support this document.
I do however have two questions related to the proposed Figure R-1: 1.
Why are two APs included in the figure? It seems to me that one would be adequate to define where the DS SAP is on the AP. (Though the old diagram did have ellipsis between the two APs and the two
mesh gates to show that numerous APs and mesh gates could be connected to the DS. But, I think this is clear from other architecture diagrams.) 2.
Why is there no mesh STA (non-Mesh Gate STA) in the figure? The figure clearly shows that non-AP STAs do not have DS SAPs, but the same is not shown for mesh STAs. Should we add a mesh STA to the DS
architecture diagram? Also I am concerned that there may be references in the specification outside of sections 3 and 4 that will need to be updated. For example:
1.
in 5.1.5.1 the following text is present: “During reception, a received Data frame goes through processes of possible A-MPDU deaggregation, MPDU header and cyclic redundancy code (CRC) validation, duplicate removal, possible reordering if the block ack mechanism is used, decryption, defragmentation, integrity checking, and replay detection. After replay detection (or defragmentation if security is not used), possible A-MSDU deaggregation, and possible MSDU rate limiting, one or more MSDUs are, delivered to the MAC SAP or to the DS.”
2.
The switching function as described in 5.1.5.3 AP role and 5.1.5.5 Mesh gate role, should probably be updated so that it is a function of the DSAF.
3.
In 8.2.4.1.4 To DS and From DS fields, the meaning of the To DS/From DS values are described: “A Data frame destined for the
DS or being sent by a STA associated with an AP to the Port Access Entity in that AP.”
Given the new DSAF definition it should probably read:
“…. with an AP to the DSAF.” There are probably more places that need to be updated, but I haven’t’ done complete search.
Do people agree that these type of corrections/enhancements should be made? Regards, Joseph From: *** 802.11 Architecture Standing Committee *** [mailto:STDS-802-11-ARC@xxxxxxxx]
On Behalf Of Mark Hamilton --- This message came from the IEEE 802.11 ARC Reflector ---
All, In July, I presented what I think is a final version of the proposal for text changes to make the DS-SAP normative text (primarily by moving Annex R into a new clause, probably clause 7). This proposal is in:
https://mentor.ieee.org/802.11/dcn/15/11-15-0555-04-0arc-normative-ds-sap-proposal.docx.
At the end of the July REVmc session, we left things as (per the minutes), “Would expect to bring to the September and have ARC final review and motion in REVmc”. We ran out of time to consider this in Bangkok, in September. Thus, I am planning to have ARC re-confirm the document at the November meeting in Dallas, and then bring it to REVmc for a motion, also during the Dallas meeting. If anyone has any comments on the document, those would be very welcome – before the Dallas REVmc session and motion, if possible! ;) Thanks. Mark |