Source: http://www.google.es/patents/US9565125
Timestamp: 2018-01-22 10:41:51
Document Index: 781474173

Matched Legal Cases: ['art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 400', 'art 400', 'art 400', 'art 400', 'art 400', 'art 400', 'art 400', 'art 400', 'art 400', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'Application No. 11823931', 'Application No. 12879114']

Patente US9565125 - Multicast to unicast conversion technique - Google Patentes
A technique allows stations to utilize an equal share of resources (e.g., airtime or throughput). This prevents slow stations from consuming too many resources (e.g., using up too much air time). Fairness is ensured by selective dropping after a multicast packet is converted to unicast. This prevents...http://www.google.es/patents/US9565125?utm_source=gb-gplus-sharePatente US9565125 - Multicast to unicast conversion technique
Número de publicación US9565125 B2
Número de solicitud US 14/645,184
Fecha de presentación 11 Mar 2015
Fecha de prioridad 14 Jun 2012
También publicado como CN104769864A, EP2862301A2, EP2862301A4, US8787375, US9008089, US9729463, US20130336319, US20140307557, US20150188836, US20170149680, US20170302467, WO2013187923A2, WO2013187923A3
Número de publicación 14645184, 645184, US 9565125 B2, US 9565125B2, US-B2-9565125, US9565125 B2, US9565125B2
Inventores Liwu Liu, Jianlin Zeng
Cesionario original Aerohive Networks, Inc.
Citas de patentes (215), Otras citas (13), Clasificaciones (31), Eventos legales (1)
Multicast to unicast conversion technique
US 9565125 B2
A technique allows stations to utilize an equal share of resources (e.g., airtime or throughput). This prevents slow stations from consuming too many resources (e.g., using up too much air time). Fairness is ensured by selective dropping after a multicast packet is converted to unicast. This prevents slow stations from using more than their share of buffer resources. Multicast conversion aware back-pressure into the network layer can be used to prevent unnecessary dropping of packets after multicast to unicast (1:n) conversion by considering duplicated transmit buffers. This technique helps achieve airtime/resource fairness among stations.
identifying a subplurality of traffic identifier (TID) queues associated with a multicast packet;
converting the multicast packet into a multicast-to-unicast converted unicast packet for the subplurality of TID queues;
enqueueing the multicast-to-unicast converted unicast packet in available TID queues of the subplurality of TID queues, wherein availability of the subplurality of TID queues is based on an amount of unused space in each TID queue of the subplurality of TID queues;
dequeueing the multicast-to-unicast converted unicast packet from a TID queue of the available TID queues according to a token bucket checking cycle applied to the subplurality of TID queues;
transmitting the multicast-to-unicast converted unicast packet to a destination.
2. The method of claim 1, wherein dequeueing the multicast-to-unicast converted unicast packet from the TID queue of the available TID queues according to a token bucket checking cycle further comprises:
determining whether a token weight of the TID queue is greater than a token balance threshold of the TID queue;
determining whether to dequeue the multicast-to-unicast converted unicast packet from the TID queue based on the determination whether the token weight of the TID queue is greater than the token balance threshold of the TID queue.
3. The method of claim 2, wherein if it is determined that the token weight of the TID queue is greater than the token balance threshold of the TID queue, the method further comprises dequeueing the multicast-to-unicast converted unicast packet from the TID queue.
4. The method of claim 2, wherein if it is determined that the token weight of the TID queue is less than the token balance threshold of the TID queue, the method further comprises incrementing token buckets associated with the subplurality of TID queues.
5. The method of claim 1, wherein a token bucket associated with the TID queue has a token weight greater than token weights of token buckets associated with the subplurality of TID queues.
6. The method of claim 1, wherein the TID queue has a lowest estimated transmission cost of the subplurality of TID queues.
7. The method of claim 6, wherein estimated transmission costs of the subplurality of TID queues is determined based on an estimated airtime of transmitting packets in the subplurality of TID queues.
8. The method of claim 7, wherein the estimated airtime of transmitting packets in the subplurality of TID queues is determined based on airtime required to transmit previous packets to a same client.
9. The method of claim 7, wherein the estimated airtime of transmitting packets in the subplurality of TID queues is determined based on clients assigned to the same QoS profile associated with the packets.
10. The method of claim 7, wherein the estimated airtime of transmitting packets in the subplurality of TID queues is determined based on clients assigned to the same QoS profile associated with the packets and a size of the packets.
a backpressure alleviation engine configured to identify a subplurality of traffic identifier (TID) queues associated with a multicast packet;
a multicast-to-unicast conversion engine configured to convert the multicast packet into a multicast-to-unicast converted unicast packet for the subplurality of TID queues;
a TID queuing engine configured to enqueue the multicast-to-unicast converted unicast packet in available TID queues of the subplurality of TID queues, availability of the subplurality of TID queues based on an amount of unused space in each TID queue of the subplurality of TID queues;
a TID-to-Access Category (AC) scheduling engine configured to dequeue the multicast-to-unicast converted unicast packet from a TID queue of the available TID queues according to a token bucket checking cycle applied to the subplurality of TID queues;
a medium interface configured to transmit the multicast-to-unicast converted unicast packet to a destination.
12. The system of claim 11, wherein in dequeueing the multicast-to-unicast converted unicast packet from the TID queue of the available TID queues according to a token bucket checking cycle, the TID-to-AC scheduling engine is further configured to:
determine whether a token weight of the TID queue is greater than a token balance threshold of the TID queue;
determine whether to dequeue the multicast-to-unicast converted unicast packet from the TID queue based on the determination whether the token weight of the TID queue is greater than the token balance threshold of the TID queue.
13. The system of claim 12, wherein the TID-to-AC scheduling engine is further configured to dequeue the multicast-to-unicast converted unicast packet from the TID queue, if it is determined that the token weight of the TID queue is greater than the token balance threshold of the TID queue.
14. The system of claim 12, wherein the TID-to-AC scheduling engine is further configured to increment token buckets associated with the subplurality of TID queues if it is determined that the token weight of the TID queue is less than the token balance threshold of the TID queue.
15. The system of claim 11, wherein a token bucket associated with the TID queue has a token weight greater than token weights of token buckets associated with the subplurality of TID queues.
16. The system of claim 11, wherein the TID queue has a lowest estimated transmission cost of the subplurality of TID queues.
17. The system of claim 16, wherein estimated transmission costs of the subplurality of TID queues is determined based on an estimated airtime of transmitting packets in the subplurality of TID queues.
18. The system of claim 17, wherein the estimated airtime of transmitting packets in the subplurality of TID queues is determined based on airtime required to transmit previous packets to a same client.
19. The system of claim 17, wherein the estimated airtime of transmitting packets in the subplurality of TID queues is determined based on clients assigned to the same QoS profile associated with the packets.
20. The system of claim 17, wherein the estimated airtime of transmitting packets in the subplurality of TID queues is determined based on clients assigned to the same QoS profile associated with the packets and a size of the packets.
means for identifying a subplurality of traffic identifier (TID) queues associated with a multicast packet;
means for converting the multicast packet into a multicast-to-unicast converted unicast packet for the subplurality of TID queues;
means for enqueueing the multicast-to-unicast converted unicast packet in available TID queues of the subplurality of TID queues, wherein availability of the subplurality of TID queues is based on an amount of unused space in each TID queue of the subplurality of TID queues;
means for dequeueing the multicast-to-unicast converted unicast packet from a TID queue of the available TID queues according to a token bucket checking cycle applied to the subplurality of TID queues;
means for transmitting the multicast-to-unicast converted unicast packet to a destination.
This application is a continuation of U.S. Ser. No. 14/314,893, filed Jun. 25, 2014; entitled “MULTICAST TO UNICAST CONVERSION TECHNIQUE”, which is a continuation of U.S. Ser. No. 13/646,547, filed Oct. 5, 2012, now U.S. Pat. No. 8,787,375; entitled “MULTICAST TO UNICAST CONVERSION TECHNIQUE,” which claims priority to U.S. Ser. No. 61/659,902, filed Jun. 14, 2012, entitled “MULTICAST TO UNICAST CONVERSION TECHNIQUE,” all of which are incorporated by reference.
An area of ongoing research and development is in improving performance of communication over a network, and in particular a wireless network. 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 (e.g., discussion of the 802.11n) provides a useful context in which to describe issues as they relate to wireless systems, at least partly because the standards are well-known and documented,
Performance improvements can include improving one aspect of network communications at the expense of another. Trade-offs between packet types, classes of users, etc., are generally considered an implementation-specific issue. For shared communications, such as multicast video, it may be desirable to sacrifice the performance at a particular network client in favor of other network clients, or ensure that the treatment of various network clients is fair given the capabilities of their stations. Improving overall performance of a group and ensuring fairness have been goals that have not yet been perfectly met.
A technique for improved performance on a network involves converting multicast packets to unicast packets. It is known that some stations take much longer to transmit than others. Slow stations can easily use up transmit buffer resources, resulting in back pressure to a network layer and degraded traffic quality to fast stations. To ensure fairness, each station is allowed to utilize an equal share of resources (e.g., airtime or throughput). This prevents slow stations from consuming too many resources (e.g., using up too much air time). Fairness is ensured by selective dropping after a multicast packet is converted to unicast. This prevents slow stations from using more than their share of buffer resources. Moreover, multicast conversion aware back-pressure into the network layer can be used to prevent unnecessary dropping of packets after multicast to unicast (1:n) conversion by considering duplicated transmit buffers. Advantageously, this technique helps achieve airtime/resource fairness among stations, for example, receiving a shared multicast transmission.
FIG. 1 depicts a diagram of an example of a back-pressure sensitive multicast to unicast conversion system.
FIG. 2 depicts a diagram of an example of a system for providing airtime or throughput fairness-enforced QoS for multicast video in Wi-Fi.
FIG. 3 depicts a flowchart of an example of a method for carrying out a token bucket check for ensuring packet transmission fairness.
FIG. 4 depicts a flowchart of an example of a token-weighted token bucket checking cycle.
FIG. 5 depicts a flowchart of an example of a method for dynamically adjusting bucket depth.
FIG. 1 depicts a diagram 100 of an example of a back-pressure sensitive multicast to unicast conversion system. In the example of FIG. 1, the diagram 100 includes a network 102, a server 104, clients 106-1 to 106-N (collectively referred to as clients 106), a computer-readable medium 108, and a multicast-to-unicast conversion, high session performance system 110.
In the example of FIG. 1, the network 102 may be practically any type of communications network, such as the Internet or an infrastructure network. The term “Internet” as used in this paper refers to a network of networks that use 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”). More generally, the network 102 can include, for example, a wide area network (WAN), metropolitan area network (MAN), campus area network (CAN), or local area network (LAN), but the network 102 could at least theoretically be of any size or characterized in some other fashion (e.g., personal area network (PAN) or home area network (HAN), to name a couple of alternatives). Networks can include enterprise private networks and virtual private networks (collectively, private networks). As the name suggests, private networks are under the control of a single entity. Private networks can include a head office and optional regional offices (collectively, offices). Many offices enable remote users to connect to the private network offices via some other network, such as the Internet. The example of FIG. 1 is intended to illustrate a network 102 that may or may not include more than one private network.
In the example of FIG. 1, the server 104 is coupled to the network 102. The server 104, and more generally any device connected to a network, can be referred to as “on” the network. For illustrative purposes, the server 104 is described in this example as serving content. Accordingly, in this example, the server 104 can be referred to as a content server. A web server, which is one type of content server, is typically at least one computer system that operates as a server computer system and is configured to operate with the protocols of the World Wide Web and is coupled to the Internet. Unless context dictates otherwise, a server as used in this paper includes at least a portion of a computer system running server software.
A computer system, as used in this paper, is intended to be construed broadly. In general, a computer system will include a processor, memory, non-volatile storage, and an interface. A typical computer system will usually include at least a processor, memory, and a device (e.g., a bus) coupling the memory to the processor.
The processor can be, for example, a general-purpose central processing unit (CPU), such as a microprocessor, or a special-purpose processor, such as a microcontroller.
Software is typically stored in the non-volatile storage. Indeed, for large programs, it may not even be possible to store the entire program in the memory. Nevertheless, it should be understood that for software to run, if necessary, it is moved to a computer-readable location appropriate for processing, and for illustrative purposes, that location is referred to as the memory in this paper. Even when software is moved to the memory for execution, the processor will typically make use of hardware registers to store values associated with the software, and local cache that, ideally, serves to speed up execution. As used herein, a software program is assumed to be stored at any known or convenient location (from non-volatile storage to hardware registers) when the software program is referred to as “implemented in a computer-readable storage medium.” A processor is considered to be “configured to execute a program” when at least one value associated with the program is stored in a register readable by the processor.
In the example of FIG. 1, the server 104 serves content to the clients 106. In this example, the server-client relationship between the server 104 and the clients 106 is that of content server to content consumer. A device that includes a client 106-1 can also include a client of some other server or include a server for some other client. For example, in a wireless context, the device can include a wireless client and be associated with a wireless network, such as a wireless LAN (WLAN).
In a wireless communications context, the clients 106 can be referred to as stations. A station, as used in this paper, may be referred to as a device with a media access control (MAC) address and a physical layer (PHY) interface to a wireless medium that complies with the IEEE 802.11 standard. Thus, for example, the stations 106 and a wireless access point (WAP) with which the stations 106 associate can be referred to as stations, if applicable. IEEE 802.11a-1999, IEEE 802.11b-1999, IEEE 802.11g-2003, IEEE 802.11-2007, and IEEE 802.11n TGn Draft 8.0 (2009) are incorporated by reference. As used in this paper, a system that is 802.11 standards-compatible or 802.11 standards-compliant complies with at least some of one or more of the incorporated documents' requirements and/or recommendations, or requirements and/or recommendations from earlier drafts of the documents, and includes Wi-Fi systems. Wi-Fi is a non-technical description that is generally correlated with the IEEE 802.11 standards, as well as Wi-Fi Protected Access (WPA) and WPA2 security standards, and the Extensible Authentication Protocol (EAP) standard. In alternative embodiments, a station may comply with a different standard than Wi-Fi or IEEE 802.11, may be referred to as something other than a “station,” and may have different interfaces to a wireless or other medium.
In the example of FIG. 1, the computer-readable medium 108 is coupled to the clients 106. In a wireless communications context, the computer-readable medium 108 can include a WLAN. In a wired communications context, the computer-readable medium 108 can include a wired network. The computer-readable medium 108 can include wired and wireless networks. It is likely that the computer-readable medium 108 would be referred to as a “network” in some implementations, but it is not a requirement.
In the example of FIG. 1, the network 102 and the computer-readable medium 108 are coupled together via the multicast-to-unicast conversion, high session performance system 110. Conceptually, the server 104, the clients 106, and the multicast-to-unicast conversion, high session performance system 110 can be on a network that comprises the network 102 and the computer readable medium 108, though in this example communications are described as passing from the server 104 through the multicast-to-unicast conversion, high session performance system 110 to the clients 106. (The network 102 and the computer-readable medium 108 can also be coupled together via some other redundant channel.)
In the example of FIG. 1, the multicast-to-unicast conversion, high session performance system 110 includes a point of presence (PoP) interface 112, a queuing engine 114, a multicast queue 116, a scheduling engine 118, traffic identifier (TID) queues 120-1 to 120-N (collectively referred to as TID queues 120), an access category (AC) scheduling engine 122, and a medium interface 124. The system 110 receives downlink traffic from the network 102 and puts the downlink traffic onto the computer-readable medium 108 (the source of the downlink traffic is the server 104 and the destination is one or more of the clients 106). Thus, in this paper, downlink network traffic refers to network traffic directed toward one or more of the clients 106. Uplink traffic, on the other hand, refers to network traffic received from one or more of the clients 106. Downlink traffic is directed to one of more of the clients 106 in direct or indirect communication with the system 110 via a wireless network connection. The system 110 may be adapted to communicate the packet directly to one or more of the clients 106 via a wired or wireless network connection (depending upon the nature of the computer-readable medium 108) and/or to other network devices, which in turn communicate the packet to one or more of the clients 106 via a wired or wireless network connection.
In the example of FIG. 1, the PoP interface 112 is intended to represent an engine that enables the system 110 to communicate with the network 102. The term “PoP” is frequently used with reference to an access point to the Internet, but is used more broadly in this paper to include an access point to the network 102. In addition to or as part of the PoP interface 112, the system 110 can include servers, routers, ATM switches, digital/analog call aggregators, etc. that are conceptually part of a PoP associated with the PoP interface 112 on the network 102. The PoP interface 112 can be part of the facilities of a telecommunications provider that an Internet service provider (ISP) rents or a location separate from a telecommunications provider. In this paper, the PoP interface 112 is considered to include the components of the system 110 that are under the control of a party that provides access to the network 102 or a service thereof; the party can be referred to as a network service provider (NSP) which is a superset of ISP.
In the example of FIG. 1, the PoP interface 112 is coupled to the queuing engine 114. In a specific implementation, the queuing engine 114 can be considered part of a network switch. A network switch includes a computer networking device that connects network segments, and can also include port mirroring, firewall, network intrusion detection, performance analysis, and other applicable known or convenient engines. A network switch can include a network bridge that processes and routes data in the data link layer (layer 2) of the OSI model. For example, an Ethernet switch operates at the data link layer. However, the network switch could be implemented as a multilayer switch that also processes data at the network layer (layer 3) and/or transport layer (layer 4). A network hub or repeater operates on the physical layer (layer 1) and typically receives data on a port of entry and broadcasts out on every port other than the port of entry. The network switch would not typically be a passive network device such as a hub, which falls outside of the definition of “network switch” as used in this paper, but within the definition of a “networking device” as used in this paper.
A network switch can be implemented in a converged device such as a gateway to access broadband services such as digital subscriber line (DSL) or cable internet. The converged device would typically include components that interface to the particular broadband technology, such as a protocol converter, and can include a telephone interface for voice over IP (VoIP). The term “broadband” is a relative term. For example, broadband Internet access is typically contrasted with dial-up access using a 56 k modem. In a specific implementation, the term broadband can be used to mean at least equivalent to a DSL, which is about 70 Mbps. For example, 70 Mbps could include 6 Mbps of Internet access, 30 Mbps of broadcast video, and 35 Mbps of switched digital video (give or take). In Ethernet provided over cable modem is a common alternative to DSL; and the term broadband should be interpreted to mean equivalent to that of 100BASE-T Ethernet, as well. In telecommunication, a very narrow band can carry Morse code, a narrow band will carry speech (voiceband), and a still broader band will carry real-time multimedia. Only the latter would normally be considered “broadband.” However, it may be noted that a voice line could be converted to a non-laded twisted-pair wire (no telephone filters) to become hundreds of kilohertz wide (broadband) and can carry several Mbps. Thus, the term broadband in this paper should include equivalent to ADSL, which, depending upon the implemented standard can be from 2 Mpbs to 27.5 Mbps. As another example, digital signal 3 (DS3) is a digital signal level 3 T-carrier, also referred to as a T3 line, with a data rate of 44.736 Mpbs, which would be considered in the “broadband” range. Currently, a sophisticated consumer expectation for broadband range for Internet access would be perhaps 44 Mbps or higher, or perhaps approximately 70-100 Mbps, but it should be understood that the definition of broadband could change over time to include different, presumably higher, Mbps than those just described, and different consumer expectations.
In a specific implementation, the queuing engine 114 includes bridging functionality (and can be referred to as a “bridging and queuing engine”). Bridging often refers to transparent bridging or learning bridge operations. In Ethernet networks, bridging functionality is descriptive of a device that behaves according to the IEEE 802.1D standard. Another form of bridging, source route bridging, was developed for token ring networks. Other packet-switched networks can operate in accordance with other standards.
In a specific implementation, the queuing engine 114 includes classification functionality (and can be referred to as a “classification and queuing engine”). Classification functionality enables the identification of a kind of traffic in a traffic stream, such as audio or video. Traffic class can be used to indicate the kind of traffic in a traffic stream, such as audio or video. Quality of service (QoS) refers to control mechanisms that can provide different priority to different traffic classes, users, or data flows, or guarantee a certain level of performance to a data flow in accordance with requests from the application program.
In a specific implementation, the queuing engine 114 includes both bridging and classification functionality (and can be referred to as a “bridging, classification, and queuing engine”).
In the example of FIG. 1, the queuing engine 114 is coupled to the multicast queue 116. The multicast queue 116 can be implemented as a buffer, such as a network DRAM buffer. In a specific implementation, the queuing engine 114 enqueues packets in the multicast queue 116. As used in this paper, unless context dictates otherwise, a packet includes a collection of data that can be referred to (typically depending upon the context and/or layer of ODI model considered), a datagram, frame, message, or some other type of network data package. For illustrative purposes, the packets include multicast packets, which are at some point converted to unicast. This is relevant due to the advantageous back-pressure control offered by the techniques described in this paper (and the multicast queue 116 can be referred to as a “backpressure-controlled multicast queue”). The multicast queue 116 can be part of an indiscriminant queue for packets, or can be a physically or logically distinct queue from queues containing, e.g., unicast packets.
In the example of FIG. 1, the multicast queue 116 is coupled to the scheduling engine 118. In a specific implementation, the scheduling engine 118 includes a “dummy scheduler.” In a Wi-Fi implementation, the scheduling engine 118 can perform IEEE 802.3-to-802.11 encapsulation. In a specific implementation, the scheduling engine 118 converts multicast packets in the multicast queue 116 into unicast packets.
In a specific implementation, the scheduling engine 118 is backpressure-aware in the network layer (and can be referred to as a “backpressure-aware scheduling engine”). In the context of this example, “backpressure” is descriptive of insufficient transmit buffers in a transmit subsystem (e.g., a Wi-Fi subsystem). The scheduling engine 118 avoids dropping packets, such as video packets, after multicast-to-unicast conversion by considering duplicated transmit buffers. In a specific implementation, this entails counting the number of duplicate unicast packets to be derived from the multicast packet per packet when considering transmit buffer requirements. For example, when the scheduling engine 118 schedules multicast packets, the scheduling engine checks whether the transmit subsystem has enough buffers for each copy to be duplicated, as opposed to only checking one available buffer.
In a specific implementation, the scheduling engine 118 ensures buffer fairness (and can be referred to as an “ensured buffer fairness scheduling engine”). Buffer fairness is ensured by selective dropping after a multicast packet is converted to multiple unicast packets for multiple stations. Advantageously, this can prevent slow stations from using unfair amounts of buffer resources and from causing other stations to have limited buffer resources to utilize their assigned fair share of airtime; and can help to achieve airtime/throughput fairness among multiple stations, e.g., watching the same multicast video stream. TID identifies data packets as belonging to a unique traffic stream. Assuming packets are not dropped, the scheduling engine 118 enqueues multicast-to-unicast converted packets in the appropriate TID queues 120.
In operation, the scheduling engine 118 determines a QoS profile to be associated with a packet. (The AC scheduling engine 122 could alternatively or redundantly determine the QoS profile, or the scheduling engine 118 could share some portion of the determination with the AC scheduling engine 122.) QoS profiles can be assigned to packets based on source, destination, user identity or user class associated with source and/or destination, content or control data associated with the packet, source or client application, and/or data flow associated with the packet. In a specific implementation, the set of QoS profiles are specified by network administrators. Each QoS profile can be assigned a scheduling weight and a scheduling mode to facilitate prioritization of packets. In specific implementation, a QoS profile can be associated with a per-user rate limit.
In the example of FIG. 1, the scheduling engine 118 is coupled to the TID queues 120. In a specific implementation, the TID queues 120 are associated with respective traffic flows on a per-station, per-priority basis. In a multi-station IEEE 802.11n TID packet scheduling scheme, the TID queues 120 are compatible with IEEE 802.11n TID queues. In other implementations, the TID queues 120 may be compatible with some other protocol or go by some other name.
In the example of FIG. 1, the TID queues 120 are coupled to the AC scheduling engine 122. Wireless Multimedia Extensions, also known as Wi-Fi Multimedia (WMM), is a Wi-Fi Alliance interoperability certification, based on the IEEE 802.11e standard, that provides basic QoS features to IEEE 802.11 networks. WMM prioritizes traffic according to four ACs—voice, video, best effort, and background. In a Wi-Fi context, the AC scheduling engine 122 would schedule according to these four categories, but other standards may refer to categories by a name other than AC, and may have a different number of categories.
In a specific implementation, the AC scheduling engine 122 can replace a round-robin TID scheduling algorithm with an airtime fairness and/or throughput fairness scheduling algorithm, targeting each station to utilize equal share of either airtime or throughput. In such an implementation, the AC scheduling engine 122 is responsible for fairness-enforced TID to access category scheduling (and can be referred to as a “fairness-enforced TID to AC scheduling engine”). The enforced fairness can be with respect to airtime, for example preventing stations with low packet rates from using too much airtime. In an embodiment in which the AC scheduling engine 122 has the requisite capability, the AC scheduling engine 122 can be referred to as an “airtime fairness-enforced AC scheduling engine.” The enforced fairness can be with respect to throughput, for example improving the overall throughput for majority stations with similar packet rates. In an embodiment in which the AC scheduling engine 122 has the requisite capability, the AC scheduling engine 122 can be referred to as a “throughput fairness-enforced AC scheduling engine.” Alternatively, the AC scheduling engine can be referred to as an “airtime and throughput fairness-enforced AC scheduling engine,” or “airtime or throughput fairness-enforced AC scheduling engine” (the former is considered to be a subset of the latter), if applicable. It may be noted that in some embodiments, the airtime and throughput fairness-enforced AC scheduling engine operates in either airtime fairness mode or throughput fairness mode, but not both at the same time for a particular domain.
In a specific implementation, the AC scheduling engine determines a cost for a packet in one or more of the TID queues 120. The cost to send the packet can be referred to as a “token cost.” The token cost can be based on factors including, for example, an estimated airtime for the packet, the bandwidth required to send the package, the QoS profile, etc. The token cost represents an estimate or ratio of network resources consumed when sending the associated packet.
In an implementation in which the token cost is based at least in part on an estimated airtime, the estimate can be based on airtime required by previous packets to the same client, similar clients, and/or clients assigned to the same QoS profile. For example, a running average of airtime consumed by one or more most-recently sent packets to the same client may be used to determine at least a portion of estimated packet airtime for a currently received packet. In a specific implementation, the average airtime of recently sent packets can be weighted or divided by their respective packet sizes to determine an average airtime consumed per data unit, such as average airtime consumed per byte. This average airtime consumed per data unit can be scaled or weighted according the size of the received packet to determine at least a portion of the estimated airtime for the currently received packet, causing token cost to increase with packet size. The token cost or total estimated airtime may or may not include an estimated airtime for transmitting a packet to the client, the actual, estimated, or prorated airtime used for retransmitting packets that were previously unsuccessfully transmitted, and/or network overhead.
In a specific implementation, the AC scheduling engine 122 aggregates frames (and can be referred to as an “AC scheduling and frame aggregation engine”). In a specific implementation, the AC scheduling engine 122 performs airtime or throughput fairness-enforced TID to AC scheduling and aggregates frames (and can be referred to as an “airtime or throughput fairness-enforced TID to AC scheduling and frame aggregation engine”).
In the example of FIG. 1, the access category aggregation engine 122 is coupled to the medium interface 124. In a Wi-Fi implementation, the medium interface 124 can include a Wi-Fi radio. In other implementations, applicable known or convenient components can be used to couple the system 110 to the computer-readable medium 108 in a wired or wireless fashion.
In the example of FIG. 1, in operation, the PoP interface 112 receives a multicast packet (typically an IP packet) from the network 102 that was sent from the server 104. The queuing engine 114 enqueues the multicast packet (typically after proper classification) on the multicast queue 116. The scheduling engine 118 dequeues the multicast packet and enqueues a unicast packet (typically with proper encapsulation) on each of the relevant TID queues 120, corresponding to the client 106 that is an intended recipient of the multicast packet. The access category aggregation engine 122 aggregates frames by access category and provides the frames to the medium interface 124 for placing on the computer-readable medium 108.
FIG. 2 depicts a diagram 200 of an example of a system for providing airtime or throughput fairness-enforced QoS for multicast video in Wi-Fi. FIG. 2 is intended to illustrate techniques for ensuring fairness and performance in a system such as is illustrated in the example of FIG. 1. The diagram 200 is directed to Wi-Fi, but could be directed to other standards (or no standard) as well. The diagram 200 includes a multicast queue 202, a backpressure-sensitive scheduling engine 204, TID queues 206-1 to 206-N (referred to collectively as TID queues 206), an AC scheduling and frame aggregation engine 208, and a Wi-Fi Radio 210.
In the example of FIG. 2, the multicast queue 202 can be similar to the multicast queue 116 (FIG. 1). In a specific implementation, the multicast queue 202 is configured as a buffer to store multicast packets. The multicast queue 202 can be implemented as part of a queue that physically or logically includes unicast packets, but nevertheless can be referred to as a “multicast queue” because multicast packets, though perhaps interspersed with unicast packets, are still queued therein. In a specific implementation, the multicast packets include multicast video packets (and can be referred to as a “multicast video queue”). The multicast queue 202 can be implemented as part of a queue that physically or logically includes packets having ACs other than video, but nevertheless can be referred to as a “multicast video queue” because multicast video packets, though perhaps interspersed with multicast voice (or other AC) packets, are still queued therein.
In the example of FIG. 2, the backpressure-sensitive scheduling engine 204 can be similar to the scheduling engine 114 (FIG. 1). The backpressure-sensitive scheduling engine 204 includes a dummy scheduler 212, a backpressure alleviation engine 214, an 802.3-to-802.11 encapsulation engine 216, a multicast-to-unicast conversion engine 218, a TID queuing engine 220, and a buffer fairness enforcement engine 222. While the example of FIG. 2 makes explicit reference to certain standards, it should be understood that techniques described in association with this example may be applicable to other wireless or wired standards or to standard-less implementations.
In the example of FIG. 2, the dummy scheduler 212 is coupled to the multicast queue 202. The purpose of the dummy scheduler 212 is to dequeues packets from the multicast queue 202 in accordance with an implemented algorithm, schedule, or timer. The act of dequeuing packets from the multicast queue 202 frees up a network buffer. (It may be noted that the dummy scheduler could be implemented to mark a packet for processing, but freeing up the network buffer could occur later.)
In the example of FIG. 2, the backpressure alleviation engine 214 determines whether a multicast packet scheduled into Wi-Fi needs multiple copies of transmit buffers for the corresponding multicast-to-unicast converted packet. This enables the backpressure alleviation engine 214 to intelligently reduce backpressure that would otherwise prevent a network scheduler from scheduling packets into the Wi-Fi domain to avoid dropping packets in the Wi-Fi domain. The determination can include counting the number of multicast-to-unicast converted packets that will be derived from a multicast packet when considering transmit buffer requirements. In a specific implementation that includes video multicast packets, the backpressure alleviation engine 214 provides backpressure sensitivity to the network layer to prevent unnecessarily dropping packets after multicast-to-unicast conversion by considering the duplicated transmit buffers.
In a specific implementation, one aspect of airtime (or throughput) fairness-based scheduling is backpressure alleviation. The backpressure alleviation engine 214 can force clients of a network (e.g., a WLAN) to utilize equal shares of airtime (or throughput) at the network layer. This prevents stations with lower Wi-Fi packet rates to use too much airtime. For example, stations with low signal-to-noise ratio (SNR) take more airtime to transmit than stations with high SNR (the former can be referred to as “slow stations” and the latter can be referred to as “fast stations”). Slow stations use more airtime causing fast stations to potentially receive poor, e.g., video quality as their shares of airtime are squeezed. Airtime fairness-based scheduling can ameliorate this problem so that airtime usage of slow stations is more limited and faster stations can achieve better, e.g., video quality.
Backpressure alleviation could also or instead be implemented at the TID queuing engine 220, discussed later, when determining whether to enqueue a packet in an appropriate one of the TID queues 206. In such an implementation, the backpressure alleviation engine 214 can selectively drop multicast-to-unicast converted packets that do not have space on the TID queues 206. (Unicast packets can also be selectively dropped, or handled in some other manner.)
Advantageously, the backpressure alleviation engine 214 enables consideration of TID scheduling from a Wi-Fi native layer, rather than an abstract IEEE 802 generic MAC and mostly focused on IP layer. This provides fine QoS control logic. For example, the backpressure alleviation engine 214 provides insight into how multicast-to-unicast converted video packets will be scheduled in a Wi-Fi native layer.
In the example of FIG. 2, the 802.3-to-802.11 encapsulation engine 216 is coupled to the dummy scheduler 212. As is well-known in the relevant art, IEEE 802.3 is a working group and a collection of IEEE standards produced by the working group defining the physical layer and data link layer's media access control (MAC) of wired Ethernet. This is generally a local area network technology with some wide area network applications. Physical connections are typically made between nodes and/or infrastructure devices (hubs, switches, routers) by various types of copper or fiber cable. IEEE 802.3 is a technology that supports the IEEE 802.1 network architecture. As is well-known in the relevant art, IEEE 802.11 is a working group and collection of standards for implementing WLAN computer communication in the 2.4, 3.6 and 5 GHz frequency bands. The base version of the standard IEEE 802.11-2007 has had subsequent amendments. These standards provide the basis for wireless network products using the Wi-Fi brand. Obviously, the example of FIG. 2 is intended to illustrate a specific implementation that involves 802.3-compatible packets in the multicast queue 202 and converts via encapsulation to 802.11-compatible packets for enqueuing on the TID queues 206.
In the example of FIG. 2, the multicast-to-unicast conversion engine 218 is coupled to the 802.3-to-802.11 encapsulation engine 216. The engines 216, 218 can be logically or physically combined to form a single “encapsulation and conversion-to-unicast engine.” Conversion from multicast-to-unicast can entail changing values in a header. In the example of FIG. 2, the changes would be to an 802.11-compatible header. In a specific implementation, converting a multicast packet to a unicast packet involves changing a group address in the header of the multicast packet to a unicast MAC address (or some other unicast address), which converts the multicast packet to a unicast packet that is bound for the client having the MAC address. In order to generate unicast packets for each client that is part of the group (or a set of clients downstream from a given network device that are part of the group), the multicast-to-unicast conversion engine 216 generates a set of copies of the multicast packet for a corresponding set of clients, and converts the set of copies of the multicast packet to unicast packets that include a destination for the corresponding client (or a destination sufficient to enable the system to get the unicast packet to the client).
In the example of FIG. 2, the TID queuing engine 220 is coupled to the multicast-to-unicast conversion engine 218. The TID queuing engine 220 enqueues packets in the TID queues 206 in accordance with the client and priority associated with the TID queues. The TID queuing engine 220 enqueues packets in the TID queues 206 explicitly, implicitly, or otherwise allowed by the buffer fairness enforcement engine 222.
In the example of FIG. 2, the buffer fairness enforcement engine 222 is coupled to the TID queuing engine 220. In a specific implementation, the buffer fairness enforcement engine 222 instructs the TID queuing engine 220 to selectively drop multicast-to-unicast converted packets for certain clients. Fast stations will tend to have small TID queue length and slow stations will tend to have large TID queue length. If a station meets the limit, it does not attend multicast-to-unicast conversion even if it is in the group, implicitly resulting in a dropped packet. This can be referred to as a “multicast-to-unicast conversion (MC) drop.”
MC drops can prevent slow stations from using an unfair amount of buffer resources thereby enabling fast stations to utilize their assigned fair share of airtime (or throughput). In a specific implementation, the buffer fairness enforcement engine 222 enables airtime (or throughput) fairness among multiple stations receiving the same multicast video stream. Advantageously, the buffer fairness enforcement engine 222 can take into account the importance of Wi-Fi native transmission buffer allocation, which can be associated with limited resources, particularly for system on chip (SoC) implementations. When ignored, slow stations can hog transmission buffer resources and block fast stations to break IP QoS.
In a specific implementation, the buffer fairness enforcement engine 222 limits buffer resources per station based upon buffer resources currently available. In a specific implementation, each station is initially (perhaps conceptually) allocated I=T/S, where I is transmit buffer resources initially allocated to each station, T is total available buffer resources, and S is the number of transmit-active stations. Advantageously, the buffer fairness enforcement engine 222 can allow sharing of buffer resources without reducing performance from slow stations hogging resources. In a specific implementation, the buffer fairness enforcement engine 222 increases the buffer resources available in accordance with the equation M=C A/S, where M is the maximum buffer resources that can be allocated per station, C is a constant, A is the number of buffer resources currently available, and S is the number of transmit-active stations. C can be set to a value that has been empirically shown to be effective, such as 10. Alternatively, C can be replaced with a variable, V, that is adjustable based upon the characteristics of current or predicted traffic. In a specific implementation, A/T can have a floor of 0.2 and/or M can be ignored if A/T is greater than 0.8 (for unlimited buffer resource sharing). This can be referred to as establishing a floor and/or unlimiting a ceiling for an available-to-total transmit buffer ratio. M can also be established more chunkily by, for example, rounding or truncating A/T to the nearest 0.1, 0.2, or some other value. This can be referred to as discretely segmenting an available-to-total transmit buffer ratio. (Note: M=C(A/T)(T/S)=C A/S; or M=V(A/T)(T/S)=V A/S.)
To illustrate this concept for C=10 (or V=10), an A/T floor of 0.2 and chunkiness of 0.2, assume T=512; so each station is initially (perhaps conceptually) allocated 512/S buffers. Because T=512 is total buffer resources and A/T floor is 0.2, it follows that for A<100 (approximate), A can be treated as 100, and M≈1000/S (or M=512/S*2). Due to the chunkiness of 0.2 in this example, M can also equal M=512/S*4, M=512/S*6, M=512/S*8, or M=512/S*10.
In the example of FIG. 2, the TID queues 206 are coupled to the TID queuing engine 220 of the backpressure-sensitive scheduling engine 204. The TID queues 206 can be similar to the TID queues 120 (FIG. 1).
In the example of FIG. 2, the AC scheduling and frame aggregation engine 208 is coupled to the TID queues 206. The AC scheduling and frame aggregation engine 208 includes a TID-to-AC scheduling engine 224, a token bucket management engine 226, token bucket datastores 228-1 to 228-N (collectively referred to as token bucket datastores 228), a token refresh engine 230, and a frame aggregation engine 232.
In the example of FIG. 2, the TID-to-AC scheduling engine 224 is coupled to the TID queues 206. The TID-to-AC scheduling engine 224 dequeues packets from the TID queues 206 for AC scheduling. Slow or marginal Wi-Fi stations can use up Wi-Fi hardware transmit buffers and/or airtime to the detriment of other stations, even stations that have the capability to achieve good playback quality if resources were fairly allocated. Moreover, global fairness cannot be achieved for airtime in Wi-Fi when slow stations have packets queued for sending and fast stations have none, which triggers frequent token reissuing for slow stations to steal away airtime share. Airtime (or throughput) fairness targets each station to utilize equal shares of airtime (or throughput). The TID-to-AC scheduling engine 224 ameliorates the inherent unfairness of, e.g., a straight-forward round-robin scheduling algorithm with the use of an implemented token-restricted round-robin algorithm.
In the example of FIG. 2, the token bucket management engine 226 is coupled to the TID-to-AC scheduling engine 224. The token bucket management engine 226 provides the TID-to-AC scheduling engine 224 instructions to enable the TID-to-AC scheduling engine 224 to schedule packets in accordance with an implemented token-restricted round-robin algorithm.
In the example of FIG. 2, the token buckets 228, which respectively correspond to the TID queues 206, are coupled to the token bucket management engine 226. Alternatively, the token buckets 228 can correspond to subpluralities of the TID queues 206 (e.g., one token bucket per station where a station has multiple associated TID queues, such as one TID queue per priority class). In a relatively simplistic implementation, the token buckets 228 store a token balance for the corresponding TID queues 206. The token buckets 228 can be implemented as a datastore for storing a value representative of an unused airtime (or throughput) share. The token buckets 228 can have minimum values (floors), which can include zero or negative values, and/or maximum values (ceilings).
Depending upon the context, it may be useful to refer to certain terms, such as “token surplus,” “no token balance,” and “token deficit.” For illustrative convenience, no token balance is indicative of a lower threshold at which no tokens are available for a relevant traffic flow, and may be referred to as zero with the understanding that some other number could be representative of no token balance. For illustrative convenience, a token surplus is indicative of one or more tokens more than no token balance, and may be referred to as a positive number of tokens greater than zero with the understanding that alternative numbering schemes could be used (e.g., a token surplus could be any number greater than some arbitrary number, such as −5 or 20; or token surplus could be ordinally smaller than no token balance by switching from an incremental to decremental system). For illustrative convenience, a token deficit is some amount of tokens less than no token balance, and may be referred to as a negative number of tokens with the understanding that alternative numbering schemes could be used. Token deficits may or may not be allowed, depending upon implementation- or configuration-specific factors.
In a specific implementation, the token bucket management engine 226 initializes the token buckets 228 to an initial value. The initial value can be a positive number, where the number represents an applicable unit of measure (e.g., bytes, seconds, a ratio, etc.). Token buckets can be incremented from time to time by an increment value. A scheduling weight may or may not be used to modify the size of the initial and/or increment value. The scheduling weight can depend upon, for example, characteristics of corresponding TID queue(s), characteristics of other TID queues, characteristics of a station with which a token bucket is associated, characteristics of a network (such as performance), etc.
In a specific implementation, the token bucket management engine 226 carries out a token bucket checking cycle. For illustrative purposes, the token bucket 228-1 is treated as the first in a token bucket checking cycle, and 228-N is treated as the last. In an alternative, there can be multiple token bucket checking cycles that operate in parallel (e.g., one for each priority class). Over the course of a token bucket checking cycle, the token bucket management engine 226 can increment the values in the token buckets 228. (Initialization can occur in an initialization cycle, or can instead, depending upon the implementation, occur in a token bucket checking cycle.)
In a specific implementation, in a token bucket checking cycle, the token bucket management engine 226 determines whether a token balance for a token bucket 228-1 is at an allowable threshold. In a specific implementation, an allowable threshold value can be the same as the initial value, a value lower than the initial value, when the token bucket 228-1 has a token surplus, etc. If the token bucket 228-1 is at an allowable threshold, the token bucket management engine 226 gives the TID-to-AC scheduling engine 224 permission to dequeue and schedule one or more packets from the TID queue 206-1.
In a specific implementation, each packet has an associated token cost. A token cost can be indicative of resources used to transmit the packets (e.g., based on packet size, time to transmit, etc.). When the TID-to-AC scheduling engine 224 dequeues a packet from the TID queue 206-1, the token bucket management engine 226 deducts an appropriate token cost from the balance of the token bucket 228-1. Alternatively, the token cost can be determined and/or deducted at a later time (e.g., in the frame aggregation engine 230 or in the wi-fi radio 210, with feedback to the token bucket management engine 226 to carry out the deduction). In a specific implementation, the token cost may be deducted even if the deduction results in the token balance being reduced to below zero (or an equivalent value indicative of the floor at which dequeuing a packet is not allowed). In essence, a flow with a token balance (i.e., a token balance greater than a “no token balance” amount) can send a packet “on credit” even if the packet is sufficiently large that it has greater token cost than token balance. In a specific implementation, the token bucket management engine 226 can deduct an estimated token cost for a packet, and later adjust the relevant token bucket balance after measuring resources consumed in the transmission of the packet at a later time. (In the case of uplink traffic, token cost may be known beforehand, obviating the need for an estimate.)
In the example of FIG. 2, the token refresh engine 230 is coupled to the token buckets 228. The TID-to-AC scheduling engine 224 and token bucket management engine 226 can carry out the token bucket checking cycle as described in the preceding several paragraphs for each of the TID queues 206 and token buckets 228. After one or more token bucket checking cycles, the token refresh engine 230 can increment each of the token buckets 228 by an increment value. The token refresh engine 230 can increment each of the token buckets 228 in a refresh cycle that runs in parallel with the token bucket checking cycle, incrementing token buckets after they are checked. In such a case, the token buckets can be incremented after every time the token buckets are checked or a fraction of the times the token buckets are checked (e.g., once every 2 or more times a token bucket checking cycle iterates). Alternatively to parallel execution, the token refresh engine 230 can carry out the token bucket refresh cycles intermittently with the token bucket checking cycles. The token refresh engine 230 can carry out token bucket refresh cycles in accordance with a timer and/or can be reactive to environmental factors, such as network congestion. Depending upon the implementation, the token bucket checking cycle and token bucket refresh cycles can be considered aspects of a single token bucket management cycle.
By employing the token bucket checking cycle and the token bucket refresh cycle, the token bucket management engine 226 provides instructions to the TID-to-AC scheduling engine 224 to dequeue packets for traffic flows that are currently permitted to send, and eventually allows all traffic flows to send as token buckets that run out of tokens are replenished. Of course, if a traffic flow is sufficiently delayed, it can result in drops, which means even though token buckets are refreshed, the token buckets may not be refreshed with sufficient speed to ensure that all packets bound for a station are actually sent.
In the example of FIG. 2, the Wi-Fi radio 210 is coupled to the frame aggregation engine 232 of the AC scheduling and frame aggregation engine 208. The frame aggregation engine 232 receives frames from the TID-to-AC scheduling engine 224, aggregates them appropriately, and provides the aggregated frames to the Wi-Fi radio 210 for transmission via a wireless network.
FIG. 3 depicts a flowchart 300 of an example of a method for carrying out a token bucket check for ensuring packet transmission fairness. In the example of FIG. 3, the flowchart 300 starts at module 302 where an initialization cycle is started. The initialization cycle adds an initial value to each token bucket that is to be part of a token bucket checking cycle or sets each token bucket to the initial value. The initialization cycle need not be explicit (e.g., the token buckets could start with a value of 0 without an explicit initialization cycle to cycle through each of the token buckets in turn). The initial value need not be the same for each TID queue (e.g., some TID queues could have larger associated initial and refresh values than other TID queues).
In the example of FIG. 3, the flowchart 300 continues to decision point 304 where it is determined whether a currently considered TID queue is marked. A TID queue is marked if it runs out of tokens (e.g., if the TID queue has a token deficit). If the TID queue under consideration is marked, that signifies that a token bucket checking cycle has cycled through each applicable TID queue and returned to a TID queue that previously had insufficient tokens and was, therefore, marked. For this reason, the marker can be referred to as an “insufficient tokens indicator” for the TID queue. Depending upon the implementation, the marker can be a Boolean value (true or false) or a Boolean expression (e.g., token balance <0), or some other value or function that provides the applicable status of the TID queue. As will be indicated later in the flowchart 300, if a marker survives until the token bucket checking cycle returns to the TID queue associated with the marker, a refresh cycle is needed because that means none of the TID queues have sufficient tokens.
If it is determined that the currently considered TID queue is not marked (304-N), then the flowchart 300 continues to decision point 306 where it is determined whether the currently considered TID queue has packets to send. If it is determined that the currently considered TID queue has no packets to send (306-N), then the flowchart 300 continues to decision point 308 where it is determined whether any TID queue in the token bucket checking cycle has a marker. If it is determined that no TID queue in the token bucket checking cycle has a marker (308-N), then the flowchart 300 continues to module 310 where the currently considered TID queue is marked, to module 312 where the token bucket checking cycle cycles to the next TID queue, and returns to decision point 304 to continue as described previously for a next TID queue.
If, on the other hand, it is determined that a TID queue in the token bucket checking cycle has a marker (308-Y), then the flowchart continues to module 312 as just described (but skipping module 310). Thus, if a TID queue has no packets to send and no other TID queue has been marked, the TID queue is marked, but if the TID queue has no packets to send and some other TID queue has been marked, the currently considered TID queue is not marked. In the latter case, marking the currently considered TID queue would be redundant because if the token bucket checking cycle reaches the previously marked TID queue (which it will do before reaching the currently considered TID queue again), then a refresh cycle will start to refresh all TID queues, including the currently considered TID queue. In an alternative, the flowchart 300 could simply mark any TID queue that has no packets, regardless of the status of other TID queues. This has the advantage of requiring no status checking, but the disadvantage of unnecessarily marking a TID queue and needing to clear the mark during the refresh cycle. On the other hand, if a periodic refresh cycle is implemented in addition to the as-needed refresh cycle of the example of FIG. 3, it may or may not be desirable to mark any TID queue that has a token deficit and clear the marker when either the periodic or as-needed refresh cycle reaches the marked TID queue.
Referring once again to decision point 306, if it is determined that the currently considered TID queue has packets to send (306-Y), then the flowchart 300 continues to decision point 314 where it is determined whether the currently considered TID queue has a positive token balance (e.g., zero or a surplus). If it is determined that the currently considered TID queue does not have a positive token balance (314-N), then the flowchart 300 returns to module 310 and continues as described previously.
If, on the other hand, it is determined that the currently considered TID queue has a positive token balance (314-Y), then the flowchart 300 continues to module 316 with sending packets. In a specific implementation, packets can be sent for any token balance (even if the token balance is zero), and token costs for sending the packets can result in a token deficit corresponding to the size of the token cost over the token balance. Depending upon the implementation, the token cost of sending packets can be calculated in advance, determined as the packets are sent, or both (redundantly).
In the example of FIG. 3, the flowchart 300 continues to module 318 where a token cost for sending the packets is deducted from the token bucket balance. The determination of how many packets to send can be intermingled with the determination of token costs, and estimated token costs can be corrected later when actual token costs become known. For example, token costs can be deducted as packets are dequeued, based upon the size of the packets. When the token cost reaches a maximum allowed share in the token bucket checking cycle or when the token cost results in a token bucket deficit, no additional packets are dequeued for the currently considered TID queue in the current cycle.
In the example of FIG. 3, the flowchart 300 continues to decision point 320 where it is determined whether the currently considered TID queue still has tokens (after sending packets). If the currently considered TID queue does not still have tokens (320-N), then the flowchart 300 returns to decision point 308 and continues as described previously. If, on the other hand, the TID queue still has tokens (320-Y), then the flowchart 300 continues to decision point 322 where it is determined whether any TID queue in the token bucket checking cycle has a marker. If it is determined that no TID queue in the token bucket checking cycle has a marker (322-N), then the flowchart 300 returns to module 312 and continues as described previously.
If, on the other hand, it is determined that a TID queue in the token bucket checking cycle has a marker (322-Y), then the flowchart 300 continues to module 324 where the marker is removed, and returns to module 312 to continue as described previously. By removing the marker, the token bucket checking cycle will not enter an as-needed refresh cycle simply because it reaches a TID queue with a token deficit. Rather, the token bucket checking cycle will return to the currently considered TID queue to let the currently considered TID queue use up its positive token balance.
Referring once again to decision point 304, if it is determined that the currently considered TID queue is marked, then the flowchart 300 continues to module 326 where a refresh cycle is started. In a specific implementation, an increment value (number of tokens) is added to the token bucket associated with the currently considered TID queue. If the currently considered TID queue has a token deficit (which expected given the progress of the flowchart 300 to this point), the token balance after refresh will be smaller than the increment value.
In the example of FIG. 3, the flowchart 300 continues to module 328 where the marker is removed from the currently considered TID queue. Depending upon the implementation, it is at least theoretically possible for a refresh to be inadequate to eliminate the deficit entirely. In such a case, the logic of the flowchart 300 re-marks the currently considered TID queue (310). Alternatively, the marker could be left, rather than removed, at module 328.
In the example of FIG. 3, the flowchart 300 returns to decision point 306 to continue as described previously. After the refresh cycle has been started, after the flowchart 300 returns to module 312 until reaching the TID queue at which the refresh cycle started, the token bucket for the next TID queue can be incremented by the increment value. Alternatively, the refresh cycle can run independently of the token bucket checking cycle, refreshing token buckets at a different pace (e.g., faster, slower, or sometimes faster, sometimes slower). In a specific implementation, a periodic refresh cycle can be running alongside the refresh cycle that is triggered when the token bucket checking cycle returns to a marked queue. The periodic refresh cycle can “top off” token buckets that do not necessarily need additional tokens. If there is a periodic refresh cycle and an as-needed refresh cycle, the cycles can be referred to as such to distinguish; otherwise, context should dictate the type of refresh cycle that is used.
Referring once again to module 318, the flowchart 300 can continue along an alternative path to module 330 where actual token cost is calculated. The alternative path can be taken in parallel to other paths in the example of FIG. 3. The alternative path can be referred to as a token cost adjustment path (or cycle). In a wireless context, the token cost adjustment can be an airtime token cost adjustment. That is, the amount of airtime used is calculated and an actual token cost is determined in accordance with the calculation.
In the example of FIG. 3, on the token cost adjustment path, the flowchart 300 continues to module 332 where actual token cost is deducted from the relevant TID queue. (It may be noted that at a given time, it is not clear what TID queue is being considered in the token bucket checking cycle, but the token cost adjustment is for the TID queue that was currently being considered at module 318.)
In the example of FIG. 3, on the token cost adjustment path, the flowchart 300 continues to module 334 where estimated token cost is added to the relevant TID queue. In this way, the relevant token bucket from which an estimated token cost was previously deducted is adjusted after the fact to instead deduct the actual token cost. Obviously, the order of modules 332 and 334 are not particularly relevant and can be combined (e.g., by adding estimated token cost minus actual token cost to the relevant TID queue).
In the example of FIG. 3, on the token cost adjustment path, the flowchart 300 ends at module 336 where estimated token cost of future transmission is updated to reflect the actual token cost for the just-considered transmission. In this way, the estimated token cost deducted at (future) module 318 can use the latest transmission cost.
In a specific implementation, the token bucket checking cycle is not round-robin. FIG. 4 is intended to illustrate a token-weighted token bucket checking cycle. FIG. 4 depicts a flowchart 400 of an example of a token-weighted token bucket checking cycle. In the example of FIG. 4, the flowchart 400 starts at module 402 with initializing token buckets for TID queues to an initial value.
In the example of FIG. 4, the flowchart 400 continues to module 404 where a TID queue having a greatest token weight is identified. The identification may or may not entail sorting the TID queues by associated token weights. In this example, a token weight can be defined as a number of tokens in a token bucket associated with the TID queue. In a specific implementation, the token weight can be equal to the token balance associated with a TID queue, where a larger token balance is indicative of a greater number of tokens. If token balances are identical for two TID queues, weight can be determined arbitrarily, ordinally, randomly, or using some other function (e.g., a function that weights TID queues with smaller expected token costs greater than TID queues with larger expected token costs).
In the example of FIG. 4, the flowchart 400 continues to decision point 406 where it is determined whether the token weight of the identified TID queue is greater than a token balance threshold. The token balance threshold is a threshold at which it becomes time for a refresh cycle. If it is determined that the token weight of the identified TID queue is greater than a token balance threshold (406-Y), then the flowchart 400 continues to module 408 where packets from the identified TID queue are dequeued for transmission.
In the example of FIG. 4, the flowchart 400 continues to module 410 where the identified TID queue has an estimated packet transmission cost deducted from its associated token bucket. The estimated packet transmission cost can be based upon, for example, a last measured packet transmission cost, a weighted average of previously measured packet transmission costs (with the most recent being the most heavily weighted), or some other basis that is determined to be likely to provide a good estimate.
In the example of FIG. 4, the flowchart 400 returns to module 404 to continue as described previously.
Referring once again to decision point 406, if it is determined that the token weight of the identified TID queue is not greater than a token balance threshold, then the flowchart 400 continues to module 412 where each token bucket is incremented. The reason for the increment is that the TID queue with the greatest weight does not have what has been determined to be a sufficient token bucket balance. Following (or during) the refresh cycle, the token bucket checking cycle can continue as described previously. However, in order to minimize latency, an optional technique can be used as follows (the alternative would be for the flowchart to return to module 404 after module 412).
In the example of FIG. 400, the flowchart 400 continues to module 414 where a TID queue with a lowest estimated transmission cost is identified and returns to module 408 to continue as described previously (but with the identified queue being the TID queue with the lowest estimated transmission cost).
To this point, bucket depth has been treated as a static value, but in a specific implementation, the bucket depth has a dynamic value. Bucket depth defines how sensitive fairness can be implemented. FIG. 5 depicts a flowchart 500 of an example of a method for dynamically adjusting bucket depth. In the example of FIG. 5, the flowchart 500 starts at module 502 where token bucket depths for TID queues are set to an initial value. The initial value can be arbitrary, predetermined, based upon historical data, or established in some other manner.
In the example of FIG. 5, the flowchart 500 continues to module 504 where packets are processed for transmission. The manner in which packets are processed can be in accordance with techniques described previously in this paper and/or one or more of such techniques combined with known or convenient techniques.
In the example of FIG. 5, the flowchart 500 continues to module 506 where it is determined that a bucket depth reset threshold has been reached. The bucket depth reset threshold can be based upon time, number of cycles, network conditions, etc., and can differ depending upon the circumstances. An example of different threshold units is in an example where the bucket depth reset threshold is set to a single cycle of a token bucket checking cycle after the token bucket depths are initialized (e.g., at module 502), then based upon a period of time thereafter. An example of different threshold values is an example where the bucket depth reset threshold is set to one minute, but the period is reduced if there are a large number of wireless connections made over a period of time (in a wireless embodiment). Of course, the bucket depth reset threshold can also be consistent (e.g., the threshold can be reached every 60 seconds).
In the example of FIG. 5, the flowchart 500 continues to module 508 where a TID queue with a highest associated estimated transmission cost is identified. Slower stations will tend to have higher estimated transmission costs than faster stations. However, stations come and go in certain implementations, making the highest estimated transmission cost vary over time.
In the example of FIG. 5, the flowchart 500 continues to module 510 where bucket depths are set to a multiple of the highest estimated transmission cost. It has been found that a bucket depth of some size greater than the transmission cost is desirable. Accordingly, the multiple can be set to some relatively low integer value (e.g., 2). The multiple need not be adjusted, but if it were a variable, it could be adjusted for a number of reasons, including ensuring bucket depths do not drop too low, which could conceivably cause problems for a very slow station that connects to a wireless network that has only very fast stations.
As used herein, the term “embodiment” means an embodiment that serves to illustrate by way of example but not limitation. The techniques described in the preceding text and figures can be mixed and matched as circumstances demand to produce alternative embodiments.
US5471671 3 Nov 1993 28 Nov 1995 Motorola, Inc. Hanset for a multiple channel communication system and use thereof
US5697059 31 Oct 1996 9 Dic 1997 Airnet Communications Corp. System for dynamically allocating channels among base stations in a wireless communication system
US5956643 9 Mar 1995 21 Sep 1999 Lucent Technologies Inc. Apparatus and method for adaptive dynamic channel assignment in wireless communication networks
US6112092 18 Abr 1996 29 Ago 2000 Lucent Technologies Inc. Self-configurable channel assignment system and method
US6154655 5 Mar 1998 28 Nov 2000 Lucent Technologies Inc. Flexible channel allocation for a cellular system based on a hybrid measurement-based dynamic channel assignment and a reuse-distance criterion algorithm
US6201792 14 May 1998 13 Mar 2001 3Com Corporation Backpressure responsive multicast queue
US6314294 30 Dic 1998 6 Nov 2001 At&T Corp. Method for self-calibration of a wireless communication system
US6473413 22 Jun 1999 29 Oct 2002 Institute For Information Industry Method for inter-IP-domain roaming across wireless networks
US6519461 29 Oct 1999 11 Feb 2003 Telefonaktiebolaget Lm Ericsson (Publ) Channel-type switching from a common channel to a dedicated channel based on common channel load
US6628938 14 Ago 2000 30 Sep 2003 Koninklijke Philips Electronics N.V. Wireless system, a method of selecting an application while receiving application specific messages and user location method using user location awareness
US6865393 3 Mar 2000 8 Mar 2005 Motorola, Inc. Method and system for excess resource distribution in a communication system
US7002943 15 Oct 2004 21 Feb 2006 Airtight Networks, Inc. Method and system for monitoring a selected region of an airspace associated with local area networks of computing devices
US7057566 20 Ene 2004 6 Jun 2006 Cisco Technology, Inc. Flexible multichannel WLAN access point architecture
US7085224 14 Jun 2001 1 Ago 2006 Cisco Technology, Inc. Method and apparatus for fast failure detection in switched LAN networks
US7154874 14 Nov 2005 26 Dic 2006 Airtight Networks, Inc. Method and system for monitoring a selected region of an airspace associated with local area networks of computing devices
US7164667 28 Jun 2002 16 Ene 2007 Belair Networks Inc. Integrated wireless distribution and mesh backhaul networks
US7174170 10 Oct 2003 6 Feb 2007 Nortel Networks Limited Self-selection of radio frequency channels to reduce co-channel and adjacent channel interference in a wireless distributed network
US7181530 27 Jul 2001 20 Feb 2007 Cisco Technology, Inc. Rogue AP detection
US7216365 6 May 2005 8 May 2007 Airtight Networks, Inc. Automated sniffer apparatus and method for wireless local area network security
US7224697 4 Nov 2002 29 May 2007 Agere Systems Inc. Dynamic channel selector and method of selecting a channel in a wireless local area network
US7336670 24 Oct 2003 26 Feb 2008 Airespace, Inc. Discovery of rogue access point location in wireless network environments
US7339914 31 Ago 2004 4 Mar 2008 Airtight Networks, Inc. Automated sniffer apparatus and method for monitoring computer systems for unauthorized access
US7346338 4 Abr 2003 18 Mar 2008 Airespace, Inc. Wireless network system including integrated rogue access point detection
US7366894 27 Nov 2002 29 Abr 2008 Cisco Technology, Inc. Method and apparatus for dynamically securing voice and other delay-sensitive network traffic
US7512379 27 Oct 2005 31 Mar 2009 Hien Nguyen Wireless access point (AP) automatic channel selection
US7536723 31 Ago 2004 19 May 2009 Airtight Networks, Inc. Automated method and system for monitoring local area computer networks for unauthorized wireless access
US7562384 7 Mar 2003 14 Jul 2009 Cisco Technology, Inc. Method and apparatus for providing a secure name resolution service for network devices
US7656822 27 Oct 2004 2 Feb 2010 Sun Microsystems, Inc. Method and apparatus for decentralized device and service description and discovery
US7706789 31 Mar 2005 27 Abr 2010 Intel Corporation Techniques to manage roaming
US7751393 10 Sep 2008 6 Jul 2010 Airtight Networks, Inc. Method and system for detecting wireless access devices operably coupled to computer local area networks and related methods
US7768952 16 Ago 2007 3 Ago 2010 WI-FI Rail, Inc. System and method of wirelessly communicating with mobile devices
US7793104 14 Ene 2009 7 Sep 2010 Motorola, Inc. Security authentication and key management within an infrastructure-based wireless multi-hop network
US7844057 2 Jul 2007 30 Nov 2010 Cisco Technology, Inc. Roaming using reassociation
US7856209 30 Nov 2005 21 Dic 2010 Airtight Networks, Inc. Method and system for location estimation in wireless networks
US7921185 29 Mar 2006 5 Abr 2011 Dell Products L.P. System and method for managing switch and information handling system SAS protocol communication
US7949342 27 Sep 2004 24 May 2011 Interdigital Technology Corporation Radio resource management in wireless local area networks
US7961725 31 Jul 2007 14 Jun 2011 Symbol Technologies, Inc. Enterprise network architecture for implementing a virtual private network for wireless users by mapping wireless LANs to IP tunnels
US8000308 20 Oct 2008 16 Ago 2011 Cisco Technology, Inc. Containment of rogue systems in wireless network environments
US8219688 13 Ago 2008 10 Jul 2012 Huawei Technologies Co., Ltd. Method, apparatus and system for service selection, and client application server
US8249606 10 Feb 2009 21 Ago 2012 Optimi Corporation Frequency planning optimization for mobile communications
US8493918 25 Jul 2012 23 Jul 2013 Broadcom Corporation Communication system and method for discovering end-points that utilize a link layer connection in a wired/wireless local area network
US8824448 30 Jul 2010 2 Sep 2014 Avaya Inc. Method for enhancing redundancy in a wireless system using location attributes
US8948046 21 Sep 2007 3 Feb 2015 Aerohive Networks, Inc. Routing method and system for a wireless network
US9003527 26 Jun 2012 7 Abr 2015 Airtight Networks, Inc. Automated method and system for monitoring local area computer networks for unauthorized wireless access
US20010006508 27 Feb 2001 5 Jul 2001 Rajesh Pankaj System for allocating resources in a communication system
US20020012320 1 Dic 2000 31 Ene 2002 Ogier Richard G. Mobile ad hoc extensions for the internet
US20020021689 29 Dic 2000 21 Feb 2002 Robbins Barry R. Method and apparatus for transparent internet mobility management
US20020071422 23 Sep 1999 13 Jun 2002 Anthony D. Amicangioli Tagging for demultiplexing in a network traffic server
US20020091813 7 Nov 2001 11 Jul 2002 International Business Machines Corporation Enabling surveillance of network connected device
US20020116463 20 Feb 2001 22 Ago 2002 Hart Matthew Thomas Unwanted e-mail filtering
US20020128984 26 Feb 2002 12 Sep 2002 4Thpass Inc. Method and system for transmission-based billing of applications
US20030005100 28 Jun 2001 2 Ene 2003 Barnard John D. Discovery and management of network printers
US20030087629 27 Sep 2002 8 May 2003 Bluesocket, Inc. Method and system for managing data traffic in wireless networks
US20030104814 3 May 2002 5 Jun 2003 Docomo Communications Laboratories Usa Low latency mobile initiated tunneling handoff
US20030129988 9 Ene 2003 10 Jul 2003 Lee Sung-Won System and method for call admission for a mobile communication system
US20030145091 28 Ene 2002 31 Jul 2003 Telefonaktiebolaget L M Ericsson Access terminal profile in a data cellular network
US20030179742 29 Nov 2002 25 Sep 2003 Ogier Richard G. Method and apparatus for disseminating topology information and for discovering new neighboring nodes
US20040003285 28 Jun 2002 1 Ene 2004 Robert Whelan System and method for detecting unauthorized wireless access points
US20040013118 22 Jul 2002 22 Ene 2004 3Com Corporation System and method for GRE heartbeats
US20040022222 31 Jul 2002 5 Feb 2004 Allister Clisham Wireless metropolitan area network system and method
US20040064467 18 Dic 2000 1 Abr 2004 Tero Kola Method for scheduling of packet data and a packet data scheduler
US20040077341 2 Jul 2003 22 Abr 2004 Chandranmenon Girish P. Multi-interface mobility client
US20040103282 17 Abr 2003 27 May 2004 Robert Meier 802.11 Using a compressed reassociation exchange to facilitate fast handoff
US20040109466 31 Oct 2003 10 Jun 2004 Alcatel Method of relaying traffic from a source to a targeted destination in a communications network and corresponding equipment
US20040162037 18 Feb 2003 19 Ago 2004 Eran Shpak Multi-channel WLAN transceiver with antenna diversity
US20040185876 24 Feb 2004 23 Sep 2004 Computer Associates Think, Inc. Mobility management in wireless networks
US20040196977 2 Abr 2003 7 Oct 2004 Johnson Bruce L. Conveying wireless encryption keys upon client device connecting to network in non-wireless manner
US20040236939 27 Ene 2004 25 Nov 2004 Docomo Communications Laboratories Usa, Inc. Wireless network handoff key
US20040255028 30 May 2003 16 Dic 2004 Lucent Technologies Inc. Functional decomposition of a router to support virtual private network (VPN) services
US20050053003 9 Sep 2003 10 Mar 2005 Harris Corporation Mobile ad hoc network (MANET) with quality-of-service (QoS) protocol hierarchy and related methods
US20050074015 24 Nov 2004 7 Abr 2005 Tropos Networks, Inc. Method of subnet roaming within a network
US20050099983 5 Nov 2004 12 May 2005 Nobuyuki Nakamura Communication terminal and communication network
US20050122946 18 Nov 2004 9 Jun 2005 Won Chan Y. DHCP pool sharing mechanism in mobile environment
US20050154774 26 Mar 2003 14 Jul 2005 Raffaele Giaffreda Method of data transfer in mobile and fixed telecommunications systems
US20050207417 28 Dic 2004 22 Sep 2005 Masayuki Ogawa Method and apparatus for multicast packet readout control
US20050262266 20 Jun 2002 24 Nov 2005 Niclas Wiberg Apparatus and method for resource allocation
US20050266848 6 May 2005 1 Dic 2005 Lg Electronics Inc. Performing handover by deferring IP address establishment
US20060013179 12 Jul 2005 19 Ene 2006 Iwatsu Electric Co., Ltd. Channel decision system for access point
US20060026289 28 Feb 2005 2 Feb 2006 Microsoft Corporation System, method and user interface for network status reporting
US20060062250 29 Ago 2005 23 Mar 2006 Payne William A Iii Method for wireless access system supporting multiple frame types
US20060107050 21 Ene 2005 18 May 2006 Chih-Heng Shih Method used by an access point of a wireless lan and related apparatus
US20060117018 30 Nov 2004 1 Jun 2006 Microsoft Corporation Method and system for caching remote files locally
US20060140123 29 Dic 2004 29 Jun 2006 Intel Corporation Methods and apparatus for distributing link-state information associated with a wireless mesh network
US20060146748 16 Jun 2004 6 Jul 2006 Matsushita Electric Industrical Co., Ltd. Mobile terminal device and hand-off method thereof
US20060146846 5 Ene 2005 6 Jul 2006 Intel Corporation Methods and apparatus for providing a transparent bridge associated with a wireless mesh network
US20060165015 23 Dic 2005 27 Jul 2006 Lightwaves Systems, Inc. Method for routing data packets using an IP address based on geo position
US20060187949 8 Feb 2006 24 Ago 2006 Ganesh Seshan Queuing and scheduling architecture for a unified access device supporting wired and wireless clients
US20060221920 5 Abr 2005 5 Oct 2006 Toshiba America Research, Inc. Beamforming and distributed opportunistic scheduling in wireless networks
US20060233128 15 Abr 2005 19 Oct 2006 Kapil Sood Apparatus, system and method capable of pre-allocating and communicating IP address information during wireless communication
US20060234701 23 Nov 2005 19 Oct 2006 Azalea Networks Method and system for distributed roaming services for mobile users on wireless mesh networks
US20060245442 29 Abr 2005 2 Nov 2006 Tropos Networks, Inc. Wireless mesh network verification
US20060268802 8 May 2006 30 Nov 2006 Nokia Corporation Mechanism to enable discovery of link/network features in WLAN networks
US20060294246 23 Jun 2005 28 Dic 2006 Cisco Technology, Inc. Element designations for network optimization
US20070004394 30 Jun 2005 4 Ene 2007 Michael Chu Assessing wireless network quality
US20070010231 6 Jul 2005 11 Ene 2007 Xiaohui Du Connection and data application billing
US20070025274 27 Feb 2006 1 Feb 2007 Shahriar Rahman Hybrid distance vector protocol for wireless mesh networks
US20070025298 31 Jul 2006 1 Feb 2007 Samsung Electronics Co., Ltd. Method and system for providing roaming service in mobile communication system
US20070077937 26 Ago 2005 5 Abr 2007 Ramakrishnan Kajamalai G Method and system for performing call admission control in a communication system
US20070078663 3 Mar 2003 5 Abr 2007 Grace Ryan T Method and instrument for proposing marriage to an individual
US20070082656 11 Oct 2005 12 Abr 2007 Cisco Technology, Inc. Method and system for filtered pre-authentication and roaming
US20070091859 26 Oct 2005 26 Abr 2007 Aseem Sethi System and method for association of mobile units with an access point
US20070115847 18 Nov 2005 24 May 2007 Strutt Guenael J Method and apparatus to estimate link performance in a packetized communication network
US20070116011 10 Oct 2006 24 May 2007 Han-Na Lim Method and apparatus for communications of user equipment using internet protocol address in a mobile communication system
US20070121947 30 Nov 2005 31 May 2007 Kapil Sood Methods and apparatus for providing a key management system for wireless communication networks
US20070140191 31 Mar 2006 21 Jun 2007 Fujitsu Limited Wireless LAN device and communication mode switching method
US20070153741 28 Dic 2006 5 Jul 2007 Colubris Networks, Inc. Seamless roaming across wireless subnets using source address forwarding
US20070156804 5 Ene 2007 5 Jul 2007 Fuze Networks System and method for a virtual mobile network supporting dynamic personal virtual mobile network with multimedia service orchestration
US20070171885 2 Abr 2007 26 Jul 2007 AirTight Networks, Inc.(F/K/A Wibhu Technologies, Inc.) Automated sniffer apparatus and method for wireless local area network security
US20070192862 21 Dic 2004 16 Ago 2007 Vincent Vermeulen Automated containment of network intruder
US20070249324 18 Abr 2007 25 Oct 2007 Tyan-Shu Jou Dynamic authentication in secured wireless networks
US20070263532 10 May 2006 15 Nov 2007 Sina Mirtorabi Backup path convergence in the APS environment
US20070280481 6 Jun 2006 6 Dic 2007 Eastlake Donald E Method and apparatus for multiple pre-shared key authorization
US20070288997 2 Jul 2007 13 Dic 2007 Robert Meier Roaming using reassociation
US20080002642 30 Jun 2006 3 Ene 2008 Udayan Borkar Techniques for peer wireless switch discovery within a mobility domain
US20080022392 5 Jul 2006 24 Ene 2008 Cisco Technology, Inc. Resolution of attribute overlap on authentication, authorization, and accounting servers
US20080037552 11 Ago 2006 14 Feb 2008 Latitude Broadband, Inc. Methods And Systems For Providing Quality Of Service In Packet-Based Core Transport Networks
US20080080369 31 Ago 2007 3 Abr 2008 Fujitsu Limited Relay apparatus, relay method, and relay program
US20080080377 27 Jul 2007 3 Abr 2008 Fujitsu Limited Best-effort bandwidth allocating method and device
US20080090575 15 Ene 2007 17 Abr 2008 Oz Barak WiMAX ACCESS POINT NETWORK WITH BACKHAUL TECHNOLOGY
US20080095094 11 Oct 2007 24 Abr 2008 Takaharu Innami Mobile communication system, base station device and method of estimating number of uplink packet retransmissions thereof
US20080107027 3 Abr 2007 8 May 2008 Nortel Networks Limited Engineered paths in a link state protocol controlled Ethernet network
US20080109879 8 Ene 2008 8 May 2008 Airtight Networks, Inc. Automated sniffer apparatus and method for monitoring computer systems for unauthorized access
US20080130495 5 Dic 2006 5 Jun 2008 Latitude Broadband, Inc. Methods And Systems For Dynamic Bandwidth Management For Quality Of Service In IP Core And Access Networks
US20080146240 12 Dic 2007 19 Jun 2008 Colubris Networks, Inc. Call admission control for Wi-Fi
US20080170527 11 Ene 2007 17 Jul 2008 Motorola, Inc. Changing access point (ap) device type based on connectivity to a network
US20080207215 21 Feb 2008 28 Ago 2008 Stmicroelectronics, Inc. Fair channel use in a wireless area network
US20080225857 13 Mar 2007 18 Sep 2008 Lange Andrew S Low-impact call connection request denial
US20080229095 24 Abr 2008 18 Sep 2008 Ramesh Kalimuthu Method and apparatus for dynamically securing voice and other delay-sensitive network traffic
US20080240128 30 Mar 2007 2 Oct 2008 Elrod Craig T VoIP Security
US20080253370 21 Feb 2008 16 Oct 2008 Con Cremin Maintenance of bandwidth allocation for traffic including multicasts
US20080273520 30 Abr 2008 6 Nov 2008 Samsung Electronics Co. Ltd. NETWORK ARCHITECTURE FOR DYNAMICALLY SETTING END-TO-END QUALITY OF SERVICE (QoS) IN A BROADBAND WIRELESS COMMUNICATION SYSTEM
US20080279161 9 May 2007 13 Nov 2008 Vlad Stirbu Modifying remote service discovery based on presence
US20090019521 12 Jul 2007 15 Ene 2009 Hewlett-Packard Development Company, L.P. Controlling access privileges in a wireless domain
US20090028052 27 Jul 2007 29 Ene 2009 General Instrument Corporation Method and Apparatus for Optimizing Home Network Interface Selection In Home Networking Applications
US20090040989 19 May 2008 12 Feb 2009 Mesh Dynamics, Inc. High performance wireless networks using distributed control
US20090043901 9 Ago 2007 12 Feb 2009 Lucent Technologies Inc. Bootstrapping Method For Setting Up A Security Association
US20090082025 17 Sep 2008 26 Mar 2009 Qualcomm Incorporated Mobility management of multiple clusters within a wireless communications network
US20090088152 28 Sep 2007 2 Abr 2009 Mark Orlassino System and Method for Adaptive/Predictive Location-Based Roaming Optimization
US20090097436 12 Oct 2007 16 Abr 2009 Subramanian Vasudevan Methods for access control in femto system
US20090111468 29 Oct 2007 30 Abr 2009 Burgess John K Hand-off trigger at access technology borders
US20090113018 17 Jul 2008 30 Abr 2009 Allan Thomson Mobility service clustering using network service segments
US20090144740 30 Nov 2007 4 Jun 2009 Lucent Technologies Inc. Application-based enhancement to inter-user priority services for public safety market
US20090168645 30 Jun 2006 2 Jul 2009 Tester Walter S Automated Network Congestion and Trouble Locator and Corrector
US20090172151 29 Dic 2007 2 Jul 2009 Cisco Technology, Inc. Dynamic network configuration
US20090239531 24 Mar 2008 24 Sep 2009 Flemming Andreasen Policy for a Roaming Terminal Based on a Home Internet Protocol (IP) Address
US20090240789 24 Mar 2008 24 Sep 2009 Sankarlingam Dandabany Method and system for removing a tunnel between portal points
US20090247170 23 Mar 2009 1 Oct 2009 Qualcomm Incorporated Power efficient small base station scanning and acquisition
US20090310557 21 Ago 2009 17 Dic 2009 Fujitsu Limited Communication resource management device
US20100046368 * 21 Ago 2008 25 Feb 2010 Gideon Kaempfer System and methods for distributed quality of service enforcement
US20100057930 26 Ago 2008 4 Mar 2010 Dehaan Michael Paul Methods and systems for automatically locating a provisioning server
US20100112540 31 Jul 2009 6 May 2010 Digital Millennial Consulting Llc System and method of education utilizing mobile devices
US20100115576 31 Oct 2008 6 May 2010 Echostar Technologies L.L.C. Firmware recovery of wireless devices
US20100132040 7 Abr 2009 27 May 2010 Airtight Networks, Inc. Automated method and system for monitoring local area computer networks for unauthorized wireless access
US20100208614 19 Oct 2007 19 Ago 2010 Harmatos Janos Method and arrangement for scheduling data packets in a communication network system
US20100228843 16 Ago 2007 9 Sep 2010 Posdata Co. ltd Element management system in wireless communication network
US20100240313 22 Jun 2007 23 Sep 2010 Nec Corporation Wireless communication device and method for switching modulation system thereof
US20100254316 3 Jun 2010 7 Oct 2010 Olsonet Communications Corporation Method for Routing Ad-Hoc Signals
US20100260091 13 Abr 2010 14 Oct 2010 Lg Electronics Inc. Method and apparatus for processing multicast frame
US20100290397 4 May 2010 18 Nov 2010 Avaya Inc. Location based load balancing of wireless access points and wireless switches
US20100304738 24 Jul 2009 2 Dic 2010 Research In Motion Limited Signal Quality Determination Methods And Apparatus Suitable For Use In WLAN-To-WWAN Transitioning
US20100311420 5 Jun 2009 9 Dic 2010 Reza Ashrafur Md Apparatus and Method for Improved Idle State Handoff
US20100322217 17 Jun 2010 23 Dic 2010 Electronics And Telecommunications Research Institute Method for supporting idle mode in wireless local area network system
US20100325720 10 Jun 2010 23 Dic 2010 Craig Stephen Etchegoyen System and Method for Monitoring Attempted Network Intrusions
US20110004913 31 Jul 2007 6 Ene 2011 Symbol Technologies, Inc. Architecture for seamless enforcement of security policies when roaming across ip subnets in ieee 802.11 wireless networks
US20110040867 12 Ago 2009 17 Feb 2011 Cellco Partnership D/B/A Verizon Wireless Mechanism to detect restricted access via internet hotspot
US20110051677 13 Ene 2009 3 Mar 2011 Firetide, Inc. Channel assignment for wireless access networks
US20110055326 26 Ago 2009 3 Mar 2011 Qualcomm Incorporated Methods and systems for service discovery management in peer-to-peer networks
US20110055928 31 Ago 2009 3 Mar 2011 Verizon Patent And Licensing Inc. Method and system for detecting unauthorized wireless devices
US20110058524 10 Sep 2009 10 Mar 2011 Brian Hart Distributed channel assignment
US20110064065 19 Nov 2010 17 Mar 2011 Tetsu Nakajima Wireless communication apparatus and method
US20110182225 27 Ene 2010 28 Jul 2011 Qualcomm Incorporated Setting up a multicast group communication session within a wireless communications system
US20110185231 27 Ene 2010 28 Jul 2011 Filippo Balestrieri Software application testing
US20110258641 20 Abr 2010 20 Oct 2011 International Business Machines Corporation Remote Adapter Configuration
US20120014386 29 Jun 2011 19 Ene 2012 Futurewei Technologies, Inc. Delegate Gateways and Proxy for Target Hosts in Large Layer 2 and Address Resolution with Duplicated Internet Protocol Addresses
US20120290650 11 May 2011 15 Nov 2012 Futurewei Technologies, Inc. System and Method for Peer to Peer Communications in Cellular Communications Systems
US20130003729 3 Feb 2012 3 Ene 2013 Brocade Communications Systems, Inc. Clearing forwarding entries dynamically and ensuring consistency of tables across ethernet fabric switch
US20130003739 20 Mar 2012 3 Ene 2013 Brocade Communications Systems, Inc. Scalable mac address distribution in an ethernet fabric switch
US20130028158 27 Jul 2011 31 Ene 2013 Cisco Technology, Inc. Transmit Power Control Maximizing Coverage At A Minimum Interference
US20130059570 19 Jul 2012 7 Mar 2013 Fujitsu Limited Mobile terminal device, communication system, communication program, and control method
US20130086403 30 Sep 2011 4 Abr 2013 Nathan Stanley Jenne Method of reducing power consumption in a network
US20130103833 30 Jun 2011 25 Abr 2013 British Telecommunications Public Limited Company Method and apparatus for a mobile node to connect different access routers while maintaining a consistent network address
US20140269327 18 Mar 2013 18 Sep 2014 John C. Fulknier Mobile network operating method
US20140298467 17 Jun 2014 2 Oct 2014 Airtight Networks, Inc. Automated sniffer apparatus and method for monitoring computer systems for unauthorized access
US20150120864 30 Oct 2013 30 Abr 2015 Aruba Networks, Inc. Network device workload balancing
EP0940999A2 23 Feb 1999 8 Sep 1999 Lucent Technologies Inc. Cost-function-based dynamic channel assignment for a cellular system
EP1490773B1 20 Nov 2002 9 Ene 2013 Lenovo (Singapore) Pte. Ltd. Methods apparatus and program products for wireless access points
EP1732276B1 5 Jun 2006 5 Ago 2015 Samsung Electronics Co., Ltd. Method and apparatus for allocating a channel to a wireless interface of a node in a wireless network
EP1771026A1 26 Sep 2006 4 Abr 2007 Robert Bosch GmbH Method and system for providing interference avoidance in wireless systems
WO2000059251A1 7 Feb 2000 5 Oct 2000 Siemens Information And Communication Networks, Inc. Radio communications systems
WO2004042971A1 27 Oct 2003 21 May 2004 Telcordia Technologies, Inc. Method and system for real time cellular network configuration
WO2006129287A1 1 Jun 2006 7 Dic 2006 Koninklijke Philips Electronics N.V. Method and devices for wireless network access management
WO2009141016A1 4 Sep 2008 26 Nov 2009 Telefonaktiebolaget Lm Ericsson (Publ) Partitioning entity and method for partitioning capacity
1 Chirumamilla, Mohan K. et al., "Agent Based Intrustion Detection and Response System for Wireless LANs," CSE Conference and Workshop Papers, Paper 64, Jan. 1, 2003.
2 Clausen, T., et al., "Optimized Link State Routing Protocol (OLSR)," Network Working Group, pp. 1-71, Oct. 2003.
3 Craiger, J. Philip, "802.11, 802.1x, and Wireless Security," SANS Institute InfoSec Reading Room, Jun. 23, 2002.
4 European Patent Application No. 11823931.8, Search Report mailed Aug. 29, 2016.
5 European Patent Application No. 12879114.2, Search Report mailed Jan. 21, 2016.
6 Finlayson, Ross et al., "A Reverse Address Resolution Protocol," Nework Working Group, Request for Comments: 903 (RFC 903), Jun. 1984.
7 He, Changhua et al., "Analysis of the 802.11i 4-Way Handshake," Proceedings of the 3rd ACM Workshop on Wireless Security, pp. 43-50, Oct. 2004.
8 International Application No. PCT/US2008/061674, International Search Report and Written Opinion mailed Oct. 14, 2008.
9 International Application No. PCT/US2011/047591, International Search Report and Written Opinion mailed Dec. 19, 2011.
10 International Application No. PCT/US2012/059093, International Search Report and Written Opinion mailed Jan. 4, 2013.
11 Lee, Jae Woo et al, "z2z: Discovering Zeroconf Services Beyond Local Link," 2007 IEEE Globecom Workshops, pp. 1-7, Nov. 26, 2007.
12 Nu, Haitao et al., "Layer 2.5 SoftMAC: End-System Based Media Streaming Support on Home Networks," IEEE Global Telecommunications Conference (GLOBECOM '05), vol. 1, pp. 235-239, Nov. 2005.
13 Perkins, C., et al., "Ad hoc On-Demand Distance Vector (AODV) Routing," Network Working Group, pp. 1-35, Oct. 2003.
Clasificación internacional H04L12/823, H04W28/14, H04L29/06, H04L12/873, H04L12/835, H04L12/819, H04L12/801, H04L12/931, H04L12/867, H04L12/863, H04L12/18, H04W4/06
Clasificación cooperativa H04L47/6295, H04L47/15, H04L12/1886, H04L12/18, H04W28/0268, H04L47/527, H04L69/08, H04L49/201, H04L65/80, H04W28/14, H04L47/32, H04L47/215, H04W4/06, H04L47/30, H04L65/4076, H04L47/629, H04L47/621, H04L12/1881, H04L47/6215
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LIU, LIWU;ZENG, JIANLIN;REEL/FRAME:035188/0448