Post on 04-Jan-2016
doc.: IEEE 802.11-10/0436r1
Submission Slide 1 Naveen Kakani, Nokia et., al
May 2010
Slide 1
< Fast Session Transfer NT >Date: 2010-05-17
Author(s)/Supporter(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
Cariou, Laurent Orange laurent.cariou@orange-ftgroup.com
Chamberlin, Philippe Technicolor R&I philippe.chambelin@technicolor.com
Chang, Kapseok ETRI kschang@etri.re.kr
Chin, Francois I2R chinfrancois@i2r.a-star.edu.sg
Christin, Philippe Orange philippe.christin@orange-ftgroup.com
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
Derham, Thomas Orange thomas.derham@orange-ftgroup.com
Dorsey, John Apple jdorsey@apple.com
Elboim, Yaron Wilocity yaron.elboim@wilocity.com
Fischer, Matthew Broadcom mfischer@broadcom.com
doc.: IEEE 802.11-10/0436r1
Submission
May 2010
Slide 2 Naveen Kakani, Nokia et., alSlide 2
Author(s)/Supporter(s):Name Company Address Phone email
Giraud, Claude NXP claude.giraud@nxp.comGolan, Ziv Wilocity Ziv.golan@wilocity.com
Gong, Michelle Intel Michelle.x.gong@intel.comGrandhi, Sudheer InterDigital sagrandhi802@gmail.com
Grieve, David Agilent david_grieve@agilent.comGrodzinsky, Mark Wilocity Mark.grodzinsky@wilocity.com
Hansen, Christopher Broadcom chansen@broadcom.comHart, Brian Cisco brianh@cisco.com
Hassan, Amer Microsoft amerh@microsoft.comHong, Seung Eun ETRI iptvguru@etri.re.krHosoya, Kenichi NEC k-hosoya@ce.jp.nec.comHosur, Srinath Texas Instruments hosur@ti.com
Hsu, Alvin MediaTek alvin.hsu@mediatek.comHsu, Julan Samsung Julan.hsu@samsung.com
Hung, Kun-Chien MediaTek kc.hung@mediatek.comJain, Avinash Qualcomm avinashj@qualcomm.com
Jauh, Alan MediaTek alan.jauh@mediatek.comJayabal, Raymond Jararaj s/o I2R jraymond@i2r.a-star.edu.sg
Jeon, Paul LGE bjjeon@lge.comJin, Sunggeun ETRI sgjin@etri.re.kr
Jones, VK Qualcomm vkjones@qualcomm.comJoseph, Stacy Beam Networks stacy@beamnetworks.com
Jun, Haeyoung Samsung Haeyoung.jun@samsung.comKaaja, Harald Nokia harald.kaaja@nokia.comKafle, Padam Nokia padam.kafle@nokia.com
Kakani, Naveen Nokia naveen.kakani@nokia.comKasher, Assaf Intel Assaf.kasher@intel.comKasslin, Mika Nokia mika.kasslin@nokia.comKim, Hodong Samsung hodong0803.kim@samsung.com
doc.: IEEE 802.11-10/0436r1
Submission
May 2010
Slide 3 Naveen Kakani, Nokia et., alSlide 3
Author(s)/Supporter(s):Name Company Address Phone email
Kim, Yongsun ETRI doori@etri.re.krKreifeldt, Rick Harman International rick.kreifeldt@harman.comKwon, Edwin Samsung cy.kwon@samsung.com
Kwon, Hyoungjin ETRI kwonjin@etri.re.krKwon, Hyukchoon Samsung hyukchoon.kwon@samsung.com
Laine, Tuomas Nokia tuomas.laine@nokia.comLakkis, Ismail Tensorcom ilakkis@tensorcom.comLee, Hoosung ETRI hslee@etri.re.kr
Lee, Keith AMD keith.lee@amd.comLee, Wooyong ETRI wylee@etri.re.kr
Liu, Yong Marvell yongliu@marvell.comLou, Hui-Ling Marvell hlou@marvell.com
Majkowski, Jakub Nokia jakub.majkowski@nokia.comMarin, Janne Nokia janne.marin@nokia.com
Maruhashi, Kenichi NEC k-maruhashi@bl.jp.nec.comMatsumoto, Taisuke Panasonic matsumoto.taisuke@jp.panasonic.com
Meerson, Yury Wilocity Yury.meerson@wilocity.comMese, Murat Broadcom mesem@broadcom.com
Montag, Bruce Dell bruce_montag@dell.comMyles, Andrew Cisco amyles@cisco.com
Nandagopalan, Saishankar Broadcom nsai@broadcom.comNgo, Chiu Samsung Chiu.ngo@samsung.com
Nikula, Eero Nokia eero.nikula@nokia.comPark, DS Samsung dspark@samsung.com
Park, Minyoung Intel Minyoung.park@intel.comPeng, Xiaoming I2R pengxm@i2r.a-star.edu.sg
Pi, Zhouyue Samsung zpi@sta.samsung.comPonnampalam, Vish MediaTek vish.ponnampalam@mediatek.com
Prasad, Narayan NEC prasad@nec-labs.com
doc.: IEEE 802.11-10/0436r1
Submission
May 2010
Slide 4 Naveen Kakani, Nokia et., alSlide 4
Author(s)/Supporter(s):Name Company Address Phone email
Prat, Gideon Intel Gideon.prat@intel.comQu, Xuhong I2R quxh@i2r.a-star.edu.sg
Ramachandran, Kishore NEC kishore@nec-labs.comRaymond, Yu Zhan Panasonic Raymond.Yuz@sg.panasonic.com
Roblot, Sandrine Orange sandrine.roblot@orange-ftgroup.comRonkin, Roee Wilocity Roee.ronkin@wilocity.comRozen, Ohad Wilocity Ohad.rozen@wilocity.com
Sachdev, Devang NVIDIA dsachdev@nvidia.comSadri, Ali Intel Ali.S.Sadri@intel.com
Sampath, Hemanth Qualcomm hsampath@qualcomm.comSanderovich, Amichai Wilocity Amichai.sanderovich@wilocity.com
Sankaran, Sundar Atheros Sundar.Sankaran@Atheros.comScarpa, Vincenzo STMicroelectronics vincenzo.scarpa@st.com
Seok, Yongho LGE yongho.seok@lge.comShao, Huai-Rong Samsung hr.shao@samsung.comShen, Ba-Zhong Broadcom bzshen@broadcom.com
Sim, Michael Panasonic Michael.Simhc@sg.panasonic.comSingh, Harkirat Samsung har.singh@sisa.samsung.comSoffer, Menashe Intel Menashe.soffer@intel.comSong, Seungho SK Telecom shsong@sktelecom.comSorin, Simha Wilocity Simha.sorin@wilocity.comSmith, Matt Atheros matt.smith@atheros.com
Stacey, Robert Intel Robert.stacey@intel.comSubramanian, Ananth I2R sananth@i2r.a-star.edu.sg
Sutskover, Ilan Intel Ilan.sutskover@intel.com
doc.: IEEE 802.11-10/0436r1
Submission
May 2010
Slide 5 Naveen Kakani, Nokia et., alSlide 5
Author(s)/Supporter(s):Name Company Address Phone email
Taghavi, Hossain Qualcomm mtaghavi@qualcomm.comTakahashi, Kazuaki Panasonic takahashi.kazu@jp.panasonic.comTrachewsky, Jason Self jtrachewsky@gmail.comTrainin, Solomon Intel Solomon.trainin@intel.com
Usuki, Naoshi Panasonic usuki.naoshi@jp.panasonic.comVarshney, Prabodh Nokia prabodh.varshney@nokia.com
Vertenten, Bart NXP bart.vertenten@nxp.comVlantis, George STMicroelectronics george.vlantis@st.com
Wang, Chao-Chun MediaTek chaochun.wang@mediatek.comWang, Homber TMC homber@emcite.comWang, James MediaTek james.wang@mediatek.com
Wong, David Tung Chong I2R wongtc@i2r.a-star.edu.sgYee, James MediaTek james.yee@mediatek.com
Yucek, Tevfik Atheros Tevfik.Yucek@Atheros.comYong, Su Khiong Marvell skyong@marvell.comZhang, Hongyuan Marvell hongyuan@marvell.com
doc.: IEEE 802.11-10/0436r1
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/432r1 (slides) and 802.11-10/433r1 (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
doc.: IEEE 802.11-10/436r1
Submission
May 2010
Naveen Kakani, Nokia et., alSlide 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.
doc.: IEEE 802.11-10/436r1
Submission
May 2010
Naveen Kakani, Nokia et., alSlide 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 directlyIt 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
STA1 STA2
doc.: IEEE 802.11-10/436r1
Submission
May 2010
Naveen Kakani, Nokia et., alSlide 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
doc.: IEEE 802.11-10/436r1
Submission
May 2010
Naveen Kakani, Nokia et., alSlide 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
doc.: IEEE 802.11-10/436r1
Submission
May 2010
Naveen Kakani, Nokia et., alSlide 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
doc.: IEEE 802.11-10/436r1
Submission
May 2010
Naveen Kakani, Nokia et., alSlide 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”
doc.: IEEE 802.11-10/436r1
Submission
May 2010
Naveen Kakani, Nokia et., alSlide 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
doc.: IEEE 802.11-10/436r1
Submission
May 2010
Naveen Kakani, Nokia et., alSlide 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
doc.: IEEE 802.11-10/436r1
Submission
May 2010
Naveen Kakani, Nokia et., alSlide 15
FST Mechanism (11.34)
Initial state(Communicating
in Old band)
Setup completion state(Communicating
in Old band)
Transition done
state(Communicating
in New band)
Status<>0OR
Operation (New Band)=0
Transition confirmed state
(Full connectivity in New band)
LLT>0
Timeout or rejection or FST
Tear Down, initiated by any
STA
FST Setup Request, FST Setup Response
LLT=0 in the FST Setup Request
OR LLT transitions
from one to zero
FST Ack request, FST Ack response
OR successful frame exchange