July 2014 doc.: Ieee 802. 11-14/780r2 ieee p802. 11

Comments marked Trivial Technical requiring review

3036

1838.63

10.44.7.1

"The NCC responding STA might grant permission for using the selected frequencies for multiple WLAN network channels to the NCC requesting STA by using the NCC response frame" -- there is no such thing as an NCC response frame.

Reword so that it relates either to a specific frame, or make it generic e.g., "NCC response".

Discussion:

There is no such thing as an NCC response frame, nor an NCC frame.

There are a bunch of references to NCC * frame.

There is a Network Channel Control frame, with a Reason Result Code field indicating whether it is a REQUEST or not.

There are also a number of grammar, stylistic and consistency changes that should be made.
Proposed Resolution:

Revised. Make changes under CID 3036 in . These changes replace the cited usages with defined terms.

Context and proposed changes: 1838.48:

Network channel control (NCC) procedures(11af) Introduction(11af) This subclause describes network channel control procedures that can be used to manage channels for operation of a GDD STA. STAs can A STA may use the NCC procedures specified here when dot11GDDActivated is true. There is no such thing as an NCC response frame (below). Network channel control utilizes a two-message transaction sequence to allow an NCC responding STA to control the frequency usage in TV bands of an NCC requesting STA’s WLAN network channels. The first message MMPDU sent by the NCC requesting STA asserts identity and requests NCC information. The NCC requesting STA may select its preferred frequencies from its WSM and request usage. The message MMPDU sent by the NCC responding STA returns the NCC result. The NCC responding STA might grant permission for usingto use the selected frequencies for multiple WLAN network channels to the NCC requesting STA by using responding with the a NCC response Network Channel Control frame (see 8.6.8.30 (Network Channel Control frame format)). When responding, the NCC responding STA provides the confirmed WLAN network channels and the transmit power constraints as well. The WLAN network channels that the network channel controlNCC responding STA confirms might be the same as or a subset of the network channels listed in the NCC requestNetwork Channel Control frame received from the NCC requesting STAor a subset of the list in the NCC request frame. An NCC requesting STA employing RLQP may send an NCC Network Channel Control frame to the RLSS to request its preferred frequencies given by the WSM for WLAN network channels. The NCC requesting STA accomplishes this by transmitting an RLQP-element with the RLQP ID for NCC in the Query Request field in a Gas Initial Request frame. After it receives this frame the NCC responding STA forwards the NCC request to the RLSS. After receiving the NCC request, the RLSS responds and sends an NCC response via the NCC responding STA to the NCC requesting STA. When responding, the RLSS also provides the confirmed WLAN network channels and the transmit power constraints. The WLAN network channels that the RLSS confirms might be the same as or a subset of the network channels listed in the NCC Network Channel Controlrequest frame or a subset of the list in the NCC request frame received from the NCC requesting STA. Whenever the WSM has changed due to the update of the database information or detection of the primary service signals, the network channel control an NCC requesting STAs may transmit the NCC request frame againa new Network Channel Control frame. NCC requesting STA(11af) The An NCC requesting STA may be a GDD dependent STA. An NCC requesting STA employing RLQP may use the GAS protocol … as follows: … The Reason Result code is REQUEST0, as defined in 8.4.5.4 (Network Channel Control RLQP-element). … An NCC Requesting STA might use the NCC Public Action Network Channel Control frame or its protected dual to query another STA to request frequency usage in TV bands for WLAN network channels. Upon receipt of the MLME-NETWORKCHANNELCONTROL.request primitive with NCC parameter value of NCC element, the requesting STA transmits a (protected) Network Channel Control framen Action frame containing an NCC element. The request frame is generated as follows: … The Reason Result Code is REQUEST0, as defined in 8.4.5.4 (Network Channel Control RLQP-element). … NCC responding STA(11af) AnThe NCC responding STA may be a GDD enabling STA. An NCC responding STA employing RLQP may use the GAS protocol … follows: … Reason Result Code field = values SUCCESS2, REFUSED3, TOO_MANY_SIMULTANEOUS_REQUESTS4, 5, or 6 Continuation frame as defined in 8.4.5.4 (Network Channel Control RLQP-element). … An NCC responding STA may use an NCC Public ActionNetwork Channel Control frame or its protected dual to respond to another STA with NCC information. Upon receipt of the MLME-NETWORKCHANNELCONTROL.response primitive with NCC parameter value of NCC element, the NCC responding STA transmits a Network Channel Controln Action frame containing an NCC element. The response frame is generated as follows: … Reason Result Code = values SUCCESS, REFUSED, TOO_MANY_SIMULTANEOUS_REQUESTS, or Continuation frame 2, 3, 4, 5, or 6 as defined in 8.4.5.4 (Network Channel Control RLQP-element). …

3332

2152.01

16

TXTIME is not defined for 802.11 classic (802.11-1997) devices

Add a reference to clause 17 (11b)

Discussion:

The commenter is correct.
Insert the following new subclause: (replacing with the glyph)

16.4.7 DS PHY TXTIME calculation The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive shall be calculated according to the following equation: Copy the equation from 2194.02 where LENGTH and DATARATE are values from the TXVECTOR parameter of the corresponding PLME-TXTIME.request primitive LENGTH is in units of octets DATARATE is in units of Mb/s The value of PreambleLength is 144 s The value of PHYHeaderTime is 48 s

Proposed Resolution:

Revised. Make changes in document under CID 3332. These add a TXTIME calculation for Clause 16.

3116	2175.30	16.4.6.5	"...the DSSS PHY shall be 6". That don't sound right. See proposed change for correct text.	Replace "6", with "hold the CCA signal inactive (channel busy) for the full duration as indicated by the PHY LENGTH field. Should a loss of CS occur in the middle of reception, the CCA shall indicate a busy medium for the intended duration of the transmitted packet"
3153	2175.30	16.4.6.5	Items c and d (respectively, "In the event that a correct PHY header is received, the DSSS PHY shall 6" and "inactive (channel busy) ...") are garbled, apparently by an editing error.	In c), change "6" to "hold the CCA signal", delete "d)", and merge the rest of the text of the current d) into c).

Context: 2175.30

c) In the event that a correct PHY header is received, the DSSS PHY shall 6 d) inactive (channel busy) for the full duration as indicated by the PHY LENGTH field. Should a loss of CS occur in the middle of reception, the CCA shall indicate a busy medium for the intended duration of the transmitted packet.

Discussion:

Agree this is clearly an editing error of some kind.

There are actually three issues with this text:

1. 
   The error reported in the comment
   
2. 
   The terminology inactive as a synonym for channel busy is undefined and counter-intuitive
   
3. 
   The PHY doesn’t hold signals, it generates CCA indication primitives. The text is worded as though it is describing a function that passes through another function to generate the CCA.indication primitive. But no such other function is described.
   

The cited text is a cut and paste 17.3.8.5 (2206.38), which also suffers from issues 2) and 3).

Clause 20 has statements that have been worked to avoid the “hold a signal” language as follows: 2353.46:

Upon reception of an HT-mixedformat preamble, the HT PHY shall not generate a PHYCCA.indication(IDLE) primitive for the predicted duration of the transmittedframe, as defined by TXTIME in 20.4.3 (TXTIME calculation), for all supported and unsupported modes except Reserved HT-SIG Indication. Reserved HT-SIG Indication is defined in the fourth list item below.

Proposed changes: 2174.61:

CCA The DSSS PHY shall provide the capability to perform CCA according to at least one of the following three methods: CCA Mode 1: Energy above threshold. CCA shall report a busy medium upon detection of any energy above the ED threshold. CCA Mode 2: CS only. CCA shall report a busy medium only upon detection of a DSSS signal. This signal may be above or below the ED threshold. CCA Mode 3: CS with energy above threshold. CCA shall report a busy medium upon detection of a DSSS signal with energy above the ED threshold. (#61)A busy channel shall be indicated by a PHY-CCA.indication(BUSY) primitive.(#1603) A clear channel shall be indicated by a PHY-CCA.indication(IDLE) primitive.(#1603) The dot11CCAModeSupported shall indicate the appropriate operation modes. The PHY shall be configured through dot11CurrentCCAMode. The CCA shall be trueindicate a clear channel if there is no energy detect or CS. The CCA parameters are subject to the following criteria: The ED threshold shall be  –80 dBm for TX power > 100 mW, –76 dBm for 50 mW < TX power  100 mW, and –70 dBm for TX power  50 mW. With a valid signal (according to the CCA mode of operation) present at the receiver antenna within 5 µs of the start of a MAC slot boundary, the PHY-CCA. indication(BUSY) primitiveor shall report channel busybe generated before the end of the slot time. This implies that the CCA signal is available as an exposed test point. Refer to Figure 9-18 (DCF timing relationships) (in 9.3.7 (DCF timing relations)) for a definition of slot time boundary. In the event that a correct PHY(#61) header is received, the DSSS PHY shall 6 not generate a PHY-CCA.indication(IDLE) primitive until the end of the PPDU as determined by TXTIME in 16.4.7,. inactive (channel busy) for the full duration as indicated by the PHY(#61) LENGTH field. Should a loss of CS occur in the middle of reception, the CCA shall indicate a busy medium for the intended duration of the transmitted packet. Conformance to DSSS PHY CCA shall be demonstrated by applying a DSSS-compliant signal, above the appropriate ED threshold (item a), so that all conditions described in item b and item c are demonstrated.

Proposed changes:

CCA The high rate(#1353) PHY shall provide the capability to perform CCA according to at least one of the following three methods: CCA Mode 1: Energy above threshold. CCA shall report a busy medium upon detecting any energy above the ED threshold. CCA Mode 4: CS with timer. CCA shall start a timer whose duration is 3.65 ms and report a busy medium only upon the detection of a high rate(#1353) PHY signal. CCA shall report an IDLE medium after the timer expires and no high rate(#1353) PHY signal is detected. The 3.65 ms timeout is the duration of the longest possible 5.5 Mb/s PSDU. CCA Mode 5: A combination of CS and energy above threshold. CCA shall report busy at least while a high rate(#1353) PPDU with energy above the ED threshold is being received at the antenna. (#61)A busy channel shall be indicated by PHY-CCA.indication(BUSY) primitive.(#1603) A clear channel shall be indicated by PHY-CCA.indication(IDLE) primitive.(#1603) dot11HRCCAModeSupported(#2410) shall indicate the appropriate operation modes. The PHY shall be configured through dot11CurrentCCAMode. The CCA shall indicate true a clear channel if there is no energy detect or CS. The CCA parameters are subject to the following criteria: If a valid high rate(#1353) signal is detected during its preamble within the CCA window, the ED threshold shall be less than or equal to –76 dBm for TX power > 100 mW; –73 dBm for 50 mW < TX power 100 mW; and –70 dBm for TX power 50 mW. With a valid signal (according to the CCA mode of operation) present at the receiver antenna within 5 s of the start of a MAC slot boundary, the PHY-CCA. indication primitive(BUSY) or primitive shall report channel busy be generated before the end of the slot time. This implies that the CCA signal is available as a signal at an exposed test point. Refer to    Figure 9-18 (DCF timing relationships) (in 9.3.7 (DCF timing relations)) for a slot time boundary definition. In the event that a correct PHY(#61) header is received, the high rate(#1353) PHY shall not generate a PHY-CCA.indication(IDLE) primitiveshall hold the CCA signal inactive (channel busy) for the full duration,until the end of the PPDU as indicated by determined by TXTIME in 17.3.4, the PHY(#61) LENGTH field. Should a loss of CS occur in the middle of reception, the CCA shall indicate a busy medium for the intended duration of the transmitted PPDU. Upon reception of a correct PHY(#61) header, the timer of CCA Mode 2 shall be overridden by this requirement. Conformance to the high rate(#1353) PHY CCA shall be demonstrated by applying an equivalent High-Rate--compliant signal above the appropriate ED threshold (item a) so that all conditions described in item b and item c are demonstrated.

Proposed Resolution:

Revised. Make changes in under CID 3116. These changes address the error reported, and also address CCA terminology for consistency with later subclauses.