1. doc.: IEEE 802.11-10/0494r1 Submission May 2010 Carlos Cordeiro, Intel, et. al.Slide 1 Relay Operation in IEEE 802.11ad Date: 2010-05-01 Author(s): NameCompanyAddressPhoneemail Abu-Surra, ShadiSamsungsasurra@sta.samsung.com Ban, KoichiroToshibakoichiro.ban@toshiba.co.jp Banerjea, RajaMarvellrajab@marvell.com Basson, GalWilocitygal.basson@wilocity.com Blanksby, AndrewBroadcomandrew.blanksby@broadcom.com Borges, DanielAppledrborges@apple.com Borison, DavidRalinkdavid_borison@ralinktech.com Chang, KapseokETRIkschang@etri.re.kr Chu, LiwenSTMicroelectronicsLiwen.chu@st.com Chung, Hyun KyuETRIhkchung@etri.re.kr Coffey, SeanRealtekcoffey@realtek.com Cordeiro, CarlosIntelCarlos.Cordeiro@intel.com Dorsey, JohnApplejdorsey@apple.com Elboim, YaronWilocityyaron.elboim@wilocity.com Fischer, MatthewBroadcommfischer@broadcom.com Giraud, ClaudeNXPclaude.giraud@nxp.com Golan, ZivWilocityZiv.golan@wilocity.com Gong, MichelleIntelMichelle.x.gong@intel.com Grieve, DavidAgilentdavid_grieve@agilent.com

2. doc.: IEEE 802.11-10/0494r1 Submission May 2010 Slide 2 Author(s): NameCompanyAddressPhoneemail Grodzinsky, MarkWilocityMark.grodzinsky@wilocity.com Hansen, ChristopherBroadcomchansen@broadcom.com Hart, BrianCiscobrianh@cisco.com Hassan, AmerMicrosoftamerh@microsoft.com Hong, Seung EunETRIiptvguru@etri.re.kr Hosoya, KenichiNECk-hosoya@ce.jp.nec.com Hosur, SrinathTexas Instrumentshosur@ti.com Hsu, AlvinMediaTekalvin.hsu@mediatek.com Hsu, JulanSamsungJulan.hsu@samsung.com Hung, Kun-ChienMediaTekkc.hung@mediatek.com Jain, AvinashQualcommavinashj@qualcomm.com Jauh, AlanMediaTekalan.jauh@mediatek.com Jeon, PaulLGEbjjeon@lge.com Jin, SunggeunETRIsgjin@etri.re.kr Jones, VKQualcommvkjones@qualcomm.com Joseph, StacyBeam Networksstacy@beamnetworks.com Jun, HaeyoungSamsungHaeyoung.jun@samsung.com Kaaja, HaraldNokiaharald.kaaja@nokia.com Kafle, Padam Nokiapadam.kafle@nokia.com Kakani, Naveen Nokianaveen.kakani@nokia.com Kasher, Assaf IntelAssaf.kasher@intel.com Kasslin, Mika Nokiamika.kasslin@nokia.com Kim, Hodong Samsunghodong0803.kim@samsung.com Kim, Yongsun ETRIdoori@etri.re.kr Kreifeldt, RickHarman Internationalrick.kreifeldt@harman.com Kwon, Edwin Samsungcy.kwon@samsung.com Kwon, Hyoungjin ETRI kwonjin@etri.re.kr Kwon, Hyukchoon Samsunghyukchoon.kwon@samsung.com Laine, Tuomas Nokiatuomas.laine@nokia.com Carlos Cordeiro, Intel, et. al.

3. doc.: IEEE 802.11-10/0494r1 Submission Author(s): NameCompanyAddressPhoneemail Lakkis, Ismail Tensorcomilakkis@tensorcom.com Lee, Hoosung ETRIhslee@etri.re.kr Lee, KeithAMDkeith.lee@amd.com Lee, WooyongETRIwylee@etri.re.kr Liu, Yong Marvellyongliu@marvell.com Lou, Hui-Ling Marvellhlou@marvell.com Majkowski, Jakub Nokiajakub.majkowski@nokia.com Marin, Janne Nokiajanne.marin@nokia.com Maruhashi, Kenichi NECk-maruhashi@bl.jp.nec.com Matsumoto, Taisuke Panasonicmatsumoto.taisuke@jp.panasonic.com Meerson, Yury WilocityYury.meerson@wilocity.com Mese, Murat Broadcommesem@broadcom.com Montag, Bruce Dellbruce_montag@dell.com Myles, Andrew Ciscoamyles@cisco.com Nandagopalan, Saishankar Broadcomnsai@broadcom.com Ngo, Chiu SamsungChiu.ngo@samsung.com Nikula, Eero Nokiaeero.nikula@nokia.com Park, DS Samsungdspark@samsung.com Park, Minyoung IntelMinyoung.park@intel.com Pi, Zhouyue Samsungzpi@sta.samsung.com Ponnampalam, Vish MediaTekvish.ponnampalam@mediatek.com Prasad, Narayan NECprasad@nec-labs.com Prat, Gideon IntelGideon.prat@intel.com Ramachandran, Kishore NECkishore@nec-labs.com Raymond, Yu Zhan PanasonicRaymond.Yuz@sg.panasonic.com Ronkin, Roee WilocityRoee.ronkin@wilocity.com Rozen, Ohad WilocityOhad.rozen@wilocity.com Sachdev, DevangNVIDIAdsachdev@nvidia.com Sadri, AliIntelAli.S.Sadri@intel.com Sampath, HemanthQualcommhsampath@qualcomm.com Slide 3Carlos Cordeiro, Intel, et. al. May 2010

4. doc.: IEEE 802.11-10/0494r1 Submission Author(s): NameCompanyAddressPhoneemail Sanderovich, Amichai WilocityAmichai.sanderovich@wilocity.com Sankaran, Sundar AtherosSundar.Sankaran@Atheros.com Scarpa, Vincenzo STMicroelectronicsvincenzo.scarpa@st.com Seok, Yongho LGEyongho.seok@lge.com Shao, Huai-Rong Samsunghr.shao@samsung.com Shen, Ba-Zhong Broadcombzshen@broadcom.com Sim, Michael PanasonicMichael.Simhc@sg.panasonic.com Singh, Harkirat Samsunghar.singh@sisa.samsung.com Soffer, Menashe IntelMenashe.soffer@intel.com Song, SeunghoSK Telecomshsong@sktelecom.com Sorin, Simha WilocitySimha.sorin@wilocity.com Smith, Matt Atherosmatt.smith@atheros.com Stacey, Robert IntelRobert.stacey@intel.com Sutskover, Ilan IntelIlan.sutskover@intel.com Taghavi, Hossain Qualcommmtaghavi@qualcomm.com Takahashi, Kazuaki Panasonictakahashi.kazu@jp.panasonic.com Trachewsky, Jason Selfjtrachewsky@gmail.com Trainin, Solomon IntelSolomon.trainin@intel.com Usuki, Naoshi Panasonicusuki.naoshi@jp.panasonic.com Varshney, Prabodh Nokiaprabodh.varshney@nokia.com Vertenten, Bart NXPbart.vertenten@nxp.com Vlantis, George STMicroelectronicsgeorge.vlantis@st.com Wang, Chao-Chun MediaTekchaochun.wang@mediatek.com Wang, HomberTMChomber@emcite.com Wang, James MediaTekjames.wang@mediatek.com Yee, James MediaTekjames.yee@mediatek.com Yucek, Tevfik AtherosTevfik.Yucek@Atheros.com Yong, Su Khiong Marvellskyong@marvell.com Zhang, Hongyuan Marvellhongyuan@marvell.com Slide 4Carlos Cordeiro, Intel, et. al. May 2010

5. doc.: IEEE 802.11-10/0494r1 Submission Proposal overview This presentation is part and is in support of the complete proposal described in 802.11-10/432r0 (slides) and 802.11-10/433r0 (text) that: –Supports data transmission rates up to 7 Gbps –Supplements and extends the 802.11 MAC and is backward compatible with the IEEE 802.11 standard –Enables both the low power and the high performance devices, guaranteeing interoperability and communication at gigabit rates –Supports beamforming, enabling robust communication at distances beyond 10 meters –Supports GCMP security and advanced power management –Supports coexistence with other 60GHz systems –Supports fast session transfer among 2.4GHz, 5GHz and 60GHz May 2010 Carlos Cordeiro, Intel, et. al.Slide 5

6. doc.: IEEE 802.11-10/0494r1 Submission Outline Introduction mmWave Relay Operation Common Relay Setup Link Switching Type Link Cooperating Type Relay Operation-type Change Conclusion Appendix Kapseok Chang, ETRISlide 6 May 2010

7. doc.: IEEE 802.11-10/0494r1 Submission Introduction (1/3) Problem statement for 60 GHz channel –P1: High directivity and High path loss Large free space path loss (22 dB higher than 5GHz [1]) Resulting in shortening communication coverage (or range) –P2: High penetration loss by human or wall 60GHz ray cannot penetrate most walls and doors. High penetration loss (e.g., human body ~18 to 36 dB [2]) Resulting in no or lower-rate communication between source and destination STAs Kapseok Chang, ETRISlide 7 May 2010

8. doc.: IEEE 802.11-10/0494r1 Submission Introduction (2/3) Current solution of P1 –Beam-forming (BF) Previous 60 GHz standards have sought for coverage up to 10 meters in some NLOS PHY channel conditions. It is insufficient to further extend coverage with maintaining required throughput in indoor 60 GHz wireless environments [3]. Current solution of P2 –Beam-steering A bad link detection and then scheduling of next best beam direction It is insufficient in case of no reflector nearby or insufficient one [3]. –Fast session transfer (60 GHz  2.4/5 GHz) in current TGad functional requirements Coverage extension, but throughput reduction Kapseok Chang, ETRISlide 8 May 2010

9. doc.: IEEE 802.11-10/0494r1 Submission Introduction (3/3) In order to complement current solutions of P1 and/or P2, we support relay operation with the aid of relay- supportable STA as follows, –Relay operation Link switching type Link cooperating type –Relay Operation-type Change According to link channel quality, type change can be made. May 2010 Kapseok Chang, ETRISlide 9

10. doc.: IEEE 802.11-10/0494r1 Submission mmWave Relay Operation (1/3) Relaying allows a source relay usable mSTA (RUS) to transmit frames to a destination relay usable mSTA (RUS) with the assistance of another mSTA called the relay supportable mSTA (RSUS). A source RUS, a destination RUS and an RUS establish two types of relay operation –Link switching –Link cooperating, and Relay Operation-type Change Kapseok Chang, ETRISlide 10 Direct link (S-D) Relay link S-R Relay link (R-D) Source RUS (‘S’) Destination RUS (‘D’) RSUS (‘R’) May 2010

11. doc.: IEEE 802.11-10/0494r1 Submission mmWave Relay Operation (2/3) Link Switching type –If the S-D direct PHY link is disrupted, the source RUS redirects the transmission of frames addressed to the destination RUS via the RSUS. –Direct link between the source RUS and destination RUS can resume after the direct link between them is recovered. –For realization of the link switching, it is needed as follows, Common Relay setup procedures including BF procedure via relay Frame exchange and link feedback rule Kapseok Chang, ETRISlide 11 S-D Direct link S-R Relay link R-D Relay link Source RUS Destination RUS RSUS May 2010

12. doc.: IEEE 802.11-10/0494r1 Submission mmWave Relay Operation (3/3) Link Cooperating type –The RSUS is actively involved in the direct link communication between S-D. At the same time, a frame transmission from the source RUS to the destination RUS is repeated by the RSUS. –It can possibly increase the signal quality received at the destination RUS. –For realization of the Link cooperating, it is needed as follows, Additional Relay setup procedure (i.e., Transmission time-Point Adjustment (TPA)) for Receive multi-synchronization at the destination RUS Frame exchange and link feedback rule Kapseok Chang, ETRISlide 12 S-D Direct link S-R Relay linkR-D Relay link Source RUS Destination RUS RSUS STA Cooperation May 2010

13. doc.: IEEE 802.11-10/0494r1 Submission Common Relay Setup Kapseok Chang, ETRISlide 13 May 2010

14. doc.: IEEE 802.11-10/0494r1 Submission Contents Objective Common Relay Link Setup –Relay capabilities and RSUS discovery procedures –RSUS selection procedure –RLS (Relay link Setup) procedure Kapseok Chang, ETRISlide 14 May 2010

15. doc.: IEEE 802.11-10/0494r1 Submission Objective We describe the procedures that a source RUS, a destination RUS and an RSUS employ to setup a relay operation among these STAs. These procedures are commonly used for both –Link Switching type –Link Cooperating type In the order we perform the following procedures: –Relay capabilities and RSUS discovery procedures –RSUS selection procedure –RLS procedure Kapseok Chang, ETRISlide 15 May 2010

16. doc.: IEEE 802.11-10/0494r1 Submission Relay Link Setup (1/11) Simple scenario considered for explanation –There exist a PCP/AP, a source RUS, RSUS, and destination RUS. –The number of RSUSs can be multiple within a BSS. –The considered scenario is shown in below Kapseok Chang, ETRISlide 16 May 2010

17. doc.: IEEE 802.11-10/0494r1 Submission Relay Link Setup (2/11) Relay capabilities and RSUS discovery procedures –The source STA that intends to setup relay operation with a destination STA shall obtain the relay capabilities of the destination STA prior to initiating the relay setup procedure with the destination STA. –The source STA shall only attempt to setup relay operation with the destination STA if both STAs are RUS, and there exists at least one RSUS in the BSS. –  Relay Capabilities Information Element Kapseok Chang, ETRISlide 17 May 2010

18. doc.: IEEE 802.11-10/0494r1 Submission Relay Link Setup (3/11) Relay capabilities and RSUS discovery procedures (cont’d) –  Relay Capabilities Information Element (IE) (cont’d) This IE is embedded in the Beacon, Association Request/Response, Information Request/Response. The sub-filed definition in the Relay Capabilities Info field –Relay Supportability Indicates that STA is capable of relaying via itself by transmitting and receiving frames between a pair of other STAs. A STA supporting relay is named “relay STA”. Set to 1 if STA is relay supportable. OW set to 0. Kapseok Chang, ETRISlide 18 May 2010

19. doc.: IEEE 802.11-10/0494r1 Submission Relay Link Setup (4/11) Relay capabilities and RSUS discovery procedures (cont’d) –  Relay Capabilities Information Element (IE) (cont’d) The sub-filed definition in the Relay Capabilities Info field (cont’d) –Relay Usability Indicates that STA is capable of using frame-relaying through a relay STA. Set to 1 if STA is relay usable. OW set to 0. –Relay Permission Indicates whether the PCP/AP allows relay operation to be used within his BSS. Set to 1 if relay operation is allowed. OW set to 0. Kapseok Chang, ETRISlide 19 May 2010

20. doc.: IEEE 802.11-10/0494r1 Submission Relay Link Setup (5/11) Relay capabilities and RSUS discovery procedures (cont’d) –  Relay Capabilities Information Element (IE) (cont’d) The sub-filed definition in the Relay Capabilities Info field (cont’d) –A/C Power Indicates that relay STA is capable of obtaining A/C power. Set to 1 if relay STA is being supplied by A/C power. OW set to 0. –Mobility Indicates that relay STA is capable of support mobility. Set to 1 if relay STA is capable of supporting mobility. OW set to 0. Kapseok Chang, ETRISlide 20 May 2010

21. doc.: IEEE 802.11-10/0494r1 Submission Relay Link Setup (6/11) Relay capabilities and RSUS discovery procedures (cont’d) –  Relay Capabilities Information Element (IE) (cont’d) The sub-filed definition in the Relay Capabilities Info field (cont’d) –Relay Preference Indicates that a STA prefers to become RSUS rather than RUS. Set to 1 if a STA prefers to be RSUS. OW set to 0. –Duplex Indicates whether relay STA is capable of full duplex and amplify-and- forward (FD/AF) or half duplex and decode-and-forward (HD/DF). Set to 01 (only FD/AF). Set to 10 (only HD/AF). Set to 11 (both FD/AF and HD/AF). The value 00 is reserved. Kapseok Chang, ETRISlide 21 May 2010

22. doc.: IEEE 802.11-10/0494r1 Submission Relay Link Setup (7/11) Relay capabilities and RSUS discovery procedures (cont’d) –  Relay Capabilities Information Element (IE) (cont’d) The sub-filed definition in the Relay Capabilities Info field (cont’d) –Cooperation Indicates whether a STA is capable of supporting Link Cooperating type. Set to 1 if a STA supports both Link Cooperating and Link Switching types. Set to 0 if a STA supports only Link Switching or if the Duplex field is set to 01. Kapseok Chang, ETRISlide 22 May 2010

23. doc.: IEEE 802.11-10/0494r1 Submission Relay Link Setup (8/11) Relay capabilities and RSUS discovery procedures (cont’d) Kapseok Chang, ETRISlide 23 May 2010

24. doc.: IEEE 802.11-10/0494r1 Submission Relay Link Setup (9/11) RSUS selection procedure Kapseok Chang, ETRISlide 24 May 2010

25. doc.: IEEE 802.11-10/0494r1 Submission Relay Link Setup (10/11) RSUS selection procedure (cont’d) –The selection of the RSUS is implementation-dependent, and it can be based on information contained within an RSUS’s Relay capability and channel quality. Kapseok Chang, ETRISlide 25 May 2010

26. doc.: IEEE 802.11-10/0494r1 Submission Relay Link Setup (11/11) Relay Link Setup (RLS) procedure Kapseok Chang, ETRISlide 26 May 2010

27. doc.: IEEE 802.11-10/0494r1 Submission Link Switching Type Kapseok Chang, ETRISlide 27 May 2010

28. doc.: IEEE 802.11-10/0494r1 Submission Contents SP Request and Allocation Frame Exchange Rules for FD/AF Relay Frame Exchange Rules for HD/DF Relay May 2010 Kapseok Chang, ETRISlide 28

29. doc.: IEEE 802.11-10/0494r1 Submission SP Request and Allocation By using an ADDTS Request frame for which the source AID and the destination AID fields within the Extended mmWave TSPEC element are equal to, respectively, the source RUS and the destination RUS pair, the source RUS requests an SP to the PCP/AP The PCP/AP schedules an SP with the source STA as the source RUS and the destination STA as the destination RUS. The selected RSUS shall check the value of the source AID and the destination AID fields of each SP allocation within an Extended Schedule element it receives in a mmWave Beacon or Announce frame from the PCP/AP. –If the value of the source AID and the destination AID fields of an SP allocation correspond to the source RUS and the destination RUS, the RSUS is allowed to operate as an RSUS during that SP allocation. Kapseok Chang, ETRISlide 29 May 2010

30. doc.: IEEE 802.11-10/0494r1 Submission Frame Exchange Rules for FD/AF Relay (1/4) Link Change Interval –Indicates an opportunity to change the link used for communication. Data Sensing Time –Indicates the defer time offset from the start of the next Link Change Interval when current link is unavailable, for implicit signaling for link switching. Kapseok Chang, ETRISlide 30 May 2010

31. doc.: IEEE 802.11-10/0494r1 Submission Frame Exchange Rules for FD/AF Relay (2/4) A source RUS shall use the direct link to initiate frame transmission to the destination RUS at the start of the first SP allocated between the source RUS and destination RUS. Kapseok Chang, ETRISlide 31 May 2010

32. doc.: IEEE 802.11-10/0494r1 Submission Frame Exchange Rules for FD/AF Relay (3/4) If a source RUS transmits a frame to the destination RUS via the direct link but does not receive an expected ACK frame or BA frame from the destination RUS during a Link Change Interval period, –the source RUS shall start its frame transmission after Data Sensing Time from the start of the following Link Change Interval period and use the RSUS to forward frames to the destination RUS. Kapseok Chang, ETRISlide 32 May 2010

33. doc.: IEEE 802.11-10/0494r1 Submission Frame Exchange Rules for FD/AF Relay (4/4) The destination does not receive a valid frame from the source within Data Sensing Time after the start of a Link Change Interval, the destination shall immediately change the link to attempt to receive frames from the source through the RSUS, which is a sort of implicit signaling for link switching. Kapseok Chang, ETRISlide 33 May 2010

34. doc.: IEEE 802.11-10/0494r1 Submission Frame Exchange Rules for HD/DF Relay (1/4) A source RUS shall use the direct link to initiate frame transmission to the destination RUS at the start of the first SP allocated between the source RUS and destination RUS. If the direct link is used in communication, Link Change Interval is employed. If the relay link is used in communication, 1st and 2nd Periods are employed. Kapseok Chang, ETRISlide 34 May 2010

35. doc.: IEEE 802.11-10/0494r1 Submission Frame Exchange Rules for HD/DF Relay (2/4) If a source RUS transmits a frame to the destination RUS via the direct link but does not receive an expected ACK frame or BA frame from the destination RUS during a Link Change Interval period, –the source RUS should change the link used for frame transmission at the start of the following First Period and transmit frames to the RSUS. Kapseok Chang, ETRISlide 35 May 2010

36. doc.: IEEE 802.11-10/0494r1 Submission Frame Exchange Rules for HD/DF Relay (3/4) In the First Period, –the source RUS shall transmit a frame to the RSUS. In this case, the destination RUS can implicitly indicate that the link switching happens. And then the RSUS responds within SIFS. In the Second Period, –the RSUS shall forward the frame received from the source RUS to the destination RUS. –Then the destination RUS responds within SIFS. Kapseok Chang, ETRISlide 36 May 2010

37. doc.: IEEE 802.11-10/0494r1 Submission Frame Exchange Rules for HD/DF Relay (4/4) The source RUS may transmit a Relay ACK Request frame to the RSUS to determine whether all frames forwarded through the RSUS were successfully received by the destination RUS. Upon reception of a Relay ACK Request frame, the RSUS shall respond with a Relay ACK Response frame and set the BlockAck Bitmap field to indicate which frames have been successfully received by the destination RUS. Kapseok Chang, ETRISlide 37 May 2010

38. doc.: IEEE 802.11-10/0494r1 Submission Link Cooperating Type Kapseok Chang, ETRISlide 38 May 2010

39. doc.: IEEE 802.11-10/0494r1 Submission Contents TPA (Transmission time-Point Adjustment) Procedure SP Request and Allocation Data Transmission Rules Kapseok Chang, ETRISlide 39 May 2010

40. doc.: IEEE 802.11-10/0494r1 Submission TPA (Transmission time-Point Adjustment) Procedure (1/5) A source RUS, a destination RUS, and an RSUS that wish to setup a link cooperating relay shall additionally perform the TPA procedure, to establish a link cooperating relay. Motivation on this procedure –For Link Cooperating, the received signal from the source RUS and that from the RSUS should be multi-synchronized at the destination RUS in order to avoid the ICI (OFDM transmission mode) or the ISI (SC transmission mode). For example, if the distance difference between S-D and R-D links is higher than about 7.5m, the arrival time deviation between them exceeds the cyclic prefix duration, which leads to ICI. Even if the time deviation is within CP, ICI may occurs owing to the delay spread from S. Kapseok Chang, ETRISlide 40 May 2010

41. doc.: IEEE 802.11-10/0494r1 Submission TPA Procedure (2/5) For estimating the arrival timing offsets from S and R –D sends R and S their TPA Request frames sequentially. Request the Transmission time-Point Adjustment for R and S. Include the pre-defined time (Dtime) when for R and S to transmit their TPA Response frame to D for TPA estimation at D. –Just after Dtime plus each propagation delay, R and S send their TPA Response frames to D, respectively. Kapseok Chang, ETRI May 2010

42. doc.: IEEE 802.11-10/0494r1 Submission TPA Procedure (3/5) For estimating the arrival timing offsets from S and R (cont’d) –Then, D estimates the time deviations (i.e., 2*dT DR, 2*dT DS ) between Dtime and each arrival time from R and S. For estimating the propagation delay from S to R –It is necessary that S should know the starting-time when R transmits data to D. Kapseok Chang, ETRI May 2010

43. doc.: IEEE 802.11-10/0494r1 Submission TPA Procedure (4/5) For estimating the propagation delay from S to R (cont’d) –S sends R its TPA Request frame. Include the pre-defined time (Dtime) when for R to transmit its TPA Response frame to S for propagation delay (dT SR ) estimation. –Just after Dtime plus dT SR, R sends its TPA Response frame to S. –Then, S estimates the time deviation (i.e., 2*dT SR ) between Dtime and the arrival time from R. Kapseok Chang, ETRI May 2010

44. doc.: IEEE 802.11-10/0494r1 Submission TPA Procedure (5/5) For giving R its transmission time-point adjustment information –After the time when R transmits the TPA Response frame to S, D sends R its TPA Request frame that Includes the pre-defined time (Dtime) when for R to transmit its TPA Response frame to D. The timing offset adjustment value (i.e., dT DS -dT DR ) that enables R to transmit its TPA response frame after (dT DS -dT DR ) time duration from Dtime. –Then, R transmits its TPA Response frame to D for confirmation. Kapseok Chang, ETRI May 2010

45. doc.: IEEE 802.11-10/0494r1 Submission SP Request and Allocation If the source RUS receives a TPA Report frame that indicates the successful completion of the TPA procedure with the RSUS and the destination RUS, –the source RUS uses the procedure in 11.4 to request an SP allocation with the destination RUS. The source RUS can use the SP allocation for communication with the destination RUS with the assistance of the RSUS. Kapseok Chang, ETRISlide 45 May 2010

46. doc.: IEEE 802.11-10/0494r1 Submission Data Transmission Rules (1/4) In the allocated SP, T1 and T2 for a cooperated data frame transfer are determined by the packet transmission time at each transmission from the source RUS to the destination RUS within the SP. Kapseok Chang, ETRISlide 46 May 2010

47. doc.: IEEE 802.11-10/0494r1 Submission Data Transmission Rules (2/4) At the start of each time T1, the source RUS transmits a frame with its transmit antenna pattern directed towards the RSUS and with the TA and the RA fields in the MAC header set to the MAC address of the source RUS and destination RUS, respectively. Kapseok Chang, ETRISlide 47 May 2010

48. doc.: IEEE 802.11-10/0494r1 Submission Data Transmission Rules (3/4) After Ptime+dT SR from the start of T2, the source RUS retransmits the same frame sent to the RSUS during the previous time T1 but now with its transmit antenna pattern directed towards the destination RUS. Similarly, after Ptime+(dT DS - dT DR ) from the start of T2, the RSUS relays the same frame it received from the source RUS during the previous time T1 with its transmit antenna pattern directed towards the destination RUS. Kapseok Chang, ETRISlide 48 May 2010

49. doc.: IEEE 802.11-10/0494r1 Submission Data Transmission Rules (4/4) So that the destination RUS can take advantage of the improved received signal level from both of these transmissions, the destination RUS should set its receive antenna pattern during T2 such that it simultaneously covers the links towards both the source RUS and the RSUS. The Ack policy used during an SP where link cooperation is in use is the same as defined in clause 9. Kapseok Chang, ETRISlide 49 May 2010

50. doc.: IEEE 802.11-10/0494r1 Submission Relay Operation-type Change (ROC) Kapseok Chang, ETRISlide 50 May 2010

51. doc.: IEEE 802.11-10/0494r1 Submission Contents Motivation Procedure of changing from link-cooperating to link- switching Procedure of changing from link-switching to link- cooperating Kapseok Chang, ETRISlide 51 May 2010

52. doc.: IEEE 802.11-10/0494r1 Submission Motivation If either one of S-D, or S-R, or R-D links becomes unavailable or for other reasons, the source RUS may change the relay operation type from link switching to link cooperating, and vice-versa. To assist in this decision, the source RUS may use the link adaptation procedure (11.37.5) to obtain the quality of a link. ROC Procedure –If the source RUS catches one of events to trigger the ROC, then it initiates the ROC procedure by transmitting a ROC Request action frame. –The corresponding RSUS and destination RUS may respond with a ROC Response action frame. –Two procedures Procedure of changing from link-cooperating to link-switching Procedure of changing from link-switching to link-cooperating Kapseok Chang, ETRISlide 52 May 2010

53. doc.: IEEE 802.11-10/0494r1 Submission Procedure of changing from Link Cooperating to Link Switching (1/2) Kapseok Chang, ETRISlide 53 May 2010

54. doc.: IEEE 802.11-10/0494r1 Submission Procedure of changing from Link Cooperating to Link Switching (2/2) Kapseok Chang, ETRISlide 54 May 2010

55. doc.: IEEE 802.11-10/0494r1 Submission Procedure of changing from Link Switching to Link Cooperating Kapseok Chang, ETRISlide 55 May 2010

56. doc.: IEEE 802.11-10/0494r1 Submission Conclusion Link Switching type –Simple blocking avoidance mechanism (blocking detection and detour) –A complement to beamforming technology –When the HD/DF at RSUS is employed, the throughput can be decreased to half. Link Cooperating type –We don’t need multi-preamble structure for estimating the channel state information of multiple links (e.g., S-D and R-D links). –Depending on RSUS position between source and destination RUSs, using both DLS and relay links even in HD/DF mode can enhance more throughput over only direct link communication owing to path-loss and diversity gains [6]. Relay Operation-type Change –By monitoring the link quality for each of S-D, S-R, and R-D links, and employing ROC, we can realize a seamless communication. Kapseok Chang, ETRISlide 56 May 2010

57. doc.: IEEE 802.11-10/0494r1 Submission References [1] Sai Nandagopalan, Carlos Cordeiro, Mathew Fischer, Solomon Trainin, Jason Trachewsky, Vinko Erceg, James Yee, Chao Chun Wang, Yong Liu, Hongyuan Zhang, Huai-Rong Shao, Julan Hsu, Gal Basson, and Matt Smith, “MAC channel access in 60 GHz,” IEEE 802.11-09/0572r0, May 2009. [2] S.K. Yong, “TG3c channel modeling sub-committee final report,” IEEE 802.15-06-0195-07-003c, Nov. 2006. [3] K. Chang et al., “Service Coverage Extension,” IEEE 802.11-09/0769r0. [4] A. Sendonaris, E. Erkip, and B. Aazhang, “User cooperation diversity-part I: System description,” IEEE Trans. Commun., vol. 51, pp. 1927-1938, Nov. 2003. [5] Joffray Guillory, “Radio over Fiber for an optimal 60 GHz Home Area Network,” IEEE 802.11-10-0011-00-00ad, Jan. 2010. [6] K. Chang, W.Y. Lee, and H.K. Chung, “Achievable rates of cooperative relaying schemes applied in beamforming mode,” IEEE CCNC 2010, Jan. 2010. Kapseok Chang, ETRISlide 57 May 2010

58. doc.: IEEE 802.11-10/0494r1 Submission Appendix Kapseok Chang, ETRISlide 58 May 2010

59. doc.: IEEE 802.11-10/0494r1 Submission Usage of RSUS in Link Switching Type Transmission mode of FD/AF RSUS –Normal mode: a pair of source RUS and destination RUS exchange frames via either the direct link or the relay link until this link is determined to become unavailable due to, for example, blockage or channel degradation. –Alternation mode: a pair of source RUS and destination RUS will exchange frames with two links alternatively. An RSUS that supports only HD/DF shall operate in the Normal mode. The frame transmission mode is indicated in the Relay Transfer Parameter Set element (see 7.3.2.72) exchanged by the source RUS, destination RUS, and RSUS during the RLS procedure. A source RUS or destination RUS may change the transmission mode used in a relay link following a successful exchange of RLS Request and RLS Response frames as described in 11.37.1.3. Kapseok Chang, ETRISlide 59 Kapseok Chang, ETRISlide 59 May 2010

60. doc.: IEEE 802.11-10/0494r1 Submission FD/AF RSUS in Link Switching Type Assumptions on FD/AF RSUS –Have at least two RF chains for receiving signal and at the same time, sending it –Switch the mode of two RF chains, (Rx->Tx and Tx->Rx) –Decode and encode 11ad compatible frames Kapseok Chang, ETRISlide 60 May 2010

61. doc.: IEEE 802.11-10/0494r1 Submission RF Mode Switching of RSUS in Link Switching Type (1/3) In general, data frame and its ACK go through RSUS in reverse direction. Since the time when the RSUS needs to receive ACK can be changed according to the ACK Policy, the RSUS should have the method for predicting the transmission direction of next data before data reach the RSUS. For this, the RSUS shall decode the relayed frame to identify ACK policy from frame header as well as amplify and forwards it at the same time. The RSUS shall switch the mode of each RF chain based on the information extracted from frame header. Kapseok Chang, ETRISlide 61 May 2010

62. doc.: IEEE 802.11-10/0494r1 Submission RF Mode Switching of RSUS in Link Switching Type (2/3) If ACK policy is block ACK with aggregation or immediate ACK, RF mode is switched right after the relaying of one data frame ends. If ACK policy is delayed ACK, RF mode switching is performed only when the data frame includes the delayed ACK request field. Kapseok Chang, ETRISlide 62 May 2010

63. doc.: IEEE 802.11-10/0494r1 Submission RF Mode Switching of RSUS in Link Switching Type (3/3) If the RSUS receives ACK frame, RF mode is switched right after the relaying. Kapseok Chang, ETRISlide 63 May 2010

64. doc.: IEEE 802.11-10/0494r1 Submission Relay Link Adaptation When a relay link is used for communication between a source RUS and a destination RUS, the link qualities of the S-R link, the R-D link, and the S-D link may be required. The source RUS, destination RUS, and RSUS use the procedure described in 9.27 to request and report the link quality among themselves with the following exception. In the Link Margin Response frame the RSUS transmits to the source RUS, the RSUS shall include two Link Margin elements in this order: –The first Link Margin element shall report the link quality between the source RUS and the RSUS –The second Link Margin element shall report the link quality between the RSUS and the destination RUS Upon reception of a Link Margin Response frame, the source RUS can take several actions including changing the MCS it uses for frame transmission to the RSUS and destination RUS. Kapseok Chang, ETRISlide 64 May 2010

65. doc.: IEEE 802.11-10/0494r1 Submission Relay Teardown A source RUS that has successfully completed the RLS procedure with a destination RUS may teardown the relay operation between the source RUS, destination RUS and RSUS. To do that, the source RUS shall transmit an RLS Teardown frame to the RSUS, destination RUS and PCP/AP of the BSS. Within the Relay Teardown frame, the source RUS shall set the source AID field to the AID of the source RUS, the destination AID field to the AID of the destination RUS and the relay AID field to the AID of the RSUS. A RSUS may teardown the relay operation between the source RUS, destination RUS and RSUS. To do that, the RSUS shall transmit an RLS Teardown frame to the source RUS, destination RUS and PCP/AP of the BSS. Within the Relay Teardown frame, the RSUS shall set the source AID field to the AID of the source RUS, the destination AID field to the AID of the destination RUS and the relay AID field to the AID of the RSUS. Kapseok Chang, ETRISlide 65 May 2010

66. doc.: IEEE 802.11-10/0494r1 Submission 7.3 Management frame body components (1/7) 7.3.1.51 Relay Capable STA Info field –The AID field contains the AID of the relay capable STA which is associated with PCP/AP. –The Relay Capabilities Info field is defined in 7.3.2.71.2. 7.3.2 Information elements Kapseok Chang, ETRISlide 66 [Relay STA Info field] [Additional Element IDs] AIDRelay Capabilities Info Bits:B0-B7B8-B15 Information elementElement IDLength (in octets) Relay Capabilities 1 Relay Transfer Parameter set 8 May 2010

67. doc.: IEEE 802.11-10/0494r1 Submission 7.3 Management frame body components (2/7) 7.3.2.71 Relay Capabilities element Kapseok Chang, ETRISlide 67 [Relay Capabilities element format] [Relay Capabilities Info field] Element IDLengthRelay Capabilities Info Octets:112 Relay Supportability Relay Usability Relay Permission A/C Power MobilityRelay Preference DuplexCooperationReserve d Bit B0B1B2B3B4B5B6-B7B8B9-B15 SubfieldDefinitionEncoding Relay SupportabilityIndicates that STA is capable of relaying via itself by transmitting and receiving frames between a pair of other STAs. A STA capable of relaying support is named “relay STA”. Set to 1 if STA is relay supportable. Otherwise set to 0 [Subfields of the Relay Capabilities Info field] May 2010

68. doc.: IEEE 802.11-10/0494r1 Submission 7.3 Management frame body components (3/7) 7.3.2.71 Relay Capabilities element Kapseok Chang, ETRISlide 68 [Subfields of the Relay Capabilities Info field] SubfieldDefinitionEncoding Relay Usability Indicates that STA is capable of using frame-relaying through a relay STA. Set to 1 if STA is relay usable. Otherwise set to 0 Relay Permission Indicates whether the PCP/AP allows relay operation (11.37) to be used within the PCP/AP’s BSS. This field is ignored when transmitted by a non- PCP/non-AP STA. Set to 0 if relay operation is not allowed in the BSS. Set to 1 if relay operation is allowed in the BSS. A/C PowerIndicates that relay STA is capable of obtaining A/C power Set to 1 if relay STA is capable of being supplied by A/C power. Otherwise set to 0. MobilityIndicates that relay STA is capable of support mobility Set to 1 if relay STA is capable to support mobility. Otherwise set to 0. Relay Preference Indicates that a STA prefers to become RSUS rather than RUS Set to 1 if a STA prefers to be RSUS. Otherwise set to 0. May 2010

69. doc.: IEEE 802.11-10/0494r1 Submission 7.3 Management frame body components (4/7) 7.3.2.71 Relay Capabilities element Kapseok Chang, ETRISlide 69 [Subfields of the Relay Capabilities Info field] SubfieldDefinitionEncoding DuplexIndicates whether relay STA is capable of FD/AF or HD/DF. Set to 01 if relay STA is not capable of HD/DF but only capable of FD/AF. Set to 10 if relay STA is capable of HD/DF but not capable of FD/AF. Set to 11 if relay STA is capable of both HD/DF and FD/AF. The value 00 is reserved. CooperationIndicates whether a STA is capable of supporting Link cooperating. Set to 1 if a STA supports both Link cooperating type and Link switching type. Set to 0 if a STA supports only Link switching or if the Duplex field is set to 01. May 2010

70. doc.: IEEE 802.11-10/0494r1 Submission 7.3 Management frame body components (5/7) 7.3.2.72 Relay Transfer Parameter Set element –A source RUS which intends to transfer frames via an RSUS advertizes the parameters for the relay operation with the transmission of a Relay Transfer Parameter Set element. Kapseok Chang, ETRISlide 70 [Relay Transfer Parameter Set element format] Element IDLengthRelay Transfer Parameter Octets:118 Duplex -Mode Cooperation- Mode Tx- Mode ReservedLink Change Interval Data Sensing Time First Period Second Period Reser ved B it: B0B1B2B3-B7B8-B15B16-B23B24- B39 B40- B55 B56- B63 [Relay Transfer Parameter field] May 2010

71. doc.: IEEE 802.11-10/0494r1 Submission 7.3 Management frame body components (6/7) 7.3.2.72 Relay Transfer Parameter Set element –The Duplex-Mode subfield indicates that the source RUS set the duplex mode of the RSUS involved in RLS. The Duplex-Mode subfield value is set to 0 if the RSUS operates in HD/DF mode. It is set to 1 if the RSUS operates in FD/AF mode. –The Cooperation-Mode subfield indicates whether the source RUS sets the link cooperating of the RSUS involved in RLS or not. This subfield is valid only when the RSUS is capable of link cooperating type and Duplex-Mode subfield is set to 0. Otherwise this subfield is ignored. The Cooperation-Mode subfield value is set to 0 if the RSUS operates in link switching type. It is set to 1 if the RSUS operates in link cooperation type. –The Tx-Mode subfield indicates that the source RUS sets the transmission mode of the RSUS involved in RLS. This subfield is valid only when the RSUS is capable of link–switching type and Duplex-Mode subfield is set to 1. Otherwise this subfield is ignored. The Tx-Mode subfield value is set to 0 if a group of three STAs involved in the RLS operates in Normal mode, as defined in 11.37.1.3.2. It is set to 1 if the group operates in Alternation mode, as defined in 11.37.1.3.2. –The Link Change Interval subfield indicates when the link of frame transmission between source RUS and destination RUS is changed. From the start position of one reserved contiguous SP, every time instant of Link Change Interval can have an opportunity to change the link. Within one Link Change Interval, only one link is used for frame transfer. The unit of this field is microseconds. This subfield is used only when the group involved in the RLS operates in link switching type. –The Data Sensing Time subfield indicates the defer time offset from the time instant of the next Link Change Interval when the link switching occurs. By default, it is set to SIFS plus SBIFS. This subfield is used only when the STAs involved in the RLS operate in link switching with Tx-Mode that is set to 0. Kapseok Chang, ETRISlide 71 May 2010

72. doc.: IEEE 802.11-10/0494r1 Submission 7.3 Management frame body components (7/7) 7.3.2.72 Relay Transfer Parameter Set element –The First Period subfield indicates the period of the source RUS- RSUS link in which the source RUS and RSUS exchange frames. This subfield is used only when HD/DF RSUS operates in link switching type. –The Second Period subfield indicates the period of the RSUS- destination RUS link in which the RSUS and destination RUS exchange frames and the following period of the RSUS-source RUS link in which the RSUS informs the source RUS of finishing one frame transfer. This subfield is used only when HD/DF RSUS operates in link switching type. Kapseok Chang, ETRISlide 72 May 2010

73. doc.: IEEE 802.11-10/0494r1 Submission 7.4 Action Frame Format (1/9) mmWave Action frame details Kapseok Chang, ETRISlide 73 Action field valueMeaning NRelay Search Request N+1Relay Search Response N+2Multi-Relays Channel Measurement Request N+3Multi-Relays Channel Measurement Report N+4RLS Request N+5RLS Response N+6RLS Announcement N+7RLS Teardown N+8Relay ACK Request N+9Relay ACK Response N+10TPA Request N+11TPA Response N+12TPA Report N+13ROC Request N+14ROC Response N+15-255Reserved May 2010

74. doc.: IEEE 802.11-10/0494r1 Submission 7.4 Action Frame Format (2/9) Relay Search Request/Response Action Frames Usage –This frame is used for requesting the list of RSUSs’ in BSS/PBSS. –Source RUS sends the request frame to AP/PCP including the destination RUS’s AID for triggering BF between RSUSs and the source RUS and between RSUSs and the destination RUS. –AP/PCP sends a Relay Search Response frame to the source RUS, in order to report RSSs’ AIDs and their Relay Capabilities. Kapseok Chang, ETRISlide 74 OrderInformation 1Category 2Action 3Dialog Token 4Destination RUS AID AIDRelay Capabilities Info Bits:B0-B7B8-B15 OrderInformation 1Category 2Action 3Dialog Token 4Status code 5Relay Capable STA Info 1 …… N+4Relay Capable STA Info N [Relay Search Request Action Frame] [Relay Search Response Action Frame] [Relay Capable STA Info field] May 2010

75. doc.: IEEE 802.11-10/0494r1 Submission 7.4 Action Frame Format (3/9) Multi-Relays Channel Measurement(CM) Request/Report Action Frames Usage –The request frame is transmitted by source RUS to destination RUS in order to obtain channel measurements between RSUSs and destination RUS or to RSUS in order to obtain the one with destination RUS. –The report frame is sent in response to the request frame including the list of RSUS AID and channel measurement between the RSUS and destination RUS Kapseok Chang, ETRISlide 75 OrderInformation 1Category 2Action 3Dialog Token Peer STA AIDSNRInternal AngleRecommendReserved Bits:B0-B7B8-B15B16-B22B23B24-B31 [Multi-Relays CM Request Action Frame][Multi-Relays CM Report Action Frame] [Channel Measurement Info field] OrderInformation 1Category 2Action 3Dialog Token 4Channel Measurement Info 1 …… N+3Channel Measurement Info N May 2010

76. doc.: IEEE 802.11-10/0494r1 Submission 7.4 Action Frame Format (4/9) RLS Request/Response Action Frames Usage –The RLS request frame is used to set up a relayed link with a peer MAC and set Relay Transfer Parameter Set during frame transfer. –The RLS response frame is sent in response to a RLS Request frame. –The status code indicates a result of RLS Request by the STA responding the RLS Request frame. Kapseok Chang, ETRISlide 76 [RLS Request Action Frame][RLS Response Action Frame] OrderInformation 1Category 2Action 3Dialog Token 4Destination AID 5Relay AID 6Source AID 7Destination Capability Information 8Relay Capability Information 9Source Capability Information 10Destination Status Code 11Relay Status Code OrderInformation 1Category 2Action 3Dialog Token 4Destination AID 5Relay AID 6Source AID 7Destination Capability Information 8Relay Capability Information 9Source Capability Information 10RLS Timeout Value 11Relay Transfer Parameter Set May 2010

77. doc.: IEEE 802.11-10/0494r1 Submission 7.4 Action Frame Format (5/9) RLS Announcement/Teardown Action frames RLS Announcement/Teardown Usage –RLS Announcement frame is sent to announce the successful RLS. –RLS Teardown frame is sent to to terminate a relay operation. Kapseok Chang, ETRISlide 77 OrderInformation 1Category 2Action 3Status Code 4Destination AID 5Relay AID 6Source AID [RLS Announcement Action Frame] OrderInformation 1Category 2Action 3Destination AID 4Relay AID 5Source AID 6Reason Code [RLS Teardown Action Frame] May 2010

78. doc.: IEEE 802.11-10/0494r1 Submission 7.4 Action Frame Format (6/9) Relay ACK Request/Response Action frame Usage –These frames are used on behalf of normal ACK in relay link. –The Relay ACK Request frame is sent by an source RUS to an RSUS in order to determine whether all frames forwarded through the RSUS were successfully received by the destination RUS. –The Relay ACK Response frame is sent by an RSUS to a source RUS in order to report which frames have been received by the destination RUS. Kapseok Chang, ETRISlide 78 OrderInformation 1Category 2Action 3BA Control 4BlockAck Starting Sequence Control 5BlockAck Bitmap OrderInformation 1Category 2Action 3BAR Control 4BlockAck Starting Sequence Control [Relay ACK Request Action Frame] [Relay ACK Response Action Frame] May 2010

79. doc.: IEEE 802.11-10/0494r1 Submission 7.4 Action Frame Format (7/9) TPA Request/Response Action frames TFA Request/Response Usage –Refer to TPA mechanism –Timing Offset (2 octets) Indicates the amount by which to change the timing offset of the burst transmission so that bursts arrive at the expected time at the destination RUS. –Response Offset Indicates when the TOA Response frame is transmitted in response to the previous TOA Request frame. –The Sampling Frequency Offset (2 octets) indicates the amount by which to change the sampling frequency offset of the burst transmission so that bursts arrive at the destination STA with no sampling frequency offset. The unit is 0.01 ppm. Kapseok Chang, ETRISlide 79 [TPA Request Action Frame] [TPA Response Action Frame] OrderInformation 1Category 2Action 3Dialog Token 4Timing Offset 5Response Offset 6Sampling Frequency Offset (Optional) OrderInformation 1Category 2Action 3Dialog Token May 2010

80. doc.: IEEE 802.11-10/0494r1 Submission 7.4 Action Frame Format (8/9) TPA Report Action frame –The TPA Report frame is sent to announce whether current TPA procedure defined in 11.37.2.1.5 is failed or not. –The Category field is set to the category for mmWave, specified in Table YYY. –The Action field is set to the value corresponding to TPA Report, specified in Table YYY. –If the Status Code field is set to 1, then it is indicated that current TPA procedure is successful. Otherwise, it is indicated that current TPA procedure is failed. Kapseok Chang, ETRISlide 80 OrderInformation 1Category 2Action 3Status code [TPA Report Action frame] May 2010

81. doc.: IEEE 802.11-10/0494r1 Submission 7.4 Action Frame Format (9/9) ROC Request/Response Action frames Usage –The Link cooperating subfield is set to 0 to indicate that the relay operation type is Link switching and set to 1 to indicate that the relay operation type is Link cooperating. –The Relay-link subfield is set to 0 to indicate that the Link switching operation starts at direct link and set to 1 to indicate that the Link switching operation starts at relay link. Kapseok Chang, ETRISlide 81 OrderInformation 1Category 2Action 3Dialog Token 4Relay operation type Link-cooperatingDetour-linkReserved Bits:B0B1B2-B7 OrderInformation 1Category 2Action 3Dialog Token 4Status code 5Relay operation type [ROC Request Action Frame][ROC Response Action Frame] [Relay operation type field] May 2010