May 2009
doc.: IEEE 802.15-09-0395-00-003c
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Resolution to PHY and MAC comments for 15.3c sponsor ballot SB1]
Date Submitted: [May 11, 2009]
Source: [Huai-Rong Shao, Sukhiong Yong, Chiu Ngo, Edwin kweon, Jisung Oh, Seongsoo Kim]
Company: [Samsung Electronics]
Address: [75 West plumeria Dr, San Jose, CA 95134, USA]
Voice: [408-544-5552], FAX: [],
E-Mail: [ {hr.shao, sk.yong, chiu.ngo, cy.kwon, jisung0714.oh, seongsoo1.kim}@samsung.com]
Re: []
Abstract: [15.3c sponsor ballot comment resolutions for CID 108,112,113,114,122,193,207]
Purpose: [To be considered in IEEE 802.15.3c specification]
Notice: This document has been prepared to assist the IEEE P802.15. 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 contributor acknowledges and accepts that this contribution becomes the property of
IEEE and may be made publicly available by P802.15.
Submission
Slide 1
Samsung Electronics
May 2009
doc.: IEEE 802.15-09-0395-00-003c
Comment #75
• Comment: S-CAP partitioning in directional peer
communication in the regular CAP is ambiguous.
• Resolution from commenter: It should be clear if by
allocating the regular CAP for peer to peer communication,
the S-CAP division is no longer valid or suggest new
mechanism for peer to peer communication over CAP
• Recommended resolution: Agree in principle. Add one
sentence on Page 46, Line 46, (Before “After the…”)
“Directional peer communication between two non-PNC
devices ignores the S-CAP boundaries in the regular
CAP”.
Submission
Slide 2
Samsung Electronics
May 2009
doc.: IEEE 802.15-09-0395-00-003c
Comment #108, 112
• Comment: DEV to DEV directional transmission in
directional CAP is not well supported. Need improvement
• Resolution from commenter: Use directional RTS/CTS
fro DEV to Dev communication.
• Recommended resolution: Rejected. RTS/CTS will
introduce high complexity to 15.3c. DEV to DEV
transmission has been well supported in directional CAP
described in 8.6.6.2.
Submission
Slide 3
Samsung Electronics
May 2009
doc.: IEEE 802.15-09-0395-00-003c
Comment #113
• Comment: The regular CAP as described supports slottedaloha, directional CAP via division into multiple periods
and CSMA/CA. There are too many incompatible modes.
• Resolution from commenter: Make the regular CAP a
single period and a set of rules on how to use it. (1) It is
recommended that devices should perform some level of
beamforming before using the CAP. (2) Limit maximum
size of packets in the CAP to say 2K octets (for example)
(3) slotted operation (4) CSMA/CA as a best effort (5)
with or without RTS/CTS.
• Recommended resolution: Rejected. Association
procedure itself does the Quasi-omni level direction
training.
Submission
Slide 4
Samsung Electronics
May 2009
doc.: IEEE 802.15-09-0395-00-003c
Comment #114
• Comment: If the association request is sent into multiple
packets back to back in few directions than there should be
a field indicating the number of packets in the association
request and the index of the current request or remaining
duration.
• Resolution from commenter: Add 2 counters indicating
the index of the current packet within the association
request and the total number of packets or a counter of
remaining number of packets.
• Recommended resolution: Rejected. Association request
is not sent into multiple packets back to back since sent out
at different S-CAPs.
Submission
Slide 5
Samsung Electronics
May 2009
doc.: IEEE 802.15-09-0395-00-003c
Comment #122
•
•
•
Comment: There should be a distinction between a DEV beamforming capability and what degree of
beamforming it wants to do before communicationg with another DEV. For example DEV1 might
want to perfrom a level 1 only beamforming with DEV2 before communication although DEV1 is
capable of 2 levels. Or DEV1 might be omni capable and does not want to do any beamforming. after
1st level
Resolution from commenter: When DEV1 requests a CTA from the PN to perform beamforming
with DEV2 it should tell the PNC the number of levels it wants to perform during this CTA.
Proposed Resolution: Accept in principle. Change the text in page 153, line 33-35 from
“Support for beam forming is optional. However, when the beam forming in this clause is
implemented, the sector level training shall be supported for switched/sectored antennas and the
two-level training, as defined in 13.5.1, shall be supported for all other antenna configurations.”
to as follows:
“Support for beam forming is optional. However, when the beam forming in this clause is
implemented, the sector level training shall be supported when both of the beamforming DEVs are
switched/sectored antenna capable or one of the beamforming DEVs is switched/sectored antenna
capable while the other DEV is single antenna capable. The two-level training, as defined in 13.5.1,
shall be supported as long as there is a beamforming antenna arrays at either of the DEV.”
The proposed change will mean that as long as the antenna capability is known, the DEV shall know
which level of training it is going to train. Single antenna or sector antenna is needed to assist the
training of a more capable DEV.
Submission
Samsung Electronics
May 2009
doc.: IEEE 802.15-09-0395-00-003c
Comment #193
• Comment: There is no lsb retransmission field and if so, why should
we specify how it is set and then ignore it on reception. Likely, this
refers to the ACK fields in the subheader, which is correctly defined in
7.2.8 and so should not be defined here as well.
• Resolution from commenter: Delete the paragraph on page 53, lines
4-7 and 40-43, If the subframe contains ... ignored upon reception.
• Recommended resolution:
– Change the paragraph on page 53, lines 4-7 and also lines 40-43 to “If the
subframe contains only msb information, the lsb ACK in the Blk-ACK
Bitmap field in MAC header shall be set to zero and shall be ignored upon
reception. Likewise, if the a subframe contains only lsb information, the
msb ACK in the Blk-ACK Bitmap field shall be set to zero and shall be
ignored upon reception.”
Submission
Slide 7
Samsung Electronics
May 2009
doc.: IEEE 802.15-09-0395-00-003c
Comment #207
•
Comment: The description of this section can not be implemented. The 1st paragraph in 12.3.2.8 describes the toneinterleaver as a bit-reversal tone interleaver which only applies to data subcarriers. However, the bit-reversal of datasubcarrier index is not guaranteed to be a data-subcarrier again within an OFDM symbol. In other words, the same
index might indicate a pilot or some other subcarrier.
•
Resolution from commenter: Define a mechanism which can be implemented.
•
Proposed Resolution: Replace the text in 12.3.2.8 with the following text:
“All bits shall be interleaved by a block interleaver with a block size corresponding to the size of FFT in a single
OFDM symbol, Nsc. The interleaver is used so that the adjacent data symbols are mapped onto separate subcarriers.
At the transmitter side, the interleaver permutation shall be defined as follows: Let k be the index of the tones
(including data tones, pilot tones, DC tones and null tones) before permutation ranging between 0 and Nsc - 1. Let i be
the index of the interleaved tones over the same range (including data tones, pilot tones, DC tones and null tones) after
permutation. Let
L
k  aj 2j
j 0
where L = log2Nsc -1, with [aL, …, a0] being the binary representation of integer k. Then the binary representation of
integer i can be written as [a0, …, aL], i.e.,
L
i   a j 2L j
j 0
DC, null, and pilot tones shall be inserted in the bit-reversal position before the tone interleaver. This ensure that after
permutation, the DC, null and pilot tones appear in the pre-specified positions.
Submission
Samsung Electronics
May 2009
doc.: IEEE 802.15-09-0395-00-003c
Comment #207 (cont’)
• Proposed Resolution (cont’):
– In 12.4.2.11 Bit reversal tone interleaver
– Change Page 136 Line 18 “where L = 8 for HRP modes
and L = 6 for LRP modes,” to
“where L = log2Nsc(HR) - 1 for HRP modes and L = log2Nsc(LR) -1 for
LRP modes,”
– Insert the following equation in Page 136 Line 20
L
i   a j 2L j
j 0
Submission
Samsung Electronics