Traffic Generation Information for Proactive Load Management December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Traffic Generation Information for Proactive Load Management Date: 2007-01-09 Authors: Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// 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 stuart@ok-brit.com 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Moo Ryong Jeong, DoCoMo USA Labs Moo Ryong Jeong, DoCoMo USA Labs

December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Abstract This slide is about identification of voice terminals to improve QoS effectiveness in accordance with Req 2030 Moo Ryong Jeong, DoCoMo USA Labs Moo Ryong Jeong, DoCoMo USA Labs

Motivation Blocking Probability December 2006 doc.: IEEE 802.11-07/0081r0 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 802.11 standard Bottom line: 802.11 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-emails, … Moo Ryong Jeong, DoCoMo USA Labs Moo Ryong Jeong, DoCoMo USA Labs

Blocking Probability Management in Telephony December 2006 doc.: IEEE 802.11-07/0081r0 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

Two Types of Load Management December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Two Types of Load Management Reactive Load management based on existing traffic generation STA associates with AP of best QoS Appropriate for active STAs that are generating traffic Also applicable to inactive STAs if they are known to be a voice terminal Proactive Load management based on existing and potential traffic generation STA associates with AP of least blocking probability Appropriate for inactive STAs that are not generating traffic Possible if you can tell whether a STA is voice terminal before it becomes active Either case, identification of voice terminals is useful Moo Ryong Jeong, DoCoMo USA Labs Moo Ryong Jeong, DoCoMo USA Labs

Associate with AP1 or AP2? Assumptions January 2007 December 2006 doc.: IEEE 802.11-07/0081r0 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

Current Load Management in 802.11 Standard December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Current Load Management in 802.11 Standard 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 802.11 unless voice session is on-going. Many terminals never become a voice terminal for the lifetime of operation. Only allows load balancing based on existing load (e.g. available admission capacity) Potential load from associated but inactive STAs are simply ignored Moo Ryong Jeong, DoCoMo USA Labs Moo Ryong Jeong, DoCoMo USA Labs

Possible Improvements by Knowing Inactive Voice Terminals December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Possible Improvements by Knowing Inactive Voice Terminals Reduce the blocking probability by influencing the number of voice terminal in an AP Blocking probability= number of unsuccessful calls / number of offered calls Number of offered calls are dependent on the number of voice terminals Manage load before it becomes real Balance the load before it becomes critical Moo Ryong Jeong, DoCoMo USA Labs Moo Ryong Jeong, DoCoMo USA Labs

December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Solutions As far as identification of voice terminals can be done, we are flexible in terms of the specific approach Here are some possible approaches Option 1: traffic generation information in (re)association request See Option 1 in 07/0081r1 for normative text Option 2: voice service bit in Wireless Network Management Capabilities field See Option 2 in 07/0081r1 for normative text Option 3: Admission Control Traffic Query information element in (re)association request See 06/1828r2 for normative text Option 4: ADDTS indication or provisional ADDTS Normative text to be prepared if needed Moo Ryong Jeong, DoCoMo USA Labs Moo Ryong Jeong, DoCoMo USA Labs

December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Option 1 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

(Re)Association Request Frame December 2006 doc.: IEEE 802.11-07/0081r0 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

Traffic Generation Element December 2006 doc.: IEEE 802.11-07/0081r0 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

Traffic Generation Flags December 2006 doc.: IEEE 802.11-07/0081r0 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

Traffic Generation Flags (Cont’d) December 2006 doc.: IEEE 802.11-07/0081r0 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

December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Option 2 B0 B1 B2 B3 B4 B5 B6 B7 B15 Event Log Diagnostics Multicast Alert Presence FBMS Proxy ARP Service Voice Service Reserved Bit2: 1 9 The Voice Service bit set to 1 indicates that the STA supports voice service. The Voice Service bit set to 0 indicates that the STA does not support voice service. The Voice Service bit is set from the configuration of a voice application, supplied via SME. A STA is capable of voice service if a voice application is configured to initiate voice service upon arrival or generation of voice session, and it is not capable of voice service otherwise. Voice service capability of a STA may change upon initial configuration or configuration change of the voice application. If voice service capability of a STA is changed after a most recent association or reassociation, the STA shall send to the serving AP a reassociation request frame with updated Voice Service bit. Initiation of a voice service is not considered as a change of configuration. Moo Ryong Jeong, DoCoMo USA Labs Moo Ryong Jeong, DoCoMo USA Labs

Conclusion Voice terminals can be identified with negligible overhead December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Conclusion Voice terminals can be identified with negligible overhead Three octets per (re)association (Option 1) Use of 1 bit in the existing field (Option 2) As little as 6 octets per (re)association (Option 3) However, Traffic Generation Information allows blocking probability to be addressed in 802.11 framework Minimal normative requirements Moo Ryong Jeong, DoCoMo USA Labs Moo Ryong Jeong, DoCoMo USA Labs

December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Straw Polls Identification of voice terminals within 802.11 standard is necessary Yes: No: Abstain: Moo Ryong Jeong, DoCoMo USA Labs Moo Ryong Jeong, DoCoMo USA Labs

December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Straw Polls Which approaches do you like? (You can vote multiple times if you like more than one) Option 1: traffic generation information in (re)association request See Option 1 in 07/0081r1 for normative text Option 2: voice service bit in Wireless Network Management Capabilities field See Option 2 in 07/0081r1 for normative text Option 3: Admission Control Traffic Query information element in (re)association request See 06/1828r2 for normative text Option 4: ADDTS indication or provisional ADDTS Normative text to be prepared if needed Moo Ryong Jeong, DoCoMo USA Labs Moo Ryong Jeong, DoCoMo USA Labs

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

Informative Texts (Option 1) December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Informative Texts (Option 1) 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

Informative Texts (Option 1) December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Informative Texts (Option 1) 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

Informative Texts (Option 1) December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Informative Texts (Option 1) 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

Informative Texts (Option 1) December 2006 doc.: IEEE 802.11-07/0081r0 January 2007 Informative Texts (Option 1) 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