1. doc.: IEEE 802.15-<doc#>
<month year>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Comment resolutions for MAC]
Date Submitted: [April 1, 2008]
Source: [Hiroshi Harada (1), Chang woo Pyo, Zhou Lan, Fumihide Kojima, Chin-Sean Sum, Tuncer Baykas, Junyi Wang, Hiroyuki Nakase, Ruhei Funada, Shuzo Kato, Ismail Lakkis (2)]
Company [National Institute of Information and Communications Technology (NICT)]
Address1[3-4 Hikari-no-oka, Yokosuka-shi, Kanagawa , Japan]
Voice1:[ ] , FAX1: [ ]
Address2 [10875, Rancho Bernardo Rd#108, San Diego, CA, USA]
Voice2:[ ] , FAX2: [ ] []
Re: [In response to TG3c Call for Proposals (IEEE P c)]
Abstract: [Comment resolutions for MAC]
Purpose: [To be considered in TG3C baseline document.]
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributors acknowledge and accept that this contribution becomes the property of IEEE and may be made publicly available by P
<author>, <company>

2. Summary of Comment Resolution
The table shown below summarizes 90 comments
Type of Comment
Total
Technical
Editorial
Responded
Open
All 90 53 19 18
PHY 36 21 3 12
MAC 34 23 8
Beamforming BF 7 6 1
Others
(OFDM related) 13 9 2
This document resolved 6 MAC comments categorized by channel probing, UEP and missing definition
2 comment resolutions for channel probing (#16, #38)
3 comment resolutions for UEP (#17, #35, #36)
1 comment resolution for missing definition (#89)
3 PHY and 6 beamforming open comments will be discussed at the following teleconference (8 April, 2008)

3. Comment #16 (Definition of channel status information)
What is the definition of the value of the Channel Status Information field?
Answer
According to the resolution of comment #38, Channel probing response will be eliminated. So the Channel Status Information field will be eliminated as well
Instead, the channel status information will be put in the ACK frame and reported back by receiver during channel probing procedure
The new definition of channel status information in ACK frame is in next slide

4. Channel status information in ACK frame
Suggestions for feedback in channel probing (from )
RSSI: use 4 bits, 2 dB steps relative to the receiver’s sensitivity, starting with 0000 – 0 dB, 0001 – 2 dB, ..., 1110 – 28 dB, > 30 dB.
SINR: Estimated SNR at decision point of receiver . From 0dB to 30 dB with 2dB step (0000 stands for 0dB, 1111 stands for 30dB)
Suggested Channel Estimation Sequence (CES) Length: use 2bits, suggested CES length of short or long from the receiver to the transmitter
FER: from 10-1 to 10-2 with 10 times step
Detailed bit assignment refers to the resolution of comment #89

5. Comment #38 (channel probing)
Can we use the existing facilities in b to accomplish this (channel probing) in a manner that improves the performance.
Answer
Yes, ACK frame (Imm-ACK, Dly-ACK, Imp-ACK) defined in b can be used to realize what is intended for channel probing
Channel probing response command proposed in DF2 can be eliminated
Suggested solution is given in the following slides

6. Differences from old channel probing defined in DF2
CTAs needed
One CTA for both channel probing and streaming (new)
Separated CTAs for channel probing and streaming (DF2)
Data for measuring channel status
Regular data frame (new)
One bit in MAC header to indicate receiver to report channel status information by ACK frame
Special channel probing sequence (DF2)
Method to report back channel status information
Use ACK frame (new Slide 7)
Channel probing response command (DF2)

7. Suggested channel probing procedure (1/2)

8. Suggested channel probing procedure (2/2)
A DEV may firstly request a CTA of length calculated based on base rate ( b )
The Src DEV may send empty data frames with ACK policy set to Imm-ACK or Dly-ACK (1 bit in MAC indicates the receiver should report back channel status information)
The Dest DEV, upon receiving the empty frames, feedbacks the estimated SNR, BER and suggested / highest MCS back to Src with Imm-ACK or Dly-ACK (using fragmentation field defined in MAC header as in slide 8)
The DEV determines the appropriate MCS based on information feedback by ACK and modifies the CTA length based on the new MCS ( b )
Streaming with the new MCS
The receiver constantly reports back channel status with Imm-ACK, Dly-ACK
If the channel becomes worse than expected, pause current streaming and go to step 2 for channel probing again

9. Suggested modification from DF2
Modify the DEV to DEV channel probing procedure as indicated in the previous slides
Remove channel probing response command
Remove MLME-SAP as suggested in
Remove PNC to DEV channel probing as suggested in
Remove the special stream index defined for channel probing as suggested in

10. Comments #17 & #36 (UEP) Comment #17
Can this be done with an information element? Also, there are some updates to the frame format that need to be reviewed.
Resolution
Yes. Capability IE can be used for exchanging UEP capability.
Capability IE for UEP capable field (5bits) is updated
Comment #36
Rather than using commands, if the UEP capabilities are exchanged as part of the normal capabilities exchange, then the commands are not needed.
That is right. Capability IE is used for exchanging UEP capability rather than creating new command frame capabilities.
Suggest to eliminate UEP commands from baseline document DF2

11. UEP capable field in Capability IE (1/2)
5 bit UEP capable field (2bits for SC/HSI-OFDM/AV-OFDM indication and 3bits for UEP field) in Capability IE is sufficient, no commands or extra IEs required
UEP capable field b0 b1 b2 b3 b4
SC/HSI-OFDM/AV-OFDM UEP capable indication
UEP Field
2bits for SC/HSI-OFDM/AV-OFDM UEP capable indication b0 b1
SC/HSI/AV-OFDM Capable indication
No UEP Capable 1
SC UEP Capable
HSI-OFDM UEP Capable
AV-OFDM UEP Capable

12. UEP capable field in Capability IE (1/2)
3bit UEP field in SC UEP capable b2 b3 b4
HSI-OFDM UEP Capable& AV-OFDM UEP Capable
No UEP Capable 1
Type 1 capable for MCS of QPSK/RS/LDPC
Type 1 capable with MCS of 16QAM/RS/LDPC
Type 2 capable for MCS of QPSK/RS/LDPC
Type 2 capable for MCS of 16QAM/RS/LDPC
Type3 with MCS only
Type3 with skewed constellation only
Type3 with MCS and skewed constellation
3bit UEP field in AV/HSI-OFDM UEP capable (IEEE /0174r0) b2 b3 b4
HSI-OFDM UEP Capable& AV-OFDM UEP Capable
No UEP Capable 1
Type 1 capable
Type 2 capable
Type3 with MCS only
Type3 with skewed constellation only
Type3 with MCS and skewed constellation
Reserved

13. Appendix1 : UEP for SC/HSI-OFDM/AV-OFDM
Outer FEC
MSB
LSB
QPSK
RS (255,239)
LDPC(576,288)
LDPC(576,432)
LDPC(576,504) -
8QAM
16QAM
UEP for HSI-OFDM
Outer FEC
MSB
LSB
QPSK
0.94
1/2
3/4
7/8
16QAM
UEP for AV-OFDM
MSB
LSB
UEP
QPSK
4/7
4/5
16QAM
MSB only retransmission
1/3
N/A
2/3

14. Comment # 35 (UEP) Comment Resolution
There needs to be a way for the upper layer that is the source of data to say if the use of UEP is allowed for the data stream.
Resolution
For the use of UEP, MAC-SAP can be extended for this. In MAC-ISOCH-DATA.request primitive, a parameter [UEPRequested] to tell lower layer that upper layer requires to use UEP needs to be defined. The other direction, in the MAC-ISOCH-DATA.confirm primitive, the ReasonCode needs be extended to report back the UEP capability of lower layer.

15. MAC-SAP extension for UEP
MAC-ISOCH-DATA.request (
RequestID,
StreamIndex,
TransmitTimeout,
MaxRetries,
SNAPHeaderPresent,
ACKRequested,
ConfirmRequested,
UEPRequested,
Length,
Data )
MAC-ISOCH-DATA.confirm
TransmitDelay,
ResultCode,
ReasonCode
Name
Type
Valid range
Description
UEPRequested
Boolean
TRUE FALSE
Indicates if the request requires using UEP
Name
Type
Valid range
Description
ReasonCode
Enumeration
TRANSMIT_TIMEOUT, MAX_RETRIES, NOT_ASSOCIATED,
UEP_NOT_SUPPORT,
OTHER
The reason for the request failure

16. Comment #89 (missing definition)
missing definition of the following fields: (a) UEP field (b) Transmit Beam Number filed, (c) Received Beam Number field, (d) Beam Status Information field, (e) Channel Status Information field
Resolutions
(a) UEP field (refer to comment #17 & #36)
(b) and (c) will be replaced by beamforming IEs. These will be shown in beamforming comment resolutions
(d) is changed: “SINR table” for best SNR beam pair tracking
The SNR table is the same as in defined in(e)
(e) is designed to include RSSI, SINR, suggested CES length, and FER

17. Possible results obtained from channel status information
RSSI
SINR
R.M.S delay spread
Possible results
Small
Small/large
Signal is weak, more robust transmission scheme (e.g. Common Rate) needed.
Large
Strong interference.
Signal is strong, delay spread is short.
Short CES can be suggested.
No equalization required in receiver.
Signal is strong, delay spread is long.
Long CES can be suggested.
Equalization required in receiver.
Knowledge of R.M.S delay spread helps to determine the channel estimation sequence (CES) length
Knowledge of FER helps to confirm the fulfillment of the target FER required for specific applications

18. Bit assignment of Channel State Information field (1/3)
RSSI
SINR
RSSI [dB]
Bit assignment
0000 2
0001 4
0010 6
0011 . 30
1110
Reserved
1111
SINR [dB]
Bit assignment
0000 2
0001 4
0010 6
0011 . 30
1110
Reserved
1111
10dB below receiver sensitivity
20dB above receiver sensitivity
Reference point for RSSI=0dB: 10dB below Receiver sensitivity

19. Bit assignment of Channel State Information field (2/3)
Suggested Channel Estimation (CES) Length
Suggested CES length
Bit assignment
Long CES 00
Short CES 01
Reserved
10-11
Suggested CES length will be sent from the receiver to the transmitter based on the current channel condition (i.e delay spread)
Long CES: Golay codes a(256) and b(256) with prefixes and postfixes (0.59us)
Short CES: Golay codes a(128) and b(128) with prefixes and postfixes (0.3us)

20. Bit assignment of Channel State Information field (3/3)
Frame Error Rate (FER)
FER
Bit assignment
Corresponding BER
10-1
0000
10-5
10-2
0001
10-6
10-3
0011
10-7 .
10-10(TBD)
1001
10-14(TBD)
Reserved
PER-to-BER converted by PER=1-(1-(2048*8)*BER)