doc.: ieee 802.11-10/0494r1 submission may 2010 carlos cordeiro, intel, et. al.slide 1 relay...

doc.: IEEE 802.11-10/0494r1

Submission

May 2010

Carlos Cordeiro, Intel, et. al.Slide 1

Relay Operation in IEEE 802.11adDate: 2010-05-01

Author(s):

Name Company Address Phone email

Abu-Surra, Shadi Samsung [email protected]

Ban, Koichiro Toshiba [email protected]

Banerjea, Raja Marvell [email protected]

Basson, Gal Wilocity [email protected]

Blanksby, Andrew Broadcom [email protected]

Borges, Daniel Apple [email protected]

Borison, David Ralink [email protected]

Chang, Kapseok ETRI [email protected]

Chu, Liwen STMicroelectronics [email protected]

Chung, Hyun Kyu ETRI [email protected]

Coffey, Sean Realtek [email protected]

Cordeiro, Carlos Intel [email protected]

Dorsey, John Apple [email protected]

Elboim, Yaron Wilocity [email protected]

Fischer, Matthew Broadcom [email protected]

Giraud, Claude NXP [email protected]

Golan, Ziv Wilocity [email protected]

Gong, Michelle Intel [email protected]

Grieve, David Agilent [email protected]

doc.: IEEE 802.11-10/0494r1

Submission

May 2010

Slide 2

Author(s):Name Company Address Phone email

Grodzinsky, Mark Wilocity [email protected], Christopher Broadcom [email protected]

Hart, Brian Cisco [email protected], Amer Microsoft [email protected]

Hong, Seung Eun ETRI [email protected], Kenichi NEC [email protected], Srinath Texas Instruments [email protected]

Hsu, Alvin MediaTek [email protected], Julan Samsung [email protected]

Hung, Kun-Chien MediaTek [email protected], Avinash Qualcomm [email protected]

Jauh, Alan MediaTek [email protected], Paul LGE [email protected]

Jin, Sunggeun ETRI [email protected], VK Qualcomm [email protected]

Joseph, Stacy Beam Networks [email protected], Haeyoung Samsung [email protected], Harald Nokia [email protected], Padam Nokia [email protected]

Kakani, Naveen Nokia [email protected], Assaf Intel [email protected], Mika Nokia [email protected], Hodong Samsung [email protected], Yongsun ETRI [email protected], Rick Harman International [email protected], Edwin Samsung [email protected]

Kwon, Hyoungjin ETRI [email protected], Hyukchoon Samsung [email protected]

Laine, Tuomas Nokia [email protected]

Carlos Cordeiro, Intel, et. al.

doc.: IEEE 802.11-10/0494r1

Submission


Lakkis, Ismail Tensorcom [email protected], Hoosung ETRI [email protected]

Lee, Keith AMD [email protected], Wooyong ETRI [email protected]

Liu, Yong Marvell [email protected], Hui-Ling Marvell [email protected]

Majkowski, Jakub Nokia [email protected], Janne Nokia [email protected]

Maruhashi, Kenichi NEC [email protected], Taisuke Panasonic [email protected]

Meerson, Yury Wilocity [email protected], Murat Broadcom [email protected]

Montag, Bruce Dell [email protected], Andrew Cisco [email protected]

Nandagopalan, Saishankar Broadcom [email protected], Chiu Samsung [email protected]

Nikula, Eero Nokia [email protected], DS Samsung [email protected]

Park, Minyoung Intel [email protected], Zhouyue Samsung [email protected]

Ponnampalam, Vish MediaTek [email protected], Narayan NEC [email protected]

Prat, Gideon Intel [email protected], Kishore NEC [email protected]

Raymond, Yu Zhan Panasonic [email protected], Roee Wilocity [email protected], Ohad Wilocity [email protected]

Sachdev, Devang NVIDIA [email protected], Ali Intel [email protected]

Sampath, Hemanth Qualcomm [email protected] 3 Carlos Cordeiro, Intel, et. al.

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


Sanderovich, Amichai Wilocity [email protected], Sundar Atheros [email protected], Vincenzo STMicroelectronics [email protected]

Seok, Yongho LGE [email protected], Huai-Rong Samsung [email protected], Ba-Zhong Broadcom [email protected]

Sim, Michael Panasonic [email protected], Harkirat Samsung [email protected], Menashe Intel [email protected], Seungho SK Telecom [email protected], Simha Wilocity [email protected], Matt Atheros [email protected]

Stacey, Robert Intel [email protected], Ilan Intel [email protected]

Taghavi, Hossain Qualcomm [email protected], Kazuaki Panasonic [email protected], Jason Self [email protected], Solomon Intel [email protected]

Usuki, Naoshi Panasonic [email protected], Prabodh Nokia [email protected]

Vertenten, Bart NXP [email protected], George STMicroelectronics [email protected]

Wang, Chao-Chun MediaTek [email protected], Homber TMC [email protected], James MediaTek [email protected], James MediaTek [email protected]

Yucek, Tevfik Atheros [email protected], Su Khiong Marvell [email protected], Hongyuan Marvell [email protected]

Slide 4 Carlos Cordeiro, Intel, et. al.

May 2010

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

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

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


May 2010

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


May 2010

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


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


Direct link(S-D)

Relay linkS-R

Relay link(R-D)Source

RUS (‘S’)Destination

RUS (‘D’)

RSUS(‘R’)

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


• 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


S-D Direct link

S-R Relay link R-D Relay linkSource

RUS

DestinationRUS

RSUS

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


• 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


S-D Direct link

S-R Relay link R-D Relay linkSource

RUSDestination

RUS

RSUS

STA Cooperation

May 2010

doc.: IEEE 802.11-10/0494r1

Submission

Common Relay Setup


May 2010

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


May 2010

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


May 2010

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


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


• 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


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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


May 2010

doc.: IEEE 802.11-10/0494r1

Submission



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


May 2010

doc.: IEEE 802.11-10/0494r1

Submission



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


May 2010

doc.: IEEE 802.11-10/0494r1

Submission



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


May 2010

doc.: IEEE 802.11-10/0494r1

Submission



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


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


• Relay capabilities and RSUS discovery procedures (cont’d)


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


• RSUS selection procedure


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


• Relay Link Setup (RLS) procedure


May 2010

doc.: IEEE 802.11-10/0494r1

Submission

Link Switching Type


May 2010

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


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.


May 2010

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 30Data Sensing Time

SP Data Frame to Direct Link

ACK Frame to Direct Link

Data Frame to Relay Link

ACK Frame to Relay Link

Link Change Interval

SIFS

Sà DSà D Sà D Sà Rà D Sà Rà DSà Rà D

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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







SIFS


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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







SIFS


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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







SIFS


May 2010

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.



BAR Frame to Direct Link


BA Frame to Relay Link


SIFS

BA frame to Direct Link

BAR Frame to Relay Link

1st Period 2nd Period

Relay ACK Request

Relay ACK Response

1st Period

Sà RSà D Sà D Sà D Rà DSà R Sà R Sà RRà D Rà D

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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







SIFS




Relay ACK Request

Relay ACK Response

1st Period


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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







SIFS




Relay ACK Request

Relay ACK Response

1st Period


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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







SIFS




Relay ACK Request

Relay ACK Response

1st Period


May 2010

doc.: IEEE 802.11-10/0494r1

Submission

Link Cooperating Type


May 2010

doc.: IEEE 802.11-10/0494r1

Submission

Contents

• TPA (Transmission time-Point Adjustment) Procedure

• SP Request and Allocation

• Data Transmission Rules


May 2010

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.


May 2010

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

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*dTDR, 2*dTDS) 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

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 (dTSR) estimation.

– Just after Dtime plus dTSR, R sends its TPA Response frame to S.– Then, S estimates the time deviation (i.e., 2*dTSR) between Dtime and

the arrival time from R.

Kapseok Chang, ETRI

May 2010

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., dTDS-dTDR) that enables R to transmit its

TPA response frame after (dTDS-dTDR) time duration from Dtime.– Then, R transmits its TPA Response frame to D for confirmation.

Kapseok Chang, ETRI

May 2010

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.


May 2010

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.


The SP period allocated

The period for one cooperated data frame transfer

Data Frame from Sà R

Normal Ack Frame beamformed from Dà S

Ptime

T1 T2

SIFS

Pre- determined time = PtimeThe first time interval =T1The second time interval = T2

Ptime

T1 T2

SIFSPtime

T1 T2

SIFS

Sà RRà DSà D

Sà R Sà R Rà DSà D

Rà DSà D

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


• After Ptime+dTSR 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+(dTDS-dTDR) 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.


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


• 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 49The SP period allocated

The period for one cooperated data frame transfer

Data Frame from Sà R

Normal Ack Frame beamformed from Dà S

Ptime

T1 T2

SIFS

Pre- determined time = PtimeThe first time interval =T1The second time interval = T2

Ptime

T1 T2

SIFSPtime

T1 T2

SIFS

Sà RRà DSà D

Sà R Sà R Rà DSà D

Rà DSà D

May 2010

doc.: IEEE 802.11-10/0494r1

Submission

Relay Operation-type Change (ROC)


May 2010

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


May 2010

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


May 2010

doc.: IEEE 802.11-10/0494r1

Submission

Procedure of changing from Link Cooperating to Link Switching (1/2)


May 2010

doc.: IEEE 802.11-10/0494r1

Submission

Procedure of changing from Link Cooperating to Link Switching (2/2)


May 2010

doc.: IEEE 802.11-10/0494r1

Submission

Procedure of changing from Link Switching to Link Cooperating


May 2010

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.


May 2010

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.


May 2010

doc.: IEEE 802.11-10/0494r1

Submission

Appendix


May 2010

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 59Kapseok Chang, ETRISlide 59

May 2010

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


MAC

PHY

RF

ANT2ANT1

AMP

AMP

BF CoeffBF C

oeff

RF m

ode

switc

h RF mode switch

May 2010

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.


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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


MAC

PHY

RF

Source RUSDestination

RUS

RX mode TX mode

RSUS

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


• If the RSUS receives ACK frame, RF mode is switched right after the relaying.


MAC

PHY

Source RUSDestination

RUS

RF

TX mode RX mode

RSUS

ACK frame

May 2010

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.


May 2010

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.


May 2010

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


[Relay STA Info field]

[Additional Element IDs]

AID Relay Capabilities InfoBits: B0-B7 B8-B15

Information element Element ID Length (in octets)Relay Capabilities <ANA> 1Relay Transfer Parameter set <ANA> 8

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


• 7.3.2.71 Relay Capabilities element


[Relay Capabilities element format]

[Relay Capabilities Info field]

Element ID Length Relay Capabilities InfoOctets:1 1 2

Relay Supportability

Relay Usability

Relay Permission

A/CPower

Mobility Relay Preference

Duplex Cooperation Reserved

Bit B0 B1 B2 B3 B4 B5 B6-B7 B8 B9-B15

Subfield Definition EncodingRelay Supportability Indicates 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

doc.: IEEE 802.11-10/0494r1

Submission




[Subfields of the Relay Capabilities Info field]Subfield Definition EncodingRelay 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 Power Indicates 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.

Mobility Indicates 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

doc.: IEEE 802.11-10/0494r1

Submission




[Subfields of the Relay Capabilities Info field]

Subfield Definition EncodingDuplex Indicates 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.

Cooperation Indicates 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

doc.: IEEE 802.11-10/0494r1

Submission


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


[Relay Transfer Parameter Set element format]

Element ID Length Relay Transfer Parameter

Octets:1 1 8

Duplex-Mode

Cooperation-Mode

Tx-Mode

Reserved Link Change Interval

Data Sensing Time

First Period

Second Period

Reserved

Bit:

B0 B1 B2 B3-B7 B8-B15 B16-B23 B24-B39

B40-B55

B56-B63

[Relay Transfer Parameter field]

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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


May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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


May 2010

doc.: IEEE 802.11-10/0494r1

Submission

7.4 Action Frame Format (1/9)

• mmWave Action frame details


Action field value MeaningN Relay Search RequestN+1 Relay Search ResponseN+2 Multi-Relays Channel Measurement RequestN+3 Multi-Relays Channel Measurement ReportN+4 RLS Request N+5 RLS ResponseN+6 RLS AnnouncementN+7 RLS TeardownN+8 Relay ACK RequestN+9 Relay ACK ResponseN+10 TPA RequestN+11 TPA ResponseN+12 TPA ReportN+13 ROC RequestN+14 ROC ResponseN+15-255 Reserved

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


• 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

Order Information1 Category2 Action3 Dialog Token4 Destination RUS AID

AID Relay Capabilities InfoBits: B0-B7 B8-B15

Order Information1 Category2 Action3 Dialog Token4 Status code5 Relay Capable STA Info 1… …N+4 Relay Capable STA Info N[Relay Search Request Action Frame]

[Relay Search Response Action Frame]

[Relay Capable STA Info field]

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


• 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

Order Information1 Category2 Action3 Dialog Token

Peer STA AID SNR Internal Angle Recommend ReservedBits: B0-B7 B8-B15 B16-B22 B23 B24-B31

[Multi-Relays CM Request Action Frame] [Multi-Relays CM Report Action Frame]

[Channel Measurement Info field]

Order Information1 Category2 Action3 Dialog Token4 Channel Measurement Info 1… …N+3 Channel Measurement Info N

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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


[RLS Request Action Frame] [RLS Response Action Frame]

Order Information1 Category2 Action3 Dialog Token4 Destination AID5 Relay AID6 Source AID7 Destination Capability Information8 Relay Capability Information9 Source Capability Information10 Destination Status Code11 Relay Status Code

Order Information1 Category2 Action3 Dialog Token4 Destination AID5 Relay AID6 Source AID7 Destination Capability Information8 Relay Capability Information9 Source Capability Information10 RLS Timeout Value11 Relay Transfer Parameter Set

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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


Order Information1 Category2 Action3 Status Code4 Destination AID5 Relay AID6 Source AID

[RLS Announcement Action Frame]

Order Information

1 Category2 Action3 Destination AID4 Relay AID5 Source AID6 Reason Code

[RLS Teardown Action Frame]

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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


Order Information1 Category2 Action3 BA Control 4 BlockAck Starting Sequence Control

5 BlockAck Bitmap

Order Information1 Category2 Action3 BAR Control 4 BlockAck Starting Sequence Control

[Relay ACK Request Action Frame][Relay ACK Response Action Frame]

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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


[TPA Request Action Frame]

[TPA Response Action Frame]

Order Information1 Category2 Action3 Dialog Token4 Timing Offset5 Response Offset6 Sampling Frequency Offset (Optional)

Order Information1 Category2 Action3 Dialog Token

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


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


Order Information1 Category2 Action3 Status code

[TPA Report Action frame]

May 2010

doc.: IEEE 802.11-10/0494r1

Submission


• 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

Order Information1 Category2 Action3 Dialog Token4 Relay operation type

Link-cooperating Detour-link ReservedBits: B0 B1 B2-B7

Order Information1 Category2 Action3 Dialog Token4 Status code5 Relay operation type

[ROC Request Action Frame] [ROC Response Action Frame]

[Relay operation type field]

May 2010

doc.: ieee 802.11-10/0494r1 submission may 2010 carlos cordeiro, intel, et. al.slide 1 relay...

Documents