1. Traffic Generation Information for Proactive Load Management
December 2006
doc.: IEEE /0080r0
January 2007
Traffic Generation Information for Proactive Load Management
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

2. December 2006
doc.: IEEE /0080r0
January 2007
Abstract
This slide is to propose Traffic Generation information element for proactive load management to improve QoS effectiveness in accordance with Req 2030
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

3. Motivation Blocking Probability
December 2006
doc.: IEEE /0080r0
January 2007
Motivation
Blocking Probability
One aspect of the quality a user experiences when making a call
Defined as the probability that a successful call connection will not be achieved
= number of unsuccessful calls / number of offered calls
Managed by limiting the number of users in a system and a BS
Important QoS metric in telecommunication industry but yet to be addressed in the standard
Bottom line: needs a new mechanisms so that blocking probability can be considered in load balancing of VoIP terminals
It may be applicable to other types of services and terminals
Video calls, push- s, …
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

4. Blocking Probability Management in Telephony
December 2006
doc.: IEEE /0080r0
January 2007
Blocking Probability Management in Telephony
If M >= N, blocking probability must be taken into account
Blocking probability depends on the number of associated terminals (M), whether active or inactive BS
With the same capacity, traffic intensity, M should be maintained the same across multiple BSs to ensure minimum blocking probability
N: Voice capacity
M: # of associated terminals
λ: Call arrival rate
1/µ: Average call lasting time
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

5. Two Types of Load Management
December 2006
doc.: IEEE /0080r0
January 2007
Two Types of Load Management
Reactive
Load management based on existing traffic generation
Appropriate for active STAs that are generating traffic
STA associates with AP of best QoS
Proactive
Load management based on existing and potential traffic generation
Appropriate for inactive STAs that are not generating traffic
STA associates with AP of least blocking probability
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

6. Associate with AP1 or AP2? Assumptions January 2007
December 2006
doc.: IEEE /0080r0
January 2007
Associate with AP1 or AP2?
Assumptions
All data terminals are active
All VoIP terminals are in standby
Voice capacity is 3
Highest QoS? AP2
Lowest blocking probability? AP2
By blocking paging due to uninterested packets, we can dramatically increase time in idle mode, thus battery life.
AP1
ME!
AP2
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

7. Current Load Management in 802.11 Standard
December 2006
doc.: IEEE /0080r0
January 2007
Current Load Management in Standard
Only allows load balancing based on existing load (e.g. available admission capacity)
Potential load from associated but inactive STAs are simply ignored
No mechanism to distinguish voice terminals from data terminals unless sessions are active
Voice is only a type of application sharing the network
A terminal may or may not be a voice terminal depending on the activation of voice application. The activation of voice application is invisible to unless voice session is on-going. Many terminals never become a voice terminal for the lifetime of operation.
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

8. December 2006
doc.: IEEE /0080r0
January 2007
Proposed Solution
Include Traffic Generation Element in association and reassociation request messages
If (re)associating STA has the expectation of generating traffic belonging to a UP, Traffic Generation Flag bit for the UP is set to 1
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

9. (Re)Association Request Frame
December 2006
doc.: IEEE /0080r0
January 2007
(Re)Association Request Frame
Insert a new row into table 10 as follows:
Table 10—Associstion Request frame body
Order
Information
Notes 12
Traffic Generation
The Traffic Generation element is present if dot11WirelessManagementImplemented is true.
Insert a new row into table 12 as follows:
Table 12—Reassocistion Request frame body
Order
Information
Notes 15
Traffic Generation
The Traffic Generation element is present if dot11WirelessManagementImplemented is true.
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

10. Traffic Generation Element
December 2006
doc.: IEEE /0080r0
January 2007
Traffic Generation Element
Figure X---Traffic Generation Element format
Element ID
Length
Traffic Generation Flags
Octets: 1
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

11. Traffic Generation Flags
December 2006
doc.: IEEE /0080r0
January 2007
Traffic Generation Flags
Table 49a－Traffic Generation Flags Definition
Bit(s)
Description
UP 0 Traffic 1
UP 1 Traffic 2
UP 2 Traffic 3
UP 3 Traffic 4
UP 4 Traffic 5
UP 5 Traffic 6
UP 6 Traffic 7
UP 7 Traffic
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

12. Traffic Generation Flags (Cont’d)
December 2006
doc.: IEEE /0080r0
January 2007
Traffic Generation Flags (Cont’d)
Constructed at the SME
No normative requirements except that a Flag bit shall be set to 0 if there is no information available to SME enough to support the expectation of traffic generation
An informative description is given of how the Flags may be constructed
May be used for load management
It is Up to vendor implementation
An informative description is given on proactive load management based on the Flags
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

13. December 2006
doc.: IEEE /0080r0
January 2007
Conclusion
Traffic Generation Information introduces negligible overhead
Three octets per (re)association
However, Traffic Generation Information allows proactive load management to be done in framework
Blocking probability, one important aspect of quality in telecommunication industry, can be better addressed
Minimal or no normative requirements for construction and use of the information
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

14. December 2006
doc.: IEEE /0080r0
January 2007
Straw Poll
Traffic Generation Information is necessary in standard
Yes:
No:
Abstain:
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

15. Annex January 2007 December 2006 doc.: IEEE 802.11-07/0080r0
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

16. Informative Texts Construction of Traffic Generation Information
December 2006
doc.: IEEE /0080r0
January 2007
Informative Texts
Construction of Traffic Generation Information
The Traffic Generation Flags may be constructed from two aspects of traffic generation by applications: whether traffic generation is required for applications and whether a specific UP is required for the generated traffic. Note that such aspects may be known before the traffic is actually generated. For example, an application may be configured to generate traffic upon the initiation of a user session and to use a specific UP if traffic is generated. Such configuration can be done before the session initiation, and during the time between the configuration and the session initiation the application is in standby, waiting for the initiation of a user session. Phone application is a typical example of such applications.
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

17. December 2006
doc.: IEEE /0080r0
January 2007
Informative Texts
Construction of Traffic Generation Information (Cn’d)
The aspects of traffic generation by an application may be supplied to SME on initial configuration or on any changes of configuration by the application. The realization of traffic generation expectation, that is, actual traffic generation, is not considered as a change of configuration. When the traffic generation aspects are supplied, the Traffic Generation Flags are updated accordingly.
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

18. Informative Texts Interpretation of Traffic Generation Element
December 2006
doc.: IEEE /0080r0
January 2007
Informative Texts
Interpretation of Traffic Generation Element
An AP may maintain station counts for each user priority (UP); that is, the number of STAs that are associated with the AP and expected to generate traffic belonging to each UP is maintained. Similarly, an AP may maintain station counts for each access category (AC). Those station counts may be interpreted as the number of STAs that are expected to access channel to transmit MSDUs of the corresponding UP or AC.
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs

19. Informative Texts Use of Traffic Generation Element
December 2006
doc.: IEEE /0080r0
January 2007
Informative Texts
Use of Traffic Generation Element
AP and network may use those station counts for the purpose of BSS load management that is defined elsewhere in the standard. Note that if STAs are not generating traffic, actual load or channel access by the STAs does not exist yet. Because such potential load can be managed proactively before it becomes real load, load management based on Traffic Generation information can be effective to control blocking probability (probability that a successful user session will not be achieved), an aspect of quality a user experiences when initiating a session. Phone application is a typical example that benefits from proactive load management to control blocking probability.
Moo Ryong Jeong, DoCoMo USA Labs
Moo Ryong Jeong, DoCoMo USA Labs