doc.: IEEE 802.15-<doc#> <month year> Project: IEEE P802.15 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 239-0847, Japan; 416 Maetan-3Dong Yeongtong-Gu Suwon-shi Kyunggi-Do 443-742, Korea*; 10875 Rancho Bernardo Rd, #108, San Diego, CA 92127+] Voice1:[+81-46-847-5074] , FAX1: [+81-46-847-5440] E-Mail[junyi.wang@nict.go.jp] 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 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 contributors acknowledge and accept that this contribution becomes the property of IEEE and may be made publicly available by P802.15. <author>, <company>

Comment 62 Comment # Subclause Comment Proposed Change 62 Bar 13.5.1.1 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 8.6.6.1 and Figure 125e in 8.6.6.4 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 8.6.6.1 and Figure 125e in 8.6.6.4 into BSIFS

Comment 66 Comment # Subclause Comment Proposed Change 66 Bar 13.5.1.1 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 12.2.3.1 and 12.2.3.2? 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.

Comment 67 Comment # Subclause Comment Proposed Change 67 Bar 13.5.1.1 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 .

Comment 68 Comment # Subclause Comment Proposed Change 68 Bar 13.5.1.1.1P163 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

Comment 69 Comment # Subclause Comment Proposed Change 69 Bar 13.5.1.1.1P163 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

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.

Comment 71 Comment # Subclause Comment Proposed Change 71 Bar 13.5 P161 L1 According to 15.3b 8.3.1 ( 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 7.5.1.1 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 8.6.6.3. Suggest to change the field name as what commenter mentioned with modifications as “best PNC Tx Q-omni pattern”.

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 15.3-2003 8.3.1 ( 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 8.6.6.3

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 8.6.6.3. 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 .

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.

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 7.4.27 Change Figure 48q- Feedback information element format from To Add the following statement in 7.2.27 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.

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 -> 0.512 ms