1. Proposal for Fast Inter-BBS Transitions
January 2005
Proposal for Fast Inter-BBS Transitions
Jie Liang, Gang Wu, Xiaoning He
Paragon Wireless, Inc.
San Jose, CA
Hui Tang
CNC Broadband, Inc.
Beijing, China
Contact:
Liang et al

2. Executive Summary
January 2005
This proposal is focused on QoS aspects of fast inter-BSS transitions
More specifically, this proposal deals not only with signaling protocol but also innovative methods for speeding up packet delivery of the handoff signaling protocols using TGe mechanisms (HCCA and EDCA)
This proposal expedites packet delivery sequence for hand-off packets from security context transfer, to QoS traffic stream setup
HCCA based methods for bounded maxim delay
EDCA based methods for expedited hand-off related packet delivery
This proposal is beneficial for various handoff scenarios (proposed faster handshake, normal 4-way handshake, full 802.1x authentication, etc), and is designed also for seamless integration with other security-focused proposals (it does not affect key hierarchy or packet exchange sequence)
Liang et al

3. Expedited Handoff Packet Delivery - Motivation
January 2005
Expedited Handoff Packet Delivery - Motivation
Packet delivery latency in a BSS depends heavily on the network load (number of users, traffic pattern, etc.).
Handoff packets must contend for the medium just like other contention based packets.
Due to the variability of the packet delivery delay, even with the proposed shortened handoff signaling protocol sequence, it is very difficult to have a bounded delay for fast BSS handoff.
To reach the goal of less than 50ms handoff latency, a method for expediting the delivery of fast BSS handoff protocol packets must be provided by TGr.
Liang et al

4. Packet Delivery Latencies
January 2005
Packet Delivery Latencies AP
VoIP
Phone
Roaming STA
High Priority AC
Regular Data Users: BE packets, 1000 bytes nominal packets
Liang et al

5. Packet Delivery Latencies
January 2005
Packet Delivery Latencies
Assumptions:
N: number of active users, CW-BE: contention window size for BE data, FrameSize: norminal BE MPDU size, R: PHY rate, Td: packet delivery delay
CW-VO: contention window size for high priority AC, α: CW-VO/CW-BE ratio of CW-VO and CW-BE
Factors considered:
Only considered packet deferment. No collision. No higher priority packets (EDCA) from other STAs.
We can derive a lower bound on the average packet delivery latency Td:
Td ≧ α2 · CW-BE/2 · min(1, N/CW-BE) · (DIFS+PreambleTime+FrameSize*8/PhyRate)
+CW-VO/2 ·aSlotTime
CW-VO/CW-BE N
FrameSize
(bytes)
Rate
(mbps)
Total Packets
Total Delay (lower bound)
7/15 15
1000 11 10
17.0ms 1
153ms
Liang et al

6. Expedited Delivery Sequence: HCCA based
January 2005
Proc.
delay
AP Proc.
delay
Proc.
delay
AP Proc.
delay P+ F P+ X B P D P P AP ● ● ●
scheduled G+ A A C E ● ● ●
Ack
SIFS
STA
PIFS
PIFS T3 T1 T2
Management or
802.1x data packets P+ X
QoS Data+CF-Poll
Ack frames G+ X P+ X+ A P
QoS CF-Poll
QoS data+CF-Ack
QoS Data+CF-Ack +
CF-Poll
T1: fast delivery setup period
T2: HCCA controlled handoff period
T3: 802.1x port open, payload delivery with TSPEC setup
CAP: polled access period
Payload packets
Liang et al

7. Fast Handoff Delivery Setup Procedure
January 2005
Fast handoff delivery is requested by STA through first handoff packet (e.g. open authentication request)
The request is through the inclusion of a Fast Handoff Packet Delivery (FHPD) Request information element
Fast handoff delivery request is granted or denied by AP in the next packet in the handoff sequence (e.g. open authentication response): handoff admission policy
The AP indicates to the requesting STA, through the inclusion of Fast Handoff Packet Delivery (FHPD) Status information element, the mode and parameters to be use for the subsequent handoff packets.
Modes supported: HCCA, EDCA
Parameters:
TSID (Traffic Stream ID) to be used for HCCA delivery
UP (user priority) to be used for EDCA delivery
Liang et al

8. Fast Handoff Packet Delivery (FHPD) Request Information Element
January 2005
Fast Handoff Packet Delivery (FHPD) Request Information Element
Element ID
Length
FHPD Control
Minimum Response Time
HCCA
(1 bit)
EDCA
(1 bit)
Preference
(2 bits)
Reserved
(4 bits) 1 1 1 2
Octects
Sent by STA
FHPD control:
- HCCA: HCCA mode is supported for FHPD
- EDCA: EDCA mode is supported for FHPD
- Preference: 10 – HCCA mode is preferred
01- EDCA mode is preferred
00 – best effort is preferred
11 – No preference
Minimum Response Time (STA processing delay):
The time that will take the Station to process an incoming handoff frame
T= this field * 32us
The AP can use this information to schedule the separation between a downlink (AP-STA) packet and a uplink CAP (polled access time)
Liang et al

9. Fast Handoff Packet Delivery (FHPD) Status Information Element
January 2005
Fast Handoff Packet Delivery (FHPD) Status Information Element
Element ID
Length
FHPD Control
FHPD Parameter
HCCA
(1 bit)
EDCA
(1 bit)
Mode
(2 bits)
Reserved
(4 bits)
TID
(4 bit)
Reserved
(4 bits) 1 1 1 1
Octects
Sent by AP
FHPD control: QoS mode to be used for packet delivery
Mode
Delivery Method 10
HCCA 01
EDCA 00
Reserved 11
FHPD Parameter:
TID:
HCCA: TSID to be used in HCCA polling
EDCA: User Priority to be used by the STA for handoff packets
Liang et al

10. HCCA Controlled Handoff
September 2002
doc.: IEEE /xxxr0
January 2005
HCCA Controlled Handoff
After the initial setup period (T1), the rest of the handoff signaling protocol can be delivered using HCCA mechanism for bounded delay
In HCCA controlled handoff, all downlink packets can be delivered through pre-emption by AP using PIFS after an on-air transmission
All uplink packets can be delivered through polling by AP
AP can schedule handoff exchange sequence around existing admitted TSPEC schedules, as well as considering minimum separation between consecutive handoff signaling frames.
Handoff time can be bounded and is not related to network load
The proposed methods can be applied to various handoff scenarios:
Cached PMK with accelerated handshake
Cached PMK with normal 4-way handshake
Full EAP/RADIUM authentication, 4-way handshake, TSPEC setup
This proposal also applies to the other proposals before TGr (e.g /r0 , /r0)
Liang et al
Eleanor Hepworth, Siemens

11. EDCA Controlled Handoff
January 2005
EDCA Controlled Handoff
After the initial setup period (T1), the STA is assigned a Priority to use for subsequent handoff packets (management frames and data frames such as the 802.1x frames and 4-way handshake frames)
The EDCA based signaling also allows the flexibility of protecting existing sessions (such as VoIP) from a flood of handoff management frames
In normal cases when the highest priority Access Category (AC) has excess bandwidth left, the highest priority AC (3) will be assigned
All uplink handoff packets can be delivered using this high priority queue
AP can still deliver downlink packets using AP preemption if it chooses to do so.
Unlike HCCA controlled handoff where delay can be bounded, EDCA based method will statistically achieve much faster handoff, but no delay bound can be guaranteed.
The EDCA method also can be applied to various handoff scenarios:
Cached PMK with accelerated handshake
Cached PMK with normal 4-way handshake
Full EAP/RADIUS authentication, 4-way handshake, TSPEC setup
The EDCA method also applies to the other proposals before TGr (e.g /1117r0 , /1127r0)
Liang et al

12. Performance: 802.11i 4-way handshake
September 2002
doc.: IEEE /xxxr0
Performance: i 4-way handshake
January 2005
Sequence
Packet
Sender
Length
(Bytes)
Delay (ms) (11mbps/1mbps) A
Open Authentication #1
STA 37
0.24/0.61 B
Open Authentication #2 AP 38
0.27/0.65 C
Re-Association Request 68
0.44/1.25 D
Re-Association Response 58
0.28/0.81 E
4-way packet #1
159
0.51/1.98 F
4-way packet #2
177
0.37/1.76 G
4-way packet #3
0.52/2.13 H
4-way packet #4
137
0.34/1.44 I
TSPEC request
101
0.46/1.52 J
TSPEC response
122
0.33/1.32
Total
3.76/13.47
SIP+Ack = *8/11=116 us/218us
PIF+POLL+PIF +Frame+Ack= *8/ STA frames = 390+ STA frames*8/11 /710 + STAframe*8
A: 96+(37*8)/11+SIFS+Ack= 239us / *8+218= 610us
B: PIFS+96+frame*8/11+SIFS+Ack= frame*8/11=242+frame*8/11=270
/ frame*8=344+38*8=648us
C: PIFS+POLL+PIFS+96+frame*8/11+SIFS+Ack = 390+frame*8/11=440 /
710+frame*8=1254
D: PIFS+96+frame*8/11+SIFS+Ack=242+frame*8/11=284 /
344+frame*8=808
E: PIFS+POLL+PIFS+96+frame*8/11+SIFS+Ack = frame*8/11=505 /
710+frame*8=1980
F: PIFS+96+frame*8/11+SIFS+Ack =242+frame*8/11=371 /
344+frame*8=1760
G: PIFS+POLL+PIFS+96+frame*8/11+SIFS+Ack = 390 +frame*8/11=519 /
710+frame*8=2130
H: PIFS+96+frame*8/1+SIFS+Ack = 242+frame*8/11=343 /
344+frame*8=1440
I: PIFS+POLL+PIFS+96+frame*8/11+SIFS+Ack = 390 +frame*8/11=464 /
710+frame*8=1518
J: PIFS+96+frame*8/11+SIFS+Ack = frame*8/11= /
344+frame*8=1320
Assumptions: 11mbps/1mbps PHY rate, HCCA controlled handoff, real-time response from STA and AP
All packet exchanges are done in one HCCA controlled burst sequence
The results do not change with network load
Liang et al
Eleanor Hepworth, Siemens

13. FHPD Capability Announcement
January 2005
FHPD Capability Announcement
AP indicates its support for Fast Handoff Packet Delivery (FHPD) by including a FHPD Status Information Element in its Beacon
Element ID
Length
FHPD Control
FHPD Parameter
HCCA
(1 bit)
EDCA
(1 bit)
Preference
(2 bits)
Reserved
(4 bits)
Reserved
(4 bit)
Reserved
(4 bits) 1 1 1 1
Octects
AP indicates its support for Fast Handoff Packet Delivery (FHPD) by including a FHPD Information Element in its Beacon
HCCA and EDCA bits in FHPD control indicate the modes supported by the AP
Preference bits in FHPD indicate the preferred mechanism in this BSS
Mode 10
HCCA 01
EDCA 00
Reserved 11
No Preference
Liang et al

14. January 2005
Conclusions
This proposal addresses a critical missing piece in Fast Inter-BSS handoff:
speedy delivery of the handoff packets
Using HCCA mode, a deterministic handoff delay bound can be guaranteed
Using EDCA mode, significant improvement can be obtained in handoff delay when 802.1x data frames are involved. It also allows better control of the handoff process (priority of the handoff frames vs. current active high-priority sessions)
This proposal achieves its benefits for various scenarios that will be encountered in real-world handoff applications:
Cached PMK exists
Full 802.1x authentication is needed
This proposal can be combined naturally with other proposals which try to reduce the number of packets in a handoff process to achieve better results.
Liang et al