Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11-TGM] PHY comment resolutions



--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

I was asked by the Chair to draw the attention of subscribers to this

reflector to a few PHY-related comment resolutions that have been

agreed in principle by the group during teleconfs, but that could do

with review by PHY experts.  Please reply (privately if you prefer) if

you have any comments.  The proposed changes are highlighted in yellow.

 

Identifiers

Comment

Proposed change

CID 291

Mark RISON

20.4.3.2.1

"Used to initialize the differential encoding." -- how?  There is no specification of "differential encoding" (20.4.3.3.4 does not specify anything)

Make a reference to this field wherever differential encoding initialisation is specified

 

Discussion:

 

Assaf KASHER (Intel) has provided the following input:

 

The differential encoding is described in 20.4.3.3.4.

The purpose of this fake bit described as the differential encoder initialization is to provide time for a reference waveform (which is the spreading sequence multiplied by either 1 or -1.   We could have added a bit outside the header to do that, but chose to have a waveform corresponding to number of bits which is a multiple of 8.

I hope it clarifies the issue.  May be inserting the word “dummy” into the description can make it clearer, but I am not sure.

[…]

This [differential encoder initialization] bit and the scrambler initialization bits are not scrambled.

[…]

A receiver may perform non-differential detection and recover d(0) directly.  Using the information that d(-1) is 1, it may recover s(0) and therefore c(0).  However, the assumption is that the receiver performs differential decoding.  It recovers s(1) by looking at the product of d(1)xd(0).  The product is calculated directly on the signals – after correlating the r_DATA(n) with the Ga(32) sequence, the receivers multiplies the peak (or a set of peaks) in adjacent symbols to recover d(n).  This cannot be done for d(0).  This is what mean by saying that from the receiver point of view d(0) does not exist.

 

Proposed changes:

 

In the first non-header row of Table 20-11, change “Differential encoder initialization” to “Differential Encoder Initialization” and after “Used to initialize the differential encoding” append “; c(0) in 20.4.3.3.4.  May be set to any value”.

 

Change 20.4.3.3.4 as follows:

 

20.4.3.3.4 Modulation

 

The scrambled and coded bit stream c(k), k = 0, 1, 2, …, is converted into a stream of complex constellation points d(k) using differential binary phase shift keying (DBPSK) as follows.

 

c(k) The encoded bit stream [c0, c1, c2, c3, c4, …] is converted to the nondifferential stream s(k) = 2c(k)k – 1. Theis is converted to the differential sequencestream is created by setting d(k) = s(k) × d(k – 1), where . For the differential encoding purposes d(–1) is defined to be 1.  s(0) is the first bit of the encoded header bits.  c(0) is the Differential Encoder Initialization field of the DMG control mode header.

NOTE—The scrambling and coding process does not affect the Differential Encoder Initialization field of the DMG control mode header.  However, a typical receiver implementation does not recover d(0) and hence does not recover the value of this field.

 

Proposed resolution:

 

REVISED

 

Make the changes shown under “Proposed changes” for CID 291 in <this document>, which clarify that the Differential Encoder Initialization field is c(0) for the differential encoding process described in 20.4.3.3.4, but that this field is not recovered by a typical receiver implementation.

 

Identifiers

Comment

Proposed change

CID 205

Mark RISON

 

Does the "PHY header" include the SERVICE field for all PHYs (e.g. Figure 17-1---PPDU format for OFDM)?  If so, then its length is dependent on the datarate of the PHY payload, which is awkward for things like aPHYHeaderLength

Make the changes indicated in 16/0839r3 under CID 8088

 

Discussion:

 

aPHYHeaderLength is defined at 648.16 as “The current PHY’s header length (in microseconds), excluding aPHYSigTwoLength if present.”

 

For things like DSSS and HR/DSSS it’s all fine (Figures 15-1 and 16-2 respectively): the SERVICE field is sent at a known PHY rate and so the duration of the PHY header is fixed.

 

However for things like OFDM, HT and VHT it’s more problematic (Figures 17-1, 19-1 and 21-4 respectively), because the PHY header includes a SERVICE field that is in the Data field and hence has a non-fixed duration, although Figures 19-1 and 21-4 don’t explicitly indicate what the “PHY header” consists of.

 

Proposed resolution:

 

REVISED

 

At 648.17, after “excluding aPHYSigTwoLength if present” add “and the SERVICE field if it is in the Data field of the PPDU”.

 

Identifiers

Comment

Proposed change

CID 207

Mark RISON

 

aSTFTwoLength and aLTFTwoLength are stated to be integers.  However, for TVHT they aren't, because of the way TVHT is derived from VHT

Make the changes shown in 16/0839r3 under CID 8316

 

Discussion:

 

The table in 6.5.4.2 claims that the type of aPreambleLength and aPHYHeaderLength is “integer”.

 

However 22.4.4 says:

 

The static TVHT PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive, shall be as shown in Table 19-25 (HT PHY characteristics) except parameters listed in Table 22-25 (TVHT PHY characteristics) and aPreambleLength, aSTFOneLength, aSTFTwoLength, aLTFOneLength, aLTFTwoLength, aPHYHeaderLength, and aPHYSigTwoLength, which are multiplied by 7.5 for 6 MHz and 7 MHz unit channels and by 5.625 for 8 MHz unit channels. The definitions for these characteristics are given in 6.5 (PLME SAP interface).

 

The values for aPreambleLength and aPHYHeaderLength in Table 19-25 are 16 µs and 4 µs respectively.  The result of multiplying the latter by 5.625 is not an integer.

 

Actually, this might also be true of a[SL]TF{One,Two}Length and aPHYSigTwoLength.  Time for a table:

 

Characteristic

× 1

× 7.5

× 5.625

aPreambleLength

16 µs

120 µs

90 µs

aSTFOneLength

8 µs

60 µs

45 µs

aSTFTwoLength

4 µs

30 µs

22.5 µs

aLTFOneLength

8 µs

60 µs

45 µs

aLTFTwoLength

4 µs

30 µs

22.5 µs

aPHYHeaderLength

4 µs

30 µs

22.5 µs

aPHYSigTwoLength

8 µs

60 µs

45 µs

 

So the non-integers appear only for a[SL]TFTwoLength and aPHYHeaderLength.  But for the latter 648.19 already says “If the actual value of the length of the modulated header is not an integer number of microseconds, the value is rounded up to the next higher value.”

 

So the problem is only for a[SL]TFTwoLength.

 

Proposed resolution:

 

REVISED

 

At 648.12½ add “.  If the actual value of the length of the HT-STF is not an integer number of microseconds, the value is rounded up to the next higher value.” to the end of the rightmost cell.

 

At 648.15½ add “.  If the actual value of the length of the Additional HT-LTFs is not an integer number of microseconds, the value is rounded up to the next higher value.” to the end of the rightmost cell.

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 


_______________________________________________________________________________

IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.

SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________