1 / 16

General ad hoc- LB115- Comment Resolutions – Jan 08

Name. Company. Address. Phone. email. bkraemer@. marvell. .com. Bruce Kraemer. Marvell. +1. -. 321. -. 4. 27. -. 4098. General ad hoc- LB115- Comment Resolutions – Jan 08. Authors:. Date: 2008-Jan-10. 5488 Marvell Lane Santa Clara, CA 95054. CID 5840. Discussion

preston-puckett
Download Presentation

General ad hoc- LB115- Comment Resolutions – Jan 08

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Name Company Address Phone email bkraemer@ marvell .com Bruce Kraemer Marvell +1 - 321 - 4 27 - 4098 General ad hoc- LB115- Comment Resolutions – Jan 08 Authors: Date: 2008-Jan-10 5488 Marvell LaneSanta Clara, CA 95054 Bruce Kraemer, Marvell

  2. CID 5840 • Discussion • The TGn draft is only an amendment to the baseline standard 802.11-2007. The requested explanation is already included in the baseline as indicated below: • Annex A • … • A.3 Instructions for completing the PICS proforma • … • A.3.4 Conditional status • The PICS proforma contains a number of conditional items. These are items for which both the applicability of the item itself, and its status if it does apply, mandatory or optional, are dependent upon whether or not certain other items are supported. • Where a group of items is subject to the same condition for applicability, a separate preliminary question about the condition appears at the head of the group, with an instruction to skip to a later point in the questionnaire if the N/A answer is selected. Otherwise, individual conditional items are indicated by a conditional symbol in the Status column. • A conditional symbol is of the form “<pred>:<S>”, where “<pred>” is a predicate as described below, and “<S>” is one of the status symbols M or O. • If the value of the predicate is true, the conditional item is applicable, and its status is given by S: the support column is to be completed in the usual way. Otherwise, the conditional item is not relevant and the N/A answer is to be marked. • A predicate is one of the following: • An item-reference for an item in the PICS proforma: the value of the predicate is true if the item is marked as supported, and is false otherwise. • b) A boolean expression constructed by combining item-references using the boolean operator OR: the value of the predicate is true if one or more of the items is marked as supported, and is false otherwise. • Each item referenced in a predicate, or in a preliminary question for grouped conditional items, is indicated by an asterisk in the Item column. Bruce Kraemer, Marvell

  3. CID 5840 Proposed resolution: • Reject. • The explanation requested is, in fact, already in the baseline standard. Adding additional explanatory text to the draft would only require its removal later in the process. Bruce Kraemer, Marvell

  4. CID 5115 Discussion Text in D3.02 “S.1 Waveform Generator Tool” currently reads: The waveform generator can be downloaded from the public IEEE 802.11 document web site. The waveform generator code may be found in document 11-06/1715 and the waveform generator description may be found in document11-06/1714. (#2801) The reason for the wording chosen was that referring to the documents would be appropriate because the document numbering system is considered to be historically stable but to avoid tying the document location to a specific document server which may change over time. Proposed resolution: • Reject. The reason for the wording chosen was that referring to the document IDs is adequate because the document numbering system is historically stable and the documents are publically available but details of the server containing the documents may change over time and should not be included in an amendment specification. Bruce Kraemer, Marvell

  5. CID 5113 Discussion Text in D 3.02 Clause 3 “Definitions” currently reads: 3.n40 overlapping basic service set (OBSS): A BSS operating on the same channel as the STA’s (#5545) BSS and within (either partly or wholly) its BSA (#807). The requested definition already exists. Proposed resolution: • Reject. The requested definition already exists in clause 3 as entry 3.n40. Bruce Kraemer, Marvell

  6. CID 5408 Discussion Text in question in D 3.02 Clause 3 “Definitions” currently reads: 3.n14 BSSBasicMCSSet: The set of MCS values that must be supported by all HT STAs that are members of an HT BSS. (#1884) Proposed resolution: • Counter • TGn Editor: change the text in 3.n17 as shown below: • HT BSS to HT-BSS The commenter correctly quotes the style guide. The 802.11 baseline uses the definitions for two purposes: a) generic definitions suitable for inclusion in IEEE 100; b) IEEE 802.11 specific definitions that make no sense outside the context of the 802.11 standard. The definitions that the commenter identifies fall into the latter category and there is no obvious way to avoid the use of Clause references as they identify PHY capabilities. This has been discussed with the IEEE-SA editorial staff. They suggest that we address this in REVmb, by introducing a new section for local terms, which is not intended to provide definitions for IEEE 100. Until then, it makes no sense to attempt to do this piecemeal in 802.11 amendments, so no action is proposed in the TGn draft in resolution of this comment. At this time the best we can do is to adjust the HT-BSS nomenclature to ensure homogeneity within the draft. Bruce Kraemer, Marvell

  7. CID 5364 Discussion:Text in question in D 3.00 was: 3.n57 space-time block code / spatial multiplexing (STBC/SM): A combination of space-time block coding and spatial multiplexing where one spatial stream is transmitted using space time block coding, and one or two additional spatial streams are transmitted using spatial multiplexing. Text in question in D 3.02 now appears as (clause number only change; no text changes): 3.n58 space-time block code / spatial multiplexing (STBC/SM): A combination of space-time block coding and spatial multiplexing where one spatial stream is transmitted using space time block coding, and one or two additional spatial streams are transmitted using spatial multiplexing. (#792) There is also an acronym listed in clause 4 SM spatial multiplexing Bruce Kraemer, Marvell

  8. CID 5364 Proposed Resolution: • Accept in principle • TGn Editor: insert the blue text as shown below in appropriate location in clause 3 : • 3.nxx spatial multiplexing (SM): Spatial multiplexing is a transmission technique employing multiple antennas where each antenna independently transmits a portion of the data signal in a spatial stream from each of the multiple transmit antennas. Bruce Kraemer, Marvell

  9. CID 5480 Discussion In D3.0 the text reads: 3.n16 high throughput (HT): the set of features as introduced in 5.2.9 (High Throughput (HT) STA). A STA supporting these features is an HT STA. A STA not supporting them is a non-HT STA. In D3.02 the text reads:3.n17 high throughput (HT): the set of features as introduced (#1983) in 5.2.9 (High Throughput (HT) STA (#964)). A STA supporting these features is an HT STA. A STA not supporting these features (#5542) is a non-HT STA. Bruce Kraemer, Marvell

  10. CID 5480 Proposed Resolution • Accept in principle • TGn Editor: change the text in 3.n17 as shown below: • 3.n17 high throughput (HT STA): • A STA supportingthe set of features as introduced (#1983) in 5.2.9 (High Throughput (HT) STA (#964)). A STA supporting these features is an HT STA. A STA not supporting these features (#5542) is a non-HT STA. Bruce Kraemer, Marvell

  11. CID 5528 Discussion Link adaptation is introduced in Clause 9.16 and indicates that channel sounding may be requested. 9.16 Link adaptation 9.16.1 Introduction To fully exploit MIMO channel variations and transmit beamforming on a MIMO link, a STA can request that another STA provide (#164) MIMO channel sounding and MCS feedback. Link Adaptation may be supported by immediate response or delayed (#164) response as described below. Unsolicited MCS feedback is also possible. (#164) — Immediate: An immediate response (#2353) occurs when the MFB responder transmits the response (#164) in the TXOP obtained by the TXOP holder. This approach allows the MFB requester to obtain the benefit of link adaptation within the same TXOP. — Delayed (#164): A delayed response (#2354) occurs when the MFB responder transmits the response in the role of a TXOP holder in response to an MCS request (#164) in a previous TXOP obtained by the MFB requester. — Unsolicited (#164): An unsolicited response occurs when a STA sends MCS feedback independent of any preceding MCS request. Bruce Kraemer, Marvell

  12. CID 5528 • 7.1.3.5a defines the HT Control field Bruce Kraemer, Marvell

  13. CID 5528 Bruce Kraemer, Marvell

  14. CID 5528 Resolution discussion: • A sounding PPDU can be used for the general purpose of link adaptation and is not exclusively used for the purpose of beamforming. There needs to be a recognition of this in the PICS. • Currently the section of the PICS that contains Sounding relationships is shown as below. Bruce Kraemer, Marvell

  15. CID 5528 Proposed Resolution Accept in principle TGn Editor: insert the text for HTP2.8.4 in Annex A under A.4.19.2 HT PHY features as shown below: Bruce Kraemer, Marvell

  16. CID 5687 Discussion There are 7 occurances of “advertises itself” in D3.02 that need to be corrected. Due to the extent of the changes they will be addressed in a separate comment resolution proposal. Proposed resolution: Defer Bruce Kraemer, Marvell

More Related