Quality of service based media access control for mobile ad hoc networks

[0001] 1. Field of the Invention

[0002] The present invention relates generally to networks and, more particularly, to quality of service, contention-based media access control for mobile ad hoc networks.

[0003] 2. Description of Related Art

[0004] The use of ad hoc wireless networks has increased in recent years. An ad hoc wireless network typically includes several wireless, usually mobile, nodes. In such a network, each of the nodes may be equipped with a radio that allows the node to communicate with other nodes to form a network. The nodes typically include a media access controller (MAC) that determines when data can be sent via radio waves to another node. The MAC algorithm that determines the appropriate times to send data is often very complex.

[0005] MAC algorithms generally fall into two broad categories: centralized and decentralized. In a mobile ad hoc environment, the infrastructure associated with the network is not guaranteed. Therefore, decentralized algorithms are typically used. Within the decentralized category, there are two general types of MAC algorithms: schedule-based and contention-based.

[0006] Schedule-based algorithms are time-oriented techniques in which each node knows when it is time to transmit. This requires time synchronization and decentralized coordination throughout the network to ensure that time slot information is consistent across the network. This is cumbersome and requires considerable overhead at the MAC layer in order to operate properly. Such a technique is also sub-optimal for bursty data.

[0007] Contention-based algorithms are channel-oriented techniques in which each node senses the state of the channel. In this technique, a node waits for the channel to be sensed as clear and then transmits its data. This technique may be optimal for bursty data, but is sub-optimal for quality of service (QoS) based data.

[0008] Another problem in conventional ad hoc networks is that nodes typically have equal access to the shared communication medium. This causes problems when a node wishes to transmit high priority data and is unable to seize the shared communication medium.

[0009] Therefore, a need exists for systems and methods that enable nodes to perform QoS, contention-based media access control in a wireless network that efficiently supports both bursty and non-bursty traffic. A need also exists for systems and methods that enable nodes to gain access to a shared communication medium based on data priority.

[0010] Systems and methods consistent with the present invention address these and other needs by using a manager node that generates a QoS polling cycle in response to QoS-based requests for network access. When a QoS-based request can be fulfilled, the polling cycle reserves a time slot for the requesting node to transmit data. Systems and methods consistent with the present invention also provide a mechanism for prioritized access to the shared communication medium. Nodes with higher priority data are given a greater probability of being able to transmit data before nodes with lower priority data by adjusting their respective contention windows based on the type of traffic.

[0011] In accordance with the principles of the invention as embodied and broadly described herein, a method is provided that includes generating a request at a first node, where the request includes information indicating that the first node requires a QoS link to a second node. The method also includes transmitting the request from the first node and receiving the request at a third node, where the third node represents a manager node. The method further includes determining, by the third node, whether the QoS link from the first node to the second node can be supported and sending an accept message from the third node to the first node when the QoS link can be supported.

[0012] In another implementation consistent with the present invention, a first node includes a receiver configured to receive a request from a second node, the request including information indicating that the second node requires a QoS link to a third node. The first node also includes a processing device configured to determine whether the QoS link from the second node to the third node can be supported, generate a polling cycle, and reserve a time slot for the second node in the polling cycle when the QoS link can be supported. The first node further includes a transmitter configured to transmit an accept message to the second node when the QoS link can be supported.

[0013] In still another implementation consistent with the present invention, a computer-readable medium having stored sequences of instructions is provided. The instructions cause a processor to generate a request indicating that a first node requires a QoS link to a second node, where the first node is associated with the processor. The instructions also cause the processor to transmit the request to a third node, the third node representing a manager node for a number of nodes including the first node. The instructions further cause the processor to receive at least one of an accept message and a deny message from the third node, the accept message indicating that the QoS link can be supported and the deny message indicating that the QoS message cannot be supported.

[0014] In a further implementation consistent with the present invention, a method for accessing a shared communication medium includes broadcasting a message from a first node to other nodes via the shared communication medium. The message identifies a link that the first node wishes to establish with a second node and includes a priority associated with the link. The method also includes receiving the message at each of the other nodes. The method further includes adjusting, by the first node, a contention window interval based on the priority included in the message.

[0015] In still another implementation consistent with the present invention, a computer-readable medium having stored sequences of instructions is provided. The instructions cause a processor to generate a request, the request indicating that a first node wishes to establish a link over a shared communication medium with a second node. The processor is associated with the first node and the request includes a priority associated with the link. The instructions also cause the processor to adjust a contention window interval based on the priority included in the request. The instructions further cause the processor to broadcast the request to a number of nodes including the second node.

[0016] In yet another implementation of the present invention, a first node includes a receiver configured to receive a broadcast message from a second node. The first node also includes a processing device configured to determine that the broadcast message indicates that the second node wishes to establish a link over a shared communication medium. The processing device is also configured to identify a priority associated with the link and adjust a contention window interval based on the priority.

[0023] The following detailed description of the invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and equivalents.

[0024] Systems and methods consistent with the present invention perform contention-based media access control in ad hoc wireless networks by allowing nodes to transmit a QoS request to a manager node. When the request is granted, the QoS manager may reserve a slot in a polling cycle for the requesting node. Systems and methods consistent with the present invention may also perform prioritized media access control in which higher priority data is more likely to get on the channel than lower priority data. This enables an ad hoc wireless network to transmit data through the network in a more efficient manner with less contention problems.

[0025] FIG. 1 is a diagram of an exemplary network 100 in which systems and methods consistent with the present invention may be implemented. Each of the circles in FIG. 1 represents a node and each of the nodes may communicate with neighboring nodes via radio frequency (RF) communication paths or links. The solid lines connecting the nodes represent “neighbor relations” between nodes (i.e., a line represents a possible path by which data messages can flow between nodes in network 100). The neighbor relations may be formed using, for example, conventional beaconing techniques.

[0026] Network 100 includes nodes 101–115 organized in a hierarchical fashion. For example, nodes 105, 110 and 115 may function as QoS managers in network 100, as described in more detail below. More specifically, node 105 may function as a QoS manager for nodes 101–104, node 110 may function as a QoS manager for nodes 106–109 and node 115 may function as a QoS manager for nodes 111–114, as indicated by the dotted lines in FIG. 1.

[0027] The QoS manager nodes 105, 110 and 115 may communicate with nodes 101–104, 106–109 and 111–114, respectively, and vice versa, as described in more detail below. It should be noted that nodes 105, 110 and 115 are shown in FIG. 1 as having neighbor relations with their respective subordinate nodes 101–104, 106–109 and 111–114, as represented by the dashed lines.

[0028] Nodes 105, 110 and 115 may also communicate with each to form a backbone in network 100 and may represent gateways in network 100. Similarly, nodes 101–104, 106–109 and 111–114 are illustrated as being neighbors in network 100 (i.e., these nodes have formed neighbor relations using, for example, beaconing techniques). The exemplary neighbor relations shown in FIG. 1 are for simplicity. It should be understood that other neighbor relations may be formed in network 100.

[0029] FIG. 2 is a diagram of an exemplary node of FIG. 1, such as node 105, according to an implementation consistent with the present invention. Node 105 may include a processor 210, a random access memory (RAM) 220, a read only memory (ROM) 230, a transceiver 240, an RF modem 250, a network interface 260 and an antenna 270. These components may be connected via one or more buses, illustrated as bus 280 for simplicity. Nodes 101–104 and 106–115 may be configured in a similar manner.

[0030] Processor 210 may include any type of conventional processor or microprocessor that interprets and executes instructions. RAM 220 may include a conventional RAM or another type of dynamic storage device that stores information and instructions for execution by processor 210. ROM 230 may include a conventional ROM device or another type of static storage device that stores static information and instructions for use by processor 210. Instructions used by the processor 210 may also, or alternatively, be stored in another type of computer-readable medium. A computer-readable medium includes one or more memory devices and/or carrier waves.

[0031] Transceiver 240 may include conventional components for transmitting and receiving data. For example, transceiver 240 may include one or more conventional transceivers for transmitting and receiving RF data via antenna 270. In other implementations, transceiver 240 may be configured as separate transmit and receive modules.

[0032] RF modem 250 may include one or more conventional modems that convert analog signals to digital signals, and vice versa, for communicating with other devices in node 105, such as processor 210 and transceiver 240. Transceiver 240 and RF modem 250 form a wireless network interface that operate under the control of processor 210 for transmitting and receiving data packets via antenna 270.

[0033] Network interface 260 may include an interface that allows node 105 to be coupled to an external network. For example, network interface 260 may include a serial line interface, an Ethernet interface, an asynchronous transfer mode (ATM) network interface, an interface to a local area network (LAN), etc.

[0034] Antenna 270 may each include one or more conventional antennas capable of transmitting and receiving RF signals. In accordance with an exemplary implementation, antenna 270 may be an omni-directional antenna or a directional antenna.

[0035] One skilled in the art would recognize that node 105 may be configured in a number of other ways and may include other components. For example, node 105 may include a different number of antennas and transceivers. In addition, node 105 may include a power supply, such as a battery, fuel cell or the like, for providing power to the components of the node 105. In some implementations, the power supply includes a recharging mechanism to permit the battery to be recharged using, for example, solar power techniques.

[0036] Node 105, consistent with the present invention, controls access to a wireless communication channel in response to processor 210 executing sequences of instructions contained in a computer-readable medium, such as RAM 220. Such instructions may be read into RAM 220 from another computer-readable medium, such as ROM 230 or an external data storage device (not shown) via a communication interface, such as network interface 260.

[0037] Execution of the sequences of instructions causes processor 210 to perform the acts that will be described hereafter. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement aspects of the present invention. For example, in alternative embodiments, the processor 210 and/or other components of node 105 may be implemented as an application specific integrated circuit (ASIC), a number of field programmable gate arrays (FPGAs) or one or more digital signal processors (DSPs). Thus, the present invention is not limited to any specific combination of hardware circuitry and software.

[0038] FIG. 3 is a flow diagram of processing by nodes in network 100 in an exemplary implementation consistent with the present invention. Processing may begin when the nodes in network 100 power up and form neighbor relations (act 310). As described previously, nodes in network 100 may perform neighbor discovery using beaconing to detect their neighboring nodes. Assume that nodes 105, 110 and 115 in network 100 are configured to act as QoS managers in network 100. For example, nodes 105, 110 and 115 may include more radios (i.e., transceivers 240) and antennas 270 or better radios/antennas than the other nodes in network 100 that enable them to act as QoS managers. Alternatively, the QoS managers may be assigned based on degree or connectivity of the nodes. That is, a node that effectively acts as a gateway to other nodes may be assigned to be the QoS manager. For example, nodes 105, 110 and 115 effectively act as gateways for nodes 101–104, 106–109 and 111–115, respectively, as shown in FIG. 1, and may be assigned to be the QoS managers. In any event, nodes 105, 110 and 115 may transmit beacon messages to the other nodes indicating that they will act as QoS managers for QoS traffic.

[0039] Assume that a node, such as node 101, wishes to establish a QoS link with another node (i.e., node 101 wants to send QoS-based data to another node). A QoS link requires that the communication channel between the sending and destination nodes meets certain throughput requirements. Such throughput requirements may be specified in a QoS request message. Node 101 may send a QoS request to its QoS manager (act 320). In the configuration illustrated in FIG. 1, node 105 acts as the QoS manager for node 101 and, therefore, node 101 sends the QoS request to node 105. Node 105 (also referred to as QoS manager 105) determines whether it can support this QoS link (act 330).

[0040] For example, the QoS request from node 101 may indicate that a particular amount of bandwidth associated with a voice call is needed. In this case, the QoS manager 105 may determine whether it can support the requested bandwidth. If the QoS manager 105 cannot support the request, QoS manager 105 sends a deny message to the requesting node, i.e., node 101 (act 340). If, however, QoS manager 105 can support the QoS link and QoS manager 105 is not the destination node for the QoS data, QoS manager 105 sends a request to the next node to determine whether the next node can support the QoS link (act 350). The next node may represent the destination node or the next hop in the path to the destination node.

[0041] For example, if the destination node for the QoS-based data is node 103, node 105 sends a request to node 103 to determine if node 103 can support the QoS link. If, however, the destination node is node 108, node 105 may forward the request to node 110, the QoS manager for node 108. Alternatively, node 105 may forward the request directly to node 108, if a neighbor relation has been formed between nodes 105 and 108.

[0042] In either case, the next node may then determine whether it can support the QoS link (act 360). If the next node cannot support the QoS link, it sends a deny message to QoS manager 105 (act 370). In addition, if the next node is not the destination node, the next node forwards the QoS request to the succeeding next node in the data path until the destination node is reached. For example, in the scenario above in which node 108 is the destination node, node 105 may transmit the request to node 110 and node 110 may transmit the request to node 108. Node 108 may then determine whether it can support the QoS link.

[0043] In summary, if any of the hops, up to and including the destination node, cannot support the QoS link, that node sends a deny message to the previous hop until it reaches the QoS manager 105 associated with the original requesting node 101. The QoS manager 105 may then send a deny message to node 101 (act 340). If the next node and all the nodes up through the destination node can support the QoS link, the QoS manager 105 receives an accept indication (act 380). In an exemplary implementation, each node in the path from the destination node to QoS manager 105 may transmit an accept indication to the previous node in the path until the accept indication reaches QoS manager 105. QoS manager 105 may then generate and transmit an accept message to the requesting node, i.e., node 101 (act 380).

[0044] Alternatively, if QoS manager 105 is the destination node and QoS manager 105 can support the QoS link (act 330), QoS manager 105 transmits an accept message to node 101, bypassing acts 340–370, as indicated by the dashed line in FIG. 3 (act 380). It should also be noted that if the destination node is a node 1-hop from requesting node 101 (e.g., node 102), the QoS manager 105 may merely have to forward the QoS request to the destination node to determine whether that node can support the QoS link. That is, the QoS manager 105 may not be included in the data path for the QoS-based data in this case, as described in more detail below, and therefore, may not have to support the QoS link.

[0045] After QoS manager 105 determines that the QoS link can be supported, the QoS manager 105 reserves a time slot for the QoS link in a QoS polling cycle (act 390). FIGS. 4A–4D illustrate exemplary timing diagrams associated with transmitting data in network 100, consistent with the present invention, which includes a QoS period and a distributed control function (DCF) period.

[0046] Referring to FIG. 4A, a QoS repetition interval 400 includes QoS period 410 and DCF period 420, which may be repeated over time. Each QoS manager controls the QoS period 410 based on requests it receives from its subordinate nodes and, possibly, other neighboring nodes. For example, QoS manager 105 controls QoS period 410 based on requests received from nodes 101–104. QoS manager 105 may alter the QoS period 410 to include additional polling intervals when a request is made and the corresponding QoS link can be supported, as described above in relation to FIG. 3. It should also be understood that each of the QoS managers 105, 110 and 115 may have a different QoS repetition interval, based on the particular requirements associated with its corresponding subordinate nodes.

[0047] FIG. 4B illustrates an exemplary QoS period 410 in more detail. Referring to FIG. 4B, the QoS period 410 includes a beaconing interval 411, two polling intervals 412 and 414 and two data sending intervals 413 and 415. The beaconing interval 411 may represent the period of time in which QoS manager 105 broadcasts a beacon to nodes 101–104 to inform these nodes that it will act as QoS manager. The beacon may also be received by other nodes in network 100, such as nodes 110 and 115.

[0048] The first polling interval 412 may represent a polling interval reserved for a node that has requested a QoS link and received an acceptance message by the QoS manager 105, as described previously with respect to FIG. 3. For example, polling interval 412 may represent a polling interval reserved for node 101 and polling interval 414 may represent a polling interval reserved for node 102. In this case, QoS manager 105 has received and accepted QoS link requests from nodes 101 and 102 in the manner described with respect to FIG. 3. Data sending intervals 413 and 415 may represent the transmission of data blocks from nodes 101 and 102, respectively. During these data sending intervals, the other nodes remain quiet.

[0049] FIG. 5 illustrates exemplary processing associated with transmitting data during QoS period 410 of FIG. 4B, consistent with the present invention. Processing may begin with QoS manager 105 broadcasting a beacon signal (act 510). The beacon may be broadcast at full power to alert other nodes in network 100 as to the existence of node 105 and may include information identifying node 105 as a QoS manager. QoS manager 105 may then broadcast a first polling signal in a polling cycle to nodes 101–104 (act 520). For example, the first polling signal may identify node 101 and indicate that the next data sending interval is reserved for node 101. Nodes 102–104 receive this polling signal and remain quiet (i.e., do not transmit data) during the following data sending interval.

[0050] Node 101 may then transmit its QoS data during data sending interval 413. According to an exemplary implementation of the present invention, the sending node (i.e., node 101) may determine if the destination for the data is 1-hop from the sending node (act 530). Node 101 may access a table in its memory to determine if the destination node is 1-hop away. If the destination for the data is 1-hop away, node 101 may send the data directly to the destination node (act 540). If the destination is more than 1-hop away, node 101 may send the data to QoS manager 105 (act 550). For example, referring to FIG. 4B, node 101 may forward data to QoS manager 105 during interval 413. In this case, if the QoS manager 105 is not the destination node, QoS manager 105 forwards the QoS data to the next hop.

[0051] QoS manager 105 may then determine whether any additional nodes have reserved polling slots in QoS period 410 (act 560). If no additional polling slots are reserved, the QoS period 410 is completed (act 570). If, however, additional polling slots have been reserved for particular nodes, processing may then return to act 520. Referring back to the exemplary QoS period 410 in FIG. 4B, QoS manager 105 broadcasts another polling signal to nodes 101–104 at polling interval 414. This signal identifies, for example, node 102 and indicates that the next data sending interval is reserved for node 102. Nodes 101, 103 and 104 receive this polling signal and remain quiet during the following data sending interval. Node 102 may then transmit its QoS data during data sending interval 415. For example, the data from node 102 may be destined for node 103. In this case, since the destination is 1-hop from the sending node, node 102 may send the data directly to node 103 and bypass node 105, thereby saving time and network resources.

[0052] The exemplary processing described above defines an exemplary QoS period 410. As described previously, the QoS period 410 may be changed as additional QoS link requests are made and are granted. QoS period 410 may also change when QoS links are no longer needed. That is, when a node no longer requires a QoS link, that node can transmit a QoS release message to its QoS manager, which then can delete the slot in its polling cycle reserved for that node. In this manner, QoS manager 105 efficiently controls data transfer from its subordinate nodes (i.e., nodes 101–104) by establishing a polling cycle to control data transmissions in network 100.

[0053] The QoS repetition interval in FIG. 4A also includes a distributed control function (DCF) period 420. As described above, polling may be used when a number of nodes are neighbor nodes of a QoS manager node. When such a configuration does not exist, a DCF mechanism may be used to avoid contention problems. In accordance with an exemplary implementation of the present invention, the DCF period 420 may be prioritized as described in more detail below.

[0054] In conventional systems that employ a DCF mechanism to control access to a shared communication channel, each node listens to the communication channel for other users. If the channel is idle, the node may transmit. If the channel is busy, however, each node must wait until transmission stops before attempting to transmit. Each node may also include a timer that times a random number of back-off time slots before attempting to transmit. In this manner, each node has equal probability of accessing the communication channel during a period of time referred to as the contention window.

[0055] Implementations of the present invention advantageously prioritize data to give certain types of data higher priority. When a node is attempting to transmit the higher priority data, that node is given a better chance of seizing the communication channel before other nodes transmitting lower priority data, as described in more detail below.

[0056] FIG. 4C schematically illustrates the DCF period 420 in more detail. Referring to FIG. 4C, the DCF period 420 includes a request to send (RTS) interval 421, a clear to send (CTS) interval 422, a data block sending interval 423, an acknowledge (ACK) interval 424 and a contention window 425. In this implementation, when a node wishes to transmit data, it broadcasts an RTS signal during interval 421. The other nodes receive this signal and the destination node transmits a CTS signal during interval 422 if the channel is clear.

[0057] The sending node may then transmit its data during interval 423 and the other nodes remain quiet (i.e., they withhold transmission). The receiving node may then transmit an ACK signal during interval 424. After the ACK interval 424, nodes in network 100 wait a predetermined period of time, known as the DCF inter-frame spacing (DIFS) interval, before attempting to seize the channel for a data transmission. After expiration of the DIFS interval, a node may attempt to seize the channel by transmitting an RTS signal. If another node has already seized the channel, the RTS may be denied (i.e., the destination node does not send a CTS signal). The contention window 425 refers to the period of time after the DIFS interval has expired that the channel is idle. During this period, each of the nodes may contend for the channel.

[0058] According to an exemplary implementation of the present invention, when a node has priority data, such as QoS-based data, the duration of the contention window 425 may be reduced. That is, the length of time between the expiration of the DIFS interval and the time when the node can transmit an RTS or other request signal is reduced from that used with lower priority traffic. In addition, when the node that is the destination for the QoS link request receives the QoS request, that node may also reduce the duration of its contention window 425. In this manner, when nodes are transmitting higher priority data, these nodes have a greater chance of being able to seize the communication channel than the other nodes.

[0059] FIG. 4D schematically illustrates the contention window 425 for various types of data consistent with the present invention. For example, FIG. 4D illustrates minimum and maximum contention windows (CW_MIN and CW_MAX) for data corresponding to various priorities. For example, type of service (ToS) refers to a value that may be used to represent various types of data traffic. According to an exemplary implementation, ToS 0 through ToS 63 may identify 64 types of service that correspond to different types of data. For example, ToS 0 may correspond to video data that is associated with a QoS request. It should be understood that the present invention may support additional types of service and corresponding ToS values.

[0060] According to the exemplary implementation of the present invention, ToS 0 represents data having the highest priority, followed by ToS 1, then ToS 2 etc. The minimum contention window (CWMIN) corresponding to ToS 0, represented by interval A in FIG. 4D, is shorter than the minimum contention window for ToS 1, represented by B in FIG. 4D. Similarly, CW_MIN for ToS 1 is shorter than CW_MIN for ToS 2, represented by C in FIG. 4D. This effectively gives a node with higher priority data a better chance of being able to seize the communication channel than a node with lower priority data, as described in more detail below. The maximum contention window, CW_MAX, is represented by “X” in FIG. 4D and may be equal for each ToS value.

[0061] FIG. 6 is a flow diagram of exemplary processing by nodes in network 100, consistent with the present invention, illustrating prioritized DCF. The DCF period 420 (FIG. 4A) may commence upon completion of the QoS period 410. Alternatively, the DCF period 420 may exist in a network that does not include a polling cycle as illustrated in QoS period 410. That is, the DCF period 420 may be used in a network that does not have the connectivity needed to support QoS manager nodes.

[0062] In either case, processing may begin with a node seizing the communication channel and broadcasting a data block (act 610). For example, assume that node 102 wishes to send data to node 104. In this case, node 102 broadcasts an RTS signal to nodes 101 and 103–105 at RTS interval 421 (FIG. 4C). Further assume that node 104 receives the RTS and broadcasts a CTS signal at CTS interval 422 indicating that the channel is clear. Nodes 101, 103 and 105 remain quiet during the subsequent data sending interval. Node 102 may then transmit its data during interval 423. Destination node 104 receives the data block and broadcasts an ACK signal during interval 424.

[0063] After the ACK signal is broadcasted, each node waits a predetermined DIFS interval before attempting to seize the communication channel. After the DIFS interval has expired, suppose that node 101 wishes to form a QoS link with node 103 to send and receive high priority data, such as ToS 0 data. In this case, node 101 identifies the particular ToS value associated with the QoS link request and adjusts its contention window to CW_MIN, based on the ToS value included in its request (act 620). In this example, since the request is associated with ToS 0 data, node 101 may reduce its contention window to the value represented by “A” in FIG. 4D. The particular length of A may be predetermined based on a number of factors, including level of traffic in network 100. Given the guidance provided herein, one of ordinary skill in the art would be able to adjust the duration of the CW_MIN and CW_MAX for ToS 0–ToS 63 to optimize the data throughput in network 100 based on the particular network requirements.

[0064] Node 101 then broadcasts the QoS request to nodes 102–105 (act 630). The QoS request may include a field that identifies the particular ToS value associated with the request and the destination for the QoS link. Nodes 102–105 receive the QoS request and identify that the QoS request is intended for node 103. Node 103 identifies the particular ToS value associated with the request and adjusts its contention window to the CW_MIN interval corresponding to the ToS value included in the request (act 640). In this example, since the request is associated with ToS 0 data, node 103 may reduce its contention window to the value represented by “A” in FIG. 4D. As described previously, the particular length of A may be chosen to optimize data throughput in network 100.

[0065] In this manner, nodes 101 and 103 reduce the duration of their contention windows to the CW_MIN value associated with the particular ToS value. This gives these nodes a greater probability of seizing the channel to communicate higher priority data traffic between themselves over network 100. Such data traffic may include voice data transmitted between nodes 101 and 103. Alternatively, if the QoS link does not require a full duplex connection, the destination node 103 may not reduce its contention window since it will not be transmitting data back to node 101.

[0066] Nodes 102, 104 and 105 also receive the broadcast QoS request and may identify the ToS value included in the request. Nodes 102, 104 and 105 may then increase their respective contention windows to the CW_MAX associated the particular ToS value included in the QoS request (act 650). When the other nodes (i.e., nodes 102, 104 and 105 in this example) increase their contention windows, this further increases the probability that nodes 101 and 103 will be able to seize the channel and complete a data communication. In the example above where the QoS request identifies ToS 0, nodes 102, 104 and 105 may increase the duration of their respective contention windows to the value represented by “X” in FIG. 4D.

[0067] After the QoS link is no longer needed, node 101 may broadcast a QoS release to nodes 102–105 (act 660). Nodes 101 and 103 may then release resources associated with fulfilling the throughput requirements associated with the QoS link. Nodes 101 and 103 may also return their respective contention windows back to their normal values (act 670). Nodes 102, 104 and 105 may similarly return their respective contention windows back to their normal values (act 670). The normal value of the contention window may be equal for each node, thereby giving each node an equal chance in gaining access to the communication channel.

[0068] Systems and methods consistent with the present invention perform contention-based media access control by using QoS manager nodes to control access to the shared channel. As a result, nodes are able to transmit data through the network with less contention problems. One advantage of using QoS managers is that QoS-based data may be transmitted through network with little additional overhead and non-QoS based data may be transmitted without any additional overhead. Systems and methods consistent with the present invention also allow prioritized access to the shared channel by adjusting the contention windows of the nodes in the network. This advantageously gives nodes with higher priority data a greater chance of gaining access to the shared channel.

[0069] The foregoing description of preferred embodiments of the present invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while the network 100 has been described as an ad hoc wireless network, systems and methods consistent with the present invention may be applicable to other types of networks. In addition, while series of acts have been described with respect to FIGS. 3, 5 and 6, the order of the acts may be modified in other implementations consistent with the present invention.

[0070] The present invention has also been described as using ToS values to indicate priority associated with a data transmission. In other implementations, other values may be used to indicate priority. In addition, the present invention has been described as using 64 ToS values to indicate various priority levels. In other implementations, more or fewer priority values may be used. For example, in one implementation, data may be characterized as having either a high priority or a normal/low priority.

[0071] The present invention has further been described as transmitting data via an ad hoc wireless network. It should be understood that the data transmitted may include voice data, video data or other data. It should further be understood that the data links between the nodes in network 100 may be full or half duplex links. The links may also be multipoint, conference-type links involving multiple nodes.

[0072] No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used.

[0073] The scope of the invention is defined by the claims and their equivalents.