doc.: ieee 802.11-10/0445r1 submission date: may, 2010 haeyoung jun, samsung, et. al.slide 1 mac...
TRANSCRIPT
doc.: IEEE 802.11-10/0445r1
Submission
Date: MAY, 2010
Haeyoung Jun, Samsung, et. al.Slide 1
MAC Link MaintenanceDate: 2010-05-19
Author(s)/Supporter(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]
Cariou, Laurent Orange [email protected]
Chamberlin, Philippe Technicolor R&I [email protected]
Chang, Kapseok ETRI [email protected]
Chin, Francois I2R [email protected]
Choi, Changsoon IHP GmbH [email protected]
Christin, Philippe Orange [email protected]
Chu, Liwen STMicroelectronics [email protected]
Chung, Hyun Kyu ETRI [email protected]
Coffey, Sean Realtek [email protected]
Cordeiro, Carlos Intel [email protected]
Derham, Thomas Orange [email protected]
Dorsey, John Apple [email protected]
doc.: IEEE 802.11-10/0445r1
Submission
Date: MAY, 2010
Slide 2
Author(s)/Supporter(s):Name Company Address Phone email
Elboim, Yaron Wilocity [email protected], Matthew Broadcom [email protected], Claude NXP [email protected], Ron Peraso Technologies [email protected]
Golan, Ziv Wilocity [email protected], Michelle Intel [email protected]
Grandhi, Sudheer InterDigital [email protected], Eckhard IHP GmbH [email protected], David Agilent [email protected]
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], Raymond Jararaj s/o I2R [email protected]
Jeon, Paul LGE [email protected], Sunggeun ETRI [email protected]
Jones, VK Qualcomm [email protected], Stacy Beam Networks [email protected]
Jun, Haeyoung Samsung [email protected], Harald Nokia [email protected], Padam Nokia [email protected]
Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
Author(s)/Supporter(s):Name Company Address Phone email
Kakani, Naveen Nokia [email protected], Assaf Intel [email protected], Mika Nokia [email protected], Hodong Samsung [email protected], Yongsun ETRI [email protected], Rolf IHP GmbH [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], 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], Brad Peraso Technologies [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]
Slide 3 Haeyoung Jun, Samsung, et. al.
Date: MAY, 2010
doc.: IEEE 802.11-10/0445r1
Submission
Author(s)/Supporter(s):Name Company Address Phone email
Park, DS Samsung [email protected], Minyoung Intel [email protected], Xiaoming I2R [email protected]
Pi, Zhouyue Samsung [email protected], Vish MediaTek [email protected]
Prasad, Narayan NEC [email protected], Gideon Intel [email protected], Xuhong I2R [email protected]
Ramachandran, Kishore NEC [email protected], Yu Zhan Panasonic [email protected]
Roblot, Sandrine Orange [email protected], Roee Wilocity [email protected], Ohad Wilocity [email protected]
Sachdev, Devang NVIDIA [email protected], Ali Intel [email protected]
Sampath, Hemanth Qualcomm [email protected], Amichai Wilocity [email protected]
Sankaran, 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]
Slide 4 Haeyoung Jun, Samsung, et. al.
Date: MAY, 2010
doc.: IEEE 802.11-10/0445r1
Submission
Author(s)/Supporter(s):Name Company Address Phone email
Sorin, Simha Wilocity [email protected], Matt Atheros [email protected]
Stacey, Robert Intel [email protected], Ananth I2R [email protected]
Sutskover, Ilan Intel [email protected], Hossain Qualcomm [email protected]
Takahashi, Kazuaki Panasonic [email protected], Ichihiko NTT [email protected]
Trachewsky, 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]
Wong, David Tung Chong I2R [email protected], James MediaTek [email protected]
Yucek, Tevfik Atheros [email protected], Su Khiong Marvell [email protected], Hongyuan Marvell [email protected]
Slide 5 Haeyoung Jun, Samsung, et. al.
Date: MAY, 2010
doc.: IEEE 802.11-10/0445r1
Submission
Proposal overview
• This presentation is part and is in support of the complete proposal described in 802.11-10/432r2 (slides) and 802.11-10/433r2 (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
Date: MAY, 2010
Slide 6 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
Motivations behind Proposed New Technique
• STA movement breaks beam-formed link in 60GHz
• A STA acting as a PCP may leave PBSS– Another STA in PBSS should take the PCP role over
– Seamless Service Continuity is an important feature
• Fast Channel Fading in 60GHz Channel– Adaptive Link Adaptation technique is required
• This New Techniques Support the following features– Beam-formed link maintenance
– PCP Handover (Implicit / Explicit)
– Link Adaptation
Date: MAY, 2010
Slide 7 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
Scope
• This presentation covers following sections of the CP described in 802.11-10/433r0;
– 11.30.1 : Beamformed Link Maintenance
– 11.32.2 : PCP Handover
– 9.27 : Link Adaptation
Date: MAY, 2010
Slide 8 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
Beamformed Link Maintenance ( STA to STA )
• Determination of Beam-formed link breakage by a destination STA– If a PHY-RXSTART.indication does not occur during aSlotTime (=3us) + aPHY-RX-
START-Delay (=128 us) from the start of the SP
– If a PHY-RXEND.indication does not occur which means MPDU transmission is not successful.
• Action required after beam-formed link breakage– The destination STA of the SP should configure its receive antenna to a quasi-omni pattern
– The source STA of the SP may transmit an RTS frame at MCS 0 to restore the beam-formed link with the destination STA.
– The source STA of the SP should restart beamforming with the destination STA after no more than dot11ShortRetryLimit (=7) RTS retransmission attempts without a response CTS.
Date: MAY, 2010
Slide 9 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
Beamformed Link Maintenance ( PCP/AP to non-PCP/non-AP STA )
• The PCP/AP sends a frame with its antenna pattern directed to the STA at least once every aMinBTPeriod (=4) beacon intervals
• The STA sends a frame with its antenna pattern directed to the PCP/AP at least once every aMinBTPeriod beacon intervals.
• If the PCP/AP does not receive a frame with a MCS other than MCS 0 from the STA after dot11ShortRetryLimit transmission attempts, it assumes that the beamformed link with the STA is invalid and should schedule time in the beacon interval for the PCP/AP to initiate beamforming training with the STA
Date: MAY, 2010
Slide 10 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
Beamformed Link Maintenance ( Alternative )
• If a STA detects degradation in the link quality between itself and another STA, the STA can use beam tracking or beam refinement to improve the link quality.
• The STA can try beam tracking or beam refinement by;– Requesting the PCP/AP to schedule an SP to perform BF ( with non-PCP/non-AP STA )
– Use CBP to perform BF ( with non-PCP/non-AP STA )
– Use A-BFT to perform BF ( with PCP/AP )
• If the link quality with a PCP/AP degrades but the STA can still receive mmWave Beacon frames and the A-BFT present field set to 1, the STA should improve the link quality by performing beamforming during the A-BFT period
Date: MAY, 2010
Slide 11 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
PCP Handover
• PCP Handover process consists of– PCP Distributes STA information & pseudo-static scheduling
information to suitable PCP handover capable STA(s)
– PCP handover capable STA to take over the PCP responsibilities
• Two types of PCP handover may be supported– Explicit PCP Handover
• The PCP hands over the PCP role before it leaves the PBSS
– Implicit PCP Handover• The PCP leaves the PBSS (or Turned off) without Explicit Handover
• PCP Handover capability is Optional – indicated in the STA’s mmWave Capabilities element
Date: MAY, 2010
Slide 12 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
Explicit PCP Handover(Request by PCP)
• The PCP transmits a Handover Request frame to a non-PCP STA that is handover capable.
– The STA becomes a candidate PCP after receiving the Hanover Request
• The candidate PCP transmits a Handover Response frame to the PCP– A candidate PCP should request STA / Pseudo-static scheduling information from
the PCP using an Information Request frame.
– The candidate PCP should also request SPs to perform beamforming and establish security association with other associated STAs prior to the completion of PCP handover
• PCP shall transmit the PCP Handover element within its mmWave Beacon or Announce frame for each of the next dot11NbrOfChangeBeacons BIs – with Remaining BIs field specifying the number of BIs remaining until the
candidate PCP takes over the new PCP role.
Date: MAY, 2010
Slide 13 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
Explicit PCP Handover(Request by non-PCP STA)
• A non-PCP STA, that is handover capable, transmits a Handover Request frame to the PCP. – The non-PCP STA becomes the candidate PCP.
• The PCP transmits a Handover Response frame to the candidate PCP– A candidate PCP should request STA / Pseudo-static scheduling information from
the PCP using an Information Request frame.
– The candidate PCP should also request SPs to perform beamforming and establish security association with other associated STAs prior to the completion of PCP handover
• PCP shall transmit the PCP Handover element within its mmWave Beacon or Announce frame for each of the next dot11NbrOfChangeBeacons BIs – with Remaining BIs field specifying the number of BIs remaining until the
candidate PCP takes over the new PCP role.
Date: MAY, 2010
Slide 14 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
Implicit PCP Handover
• The PCP distributes the Next PCP List element in its mmWave Beacon or Announce frame.
– The PCP may decide the priority of Next PCPs based on information contained within a STA’s mmWave PCP/AP Capability element
• The STA whose AID in the ith AID entry in the NextPCP List element received from the PCP becomes the ith Implicit candidate PCP
– All implicit candidate PCP should request STA / pseudo-static scheduling information from the PCP by transmitting an Information Request.
• If the ith Implicit candidate PCP fails to receive a mmWave Beacon or Announce frames from the PCP for (i * dot11ImplicitHandoverLostBeacons) BIs, it sends a mmWave Beacon to announce that it is taking over the responsibility as the PCP of the PBSS.
Date: MAY, 2010
Slide 15 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
PCP Handover
Order Information1 Category2 Action3 Handover Reason4 Handover Remaining BI
Order Information1 Category2 Action3 Handover Result4 Handover Reject Reason
Element ID Length New PCP AID
Remaining BIs
Octets: 1 1 1 1
Element ID
Length Token AID of
NextPCP 1…
AID of NextPCP n
Octets: 1 1 1 1 … 1
Handover Request frame Handover Response frame
PCP Handover element
Next PCP List element
Date: MAY, 2010
Slide 16 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
Link Adaptation
• A STA transmits a Link Margin Request frame to a (responding) STA indicated in the RA field of the frame.
• The responding STA responds with Link Margin Response frame.– The Link Margin Response frame contains the values of SNR, Link Margin,
Recommended action, and the Recommended MCS.
• A STA may send an unsolicited Link Margin Response frame
• The Link Margin Request & Response can be used to determine appropriate action by the Requesting STA
– Including Tx power change, MCS level change, and FST initiation.
Date: MAY, 2010
Slide 17 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
Link Adaptation ( Alternative )
• A STA transmits a Link Margin Request frame to a (responding) STA indicated in the RA field of the frame.
• The responding STA sends ACK or BA to the requesting STA
• The requesting STA sends a frame to the same responding STA SIFS after receiving the ACK or BA frame
• The responding STA responds with Link Margin Response frame.– The Link Margin Response frame contains the values of SNR, Link Margin,
Recommended action, and the Recommended MCS which are determined using the measurements of the PPDU which is the subsequent frame following the Link Margin Request frame.
Date: MAY, 2010
Slide 18 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
Link Adaptation
Element ID Length Action MCSLink
MarginSNR Reference
TimestampOctets: 1 1 1 1 1 1 4
Preferred Action Value Meaning0 No Preference1 Change MCS2 Change Transmit Power3 Fast Session Transfer (FST)4 Power conserve mode
5-7 reserved
Order Information1 Category2 Action3 Dialog Token
Order Information1 Category2 Action3 Dialog Token4 Link Margin
Link Margin Request frame Link Margin Response frame
Link Margin element
Date: MAY, 2010
Slide 19 Haeyoung Jun, Samsung, et. al.
doc.: IEEE 802.11-10/0445r1
Submission
References
• [1] 802.11-10/432r2-ad-CP-presentation.ppt
• [2] 802.11-10/433r2-ad-CP-specification.doc
• [3] 802.11-10/430r1-ad-NT-11.ppt
Date: MAY, 2010
Slide 20 Haeyoung Jun, Samsung, et. al.