WO2006133415A2 - Avoiding exposed node problems in wireless local area networks - Google Patents
Avoiding exposed node problems in wireless local area networks Download PDFInfo
- Publication number
- WO2006133415A2 WO2006133415A2 PCT/US2006/022485 US2006022485W WO2006133415A2 WO 2006133415 A2 WO2006133415 A2 WO 2006133415A2 US 2006022485 W US2006022485 W US 2006022485W WO 2006133415 A2 WO2006133415 A2 WO 2006133415A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- rts
- channel
- nav
- cts
- node
- Prior art date
Links
- 230000005540 biological transmission Effects 0.000 claims abstract description 63
- 238000000034 method Methods 0.000 claims abstract description 39
- 230000004044 response Effects 0.000 claims abstract description 16
- 238000004590 computer program Methods 0.000 abstract description 5
- 238000004891 communication Methods 0.000 description 13
- 108700026140 MAC combination Proteins 0.000 description 8
- 238000010586 diagram Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 230000003287 optical effect Effects 0.000 description 3
- 230000007812 deficiency Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000007792 addition Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 229910003460 diamond Inorganic materials 0.000 description 1
- 239000010432 diamond Substances 0.000 description 1
- 244000144992 flock Species 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/407—Bus networks with decentralised control
- H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W74/00—Wireless channel access
- H04W74/08—Non-scheduled access, e.g. ALOHA
- H04W74/0808—Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA]
- H04W74/0816—Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA] with collision avoidance
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W74/00—Wireless channel access
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W74/00—Wireless channel access
- H04W74/002—Transmission of channel access control information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W74/00—Wireless channel access
- H04W74/04—Scheduled access
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/18—Negotiating wireless communication parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/26—Resource reservation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/20—Control channels or signalling for resource management
- H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/10—Small scale networks; Flat hierarchical networks
- H04W84/12—WLAN [Wireless Local Area Networks]
Definitions
- BACKGROUND Wireless Local Area Networks have become ubiquitous. Typically, a single channel is used for wireless communication in WLANs, which is accessed through, among others, a distributed MAC protocol.
- WLANS can include multiple channels and multiple radios.
- An approach that offers both multichannel and multi-radio capabilities appears in the co-pending patent application titled “A Protocol For Wireless Multi-Channel Access Control ", Attorney docket number AVA06-01, filed March 29, 2006, the disclosure of which is incorporated by reference herein, which describes the CCC (Common Control Channel) MAC protocol.
- CCC Common Control Channel
- CCC utilizes two types of logical channels, the control channel and the data channels.
- a wireless channel can be reserved for the transmission of a sequence of frames while employing asynchronous distributed random channel access methods.
- both the source and destination of the transmission broadcast the reservation duration in order to establish the interference neighborhood.
- RTS/CTS frames are used to notify neighbors of a transmission.
- the source and destination of the transmission send the RTS and CTS control frames, respectively, which contain the reservation duration in order to establish the interference neighborhood. Nodes receiving either control frame refrain from transmitting or agreeing to receive a transmission for the specified duration.
- One method of reserving the channel and preventing collisions with hidden terminals in wireless LANS is by utilizing frame-by-frame reservation.
- RTS/CTS frames are sent at the start of the reservation.
- the reservation time is extended on a frame-by-frame basis, by updating the duration of the reservation with each data frame and the acknowledgement that follows.
- a consequence of frame-by-frame reservation if that, if the reservation is not accepted - that is, a CTS frame is not returned in tine — there is no reserved time left unused and, hence, the reservation does not require cancellation.
- the exposed node problem arises when the NAV is set upon receipt of a frame from either the source (e.g. RTS/CTS) or the destination of a transmission.
- RTS/CTS the source
- This NAV setting convention leads to overly conservative measures for the avoidance of collisions.
- a station near the source of an RTS should be prevented from transmitting if it cannot hear the CTS response.
- a station that hears the CTS, but not the RTS prompting the former should not be prevented from receiving a different transmission.
- This invention describes how exposed nodes can be avoided when using a multi-channel protocol like CCC.
- Embodiments of the invention provide mechanisms and techniques that prevent the exposed node problem.
- the exposed node problem is addressed by maintaining separate NAVs for NAV-setting frames sent by the source and the destination of a transmission or a TXOP. All frames in a TXOP must be in one direction. This requirement is met by sending acknowledgements for the received frames in a group acknowledgement on the control channel
- the method includes maintaining at a node a first timer (NAVJRTS) for a channel which, if set, prevents the node from authoring a transmission on the channel to itself and maintaining at the node a second timer (NAV_CTS) for the channel which, if set, prevents the node from transmitting on the channel.
- NAVJRTS first timer
- NAV_CTS second timer
- the method further includes updating the NAVJRTS when a transmission request (CC-RTS frame) is received having a reservation duration value greater than zero and greater than a current value of the NAVJRTS, and updating the NAV_CTS when a transmission response (CC-CTS frame) is received having a reservation duration value greater than zero and greater than a current value of the NAV_CTS.
- inventions include a computer readable medium having computer readable code thereon for avoiding exposed terminals, the medium including instructions for maintaining at a node a first timer (NAVJRTS) for a channel which, if set, prevents the node from authoring a transmission on the channel to itself and maintaining at the node a second timer (NAV-CTS) for the channel which, if set, prevents the node from transmitting on the channel.
- NAVJRTS first timer
- NAV-CTS second timer
- the medium further includes instructions for updating the NAVJRTS when a transmission request (CC-RTS) frame is received having a reservation duration value greater than zero and greater than a current value of the NAV_RTS, and instructions for updating the NAV-CTS when a transmission response (CC-CTS) frame is received having a reservation duration value greater than zero and greater than a current value of the NAV_CTS.
- CC-RTS transmission request
- CC-CTS transmission response
- Still other embodiments include a computerized device, configured to process all the method operations disclosed herein as embodiments of the invention.
- the computerized device includes a memory system, a processor, communications interface in an interconnection mechanism connecting these components.
- the memory system is encoded with a process that avoids exposed nodes as explained herein that when performed (e.g. when executing) on the processor, operates as explained herein within the computerized device to perform all of the method embodiments and operations explained herein as embodiments of the invention.
- any computerized device that performs or is programmed to perform up processing explained herein is an embodiment of the invention.
- a computer program product is one embodiment that has a computer-readable medium including computer program logic encoded thereon that when performed in a computerized device provides associated operations avoiding exposed nodes explained herein.
- the computer program logic when executed on at least one processor with a computing system, causes the processor to perform the operations (e.g., the methods) indicated herein as embodiments of the invention.
- Such arrangements of the invention are typically provided as software, code and/or other data structures arranged or encoded on a computer readable medium such as an optical medium (e.g., CD-ROM), floppy or hard disk or other a medium such as firmware or microcode in one or more ROM or RAM or PROM chips or as an Application Specific Integrated Circuit (ASIC) or as downloadable software images in one or more modules, shared libraries, etc.
- the software or firmware or other such configurations can be installed onto a computerized device to cause one or more processors in the computerized device to perform the techniques explained herein as embodiments of the invention.
- Software processes that operate in a collection of computerized devices, such as In a group of data communications devices or other entities can also provide the system of the invention.
- the system of the invention can be distributed between many software processes on several data communications devices, or all processes could run on a small set of dedicated computers, or on one computer alone.
- the embodiments of the invention can be embodied strictly as a software program, as software and hardware, or as hardware and/or circuitry alone, such as within a data communications device.
- the features of the invention, as explained herein, may be employed in data communications devices and/or software systems for such devices such as those manufactured by Avaya Inc. of Lincroft New Jersey.
- Figure 1 depicts a diagram of a network showing a first example of an exposed node
- Figure 2 depicts a diagram of a network showing a second example of an exposed node
- Figures 3 A and 3B illustrates a particular embodiment of a method for avoiding exposed nodes in accordance with embodiments of the invention
- Figure 4 is a block diagram of a node which operates in accordance with the present invention.
- CCC Common Control
- the CCC protocol is a MAC protocol that extends the IEEE 802.11 distributed MAC protocol to enable use of multiple channels within a BSS or mesh network.
- the CCC protocol defines a flexible channel access architecture based on distributed prioritized contention-based medium access.
- the CCC protocol distinguishes between two logical channel functions, the Control Channel (CC) and the Data Channel (DC).
- CC Control Channel
- DC Data Channel
- stations or mesh points observing the CCC MAC protocol are referred to as 'nodes'. Nodes exchange control and management frames on the control channel.
- the data channels carry data traffic. Reservations for transmission on the various data channels are made by exchanging control frames on the control channel.
- the CC- RTS and CC-CTS are used to reserve a data channel for the time it takes to transmit a Transmission Opportunity (TXOP).
- TXOP is a sequence of frames (and their respective acknowledgements) transmitted serially, immediately following a single successful contention-based channel access attempt, as for instance that prescribed by the IEEE 802.1 Ie standard.
- the particular data channel selected for transmission of the TXOP is indicated in a special field on the CC-RTS/CC-CTS.
- the CC-RTS/CC-CTS exchange could be defined so that it can reserve multiple data channels, or a data channel and the control channel, for the same time interval.
- a node keeps track of the length of time for which a channel(s) is reserved in a channel-specific NAV, based on the value of the Reservation Duration field of the CC-RTS/CC-CTS.
- Both the forwarding and receiving node maintain a NAV for each usable channel.
- a node monitors the control channel and keeps track of all reservations made by other nodes to determine the busy/idle status of data channels, and when they will become available.
- the Reservation Duration field on the CC-RTS/CC-CTS is used to update the NAV for the channel reserved.
- the CC-RTS/CC-CTS Reservation Duration field is different from the Duration/ID field in the MAC header of the CC-RTS/CC-CTS frames. The latter indicates the length of the CC-RTS/CC-CTS transmission on the control channel.
- a reservation request is declined if the receiving node deems the requested channel busy, or if all its radios are busy.
- the receiving node responds with a CC-CTS within a time interval of length Short InterFrame Space (SIFS).
- a CC-CTS is sent to indicate acceptance of a channel reservation request.
- the Reservation Duration field is copied in the CC-CTS sent by the receiving node. If a CC-CTS is not received, the forwarding node assumes that the reservation request is declined.
- a reservation is accepted if the data channel indicated in the CC-RTS will become idle within a pre-specified time interval, according to the NAV maintained by the receiving node and if the receiving node has available radios to receive the transmission.
- Successful receipt of a data traffic transmission is followed by an acknowledgement sent either on the data channel according to EDCA rules or as a group acknowledgment on the control channel.
- Both the forwarding and receiving node maintain a NAV for each usable channel.
- a node monitors the control channel and keeps track of all reservations made by other nodes to determine the busy/idle status of data channels, and when they will become available.
- the Reservation Duration field on the CC-RTS/CC-CTS is used to update the NAV for the channel reserved.
- the CC-RTS/CC-CTS Reservation Duration field is different from the Duration/ID field in the MAC header of the CC-RTS/CC-CTS frames. The latter indicates the length of the CC-RTS/CC-CTS transmission on the control channel.
- a reservation request is declined if the receiving node deems the requested channel busy, or if all its radios are busy.
- the receiving node responds with a CC-CTS within a time interval of length Short InterFrame Space (SIFS).
- a CC-CTS is sent to indicate acceptance of a channel reservation request.
- the Reservation Duration field is copied in the CC-CTS sent by the receiving node. If a CC-CTS is not received, the forwarding node assumes that the reservation request is declined.
- a reservation is accepted if the data channel indicated in the CC-RTS will become idle within a pre-specified time interval, according to the NAV maintained by the receiving node and if the receiving node has available radios to receive the transmission.
- Successful receipt of a data traffic transmission is followed by an acknowledgement sent either on the data channel according to EDCA rules or as a group acknowledgment on the control channel.
- Different frames utilized include a CC-RTS frame, used by a node initiating a TXOP.
- This frame includes several fields including a source node; a destination node; a source node transmit channel; a duration and a number of frames in TXOP.
- a CC-CTS frame is used by a node accepting a TXOP.
- the CC-CTS frame includes several fields including a destination node; a source node; a source node transmit channel; a duration; a number of frames in TXOP; and a Radio Counter.
- a CC-ACK frame identifies the individual frame in a sequence of frames that were received successfully.
- the CC-ACK frame includes a destination node; source node; and a TXOP frame receipt status.
- Channel Reservation occurs when the source node reserves its data channel for one or multiple frames by sending a CC-RTS frame to the destination node on the control channel, provided the Channel_State indication for the data channel is idle.
- the Reservation Duration field and number of TXOP frames are set in the CC-RTS.
- the destination node sends a CC-CTS in response within SIFS.
- the reservation request is accepted if the destination node has a Channel_State idle indication for the source node's data channel, and the destination node has available radios to receive the transmission; i.e. the Radio Counter is non-zero.
- the Reservation Duration field is adjusted and the number of frames in the TXOP is repeated in the CC-CTS sent by the destination node and the CC-CTS includes the number of its radios that remain available to receive traffic - that is the Radio Counter. (The latter is not necessary, but it is useful to other nodes with frames to send to the destination node).
- the Reservation Duration field in the CC-CTS is set to 0 and the source node in that case sends another CC-RTS with a Reservation Duration field set to 0.
- the destination node will send a CC-CTS with a 0 in the Reservation Duration field in response to a CC-RTS with a Reservation Duration field set to 0.
- the destination node will acknowledge the status of the transmit sequence by sending an acknowledgement, called CC-ACK, on the control channel.
- the frames received successfully will be identified in the CC-ACK.
- the acknowledgement will be transmitted by contending at the highest access priority Channel Reservation occurs when the source node reserve its data channel for one or multiple frames by sending a CC-RTS frame to the destination node on the control channel, provided the Channel_State indication for the data channel is idle.
- the Reservation Duration field and number of TXOP frames are set in the CC-RTS.
- the destination node sends a CC-CTS in response within SIFS.
- the reservation request is accepted if the destination node has a Channel_State idle indication for the source node's data channel, and the destination node has available radios to receive the transmission; i.e. the Radio Counter is non-zero. If the reservation request is accepted by the
- the Reservation Duration field is adjusted and the number of frames in the TXOP is repeated in the CC-CTS sent by the destination node and the CC-CTS includes the number of its radios that remain available to receive traffic - that is the Radio Counter. (The latter is not necessary, but it is useful to other nodes with frames to send to the destination node).
- the Reservation Duration field in the CC-CTS is set to 0 and the source node in that case sends another CC-RTS with a Reservation Duration field set to 0.
- the destination node will send a CC-CTS with a 0 in the Reservation Duration field in response to a CC-RTS with a Reservation Duration field set to 0.
- the destination node When all frames in a TXOP are transmitted, the destination node will acknowledge the status of the transmit sequence by sending an acknowledgement, called CC-ACK, on the control channel. The frames received successfully will be identified in the CC-ACK. The acknowledgement will be transmitted by contention.
- CC-ACK acknowledgement
- the CCC protocol observes the rules of the distributed random access protocol of IEEE 802.11 and its amendments (DCF and EDCA) for channel access and virtual carrier sensing, although further enhancements can enable better channel access prioritization.
- DCF and EDCA distributed random access protocol
- CCC is backward compatible with existing 802.11 technologies. All nodes, that is both nodes using existing 802.11 technology and CCC compliant nodes, can communicate on the control channel through the existing 802.11 MAC protocol. In addition, a node that secures the reservation of a data channel will transmit on the reserved channel only after listening for a period equal to the arbitration inter-frame space to ensure that the channel is idle. This measure is introduced to allow for coexistence of CCC-compliant stations with legacy/independent stations.
- Nodes with a single radio (which transmit data on the control channel) can employ any of the acknowledgement forms provided by the 802.11 standard and its amendments. The same holds for nodes with two radios, one control radio and one data radio, except in certain situations when communicating with a node with multiple data radios.
- Nodes may also transmit a group acknowledgement on the control channel, called the CC-Acknowledgement (CC-ACK), in order to notify the sender of the successful receipt of a TXOP.
- CC-ACK group acknowledgement on the control channel
- the CC-Ack would be used in order to avoid adjacent channel interference or in order to avoid exposed nodes.
- An 'exposed node' is one that is either within the sensing range of the sender node but outside the interference range of the receiver node - therefore it could not receive a transmission from another node, but could transmit itself; or within the sensing range of the receiver node but outside the interference range of the sender node - therefore it could not transmit but it could receive another transmission directed to it.
- Mesh networks accentuate the exposed node problem because of the distances between nodes. Due to the spatial arrangement of a mesh, nodes become exposed and set their NAVs conservatively. New NAV rules allow what would have otherwise been 'exposed nodes' to transmit without causing collisions.
- the exposed node problem can be avoided if reservations and acknowledgements are made on a control channel, which is different from the mesh traffic channel.
- the NAVs are modified accordingly.
- the exposed node problem causes the NAVs of neighbors of transmitting nodes to be set in an overly conservative way.
- a node that can hear a NAV setting request refrains from transmitting, and when receiving a reservation request (i.e., a CC-RTS), it declines the reservation.
- a NAV setting request either a CC-RTS or a CC-CTS
- Such a node may be able to either transmit or receive a transmission concurrently with the transmission that caused its NAV to be set. The node need not, however, refrain from transmitting concurrently if it is sufficiently distant from the destination of the ongoing transmission.
- Ack prevents Tx(Rx) by exposed node on the same channel.
- node C is within a sensing range of node B.
- Node B is in communication with node A and node C is in communication with node D.
- all nodes within sensing range hear the CC-RTS (e.g. node B).
- Node B sets its NAV accordingly and refrains from transmitting. If a node is not within interference range of the destination of the CC-RTS, that node could transmit simultaneously without causing a collision.
- Node B can transmit at the same time as C sends a transmission to D.
- a node that hears a CC-RTS should not accept a CC-RTS directed to itself.
- Node B could not receive a transmission from Node A while C is transmitting to D.
- a second transmission to a destination outside the sensing range of the CC-RTS would be possible from B. Since Node A is outside the sensing range of C, it did not hear the CC-RTS from C and would thus respond with a CC-CTS to a CC-RTS from node B. Node B becomes 'exposed' when node C transmits. Node C becomes 'exposed' when node B transmits. Another example of the exposed node problem is depicted in Figure 2. In this environment, node C is within a sensing range of node B. Node B is in communication with node A and node C is in communication with node D.
- Node D When Node D sends a CC- RTS to node C, all nodes within sensing range hear the CC-RTS. Node B sets its NAV accordingly and refrains from transmitting. If a node is not within interference range of the destination of the CC-RTS, it could transmit simultaneously without causing a collision. Node A can transmit at the same time as D sends a transmission to C. A second transmission to a destination outside the sensing range of the CC-RTS would be possible. Since Node A is outside the sensing range of C, it did not hear the CC-CTS from C and could thus send a CC-RTS to node B. A node that hears a CC-CTS should accept a CC-RTS directed to itself. Node B could receive a transmission from Node A while C is transmitting to D. Node B becomes 'exposed' when node D transmits. Node C becomes 'exposed' when node A transmits.
- the control channel is used for reservations on traffic channels.
- the control channel is generally different from the channel carrying data traffic.
- a group acknowledgement, Mesh Ack (MACK) can be sent on the control channel, upon successful receipt of a TXOP. This is in place of regular Acks (individual or group) that are normally sent on the channel used by the transmission.
- MACK Mesh Ack
- This is in place of regular Acks (individual or group) that are normally sent on the channel used by the transmission.
- By removing the Ack from the traffic channel it is possible for an exposed node to transmit concurrently with a neighbor with a pending NAV-setting request.
- new NAV rules are used. According to conventional 802.11 NAV rules, a CC-RTS/CC-CTS sets the NAV of a neighbor.
- a node cannot send a CC-RTS or authorize a CC-RTS by sending a CC- CTS until the NAV expires.
- the existing NAV-setting rules are not adequate to enable an exposed node to transmit when appropriate.
- NAV The new rules for a NAV are as follows. A NAV must distinguish when a node receiving a CC-RTS/CC-CTS can transmit. A NAV must distinguish when a node receiving a CC-RTS/CC-CTS can accept a reservation (i.e., send a CC-CTS). To address the 'exposed node' problem, each node maintains two NAVs for each data channel, NAV_RTS and NAV_CTS. NAV_RTS is updated when receiving a CC-RTS with Reservation duration greater than zero and greater than a current value of the reservation duration.
- NAV-CTS is updated when receiving a CC-CTS with Reservation duration greater than zero and greater than a current value of the reservation duration. IfNAV-CTS is greater than zero for a channel, a node must not attempt a reservation on that channel. If a node hears a CC-RTS with a Reservation duration equal to zero the NAV_RTS is not updated. If a node hears a CC-CTS with a Reservation duration equal to zero the NAV_CTS is not updated.
- a node If a node hears a CC-RTS with Reservation duration greater than zero, following an idle greater than SIFS, it updates the NAV_RTS for the time needed to receive a CC- CTS and a CC-RTS and extends the NAV if a cancellation is not received. If a node hears a CC-RTS with Reservation duration greater than zero, following an idle less than or equal to SIFS, it updates the NAV_RTS for the CC-RTS Reservation duration value. If a node hears a CC-CTS with Reservation duration greater than zero, it updates the NAV_CTS for the CC-CTS Reservation duration value (a simultaneous transmission by the node would cause collision).
- the use of double NAVs for a channel enables an exposed node to either receive or transmit without interfering with the transmission for which the channel is reserved through the CC-RTS/CC-CTS.
- a transmission to or from an exposed node would interfere however with the acknowledgment, which is transmitted in the opposite direction.
- the acknowledgement can be transmitted on the control channel.
- use of the CC-ACK an acknowledgement transmitted on the control channel following transmission of a TXOP on a data channel, would be needed for acknowledgement to enable a WLAN mesh to prevent exposed nodes.
- FIG. IA A flow chart of the presently disclosed method is depicted in Figures IA and IB.
- the rectangular elements are herein denoted “processing blocks” and represent computer software instructions or groups of instructions.
- the diamond shaped elements are herein denoted “decision blocks,” represent computer software instructions, or groups of instructions which affect the execution of the computer software instructions represented by the processing blocks.
- the processing and decision blocks represent steps performed by functionally equivalent circuits such as a digital signal processor circuit or an application specific integrated circuit (ASIC).
- ASIC application specific integrated circuit
- the flow diagrams do not depict the syntax of any particular programming language. Rather, the flow diagrams illustrate the functional information one of ordinary skill in the art requires to fabricate circuits or to generate computer software to perform the processing required in accordance with the present invention. It should be noted that many routine program elements, such as initialization of loops and variables and the use of temporary variables are not shown. It will be appreciated by those of ordinary skill in the art that unless otherwise indicated herein, the particular sequence of steps described is illustrative only and can be varied without departing from the spirit of the invention. Thus, unless otherwise stated the steps described below are unordered meaning that, when possible, the steps can be performed in any convenient or desirable order.
- processing block 102 which discloses maintaining at a node a first time period (NAVJRTS) for a channel other nodes must refrain from transmitting on the channel.
- processing block 204 states maintaining at the node a second timer (NAV_CTS) for the channel other nodes must refrain from transmitting on the channel.
- Processing block 206 recites updating the NAV_RTS when a transmission request (CC-RTS) frame is received having a reservation duration value greater than zero and greater than a current value of the NAV_RTS.
- the updating the NAVJRTS when a transmission request (CC-RTS) frame is received having a reservation duration value greater than zero and greater than a current value of the NAVJRTS comprises determining if the CC-RTS was received following an idle time greater than a Short InterFrame Space (SIFS) time then updating the NAV_RTS for the time needed to receive a CC-CTS and a CC-RTS and extending the NAVJRTS when a cancellation is not received.
- SIFS Short InterFrame Space
- updating the NAVJRTS when a transmission request (CC-RTS) is received having a reservation duration value greater than zero and greater than a current value of the NAV-RTS comprises determining if the CC-RTS was received following an idle time not greater than a Short InterFrame Space (SIFS) time then updating the NAV_RTS time period for the CC-RTS reservation duration value.
- SIFS Short InterFrame Space
- Processing block 212 discloses updating the NAV_CTS when a transmission response (CC-CTS) frame is received having a reservation duration value greater than zero and greater than a current value of the NAV_CTS. This may include, as shown in processing flock 214, updating the NAV_CTS when a transmission response (CC-CTS) is received having a reservation duration value greater than zero and greater than a current value of the NAV_CTS comprises updating the NAV_CTS time period for the CC-CTS reservation duration value.
- CC-CTS transmission response
- Processing continues with processing block 216 which states refraining from updating the NAVJRTS when a CC-RTS frame having a reservation duration equal to zero is received.
- Processing block 218 recites refraining from updating the NAV_CTS when a CC-CTS frame having a reservation duration equal to zero is received.
- Processing block 220 depicts that the method further includes maintaining a timer, remembering a forwarding node and a last node of a last CC-MRTS received and maintaining a reservation duration value for the last CC-RTS received.
- Processing block 222 states when a node receives a CC-RTS with a reservation duration value greater than zero while the timer is at a value of zero, then updating the NAV-RTS for a time interval needed to receive a CC-CTS and a CC-RTS (CC-RTSHSHK), setting the timer to the value of the CC-RTSHSHK and updating the NAVJRTS with a value equal to the reservation duration of the last CC-RTS received when the timer expires.
- CC-RTSHSHK CC-RTSHSHK
- Processing block 224 recites when a node receives a CC-RTS from the same node as the last node with a reservation duration value greater than zero while the timer is greater than zero, then updating the NAVJRTS for the CC-RTS duration value and resetting the timer.
- Processing block 226 discloses when the node receives a CC-RTS from the same node as the last node having a reservation duration of zero and the timer is greater than zero then resetting the timer.
- Processing block 228 states when the node receives a CC-CTS having a reservation duration greater than zero then updating the NAV-CTS for the CC_CTS reservation duration value; and processing block 230 recites when the node receives other NAV setting requests then updating the NAV-RTS and the NAV-CTS for the duration value in the NAV-setting frame.
- Figure 4 illustrates example architectures of a computer system that is configured as anode 240.
- the node 240 may be any type of computerized system such as a personal computer, workstation, portable computing device, mainframe, server or the like.
- the node includes an interconnection mechanism 211 that couples a memory system 212, a processor 213, and a communications interface 214.
- the communications interface 214 allows the node 240 to communicate with external devices or systems.
- the memory system 212 may be any type of computer readable medium that is encoded with an application 255-A that represents software code such as data and/or logic instructions (e.g., stored in the memory or on another computer readable medium such as a disk) that embody the processing functionality of embodiments of the invention as explained above.
- the processor 213 can access the memory system 212 via the interconnection mechanism 211 in order to launch, run, execute, interpret or otherwise perform the logic instructions of the applications 255-A for the host in order to produce a corresponding process 255-B.
- the process 255-B represents one or more portions of the application 255-A performing within or upon the processor 213 in the computer system.
- embodiments of the invention include the applications (i.e., the un-executed or non-performing logic instructions and/or data) encoded within a computer readable medium such as a floppy disk, hard disk or in an optical medium, or in a memory type system such as in firmware, read only memory (ROM), or, as in this example, as executable code within the memory system 212 (e.g., within random access memory or RAM).
- a computer readable medium such as a floppy disk, hard disk or in an optical medium
- a memory type system such as in firmware, read only memory (ROM), or, as in this example, as executable code within the memory system 212 (e.g., within random access memory or RAM).
- ROM read only memory
- RAM random access memory
- a computer usable medium can include a readable memory device, such as a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having computer readable program code segments stored thereon.
- the computer readable medium can also include a communications link, either optical, wired, or wireless, having program code segments carried thereon as digital or analog signals.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
Abstract
A method, apparatus and computer program product for avoiding exposed nodes in Wireless local Area Networks is presented. The method includes maintaining at a node a first timer (NAV_RTS) for a channel which, if set, prevents the node from authorizing a transmission on the channel to itself and maintaining at the node a second timer (NAV_CTS) for the channel which, if set, prevents the node from transmitting on the channel. The method further includes updating the NAV_RTS when a transmission request (CC-RTS) frame is received having a reservation duration value greater than zero and greater than a current value of the NAV_RTS, and updating the NAV_CTS when a transmission response (CC-CTS) frame is received having a reservation duration value greater than zero and greater than a current value of the NAV_CTS.
Description
AVOIDING EXPOSED NODE PROBLEMS IN WIRELESS LOCAL AREA NETWORKS
BACKGROUND Wireless Local Area Networks (WLANS) have become ubiquitous. Typically, a single channel is used for wireless communication in WLANs, which is accessed through, among others, a distributed MAC protocol. [IEEE 802.11 standard] WLANS can include multiple channels and multiple radios. An approach that offers both multichannel and multi-radio capabilities appears in the co-pending patent application titled "A Protocol For Wireless Multi-Channel Access Control ", Attorney docket number AVA06-01, filed March 29, 2006, the disclosure of which is incorporated by reference herein, which describes the CCC (Common Control Channel) MAC protocol. CCC utilizes two types of logical channels, the control channel and the data channels.
In wireless Local Area Networks (LANS), a wireless channel can be reserved for the transmission of a sequence of frames while employing asynchronous distributed random channel access methods. In such an environment, both the source and destination of the transmission broadcast the reservation duration in order to establish the interference neighborhood.
According to the 802.11 distributed channel access MAC protocol, RTS/CTS frames are used to notify neighbors of a transmission. The source and destination of the transmission send the RTS and CTS control frames, respectively, which contain the reservation duration in order to establish the interference neighborhood. Nodes receiving either control frame refrain from transmitting or agreeing to receive a transmission for the specified duration. One method of reserving the channel and preventing collisions with hidden terminals in wireless LANS is by utilizing frame-by-frame reservation. RTS/CTS frames are sent at the start of the reservation. The reservation time is extended on a frame-by-frame basis, by updating the duration of the reservation with each data frame and the acknowledgement that follows. A consequence of frame-by-frame reservation if that, if the reservation is not accepted - that is, a CTS frame is not returned in tine — there is no reserved time left unused and, hence, the reservation does not require cancellation.
SUMMARY
Conventional mechanisms such as those explained above suffer from a variety of deficiencies. One such deficiency is referred to as the 'exposed node' problem, which is exacerbated in wireless mesh networks. The exposed node problem arises when the NAV is set upon receipt of a frame from either the source (e.g. RTS/CTS) or the destination of a transmission. This NAV setting convention leads to overly conservative measures for the avoidance of collisions. A station near the source of an RTS should be prevented from transmitting if it cannot hear the CTS response. Similarly, a station that hears the CTS, but not the RTS prompting the former, should not be prevented from receiving a different transmission. This invention describes how exposed nodes can be avoided when using a multi-channel protocol like CCC.
Embodiments of the invention provide mechanisms and techniques that prevent the exposed node problem. The exposed node problem is addressed by maintaining separate NAVs for NAV-setting frames sent by the source and the destination of a transmission or a TXOP. All frames in a TXOP must be in one direction. This requirement is met by sending acknowledgements for the received frames in a group acknowledgement on the control channel
In a particular embodiment of a method for avoiding exposed terminals, the method includes maintaining at a node a first timer (NAVJRTS) for a channel which, if set, prevents the node from authoring a transmission on the channel to itself and maintaining at the node a second timer (NAV_CTS) for the channel which, if set, prevents the node from transmitting on the channel. The method further includes updating the NAVJRTS when a transmission request (CC-RTS frame) is received having a reservation duration value greater than zero and greater than a current value of the NAVJRTS, and updating the NAV_CTS when a transmission response (CC-CTS frame) is received having a reservation duration value greater than zero and greater than a current value of the NAV_CTS.
Other embodiments include a computer readable medium having computer readable code thereon for avoiding exposed terminals, the medium including instructions for maintaining at a node a first timer (NAVJRTS) for a channel which, if set, prevents the node from authoring a transmission on the channel to itself and maintaining at the node a second timer (NAV-CTS) for the channel which, if set, prevents the node from
transmitting on the channel. The medium further includes instructions for updating the NAVJRTS when a transmission request (CC-RTS) frame is received having a reservation duration value greater than zero and greater than a current value of the NAV_RTS, and instructions for updating the NAV-CTS when a transmission response (CC-CTS) frame is received having a reservation duration value greater than zero and greater than a current value of the NAV_CTS.
Still other embodiments include a computerized device, configured to process all the method operations disclosed herein as embodiments of the invention. In such embodiments, the computerized device includes a memory system, a processor, communications interface in an interconnection mechanism connecting these components. The memory system is encoded with a process that avoids exposed nodes as explained herein that when performed (e.g. when executing) on the processor, operates as explained herein within the computerized device to perform all of the method embodiments and operations explained herein as embodiments of the invention. Thus any computerized device that performs or is programmed to perform up processing explained herein is an embodiment of the invention.
Other arrangements of embodiments of the invention that are disclosed herein include software programs to perform the method embodiment steps and operations summarized above and disclosed in detail below. More particularly, a computer program product is one embodiment that has a computer-readable medium including computer program logic encoded thereon that when performed in a computerized device provides associated operations avoiding exposed nodes explained herein. The computer program logic, when executed on at least one processor with a computing system, causes the processor to perform the operations (e.g., the methods) indicated herein as embodiments of the invention. Such arrangements of the invention are typically provided as software, code and/or other data structures arranged or encoded on a computer readable medium such as an optical medium (e.g., CD-ROM), floppy or hard disk or other a medium such as firmware or microcode in one or more ROM or RAM or PROM chips or as an Application Specific Integrated Circuit (ASIC) or as downloadable software images in one or more modules, shared libraries, etc. The software or firmware or other such configurations can be installed onto a computerized device to cause one or more processors in the computerized device to perform the techniques explained herein as embodiments of the invention. Software processes that operate in a collection of
computerized devices, such as In a group of data communications devices or other entities can also provide the system of the invention. The system of the invention can be distributed between many software processes on several data communications devices, or all processes could run on a small set of dedicated computers, or on one computer alone.
It is to be understood that the embodiments of the invention can be embodied strictly as a software program, as software and hardware, or as hardware and/or circuitry alone, such as within a data communications device. The features of the invention, as explained herein, may be employed in data communications devices and/or software systems for such devices such as those manufactured by Avaya Inc. of Lincroft New Jersey.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.
Figure 1 depicts a diagram of a network showing a first example of an exposed node;
Figure 2 depicts a diagram of a network showing a second example of an exposed node;
Figures 3 A and 3B illustrates a particular embodiment of a method for avoiding exposed nodes in accordance with embodiments of the invention; and Figure 4 is a block diagram of a node which operates in accordance with the present invention.
DETAILED DESCRIPTION
Conventional wireless networks may utilize a Common Control (CCC) Protocol for medium access control. The CCC protocol is a MAC protocol that extends the IEEE 802.11 distributed MAC protocol to enable use of multiple channels within a BSS or mesh network. The CCC protocol defines a flexible channel access architecture based on distributed prioritized contention-based medium access. The CCC protocol
distinguishes between two logical channel functions, the Control Channel (CC) and the Data Channel (DC). In the description that follows, stations or mesh points observing the CCC MAC protocol are referred to as 'nodes'. Nodes exchange control and management frames on the control channel. The data channels carry data traffic. Reservations for transmission on the various data channels are made by exchanging control frames on the control channel. As extensions of the legacy RTS and CTS messages, the CC- RTS and CC-CTS are used to reserve a data channel for the time it takes to transmit a Transmission Opportunity (TXOP). A TXOP is a sequence of frames (and their respective acknowledgements) transmitted serially, immediately following a single successful contention-based channel access attempt, as for instance that prescribed by the IEEE 802.1 Ie standard. The particular data channel selected for transmission of the TXOP is indicated in a special field on the CC-RTS/CC-CTS. The CC-RTS/CC-CTS exchange could be defined so that it can reserve multiple data channels, or a data channel and the control channel, for the same time interval. A node keeps track of the length of time for which a channel(s) is reserved in a channel-specific NAV, based on the value of the Reservation Duration field of the CC-RTS/CC-CTS.
Both the forwarding and receiving node maintain a NAV for each usable channel. A node monitors the control channel and keeps track of all reservations made by other nodes to determine the busy/idle status of data channels, and when they will become available. The Reservation Duration field on the CC-RTS/CC-CTS is used to update the NAV for the channel reserved. The CC-RTS/CC-CTS Reservation Duration field is different from the Duration/ID field in the MAC header of the CC-RTS/CC-CTS frames. The latter indicates the length of the CC-RTS/CC-CTS transmission on the control channel. A reservation request is declined if the receiving node deems the requested channel busy, or if all its radios are busy.
The receiving node responds with a CC-CTS within a time interval of length Short InterFrame Space (SIFS). A CC-CTS is sent to indicate acceptance of a channel reservation request. The Reservation Duration field is copied in the CC-CTS sent by the receiving node. If a CC-CTS is not received, the forwarding node assumes that the reservation request is declined. A reservation is accepted if the data channel indicated in the CC-RTS will become idle within a pre-specified time interval, according to the NAV maintained by the receiving node and if the receiving node has available radios to receive the transmission. Successful receipt of a data traffic transmission is followed by
an acknowledgement sent either on the data channel according to EDCA rules or as a group acknowledgment on the control channel.
Both the forwarding and receiving node maintain a NAV for each usable channel. A node monitors the control channel and keeps track of all reservations made by other nodes to determine the busy/idle status of data channels, and when they will become available. The Reservation Duration field on the CC-RTS/CC-CTS is used to update the NAV for the channel reserved. The CC-RTS/CC-CTS Reservation Duration field is different from the Duration/ID field in the MAC header of the CC-RTS/CC-CTS frames. The latter indicates the length of the CC-RTS/CC-CTS transmission on the control channel. A reservation request is declined if the receiving node deems the requested channel busy, or if all its radios are busy.
The receiving node responds with a CC-CTS within a time interval of length Short InterFrame Space (SIFS). A CC-CTS is sent to indicate acceptance of a channel reservation request. The Reservation Duration field is copied in the CC-CTS sent by the receiving node. If a CC-CTS is not received, the forwarding node assumes that the reservation request is declined. A reservation is accepted if the data channel indicated in the CC-RTS will become idle within a pre-specified time interval, according to the NAV maintained by the receiving node and if the receiving node has available radios to receive the transmission. Successful receipt of a data traffic transmission is followed by an acknowledgement sent either on the data channel according to EDCA rules or as a group acknowledgment on the control channel.
Different frames utilized include a CC-RTS frame, used by a node initiating a TXOP. This frame includes several fields including a source node; a destination node; a source node transmit channel; a duration and a number of frames in TXOP. A CC-CTS frame is used by a node accepting a TXOP. The CC-CTS frame includes several fields including a destination node; a source node; a source node transmit channel; a duration; a number of frames in TXOP; and a Radio Counter. A CC-ACK frame identifies the individual frame in a sequence of frames that were received successfully. The CC-ACK frame includes a destination node; source node; and a TXOP frame receipt status. Channel Reservation occurs when the source node reserves its data channel for one or multiple frames by sending a CC-RTS frame to the destination node on the control channel, provided the Channel_State indication for the data channel is idle. The Reservation Duration field and number of TXOP frames are set in the CC-RTS. The
destination node sends a CC-CTS in response within SIFS. The reservation request is accepted if the destination node has a Channel_State idle indication for the source node's data channel, and the destination node has available radios to receive the transmission; i.e. the Radio Counter is non-zero. If the reservation request is accepted by the Destination node, the Reservation Duration field is adjusted and the number of frames in the TXOP is repeated in the CC-CTS sent by the destination node and the CC-CTS includes the number of its radios that remain available to receive traffic - that is the Radio Counter. (The latter is not necessary, but it is useful to other nodes with frames to send to the destination node). If the reservation request is declined by the Destination node, the Reservation Duration field in the CC-CTS is set to 0 and the source node in that case sends another CC-RTS with a Reservation Duration field set to 0. Additionally, the destination node will send a CC-CTS with a 0 in the Reservation Duration field in response to a CC-RTS with a Reservation Duration field set to 0. When all frames in a TXOP are transmitted, the destination node will acknowledge the status of the transmit sequence by sending an acknowledgement, called CC-ACK, on the control channel. The frames received successfully will be identified in the CC-ACK. The acknowledgement will be transmitted by contending at the highest access priority Channel Reservation occurs when the source node reserve its data channel for one or multiple frames by sending a CC-RTS frame to the destination node on the control channel, provided the Channel_State indication for the data channel is idle. The Reservation Duration field and number of TXOP frames are set in the CC-RTS. The destination node sends a CC-CTS in response within SIFS. The reservation request is accepted if the destination node has a Channel_State idle indication for the source node's data channel, and the destination node has available radios to receive the transmission; i.e. the Radio Counter is non-zero. If the reservation request is accepted by the
Destination node, the Reservation Duration field is adjusted and the number of frames in the TXOP is repeated in the CC-CTS sent by the destination node and the CC-CTS includes the number of its radios that remain available to receive traffic - that is the Radio Counter. (The latter is not necessary, but it is useful to other nodes with frames to send to the destination node). If the reservation request is declined by the Destination node, the Reservation Duration field in the CC-CTS is set to 0 and the source node in that case sends another CC-RTS with a Reservation Duration field set to 0.
Additionally, the destination node will send a CC-CTS with a 0 in the Reservation Duration field in response to a CC-RTS with a Reservation Duration field set to 0.
When all frames in a TXOP are transmitted, the destination node will acknowledge the status of the transmit sequence by sending an acknowledgement, called CC-ACK, on the control channel. The frames received successfully will be identified in the CC-ACK. The acknowledgement will be transmitted by contention.
Aside from these additions and a special form of acknowledgement (which is discussed below), the CCC protocol observes the rules of the distributed random access protocol of IEEE 802.11 and its amendments (DCF and EDCA) for channel access and virtual carrier sensing, although further enhancements can enable better channel access prioritization.
CCC is backward compatible with existing 802.11 technologies. All nodes, that is both nodes using existing 802.11 technology and CCC compliant nodes, can communicate on the control channel through the existing 802.11 MAC protocol. In addition, a node that secures the reservation of a data channel will transmit on the reserved channel only after listening for a period equal to the arbitration inter-frame space to ensure that the channel is idle. This measure is introduced to allow for coexistence of CCC-compliant stations with legacy/independent stations.
Successful transmissions can be acknowledged, if desired. Nodes with a single radio (which transmit data on the control channel) can employ any of the acknowledgement forms provided by the 802.11 standard and its amendments. The same holds for nodes with two radios, one control radio and one data radio, except in certain situations when communicating with a node with multiple data radios.
Nodes may also transmit a group acknowledgement on the control channel, called the CC-Acknowledgement (CC-ACK), in order to notify the sender of the successful receipt of a TXOP. The CC-Ack would be used in order to avoid adjacent channel interference or in order to avoid exposed nodes.
An 'exposed node' is one that is either within the sensing range of the sender node but outside the interference range of the receiver node - therefore it could not receive a transmission from another node, but could transmit itself; or within the sensing range of the receiver node but outside the interference range of the sender node - therefore it could not transmit but it could receive another transmission directed to it. Mesh networks accentuate the exposed node problem because of the distances between
nodes. Due to the spatial arrangement of a mesh, nodes become exposed and set their NAVs conservatively. New NAV rules allow what would have otherwise been 'exposed nodes' to transmit without causing collisions.
The exposed node problem can be avoided if reservations and acknowledgements are made on a control channel, which is different from the mesh traffic channel. The NAVs are modified accordingly. The exposed node problem causes the NAVs of neighbors of transmitting nodes to be set in an overly conservative way.
A node that can hear a NAV setting request (either a CC-RTS or a CC-CTS) refrains from transmitting, and when receiving a reservation request (i.e., a CC-RTS), it declines the reservation. Such a node may be able to either transmit or receive a transmission concurrently with the transmission that caused its NAV to be set. The node need not, however, refrain from transmitting concurrently if it is sufficiently distant from the destination of the ongoing transmission.
Ack prevents Tx(Rx) by exposed node on the same channel. An exposed node that hears a CC-RTS, but not the CC-CTS sent in response, cannot transmit concurrently because of a possible collision with the Ack. If an Ack were not returned on the same channel, transmission by the exposed node would be possible (e.g. suppressed Ack or Ack on separate channel).
Referring now to Figure 1, as example of an exposed node is shown. In this environment, node C is within a sensing range of node B. Node B is in communication with node A and node C is in communication with node D. When node C sends a CC- RTS to node D, all nodes within sensing range hear the CC-RTS (e.g. node B). Node B sets its NAV accordingly and refrains from transmitting. If a node is not within interference range of the destination of the CC-RTS, that node could transmit simultaneously without causing a collision. Node B can transmit at the same time as C sends a transmission to D. A node that hears a CC-RTS should not accept a CC-RTS directed to itself. Node B could not receive a transmission from Node A while C is transmitting to D.
A second transmission to a destination outside the sensing range of the CC-RTS would be possible from B. Since Node A is outside the sensing range of C, it did not hear the CC-RTS from C and would thus respond with a CC-CTS to a CC-RTS from node B. Node B becomes 'exposed' when node C transmits. Node C becomes 'exposed' when node B transmits.
Another example of the exposed node problem is depicted in Figure 2. In this environment, node C is within a sensing range of node B. Node B is in communication with node A and node C is in communication with node D. When Node D sends a CC- RTS to node C, all nodes within sensing range hear the CC-RTS. Node B sets its NAV accordingly and refrains from transmitting. If a node is not within interference range of the destination of the CC-RTS, it could transmit simultaneously without causing a collision. Node A can transmit at the same time as D sends a transmission to C. A second transmission to a destination outside the sensing range of the CC-RTS would be possible. Since Node A is outside the sensing range of C, it did not hear the CC-CTS from C and could thus send a CC-RTS to node B. A node that hears a CC-CTS should accept a CC-RTS directed to itself. Node B could receive a transmission from Node A while C is transmitting to D. Node B becomes 'exposed' when node D transmits. Node C becomes 'exposed' when node A transmits.
According to the CCC MAC protocol the control channel is used for reservations on traffic channels. The control channel is generally different from the channel carrying data traffic. A group acknowledgement, Mesh Ack (MACK), can be sent on the control channel, upon successful receipt of a TXOP. This is in place of regular Acks (individual or group) that are normally sent on the channel used by the transmission. By removing the Ack from the traffic channel, it is possible for an exposed node to transmit concurrently with a neighbor with a pending NAV-setting request. To determine when a node receiving a CC-RTS can transmit, new NAV rules are used. According to conventional 802.11 NAV rules, a CC-RTS/CC-CTS sets the NAV of a neighbor. Once the NAV is set, a node cannot send a CC-RTS or authorize a CC-RTS by sending a CC- CTS until the NAV expires. The existing NAV-setting rules are not adequate to enable an exposed node to transmit when appropriate.
The new rules for a NAV are as follows. A NAV must distinguish when a node receiving a CC-RTS/CC-CTS can transmit. A NAV must distinguish when a node receiving a CC-RTS/CC-CTS can accept a reservation (i.e., send a CC-CTS). To address the 'exposed node' problem, each node maintains two NAVs for each data channel, NAV_RTS and NAV_CTS. NAV_RTS is updated when receiving a CC-RTS with Reservation duration greater than zero and greater than a current value of the reservation duration. IfNAV-RTS is greater then zero for a channel, a node must decline a CC-RTS reservation request for that channel by sending a CC-CTS with
Reservation duration equal to zero. NAV-CTS is updated when receiving a CC-CTS with Reservation duration greater than zero and greater than a current value of the reservation duration. IfNAV-CTS is greater than zero for a channel, a node must not attempt a reservation on that channel. If a node hears a CC-RTS with a Reservation duration equal to zero the NAV_RTS is not updated. If a node hears a CC-CTS with a Reservation duration equal to zero the NAV_CTS is not updated.
Co-pending patent application titled "Avoiding Hidden Terminals In A Wireless Local Area Networks" attorney docket number AVA06-30, filed on the same date as the present application and which is incorporated by reference in it's entirety, discusses hidden nodes and declining reservations and can be implemented in conjunction with the present invention. The NAV-setting process proposed in order to cancel a channel reservation caused by a declined CC-RTS can be incorporated in the new NAV-setting rules. In response to a CC-RTS, the NAV is set in two steps; a fixed time interval to allow for the reservation handshake, and the remaining reservation time. If a node hears a CC-RTS with Reservation duration greater than zero, following an idle greater than SIFS, it updates the NAV_RTS for the time needed to receive a CC- CTS and a CC-RTS and extends the NAV if a cancellation is not received. If a node hears a CC-RTS with Reservation duration greater than zero, following an idle less than or equal to SIFS, it updates the NAV_RTS for the CC-RTS Reservation duration value. If a node hears a CC-CTS with Reservation duration greater than zero, it updates the NAV_CTS for the CC-CTS Reservation duration value (a simultaneous transmission by the node would cause collision).
The use of double NAVs for a channel enables an exposed node to either receive or transmit without interfering with the transmission for which the channel is reserved through the CC-RTS/CC-CTS. A transmission to or from an exposed node would interfere however with the acknowledgment, which is transmitted in the opposite direction. To avoid such collisions, the acknowledgement can be transmitted on the control channel. In other words, use of the CC-ACK, an acknowledgement transmitted on the control channel following transmission of a TXOP on a data channel, would be needed for acknowledgement to enable a WLAN mesh to prevent exposed nodes.
A flow chart of the presently disclosed method is depicted in Figures IA and IB. The rectangular elements are herein denoted "processing blocks" and represent computer software instructions or groups of instructions. The diamond shaped elements, are
herein denoted "decision blocks," represent computer software instructions, or groups of instructions which affect the execution of the computer software instructions represented by the processing blocks.
Alternatively, the processing and decision blocks represent steps performed by functionally equivalent circuits such as a digital signal processor circuit or an application specific integrated circuit (ASIC). The flow diagrams do not depict the syntax of any particular programming language. Rather, the flow diagrams illustrate the functional information one of ordinary skill in the art requires to fabricate circuits or to generate computer software to perform the processing required in accordance with the present invention. It should be noted that many routine program elements, such as initialization of loops and variables and the use of temporary variables are not shown. It will be appreciated by those of ordinary skill in the art that unless otherwise indicated herein, the particular sequence of steps described is illustrative only and can be varied without departing from the spirit of the invention. Thus, unless otherwise stated the steps described below are unordered meaning that, when possible, the steps can be performed in any convenient or desirable order.
Referring now to Figures 3 A and 3B, a particular embodiment of a method 100 for avoiding exposed nodes in a wireless network is shown. The method begins with processing block 102 which discloses maintaining at a node a first time period (NAVJRTS) for a channel other nodes must refrain from transmitting on the channel. Processing block 204 states maintaining at the node a second timer (NAV_CTS) for the channel other nodes must refrain from transmitting on the channel.
Processing block 206 recites updating the NAV_RTS when a transmission request (CC-RTS) frame is received having a reservation duration value greater than zero and greater than a current value of the NAV_RTS. As shown in processing block 208 the updating the NAVJRTS when a transmission request (CC-RTS) frame is received having a reservation duration value greater than zero and greater than a current value of the NAVJRTS comprises determining if the CC-RTS was received following an idle time greater than a Short InterFrame Space (SIFS) time then updating the NAV_RTS for the time needed to receive a CC-CTS and a CC-RTS and extending the NAVJRTS when a cancellation is not received. As further shown in processing block 210 updating the NAVJRTS when a transmission request (CC-RTS) is received having a reservation duration value greater than zero and greater than a current value of the
NAV-RTS comprises determining if the CC-RTS was received following an idle time not greater than a Short InterFrame Space (SIFS) time then updating the NAV_RTS time period for the CC-RTS reservation duration value.
Processing block 212 discloses updating the NAV_CTS when a transmission response (CC-CTS) frame is received having a reservation duration value greater than zero and greater than a current value of the NAV_CTS. This may include, as shown in processing flock 214, updating the NAV_CTS when a transmission response (CC-CTS) is received having a reservation duration value greater than zero and greater than a current value of the NAV_CTS comprises updating the NAV_CTS time period for the CC-CTS reservation duration value.
Processing continues with processing block 216 which states refraining from updating the NAVJRTS when a CC-RTS frame having a reservation duration equal to zero is received. Processing block 218 recites refraining from updating the NAV_CTS when a CC-CTS frame having a reservation duration equal to zero is received. Processing block 220 depicts that the method further includes maintaining a timer, remembering a forwarding node and a last node of a last CC-MRTS received and maintaining a reservation duration value for the last CC-RTS received. Processing block 222 states when a node receives a CC-RTS with a reservation duration value greater than zero while the timer is at a value of zero, then updating the NAV-RTS for a time interval needed to receive a CC-CTS and a CC-RTS (CC-RTSHSHK), setting the timer to the value of the CC-RTSHSHK and updating the NAVJRTS with a value equal to the reservation duration of the last CC-RTS received when the timer expires. Processing block 224 recites when a node receives a CC-RTS from the same node as the last node with a reservation duration value greater than zero while the timer is greater than zero, then updating the NAVJRTS for the CC-RTS duration value and resetting the timer. Processing block 226 discloses when the node receives a CC-RTS from the same node as the last node having a reservation duration of zero and the timer is greater than zero then resetting the timer. Processing block 228 states when the node receives a CC-CTS having a reservation duration greater than zero then updating the NAV-CTS for the CC_CTS reservation duration value; and processing block 230 recites when the node receives other NAV setting requests then updating the NAV-RTS and the NAV-CTS for the duration value in the NAV-setting frame.
Figure 4 illustrates example architectures of a computer system that is configured as anode 240. The node 240 may be any type of computerized system such as a personal computer, workstation, portable computing device, mainframe, server or the like. In this example, the node includes an interconnection mechanism 211 that couples a memory system 212, a processor 213, and a communications interface 214. The communications interface 214 allows the node 240 to communicate with external devices or systems.
The memory system 212 may be any type of computer readable medium that is encoded with an application 255-A that represents software code such as data and/or logic instructions (e.g., stored in the memory or on another computer readable medium such as a disk) that embody the processing functionality of embodiments of the invention as explained above. The processor 213 can access the memory system 212 via the interconnection mechanism 211 in order to launch, run, execute, interpret or otherwise perform the logic instructions of the applications 255-A for the host in order to produce a corresponding process 255-B. In other words, the process 255-B represents one or more portions of the application 255-A performing within or upon the processor 213 in the computer system.
It is to be understood that embodiments of the invention include the applications (i.e., the un-executed or non-performing logic instructions and/or data) encoded within a computer readable medium such as a floppy disk, hard disk or in an optical medium, or in a memory type system such as in firmware, read only memory (ROM), or, as in this example, as executable code within the memory system 212 (e.g., within random access memory or RAM). It is also to be understood that other embodiments of the invention can provide the applications operating within the processor 213 as the processes. While not shown in this example, those skilled in the art will understand that the computer system may include other processes and/or software and hardware components, such as an operating system, which have been left out of this illustration for ease of description of the invention.
Having described preferred embodiments of the invention it will now become apparent to those of ordinary skill in the art that other embodiments incorporating these concepts may be used. Additionally, the software included as part of the invention may be embodied in a computer program product that includes a computer useable medium. For example, such a computer usable medium can include a readable memory device,
such as a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having computer readable program code segments stored thereon. The computer readable medium can also include a communications link, either optical, wired, or wireless, having program code segments carried thereon as digital or analog signals. Accordingly, it is submitted that that the invention should not be limited to the described embodiments but rather should be limited only by the spirit and scope of the appended claims.
Claims
1. A method comprising: maintaining at a node a first timer (NAV_RTS) for a channel which, if set, prevents the node from authorizing a transmission on the channel to itself; maintaining at the node a second timer (NAV_CTS) for the channel which, if set, prevents the node from transmitting on the channel ; updating said NAV_RTS when a transmission request (CC-RTS) frame is received for that channel having a reservation duration value greater than zero and greater than a current value of said NAV_RTS; and updating said NAV_CTS when a transmission response (CC-CTS) frame is received for that channel having a reservation duration value greater than zero and greater than a current value of said NAV_CTS.
2. The method of claim 1 further comprising refraining from updating said NAVJRTS when a CC-RTS frame having a reservation duration equal to zero is received.
3. The method of claim 1 further comprising refraining from updating said NAV-CTS when a CC-CTS frame having a reservation duration equal to zero is received.
4. The method of claim 1 wherein said updating said NAV_RTS when a transmission request (CC-RTS) frame is received for the channel having a reservation duration value greater than zero and greater than a current value of said NAV_RTS comprises determining if the CC-RTS was received following an idle time greater than a Short InterFrame Space (SIFS) time then updating said NAV-RTS for the time needed to receive a CC-CTS and a CC-RTS and extending the NAV_RTS when a cancellation is not received.
5. The method of claim 1 wherein said updating said NAV-RTS when a transmission request (CC-RTS) is received for the channel having a reservation duration value greater than zero and greater than a current value of said NAVJRTS comprises determining if the CC-RTS was received following an idle time not greater than a Short InterFrame Space (SIFS) time then updating said NAV_RTS time period for the CC- RTS reservation duration value.
6. The method of claim 1 wherein said updating said NAV_CTS when a transmission response (CC-CTS) is received for the channel having a reservation duration value greater than zero and greater than a current value of said NAV_CTS comprises updating said NAV_CTS time period for the CC-CTS reservation duration value.
7. The method of claim 1 further comprising maintaining a timer for the channel, remembering a forwarding node and a last node of a last CC-MRTS received for the channel and maintaining a reservation duration value for the last CC-RTS received for the channel.
8. The method of claim 7 wherein when a node receives a CC-RTS for a channel with a reservation duration value greater than zero while said timer is at a value of zero, then updating the NAV_RTS for the channel for a time interval needed to receive a CC- CTS and a CC-RTS (CC-RTSHSHK), setting said timer to the value of said CC- RTSHSHK and updating the NAV_RTS for the channel with a value equal to the reservation duration of the last CC-RTS received for the channel when said timer expires.
9. The method of claim 7 wherein when a node receives a CC-RTS for a channel from the same node as the last node and the same channel with a reservation duration value greater than zero while said timer is greater than zero, then updating the NAV_RTS for the channel for the CC-RTS duration value and resetting said timer.
10. The method of claim 7 wherein when the node receives a CC-RTS for a channel from the same node and channel as the last node having a reservation duration of zero and said timer is greater than zero then resetting said timer.
11. The method of claim 7 wherein when the node receives a CC-CTS for a channel having a reservation duration greater than zero then updating the NAV-CTS for the channel for the CC_CTS reservation duration value.
12. The method of claim 7 wherein when the node receives other NAV setting requests for a channel then updating the NAV-RTS and the NAV-CTS for the channel for the duration value of the NAV-setting frame.
13. A computer readable medium having computer readable code thereon for avoiding exposed nodes, the medium comprising: instructions for maintaining at a node a first timer (NAV-RTS) for a channel which, if set, prevents the node from authoring a transmission on the channel to itself; instructions for maintaining at the node a second timer (NAV_CTS) for the channel which, if set, prevents the node from transmitting on the channel; instructions for updating said NAV_RTS when a transmission request (CC-RTS) frame is received having a reservation duration value greater than zero and greater than a current value of said NAV-RTS; and instructions for updating said NAV_CTS when a transmission response (CC- CTS) frame is received having a reservation duration value greater than zero and greater than a current value of said NAV_CTS.
14. The computer readable medium of claim 13 further comprising instructions for refraining from updating said NAV-RTS for a channel when a CC-RTS frame having a reservation duration equal to zero is received for the channel.
15. The computer readable medium of claim 13 further comprising instructions for refraining from updating said NAV_CTS for a channel when a CC-CTS frame having a reservation duration equal to zero is received for the channel.
16. The computer readable medium of claim 13 wherein said instructions for updating said NAV_RTS for the channel when a transmission request (CC-RTS) frame is received for the channel having a reservation duration value greater than zero and greater than a current value of said NAV_RTS for the channel comprises instructions for determining if the CC-RTS was received for the channel following an idle time greater than a Short InterFrame Space (SIFS) time then updating said NAVJRTS for the time needed to receive a CC-CTS and a CC-RTS and extending the NAV_RTS when a cancellation is not received.
17. The computer readable medium of claim 13 wherein said instructions for updating said NAVJRTS for the channel when a transmission request (CC-RTS) is received for the channel having a reservation duration value greater than zero and greater than a current value of said NAV_RTS comprises instructions for determining if the CC- RTS was received for the channel following an idle time not greater than a Short InterFrame Space (SIFS) time then updating said NAV_RTS time period for the CC- RTS reservation duration value.
18. The computer readable medium of claim 13 wherein said instructions for updating said NAV-CTS for the channel when a transmission response (CC-CTS) is received for the channel having a reservation duration value greater than zero and greater than a current value of said NAV_CTS comprises instructions for updating said NAV_CTS time period for the CC-CTS reservation duration value.
19. The computer readable medium of claim 13 further comprising instructions for maintaining a timer, remembering a forwarding node and a last node of a last CC-MRTS received for the channel and maintaining a reservation duration value for the last CC- RTS received for the channel.
20. The computer readable medium of claim 19 further comprising instructions wherein when a node receives a CC-RTS for a channel with a reservation duration value greater than zero while said timer is at a value of zero, then updating the NAV_RTS for the channel for a time interval needed to receive a CC-CTS and a CC-RTS (CC- RTSHSHK), setting said timer to the value of said CC-RTSHSHK and updating the NAV_RTS for the channel with a value equal to the reservation duration of the last CC- RTS received for the channel when said timer expires.
21. The computer readable medium of claim 19 further comprising instructions wherein when a node receives a CC-RTS for a channel from the same node as the last node with a reservation duration value greater than zero while said timer is greater than zero, then updating the NAV_RTS for the channel for the CC-RTS duration value and resetting said timer.
22. The computer readable medium of claim 19 further comprising instructions wherein when the node receives a CC-RTS for a channel from the same node as the last node and for the same channel having a reservation duration of zero and said timer is greater than zero then resetting said timer.
23. The computer readable medium of claim 19 further comprising instructions wherein when the node receives a CC-CTS for a channel having a reservation duration greater than zero then updating the NAV-CTS for the channel for the CC_CTS reservation duration value.
24. The computer readable medium of claim 19 further comprising instructions wherein when the node receives other NAV-setting requests for a channel then updating the NAV-RTS and the NAV-CTS for the channel for the duration value in the NAV- setting frame.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008515971A JP5129127B2 (en) | 2005-06-08 | 2006-06-08 | Avoiding exposed node problems in wireless local area networks |
EP06772692A EP1894428A4 (en) | 2005-06-08 | 2006-06-08 | Avoiding exposed node problems in wireless local area networks |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US68833505P | 2005-06-08 | 2005-06-08 | |
US60/688,335 | 2005-06-08 | ||
US69052205P | 2005-06-15 | 2005-06-15 | |
US60/690,522 | 2005-06-15 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2006133415A2 true WO2006133415A2 (en) | 2006-12-14 |
WO2006133415A3 WO2006133415A3 (en) | 2007-05-24 |
Family
ID=37499153
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2006/022485 WO2006133415A2 (en) | 2005-06-08 | 2006-06-08 | Avoiding exposed node problems in wireless local area networks |
PCT/US2006/022484 WO2006133414A2 (en) | 2005-06-08 | 2006-06-08 | Avoiding hidden terminals in wireless local area networks |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2006/022484 WO2006133414A2 (en) | 2005-06-08 | 2006-06-08 | Avoiding hidden terminals in wireless local area networks |
Country Status (7)
Country | Link |
---|---|
US (2) | US7616655B2 (en) |
EP (1) | EP1894428A4 (en) |
JP (1) | JP5129127B2 (en) |
KR (2) | KR20080016943A (en) |
DE (1) | DE112006001523B4 (en) |
GB (1) | GB2443112B (en) |
WO (2) | WO2006133415A2 (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011526467A (en) * | 2008-06-25 | 2011-10-06 | クゥアルコム・インコーポレイテッド | Dynamic control blanking in heterogeneous networks |
WO2012167193A3 (en) * | 2011-06-03 | 2013-01-24 | Qualcomm Incorporated | Systems and methods for receiver based clear channel assessment |
US8462686B2 (en) | 2008-06-23 | 2013-06-11 | Thomson Licensing | Apparatus for collision mitigation of multicast transmissions in wireless networks |
US8472365B2 (en) | 2008-06-26 | 2013-06-25 | Thomson Licensing | Method and system for acknowledgement and retransmission of multicast data in wireless local area networks |
US8514763B2 (en) | 2008-06-26 | 2013-08-20 | Thomson Licensing | Apparatus for requesting acknowledgement and transmitting acknowledgement of multicast data in wireless local area networks |
US8553548B2 (en) | 2008-06-23 | 2013-10-08 | Thomson Licensing | Collision mitigation for multicast transmission in wireless local area networks |
US8705383B2 (en) | 2008-06-18 | 2014-04-22 | Thomson Licensing | Contention based medium reservation for multicast transmission in wireless local area networks |
US8737281B2 (en) | 2008-06-18 | 2014-05-27 | Thomson Licensing | Apparatus for multicast transmissions in wireless local area networks |
Families Citing this family (47)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7961749B2 (en) * | 2005-08-18 | 2011-06-14 | Samsung Electronics Co., Ltd. | Signaling method and system for channel switching in a wireless local area network |
JP4604916B2 (en) * | 2005-08-29 | 2011-01-05 | パナソニック株式会社 | Wireless network system, wireless communication method, and wireless communication apparatus |
US8102871B1 (en) * | 2005-11-10 | 2012-01-24 | Ozmo, Inc. | Method and apparatus for medium reservation and medium reservation modification in a communication system |
JP5028476B2 (en) | 2006-04-24 | 2012-09-19 | インターデイジタル テクノロジー コーポレーション | Method and signaling procedure for TXOP usage in a wireless mesh network |
US7940688B1 (en) * | 2006-05-15 | 2011-05-10 | Avaya Inc. | Method and apparatus for canceling channel reservations in a wireless network |
US7969920B2 (en) * | 2006-05-18 | 2011-06-28 | Xocyst Transfer Ag L.L.C. | Communication roaming systems and methods |
US20100226308A1 (en) * | 2006-08-15 | 2010-09-09 | Comhouse Wireless Lp | node- arbitrated media access control protocol for ad hoc broadcast networks carrying ephemeral information |
EP2084862B1 (en) * | 2006-11-10 | 2013-06-19 | Broadcom Corporation | A serial clear to send to self messaging procedure |
KR101316621B1 (en) * | 2007-01-11 | 2013-10-15 | 인하대학교 산학협력단 | Method and apparatus for communicating of distributed network system in a cognitive radio technique |
JP4888396B2 (en) * | 2007-03-05 | 2012-02-29 | ソニー株式会社 | Wireless communication system, wireless communication apparatus, wireless communication method, and computer program |
US8144676B2 (en) * | 2007-09-04 | 2012-03-27 | Conexant Systems, Inc. | Network allocation |
US20090138603A1 (en) * | 2007-11-28 | 2009-05-28 | Qualcomm Incorporated | Protection for direct link setup (dls) transmissions in wireless communications systems |
US8320358B2 (en) * | 2007-12-12 | 2012-11-27 | Qualcomm Incorporated | Method and apparatus for resolving blinded-node problems in wireless networks |
FR2928479B1 (en) * | 2008-03-05 | 2011-07-01 | Somfy Sas | METHOD OF COMMUNICATING BETWEEN A FIRST NODE AND A SECOND NODE OF A DOMOTIC INSTALLATION |
JP5173526B2 (en) * | 2008-03-28 | 2013-04-03 | 株式会社東芝 | Wireless system, wireless base station and wireless terminal |
US8179867B2 (en) * | 2008-05-09 | 2012-05-15 | Lg Electronics Inc. | Apparatus and method for transmission opportunity in mesh network |
KR101452504B1 (en) | 2008-06-18 | 2014-10-23 | 엘지전자 주식회사 | Channel access mechanism for Very High Throughput (VHT) wireless local access network system and station supporting the channel access mechanism |
US9066267B2 (en) * | 2008-08-29 | 2015-06-23 | Intel Corporation | Device, method and system of establishing a protected time during an allocated time |
US8218493B2 (en) * | 2008-09-08 | 2012-07-10 | Wisconsin Alumni Research Foundation | System and method for interference mitigation in wireless networks |
TWI398178B (en) * | 2008-09-25 | 2013-06-01 | Skyphy Networks Ltd | Multi-hop wireless systems having noise reduction and bandwidth expansion capabilities and the methods of the same |
FR2940568A1 (en) * | 2008-12-22 | 2010-06-25 | Thomson Licensing | METHOD FOR TRANSMITTING IN A WIRELESS NETWORK AND CORRESPONDING COMMUNICATION MANAGEMENT METHOD |
KR101622262B1 (en) | 2009-03-09 | 2016-05-18 | 코닌클리케 필립스 엔.브이. | Method for controlling medium access in a mesh network using allocation vectors and station carrying out such method |
US8503359B2 (en) | 2009-06-26 | 2013-08-06 | Intel Corporation | Use of delayed clear-to-send and denial-to-send in directional wireless networks |
US9173234B2 (en) | 2010-03-31 | 2015-10-27 | Qualcomm Incorporated | Protection mechanisms for multi-user MIMO transmissions |
US8989066B2 (en) * | 2010-03-31 | 2015-03-24 | Qualcomm, Incorporated | Protection mechanisms for multi-user MIMO transmissions |
US9031054B2 (en) * | 2010-07-09 | 2015-05-12 | Nokia Corporation | Reservation response and multi-user transmissions |
US8681612B2 (en) * | 2010-10-07 | 2014-03-25 | Qualcomm Incorporated | Methods and devices to implement a reduced contention period to facilitate channel access for access terminals operating in a wireless communication environment |
US8958307B2 (en) | 2010-12-25 | 2015-02-17 | Intel Corporation | Enabling coexistence of high-density and low-density transmissions |
KR101762699B1 (en) * | 2011-01-25 | 2017-07-28 | 삼성전자주식회사 | Transmitting device, receiving device and communication method thereof |
US8923146B2 (en) * | 2011-08-31 | 2014-12-30 | Nokia Corporation | Channel reservation procedure |
CN103002591B (en) | 2011-09-15 | 2015-09-30 | 华为技术有限公司 | A kind of the method for NAV control, device, system and node are carried out to node |
US9137826B2 (en) * | 2011-09-16 | 2015-09-15 | Qualcomm Incorporated | Apparatus and method for transmission and recovery modes for an RTS/CTS system that utilizes multichannels |
CN102523603B (en) * | 2011-12-27 | 2016-01-20 | 重庆大学 | A kind of monitoring of isomerous wireless mesh network and method of estimation |
MY164492A (en) | 2012-12-06 | 2017-12-29 | Mimos Berhad | A system and method for routing in a network |
US10306672B2 (en) * | 2013-05-03 | 2019-05-28 | Qualcomm Incorporated | Transmit opportunity (TXOP) based channel reuse |
EP2992725B1 (en) * | 2013-05-03 | 2020-04-15 | Interdigital Patent Holdings, Inc. | Methods and apparatus for wifi sectorization mac enhancement |
US9537688B2 (en) | 2013-07-05 | 2017-01-03 | Qualcomm Incorporated | Methods and apparatus for clear channel assessment |
US9337884B2 (en) * | 2013-09-18 | 2016-05-10 | Gwangju Institute Of Science And Technology | Medium access control method in single channel wireless network environment |
WO2015094046A1 (en) * | 2013-12-18 | 2015-06-25 | Telefonaktiebolaget L M Ericsson (Publ) | Transmitting and receving wireless devices and respective methods performed thereby for transmission of data in a contention based wireless network |
EP3089395B1 (en) * | 2014-01-21 | 2021-09-22 | Huawei Technologies Co., Ltd. | Data transmission method and device |
EP2950602B1 (en) * | 2014-05-29 | 2017-04-26 | Nxp B.V. | Wireless network and method |
US10405349B2 (en) | 2014-11-07 | 2019-09-03 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Media access control for license-assisted access |
KR102441711B1 (en) * | 2014-11-20 | 2022-09-13 | 한국전자통신연구원 | Data communicating method in overlapping basic service sets environment |
US9872298B2 (en) * | 2015-04-16 | 2018-01-16 | Qualcomm Incorporated | System and method for reducing collisions in wireless networks |
US10257857B2 (en) * | 2015-09-28 | 2019-04-09 | Newracom, Inc. | Apparatus and methods for TXOP duration field in PHY header |
US10149321B2 (en) | 2016-09-30 | 2018-12-04 | Qualcomm Incorporated | Multiple timers for request to send and clear to send communications |
US10165598B2 (en) * | 2016-12-14 | 2018-12-25 | Aruba Networks, Inc. | Wireless medium clearing |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2004109473A2 (en) | 2003-06-06 | 2004-12-16 | Meshnetworks, Inc. | System and method to provide fairness and service differentiation in ad-hoc networks |
US20050002355A1 (en) | 2003-04-28 | 2005-01-06 | Sony Corporation | Communication system, a communication method, and a communication apparatus |
Family Cites Families (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5844905A (en) * | 1996-07-09 | 1998-12-01 | International Business Machines Corporation | Extensions to distributed MAC protocols with collision avoidance using RTS/CTS exchange |
US7054329B2 (en) * | 2000-07-07 | 2006-05-30 | Koninklijke Philips Electronics, N.V. | Collision avoidance in IEEE 802.11 contention free period (CFP) with overlapping basic service sets (BSSs) |
US7058074B2 (en) | 2000-11-01 | 2006-06-06 | Texas Instruments Incorporated | Unified channel access for supporting quality of service (QoS) in a local area network |
US7027462B2 (en) * | 2001-01-02 | 2006-04-11 | At&T Corp. | Random medium access methods with backoff adaptation to traffic |
US7305004B2 (en) * | 2001-01-16 | 2007-12-04 | At&T Corp. | Interference suppression methods for 802.11 |
US7046690B2 (en) * | 2001-01-16 | 2006-05-16 | At&T Corp. | Interference suppression methods for 802.11 |
US20020172186A1 (en) * | 2001-04-09 | 2002-11-21 | Peter Larsson | Instantaneous joint transmit power control and link adaptation for RTS/CTS based channel access |
US7164671B2 (en) * | 2001-12-27 | 2007-01-16 | Koninklijke Philips Electronics N.V. | Overlapping network allocation vector (ONAV) for avoiding collision in the IEEE 802.11 WLAN operating under HCF |
US6693888B2 (en) * | 2001-06-06 | 2004-02-17 | Networks Associates Technology, Inc. | Method and apparatus for filtering that specifies the types of frames to be captured and to be displayed for an IEEE802.11 wireless LAN |
US7161951B1 (en) * | 2001-06-12 | 2007-01-09 | At&T Corp. | Mechanism for implementing virtual carrier sense |
US7245605B2 (en) * | 2001-11-02 | 2007-07-17 | At&T Corp. | Preemptive packet for maintaining contiguity in cyclic prioritized multiple access (CPMA) contention-free sessions |
DE10214117B4 (en) * | 2002-03-28 | 2005-06-23 | Siemens Ag | Adaptive modulation and other extensions of the physical layer in multiple access systems |
JP2004023564A (en) * | 2002-06-18 | 2004-01-22 | Canon Inc | Device and method for controlling radio communication |
US7031336B2 (en) * | 2002-08-26 | 2006-04-18 | Colubris Networks, Inc. | Space-time-power scheduling for wireless networks |
US20040162024A1 (en) * | 2003-02-14 | 2004-08-19 | Wentink Maarten Menzo | Embedding class of service information in MAC control frames |
US7315528B2 (en) * | 2003-08-11 | 2008-01-01 | Agere Systems Inc. | Management of frame bursting |
US8274961B2 (en) * | 2003-10-24 | 2012-09-25 | Sony Corporation | Apparatus and associated methodology of adjusting a RTS/CTS transmission protocol |
JP4005974B2 (en) * | 2004-01-09 | 2007-11-14 | 株式会社東芝 | COMMUNICATION DEVICE, COMMUNICATION METHOD, AND COMMUNICATION SYSTEM |
JP4266192B2 (en) * | 2004-03-05 | 2009-05-20 | 株式会社東芝 | Wireless communication apparatus and wireless communication method |
US7965691B2 (en) * | 2004-06-01 | 2011-06-21 | Broadcom Corporation | Network time reservation cancellation |
JPWO2006001085A1 (en) * | 2004-06-29 | 2008-04-17 | 三菱電機株式会社 | Wireless terminal station and wireless communication system |
US7330457B2 (en) * | 2004-10-07 | 2008-02-12 | Polytechnic University | Cooperative wireless communications |
CN100477613C (en) * | 2004-11-25 | 2009-04-08 | 都科摩(北京)通信技术研究中心有限公司 | Distributed wireless access method and apparatus based on network distribution vector table |
US7768988B2 (en) * | 2005-02-22 | 2010-08-03 | Intel Corporation | Method and apparatus to perform network medium reservation in a wireless network |
US7843819B1 (en) * | 2005-03-29 | 2010-11-30 | Avaya Inc. | Protocol for wireless multi-channel access control |
KR101175813B1 (en) * | 2005-06-02 | 2012-08-24 | 삼성전자주식회사 | System and method of congestion control in wireless mesh networks |
US7796566B2 (en) * | 2005-06-22 | 2010-09-14 | Texas Instruments Incorporated | Methods and apparatus to perform dynamic channel management and dynamic bandwidth changes in wireless local area networks |
US7385961B2 (en) * | 2005-06-27 | 2008-06-10 | Intel Corporation | Contending for the medium with a mixture of backwards-compatible wireless devices |
-
2006
- 2006-06-08 US US11/449,921 patent/US7616655B2/en active Active
- 2006-06-08 KR KR1020087000461A patent/KR20080016943A/en not_active Application Discontinuation
- 2006-06-08 US US11/449,922 patent/US7656854B2/en active Active
- 2006-06-08 WO PCT/US2006/022485 patent/WO2006133415A2/en active Application Filing
- 2006-06-08 DE DE112006001523T patent/DE112006001523B4/en active Active
- 2006-06-08 GB GB0800243A patent/GB2443112B/en active Active
- 2006-06-08 JP JP2008515971A patent/JP5129127B2/en active Active
- 2006-06-08 WO PCT/US2006/022484 patent/WO2006133414A2/en active Application Filing
- 2006-06-08 KR KR1020087000343A patent/KR20080021764A/en not_active Application Discontinuation
- 2006-06-08 EP EP06772692A patent/EP1894428A4/en not_active Withdrawn
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050002355A1 (en) | 2003-04-28 | 2005-01-06 | Sony Corporation | Communication system, a communication method, and a communication apparatus |
WO2004109473A2 (en) | 2003-06-06 | 2004-12-16 | Meshnetworks, Inc. | System and method to provide fairness and service differentiation in ad-hoc networks |
Non-Patent Citations (1)
Title |
---|
See also references of EP1894428A4 |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8705383B2 (en) | 2008-06-18 | 2014-04-22 | Thomson Licensing | Contention based medium reservation for multicast transmission in wireless local area networks |
US8737281B2 (en) | 2008-06-18 | 2014-05-27 | Thomson Licensing | Apparatus for multicast transmissions in wireless local area networks |
US8462686B2 (en) | 2008-06-23 | 2013-06-11 | Thomson Licensing | Apparatus for collision mitigation of multicast transmissions in wireless networks |
US8553548B2 (en) | 2008-06-23 | 2013-10-08 | Thomson Licensing | Collision mitigation for multicast transmission in wireless local area networks |
US9974065B2 (en) | 2008-06-25 | 2018-05-15 | Qualcomm Incorporated | Dynamic control blanking in heterogeneous networks |
JP2011526467A (en) * | 2008-06-25 | 2011-10-06 | クゥアルコム・インコーポレイテッド | Dynamic control blanking in heterogeneous networks |
JP2014096827A (en) * | 2008-06-25 | 2014-05-22 | Qualcomm Incorporated | Dynamic control blanking in heterogeneous networks |
US8472365B2 (en) | 2008-06-26 | 2013-06-25 | Thomson Licensing | Method and system for acknowledgement and retransmission of multicast data in wireless local area networks |
US8514763B2 (en) | 2008-06-26 | 2013-08-20 | Thomson Licensing | Apparatus for requesting acknowledgement and transmitting acknowledgement of multicast data in wireless local area networks |
KR20140031965A (en) * | 2011-06-03 | 2014-03-13 | 퀄컴 인코포레이티드 | Systems and methods for receiver based clear channel assessment |
EP2806687A1 (en) * | 2011-06-03 | 2014-11-26 | Qualcomm Incorporated | Systems and methods for receiver based clear channel assessment |
KR101629867B1 (en) | 2011-06-03 | 2016-06-13 | 퀄컴 인코포레이티드 | Systems and methods for receiver based clear channel assessment |
US9392469B2 (en) | 2011-06-03 | 2016-07-12 | Qualcomm Incorporated | Systems and methods for receiver based clear channel assessment |
WO2012167193A3 (en) * | 2011-06-03 | 2013-01-24 | Qualcomm Incorporated | Systems and methods for receiver based clear channel assessment |
Also Published As
Publication number | Publication date |
---|---|
DE112006001523B4 (en) | 2012-09-06 |
GB2443112A (en) | 2008-04-23 |
GB0800243D0 (en) | 2008-02-13 |
US7656854B2 (en) | 2010-02-02 |
EP1894428A2 (en) | 2008-03-05 |
KR20080021764A (en) | 2008-03-07 |
JP2009510803A (en) | 2009-03-12 |
KR20080016943A (en) | 2008-02-22 |
JP5129127B2 (en) | 2013-01-23 |
WO2006133414A3 (en) | 2007-04-05 |
DE112006001523T5 (en) | 2008-07-24 |
US20070002887A1 (en) | 2007-01-04 |
WO2006133414A2 (en) | 2006-12-14 |
GB2443112B (en) | 2010-01-06 |
WO2006133415A3 (en) | 2007-05-24 |
EP1894428A4 (en) | 2011-12-28 |
US20070002814A1 (en) | 2007-01-04 |
US7616655B2 (en) | 2009-11-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7616655B2 (en) | Avoiding exposed node problems in wireless local area networks | |
EP1768441B1 (en) | Coordinating adjacent channel transmissions on multiple radio nodes | |
US7860054B2 (en) | Method and apparatus for using single-radio nodes and multi-radio nodes in a network | |
US7843819B1 (en) | Protocol for wireless multi-channel access control | |
EP2289257B1 (en) | Apparatus and computer program storage device for multicast transmissions in wireless local area networks | |
US7693175B1 (en) | Prioritized access in a multi-channel MAC protocol | |
KR101531475B1 (en) | Method and apparatus imposing random delays for avoiding hidden terminal collisions in wireless mesh networks | |
US7940688B1 (en) | Method and apparatus for canceling channel reservations in a wireless network | |
US8737281B2 (en) | Apparatus for multicast transmissions in wireless local area networks | |
US20020120740A1 (en) | Shared communications channel access in an overlapping coverage environment | |
JP2011525773A (en) | Method and apparatus for multicast transmission | |
BRPI0403932B1 (en) | WIRELESS COMMUNICATION SYSTEM, WIRELESS COMMUNICATION METHOD, AND WIRELESS COMMUNICATION STATION | |
EP1988726A2 (en) | Broadcast/multicast data in a wireless network | |
US7864796B1 (en) | Start-to-finish reservations in distributed MAC protocols for wireless LANs | |
EP1748602B1 (en) | Broadcast/Multicast data in a wireless network | |
EP2070262A1 (en) | Wireless network | |
US7688783B1 (en) | Mixing basic service set (BSS) traffic and mesh forwarding traffic | |
CA2588013A1 (en) | Broadcast/multicast data in a wireless network | |
KR20140016128A (en) | Method for transmitting data using implicit forward orderinginformation obtained through dcf(distributed coordination function) contention in wireless lan, and wireless communication device for transmitting data using it |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 200680025818.2 Country of ref document: CN |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
ENP | Entry into the national phase |
Ref document number: 2008515971 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2006772692 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1020087000461 Country of ref document: KR |