Date post: | 01-Apr-2015 |
Category: |
Documents |
Upload: | glenn-kewley |
View: | 213 times |
Download: | 1 times |
doc.: IEEE 802.11-10/0436r2
Submission Slide 1 Naveen Kakani, Nokia et., al
May 2010
Slide 1
< Fast Session Transfer NT >Date: 2010-05-18
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/0436r2
Submission
May 2010
Slide 2 Naveen Kakani, Nokia et., alSlide 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]
doc.: IEEE 802.11-10/0436r2
Submission
May 2010
Slide 3 Naveen Kakani, Nokia et., alSlide 3
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]
doc.: IEEE 802.11-10/0436r2
Submission
May 2010
Slide 4 Naveen Kakani, Nokia et., alSlide 4
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]
doc.: IEEE 802.11-10/0436r2
Submission
May 2010
Slide 5 Naveen Kakani, Nokia et., alSlide 5
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]
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
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