11 10 0494 01 00ad Relay Operation in Ieee 802 11ad

May 2010 doc.: IEEE 802.
11-10/0494r1
Relay Operation in IEEE 802.11ad

Date: 2010-05-01
Author(s):
Name Company Address Phone email
Abu-Surra, Shadi Samsung sasurra@sta.samsung.com
Ban, Koichiro Toshiba koichiro.ban@toshiba.co.jp
Banerjea, Raja Marvell rajab@marvell.com
Basson, Gal Wilocity gal.basson@wilocity.com
Blanksby, Andrew Broadcom andrew.blanksby@broadcom.com
Borges, Daniel Apple drborges@apple.com
Borison, David Ralink david_borison@ralinktech.com
Chang, Kapseok ETRI kschang@etri.re.kr
Chu, Liwen STMicroelectronics Liwen.chu@st.com
Chung, Hyun Kyu ETRI hkchung@etri.re.kr
Coffey, Sean Realtek coffey@realtek.com
Cordeiro, Carlos Intel Carlos.Cordeiro@intel.com
Dorsey, John Apple jdorsey@apple.com
Elboim, Yaron Wilocity yaron.elboim@wilocity.com
Fischer, Matthew Broadcom mfischer@broadcom.com
Giraud, Claude NXP claude.giraud@nxp.com
Golan, Ziv Wilocity Ziv.golan@wilocity.com
Gong, Michelle Intel Michelle.x.gong@intel.com
Grieve, David Agilent david_grieve@agilent.com
Submission Slide 1 Carlos Cordeiro, Intel, et. al.
May 2010 doc.: IEEE 802.11-10/0494r1
Author(s):
Grodzinsky, Mark Wilocity Mark.grodzinsky@wilocity.com
Hansen, Christopher Broadcom chansen@broadcom.com
Hart, Brian Cisco brianh@cisco.com
Hassan, Amer Microsoft amerh@microsoft.com
Hong, Seung Eun ETRI iptvguru@etri.re.kr
Hosoya, Kenichi NEC k-hosoya@ce.jp.nec.com
Hosur, Srinath Texas Instruments hosur@ti.com
Hsu, Alvin MediaTek alvin.hsu@mediatek.com
Hsu, Julan Samsung Julan.hsu@samsung.com
Hung, Kun-Chien MediaTek kc.hung@mediatek.com
Jain, Avinash Qualcomm avinashj@qualcomm.com
Jauh, Alan MediaTek alan.jauh@mediatek.com
Jeon, Paul LGE bjjeon@lge.com
Jin, Sunggeun ETRI sgjin@etri.re.kr
Jones, VK Qualcomm vkjones@qualcomm.com
Joseph, Stacy Beam Networks stacy@beamnetworks.com
Jun, Haeyoung Samsung Haeyoung.jun@samsung.com
Kaaja, Harald Nokia harald.kaaja@nokia.com
Kafle, Padam Nokia padam.kafle@nokia.com
Kakani, Naveen Nokia naveen.kakani@nokia.com
Kasher, Assaf Intel Assaf.kasher@intel.com
Kasslin, Mika Nokia mika.kasslin@nokia.com
Kim, Hodong Samsung hodong0803.kim@samsung.com
Kim, Yongsun ETRI doori@etri.re.kr
Kreifeldt, Rick Harman International rick.kreifeldt@harman.com
Kwon, Edwin Samsung cy.kwon@samsung.com
Kwon, Hyoungjin ETRI kwonjin@etri.re.kr
Kwon, Hyukchoon Samsung hyukchoon.kwon@samsung.com
Laine, Tuomas Nokia tuomas.laine@nokia.com
May 2010 doc.: IEEE 802.11-10/0494r1
Author(s):
Lakkis, Ismail Tensorcom ilakkis@tensorcom.com
Lee, Hoosung ETRI hslee@etri.re.kr
Lee, Keith AMD keith.lee@amd.com
Lee, Wooyong ETRI wylee@etri.re.kr
Liu, Yong Marvell yongliu@marvell.com
Lou, Hui-Ling Marvell hlou@marvell.com
Majkowski, Jakub Nokia jakub.majkowski@nokia.com
Marin, Janne Nokia janne.marin@nokia.com
Maruhashi, Kenichi NEC k-maruhashi@bl.jp.nec.com
Matsumoto, Taisuke Panasonic matsumoto.taisuke@jp.panasonic.com
Meerson, Yury Wilocity Yury.meerson@wilocity.com
Mese, Murat Broadcom mesem@broadcom.com
Montag, Bruce Dell bruce_montag@dell.com
Myles, Andrew Cisco amyles@cisco.com
Nandagopalan, Saishankar Broadcom nsai@broadcom.com
Ngo, Chiu Samsung Chiu.ngo@samsung.com
Nikula, Eero Nokia eero.nikula@nokia.com
Park, DS Samsung dspark@samsung.com
Park, Minyoung Intel Minyoung.park@intel.com
Pi, Zhouyue Samsung zpi@sta.samsung.com
Ponnampalam, Vish MediaTek vish.ponnampalam@mediatek.com
Prasad, Narayan NEC prasad@nec-labs.com
Prat, Gideon Intel Gideon.prat@intel.com
Ramachandran, Kishore NEC kishore@nec-labs.com
Raymond, Yu Zhan Panasonic Raymond.Yuz@sg.panasonic.com
Ronkin, Roee Wilocity Roee.ronkin@wilocity.com
Rozen, Ohad Wilocity Ohad.rozen@wilocity.com
Sachdev, Devang NVIDIA dsachdev@nvidia.com
Sadri, Ali Intel Ali.S.Sadri@intel.com
Sampath, Hemanth Qualcomm hsampath@qualcomm.com
May 2010 doc.: IEEE 802.11-10/0494r1
Author(s):
Sanderovich, Amichai Wilocity Amichai.sanderovich@wilocity.com
Sankaran, Sundar Atheros Sundar.Sankaran@Atheros.com
Scarpa, Vincenzo STMicroelectronics vincenzo.scarpa@st.com
Seok, Yongho LGE yongho.seok@lge.com
Shao, Huai-Rong Samsung hr.shao@samsung.com
Shen, Ba-Zhong Broadcom bzshen@broadcom.com
Sim, Michael Panasonic Michael.Simhc@sg.panasonic.com
Singh, Harkirat Samsung har.singh@sisa.samsung.com
Soffer, Menashe Intel Menashe.soffer@intel.com
Song, Seungho SK Telecom shsong@sktelecom.com
Sorin, Simha Wilocity Simha.sorin@wilocity.com
Smith, Matt Atheros matt.smith@atheros.com
Stacey, Robert Intel Robert.stacey@intel.com
Sutskover, Ilan Intel Ilan.sutskover@intel.com
Taghavi, Hossain Qualcomm mtaghavi@qualcomm.com
Takahashi, Kazuaki Panasonic takahashi.kazu@jp.panasonic.com
Trachewsky, Jason Self jtrachewsky@gmail.com
Trainin, Solomon Intel Solomon.trainin@intel.com
Usuki, Naoshi Panasonic usuki.naoshi@jp.panasonic.com
Varshney, Prabodh Nokia prabodh.varshney@nokia.com
Vertenten, Bart NXP bart.vertenten@nxp.com
Vlantis, George STMicroelectronics george.vlantis@st.com
Wang, Chao-Chun MediaTek chaochun.wang@mediatek.com
Wang, Homber TMC homber@emcite.com
Wang, James MediaTek james.wang@mediatek.com
Yee, James MediaTek james.yee@mediatek.com
Yucek, Tevfik Atheros Tevfik.Yucek@Atheros.com
Yong, Su Khiong Marvell skyong@marvell.com
Zhang, Hongyuan Marvell hongyuan@marvell.com
May 2010 doc.: IEEE 802.11-10/0494r1
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 doc.: IEEE 802.11-10/0494r1
Outline
• Introduction
• mmWave Relay Operation
• Common Relay Setup
• Link Switching Type
• Link Cooperating Type
• Relay Operation-type Change
• Conclusion
• Appendix
Submission Slide 6 Kapseok Chang, ETRI

May 2010 doc.: IEEE 802.11-10/0494r1
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
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
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
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).
RSUS
Relay link Relay link
(‘R’)
Source S-R (R-D) Destination
RUS (‘S’) RUS (‘D’)
Direct link
(S-D)
• A source RUS, a destination RUS and an RUS establish two

types of relay operation
– Link switching
– Link cooperating, and Relay Operation-type Change

May 2010 doc.: IEEE 802.11-10/0494r1
• Link Switching type

RSUS
S-R Relay link R-D Relay link

Source Destination
RUS RUS
S-D Direct link
– 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

May 2010 doc.: IEEE 802.11-10/0494r1
• Link Cooperating type

RSUS
STA Cooperation
S-R Relay link R-D Relay link
Source Destination
RUS RUS
S-D Direct link
– 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

May 2010 doc.: IEEE 802.11-10/0494r1
Common Relay Setup

May 2010 doc.: IEEE 802.11-10/0494r1
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
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
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
• 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
• 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

• 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

– 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

– 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

– 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
• Relay capabilities and RSUS discovery procedures

(cont’d)

May 2010 doc.: IEEE 802.11-10/0494r1
• RSUS selection procedure

May 2010 doc.: IEEE 802.11-10/0494r1
• 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
• Relay Link Setup (RLS) procedure

May 2010 doc.: IEEE 802.11-10/0494r1
Link Switching Type

May 2010 doc.: IEEE 802.11-10/0494r1
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
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
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.
SP Data Frame to ACK Frame to Data Frame to ACK Frame to
Direct Link Direct Link Relay Link Relay Link
Link Change Interval
SàD SàD SàD SàRàD SàRàD SàRàD
SIFS Data Sensing Time

May 2010 doc.: IEEE 802.11-10/0494r1
• 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.


May 2010 doc.: IEEE 802.11-10/0494r1
• 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.

May 2010 doc.: IEEE 802.11-10/0494r1
• 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.

May 2010 doc.: IEEE 802.11-10/0494r1
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.
SP Data Frame to BAR Frame BA frame to Data Frame to BAR Frame to BA Frame to Relay ACK Relay ACK
Direct Link to Direct Link Direct Link Relay Link Relay Link Relay Link Request Response
Link Change
Interval 1st Period 2nd Period 1st Period
SàD SàD SàD SàR SàR SàR RàD RàD RàD SàR

May 2010 doc.: IEEE 802.11-10/0494r1
• 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.
SP Data Frame to BAR Frame BA frame to Data Frame to
Direct Link to Direct Link Direct Link Relay Link
BAR Frame to BA Frame to
Relay Link Relay Link
Relay ACK
Request
Relay ACK
Response
Link Change

May 2010 doc.: IEEE 802.11-10/0494r1
• 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.
SP Data Frame to BAR Frame BA frame to Data Frame to
Direct Link to Direct Link Direct Link Relay Link
BAR Frame to BA Frame to
Relay Link Relay Link
Relay ACK
Request
Relay ACK
Response
Link Change

May 2010 doc.: IEEE 802.11-10/0494r1
• 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.
SP Data Frame to BAR Frame BA frame to Data Frame to BAR Frame to BA Frame to Relay ACK Relay ACK
Direct Link to Direct Link Direct Link Relay Link Relay Link Relay Link Request Response
Link Change

May 2010 doc.: IEEE 802.11-10/0494r1
Link Cooperating Type

May 2010 doc.: IEEE 802.11-10/0494r1
Contents
• TPA (Transmission time-Point Adjustment) Procedure

• SP Request and Allocation
• Data Transmission Rules

May 2010 doc.: IEEE 802.11-10/0494r1
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
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.
Submission Kapseok Chang, ETRI

May 2010 doc.: IEEE 802.11-10/0494r1
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*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.

May 2010 doc.: IEEE 802.11-10/0494r1
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*dT SR) between Dtime and
the arrival time from R.

May 2010 doc.: IEEE 802.11-10/0494r1
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-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.

May 2010 doc.: IEEE 802.11-10/0494r1
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
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.
Pre-determined time = Ptime The period for one cooperated data frame transfer
The first time interval =T1
Data Frame from SàR
The second time interval = T2
Normal Ack Frame beamformed from DàS
T1 T2 T1 T2 T1 T2
SàR RàD SàR RàD RàD

SàR
SàD SàD SàD
Ptime SIFS Ptime SIFS Ptime SIFS
The SP period allocated

May 2010 doc.: IEEE 802.11-10/0494r1
• 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
• 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
• 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.
Pre-determined time = Ptime The period for one cooperated data frame transfer
The first time interval =T1
Data Frame from SàR
The second time interval = T2
Normal Ack Frame beamformed from DàS
T1 T2 T1 T2 T1 T2
SàR RàD SàR RàD RàD

SàR
SàD SàD SàD
Ptime SIFS Ptime SIFS Ptime SIFS
The SP period allocated

May 2010 doc.: IEEE 802.11-10/0494r1
Relay Operation-type Change (ROC)

May 2010 doc.: IEEE 802.11-10/0494r1
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
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
Procedure of changing from Link Cooperating

to Link Switching (1/2)

May 2010 doc.: IEEE 802.11-10/0494r1
Procedure of changing from Link Cooperating

to Link Switching (2/2)

May 2010 doc.: IEEE 802.11-10/0494r1
Procedure of changing from Link Switching to

Link Cooperating

May 2010 doc.: IEEE 802.11-10/0494r1
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
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
Appendix

May 2010 doc.: IEEE 802.11-10/0494r1
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.

Slide 59 Kapseok Chang, ETRI
May 2010 doc.: IEEE 802.11-10/0494r1
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
RF mode switch
RF mode switch
BF Coeff
BF Coeff
AMP
ANT1 ANT2
AMP

May 2010 doc.: IEEE 802.11-10/0494r1
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

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.
RSUS
MAC
PHY
RF
RX mode TX mode
Destination
Source RUS
RUS
May 2010 doc.: IEEE 802.11-10/0494r1

Type (3/3)
• If the RSUS receives ACK frame, RF mode is switched
right after the relaying.
RSUS
MAC
PHY
RF
TX mode RX mode
ACK frame
Destination
Source RUS
RUS

May 2010 doc.: IEEE 802.11-10/0494r1
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
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
7.3 Management frame body components (1/7)
• 7.3.1.51 Relay Capable STA Info field

AID Relay Capabilities Info
Bits: B0-B7 B8-B15
[Relay 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
Information element Element ID Length (in octets)
Relay Capabilities <ANA> 1
Relay Transfer Parameter set <ANA> 8
[Additional Element IDs]
May 2010 doc.: IEEE 802.11-10/0494r1
• 7.3.2.71 Relay Capabilities element

Element ID Length Relay Capabilities Info
Octets:1 1 2
[Relay Capabilities element format]
Relay Relay Relay A/C Mobility Relay Duplex Cooperation Reserve
Supportability Usability Permission Power Preference d
Bit B0 B1 B2 B3 B4 B5 B6-B7 B8 B9-B15
[Relay Capabilities Info field]
Subfield Definition Encoding
Relay Supportability Indicates that STA is capable of relaying via Set to 1 if STA is relay
itself by transmitting and receiving frames supportable. Otherwise set
between a pair of other STAs. A STA capable to 0
of relaying support is named “relay STA”.
[Subfields of the Relay Capabilities Info field]
May 2010 doc.: IEEE 802.11-10/0494r1

Relay Indicates that STA is capable of using Set to 1 if STA is relay usable. Otherwise
Usability frame-relaying through a relay STA. set to 0
Relay Indicates whether the PCP/AP allows Set to 0 if relay operation is not allowed in
Permission relay operation (11.37) to be used the BSS. Set to 1 if relay operation is
within the PCP/AP’s BSS. This field is allowed in the BSS.
ignored when transmitted by a non-
PCP/non-AP STA.
A/C Power Indicates that relay STA is capable of Set to 1 if relay STA is capable of being
obtaining A/C power supplied by A/C power. Otherwise set to 0.
Mobility Indicates that relay STA is capable of Set to 1 if relay STA is capable to support
support mobility mobility. Otherwise set to 0.
Relay Indicates that a STA prefers to become Set to 1 if a STA prefers to be RSUS.
Preference RSUS rather than RUS Otherwise set to 0.
May 2010 doc.: IEEE 802.11-10/0494r1

Duplex Indicates whether relay STA is Set to 01 if relay STA is not capable
capable of FD/AF or HD/DF. 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 Set to 1 if a STA supports both Link
capable of supporting Link cooperating type and Link switching
cooperating. 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
• 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.
Element ID Length Relay Transfer Parameter

Octets:1 1 8
[Relay Transfer Parameter Set element format]
Duplex Cooperation- Tx- Reserved Link Data First Second Reser

-Mode Mode Mode Change Sensing Period Period ved
Interval Time
B B0 B1 B2 B3-B7 B8-B15 B16-B23 B24- B40- B56-
it: B39 B55 B63
[Relay Transfer Parameter field]
May 2010 doc.: IEEE 802.11-10/0494r1

– 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

– 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
7.4 Action Frame Format (1/9)
• mmWave Action frame details

Action field value Meaning
N Relay Search Request
N+1 Relay Search Response
N+2 Multi-Relays Channel Measurement Request
N+3 Multi-Relays Channel Measurement Report
N+4 RLS Request
N+5 RLS Response
N+6 RLS Announcement
N+7 RLS Teardown
N+8 Relay ACK Request
N+9 Relay ACK Response
N+10 TPA Request
N+11 TPA Response
N+12 TPA Report
N+13 ROC Request
N+14 ROC Response
N+15-255 Reserved
May 2010 doc.: IEEE 802.11-10/0494r1

• Relay Search Request/Response Action Frames
Order Information
Order Information 1 Category
1 Category 2 Action
2 Action 3 Dialog Token
3 Dialog Token 4 Status code
5 Relay Capable STA Info 1
4 Destination RUS AID
… …
[Relay Search Request Action Frame] N+4 Relay Capable STA Info N
[Relay Search Response Action Frame]
AID Relay Capabilities Info
Bits: B0-B7 B8-B15
[Relay Capable STA Info field]
• 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
Submission Relay Capabilities. Slide 74 Kapseok Chang, ETRI
May 2010 doc.: IEEE 802.11-10/0494r1

• Multi-Relays Channel Measurement(CM) Request/Report Action
Frames Order Information
1 Category
Order Information 2 Action
1 Category 3 Dialog Token
4 Channel Measurement Info 1
2 Action
… …
3 Dialog Token N+3 Channel Measurement Info N
[Multi-Relays CM Request Action Frame] [Multi-Relays CM Report Action Frame]
Peer STA AID SNR Internal Angle Recommend Reserved
Bits: B0-B7 B8-B15 B16-B22 B23 B24-B31
[Channel Measurement Info field]
• 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
Submission AID and channel measurement between the RSUS and destination RUS
Slide 75 Kapseok Chang, ETRI
May 2010 doc.: IEEE 802.11-10/0494r1

• RLS Request/Response Action Frames
Order Information Order Information
1 Category 1 Category
2 Action 2 Action
3 Dialog Token 3 Dialog Token
4 Destination AID 4 Destination AID
5 Relay AID 5 Relay AID
6 Source AID 6 Source AID
7 Destination Capability Information 7 Destination Capability Information
8 Relay Capability Information 8 Relay Capability Information
9 Source Capability Information 9 Source Capability Information
10 RLS Timeout Value 10 Destination Status Code
11 Relay Transfer Parameter Set 11 Relay Status Code
[RLS Request Action Frame] [RLS Response Action Frame]
• 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.
May 2010 doc.: IEEE 802.11-10/0494r1
• RLS Announcement/Teardown Action frames

2 Action 2 Action
3 Status Code 3 Destination AID
4 Destination AID 4 Relay AID
5 Relay AID 5 Source AID
6 Source AID 6 Reason Code
[RLS Announcement Action Frame] [RLS Teardown Action Frame]
• 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.

May 2010 doc.: IEEE 802.11-10/0494r1
• Relay ACK Request/Response Action frame

2 Action 2 Action
3 BAR Control 3 BA Control
4 BlockAck Starting Sequence Control 4 BlockAck Starting Sequence Control
5 BlockAck Bitmap
[Relay ACK Request Action Frame]
[Relay ACK 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.

May 2010 doc.: IEEE 802.11-10/0494r1

• TPA Request/Response Action frames
Order Information
1 Category Order Information
2 Action 1 Category
3 Dialog Token 2 Action
4 Timing Offset 3 Dialog Token
5 Response Offset [TPA Response Action Frame]
6 Sampling Frequency Offset (Optional)
[TPA Request Action Frame]
• 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.
May 2010 doc.: IEEE 802.11-10/0494r1
• TPA Report Action frame

Order Information
1 Category
2 Action
3 Status code
[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.

May 2010 doc.: IEEE 802.11-10/0494r1

• ROC Request/Response Action frames
1 Category
1 Category
2 Action
2 Action
3 Dialog Token
3 Dialog Token 4 Status code
4 Relay operation type 5 Relay operation type
[ROC Request Action Frame] [ROC Response Action Frame]
Link-cooperating Detour-link Reserved
Bits: B0 B1 B2-B7
[Relay operation type field]
• 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
Submission at relay link. Slide 81 Kapseok Chang, ETRI

11 10 0494 01 00ad Relay Operation in Ieee 802 11ad

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

11 10 0494 01 00ad Relay Operation in Ieee 802 11ad

Uploaded by

Copyright:

Available Formats

May 2010 doc.: IEEE 802.

Relay Operation in IEEE 802.11ad

Submission Slide 5 Carlos Cordeiro, Intel, et. al.

Submission Slide 6 Kapseok Chang, ETRI

• Problem statement for 60 GHz channel

Submission Slide 7 Kapseok Chang, ETRI

Submission Slide 8 Kapseok Chang, ETRI

• In order to complement current solutions of P1 and/or

Submission Slide 9 Kapseok Chang, ETRI

mmWave Relay Operation (1/3)

• Relaying allows a source relay usable mSTA (RUS) to

• A source RUS, a destination RUS and an RUS establish two

Submission Slide 10 Kapseok Chang, ETRI

mmWave Relay Operation (2/3)

• Link Switching type

S-R Relay link R-D Relay link

Submission Slide 11 Kapseok Chang, ETRI

mmWave Relay Operation (3/3)

• Link Cooperating type

Submission Slide 12 Kapseok Chang, ETRI

Common Relay Setup

Submission Slide 13 Kapseok Chang, ETRI

Submission Slide 14 Kapseok Chang, ETRI

• We describe the procedures that a source RUS, a

Submission Slide 15 Kapseok Chang, ETRI

Relay Link Setup (1/11)

• Simple scenario considered for explanation

Submission Slide 16 Kapseok Chang, ETRI

Relay Link Setup (2/11)

• Relay capabilities and RSUS discovery procedures

Submission Slide 17 Kapseok Chang, ETRI

Relay Link Setup (3/11)

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

Submission Slide 18 Kapseok Chang, ETRI

Relay Link Setup (4/11)

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

Submission Slide 19 Kapseok Chang, ETRI

Relay Link Setup (5/11)

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

Submission Slide 20 Kapseok Chang, ETRI

Relay Link Setup (6/11)

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

Submission Slide 21 Kapseok Chang, ETRI

Relay Link Setup (7/11)

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

Submission Slide 22 Kapseok Chang, ETRI

Relay Link Setup (8/11)

• Relay capabilities and RSUS discovery procedures

Submission Slide 23 Kapseok Chang, ETRI

Relay Link Setup (9/11)

• RSUS selection procedure

Submission Slide 24 Kapseok Chang, ETRI

Relay Link Setup (10/11)

• RSUS selection procedure (cont’d)

Submission Slide 25 Kapseok Chang, ETRI

Relay Link Setup (11/11)

• Relay Link Setup (RLS) procedure

Submission Slide 26 Kapseok Chang, ETRI

Link Switching Type

Submission Slide 27 Kapseok Chang, ETRI

• SP Request and Allocation

Submission Slide 28 Kapseok Chang, ETRI