Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.: IEEE 802.11-10/0445r1 Submission Date: MAY, 2010 Haeyoung Jun, Samsung, et. al.Slide 1 MAC Link Maintenance Date: 2010-05-19 Author(s)/Supporter(s):

Similar presentations


Presentation on theme: "Doc.: IEEE 802.11-10/0445r1 Submission Date: MAY, 2010 Haeyoung Jun, Samsung, et. al.Slide 1 MAC Link Maintenance Date: 2010-05-19 Author(s)/Supporter(s):"— Presentation transcript:

1 doc.: IEEE 802.11-10/0445r1 Submission Date: MAY, 2010 Haeyoung Jun, Samsung, et. al.Slide 1 MAC Link Maintenance Date: 2010-05-19 Author(s)/Supporter(s): NameCompanyAddressPhoneemail Abu-Surra, ShadiSamsungsasurra@sta.samsung.com Ban, KoichiroToshibakoichiro.ban@toshiba.co.jp Banerjea, RajaMarvellrajab@marvell.com Basson, GalWilocitygal.basson@wilocity.com Blanksby, AndrewBroadcomandrew.blanksby@broadcom.com Borges, DanielAppledrborges@apple.com Borison, DavidRalinkdavid_borison@ralinktech.com Cariou, LaurentOrangelaurent.cariou@orange-ftgroup.com Chamberlin, PhilippeTechnicolor R&Iphilippe.chambelin@technicolor.com Chang, KapseokETRIkschang@etri.re.kr Chin, FrancoisI2Rchinfrancois@i2r.a-star.edu.sg Choi, ChangsoonIHP GmbHchoi@ihp-microelectronics.com Christin, PhilippeOrangephilippe.christin@orange-ftgroup.com Chu, LiwenSTMicroelectronicsLiwen.chu@st.com Chung, Hyun KyuETRIhkchung@etri.re.kr Coffey, SeanRealtekcoffey@realtek.com Cordeiro, CarlosIntelCarlos.Cordeiro@intel.com Derham, ThomasOrangethomas.derham@orange-ftgroup.com Dorsey, JohnApplejdorsey@apple.com

2 doc.: IEEE 802.11-10/0445r1 Submission Date: MAY, 2010 Slide 2 Author(s)/Supporter(s): NameCompanyAddressPhoneemail Elboim, YaronWilocityyaron.elboim@wilocity.com Fischer, MatthewBroadcommfischer@broadcom.com Giraud, ClaudeNXPclaude.giraud@nxp.com Glibbery, RonPeraso Technologiesron@perasotech.com Golan, ZivWilocityZiv.golan@wilocity.com Gong, MichelleIntelMichelle.x.gong@intel.com Grandhi, SudheerInterDigitalsagrandhi802@gmail.com Grass, EckhardIHP GmbHgrass@ihp-microelectronics.com Grieve, DavidAgilentdavid_grieve@agilent.com Grodzinsky, MarkWilocityMark.grodzinsky@wilocity.com Hansen, ChristopherBroadcomchansen@broadcom.com Hart, BrianCiscobrianh@cisco.com Hassan, AmerMicrosoftamerh@microsoft.com Hong, Seung EunETRIiptvguru@etri.re.kr Hosoya, KenichiNECk-hosoya@ce.jp.nec.com Hosur, SrinathTexas Instrumentshosur@ti.com Hsu, AlvinMediaTekalvin.hsu@mediatek.com Hsu, JulanSamsungJulan.hsu@samsung.com Hung, Kun-ChienMediaTekkc.hung@mediatek.com Jain, AvinashQualcommavinashj@qualcomm.com Jauh, AlanMediaTekalan.jauh@mediatek.com Jayabal, Raymond Jararaj s/oI2Rjraymond@i2r.a-star.edu.sg Jeon, PaulLGEbjjeon@lge.com Jin, SunggeunETRIsgjin@etri.re.kr Jones, VKQualcommvkjones@qualcomm.com Joseph, StacyBeam Networksstacy@beamnetworks.com Jun, HaeyoungSamsungHaeyoung.jun@samsung.com Kaaja, HaraldNokiaharald.kaaja@nokia.com Kafle, Padam Nokiapadam.kafle@nokia.com Haeyoung Jun, Samsung, et. al.

3 doc.: IEEE 802.11-10/0445r1 Submission Author(s)/Supporter(s): NameCompanyAddressPhoneemail Kakani, Naveen Nokianaveen.kakani@nokia.com Kasher, Assaf IntelAssaf.kasher@intel.com Kasslin, Mika Nokiamika.kasslin@nokia.com Kim, Hodong Samsunghodong0803.kim@samsung.com Kim, Yongsun ETRIdoori@etri.re.kr Kraemer, Rolf IHP GmbHkraemer@ihp-microelectronics.com Kreifeldt, RickHarman Internationalrick.kreifeldt@harman.com Kwon, Edwin Samsungcy.kwon@samsung.com Kwon, Hyoungjin ETRI kwonjin@etri.re.kr Kwon, Hyukchoon Samsunghyukchoon.kwon@samsung.com Laine, Tuomas Nokiatuomas.laine@nokia.com Lakkis, Ismail Tensorcomilakkis@tensorcom.com Lee, Hoosung ETRIhslee@etri.re.kr Lee, KeithAMDkeith.lee@amd.com Lee, WooyongETRIwylee@etri.re.kr Liu, Yong Marvellyongliu@marvell.com Lou, Hui-Ling Marvellhlou@marvell.com Lynch, Brad Peraso Technologiesbrad@perasotech.com Majkowski, Jakub Nokiajakub.majkowski@nokia.com Marin, Janne Nokiajanne.marin@nokia.com Maruhashi, Kenichi NECk-maruhashi@bl.jp.nec.com Matsumoto, Taisuke Panasonicmatsumoto.taisuke@jp.panasonic.com Meerson, Yury WilocityYury.meerson@wilocity.com Mese, Murat Broadcommesem@broadcom.com Montag, Bruce Dellbruce_montag@dell.com Myles, Andrew Ciscoamyles@cisco.com Nandagopalan, Saishankar Broadcomnsai@broadcom.com Ngo, Chiu SamsungChiu.ngo@samsung.com Nikula, Eero Nokiaeero.nikula@nokia.com Slide 3Haeyoung Jun, Samsung, et. al. Date: MAY, 2010

4 doc.: IEEE 802.11-10/0445r1 Submission Author(s)/Supporter(s): NameCompanyAddressPhoneemail Park, DS Samsungdspark@samsung.com Park, Minyoung IntelMinyoung.park@intel.com Peng, Xiaoming I2Rpengxm@i2r.a-star.edu.sg Pi, Zhouyue Samsungzpi@sta.samsung.com Ponnampalam, Vish MediaTekvish.ponnampalam@mediatek.com Prasad, Narayan NECprasad@nec-labs.com Prat, Gideon IntelGideon.prat@intel.com Qu, Xuhong I2Rquxh@i2r.a-star.edu.sg Ramachandran, Kishore NECkishore@nec-labs.com Raymond, Yu Zhan PanasonicRaymond.Yuz@sg.panasonic.com Roblot, Sandrine Orangesandrine.roblot@orange-ftgroup.com Ronkin, Roee WilocityRoee.ronkin@wilocity.com Rozen, Ohad WilocityOhad.rozen@wilocity.com Sachdev, DevangNVIDIAdsachdev@nvidia.com Sadri, AliIntelAli.S.Sadri@intel.com Sampath, HemanthQualcommhsampath@qualcomm.com Sanderovich, Amichai WilocityAmichai.sanderovich@wilocity.com Sankaran, Sundar AtherosSundar.Sankaran@Atheros.com Scarpa, Vincenzo STMicroelectronicsvincenzo.scarpa@st.com Seok, Yongho LGEyongho.seok@lge.com Shao, Huai-Rong Samsunghr.shao@samsung.com Shen, Ba-Zhong Broadcombzshen@broadcom.com Sim, Michael PanasonicMichael.Simhc@sg.panasonic.com Singh, Harkirat Samsunghar.singh@sisa.samsung.com Soffer, Menashe IntelMenashe.soffer@intel.com Song, SeunghoSK Telecomshsong@sktelecom.com Slide 4Haeyoung Jun, Samsung, et. al. Date: MAY, 2010

5 doc.: IEEE 802.11-10/0445r1 Submission Author(s)/Supporter(s): NameCompanyAddressPhoneemail Sorin, Simha WilocitySimha.sorin@wilocity.com Smith, Matt Atherosmatt.smith@atheros.com Stacey, Robert IntelRobert.stacey@intel.com Subramanian, Ananth I2Rsananth@i2r.a-star.edu.sg Sutskover, Ilan IntelIlan.sutskover@intel.com Taghavi, Hossain Qualcommmtaghavi@qualcomm.com Takahashi, Kazuaki Panasonictakahashi.kazu@jp.panasonic.com Toyoda, Ichihiko NTTtoyoda.ichihiko@lab.ntt.co.jp Trachewsky, Jason Selfjtrachewsky@gmail.com Trainin, Solomon IntelSolomon.trainin@intel.com Usuki, Naoshi Panasonicusuki.naoshi@jp.panasonic.com Varshney, Prabodh Nokiaprabodh.varshney@nokia.com Vertenten, Bart NXPbart.vertenten@nxp.com Vlantis, George STMicroelectronicsgeorge.vlantis@st.com Wang, Chao-Chun MediaTekchaochun.wang@mediatek.com Wang, HomberTMChomber@emcite.com Wang, James MediaTekjames.wang@mediatek.com Wong, David Tung Chong I2Rwongtc@i2r.a-star.edu.sg Yee, James MediaTekjames.yee@mediatek.com Yucek, Tevfik AtherosTevfik.Yucek@Atheros.com Yong, Su Khiong Marvellskyong@marvell.com Zhang, Hongyuan Marvellhongyuan@marvell.com Slide 5Haeyoung Jun, Samsung, et. al. Date: MAY, 2010

6 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 6Haeyoung Jun, Samsung, et. al.

7 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 7Haeyoung Jun, Samsung, et. al.

8 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 8Haeyoung Jun, Samsung, et. al.

9 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 9Haeyoung Jun, Samsung, et. al.

10 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 10Haeyoung Jun, Samsung, et. al.

11 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 11Haeyoung Jun, Samsung, et. al.

12 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 12Haeyoung Jun, Samsung, et. al.

13 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 13Haeyoung Jun, Samsung, et. al.

14 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 14Haeyoung Jun, Samsung, et. al.

15 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 i th AID entry in the NextPCP List element received from the PCP becomes the i th Implicit candidate PCP –All implicit candidate PCP should request STA / pseudo-static scheduling information from the PCP by transmitting an Information Request. If the i th 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 15Haeyoung Jun, Samsung, et. al.

16 doc.: IEEE 802.11-10/0445r1 Submission PCP Handover OrderInformation 1Category 2Action 3Handover Reason 4Handover Remaining BI OrderInformation 1Category 2Action 3Handover Result 4Handover Reject Reason Element IDLengthNew PCP AIDRemaining BIs Octets:1111 Element ID LengthToken AID of NextPCP 1 … AID of NextPCP n Octets:1111…1 Handover Request frameHandover Response frame PCP Handover element Next PCP List element Date: MAY, 2010 Slide 16Haeyoung Jun, Samsung, et. al.

17 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 17Haeyoung Jun, Samsung, et. al.

18 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 18Haeyoung Jun, Samsung, et. al.

19 doc.: IEEE 802.11-10/0445r1 Submission Link Adaptation Element IDLengthActionMCS Link Margin SNR Reference Timestamp Octets:11 1 11 1 4 Preferred Action ValueMeaning 0No Preference 1Change MCS 2Change Transmit Power 3Fast Session Transfer (FST) 4Power conserve mode 5-7reserved OrderInformation 1Category 2Action 3Dialog Token OrderInformation 1Category 2Action 3Dialog Token 4Link Margin Link Margin Request frameLink Margin Response frame Link Margin element Date: MAY, 2010 Slide 19Haeyoung Jun, Samsung, et. al.

20 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 20Haeyoung Jun, Samsung, et. al.


Download ppt "Doc.: IEEE 802.11-10/0445r1 Submission Date: MAY, 2010 Haeyoung Jun, Samsung, et. al.Slide 1 MAC Link Maintenance Date: 2010-05-19 Author(s)/Supporter(s):"

Similar presentations


Ads by Google