U.S. patent application number 13/045622 was filed with the patent office on 2011-09-15 for advertisement of quality of service (qos) information for network management traffice in a wireless local area network (wlan).
This patent application is currently assigned to RESEARCH IN MOTION LIMITED. Invention is credited to Stephen McCann, Michael Peter Montemurro.
Application Number | 20110222520 13/045622 |
Document ID | / |
Family ID | 44072514 |
Filed Date | 2011-09-15 |
United States Patent
Application |
20110222520 |
Kind Code |
A1 |
Montemurro; Michael Peter ;
et al. |
September 15, 2011 |
ADVERTISEMENT OF QUALITY OF SERVICE (QoS) INFORMATION FOR NETWORK
MANAGEMENT TRAFFICE IN A WIRELESS LOCAL AREA NETWORK (WLAN)
Abstract
An access point advertises a management frame quality of service
(MFQ) policy that defines an access category used for transmitting
a first type of management frame. Each mobile station associated
with the access point is to prioritize transmission of management
frames according to the MFQ policy advertised by the access point,
unless a policy configuration request for the mobile station to
prioritize transmission of management frames according to a
different MFQ policy has been accepted.
Inventors: |
Montemurro; Michael Peter;
(Toronto, CA) ; McCann; Stephen; (Rownhams,
GB) |
Assignee: |
RESEARCH IN MOTION LIMITED
Waterloo
CA
|
Family ID: |
44072514 |
Appl. No.: |
13/045622 |
Filed: |
March 11, 2011 |
Current U.S.
Class: |
370/338 |
Current CPC
Class: |
H04W 28/24 20130101;
H04W 74/006 20130101; H04W 84/12 20130101 |
Class at
Publication: |
370/338 |
International
Class: |
H04W 84/02 20090101
H04W084/02 |
Foreign Application Data
Date |
Code |
Application Number |
Mar 15, 2010 |
CA |
2696037 |
Claims
1. A method for an access point, the method comprising: advertising
a management frame quality of service (MFQ) policy, wherein the MFQ
policy defines an access category used for transmitting a first
type of management frame.
2. The method as claimed in claim 1, wherein the access category
includes any access category among a plurality of access
categories.
3. The method as claimed in claim 1, wherein the access category is
indicative of a transmission priority used for transmitting the
first type of management frame, the transmission priority being any
transmission priority among a plurality of transmission
priorities.
4. The method as claimed in claim 3, wherein the transmission
priority is not a highest priority of transmission.
5. The method as claimed in claim 3, wherein the MFQ policy further
defines a second access category for a second type of management
frame, the second access category being indicative of another
transmission priority among the plurality of transmission
priorities.
6. The method as claimed in claim 1, wherein advertising the MFQ
policy comprises: generating an element comprising an indication of
how the MFQ policy differs from a default MFQ policy; and including
the element in one or more downlink frames transmitted by the
access point.
7. The method as claimed in claim 1, wherein advertising the MFQ
policy comprises: generating an element that defines the access
category for the first type of management frame; and transmitting
the element.
8. The method as claimed in claim 1, the method further comprising:
setting a change bit to a value indicative of a change to the MFQ
policy from a previous MFQ policy.
9. The method as claimed in claim 8, the method further comprising:
setting the change bit to a second value indicative of no change
once an interval has elapsed following the change.
10. A method for a mobile station within range of an access point,
the method comprising: receiving, from the access point, an
advertisement of a management frame quality of service (MFQ)
policy, wherein the MFQ policy defines an access category used for
transmitting a first type of management frame.
11. The method as claimed in claim 10, wherein the access category
includes any access category among a plurality of access
categories.
12. The method as claimed in claim 10, wherein the access category
is indicative of a transmission priority used for transmitting the
first type of management frame, the transmission priority being any
transmission priority among a plurality of transmission
priorities.
13. The method as claimed in claim 12, wherein the transmission
priority is not a highest priority of transmission.
14. The method as claimed in claim 12, wherein the MFQ policy
further defines a second access category for a second type of
management frame, the second access category being indicative of
another transmission priority among the plurality of transmission
priorities.
15. The method as claimed in claim 10, wherein receiving the
advertisement comprises: receiving an element that defines the
access category for the first type of management frame.
16. The method as claimed in claim 10, wherein receiving the
advertisement comprises: receiving a downlink frame transmitted by
the access point, wherein the downlink frame includes an element
comprising an indication of how the MFQ policy differs from a
default MFQ policy.
17. The method as claimed in claim 16, wherein the downlink frame
is a Generic Advertisement Service response frame, the method
further comprising: transmitting a request to the access point for
the MFQ policy prior to receiving the Generic Advertisement Service
response frame.
18. The method as claimed in claim 10, the method further
comprising: assigning the access category to management frames of
the first type according to the MFQ policy.
19. The method as claimed in claim 18, the method further
comprising: transmitting the management frames using the access
category.
20. An access point comprising: a processor configured to:
advertise a management frame quality of service (MFQ) policy,
wherein the MFQ policy defines an access category used for
transmitting a first type of management frame.
21. The access point as claimed in claim 20, wherein the access
category includes any access category among a plurality of access
categories.
22. The access point as claimed in claim 20, wherein the access
category is indicative of a transmission priority used for
transmitting the first type of management frame, the transmission
priority being any transmission priority among a plurality of
transmission priorities.
23. The access point as claimed in claim 22, wherein the
transmission priority is not a highest priority of
transmission.
24. The access point as claimed in claim 22, wherein the MFQ policy
further defines a second access category for a second type of
management frame, the second access category being indicative of
another transmission priority among the plurality of transmission
priorities.
25. The access point as claimed in claim 20, wherein the processor
is further configured to: generate an element that defines the
access category for the first type of management frame; and
transmit the element.
26. A mobile station comprising: a processor configured to:
receive, from an access point, an advertisement of a management
frame quality of service (MFQ) policy, wherein the MFQ policy
defines an access category used for transmitting a first type of
management frame.
27. The mobile station as claimed in claim 26, wherein the access
category includes any access category among a plurality of access
categories.
28. The mobile station as claimed in claim 26, wherein the access
category is indicative of a transmission priority used for
transmitting the first type of management frame, the transmission
priority being any transmission priority among a plurality of
transmission priorities.
29. The mobile station as claimed in claim 28, wherein the
transmission priority is not a highest priority of
transmission.
30. The mobile station as claimed in claim 28, wherein the MFQ
policy further defines a second access category for a second type
of management frame, the second access category being indicative of
another transmission priority among the plurality of transmission
priorities.
31. The mobile station as claimed in claim 26, wherein the
processor is further configured to receive an element that defines
the access category for the first type of management frame.
32. The mobile station as claimed in claim 26, wherein the
processor is further configured to assign the access category to
management frames of the first type according to the MFQ
policy.
33. The mobile station as claimed in claim 32, wherein the
processor is further configured to transmit the management frames
using the access category.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to Canadian patent
application 2,696,037 filed Mar. 15, 2010, entitled "Advertisement
and Dynamic Configuration of WLAN Prioritization States", the
content of which is incorporated by reference in its entirety.
TECHNICAL FIELD
[0002] The technology described herein generally relates to
wireless local area networks (WLANs), and more particularly, to the
handling of network management traffic in a WLAN.
BACKGROUND
[0003] The enhanced Distributed Channel Access (EDCA) of the
Institute of Electrical and Electronics Engineers (IEEE) standard
802.11 is an enhancement to the original IEEE 802.11 Media Access
Control (MAC) sublayer and is a method of medium access described
in the standard amendment document IEEE 802.11e. EDCA provides four
prioritized queues for transmission, where each queue is associated
with a different access category (AC). The four access categories
defined, for example, in IEEE standard 802.11e, in decreasing
priority, are AC_VO, AC_VI, AC_BE and AC_BK, named for voice
traffic, video traffic, best-effort traffic, and background
traffic, respectively. The queues use a contention-based mechanism
to determine the next frame for transmission. The queue parameters
are set such that the high priority queues have a preference for
access to the wireless medium.
[0004] Management frames are the foundation of network management
traffic in a Wireless Local Area Network (WLAN). Current IEEE
802.11 standards dictate that, in any access point (AP) or non-AP
station (STA), management frames are to be handled via the EDCA
queue of highest priority.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] FIG. 1 is an illustration of an example network architecture
for advertisement of management frame QoS (MFQ) information within
a basic service set (BSS);
[0006] FIG. 2 is an illustration of an example method to be
implemented by an access point (AP) for advertisement of MFQ
information;
[0007] FIG. 3 is an illustration of an example method to be
implemented by an AP for including MFQ information in a downlink
frame;
[0008] FIG. 4 is an illustration of an example method to be
implemented by a station (STA) associated with an AP for handling
MFQ information received from the AP in a downlink frame;
[0009] FIG. 5 is an illustration of example formatting information
for a MFQ element;
[0010] FIG. 6 is an illustration of an example method to be
performed by a STA associated with an AP for requesting permission
from the AP to deviate from MFQ information currently advertised by
the AP, receiving a policy configuration response from the AP, and
acting on the received policy configuration response;
[0011] FIG. 7 is an illustration of an example method to be
performed by an AP for receiving a policy configuration request
from an associated STA for permission to deviate from MFQ
information currently advertised by the AP and for responding to
the policy configuration request;
[0012] FIG. 8 is an illustration of example formatting for a policy
configuration request;
[0013] FIG. 9 is an illustration of example formatting for a policy
configuration response;
[0014] FIG. 10 is an illustration of example formatting for a
policy stop message;
[0015] FIG. 11 is a block diagram of an example AP;
[0016] FIG. 12 is a block diagram of an example STA;
[0017] FIG. 13 is a block diagram of a media access control (MAC)
sublayer module of an AP; and
[0018] FIG. 14 is a block diagram of a MAC sublayer module of a
STA.
DETAILED DESCRIPTION
[0019] The disclosure can be better understood with reference to
the following drawings and description. The components in the
figures are not necessarily to scale, emphasis instead being placed
upon illustrating the principles of the disclosed technology.
Moreover, in the figures, like referenced numerals designate
corresponding parts or elements throughout the different views. The
following description is merely exemplary in nature and is in no
way intended to limit the disclosure, its application, or uses. As
used herein, the term "module" refers to an Application Specific
Integrated Circuit (ASIC), an electronic circuit, a processor
(shared, dedicated, or group) and memory that executes one or more
software or firmware programs stored in the memory, a combinational
logical circuit, and/or other suitable components that provide the
described functionality. Herein, the phrase "coupled with" is
defined to mean directly connected to or indirectly connected
through one or more intermediate components. Such intermediate
components may include both hardware and software based
components.
[0020] Recent amendments to the IEEE 802.11 family of standards
have increased the number and type of management frames, resulting
in an increase in network management traffic. If all management
frames continue to be handled as frames of the highest priority,
this may adversely affect overall network performance or the
ability to provide Quality of Service (QoS) to data frames or both.
For example, it would not be desirable for the transmission of
diagnostic reports to reduce the quality of a voice call.
[0021] By way of introduction, the disclosure is related to the
prioritization of management frames and are merely exemplary in
nature. More particularly, the present disclosure describes the
implementation of prioritization scheme(s) that define various
access categories of different management frames, where each of the
access categories is associated with a respective prioritization
used for transmission. An access category may be defined for a
group of management frame subtypes or for an individual management
frame subtype.
[0022] In the present disclosure, access categories AC_BK, AC_BE,
AC_VI and AC_VO named for background traffic, best-effort traffic,
video traffic, and voice traffic, respectively, are used to
illustrate the concepts described herein. However, it is
contemplated that the list of access categories may be different.
If the list of access categories is different, then the number or
definition or both of access-category-dependent queues in a
compatible media access control (MAC) sublayer will also be
different. An access category is a label given to a common set of
enhanced distributed channel access (EDCA) parameters that are
used, for example, by a station to contend for a channel in order
to transmit information with certain priorities. In other words,
each respective access category (e.g., AC_BK, AC_BE, AC_VI and
AC_VO) is associated with (i.e., characterized by or indicative of)
a respective priority used for transmission by a station.
[0023] Each data frame generated by an application in a non-access
point (non-AP) station (STA) already has an indication of its
priority. As used herein, the term "data frame" includes both a
content data frame and a signaling data frame. For example, any one
or any combination of the following values is an example indication
of the priority of a data frame: a user priority assigned to the
data frame; the IP-ToS (Internet Protocol--Type of Service) value
in an IP header of the data frame; and a Differentiated Services
Code Point (DSCP) value in the IP header of the data frame. The
classification of a data frame to an access category by a MAC
sublayer module of a non-AP STA may be based upon the data frame's
indication of priority. For example, data frames having various
user priorities may be classified as follows:
TABLE-US-00001 User Priority Access Category 001 AC_BK 010 AC_BK
000 AC_BE 011 AC_BE 100 AC_VI 101 AC_VI 110 AC_VO 111 AC_VO
[0024] Conventionally, management frames, in contrast to data
frames, do not have an indication of priority, so there is no
inherent classification of a management frame to an access
category. Management frames are generated within the MAC sublayer
module of an AP and/or a STA.
[0025] As proposed in the present disclosure, the prioritization
scheme includes a default management frame QoS (MFQ) policy, which
is a static definition of access categories for management frames.
The default MFQ policy is implementable by a MAC sublayer module of
an AP or non-AP STA. The default MFQ policy is known to all APs and
STAs and is therefore not advertised. An example default MFQ policy
includes the following definitions, where the access category of
management frames not included in the following table is AC_BE:
TABLE-US-00002 Access Management Frame Subtypes Category Beacon
AC_VO (Re)Association Request/Response Probe Request (individually
addressed) Probe Response Announcement Traffic Indication Message
(ATIM) Dissassociation Authentication Deauthentication Spectrum
management-channel switch announcement QoS Block Ack
Public-extended channel switch announcement Public-measurement
pilot Public-TDLS Discovery Response Fast BSS Transition HT SA
Query Protected Dual of Public Action-extended channel switch
announcement Mesh Action-HWMP Mesh Path Selection AC_VI Self
Protected Spectrum Management AC_BE Public Protected Dual of Public
Action WNM Unprotected WNM Mesh Action Multihop Action
Vendor-specific Protected Vendor-specific
[0026] As proposed in the present disclosure, a MFQ policy will
apply to a basic service set (BSS), which comprises an AP and any
non-AP STAs associated with the AP. Therefore, the MFQ policy in
effect in one BSS may differ from the MFQ policy in effect in a
different BSS. In particular, the MFQ policy in effect in a BSS may
differ from the default MFQ policy. The MFQ policies in effect in
different BSSs belonging to the same extended service set (ESS) may
be identical to one another, but this is not necessary. The MFQ
policy in effect in a BSS may change over time. The prioritization
scheme for management frames of the present disclosure is therefore
dynamic in that the prioritization scheme allows for changes over
time in the definition of access categories for management frame
subtypes.
[0027] Furthermore, as proposed herein, the AP of the BSS will
determine the MFQ policy that is currently in effect in the BSS and
transmit management frames according that policy. The AP advertises
MFQ information that describes how the MFQ policy currently in
effect in the BSS differs from the default MFQ policy. Therefore,
the MFQ policy currently in effect in a BSS may be referred to as
the advertised MFQ policy, even though only the differences between
the MFQ policy currently in effect in the BSS and the default MFQ
policy are advertised. An associated STA is therefore informed of
the MFQ policy currently in effect in the BSS through receipt of
the advertised MFQ information.
[0028] In accordance with the present disclosure, an associated STA
may follow the MFQ policy determined by the AP with which the STA
is associated. Alternatively, an associated STA may follow the MFQ
policy determined by the AP with which the STA is associated unless
the STA has successfully negotiated a different MFQ policy with the
AP. Compliance of an associated STA to the advertised MFQ policy or
to the negotiated MFQ policy is not actually checked by the AP with
which the STA is associated, because prioritization of management
frames is handled internally in the STA prior to transmission of
the frames.
[0029] Advertisement of MFQ Policy by AP
[0030] FIG. 1 is an illustration of an example network architecture
for advertisement of MFQ information by an AP of a wireless local
area network (WLAN). The WLAN may be configured using IEEE 802.11
technology, and/or or other wireless communication standards
including other WLAN standards, personal area network (PAN)
standards, wide area network (WAN) standards, or cellular
communication standards or networks for providing wireless network
communications.
[0031] In the network architecture shown in FIG. 1, a WLAN access
point (AP) 10 is coupled to a network 12, possibly through a wired
communication interface, a satellite interface, a Worldwide
Interoperability for Microwave Access (WiMAX.RTM.) communication
interface, or any other suitable communication interface. AP 10
broadcasts beacon frames. Stations 14 are WLAN devices that are
within range (i.e., within communication range) of AP 10 and are
associated with AP 10. AP 10 and stations 14 together form a basic
service set (BSS) 16. A basic service set identifier (BSSID)
identifies BSS 16, and is included in every management frame sent
by AP 10 or STAs 14. The MAC address of AP 10 is often used as the
BSSID. The network to which BSS 16 belongs is identified by its
network name, referred to as a service set identifier (SSID).
Unless hidden, the SSID is included in certain downlink frames,
including, for example, beacon frames and probe response frames
transmitted by AP 10.
[0032] A station (STA) 18 is within range of AP 10 but is not
associated with AP 10. STA 18 is therefore not part of the BSS. STA
18 may detect the existence of AP 10 by undergoing a network
discovery process to identify the available wireless local area
networks within range. In some implementations, the network
discovery process includes the receipt by STA 18 of beacon frames
broadcasted by AP 10. In some implementations, the network
discovery process includes the transmission by STA 18 of a probe
request frame and receipt by STA 18 of a probe response frame from
AP 10 in response to the probe request frame.
[0033] A server 20 is coupled to AP 10 through network 12. In the
present implementation, server 20 is local to AP 10. Alternatively,
server 20 may be remote to AP 10, and the coupling of server 20 to
AP 10 may occur via other networks in addition to network 12. For
example, if server 20 is remote to AP 10, the coupling of server 20
to AP 10 may occur via the Internet.
[0034] As explained in further detail in this disclosure, AP 10
advertises MFQ information that describes how the current MFQ
policy in effect in BSS 16 differs from the default MFQ policy, and
this advertisement may be received and interpreted by associated
STAs, such as STAs 14, and by non-associated STAs, such as STA 18.
Upon receipt of the advertised MFQ policy, a classification of
management frames of the associated STA may be adjusted in
accordance with the advertised MFQ policy. A non-associated STA,
such as STA 18, may use Access Network Query Protocol (ANQP) to
query an AP, such as AP 10, for the advertised MFQ policy. For
example, a non-associated STA that is actively scanning may issue a
probe request or a Generic Advertisement Service (GAS) request on
an AP's channel in order to determine what MFQ policy the AP is
implementing. However, such a non-associated STA may choose not to
follow that MFQ policy. It should be noted that AP 10 transmits
management frames according the current MFQ policy in effect (i.e.,
being implemented) within BSS 16.
[0035] FIG. 2 illustrates an example method to be implemented by an
AP for advertisement of MFQ information. At 22, the AP creates an
advertisement of MFQ information that describes how the current MFQ
policy in effect in the BSS differs from the default MFQ policy. At
24, the AP advertises the advertisement, thus advertising the
current MFQ policy in effect in the BSS (i.e., the current MFQ
policy). For the sake of simplicity and brevity, the present
disclosure discusses one format of the advertisement generated by
the AP though those skilled in the art will appreciate that other
forms of the advertisement are anticipated.
[0036] In the example method illustrated in FIG. 3, the
advertisement is in the form of a MFQ policy element. The MFQ
policy element defines access categories of management frames and,
as mentioned above, is used to advertise and exchange MFQ policy
between a STA and an AP. The AP generates a MFQ policy element at
26. At 28, the AP includes the MFQ policy element in downlink
frames, for example, in beacon frames or in probe response frames
or in both. As part of the process of generating a beacon frame and
as part of the process of generating a probe response frame, the AP
may regenerate the MFQ policy element to reflect the current MFQ
policy in effect in the BSS. The MFQ policy element is not reused
from an earlier beacon frame or probe response frame. Rather, the
MFQ policy element is generated as part of the process of
generating the beacon frame or probe response frame in which the
MFQ policy element is to be included.
[0037] An AP may indicate support for management frame
prioritization by setting an appropriate bit, referred to herein as
MFQActivated, in the Capabilities field of the Extended
Capabilities information element (IE) to a value of 1 or may
indicate lack of support for management frame prioritization by
setting that bit to a value of 0. One of the currently reserved
bits of the Capabilities field of the Extended Capabilities IE (as
defined in IEEE Std 802.11-2007) may be used for this purpose.
Alternatively, presence of the MFQ policy element in the downlink
frame may be an indication to STAs receiving the downlink frame
that MFQ is enabled, and lack of presence of the MFQ policy element
in the downlink frame may be an indication to STAs receiving the
downlink frame that either the AP sending the downlink frame does
not support MFQ, or the AP sending the downlink frame supports MFQ
and there is no change to the current MFQ policy for the AP to
advertise.
[0038] When the AP changes its current MFQ policy in effect in the
BSS, the change is communicated in all the beacon frames
transmitted during the Delivery Traffic Indication Message (DTIM)
interval following the MFQ policy change. The change may be
indicated, for example, by setting a change bit to a value of 1.
The change bit may be part of the MFQ policy element or may be in
another part of the beacon frame. Setting the change bit to 1 in
all beacon frames transmitted during the DTIM interval following
the MFQ policy change will ensure that most, if not all, STAs in
the BSS will be informed of a change in MFQ policy for the BSS. For
example, even if a STA is in an awake state only for beacon frames
that includes DTIMs and is not awake to receive other beacon
frames, that STA will still be informed of the change in MFQ
policy, and therefore be prompted to check the MFQ policy element
in the beacon frame. However, a STA that has set its ReceiveDTIMs
parameter to "No" may not receive a beacon frame that informs of a
change in MFQ policy for the BSS.
[0039] FIG. 4 illustrates an example method to be implemented by a
STA associated with an AP for handling MFQ information received
from the AP in a downlink frame. At 30, the STA receives a downlink
frame that includes a MFQ policy element. At 32, the STA configures
itself to implement the advertised MFQ policy. In other words, the
STA configures itself to implement the default MFQ policy modified
by the content of the MFQ policy element. As such, the STA assigns
an access category to each management frame according to an access
category assignment indicated in the MFQ policy element (i.e., the
advertised MFQ policy).
[0040] FIG. 5 illustrates example formatting information for a MFQ
policy element. In order that the advertisement may be received by
associated STAs and by non-associated STAs, the size of the MFQ
policy element complies with any upper limit on the size of an
element in non-associated mode. In one implementation, an Element
ID field 34 which is 1 octet in length includes a value indicating
that the element is a MFQ policy element. A length field 36 which
is also 1 octet in length stores the length of the MFQ policy
element. The length of the MFQ policy element may vary, because
information for multiple deviations from the default MFQ policy may
be included in the MFQ policy element. A MFQ policy info field 38,
alternatively named "Access Category Assignment Count" field 38, is
1 octet in length and includes a value indicating the number of
deviations which are included in the MFQ policy element. MFQ policy
info field 38 may also include a change bit to indicate whether the
MFQ policy has changed. The "Deviation from default MFQ policy for
management frame subtype #1" field 40, alternatively named
"Management Prioritization Policy for Category #1" field 40,
"Access Category Assignment #1" field 40, or "Access Category
Mapping #1" field 40, stores a first deviation to be included in
the advertised MFQ policy. Optionally, additional deviations may be
provided in fields 42 and 44. Fields 40, 42 and 44 are all of
variable length.
[0041] Any one or any combination of the following factors may be
taken into account when determining a change to a MFQ policy:
detection of changes in network conditions, anticipation of changes
in network conditions, detection of changes in network loading (at
the BSS level or at the ESS level or both), anticipation of changes
in network loading (at the BSS level or at the ESS level or both),
detection of changes in AP loading, anticipation of changes in AP
loading, the presence or lack of a multi-media stream, detection of
changes in a multi-media stream, anticipation of changes in a
multi-media stream, and other operating conditions.
[0042] Negotiated MFQ Policy
[0043] An associated non-AP STA may negotiate with the AP with
which it is associated in order to deviate from the advertised MFQ
policy (i.e., the configured MFQ policy). FIG. 6 illustrates an
example method to be performed by a STA associated with an AP for
requesting permission from the AP to deviate from the advertised
MFQ policy, receiving a response from the AP, and acting on the
received response.
[0044] The method begins at 46 with a STA implementing the MFQ
policy configured in its MAC sublayer module. At 48, the STA
transmits a policy configuration request, also referred to herein
as an "MFQ Policy Config Request", to the AP to request a change in
the MFQ policy used to transmit management frames between the STA
and the AP (i.e., the responding AP). In other words, a MFQ Policy
Config Request is used to negotiate a change or modification to the
MFQ policy between a STA and an AP with which the STA is
associated. The MFQ Policy Config Request transmitted by the STA
includes or indicates a change(s) to the MFQ policy being
implemented. The policy configuration request may be transmitted in
response to a triggering event, for example, a network problem,
application-related diagnostics, or a financial transaction. At 50,
the STA receives a policy configuration response from the AP.
[0045] The policy configuration request (i.e., the MFQ Policy
Config Request) includes a MFQ policy element describing how a
requested MFQ policy differs from the default MFQ policy. In other
words, the MFQ policy element indicates a proposed change with
reference to the default MFQ policy. Any one or any combination of
the following factors may taken into account when determining a
requested MFQ policy: detection of changes in the associated non-AP
STA due to diminishing battery power levels, anticipation of
changes in the associated non-AP STA due to diminishing battery
power levels, detection that a current predicted motion of the
non-AP STA will shortly take the non-AP STA out of radio coverage,
so the requested MFQ policy prioritizes signaling frames over a
poor link.
[0046] If, as shown at 52, a policy configuration response, also
referred to as a "MFQ Policy Config Response", from the AP
indicates that a policy configuration request has been rejected by
the AP (i.e., the proposed change(s) in the MFQ Policy Config
Request has (have) been rejected), the STA that transmitted the
request may continue at 46 to transmit management frames in
accordance with the MFQ policy configured in its MAC sublayer
module.
[0047] In this document, a "negotiated MFQ policy" is a requested
MFQ policy requested in a policy configuration request that has
been accepted by the AP. If, as shown at 54, a policy configuration
response received from the AP indicates that a policy configuration
request has been accepted by the AP (i.e., the proposed change(s)
in the MFQ Policy Config Request has (have) been accepted), the STA
proceeds at 56 to implement the negotiated MFQ policy by
configuring its MAC sublayer module to implement the default MFQ
policy modified by the content of the policy element (i.e., the
proposed changes) in the policy configuration request that has been
accepted. In some implementations, both the STA and the AP may
transmit management frames to each other in accordance with the
changes to the MFQ policy that were indicated in the MFQ Policy
Config Request. The negotiated MFQ policy applies only to the
associated STA that made the policy configuration request and does
not apply to any other STA in the BSS.
[0048] At some point following acceptance of a policy configuration
request, the AP may send a policy stop message to the STA that made
the policy configuration request. Alternatively, the STA that made
the policy configuration request may send a policy stop message to
the AP. As long as no policy stop message has been transmitted by
the AP to the STA or by the STA to the AP, the STA may continue to
implement the negotiated MFQ policy. However, if the STA determines
at 58 that a policy stop message has been received from the AP or
transmitted by the STA, the STA may at 60 configure its MAC
sublayer module according to the MFQ policy currently advertised by
the AP. The AP may have changed its advertised MFQ policy during
the time that the STA was configured according to the negotiated
MFQ policy. After the STA has at 58 received a policy stop message
from the AP or transmitted a policy stop message to the AP, the STA
may wait for an advertisement of the MFQ policy currently in effect
for the BSS in order to configure its MAC sublayer module in
accordance with the current advertised MFQ policy.
[0049] Optionally, a policy configuration response received from
the AP may indicate that the STA should retry its policy
configuration request, as shown at 62. In this case, the policy
configuration response may include a suggested MFQ policy (not
shown) that the AP might accept upon request. At 64, the STA may
transmit another policy configuration request to the AP. This
policy configuration request may be the same policy configuration
request that was transmitted by the STA at 48, or this policy
configuration request may include a MFQ policy element received
from the AP describing a suggested MFQ policy (not shown) suggested
by the AP, or this policy configuration request may include a
different MFQ policy element describing a different MFQ policy than
the previously requested MFQ policy. After transmitting the other
policy configuration request to the AP at 64, the STA receives a
new policy configuration response from the AP at 50.
[0050] As an alternative to use of the policy stop message, a STA
that no longer wishes to follow the negotiated MFQ policy may send
to its associated AP a policy configuration request that includes
an MFQ policy element identical to the MFQ policy element
advertised by the associated AP. It is expected that the AP will
accept a policy configuration request that is requesting the MFQ
policy currently implemented in the BSS.
[0051] As an alternative to use of the policy stop message, an AP
that wants a STA to stop following a negotiated MFQ policy may send
to the STA a policy configuration request that includes an MFQ
policy element identical to the MFQ policy element advertised by
the associated AP. It is expected that the STA will interpret the
policy configuration request as a command from the associated AP to
stop following the negotiated MFQ policy and to begin following the
advertised MFQ policy.
[0052] FIG. 7 illustrates an example method to be performed by an
AP for receiving a policy configuration request from an associated
STA for permission to deviate from a MFQ policy currently
advertised by the AP and for responding to the request.
[0053] The method begins at 66 when the AP receives a policy
configuration request from an associated STA. At 68, the AP
determines the result of the policy configuration request and
includes the result in a policy configuration response to be
transmitted to the STA. For example, the AP may determine to accept
the policy configuration request or to reject the policy
configuration request. Alternatively, the AP may determine that the
STA should retry the policy configuration request. In the case that
the AP determines that the result of the policy configuration
request is retry, the AP may optionally determine at 69 a suggested
MFQ policy to include in its policy configuration response to the
STA. It is contemplated that such a suggested MFQ policy may be
more likely to be accepted by the AP than the requested MFQ policy
in the policy configuration request received from the STA at
66.
[0054] Following the AP's determination of the result of the policy
configuration request at 66 and its optional determination (if the
result is retry) of a suggested MFQ policy to describe in a policy
configuration response at 68, the AP transmits the policy
configuration response to the STA at 70.
[0055] FIG. 8 illustrates example formatting information for a
policy configuration request. A policy configuration request may be
implemented as a particular type of management frame called an
action frame. A Category field 72 which is 1 octet in length is set
to a value for public action. A Public Action field 73 which is 1
octet in length is set to indicate a policy configuration request
frame. A dialog token field 74 which is 1 octet in length is set by
the STA to a value to enable the STA to keep track of its policy
configuration requests. A MFQ policy element 76 field describes the
particular MFQ policy that is being requested.
[0056] FIG. 9 illustrates example formatting information for a
policy configuration response. A policy configuration response may
be implemented as an action frame. Category field 72 is as
described above for a policy configuration request. A Public Action
field 78 which is 1 octet in length is set to indicate a policy
configuration response frame. Dialog token field 74 is as described
above for a policy configuration request and has the same value
that was used to identify the policy configuration request for
which this is a response. A Result Code field 80, alternatively
named "Status Code" field 80, includes an indication that the AP
accepts or rejects the policy configuration request to which the
Dialog Token applies or that the STA should retry a request for a
policy. An optional MFQ policy element field 82, applicable when
the content of the Result Code field 80 comprises an indication
that the STA should retry a request, describes how a suggested MFQ
policy differs from the default MFQ policy. The STA may request the
suggested MFQ policy in place of the originally requested MFQ
policy.
[0057] FIG. 10 illustrates example formatting information for a
policy stop message. A policy stop message may be implemented as an
action frame. Category field 72 is as described above for a policy
configuration request. A Public Action field 84 which is 1 octet in
length is set to indicate a policy stop message. Dialog token field
74 is as described above for a policy configuration request and has
the same value that was used to identify the policy configuration
request for which this is a policy stop message.
[0058] Implementation of MFQ Policy (Default, Advertised or
Negotiated)
[0059] An AP or non-AP STA may configure its MAC sublayer module to
implement an MFQ policy. The MFQ policy being implemented by the
MAC sublayer module may be the default MFQ policy. Alternatively,
the MFQ policy being implemented by the MAC sublayer module may be
the default MFQ modified by an advertised MFQ policy element.
Alternatively, the MFQ policy being implemented by the MAC sublayer
module may be the default MFQ policy modified by a MFQ policy
element in a policy configuration request that has been accepted.
While a management frame is generated within the MAC sublayer
module, the management frame will be assigned to an access category
as defined by the MFQ policy, and subsequently transmitted, using
the respective access category. In the present implementation, the
management frame is directed, based on its assigned access
category, to one of four EDCA prioritized queues where each of the
prioritized queues is associated with a respective access category.
As such, in the present implementation, a management frame assigned
to AC_VO will be transmitted using a prioritization (i.e., a
transmission priority) associated with AC_VO, a management frame
assigned to AC_VI will be transmitted using a prioritization
associated with AC_VI, a management frame assigned to AC_BE will be
transmitted using a prioritization associated with AC_BE, and a
management frame assigned to AC_BK will be transmitted using a
prioritization associated with AC_BK. In other words, each access
category (e.g., AC_VO, AC_VI, AC_BE and AC_BK) is indicative of a
distinct prioritization (i.e., transmission priority) used to
transmit a particular type or subtype of management frame. Handling
of the contents of the prioritized queues may follow IEEE 802.11
scheduling and transmission rules. For example, a frame scheduler
schedules frames from the prioritized queues to be passed to the
physical (PHY) sublayer module for transmission over a channel of a
wireless medium.
[0060] FIG. 11 is a block diagram of an example AP 100. AP 10 is an
example of AP 100. AP 100 comprises a processor 102 coupled to a
memory 104 and to a communication interface 106. Communication
interface 106 may be a wired communication interface, a satellite
interface, a Worldwide Interoperability for Microwave Access
(WiMAX.RTM.) communication interface, or any other suitable
communication interface. AP 100 also comprises a WLAN interface 108
within a protocol stack 110 that is coupled to processor 102. WLAN
interface 108 comprises a logical link control (LLC) sublayer
module 112, a MAC sublayer module 114 and a PHY sublayer module
116. The BSSID of AP 100 is stored in WLAN interface 108, possibly
in a register 118. The SSID of the WLAN supported by AP 100 is
stored in WLAN interface 108, possibly in a register 120. MAC
sublayer module 114 may be compatible with IEEE 802.11. AP 100 also
comprises an antenna 122 coupled to PHY sublayer module 116.
Protocol stack 110 may comprise higher layers 124. ANQP support may
be implemented in MAC sublayer module 114.
[0061] Memory 104 may store an operating system 126 to be executed
by processor 102. Memory 104 may store applications 128 installed
in AP 100 to be executed by processor 102. Examples of applications
128 include a configuration application that enables a WLAN
administrator to configure parameters of the WLAN, for example, its
SSID and BSSID(s). Memory 104 may store code 130 which, when
executed by processor 102, results in one or more of the methods
illustrated in FIGS. 2, 3, and 7.
[0062] A default MFQ policy 132 is not advertised in the BSS.
Depending upon implementation, default MFQ policy 132 may be stored
in WLAN interface 108 (as illustrated) or in memory 104. Depending
upon implementation, an advertised MFQ policy 133 currently
implemented by WLAN MAC sublayer 114 may be stored in WLAN
interface 108 (as illustrated) or in memory 104. AP 100 is able to
advertise how advertised MFQ policy 133 differs from default MFQ
policy 132. AP 100 may optionally store data 134 related to one or
more policy configuration requests that have previously been
received from one or more associated STAs and related to one or
more policy configuration responses that have previously been
transmitted to one or more associated STAs. Data 134 may be
implemented, for example, as records in a table, where the records
are maintained on a per-AID (association identifier) basis.
Depending upon implementation, data 134 may be stored in WLAN
interface 108 (as illustrated) or in memory 104.
[0063] AP 100 may comprise other elements that, for clarity, are
not illustrated in FIG. 11. Similarly, AP 100 may comprise a subset
of the elements illustrated in FIG. 11.
[0064] FIG. 12 is a block diagram of an example STA, for example,
any one of STAs 14. An STA 200 comprises a processor 202 coupled to
a memory 204 and optionally to one or more other wireless
communication interfaces 206. For example, wireless communication
interfaces 206 may comprise a short-range wireless communication
interface such as a wireless personal area network interface,
possibly compatible with the Bluetooth Specification Version 4.0
published 30 Jun. 2010 or its official successors. In another
example, wireless communication interfaces 206 may comprise a
wireless wide area network (WWAN) interface such as for cellular
communications. One or more antennas 208 may be coupled to
respective ones of the wireless communication interfaces 206. An
antenna may be shared among more than one wireless interface.
[0065] STA 200 also comprises a WLAN interface 210 within a
protocol stack 212 that is coupled to processor 202. WLAN interface
210 comprises a LLC sublayer module 214, a MAC sublayer module 216
and a PHY sublayer module 218. MAC sublayer module 216 may be
compatible with IEEE 802.11. STA 200 also comprises an antenna 220
coupled to PHY sublayer module 218. Protocol stack 212 may comprise
higher layers 222.
[0066] Memory 204 may store an operating system 224 to be executed
by processor 202. Memory 204 may store applications 226 installed
in STA 200 to be executed by processor 202. For example,
applications 226 may comprise a control application to act on MFQ
policy elements received from an AP. In a further example,
applications 226 may comprise a Voice over Internet Protocol (VoIP)
application. In yet another example, applications 226 may comprise
a telephony application. Memory 204 may also store data (not shown)
used by operating system 224 and applications 226.
[0067] Memory 204 may store one or more WLAN connection profiles
228, each identifying a wireless local area network by its SSID, as
known in the art.
[0068] Memory 204 may store code 230 which, when executed by
processor 202, results in one or more of the methods illustrated in
FIGS. 4 and 6. Receipt of a downlink frame and handling of MFQ
information describing an advertised MFQ policy may be implemented
in MAC sublayer module 216. ANQP support may be implemented in MAC
sublayer module 216.
[0069] A default MFQ policy 232 is not advertised in the BSS.
Depending upon implementation, default MFQ policy 232 may be stored
in WLAN interface 210 (as illustrated) or in memory 204. Depending
upon implementation, a MFQ policy 233 currently implemented by WLAN
MAC sublayer 216 may be stored in WLAN interface 210 (as
illustrated) or in memory 204. STA 200 may optionally store data
234 related to one or more policy configuration requests made by
the STA and related to one or more policy configuration responses
received by the STA. STA 200 may store an indication of its
requested MFQ policy and then overwrite currently implemented MFQ
policy 233 with the negotiated MFQ policy upon receiving acceptance
of the policy configuration request.
[0070] Memory 204 may store an audio coder-decoder (codec) 238 or a
video codec 240 or both. STA 200 may comprise an audio input
element 242 and an audio output element 244, both coupled to
processor 202. STA 200 may comprise a video input element 246 and a
video output element 248, both coupled to processor 202.
[0071] STA 200 may comprise a Global Positioning System (GPS)
module 250 coupled to processor 202.
[0072] STA 200 may comprise one or more user input elements 252
coupled to processor 202. Examples of user input elements include a
keyboard, a keypad, a touchscreen, a joystick, a thumbwheel, a
roller, a touchpad, a trackpad, a capacitive touch pad, an optical
touch pad, and any other type of navigation actuator.
[0073] STA 200 may comprise one or more user output elements
coupled to processor 202, of which a display 254 is illustrated. In
the event that display 254 is a touchscreen, it functions also as a
user input element.
[0074] STA 200 may comprise one or more alert components 256
coupled to processor 202, to be activated in order to alert a user,
for example, by sounding a buzzer, playing a ringtone, emanating
light, or vibrating.
[0075] STA 200 may include mechanical interfaces, such as a power
connector jack, a data interface port such as a Universal Serial
Bus (USB) port, a headphone jack, and other mechanical interfaces
that are not explicitly shown.
[0076] STA 200 comprises a power pack 258 that provides power to
the other components of STA 200.
[0077] STA 200 may comprise other elements that, for clarity, are
not illustrated in FIG. 12. Similarly, STA 200 may comprise a
subset of the elements illustrated in FIG. 12.
[0078] FIG. 13 is a block diagram of a MAC sublayer module 300 of
an AP, for example, MAC sublayer module 114 of AP 100. MAC sublayer
module 300 uses a management frame generator 302 to generate
management frames which are distributed to different memory queues
by a management frame classification unit 304. Distribution to the
different memory queues is done according to a MFQ policy 306
currently implemented in the BSS to which the AP belongs.
Management frames of the type or types for which MFQ policy 306
defines the access category AC_VO are routed by management frame
classification unit 304 through memory queue 308. Management frames
of the type or types for which MFQ policy 306 defines the access
category AC_VI are routed by management frame classification unit
304 through memory queue 310. Management frames of the type or
types for which MFQ policy 306 defines the access category AC_BE
are routed by management frame classification unit 304 through
memory queue 312. Management frames of the type or types for which
MFQ policy 306 defines the access category AC_BK are routed by
management frame classification unit 304 through memory queue 314.
In some implementations, MFQ policy 306 defines an access category
other than the AC_VO access category associated with the highest
priority queue 308 for at least one management frame type.
[0079] Data frames (content frames and signaling frames) received
at MAC sublayer module 300 from an LLC sublayer module (not shown)
of the AP, for example, LLC sublayer module 112, may be processed
by a packet classification, fragmentation and encapsulation module
316 in MAC sublayer module 300 and then subsequently routed through
the same memory queues as the management frames.
[0080] A scheduler 318 schedules frames from memory queues 308,
310, 312 and 314 to be passed to a PHY sublayer module of the AP,
for example, PHY sublayer module 116. For example, IEEE 802.11e has
separate minimum and maximum values for each access category.
Within each access category, a random number is generated that
represents a wait time as multiplied by a "slot time". In IEEE
802.11a/g, a slot time is 9 microseconds. Once the wireless medium
is quiet or unoccupied, a countdown begins before transmission.
Each count is 9 microseconds in real time. For AC_VO queue 308, the
countdown begins at a value between 31 and 127. For AC_VI queue
310, the countdown begins at a value between 127 and 255. For AC_BE
queue 312, the countdown begins at a value between 255 and 511. For
AC_BK queue 314, the countdown begins at a value between 511 and
1023. If the countdown is interrupted, it is paused until the
wireless medium is once again quiet, and is then resumed from the
value at which it was paused. If the countdowns for different
queues begin at the same time, traffic in a higher priority queue
will gain access to the wireless medium ahead of traffic in a lower
priority queue.
[0081] MAC sublayer module 300 further comprises a MFQ policy
element generator 320 which generates a MFQ policy element based on
MFQ policy 306. As described previously, a MFQ policy element may
be included in certain management frames generated by management
frame generator 302 to advertise an advertised MFQ policy. For
example, a MFQ policy element generated by MFQ policy element
generator 320 may be included in a downlink frame such as a beacon
frame or a probe response frame that is generated by management
frame generator 302. It should be noted that, while not explicitly
shown, MAC sublayer module 300 may also implement ANQP support.
[0082] FIG. 14 is a block diagram of a MAC sublayer module 400 of a
STA, for example, MAC sublayer module 216 of STA 200. MAC sublayer
module 400 uses a management frame generator 402 to generate
management frames which are distributed to different memory queues
by a management frame mapping unit 404. Distribution to the
different memory queues is done according to a MFQ policy 406.
Management frames of the type or types for which MFQ policy 406
defines the access category AC_VO are routed by management frame
classification unit 404 through memory queue 408. Management frames
of the type or types for which MFQ policy 406 defines the access
category AC_VI are routed by management frame classification unit
404 through memory queue 410. Management frames of the type or
types for which MFQ policy 406 defines the access category AC_BE
are routed by management frame classification unit 404 through
memory queue 412. Management frames of the type or types for which
MFQ policy 406 defines the access category AC_BK are routed by
management frame classification unit 404 through memory queue 414.
In some implementations, MFQ policy 406 defines an access category
other than the AC_VO access category associated with the highest
priority queue 408 for at least one management frame type.
[0083] It is contemplated that MFQ policy 406 is an advertised MFQ
policy. It is also contemplated that MFQ policy 406 is a negotiated
MFQ policy accepted by an AP with which the STA is associated. It
is also contemplated that MFQ policy 406 is the default MFQ
policy.
[0084] Data frames (content frames and signaling frames) received
at MAC sublayer module 400 from an LLC sublayer module (not shown)
of the STA, for example, LLC sublayer module 214, may be processed
by a packet classification, fragmentation and encapsulation module
416 in MAC sublayer module 400 and then subsequently routed through
the same memory queues as the management frames.
[0085] A scheduler 418 schedules frames from memory queues 408,
410, 412 and 414 to be passed to a PHY sublayer module of the STA,
for example, PHY sublayer module 218. For example, IEEE 802.11e has
separate minimum and maximum values for each access category.
Within each access category, a random number is generated that
represents a wait time as multiplied by a "slot time". In IEEE
802.11a/g, a slot time is 9 microseconds. Once the wireless medium
is quiet or unoccupied, a countdown begins before transmission.
Each count is 9 microseconds in real time. For AC_VO queue 408, the
countdown begins at a value between 31 and 127. For AC_VI queue
410, the countdown begins at a value between 127 and 255. For AC_BE
queue 412, the countdown begins at a value between 255 and 511. For
AC_BK queue 414, the countdown begins at a value between 511 and
1023. If the countdown is interrupted, it is paused until the
wireless medium is once again quiet, and is then resumed from the
value at which it was paused. If the countdowns for different
queues begin at the same time, traffic in a higher priority queue
will gain access to the wireless medium ahead of traffic in a lower
priority queue.
[0086] MAC sublayer module 400 further comprises a MFQ policy
element generator 420 which generates a MFQ policy element based on
a requested MFQ policy. As described previously, the MFQ policy
element may be included in a policy configuration request generated
by management frame generator 402 to negotiate a deviation from an
advertised MFQ policy. It should be noted that, while not
explicitly shown, MAC sublayer module 400 may also implement ANQP
support.
[0087] Although the subject matter has been described in language
specific to structural features and/or methodological acts, it is
to be understood that the subject matter defined in the appended
claims is not necessarily limited to the specific features or acts
described above. Rather, the specific features and acts described
above are disclosed as example forms of implementing the
claims.
* * * * *