Quality of service provisioning for wireless networks

Abstract

A technique for improving quality of service involves dynamically provisioning quality of service parameters. An example according to this technique is a system including a server and an access point. The server provisions quality of service parameters restricting the station's transmission of data through the access point to one or more access classes of varying priority.

Description

BACKGROUND

Wireless networks are frequently governed by 802.11 standards. While not all networks need to use all of the standards associated with 802.11, a discussion of the standards by name, such as 802.11e provides, at least partly because the standards are well-known and documented, a useful context in which to describe issues as they relate to wireless systems.

There is only one 802.11 standard, however under the revisions introduced by 802.11e current implementations of QoS specifications typically perform one or more of the following. Mapping to a Wi-Fi Multimedia (WMM) access class by mapping an entire service set identifier (SSID), writing a cumbersome access control list (ACL), or automatically mapping DiffServ Code Point bits. Nothing within 802.11e or WMM addresses dynamic assignment of QoS to frames. Thus, QoS parameters are provisioned in a static manner.

The foregoing examples of the related art and limitations related therewith are intended to be illustrative and not exclusive. For Example, wireless clients may use different protocols other than 802.11e, potentially including protocols that have not yet been developed. However, problems associated with QoS may persist. Other limitations of the relevant art will become apparent to those of skill in the art upon a reading of the specification and a study of the drawings.

SUMMARY

The following embodiments and aspects thereof are described and illustrated in conjunction with systems, tools, and methods that are meant to be exemplary and illustrative, not limiting in scope. In various embodiments, one or more of the above-described problems have been reduced or eliminated, while other embodiments are directed to other improvements.

A technique for QoS provisioning includes provisioning QoS parameters dynamically. The dynamic provisioning may be part of authentication of a system to a wireless network. The technique may or may not be compatible with 802.11e and WMM concepts, and provide ways to dynamically configure QoS features on a per-client basis.

In a non-limiting example, consider a phone, and a laptop. Each may request use of a wireless network that operates in accordance with QoS. The phone may operate a soft phone application and transmit voice data over a network, whereas, for this example only, that the laptop does not. The phone and the laptop may each request a high priority access class in order to transmit data. Each of the phone and the laptop may or may not be validated as a part of authentication. In validating, the soft phone may or may not be identified as an application that requires a high priority access class. In contrast, the laptop, which may have requested a high priority access class even though it may not be running a high priority application, may be denied the use of the high priority access class. QoS parameters may be dynamically created and provisioned. The dynamic assignment of the high priority access class may allow the phone to transmit data at high priority whereas the laptop may not.

These and other advantages will become apparent to those skilled in the relevant art upon a reading of the following descriptions and a study of the several examples of the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated in the figures. However, the embodiments and figures are illustrative rather than limiting; they provide examples of the inventions.

FIG. 1 depicts a diagram 100 of an example of a system including a wireless access domain.

FIGS. 2A and 2B depict diagrams of examples of a system 200 including a verification engine.

FIG. 3 depicts a flowchart 300 of an example of a method for dynamically provisioning QoS parameters.

FIG. 4 depicts a flowchart 400 of an example of a method for dynamically provisioning QoS parameters including verifying that an application that requires priority is executing on a station.

FIG. 5 depicts a flowchart 500 of an example of a method for dynamically provisioning QoS parameters.

FIG. 6 depicts a flowchart 600 of an example of a method for dynamically provisioning QoS parameters including checking a database, setting a utilization rate, and/or setting a RADIUS attribute.

FIG. 7 depicts a diagram 700 of a computer system for use in the system of FIG. 1.

FIG. 8 depicts an example of a system 800 for dynamically provisioning QoS parameters to stations.

DETAILED DESCRIPTION

In the following description, several specific details are presented to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or in combination with other components, etc. In other instances, well-known implementations or operations are not shown or described in detail to avoid obscuring aspects of various embodiments.

FIG. 1 depicts a system 100 including a wireless access domain. The system 100 includes a server 102, a network 104, and a wireless access domain 106. The system 100 may or may not include multiple wireless access domains. The server 102 may be practically any type of device that is capable of communicating with a communications network, such as, by way of example but not limitation, a mainframe or a workstation. The network 104 may be practically any type of communications network, such as, by way of example but not limitation, the Internet or an infrastructure network. The term “Internet” as used herein refers to a network of networks which uses certain protocols, such as the TCP/IP protocol, and possibly other protocols such as the hypertext transfer protocol (HTTP) for hypertext markup language (HTML) documents that make up the World Wide Web (the web). The physical connections of the Internet and the protocols and communication procedures of the Internet are well known to those of skill in the art.

In a non-limiting embodiment, the server 102 may be running a program such as, by way of example but not limitation, ethereal, to decode, by way of example but not limitation, IEEE 802.11 standard packets encapsulated in TaZman Sniffer Protocol (TZSP) that are received from the wireless access domain 106. In a non-limiting embodiment, the server 102 is connected to a wireless backbone network (not shown), either directly or indirectly through a wireless network. The server 102 may include, by way of example but not limitation, a Remote Authentication Dial In User Services (RADIUS) server, an Lightweight Directory Access Protocol (LDAP) server, a policy server, a combination of these servers, or some other server.

In non-limiting embodiments, the wireless access domain 106 may be referred to as, by way of example but not limitation, a Local Area Network (LAN), virtual LAN (VLAN), and/or wireless LAN (WLAN). In an embodiment, the wireless access domain 106 may include one or more radios.

In the example of FIG. 1, the wireless access domain 106 includes access areas 108-1 to 108-N (hereinafter collectively referred to as access areas 108). The access areas 108 have characteristics that depend upon, among other things, a radio profile. A radio profile is a group of parameters such as, by way of example but not limitation, beacon interval, fragmentation threshold, and security policies. In an embodiment, the parameters may be configurable in common across a set of radios in one or more access areas 108. In another embodiment, a few parameters, such as the radio name and channel number, must be set separately for each radio. An example of the implementation of a wireless access domain, provided by way of example but not limitation, includes a Trapeze Networks “identity-aware” Mobility Domain™.

In the example of FIG. 1, the following elements are associated with each of the access areas 108: Wireless exchange switches 110-1 to 110-N (hereinafter collectively referred to as wireless exchange switches 110), networks 112-1 to 112-N (hereinafter collectively referred to as networks 112), and access points 114-1 to 114-N (hereinafter collectively referred to as access points 114).

In an embodiment, the wireless exchange switches 110 swap topology data and client information that details each user's identity, location, authentication state, VLAN membership, permissions, roaming history, bandwidth consumption, and/or other attributes assigned by, by way of example but not limitation, an Authentication, Authorization, and Accounting (AAA) backend (not shown). In an embodiment, the wireless exchange switches 110 provide forwarding, queuing, tunneling, and/or some security services for the information the wireless exchange switches 110 receive from their associated access points 114. In another embodiment, the wireless exchange switches 110 coordinate, provide power to, and/or manage the configuration of the associated access points 114. An implementation of a wireless exchange switch, provided by way of example but not limitation, includes a Trapeze Networks Mobility Exchange® switch. The Trapeze Networks Mobility Exchange® switches may, in another implementation, be coordinated by means of the Trapeze Access Point Access (TAPA) protocol.

In an embodiment, the networks 112 are simply wired connections from the wireless exchange switches 110 to the access points 114. The networks 112 may or may not be part of a larger network. In a non-limiting embodiment, the networks 112 provide a Layer 2 path for Layer 3 traffic, preserving IP addresses, sessions, and other wired Layer 3 attributes as users roam throughout the wireless access domain 106. By tunneling Layer 3 traffic at Layer 2, users stay connected with the same IP address and keep the same security and Quality of Service (QoS) policies from the wired network while they roam the wireless side.

In a non-limiting embodiment, the access points 114 are hardware units that act as a communication hub by linking wireless mobile stations such as PCs to a wired backbone network. In an embodiment, the access points 114 connect users to other users within the network and, in another embodiment, can serve as the point of interconnection between a WLAN and a fixed wire network. The number of users and size of a network help to determine how many access points are desirable for a given implementation. An implementation of an access point, provided by way of example but not limitation, includes a Trapeze Networks Mobility System® Mobility Point® (MP®) access point.

The access points 114 are stations that transmit and receive data (and may therefore be referred to as transceivers) using one or more radio transmitters. For example, an access point may have two associated radios, one which is configured for IEEE 802.11a standard transmissions, and the other which is configured for IEEE 802.11b standard transmissions. In a non-limiting embodiment, an access point transmits and receives information as radio frequency (RF) signals to and from a wireless client over a 10/100BASE-T Ethernet connection. The access points 114 transmit and receive information to and from their associated wireless exchange switches 110. Connection to a second wireless exchange switch provides redundancy.

A station, as used herein, may be referred to as a device with a media access control (MAC) address and a physical layer (PHY) interface to the wireless medium that comply with the IEEE 802.11 standard. As such, in a non-limiting embodiment, the access points 114 are stations. Similarly, a wireless client, such as the mobile device 116 of FIG. 1, may be implemented as a station. In alternative embodiments, a station may comply with a different standard than IEEE 802.11, and may have different interfaces to a wireless or other medium.

In the example of FIG. 1, the server 102 includes memory 120 and a processor 122. In the example of FIG. 1, the memory 120 includes an operating system, a QoS parameters database, and a QoS setup module. In operation, a policy configuration for the mobile device 116 includes setting or accepting QoS parameters for the mobile device 116 (or a user of the mobile device 116). The QoS setup module may provide the mobile device 116 with the policy configuration during association. In the example of FIG. 1, this QoS provisioning is illustrated by the arrow 130 from the QoS setup module to the mobile device 116.

In the example of FIG. 1, queues 118 are depicted for illustrative purposes (depending upon the implementation, the queues 118 may be considered a part of the access point 114-1). As is shown in the example of FIG. 1, the QoS provisioning 130 provides the mobile device 116 with access to background, best effort, and video queues, but no access to the high-priority voice queue. It should be noted that the policy could be configured to grant access to the high-priority voice queue if the mobile device 116 were running a VoIP application. However, for illustrative purposes, it is assumed that when the mobile device 116 was not running a VoIP application when it associated. Therefore, in the example of FIG. 1, access to the voice queue on the access point 114-1 is blocked.

If the user were allowed access to the voice queue (not shown) there could be an associated limit to voice traffic as well. For instance, a limit of 100 kbps on voice traffic could be employed to limit users to one active telephone call.

FIG. 2A and FIG. 2B depict diagrams of examples of a system including a verification engine. In the example of FIG. 2A, the system 200A includes sever 202 and station 216. The station 216 includes the application 226. The server 202 includes memory 220 and processor 222. The memory includes verification engine 224A, application 226. In the example of FIG. 2B, the system 200B includes server 202, station 216, and verification engine 224B. Notably, in this example, the verification engine 224B is not stored in the memory 220 of the server. Unless a distinction is needed, the verification engine 224A and 224B are referred to as verification engine 224.

In some embodiments, verification engine 224 determines whether or not a specific software application is executing on the station and instructs server 202 to deny the station use of a high priority data transmission queue if the software application is not executing on the station. Users naturally want the best service possible and will be tempted to try and move their best effort traffic into the voice and video queues. Using specifications like the Trusted Computing Group's Trusted Network Connect (TNC), a system can be “validated” before it is allowed to use the network. That validation may include verifying that a program requiring high priority access is running before allowing access to high-priority queues.

In a non-limiting example, a verification engine may allow access to the voice queue only if a softphone is running on the client computer. It is not necessary that the application be a phone. However, a softphone is an example of an application that requires high priority access to the network for transmission of data because a phone provides low quality service when it is unable to transmit data for even a short period of time. Contrarily, many applications may provide high quality service while only utilizing the best efforts access class. By dynamically provisioning QoS parameters, a station may be authenticated and provided high priority access. The station can then provide high quality service at the expense of a second station that is dynamically provision with only a lower priority access class, wherein the second station needs only the lower priority access class to provide high quality service. The station may then transmit data while the second station is required to wait.

In continuing the non-limiting example, a phone is an example of a station requiring high priority access and a laptop is an example of a station that may require only low priority access. Each may each request a high priority access class in order to transmit data, however, the laptop should be denied the high priority access because it cannot prove it needs a high priority access class. Each of the phone and the laptop may or may not be validated as a part of authentication. In validating, the soft phone may be identified as an application that requires a high priority access class because it runs an application that depends on high priority transmission of data, e.g. a soft phone. In contrast, the laptop, which may have requested a high priority access class even though it may not be running a high priority application, may be denied the use of the high priority access class. QoS parameters may be dynamically created and provisioned. The dynamic assignment of the high priority access class may allow the phone to transmit data at high priority whereas the laptop may not.

In some embodiments verification engine 224 may be a component of server 202 (FIG. 2A), or in some embodiments verification engine 224 may be a separate component coupled to server 202. It is not necessary that verification engine 224 be operating on the same hardware software, physical or logical unit as server. Those skilled in the art know that the components portrayed in this figure can be arbitrarily combined or divided into separate software, firmware and/or hardware components. Furthermore, such components, regardless of how they are combined or divided, can execute on the same computing device or multiple computing devices, and wherein the multiple computing devices can be connected by one or more networks.

FIG. 3 depicts a flowchart 300 of an example of a method for dynamically provisioning QoS parameters. The method is organized as a sequence of modules in the flowchart 300. However, it should be understood that these and other modules associated with other methods described herein may be reordered for parallel execution or into different sequences of modules.

In the example of FIG. 3 flowchart 300 starts at module 302 with receiving at an access point (AP) a request for authentication. The request may come from a station desiring to transmit data through the access point in accordance with an access class.

In some embodiments a capacity management and prioritization system may include a network system that takes into account the capacity of a particular access device as part of authentication. For example, a station that has requested QoS resources to which it is administratively allowed but are not available at the target access point might be redirected to a device at which those resources are available. Stations that are allowed on the network for best-effort service may initially be allowed on the network, but moved to a different access point when additional QoS is requested by, for example, a softphone.

In the example of FIG. 3, the flowchart continues to module 304 with assigning, in response to the request, one or more access classes for transmission of data. The access classes may or may not be one or more of a number of access classes defined in accordance with the Institute of Electrical and Electronics Engineers (IEEE) standard 802.11. In a non-limiting example, the classes specify voice, video, best effort, and background in order from highest to lowest priority. Each class is associated with a priority queue. The highest priority is assigned to voice data as it suffers in quality when access to the queue is unavailable. The lowest priority is assigned to background level data which does not tend to suffer when encountering traffic and being required to wait. Additionally, a queue can be reserved for sending signals controlling the network, wherein data in the queue supersedes all other data in priority.

In the example of FIG. 3, the flowchart continues to module 306 with provisioning QoS parameters associated with the one or more access classes. As discussed in reference to FIG. 1, the server provisions these parameters. One way of provisioning parameters is through a station switching record. In this way, the QoS parameters, including any limits set by the dynamic configuration, can be passed around the network in the station switching record.

In some embodiments QoS parameters can be stored in a Lightweight Directory Access Protocol (LDAP) directory associated with the security credentials for a telephone. In such an implementation, the network could, for example, perform an LDAP query against the telephone's account and make that part of the session record.

FIG. 4 depicts a flowchart 400 of an example of a method for dynamically provisioning QoS parameters including verifying that a specific application is executing on a station. The method is organized as a sequence of modules in the flowchart 400. However, it should be understood that these and other modules associated with other methods described herein may be reordered for parallel execution or into different sequences of modules.

In the example of FIG. 4 flowchart 400 starts at module 402 with receiving a at an access point (AP) a request for authentication. The request may come from a station desiring to transmit data through the access point in accordance with an access class. It may be that the request asserts the right to use a particular access class to achieve high priority transmission of data. In a non-limiting example, a request may assert the right to use the voice queue because the station operates a softphone. However, users naturally want the best service possible and will be tempted to try and move their best effort traffic into the voice and video queues even when they are not transmitting voice and video. Using specifications like the Trusted Computing Group's Trusted Network Connect (TNC), a system can be “validated” before it is allowed to use the network. That validation may include verifying that an appropriate program is running before allowing access to high-priority queues. In a non-limiting example, a verification engine may allow access to the voice queue only if a softphone is running on the client computer.

In the example of FIG. 4, the flowchart 400 continues to decision module 403 with determining whether a specific application is (or specific applications are) executing. In some embodiments, a verification engine can determine whether or not a specific software application is executing on the station. In a non-limiting example, the verification engine determines whether a softphone is executing on the station and instructs a server to deny the station use of a high priority data transmission queue if the software application is not executing on the station.

In the example of FIG. 4, if the result of decision module 403 is yes, then the flowchart continues to module 406 with assigning an access class (or access classes) for transmission of data. A program running on a station may be associated with a particular level of priority. In this case, a program was presumably running on the station that is one a group of specific programs that enable access to high priority queues. Accordingly, the station is approved to use the high priority queue to transmit data.

In the example of FIG. 4, the flowchart 400 continues to module 408 with provisioning QoS parameters associated with the access class (or access classes) to the AP. In a non-limiting example, the QoS parameters are passed around the network in a station switching record. The QoS parameters having been provisioned, the flowchart 400 ends.

In the example of FIG. 4, from decision module 403, if the result of decision module 403 is no, then the flowchart continues to module 410 with assigning, in response to the request, an access class for transmission of data. In this case the station is found to be falsely asserting a request to use the high priority queue. An appropriate response is then denial of the request.

In the example of FIG. 4, the flowchart 400 continues to module 406 with assign access class for transmission of data. Although the request has been denied, it is not necessary to exclude the station from use of the network. The station could be assigned a lower priority class, in a non-limiting example the station is assigned to the best effort access class. This allows it to transmit data, but without the high priority it has requested. The flowchart 400 then continues to module 408, as described previously.

FIG. 5 depicts a flowchart 500 of an example of a method for dynamically provisioning QoS parameters. The method is organized as a sequence of modules in the flowchart 500. However, it should be understood that these and other modules associated with other methods described herein may be reordered for parallel execution or into different sequences of modules.

In the example of FIG. 5 flowchart 500 starts at module 502 with receiving a at an access point (AP) a request for authentication. The request may come from a station desiring to transmit data through the access point in accordance with an access class.

In the example of FIG. 5, the flowchart 500 continues to module 504 with assigning the station to one or more access classes for transmission of data. In the case that the station asserts the right to use a high priority class, it may be that the station is validated using a verification engine to make certain that a required program is executing on the station before allowing the station to use the high priority queue. In some embodiments, the access classes are defined by a network administrator and the one or more access classes are assigned in accordance therewith.

In the example of FIG. 5, the flowchart 500 continues to module 506 with setting QoS parameters in accordance with the one or more access classes. QoS parameters can be stored in a Lightweight Directory Access Protocol (LDAP) directory associated with the security credentials for a telephone. In such an implementation, the network could, for example, perform an LDAP query against the telephone's account and make that part of the session record.

In the example of FIG. 5, the flowchart 500 continues to module 508 with provisioning the QoS parameters to an access point. Provisioning could be accomplished by passing the parameters around the networking in a station switching record. Alternatively, they could be directly transmitted to the station by a server.

In the example of FIG. 5, the flowchart 500 continues to module 510 with controlling transmission of data in the one or more access classes in accordance with the QoS parameters. A capacity management and prioritization system may include a network system that takes into account the capacity of a particular access device as part of authentication. For example, a station that has requested QoS resources to which it is administratively allowed but are not available at the target access point might be redirected to a device at which those resources are available. Stations that are allowed on the network for best-effort service may initially be allowed on the network, but moved to a different access point when additional QoS is requested by, for example, a softphone.

FIG. 6 depicts a flowchart 600 of an example of a method for dynamically provisioning QoS parameters including checking a database, setting a utilization rate, and/or setting a RADIUS attribute. The method is organized as a sequence of modules in the flowchart 400. However, it should be understood that these and other modules associated with other methods described herein may be reordered for parallel execution or into different sequences of modules.

In the example of FIG. 6 flowchart 600 starts at module 602 with receiving a at an access point (AP) a request for authentication. The request may come from a station desiring to transmit data through the access point in accordance with an access class.

In the example of FIG. 6, the flowchart 600 continues to module 604 with assigning the station to an access class for transmission of data. The station may receive the class it requested, or it may be assigned to a lower class as needed.

In the example of FIG. 6, the flowchart 600 continues to module 606 with optionally check database for additional information about a user associated with the request for authentication. The QoS configuration stored in the database could restrict access to particular access classes. It might say that a particular device is only allowed to do voice (if it is a telephone), or that it is only allowed best effort data (for a general-purpose device such as a laptop).

In some embodiments, backend databases can be used to manage access to the high-priority queues. By way of example but not limitation, a backend database may include information about the relative importance of each user in access to a voice queue. By labeling priorities, the system may ensure that, for example, the CEO's telephone is always able to gain access to the voice queue at the expense of lower-ranking users.

In the example of FIG. 6, the flowchart 600 continues to module 608 with optionally set a utilization rate limiting the amount of station traffic through one or more priority queues. Each access class can optionally have a utilization rate associated with it. When a device associates with a particular access class using Traffic SPECification (TSPEC), the request can be denied if it asks for more than a utilization rate. For example, a network administrator may impose a limit of 100 kbps of traffic to the voice queue per device; if a station requests more than the limit, the network may respond with a denial and grant the maximum allowable rate. In a non-limiting example, network administrators could use this type of feature to require clients to use lower-bandwidth codecs for Voice over Internet Protocol (VoIP).

In the example of FIG. 6, the flowchart 600 continues to module 610 with optionally set a RADIUS attribute restricting the station to one or more access classes. Dynamic Quality of Service (QoS) parameters may be configured through the use of a Remote Access Dial In User Service (RADIUS) attribute. However, QoS parameters might be further enhanced to, for instance, allow or disallow use of a particular 802.11e access class. For example, a device may be permitted to send video, but not be permitted to send voice.

In the example of FIG. 6, the flowchart 600 continues to module 612 with provisioning the QoS parameters to an access point e.g. transmit a station switching record. In some embodiments, a station switching record containing QoS parameters is passed around a network.

In the example of FIG. 6, the flowchart 600 continues to module 614 with controlling transmission of data in the access class in accordance with the QoS parameters. A capacity management and prioritization system may include a network system that takes into account the capacity of a particular access device as part of authentication. For example, a station that has requested QoS resources to which it is administratively allowed but are not available at the target access point might be redirected to a device at which those resources are available. Stations that are allowed on the network for best-effort service may initially be allowed on the network, but moved to a different access point when additional QoS is requested by, for example, a softphone.

FIG. 7 depicts a computer system 700 for use in the system 100 (FIG. 1). The computer system 700 may be a conventional computer system that can be used as a client computer system, such as a wireless client or a workstation, or a server computer system. The computer system 700 includes a computer 702, I/O devices 704, and a display device 706. The computer 702 includes a processor 708, a communications interface 710, memory 712, display controller 714, non-volatile storage 716, and I/O controller 718. The computer 702 may be coupled to or include the I/O devices 704 and display device 706.

The computer 702 interfaces to external systems through the communications interface 710, which may include a modem or network interface. It will be appreciated that the communications interface 710 can be considered to be part of the computer system 700 or a part of the computer 702. The communications interface 710 can be an analog modem, ISDN modem, cable modem, token ring interface, satellite transmission interface (e.g. “direct PC”), or other interfaces for coupling a computer system to other computer systems.

The processor 708 may be, for example, a conventional microprocessor such as an Intel Pentium microprocessor or Motorola power PC microprocessor. The memory 712 is coupled to the processor 708 by a bus 770. The memory 712 can be Dynamic Random Access Memory (DRAM) and can also include Static RAM (SRAM). The bus 770 couples the processor 708 to the memory 712, also to the non-volatile storage 716, to the display controller 714, and to the I/O controller 718.

The I/O devices 704 can include a keyboard, disk drives, printers, a scanner, and other input and output devices, including a mouse or other pointing device. The display controller 714 may control in the conventional manner a display on the display device 706, which can be, for example, a cathode ray tube (CRT) or liquid crystal display (LCD). The display controller 714 and the I/O controller 718 can be implemented with conventional well known technology.

The non-volatile storage 716 is often a magnetic hard disk, an optical disk, or another form of storage for large amounts of data. Some of this data is often written, by a direct memory access process, into memory 712 during execution of software in the computer 702. One of skill in the art will immediately recognize that the terms “machine-readable medium” or “computer-readable medium” includes any type of storage device that is accessible by the processor 708 and also encompasses a carrier wave that encodes a data signal.

The computer system 700 is one example of many possible computer systems which have different architectures. For example, personal computers based on an Intel microprocessor often have multiple buses, one of which can be an I/O bus for the peripherals and one that directly connects the processor 708 and the memory 712 (often referred to as a memory bus). The buses are connected together through bridge components that perform any necessary translation due to differing bus protocols.

Network computers are another type of computer system that can be used in conjunction with the teachings provided herein. Network computers do not usually include a hard disk or other mass storage, and the executable programs are loaded from a network connection into the memory 712 for execution by the processor 708. A Web TV system, which is known in the art, is also considered to be a computer system, but it may lack some of the features shown in FIG. 7, such as certain input or output devices. A typical computer system will usually include at least a processor, memory, and a bus coupling the memory to the processor.

In addition, the computer system 700 is controlled by operating system software which includes a file management system, such as a disk operating system, which is part of the operating system software. One example of operating system software with its associated file management system software is the family of operating systems known as Windows® from Microsoft Corporation of Redmond, Wash., and their associated file management systems. Another example of operating system software with its associated file management system software is the Linux operating system and its associated file management system. The file management system is typically stored in the non-volatile storage 716 and causes the processor 708 to execute the various acts required by the operating system to input and output data and to store data in memory, including storing files on the non-volatile storage 716.

Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The present invention, in some embodiments, also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.

The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language, and various embodiments may thus be implemented using a variety of programming languages.

FIG. 8 depicts an example of a system 800 for dynamically provisioning QoS parameters to stations. The system 800 includes a server 802, a network 804, a wireless access domain 806, parameter provisioning indicator 830, parameter provisioning indicator 832, phone 840, and laptop 842. The system 800 may or may not include multiple wireless access domains. Server 802 includes memory 820 and processor 822.

In the example of system 800, phone 840 and a laptop 842 each receive dynamically provisioned QoS parameters. Phone 840 is an example of a station requiring high priority access. Phone 840 executes a soft phone application. Laptop 842 is an example of a station that may require only relatively low priority access. It is noted that a laptop could operate a soft phone, however, for this non-limiting example, laptop 842 does not execute a soft phone, and operates only software requiring continuous transmission of large blocks of data having relatively time-insensitive requirements, e.g. gigantic blocks of meteorological data on weather patterns continuously recorded for long term analysis. Further, in this case, laptop 842 has been instructed to transmit data in the highest priority available in accordance with the design of the software by its creators.

In a case where there is no dynamic QoS provisioning, laptop 842 might interfere with phone 840's quality of transmission because laptop 842 would continuously transmit data in competition with phone 840 demanding highest priority. However, QoS parameters dynamically created in accordance with the granting of high or low priority access classes are provisioned in accordance with parameter provisioning indicator 830 and parameter provisioning indicator 832. Laptop 842 is provisioned, via provisioning indicator 832, QoS parameters that deny the laptop access to either the voice or video queues. Laptop 842 is denied the high priority access because it cannot prove it needs a high priority access class.

Because laptop 842 does not compete for the use of the voice or video queues, the dynamic assignment of high priority access classes allows phone 840 to transmit voice and/or video data in priority above laptop 842. Advantageously, to phone 840, there is no other traffic in the voice or video queues, and phone 840 performs in high quality in accordance with requirements for voice and video transmission. Laptop 842 does not suffer a loss of quality as applications that it executes continue to use best efforts and background queues in accordance with requirements set to maintain their quality.

As used herein, a wireless network refers to any type of wireless network, including but not limited to a structured network or an ad hoc network. Data on a wireless network is often encrypted. However, data may also be sent in the clear, if desired. With encrypted data, a rogue device will have a very difficult time learning any information (such as passwords, etc.) from clients before countermeasures are taken to deal with the rogue. The rogue may be able to confuse the client, and perhaps obtain some encrypted data, but the risk is minimal (even less than for some wired networks).

As used herein, the term “embodiment” means an embodiment that serves to illustrate by way of example but not limitation.

It will be appreciated to those skilled in the art that the preceding examples and embodiments are exemplary and not limiting to the scope of the present invention. It is intended that all permutations, enhancements, equivalents, and improvements thereto that are apparent to those skilled in the art upon a reading of the specification and a study of the drawings are included within the true spirit and scope of the present invention. It is therefore intended that the following appended claims include all such modifications, permutations and equivalents as fall within the true spirit and scope of the present invention.

Claims

1. A system, comprising: a server configured to be coupled to a network and an access point transmitting data from a first station to the server and from a second station to the server;the server configured to dynamically determine quality of service (QoS) parameters for the first station and for the second station; andthe server configured to (1) restrict the first station from a first access class from a plurality of access classes based on the QoS parameters, (2) assign the first station a second access class from the plurality of access classes based on the QoS parameters, and (3) assign the second station the first access class and the second access class based on the QoS parameters, the first access class being uniquely associated with a first priority queue from a plurality of priority queues at the access point, the second access class being different from the first access class and being uniquely associated with a second priority queue, from the plurality of priority queues, different from the first priority queue.

2. The system of claim 1, further comprising: the server configured to be coupled to a verification engine determining whether a software application is executing on the first station; andthe server configured to receive an instruction from the verification engine to deny the first station use of first priority queue from the plurality of priority queues if the software application is not executing on the station.

3. The system of claim 1, wherein the QoS parameters include a RADIUS attribute defining permission for the first station to use the second access class.

4. The system of claim 1, wherein the first access class is an 802.11 access class.

5. The system of claim 1, wherein the first access class is associated with a utilization rate defining a limit on station traffic through first priority queue.

6. The system of claim 1, wherein: the server configured to receive a request from the first station for the second access class from the plurality of access classes to transmit data at a rate; andthe server configured to deny the request when the rate exceeds a utilization rate.

7. The system of claim 1, wherein the server is configured to be coupled to a database storing the QoS parameters.

8. The system of claim 1, wherein the server is configured to transfer the QoS parameters to the access point in a station switching record.

9. A method, comprising: receiving a request for authentication from a station, the request for authentication including a request for access to a first queue of an access point, the first queue of the access point associated with a first access class having a first level of priority;when the station is executing an application authorized to be assigned the first level of priority, (1) granting the station access to the first queue of the access point and access to a second queue of the access point, the second queue associated with the second access class having a level of priority lower than the first level of priority, and (2) setting a first QoS parameter for the station; andwhen the station is not executing an application authorized to be assigned the first level of priority, (1) granting the station access to the second queue of the access point without granting access to the first queue, and (2) setting a second QoS parameter for the station.

10. The method of claim 9, further comprising storing the first QoS parameter or the second QoS parameter in a light-weight data access protocol (LDAP) directory associated with security credentials for the station.

11. The method of claim 10, wherein the QoS parameters are further associated with information about a user associated with the request for authentication.

12. A method, comprising: receiving a request from a mobile device for a first access class assignment from a server, the first access class assignment being associated with transmission of data from the mobile device to the server;verifying that the mobile device is executing an application authorized to be assigned the first access class; andwhen the mobile device is verified to be executing an application authorized to be assigned the first access class: (1) sending the first access class assignment to the server; (2) receiving a session quality of service (QoS) parameter associated with the first access class from the server for the mobile device; and (3) sending the session QoS parameter associated with the first access class to the mobile device; andwhen the mobile device is not verified to be executing the application authorized to be assigned the first access class: (1) sending a second access class assignment to the server; (2) receiving a session quality of service (QoS) parameter associated with the second access class from the server for the mobile device; and (3) sending the session QoS parameter associated with the second access class to the mobile device.

13. The method of claim 12, wherein receiving the session QoS parameter associated with the first access class includes receiving a first station switching record, receiving the session QoS associated with the second access class includes receiving a second station switching record.

14. The method of claim 12, wherein the first access class is an 802.11e access class.

15. The method of claim 12, wherein the first access class is associated with a utilization rate defining a limit on station traffic through the first priority queue of an access point.

16. The method of claim 12, wherein the session QoS parameter comprise a RADIUS attribute restricting the first station to the first access class.

17. The method of claim 12, wherein the session QoS parameter is based on a QoS parameter associated with the first station and the first access class assignment.