Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.: IEEE 802.11-10/0436r2 SubmissionSlide 1 Naveen Kakani, Nokia et., al May 2010 Slide 1 Date: 2010-05-18 Author(s)/Supporter(s): NameCompanyAddressPhoneemail.

Similar presentations


Presentation on theme: "Doc.: IEEE 802.11-10/0436r2 SubmissionSlide 1 Naveen Kakani, Nokia et., al May 2010 Slide 1 Date: 2010-05-18 Author(s)/Supporter(s): NameCompanyAddressPhoneemail."— Presentation transcript:

1 doc.: IEEE 802.11-10/0436r2 SubmissionSlide 1 Naveen Kakani, Nokia et., al May 2010 Slide 1 Date: 2010-05-18 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/0436r2 Submission May 2010 Slide 2 Naveen Kakani, Nokia et., al 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

3 doc.: IEEE 802.11-10/0436r2 Submission May 2010 Slide 3 Naveen Kakani, Nokia et., al Slide 3 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

4 doc.: IEEE 802.11-10/0436r2 Submission May 2010 Slide 4 Naveen Kakani, Nokia et., al Slide 4 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

5 doc.: IEEE 802.11-10/0436r2 Submission May 2010 Slide 5 Naveen Kakani, Nokia et., al Slide 5 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

6 doc.: IEEE 802.11-10/0436r2 Submission May 2010 Slide 6 Naveen Kakani, Nokia et., al 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 Slide 6

7 doc.: IEEE 802.11-10/436r1 Submission May 2010 Naveen Kakani, Nokia et., al Slide 7 Definition What is a Session ? –State information kept in a pair of STAs that have an established direct PHY link (i.e., excludes forwarding). What is Fast Session Transfer ? –The transfer of a session from one physical channel to another channel when the communicating STAs both have matching radios in the frequency band they wish to communicate.

8 doc.: IEEE 802.11-10/436r1 Submission May 2010 Naveen Kakani, Nokia et., al Slide 8 Scenarios to consider Scenario 1: Either a PCP or AP is one of end-points of the session. Scenario 2: Neither a PCP nor an AP is an end-point of the session but the two STAs involved in the Session are communicating directly It is likely that in both the scenarios the multi-band STA may have multiple MAC addresses or single MAC address and may be communicating simultaneously in the bands that it is capable of operating. Multi-band-capable STA AP/PCP STA1STA2

9 doc.: IEEE 802.11-10/436r1 Submission May 2010 Naveen Kakani, Nokia et., al Slide 9 Example Scenario STAA and STAB operating in LB After FST, STAA and STAB operating in UB STAA and STAB are associated with AP in 2.4/5GHz and have a Direct Link established STAA and STAB can be in the vicinity of PCP networks STAA moves towards STAB and they move the session (that was transported over DLS in 2.4/5GHz) to 60 GHz band

10 doc.: IEEE 802.11-10/436r1 Submission May 2010 Naveen Kakani, Nokia et., al Slide 10 FST Steps Step 1 : FST Setup –Parameter and capability negotiation via FST Setup Request and FST Setup Response Frames (7.4.14) Multiband Element (7.3.2.101) -> Mode of FST Session, STA capabilities in new Band (connection capabilities), Regulatory Information of new Band, Security Parameters, Role of the STA in new Band Session Transition Element (7.3.2.107) -> Session ID (FSTS ID, assigned by the initiator i.e., FST Request frame transmitter), Session Type (intended type of communication mode in new Band) Streams being switched : Switching Streams Element (7.3.2.106) Wakeup Schedule -> advertises the BI during which the STA is awake (7.3.2.94) Awake Window -> length of Awake Period (7.3.2.100) during CBP period in a BI –Mode of FST Session : Transparent: Each of the STAs participating in the same FST session has the same MAC addresses in both bands Non-transparent: At least one of the STA participating in the same FST session has different MAC addresses in each band

11 doc.: IEEE 802.11-10/436r1 Submission May 2010 Naveen Kakani, Nokia et., al Slide 11 FST Steps continued …Step 1 Parameter negotiation by : –ADDTS, DELTS, ADDBA, DELBA frames –Multiband Element is included if the frames are transmitted in band other than the band where the session is intended to be transferred –TCLAS Element is included if the FST Session is in non-transparent mode FST Setup Response with : –Status Code = 55, Pending, no transmission of the FST setup request –Status Code = 39, One or more parameters of the FST Setup Request is invalid and the responder suggests alternative parameters –Status Code = 37, Responder rejects the request. One particular case is that values of the regulatory class and channel number fields within the Multi-band element, if any, received in the FST Setup Request frame is different than the value of the corresponding fields within the Multi-band element, if any, transmitted in the following FST Setup Response

12 doc.: IEEE 802.11-10/436r1 Submission May 2010 Naveen Kakani, Nokia et., al Slide 12 FST Steps.. continued Step 2 : FST Switch –Controlled by Status Code in FST Response Frame FST Response Frame with Status Code = 0 has LLT = 0 -> Switch is immediate FST Response Frame with Status Code = 0 has LLT > 0 –If all the streams are not being switched it is possible to switch each stream individually (Stream based LLT) or all the streams together (STA based LLT) –An initiator and responder perform the STA-based and stream-based Link Loss Countdown as follows: STA-based Link Loss Countdown: both initiator and responder remain in the Setup completion state and start a Link Loss countdown timer with an initial value of LLT*32 usec. The Link Loss countdown is reloaded with the value of LLT*32 usec every time that a unicast frame is received from the peer STA of the FST session. Stream-based Link Loss Countdown: both the initiator and responder start a Link Loss countdown timer with an initial value of LLT*32 usec for each stream identified within the Switching Stream element. The Link Loss countdown for a stream is reloaded with the value of LLT*32 usec every time that a unicast frame for that stream is received from the peer STA of the FST session -The FST transition for the STA, if STA-based, or the stream, if stream-based, from the Setup completion state to the Transition done state occurs immediately after the corresponding Link Loss countdown timer transitions from one to zero within any of the initiator or responder of the FST session –FST Request with “LLT = 0”

13 doc.: IEEE 802.11-10/436r1 Submission May 2010 Naveen Kakani, Nokia et., al Slide 13 Frame Exchange Sequence - Example STA1, FST initiating STA FST_Req FST_Res, Status code “Parameters Invalid” FST_Req, Includes New Parameters FST_Res, Status code “Accept” STA2, FST responding STA FST_Req Status codes for FST_Res -Pending -Parameters invalid -Reject -Accept

14 doc.: IEEE 802.11-10/436r1 Submission May 2010 Naveen Kakani, Nokia et., al Slide 14 FST Switch Confirmation Successful transmission of FST ACK Request and reception of FST ACK Response in new Band (or) Successful frame exchange FST ACK request frame is as defined in 7.4.14.5 and FST ACK response frame is as defined in 7.4.14.6 -> includes FSTS ID

15 doc.: IEEE 802.11-10/436r1 Submission May 2010 Naveen Kakani, Nokia et., al Slide 15 FST Mechanism (11.34)


Download ppt "Doc.: IEEE 802.11-10/0436r2 SubmissionSlide 1 Naveen Kakani, Nokia et., al May 2010 Slide 1 Date: 2010-05-18 Author(s)/Supporter(s): NameCompanyAddressPhoneemail."

Similar presentations


Ads by Google