1. doc.: IEEE 802.15-<doc#>
<month year>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [DF08 Beamforming Related Comment Resolutions]
Date Submitted: [May. 12, 2009]
Source: [Junyi Wang, Zhou Lan, Chang woo Pyo, Chin-Sean Sum, Tuncer Baykas, Azizur Rahman, Ryuhei Funada, Fumihide Kojima, Hiroshi Harada, Shuzo Kato, Su-Khiong Yong*,
Huai Rong Shao*, Chiu Ngo *, Ismail Lakkis+]
Company [National Institute of Information and Communications Technology (NICT), Tensorcom, Samsung ]
Address1[3-4 Hikari-no-oka, Yokosuka-shi, Kanagawa , Japan;
416 Maetan-3Dong Yeongtong-Gu Suwon-shi Kyunggi-Do , Korea*;
10875 Rancho Bernardo Rd, #108, San Diego, CA ]
Voice1:[ ] , FAX1: [ ]
Re: []
Abstract: [Comment Resolutions related to Beamforming in DF08]
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. Comment 62
Comment #
Subclause
Comment
Proposed Change 62
Bar
P162 L8
"For the SC PHY and HSI PHY, the ..training sequence shall be identical to the CMS preamble, .. For the AV PHY, the .. training sequence shall be identical to the HRP preamble", so if Beam Tracking field is set to one in (beacon) PHY header, what is the value of IFS to the training sequense? ( in drwaing appears unspecified parameter GT)
define GT
Accept in principle. The GTs appeared in Figure 125b in and Figure 125e in shall be specified as BSIFS.
Change the following statement in L41, p153 from
Beam forming sector level IFS (BSIFS) = 1728 SC PHY chips (1 μs) To
Beam forming sector level IFS (BSIFS) = 864 SC PHY chips (0.5 μs)
Replace all GTs in Figure 125b in and Figure 125e in into BSIFS

3. Comment 66
Comment #
Subclause
Comment
Proposed Change 66
Bar
P162 L8
"For the SC PHY and HSI PHY, the ---training sequence shall be identical to the CMS preamble, --- For the AV PHY, the .. training sequence shall be identical to the HRP preamble, so if Beam Tracking field is set to one in (beacon) PHY header, does it overwirtes preamble type field in and ?
clarify
No change required. The usage of beamtracking field indicates whether there are training sequences following data frame in beam tracking stages. On the other hand, the usage of preamble type field indicates the preamble used in the next frame. They serve different purposes and are not overlapped.

4. Comment 67
Comment #
Subclause
Comment
Proposed Change 67
Bar
P162 L8
"For the SC PHY and HSI PHY, the ..training sequence shall be identical to the CMS preamble". since pCCADetectTime= 2 uS for SC / HSI Phy, wouldn't it be enough to send only J(d,r)/pCCADetectTime repetitions of a sector training sequence in the same direction ?
send only J(d,r)/pCCADetectTime
repetitions of a sector training sequence in the same direction
According to the clarification of commenter, the comment suggests using part of preamble to train one of Tx/Rx direction combinations
Reject. To estimate LQI to decide the best directions, the estimation shall be conducted after coarse synchronization. So the training sequences for any one of directions shall at least contain SYNC sequence and CES .

5. Comment 68
Comment #
Subclause
Comment
Proposed Change 68
Bar
P163 L10
what is the IFS between Announce command in different directions during the AAS DEV1 to DEV2 feedback?
set IFS to MIFS
Accept in principle. since a DEV may receive multiple training sequences from different directions, it may need time to process the receive signal. Add BSIFS/BBIFS in between announce commands of training sequences in different directions.
Add BSIFS in Figure 221 and Figure 230
Add BBIFS in Figure 237 and Figure 239

6. Comment 69
Comment #
Subclause
Comment
Proposed Change 69
Bar
P163 L10
Isn't it a protocol violation to send successive Announce command, each Imp-ACK request?
clarify
Accept in principle. During feedback stage, the DEV only needs to receive any one of feedback Announce commands, as long as the DEV receives the feedback, the DEV shall know the start of the SIFS according to the counter in the feedback IE (missed, to be defined). During the SIFS, the DEV could send Imp-ACK. There is no need to put SIFS in between Announce commands. To realize this, the following counter shall be added.
Add 1 octets in the beamforming Feedback IE specified as following fields
Total number of feedbacks : 4 bits
Index of the current feedback: 4 bits

7. Comment 70
Comment #
Subclause
Comment
Proposed Change 70
Bar
7.4.28
P351 L16
In AAS, The direction of Imm-ACK for associate Request CMD in association S-CAP, should be defined using the "best PNC Tx Q-omni direction index" IE, but there is no mapping for Q-omni direction only to sectors and beams
define IE for Q-Omni direction mapping
No change required . After association, all DEVs direct its best Q-omni pattern towards PNC. However the beamforming may be conducted between DEV(PNC) to DEV. The best Tx/Rx Q-omni pattern between PNC and DEV may not be the best Tx/Rx Q-omni pattern between DEVs, therefore the mapping from Q-omni to sector is only meaningful when one of beamforming DEVs is PNC. To simplify the beamforming protocol, the specified beamforming starts from sector level. During sector level searching, any two DEVs may find each other.

8. Comment 71
Comment #
Subclause
Comment
Proposed Change 71
Bar
13.5
P161 L1
According to 15.3b ( page 78) The PNC shall acknowledge all correctly received Association Request commands, by
sending an Imm-ACK. The direction of the PNC Imm-ACK, as I understand it, shall be in one of the PNC Q-omni direction. Since the device trained his RX with the PNC TX during beacon section, the device knows what this direction should be. In AAS, the direction of Imm-ACK for associate Request CMD in association S-CAP, should be defined using the "best PNC Tx Q-omni direction index" IE, but the procedure is not defined. Other option is to use no-ACK policy and keep sending Association Request commands until Association Response is received.
define procedure for direction association using Q-omni pattern
Accept partially. We do have the procedure as mentioned in the comment. The mentioned IE is defined as “Response Tx sector” in Association request. The information is sent with Association request command in S-CAPs for devices to inform PNC which direction is PNC’s best Tx direction. After the PNC receive the association request command, the Imm-Ack is sent through the direction specified in this field. The details of procedure is specified in
Suggest to change the field name as what commenter mentioned with modifications as “best PNC Tx Q-omni pattern”.

9. Comment 72
Comment #
Subclause
Comment
Proposed Change 72
Bar
13.5
P161 L1
Where is the associate Response CMD sent? Is it on the Regular S-CAP? According to ( page 164), this command is sent using CAP or MCTA
define procedure for direction association using Q-omni pattern
Accept in principle. The associate response CMD is also sent in Association S-CAP. To clarify this, add the following sentence in P46, L26
“The association section CAP shall be used solely for devices to send association request commands to the PNC or for PNC to send association response commands to the DEVs. ”
The clear directional association procedure is specified in

10. Comment 73
Comment #
Subclause
Comment
Proposed Change 73
Bar
13.5
P161 L1
Associate Response CMD is sent using no-ack policy, w/ ATP. This is tricky since a DEV did not train the PNC yet, so the PNC does not know what S-CAP to use, and sending response in multiple direction may cause races w/ the time out counter..This could be avoided since best Q-omni direction information is avaliable to the device (should be the direction of the association S-CAP the PNC ACKed the first associate Request CMD). but the procedure is not defined
define procedure for direction association using Q-omni pattern
No change required. The text of mentioned procedure are already in After a DEV receive beacon, the DEV knows the best Q-omni transmit pattern of PNC and the best Q-omni receive pattern of itself. Then the DEV sends multiple of Association Request Commands with information of PNC's best Q-omni transmit pattern from each of the DEV’s quasi-omni transmit pattern during association S-CAPs until it receives an Association Response command successfully or association timeout. So PNC just needs to send association response from its best Q-omni transmit pattern whenit receives association request at some S-CAP .

11. Comment 74
Comment #
Subclause
Comment
Proposed Change 74
13.5
in SAS there is no need for feedback for training, but such procedure is not defined
define procedure for SAS training w/o feedback , where each DEV trains its peers by sending repetitions of training sequence in each direction.
Reject. No change required. The feedback substage in SAS beam training is necessary. In SAS beam training, only one direction training is conducted, namely training from DEV1 to DEV2 , after this training DEV2 knows what are the DEV1’s best transmit and DEV2’s receive sector/beam, but DEV1 has not known yet. So it is necessary for DEV2 to feedback this information to DEV1. Off course, if the training sequences are sent for both directions, as Bar’s proposal, open training for DEV1-to- DEV2 and DEV2-to-DEV1, the feedback for training is not necessary, however it may increase the overhead and it is also a big risk due to the open loop since any end of link may not know whether the counterpart really finds the best direction or not. Since the better close loop training has already been documented, it is no reason to go back.

12. Comment 122
Comment #
Subclause
Comment
Proposed Change
122
Tuncer 13
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
When DEV1 requests a CTA from the PNC to perform beamforming with DEV2 it should tell the PNC the number of levels it wants to perform during this CTA.
Accept in principle. However instead of exchange this information during CTA request. It is suggested to add a field “End of training” in feedback IE defined in
Change Figure 48q- Feedback information element format from To
Add the following statement in
The field “End of training” is used to indicate the end of the training stage. Any DEV who wants to terminate the training stage from the beam training level shall set this field from 0 to 1 during sector level training period. However if one of DEVs (say DEV1) sets the field to 1 but the other (say DEV2) does not, the DEV1 shall help the DEV2 to finish beam level training by using DEV1 ‘s best transmit and receive sectors.

13. Comment 187 Accept. Unify them in ms. Change as follows
Subclause
Comment
Proposed Change
187
James
7.4.28
P36, L11
The values in the table increase by a factor of 2 except for 1000 to 1001, which increases by a factor of 2000
The tracking period should probably all be in units of ms or in units of microseconds. I would think that ms is what makes sense.
Accept. Unify them in ms.
Change as follows
64 us -> 0.064ms
128 us -> 0.128ms
256 us ->0.256 ms
512 us -> ms