GB2520692A - Method and device for data communication in an ad-hoc wireless network - Google Patents

Abstract

The invention relates to data communication over an ad-hoc wireless network. A source sends data to a receiver using a sliding window protocol. The receiver delays acknowledgment of the received data to prevent, for a predetermined delay duration, the source from requesting access to the network. The receiver determines a time from which it decides to authorize the source to send new data. The receiver acknowledges a subset of received data to the source at the determined time within a transmission opportunity TXOP, so as to release the source's transmission blocking constraint due to the sliding window protocol. The receiver allocates the source with a transmission period following the acknowledgment in TXOP, for the source to send the new data. A size of the subset is less than a size of the allocated transmission period, to ensure the source remains blocked from new transmission at the end of TXOP.

Description

METHOD AND DEVICE FOR DATA COMMUNICATION

IN AN AD-HOC WIRELESS NETWORK

FIELD OF THE INVENTION

The present invention relates generally to communication networks and more specifically to methods and devices for data communication over an ad-hoc Ad-hoc wireless networks refer to a decentralized type of wireless network, La which does not rely on a pre-existing infrastructure, but instead each node communicates directly with other nodes and may participate in routing data by forwarding data for other nodes,

BACKGROUND OF THE INVENTION

Wireless local area networks (WLAN5), such as a wireless medium in a communication network using Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA), are founded on the principles of collision avoidance. Such networks may also conform to a communication standard such as a communication protocol of 802.11 type e.g. Medium Access Control (MAC).

The IEEE 802.11 MAC standard defines the way WLAN5 must work at the physical and medium access control (MAC) level. Typically, the 802.11 MAC (Medium Access Control) relies on a contention-based mechanism based on the so-called "Carrier Sense Multiple Access with Collision Avoidance" (CSMA/CA) technique.

The 802.11 medium access protocol standard is mainly directed to the waiting management of communication nodes waiting for the medium to become idle so as to try to access to the medium.

Figure 1 illustrates a communication system in which several communication nodes exchange data packets or frames over a radio transmission channel 100 of a wireless local area network (WLAN).

Access to the shared radio medium to send data frames is based on the CSMA/CA technique, for sensing the carrier and avoiding collision by separating concurrent transmissions in space and time.

Carrier sensing in CSMA/CA is performed by both physical and virtual mechanisms. Virtual carrier sensing is achieved by transmitting control frames to reserve the medium prior to transmission of data frames.

Then after a transmitting or source node first attempts, through the physical mechanism, to sense a medium that has been idle for at least one DIFS (standing for Distributed InterErame Spacing) time period, before transmitting data frames.

However, if it is sensed that the shared radio medium is busy during the DIFS period, the transmitting node still waits until the radio medium becomes idle. To do so, it starts a countdown backoff counter designed to expire after a number of timeslots, chosen randomly between [0,CW], CW (integer) being referred to as the contention window. This backoff mechanism or procedure is the basis of the collision avoidance mechanism that defers the transmission time for a random interval, thus reducing the probability of collisions on the shared channel. After the backoff time period, the transmitting node may send the data frames.

One problem of wireless data communications is that it is not possible for the transmitting node to listen while sending, thus preventing the transmitting node from detecting data corruption due to channel fading or interference or collision phenomena. A transmitting node remains unaware of the corruption of the data frames sent and continues to transmit the frames unnecessarily, thus wasting access time.

The Collision Avoidance mechanism of CSMA/CA thus provides positive acknowledgement (ACK) of the sent data frames by the receiving node in case of successful frame reception, to notify the transmitting node that no corruption of the sent data frames occurred.

The ACK is transmitted at the end of reception of the data frame, immediately after a period of time called Short lnterFrame Space (SIFS).

If the transmitting node does not receive the ACK within a specified ACK timeout or detects the transmission of a different frame on the channel, it may infer data frame loss. In that case, it generally reschedules the frame transmission according to the above-mentioned backoff procedure.

To improve the Collision Avoidance efficiency of CSMA/CA, a four-way handshaking mechanism is optionally implemented. One implementation is known as the RTS/CTS exchange, defined in the 802.11 standard.

The RTS/CTS exchange consists in exchanging control frames to reserve the radio medium prior to transmitting data frames during a transmission opportunity called TXOP in the 802.11 standard as described below, thus protecting data transmissions from any further collisions.

The backoff procedure is one of the first processes to be implemented in the communication nodes.

Figure 2 illustrates the behaviour of three groups of nodes during a conventional communication over a IEEE 802.11 medium: transmitting or source node 20, receiving or addressee or destination node 21 and other nodes 22 not involved in the current communication.

Upon starting the backoff process 270 prior to transmitting data, a station e.g. transmitting node 20, initializes its backoff time counter to a random value as explained above. The backoff time counter is decremented once every time slot interval 260 for as long as the radio medium is sensed idle (count down starts from TO, 23 as shown in the Figure).

The time unit in the 802.11 standard is the slot time called aSlotTime' parameter. This parameter is specified by the PHY (physical) layer (for example, aSlotTime is equal to 9ps for the 802.1 in standard). All dedicated space durations (e.g. backoff) are multiples of this time unit.

The communication nodes forming the same 802.11 cell of the radio network have quasi-synchronous clock to ensure a consistent number of time slots 260 elapse simultaneously within all communication nodes, e.g. during a back-off countdown procedure.

The backoff time counter is frozen' or suspended when a transmission is detected on the radio medium channel (countdown is stopped at Ti, 24 for other nodes 22 having their backoff time counter decremented).

The countdown of the backoff time counter is resumed or reactivated when the radio medium is sensed idle anew, after a DIES time period. This is the case for the other nodes at T2, 25 as soon as the transmission opportunity TXOP granted to transmifting node 20 ends and the DIFS period 28 elapses. DIES 28 (DOE inter-frame space) thus defines the minimum waiting time for a transmitting node before trying to transmit some data. In practice, DIES = SIFS + 2 * aSlotTime.

When the backoff time counter reaches zero 26 at Ti, the corresponding node 20 requests access onto the medium in order to be granted a TXOP, and the backoff time counter is reinitialized 29 using a new random backoff value.

In the example of the Figure implementing the RTSICTS scheme, at Ti, the transmitting node 20 that wants to transmit data packets or frames 230 sends a special short frame or message acting as a medium access request to reserve the radio medium, instead of the data frames themselves, just after the channel has been sensed idle for a DIES or after the backoff period as explained above.

The medium access request is known as a Request-To-Send (RTS) message or frame. The RTS frame generally includes the address of the receiving node ("destination 21") and the duration for which the radio medium is to be reserved for transmitting the control frames (RTSICTS) and the data frames 230.

Upon receiving the RTS frame and if the radio medium is sensed as being idle, the receiving node 21 responds, after a SIFS time period 27 (for example, SIFS is equal to 16 ys for the 802.11 n standard), with a medium access response, known as a Clear-To-Send (CTS) frame. The CTS flame indicates the remaining time required for transmitting the data frames, computed from the time point at which the CTS frame starts to be sent.

The CTS frame is considered by the transmitting node 20 as an acknowledgment of its request to reserve the shared radio medium for a given time duration.

Thus, the transmitting node 20 expects to receive a CTS frame 220 from the destination node 21 before sending data 230 using unique and unicast (one source address and one addressee or destination address) frames.

The transmitting node 20 is thus allowed to send the data frames 230 upon correctly receiving the CTS frame 220 and after a new SIFS time period 27. In IEEE 802.11, the data are sent as MAC (Medium Access Control) Service Data Units (MSDUs) encapsulated into MAC Protocol Data Units (MPDU5).

An ACK frame 240 is sent by the receiving node 21 after having correctly received the data frames MPDU5 sent, after a new SIFS time period 27.

If the transmitting node 20 does not receive the ACK 240 within a specified ACK Timeout, or if it detects the transmission of a different frame on the radio medium, it reschedules the frame transmission according to the backoff procedure.

Since the RTS/CTS four-way handshaking mechanism 210/220 is optional in the 802.11 standard, it is possible for the transmitting node 20 to send data frames 230 immediately upon its backoff time counter reaching zero (i.e. at Ti).

The requested time duration for transmission defined in the RTS and CTS frames defines the length of the granted transmission opportunity TXOP, and can be read by any listening node ("other nodes 22" in Figure 2) in the radio network. The length of TXOP cannot be greater than a maximum value, TXOP_Limit, defined in the IEEE 802.11 standard.

To do so, each node has in memory a data structure known as the network allocation vector or NAV to store the time duration for which it is known that the medium will be busy. When listening to a control frame (RTS 210 or CTS 220) not addressed to itself, a listening node 22 updates its NAys (NAV 255 associated with RTS and NAV 250 associated with CTS) with the requested transmission time duration specified in the control frame. The listening node 22 thus keeps in memory the time duration for which the radio medium will remain busy.

Access to the radio medium for the other nodes 22 is consequently deferred 30 by suspending 31 their associated timer and then by later resuming 32 the timer when the NAV has expired.

This prevents the listening nodes 22 from transmitting any data or control frames during that requested period.

It is possible that the destination node 21 does not receive the RTS frame 210 correctly due to a message/frame collision or to fading. Even if it does receive it, the destination node 21 may not always respond with a CTS 220 because, for example, its NAV is set (i.e. another node has already reserved the medium). In any case, the transmitting node 20 enters into a new backoff procedure.

The RTS/CTS four-way handshaking mechanism is very efficient in terms of system performance, in particular with regard to large frames since it reduces the length of the messages involved in the contention process.

In detail, assuming perfect channel sensing by each communication node, collision may only occur when two (or more) frames are transmitted within the same time slot after a DIFS or when their own back-off counter has reached zero nearly at the same time Ti). If both transmitting nodes use the RTS/CTS mechanism, this collision can only occur for the RTS frames. Fortunately, such collision is early detected by the transmitting nodes since it is quickly determined that no CTS response is received.

However, such collisions limit the optimal functioning of the radio network. It is an aim of the present invention to reduce such collisions to improve radio medium access.

In an illustrative example, a collision occurring when a communication node has high priority data to send is liable to detrimentally postpone the sending of such high priority data.

In the example shown in Figure 5, a source node and a receiving node may concurrently request a next medium access at the same time if their backoff counters expire at the same moment. As a consequence, their RTS messages collide.

In another example, a collision may appear for a single receiving node involved in several data communications, when the source nodes of these communications collide upon each trying simultaneously to be granted transmission opportunities to communicate with the receiver node.

All these collisions are because the source and receiving nodes have no mean to know the communication timeslots which are going to be requested by and granted to the other communication nodes.

Another problem exists with the above mechanism described with reference to Figure 2. Sometimes a receiving node may not be willing to continuously receive data from one or more source nodes, for example due to traffic priorities. But the above mechanism does not make it possible for the receiving node to stop the sending of such data from the sources nodes.

The present invention has been devised to address at least one of the foregoing concerns.

SUMMARY OF THE INVENTION

According to a first aspect of the invention, there is provided a method of communicating in an ad-hoc wireless network including a source node and a receiving node, the source node sending data of a data stream to the receiving node using a sliding window protocol, wherein the receiving node delays acknowledgment of the received data to prevent, for a predetermined delay duration, the source node from requesting access to a network medium of the ad-hoc wireless network to send new data.

According to the invention, the receiving node thus drives the acknowledgment of the received data to selectively control the access of the source node to the wireless medium. This makes it possible to avoid undesirable request-to-send frames (RTS) from the source node that would increase collisions during the predetermined duration, and even to avoid the source node sending other data in case the receiving node is not willing to continuously receive data from that source node.

This is achieved by the postponement of the acknowledgment of the received data by the receiving node. This is because, due to the sliding window protocol implemented in the communication nodes, the source node is blocked for new transmission as long as none of the already sent data (the data filling the whole sliding window capacity) is acknowledged by the receiving node. As a consequence, as long as the receiving node has not acknowledged some received data (generally for a predetermined duration), it controls the transmission blocking at the source node and thus prevents the latter from requesting new access to the network. Therefore, collisions and network bandwidth waste are reduced.

By acknowledging some received data, e.g. at the end of the predetermined duration, the receiving node relaxes or releases the window-based constraint that blocks the source node's transmission capacity, by an amount of data equivalent to the acknowledged data. The source node may then resume sending new data once it is allocated or granted a new transmission opportunity.

Note that the window-sized transmission capacity constraint at the source node may result either from a sliding window at the source node or from a sliding window at the receiving node.

According to a second aspect of the invention, there is provided a communication device in an ad-hoc wireless network, comprising a communication module configured to receive data of a data stream sent by a source node using a sliding window protocol, an ack delay module configured to delay acknowledgment of the received data to prevent, for a predetermined delay duration, the source node from requesting access to a network medium of the ad-hoc wireless network to send new data.

The communication device has the same advantages as the above-defined method.

Further features of embodiments of the invention are defined in the dependent appended claims and are explained below in terms of method features.

Corresponding functional modules are therefore optionnaly provided to the communication device as defined above.

In one embodiment, the receiving node determines a time from which it decides to authorize the source node to send new data; and acknowledges a subset of the received data to the source node at the determined time so as to release transmission blocking constraint at the source node due to the sliding window protocol.

In other words, the receiving node decides when the source node is authorized to possibly make a request to access the network medium and then to send data.

In a particular embodiment, the receiving node sizes the subset of received data to acknowledge to an amount of new data it authorizes the source node to send.

This means that the receiving node controls the level of release of the transmission

B

blocking constraint at the source node. This is to avoid the latter having too much new data to send, which could require multiple medium accesses and thus cause risks of collisions.

In another particular embodiment, the subset of received data is acknowledged within a transmission opportunity granted to the receiving node in the ad-hoc wileless network; and a transmission period following the acknowledgment in the granted transmission opportunity is allocated to (or subleased to or shared with) the source node by the receiving node for the source node to send the new data.

This provision makes it possible to reduce source node's requests to access the network medium. This is because the source node can send the new data without making a new medium access request. Collisions and network bandwidth waste are thus reduced.

In one embodiment of the invention, a size of the subset of received data to acknowledge in the granted transmission opportunity is a function of a size (e.g. time length) of the allocated transmission period. Of course this may be the reverse depending on which information (time length or amount of received data to acknowledge) is first determined. Such provision if appropriately used ensures the source node is able to send all the new data it can send during the allocated transmission period, in order to avoid any medium access request from the same source node which would risk collision.

In particular, the size of the subset of received data corresponds to less data (including equal to) than the amount of data that can theoretically be sent during the allocated transmission period, given a physical network bitrate. In other words, the subset of received data is the amount of data the receiving device wants to release or free from transmission blocking constraint at the source node for it to be able to send the same amount of new data.

These provisions aim to provide enough transmission time for the source node to send new data until the source node is again blocked by the sliding window constraint when acknowledgment of the new data sent during the allocated transmission period is delayed. As a result, the source node will not attempt to access the netwoik medium, thus avoiding collisions.

In another embodiment of the invention, acknowledging the subset of received data comprises sending a Block Acknowledgment (BA) frame that includes a starting sequence number and an acknowledgement bitmap, in the granted transmission opportunity to the source node, wherein the starting sequence number and the acknowledgement bitmap are set to acknowledge already-acknowledged received data and the subset of received data only.

This configuration is different from the BA frames of known techniques where only non-previously-acknowledged data are actually acknowledged. According to the above provision, already-acknowledged received data are again acknowledged.

This provision maintains compliance with BA frame-based standards, for example the IEEE 802.11 standard, while making it possible to precisely control the amount of data (equal to the subset) the source node is authorized, by the receiving node, to send, thanks to the release of the transmission blocking constraint. This is because, by adjusting the amount of already-acknowledged received data in the BA frames, the amount of newly acknowledged data is correspondingly adjusted.

For example, seq_RX = seq_TX + ANMP -WinSize, where seq_RX is the starting sequence number set in the BA frame, 5eQTX is a starting sequence number set in a Block Acknowledgment Request (BAR) frame sent by the source node with the sent data, ANMP is a size of the subset of received data (i.e. the amount of data that the receiving device wants to release from transmission blocking constraint at the source node, for example a number of MSDUs) and WinSize is a size of the sliding window defining transmission constraint for the source node.

Compliance with the IEEE 802.11 standard is maintained while having a low complexity process to obtain the starting sequence number for BA frame.

In one particular embodiment, the receiving node receives the data in data units (e.g. MSDUs), and ANMP = floor(N), where floorC) is the floor function and N is an estimated number of data units of the data stream that arrive at the receiving node during a predefined time or that are required by the receiving node.

In a variant, the receiving node receives the data in data units, which data units are aggregated into an aggregate data unit (e.g. A-MSDU) sent by the source device, and ANMP= floor( N I floor( Max_AMSDU_size I N0minaLMSDU_Size)), where floorC) is the floor function, N is an estimated number of data units of the data stream that arrive at the receiving node during a predefined time or that are required by the receiving node, Max_AMSDU_size is a maximum size of an aggregate data unit defined in the ad-hoc wireless network and Nominal_MSDU_Size is an expected size of the data units.

These two definitions of ANMP adapt the release of the transmitting blocking constraint at the source node to the current needs of the data stream, either in terms of data arrival at the receiving node or in terms of data needs at the receiving node (for example to render the data stream in real time) or to avoid underflow/overfiow of a video rendering buffer.

In one embodiment, N = minSl * MeanDataRate I Nominal_MSDU_Size, where minSl is a minimum Service Interval which defines the minimum allowed time between two theoretical medium access requests by the source node, taking into account specifications of the data stream, MeanDataRate is the mean throughput of the data stream, and Nominal_MSDU_Size is an expected size of the data units.

In a variant, N = amount_data! Nominal_MSDU_Size, where amount_data is an amount of data required by an application of the receiving node to use the data stream, and Nominal_MSDU_Size is an expected size of the data units.

These two formulas provide good estimated numbers of data units either arriving on average at the receiving node or required by upper layer applications in the receiving node. Consequently, they are suitable for controlling the release of transmission blocking constraint at the source node (and thus to restore transmission capacity for the source node) to efficiently provide the data stream.

In another embodiment of the invention, during the granted transmission opportunity, the receiving node sends a Block Acknowledgment (BA) frame to the source node to acknowledge the subset of received data, and, after the BA frame, sends a frame transferring transmission rights of the allocated transmission period so that the source node takes control for data transmission of data units over the ad-hoc wireless network during the allocated transmission period.

For example, sending a frame transferring transmission rights comprises sending a frame including an enabled Reverse Direction Grant flag according to IEEE 802.lln standard.

These provisions make it possible to keep full compliance with IEEE 802.11 standard while providing full control of the source node's accesses to the network medium and on source nodes data transmission.

According to a particular embodiment, the transferring transmission rights frame further includes a data field defining a size (e.g. time length) of the allocated transmission period, said size being equal to N * Nominal_MSDU_Size / R, where N is an estimated number of data units of the data stream that arrive at the receiving node during a predefined time or that are required by the receiving node, Nominal_MSDU_Size is an expected size of the data units, and R is a physical network bitrate of the ad-hoc wireless network.

In a variant, the allocated transmission period size may be as follows: ceil(N) * Nominal_MSDU_Size I S, where ceilC) is the ceiling function. In that case, the ANMP can be optionally calculated using the ceil function instead of the floor function as described above. These combinations of functions ensure the number of data units that can be transmitted during the allocated transmission period is higher than the number ANMP of data units that is released from transmission constraint at the source node.

The first approach (using the floor function for calculating ANMF, and using N instead of ceil(N) for the allocated transmission period size) is preferably used when N is calculated based on local criteria, e.g. as an estimated number of data units required by the receiving node. This may help avoiding a local video buffer to overflow.

According to another particular embodiment, after the allocated transmission period in the granted transmission opportunity, the receiving node sends a second Block Acknowledgment (BA) frame to acknowledge a subset of received data from a second source node, and, after the second BA frame, sends a second frame transferring transmission rights of a second transmission period within the granted transmission opportunity so that the second source node takes control for data transmission of data units over the ad-hoc wireless network during the second transmission period.

In embodiments, the second source node is another source node than the previously mentioned source node. In variants, the second source node is the previously mentioned source node.

This provision makes it possible for the receiving node to control the access of several source nodes to the wireless network and/or of the same source node several times within the same transmission opportunity. Of course more than two BA frames and respective allocated transmission periods can be provided consecutively within the granted transmission opportunity to offer controlled access to the radio medium to more than two source nodes and/or several times for the same source node.

In yet another embodiment of the invention, the receiving node implements a Collision Avoidance mechanism using a contention window to access the network medium and to be granted the transmission opportunity, the contention window being a function of stream specifications of the data stream sent by the source node.

This configuration drives the receiving node to access the wireless network (and thus possibly to restore transmission capacity for the source node and to offer transmission time to the latter) depending on the stream specifications. This makes it possible to drive a network access for the receiving node before a time estimated at which the source node would theoretically access the network. This is to reduce, possibly to avoid, transmission buffer overflow at the source node.

According to a particular embodiment, the contention window CW is equal to minSl /TXOP_Limit, where minSl is a minimum Service Interval which defines the minimum allowed time between two theoretical medium access requests by the source node, taking into account specifications of the data stream, and TXOP_Limit is a maximum size (time length) of a transmission opportunity in the ad-hoc wireless network.

According to another particular embodiment, the receiving node implements a plurality of access categories (e.g. four access categories, ACs, in IEEE 802.lln) for which the receiving node receives respective data from source nodes, the access categories being associated with independent backoff counters of the Collision Avoidance mechanism for the receiving node to access the network medium (in particular to acknowledge received data or to send data), and the receiving node, on accessing the network medium upon expiry of one of the backoff counters, acknowledges data received for different access categories from two or more source nodes and allocates subparts of the granted transmission opportunity as transmission periods to the two or more source nodes for them to send new data.

Of course, transferring transmission right frames are preferably sent by the receiving node to make it possible for the two or more source nodes to take control for new data transmission during respective allocated transmission periods.

The receiving node thus controls and provides network access to several source nodes within the same transmission opportunity, regardless of whether or not they are associated with the same AC as the one having the backoff counter expiring.

This results in having a reduced number of medium accesses (RTSs) onto the network medium. This also reduces latency on average for the several source nodes.

In yet another embodiment of the invention, the receiving node receives new data from the source node during the allocated transmission period of the granted transmission opportunity and delays acknowledgment of the received new data for another predetermined delay duration, e.g. until another transmission opportunity is granted to the receiving node.

This maintains the source device with a transmission blocking constraint due to the sliding window protocol, and thus it is prevented from requesting new access to the network medium to send other new data.

All or part of the various embodiments of the invention as defined above may be combined together.

Another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a communication device of an ad-hoc wireless network, causes the communication device to perform the steps of: receiving data of a data stream sent by a source node using a sliding window protocol, delaying acknowledgment of the received data to prevent, for a predetermined delay duration, the source node from requesting access to a network medium of the ad-hoc wireless network to send new data.

The non-transitory computer-readable medium may have features and advantages that are analogous to those set out above and below in relation to the method and device, in particular that of improving collision avoidance.

Another aspect of the invention relates to a method for data communication in an ad-hoc wireless network substantially as herein described with reference to, and as shown in, Figure 8; Figure 9; Figures 8 and 9; Figures 8, 9 and 10 of the accompanying drawings.

Yet another aspect of the invention relates to a communication device in an ad-hoc wireless network substantially as herein described with reference to, and as shown in, Figure 7 of the accompanying drawings.

At least parts of the method according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects which may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium, for example a tangible carrier medium or a transient carrier medium. A tangible carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which: -Figure 1 illustrates a typical wireless communication system in which embodiments of the invention may be implemented; -Figure 2 is a timeline schematically illustrating a conventional communication mechanism according to the IEEE 802.11 standard; -Figure 3 illustrates the IEEE 802.lle EDCA involving access categories; -Figure 4 illustrates the 802.lle/n Block Ack feature applied to an aggregate MPDU; -Figure 5 is a timeline of communication of known systems illustrating RTS collision between a source node and a corresponding receiving node; -Figure 6 is a block diagram illustrating components of a communication device in which embodiments of the invention may be implemented; -Figure 7 illustrates function blocks of the same communication device; -Figure 8 is a timeline similar to Figure 5, illustrating an examplary mechanism of the invention for the receiving node to control source node's medium access; -Figure 9 is a flowchart illustrating general steps of a process according to embodiments of the invention; and -Figure 10 illustrates the behaviour of sequence number parameters in source node's transmission buffer and in receiving node's scoreboard context, at two different instants of the process of Figures 8 and 9.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

The invention provides communication methods and devices for data communication over an ad-hoc wireless network, the physical medium of which being shared between a plurality of communication nodes or devices. An exemplary ad-hoc wireless network is an IEEE 802.1 in network. But the invention applies to any wireless network where a source node sends data of a data stream to a receiving node using a sliding window protocol.

A goal of the invention is to improve collision avoidance by reducing the medium access requests (e.g. RTS) by source nodes. This is achieved when the receiving node delays acknowledgment of the received data to prevent, for a predetermined delay duration, the source node from requesting access to a network medium of the ad-hoc wireless network to send new data.

This is because so long as the sliding window limiting transmission capacity at the source node is full and no acknowledgment of sent data is received by the source node, the source node cannot send new data and thus does not request new access to the network medium.

The postponement of the acknowledgment for a long time also makes it possible for the receiving node to put the source node in a standby mode", i.e. to avoid receiving new data from this source node, so long as the receiving node is not willing to continuously receive data from this node.

The receiving node may then decide when to authorize the source node to start sending new data. This is done by acknowledging some of the received data (generally a subpart or subset of the received data, representing the amount of new data the receiving node authorizes the source node to send) to the source node at that time so as to release transmission blocking constraint at the source node due to the sliding window protocol. From that time (reception of acknowledgment), the source node is free again to send new data (the amount of which is limited by the amount of data acknowledged) from its transmission buffers as soon as a new opportunity to transmit on the network occurs.

To avoid a medium access request being sent from the source node, the receiving node may give a controlled opportunity to the source node for it to send the new data. This opportunity is preferably offered in the same transmission opportunity granted to the receiving node as the acknowledgment of the previously received data.

In other words, a transmission period following the acknowledgment in the transmission opportunity granted to the receiving node is allocated to the source node by the receiving node for the former to send the new data.

This is to avoid risk that the source node attempts to request new access to the network medium, which could result in risk of RTS message collision. To further avoid risk of collision, the receiving node preferably sizes the opportunity offered to the source node to substantially fit the amount of data acknowledged, meaning that the source node will be able to send all the new data it can within this allocated opportunity. No new medium access request would thus be needed for the source node.

To secure source node's blocking due to the sliding window at the end of the granted transmission opportunity, the receiving node, receiving new data from the source node during an allocated transmission period in the granted transmission opportunity, may delay acknowledgment of the received new data for another predetermined delay duration, e.g. until another transmission opportunity is granted to the receiving node.

Examples of design of transmission opportunities granted to the receiving node by which the latter acknowledges some received data and allocates a transmission period to the source node are given below.

Examples of access parameters for the receiving node to efficiently access the network medium are also given below, as well as the management of the receiving node's data queues that concurrently access the network medium and possible managements in case of a plurality of source nodes supplying the receiving node with a plurality of data streams.

The behaviour of communication nodes during a conventional communication over an 802.11 medium has been recalled above with reference to Figures 1 and 2, including the RTS/CTS four-way handshaking mechanism 210/220.

Also, it has been recalled that the original IEEE 802.11 MAC always sends an acknowledgement (ACK) frame 240 after each data frame MPDU 230 received.

In the IEEE 802.1 le standard providing quality of service enhancements to make more efficient use of the wireless channel, an optional feature, called Block ACK (acknowledgment by block), allows two or more data frames 230 to be transmitted before a Block ACK frame is returned to acknowledge the receipt of the data frames.

The Block ACK increases communication efficiency since only one signalling ACK frame is needed to acknowledge a block of frames, while every ACK frame originally used has a significant overhead for radio synchronization.

Block ACK is initiated through a setup and negotiation process between the transmitting or source node and the receiving node.

Once the Block ACK has been negotiated and established, multiple data frames can be transmitted in a contention free burst (or during the TXOP), with SIFS separation between the successive data frames. The Block ACK frame returned to the source node includes an acknowledgment bitmap, each information item (e.g. a bit) of which acknowledging the receipt of one of the data frames.

An improvement of the above standard, known as IEEE 802.lln or High Throughput WLAN standard, proposes two frame aggregation schemes that make it possible to transmit several data frames of the same traffic stream (such as voice, video and best effort data, associated with specific traffic specification) in a burst using an aggregated frame.

The two aggregation schemes, Mac Service Data Units (MSDU) aggregation (namely A-MSDU) and Message Protocol Data Unit (MPDU) aggregation (namely A-MPDU), aggregate multiple MAC service data units (MSDUs or MAC data frame) following the order by which the MSDUs are input in a transmission queue or buffer of the source node. Both aggregation methods reduce the overhead to only a single radio preamble for each frame transmission.

With such aggregation schemes, Block ACK has become mandatory, and the Block ACK (BA) frame returned by the receiving node thus includes an acknowledgement bitmap that covers a larger number of consecutive data frames, wherein each bit indicates whether a corresponding data frame (e.g. MPDU) is acknowledged or not, starting from a first data frame identified using a starting sequence number SSN.

Another aspect that the IEEE 802.lle standard has improved regards the quality of service (QoS), for example latency of data traffic. In the original standard, a communication node includes only one transmission queue/buffer. However, since a subsequent data frame cannot be transmitted until the transmission/retransmission of a preceding frame ends, the delay in transmitting/retransmitting the preceding frame prevents the communication from having QoS.

The IEEE 802.lle has overturned this deficiency in providing quality of service (QoS) enhancements to make more efficient use of the wireless medium.

This standard relies on a coordination function, called hybrid coordination function (HCF), which has two modes of operation: enhanced distributed channel access (EDCA) and HCF controlled channel access (HCCA).

As can be appreciated by one skilled in the art, EDCA is a contention-based channel access function that operates concurrently with HCCA based on a polling mechanism, which is controlled by an hybrid coordinator (HC) co-located with a Q0S Access Point (QAP).

EDCA enhances or extends functionality of the original access DCF method: EDCA has been designed for support of prioritized traffic similar to DiffServ (Differentiated Services), which is a protocol for specifying and controlling network traffic by class so that certain types of traffic get precedence.

EDCA is the dominant channel access mechanism in WLAN5 because it features a distributed and easily deployed mechanism.

The above deficiency of failing to have satisfactory QoS due to delay in frame retransmission can be solved with a plurality of transmission queues/buffers.

QoS support in EDCA is achieved with the introduction of four Access Categories (ACs), and thereby of four corresponding transmission queues or buffers.

Each AC has its own transmission queue/buffer to store corresponding data frames to be transmitted on the network. The data frames, namely the MSDUs, from an upper layer of the protocol stack are mapped onto one of the four AC queues/buffers and thus input in the mapped AC buffer.

Each AC has also its own set of channel access parameters, and is associated with a priority value, thus defining traffic of higher or lower priority of MSDU5.

That means that each AC (and corresponding buffer) acts as an independent DCF contending entity. In other words, the ACs within the same communication node compete one with each other to access the wireless medium and to obtain a transmission opportunity, using the contention mechanism as explained above with reference to Figure 2 for example.

Service differentiation between the ACs is achieved by setting different contention window parameters (CWmin, CWmax), arbitrary inteiframe spaces (AIFS), and transmission opportunity duration limits (TXOP_Limit).

With EDCA, high priority traffic has a higher chance of being sent than low priority traffic: a node with high priority traffic waits a little less (low C before it sends its packet, on average, than a node with low priority traffic.

The four AC buffers are shown in Figure 3a.

Buffers AC3 and A02 are usually reserved for real-time applications (e.g., voice or video transmission). They have the highest priorities, respectively the highest priority and the last-but-one highest priority.

Buffers AC1 and ACO are reserved for best effort and background traffic.

They have the lowest priorities, respectively the last-but-one lowest priority and the lowest priority.

Each data unit, MSDU, arriving at the MAC layer from an upper layer (e.g. [C layer) with a priority is mapped into an AC according to mapping lules. Figure 3b shows an example of mapping between eight priorities of traffic class (User Priorities or UP, 0-7 according IEEE 802.ld) and the four AC5. The data frame is then stored in the buffer corresponding to the mapped AC.

When the backoff procedure of an AC ends, the MAC controller (reference 704 in Figure 7 below) of the transmitting node transmits a data frame from this AC to the physical layer for transmission onto the communication network.

Since the ACs operate concurrently in accessing the wireless medium, it may happen that two ACs of the same communication node have their backoff ending simultaneously. In such a situation, a virtual collision handler of the MAC controller operates a selection of the AC having the highest priority between the conflicting ACs, and gives up transmission of data frames from the ACs having lower priorities.

Then, the virtual collision handler commands those ACs having lower priorities to start again a backoff operation using an increased CW value.

Figure 3c illustrates configurations of a header of a MAC data frame and a QoS control field (300) included in the header of the IEEE 802.11 e MAC frame.

As represented in the Figure, the QoS control field 300 is made of two bytes, including the following information items: Bits BO to B3 are used to store a traffic identifier (TID) which identifies a traffic stream. The traffic identifier takes the value of the transmission priority value (User Priority UP, value between 0 and 7 -see Figure 3b) corresponding to the data conveyed by the data frame or takes the value of a traffic stream identifier (TSID, value between 8 and 15) for other data streams.

Bits B5 and B6 define the ack policy subfield which specifies the acknowledgmenet policy associated with the data frame. This subfield is used to determine how the data frame has to be acknowledged by the receiving node. Usually, it may take three different values as follows: -value equal to "Normal ACK" in the case where the transmitting or source node requires a conventional acknowledgment to be sent (by the receiving node) after a shod interframe space (SIFS) period following the transmission of the data frame; -value equal to "No ACK" in the case where the source node does not require acknowledgment. That means that the receiving node takes no action upon receipt of the data frame; and -value equal to "Block ACK" as defined above. The receiving node takes no action immediately upon receiving the data frame, except the action of recording the state of reception in its scoreboard context. With such a value, the source node is expected to send a Block ACK request (BAR) frame, to which the receiving node responds using the procedure described below.

The other bits B4 and B7-B15 are of less importance for the present invention.

Figure 4 illustrates the Block ACK mechanism in case of use of A-MPDU according to IEEE 802.lln with EDCA-based QoS according to IEEE 802.lle.

The latter standard defines two Block ACK mechanisms: immediate and delayed block acknowledgment.

When using immediate Block ACK, the source node transmits multiple data frames in a contention free burst, separated by SIFS. This is for example the case of an A-MPDU 450 as shown in Figure 4a. The source node has to satisfy the constraints of the transmission opportunity (TXOP) duration it is currently operating within, meaning that the number of MPDU5 in the A-MPDU is limited.

At the end of the burst, the source node transmits a Block ACK request (BAR) frame 410 to request the receiving node to acknowledge receipt of the received frames. The receiving node must immediately reply with a Block ACK (BA) frame 420 containing the acknowledgement status for each data frame of the previous burst of data frames.

The delayed policy allows the block acknowledgement to be sent in a subsequent TXOF following the burst. The same sequence of a contention free burst and BAR frame is used as in the immediate mode. The receiving node simply sends a standard ACK frame in response to the BAR frame, indicating that the Block ACK is taken into account but delayed.

Delayed acknowledgement increases latency, and is provided to support lower performance implementations that are unable to immediately calculate the ACK.

Figure 4b illustrates a conventional BAR frame 410.

The BAR frame 410 is made up of the following fields: a frame control field, a duration field, a RA (Receiver Address) field, a TA (Transmitter Address) field, a Block ACK control field 411 (two-byte long), a Block ACK Info field 412 and a CRC/FCS (Cyclic Redundancy Check, or Frame Check Sequence, or also called

checksum) field.

Block ACK control field 411 includes the traffic identifier TID (traffic stream) corresponding to the data frames to be acknowledged.

Block ACK Information field 412 is (in the IEEE 802.lle standard) or includes (802.lln standard) a "Block ACK starting sequence control" value (BA-SSC), which is the sequence number (SSN) of the oldest MPDU in the frame burst (i.e. A-MPDU) for which an acknowledgement is needed. Note that the sequence number is incremented by one for each new data frame transmitted.

The other fields are of less importance for the present invention.

Figure 4c illustrates a conventional BA frame 420.

The BA frame 420 is made up of the following fields: a frame control field, a duration field, a RA (Receiver Address) field, a TA (Transmitter Address) field, a Block ACK control field 411 identical to the one in the corresponding BAR frame 410, a Block ACK starting sequence control field 421 (BA-SSC) containing a starting sequence number (SSN), a Block ACK bitmap field 422, and an FCS (Frame Check Sequence)

field.

The starting sequence number SSN of two-byte BA-SSC 421 is the sequence number of the first MPDU in the frame burst (i.e. A-MFDU) for which BA frame 420 is sent. It is usually of the same value as the BA-SSC value in field 412 of corresponding received BAR frame 410.

The BA bitmap field indicates the receipt status of up to 64 consecutive MPDUs, starting from the MPDU having the SSN. It includes the receipt status of a number Flightsize of received MPDU5, Flightsize possibly being less than 64 in case a sliding window protocol constrains the source node to send less than 64 MFDU5 without acknowledgment.

The other fields are of less importance for the present invention.

Back to Figure 4a, in an examplary communication sequence, an A-MPDU 450 is transmitted from the source node to the receiving node, over a wireless channel.

The source node transmits multiple data MPDU5 230 in A-MPDU 450 followed by a BAR frame 410. On receipt of the A-MPDU 450 and the BAR 410, the receiving node generates a BA frame 420 in response and transmits it to the source node over the wireless channel. BA frame 420 indicates the receipt status of each MPDU 230 in the received A-MPDU 450.

In packet-based data transmission protocols such as those implemented in IEEE 802.11 networks (for example at Data Link Layer, such as MAC layer), the communication nodes may implement a sliding window protocol by which a maximum number or predetermined amount (window size) of data packets or frames sent by the transmifting or source node and to be acknowledged by the receiving node is defined.

Once this number has been reached, the source node cannot send more data and thus cannot access the network medium. It experiences blocking on transmitting new data.

The receiving node and the source node may have different window sizes (i.e. maximum numbers of MPDU5) respectively in reception and in transmission.

Whichever the case, the smaller of the window sizes defines the transmission blocking constraint at the source node.

The receiving node may inform the source node in each acknowledgment packet of the current maximum receiver buffer size, i.e. the size or boundary of the sliding reception window. In a variant, if the maximum receiver buffer size is fixed, it may be provided during session setup.

The "sliding" results from the fact that when the window is full (a corresponding amount of data or MPDU5 has not yet been acknowledged), the source node can only send one new MPDU for one MPDU acknowledged by the receiving node. Each MPDU acknowledged by the receiving node thus releases or relaxes transmission blocking constraint (to restore transmission capacity) by one MPDU at the source node.

A well-known example of sliding window protocol is the Go-Back-N protocol.

The sliding window protocol may cause increased latency in particular if the acknowledgment is not performed quickly, which is the case with delayed acknowledgment.

Risks of collision, in particular of RTS frames, remain in IEEE 802.11 networks because the source node and the receiving node have no means to know the communication timeslots which are going to be requested by and granted to the other communication nodes.

This may be the case where several source nodes concurrently attempt to access the network medium to send data to the same or several receiving nodes.

The example of Figure 5 illustrates RTS collision between a source node and the corresponding receiving node.

The duration specified in RTS frame 210 is defined to prevent transmission by other communication nodes during the requested TXOP period. Typically, RTS frame's duration field contains a value in microseconds of time needed to transmit CTS 220, plus source node's data 230 inside A-MPDU 450, plus the BAR-BA acknowledgement sequence 410/420, plus the time for the SIES intervals between each of these transmissions.

Therefore, the network allocation vector (NAV) of the other communication nodes will be set accordingly to cover the whole duration of the transmission opportunity TXOP when receiving the RTS frame.

A number n (at least 1) of MPDU frames may be transmitted in data slot 230. The source node issues BAR frame 410, which is followed by BA frame 420 from the receiving node.

Accordingly, the collision problem previously described occurs when the two nodes concurrently request access to the wireless channel because they have their backoff counters expiring at the same time.

The present invention as defined above in general terms improves collision avoidance of RTS frames. This collision avoidance improvement in the wireless network is obtained by reducing the medium access requests (e.g. RTS) by source nodes when the receiving node delays acknowledgment of the received data to prevent, for a predetermined delay duration, the source node from requesting access to a network medium of the ad-hoc wireless network to send new data. In the invention, the receiving node uses the delayed acknowledgment and the sliding window constraint at the source node to block the latter from transmitting new data so long as the receiving node wants. By selectively deciding the amount of data it acknowledges, the receiving node may indirectly control the source node's access to the network medium.

Any communication node of Figure 1 can act as a source node or as a receiving node according to the invention as now described with reference to Figures 6 to 10.

Figure 6 schematically illustrates a communication device 600 of the radio network 100, configured to implement at least one embodiment of the present invention. The communication device 600 may be a device such as a micro-computer, a workstation or a light portable device. The communication device 600 comprises a communication bus 613 to which there are preferably connected: -a central processing unit 611, such as a microprocessor, denoted CPU; -a read only memory 607, denoted ROM, for storing computer programs for implementing the invention; -a random access memory 612, denoted RAM, for storing the executable code of methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing methods according to embodiments of the invention; and -at least one communication interface 602 connected to the radio communication network 100 over which digital data packets or frames are transmitted, for example a wireless communication network according to the 802.lln protocol. The data frames and aggregated frames are written from a FIFO sending memory in RAM 612 to the network interface for transmission or are read from the network interface for reception and writing into a FIFO receiving memory in RAM 612 under the control of a software application running in the CPU 611.

Optionally, the communication device 600 may also include the following components: -a data storage means 604 such as a hard disk, for storing computer programs for implementing methods according to one or more embodiments of the invention; -a disk drive 605 for a disk 606, the disk drive being adapted to read data from the disk 606 or to write data onto said disk; -a screen 609 for displaying decoded data and/or serving as a graphical interface with the user, by means of a keyboard 610 or any other pointing means.

The communication device 600 can be connected to various peripherals, such as for example a digital camera 608, each being connected to an input/output card (not shown) so as to supply data to the communication device 600.

The communication bus provides communication and interoperability between the various elements included in the communication device 600 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communication device 600 directly or by means of another element of the communication device 600.

The disk 606 can be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk, a USB key or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the apparatus, possibly removable and adapted to store one or more programs whose execution enables a method according to the invention to be implemented.

The executable code may be stored either in read only memory 607, on the hard disk 604 or on a removable digital medium such as for example a disk 606 as described previously. According to a variant, the executable code of the programs can be received by means of the communication network 603, via the interface 602, in order to be stored in one of the storage means of the communication device 600, such as the hard disk 604, before being executed.

The central processing unit 611 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a non-volatile memory, for example on the hard disk 604 or in the read only memory 607, are transferred into the random access memory 612, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention.

In this embodiment, the apparatus is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).

Figure 7 is a block diagram schematically illustrating the architecture of a node 600 adapted to carry out, at least partially, the invention. As illustrated, node 600 comprises a physical (PHY) layer block 703, a MAC layer block 702, and an application layer block 701.

The PHY layer block 703 (here a 802.11 standardized PHY layer) has the task of formatting and sending or receiving frames over the radio medium used 100, such as a medium access request of the RTS type to reserve a transmission slot, a medium access response of the CTS type to acknowledge reservation of a transmission slot, as well as of data frames and aggregated frames to/from that radio medium.

The MAC layer block or controller 702 comprises a standard MAC 802.11 layer 704 and four additional blocks 705 to 708 for carrying out, at least partially, the invention. The MAC layer block 702 may be implemented in software, which software is loaded into RAM 612 and executed by CPU 611.

According to a particular embodiment, the node data transmission block 705 performs the task of exchanging data packets with the PHY layer 703 and the application layer 701.

The RTS/CTS module 706 has the task of managing Request-To-Send (RTS) and Clear-To-Send (CTS) frames.

The source management module 707 is configured to implement part of the invention, in particular to control the transmission of data by the source node. This control takes into account the receiving node's own requirements with regards to data stream to decide when to authorize the source node to send new data and how much.

Note that this module 707 is also responsible for configuring the MAC layer 704 mechanism dedicated to controlling the receive reordering buffer' per TA/TID. For example, it configures the starting sequence number (SSN) of BA frames according to the invention as further described below.

It is also responsible for driving MAC layer 704 to allocate transmission period to a source node during granted transmission opportunity, as further described below in embodiments of the invention.

The backoff management block 708 has the task of managing the backoff value used by the node in a collision avoidance scheme.

Finally, the application layer block 701 implements an application that generates and receives data packets from MAC layer 702, for example data packets of a video stream.

Figure 8 schematically illustrates, in a timeline similar to Figure 5, the mechanism of the invention according to embodiments which are described here after with reference to Figures 9 to 10.

The situation shown in the Figure represents communications according to the invention after an initial transmission of data by the source node. Previously, a data exchange session has been negotiated and set up between the source node 101-107 and the receiving node 600.

Data, encapsulated in MPDUs, and BAR frame have been sent by the source node to the receiving node without the latter acknowledging the received data.

The source node is thus in a blocking state where it cannot send new data so long as no acknowledgement of previously sent data is received from the receiving node. This is the effect of the sliding window protocol as described above when the window capacity is entirely used.

The receiving node 600 knows that it has to acknowledge the received data (it may have already prepared the BA frame for acknowledgment which is waiting in a transmission queue of the receiving node). As a consequence, the receiving node has started a contention-based backoff procedure to obtain access to the network medium.

Upon expiry of its backoff counter, the receiving node 600 sends an RTS frame 210.

As in the conventional situation of Figure 5, the duration specified in RTS frame 210 is also defined to prevent transmission by other communication nodes during the TXOP period. The RTS frame's duration field contains a value in microseconds of time needed to transmit CTS 220, a polling frame 830 as further described below to support embodiments of the invention, plus a transmission period TXOPSOUICe for the source node to send new data 230 inside one A-MPDU 450, plus the BAR-BA acknowledgement sequence 410/420, plus the time for the SIFS intervals between each of these transmissions.

It may be noted that the duration is approximately the same as the conventional computed duration of Figure 5, as the size of a polling frame 830 is generally limited to a MAC header as explained below.

It must be noted that, although the BAR-BA acknowledgement sequence 410/420 is present, the order of the BAR frame and BA frame is inversed in TXOP compared to Figure 5. This is because, due to delayed acknowledgment, the BA frame is first sent to acknowledge data previously received in a previous TXOP, while the BAR frame is sent later on when new data have been sent in response to transmission blocking constraint release at the source node resulting from the acknowledgment in BA frame.

In response to RTS frame 210, the source node sends CTS frame 220.

The receiving node then sends the data from its transmission buffer, here the BA frame 420 to acknowledge a subset of the received data. It then sends a polling" frame 830 transferring transmission rights of the transmission period TXOFsource which the receiving node allocates to the source node, so that the source node takes control for data transmission of data units over the ad-hoc wireless network during the allocated transmission period TXOPSOUrOe.

The pair constituted by BA frame 420 and polling frame 830 starts immediately after medium access is granted through CTS reception: this is specific to embodiments of the invention since it includes the mechanisms making it possible for the receiving node 600 to control the source node and to only allocate it a transmission timeslot TXOPsource of predetermined duration.

To ensure the source node is blocked after having transmitted new data during the allocated TXOPSOUICe, BA frame 420 has parameters to free an amount of data (through data acknowledgment) that is a function of (or fits) the allocated TXOPsource given the physical network bitrate. More transmission time TXOPs0uIOe than the freed (acknowledged) amount of data is preferably allocated to the source node to ensure the source node's blocking at the end of TXOP. Indeed, if the BA frame frees too much transmission capacity at the source node, the latter will attempt to send data corresponding to the remaining capacity in a later medium access performed by itself (starting again a new backoff procedure). Risk of collision would thus still exist.

Control of the amount of data to free is provided by appropriately setting the SSCISSN sequence 421. Examples of how setting an appropriate starting sequence number SSN (seq_RX below) are given below with reference to Figures 9 to 10.

To comply with 802.11 standard, polling frame 830 may be a Null Data frame or a QoS-Null Data frame according to the standard. (QoS)Null Data frame is a frame meant to contain no data but flag information (header with empty payload).

Such (QoS)Null Data frame is used in particular when the receiving node 600 has no data to send (except the acknowledgment frame) to the source node. This is often the case.

Of course, in case the receiving node 600 has data to send to the source node, the former can send a conventional Data frame (instead of a Q0S_Null) frame after BA frame. This is not shown in the Figure.

To provide transfer of transmission rights of the allocated transmission period TXOPsource to the source node, embodiments of the invention provide that the polling frame 830 takes the form of a short frame according to the "Reverse Direction" (RD) feature of IEEE 802.lln standard. For example, the polling frame 830 includes an enabled Reverse Direction Grant flag 850 according to the IEEE 802.lln standard.

As known, the 802.lln RD protocol aims at providing more efficient transfer of data between two 802.11 nodes during a TXOP by eliminating the need for either device to initiate a new data transfer. RD data flow is very useful for traffic streams that have a bi-directional nature, for example like VoIP or TCP traffic (the latter because of backward TCP acknowledgment flow).

With RD protocol, once the source node has obtained a TXOP, it may essentially grant permission to the other node to send information back during the TXOP. In other words, it shares or subleases a subpart of its TXOP to the other node.

This requires that two roles be defined: RD initiator and RD responder.

The RD initiator sends its permission to the RD responder using a Reverse Direction Grant (RDG) in the RDGIMore PPDU field (1 bit) of the 4-byte HT Control field in the MAC frame. This bit is used by the RD initiator for granting permission to the RD responder (RDG field equals to 0' for no RD; Cf in case of RD), and it is used by the RD responder to signal whether or not it is sending more frames immediately following the one just received (More PPDU field equals 0' if the current PPDU is the last one; 1' if another PPDU follows the current PPDU frame).

This 4-byte HT Control' also includes: an AC Constraint' subfield bit to indicate whether the mapped AC of an RD data frame is constrained to a single AC or not; a Duration/ID field' to define the size or time length of the allocated transmission period TXOPsource.

Still refering to Figure 8, once the source node has received BA frame 420 and polling frame 830, it takes the lead on data transmission during TXCPSOUICO and sends, to the receiving node 600, as much data 450 stored in its MAC TX FlED as possible given the allocated transmission period TXOPsource and its transmission contraint due to sliding window protocol (i.e. it is indirectly given the amount of data freed by the receiving node through SSC/SSN 421 specified in BA frame 420).

In accordance with conventional methods, the source node then sends BAR frame 410.

The same TXOP may be repeated so long as the data session between the source node and the receiving node continues.

As one can note, thanks to this mechanism, there is no backoff procedure (801, 802) performed by the source node. Of course, there may be an initial backoff procedure at the early beginning of a communication session between the source node and the receiving node, until the source node is blocked due to sliding window protocol and absence of data acknowledgment from the receiving node.

As a consequence of this mechanism, the source node is no longer a source of RTS collision.

In the example of the Figure, only one source node is described. But the invention may apply with a plurality of source nodes 101-107 sending data to the same receiving node 600. The invention may also be used (in a variant or in combination with the plurality of source nodes) to provide two or more allocated transmission periods to the same source node.

In such cases, the receiving node 600 may be configured to send, after the allocated transmission period TXOPsource in the granted transmission opportunity TXOP, a second (or more) Block Acknowledgment (BA) frame 420 to acknowledge a subset of received data from a second (or more) source node, and to send, after the second BA frame 420, a second (or more) polling frame 830 transferring transmission rights of a second (or more) transmission period within the granted transmission so that the second (or more) source node takes control for data transmission of data units over the ad-hoc wireless network during the second (or more) transmission period.

In other words, the sequence { BA frame 420, polling frame 830, allocated TXOPSOUICe} can be repeated for the same source node and/or for a plurality of respective source nodes during the same TXOP granted to the receiving node. The receiving node 600 waits for a SIFS interval between each repetition.

The granted TXOP ends when all the source nodes have been polled by the receiving node 600.

Note that, in order to comply with 802.11 standard, an embodiment of the invention includes establishing a delayed BA policy during BA session negotiation between the source and receiving nodes. In such a case, a conventional ACK 240 (not shown) is issued by the receiving node 600 after BAR frame 410 to acknowledge safe reception of BAR frame 410 only.

Figure 9 is a flowchart illustrating general steps of an embodiment of the invention at any wireless communication node receiving data from a source node: the receiving node can be any of the wireless stations 101 to 107 of Figure 1. Note that the source node is a node according to IEEE 802.11 without specific processing (except if it also acts as a receiving node). In the context of the invention, the receiving node acts as a transmission coordinator for the source node, similarly to a base station in an infrastructure network, whereas the wireless network is here a pure ad-hoc network.

The source node sends MSDU packets of a data stream pertaining to a traffic category (TID), using aggregate MPDU5.

The process of Figure 9 happens after an initial session setup and initial transmission of stream data leading the source node to be blocked due to sliding window protocol (the receiving node 600 not having acknowledged an amount of data corresponding to the constraining window size).

These initial steps (not shown) may be used to negotiate the window size, for example a size of the reordering buffer at the source node or at the receiving node.

Indeed, according to IEEE 802.11 standard, the source node must not have more than this number of MPDUs outstanding before soliciting a BA.

These steps also make it possible for the receiving node 600 to be aware of

specifications of the upcoming data stream.

For instance, a L3 Audio-Video (AV) session is established: for example an RTSP (real-time streaming protocol) is used for an AV control session, an RTF is used for an AV data session, and a high-bandwidth digital content protection (HDCP) 2.0 is used for content protection. AV data are converted into data units meeting the requirements of MPEG2 TS or H.264, and are transmitted from the source node to the receiving node 600 via the RTP session. As the receiving node 600 is the recipient of the L3 AV session, it is fully aware of the AV stream specifications.

Alternative protocols allowing stream specification discovery for the receiving node 600 include: -Wi-Fi protected setup (WPS) protocol offering discovery of services, audio/video profile prior to 051-Layer 2 connection; -051-Layer 3 discovery protocols, such as UPnP, Bonjour; -Session Description File (SDF) of a session description protocol (SDP, RFC2327), which can have been downloaded by the receiving node 600 though HTTP or RTSP protocols at the session start or prior announced via a session announcement protocol (SAP).

Once the data stream from the source node has been identified, the receiving node 600 can analyze the main information of the stream specifications in terms of: -Mean Data Rate (MeanDataRate), which specifies, in bits per second, what the expected (mean) throughput is for the data stream; -Nominal_MSDU_Size, which specifies the expected data unit size; and -Minimum Service Interval (minSl), which specifies, in milliseconds (msec), the minimum allowed time between two TXOPs for the source node. If required, the minimum service interval can be determined by the receiving node 600 as nominaLMSDU_size/MeanDataRate. This is a minimum period at the end of which the source node is intended to request access to the radio medium. It corresponds to a maximum frequency, which is an estimated frequency, for such RTS requests.

As described below, these items of information are used in embodiments by the receiving node to determine the amount of data to acknowledge in BA frame as well as the size or length of the transmission period TXOPSOUICe to allocate to the source node.

The process of Figure 9 is repeated each time the receiving node 600 starts a new TXOP as shown in Figure 8.

As summarized above, the goal for the receiving node 600 is to poll and block the source node(s) (to avoid contention by the source node that could generate collisions), in such a way that a transmission period inside the TXOP initially granted to the receiving node 600 is allocated to the source node to allow it to send as much data as acknowledged by the receiving node (to again block the source node).

At step 900, a backoff procedure is initiated at the receiving node 600, in particular its backoff counter is randomly selected from [0, C according 802.11 standard. CW is the contention window, which thus defines a frequency for medium access requests by the receiving node 600.

The receiving node 600 may select a backoff counter that expires before a theoretical time estimated at which the source node would access the network given

the specifications of the data stream.

This is to ensure that the source node will not suffer from buffer overflow at its transmission buffer (as it is currently blocked from accessing the wireless medium due to the sliding window protocol).

Such a condition may be achieved by computing CW based on the stream specifications. For example, CW = minSl I TXOF_Limit.

TXOP Limit is the maximum data transmission duration allowable according to the IEEE 802.11 standard. The use of TXOP_Limit value in the above formula ensures OW is minimum given the largest possible transmission duration. The receiving node will request access to the radio medium with a service interval that is lower than minSi. In other words, the receiving node 600 is able to request access to the radio medium at a higher frequency than the source node, thus preventing a risk of buffer overflow.

Further to step 900, step 902 occurs upon detecting the expiry of receiving node's backoff counter.

At step 902, the receiving node sends a RTS frame 210 with the source node as addressee node, to request TXOP.

The receiving node may set the Duration field of RTS frame 210 to the value of TXOP_Limit in order to reserve the maximum allowable time. In that case, the receiving node is ready to free unused remaining time (if any) once the receiving node has sent all the data (if any) in its TX buffer and once all the source nodes have been polled according to the invention.

In a variant, the Duration field of RTS frame 210 may be set to a value depending on the stream specifications, for example by adding the lengths of RTS frame 210, CTS frame 220, BA frame or frames 420 (in case several source nodes are considered), polling frame or frames 830, allocated transmission period or periods TXOPSOUICe, and the appropriate SIFS intervals. Below are described examples to determine the allocated transmission period or periods TXOPsource, the other frames being of known lengths.

In response to RTS frame 210, the receiving node receives CTS frame 220 from the source node, resulting in the medium access being granted.

Next at step 904, the size or length of the transmission period TXOPsource to allocate to the source node is computed. In case the receiving node wishes to poll a plurality of source nodes, the lengths for their respective TXOPSOUFCO are computed.

Note that this length is used to build BA frame 420 and polling frame 830.

As an embodiment, the time length of TXOPSOUI depends on the stream specifications. This is to control the source node in an appropriate manner so as to avoid overflow of its transmission buffer for example.

For instance, the Simple Scheduler as defined in IEEE 802.lle standard for HCCA can be used in order to compute the length of TXOPsoume in such a way that the data stream from the source node is conveyed at each considered service interval minSi. In variants, other schedulers may be considered.

In embodiments, TXOPSOUICe =N * N0minaLMSDU_Size / R, where N, examples of calculation thereof are given below, is an estimated number of data units (e.g. MSDUs or MPDU5) of the data stream that arrive at the receiving node during a predefined time or that are required by the receiving node, and R is a physical network bitrate of the ad-hoc wireless network.

In a variant, TXOPSOUICe =ceil(N) * Nominal_MSDU_Size I ft where ceilC) is the ceiling function.

These formulae calculate the length of TXOPsource as the time needed to transmit N frames at physical rate R of the wireless network.

In a first embodiment, the receiving node 600 calculates the number N of MSDUs that arrive at the mean data rate during minSi: N = minSI * MeanDataRate I Nominal_MSDU_size In a variant, MAC layer 704 of the receiving node 600 may receive information from an upper layer about an amount of data required. For example, an application of the application level may give information on an amount of data to avoid video buffer underflow or overflow. The amount of MSDUs is thus directly deduced from required amount of data as follows: N = amount_data I Nominal_MSDU_Size, where amount_data is the amount of data required by an application of the receiving node to use the data stream.

In another embodiment, both values of N can be calculated, and the minimum value of the two results is used as N for the next steps.

At the end of step 904, the length of TXOPSOUICe is known.

Next, at step 906, the receiving node computes the starting sequence number SSN to be used in BA frame 420. As understood from the above, the setting of SSN makes it possible to adjust the number ANMP of MPDU5 to be acknowledged by the receiving node (ANMP standing for allowed number of MPDU packets), and thus how much transmission blocking constraint is released or relaxed at the source node for it to restore transmission capacity to be able to send new data. Only part of the received data not yet acknowledged is selected for acknowledgment through the setting of SSN.

To keep blocking the source node after TXOPSOUICe, the amount of data to acknowledge and thus the value of SSN are a function of the length of TXOPsource.

Examples below show this dependency through the value of N. First the value of ANMP is determined, representing the amount of data to acknowledge. Note that ANMP should always be less than 64 (which is the size of the acknowledgment bitmap 422).

As an example, in case of A-MPDU aggregation without A-MSDU aggregation, ANMP = floor(N), where floorC) is the floor function.

In a variant where both aggregation schemes are used, ANMP= floor( N / floor( Max_AMSDU_size / N0minaLMSDU_Size)), where Max_AMSDU_size is a maximum size of an aggregate A-MSDU defined in the ad-hoc wireless network.

One may note than the ANMP value should also comply with A-MPDU buffering limitation: ANMP should be reduced if the corresponding total size of data exceeds the Max_acceptable_AMPDU_size 802.11 attribute, which specifies the maximum length of an A-MPDU in bytes that can be transmitted by the source node (values 8191, 16383, 32767 or 65535 bytes are typical maximum sizes advertised by 802.lln node). This is because the source node will not be able to send more data during TXOPSOUICe. To ensure the source node is blocked after TXOPSOUFGO, no more transmission capacity should remain at the source node, but only transmission blocking.

Once the ANMP value has been determined, the receiving node computes SSN to be included in BA frame 420.

In embodiments, seq_RX = seq_TX + ANMP -WinSize, where seq_RX is the SSN to be set in the BA frame, 5eQTX is a starting sequence number set in previously received BAR frame 410 sent by the source node (and corresponding to the received data not yet acknowledged). This value seq_TX is the sequence number of the first received MPDU not yet acknowledged, and WinSize is the size of the sliding window defining transmission restriction/constraint for the source node.

Once SSN has been determined, BA frame 420 can be issued and sent by the receiving node to the source node. This is step 908.

At step 910, the receiving node issues and sends polling frame 830 which includes RDG flag set to 1' and Duration/ID field set to the time length of TXOP501as computed at step 904.

At step 914, the receiving node receives new data (if any) and corresponding BAR frame 410 from the source node during allocated TXOPsouice.

At step 916, the receiving node delays acknowledgment of the received new data for a new predetermined duration, e.g. until a future TXOP. Acknowledgment will be performed at a further medium access. The source node is blocked again, avoiding new requests for medium access and thus risks of collision due to source-node-initiated RTS.

Figure 10 illustrates the mechanism of the invention as regards the behavior of a source node's MAC transmission buffer and receiving node's MAC reception context (scoreboard context).

Figure ba shows the status of SSN for the two sides (1001 at the source node and 1002 at the receiving node) before the receiving node accesses the network medium. It corresponds to phase 801, prior to step 902 issuing RTS frame 210.

According to IEEE 802.lln standard, the source node contains a transmission buffer control that uses WinstartO and WinSize parameters to submit MPDU5 for transmission and releases transmission buffer upon receiving BA frames from the receiving node. WinStartO 1020 is the starting sequence number (SSN) of the transmission window, and WinSize is the window size negotiated in the Block Ack agreement (usually the minimum size between the size of the buffer at the receiving node and the size of the buffer at the source node). The window size WinSize is shown in the Figure as the size between WinStarto 1020 and Max_seq_TX 1021 (which identifies the sequence number of the last MPDU transmitted).

An IEEE 802.11 receiving node contains a receive reordering buffer control per TA/TID' entity, which contains a related control state. This receive reordering buffer is responsible for reordering received MSDUs or A-MSDUs so that MSDUs or A-MSDUs are eventually transmitted to an upper layer in the order of the sequence number. In addition and prior to performing the reordering, the receiving node includes a scoreboard context control' entity which stores an acknowledgment bitmap (from which the acknowledgment bitmap 422 in BA frame 420 will be generated) containing the current reception status of each MSDU or A-MSDU. This entity provides the acknowledgment bitmap (422) and the value for the SSN subfield (421) to be sent in BA frames 420 to the source node. As a result, after been deaggregated from its container A-MPDU, each received MPDU is analyzed by the scoreboard context control as well as further by the receive reordering buffer control.

Back to Figure IDa, during phase 801, the source node is blocked due to sliding window protocol and lack of data acknowledgment by the receiving node. Its TX buffer 1001 includes old sent dataIMPDUs already acknowledged (1010), which MPDUs have sequence numbers prior to current SSN=5eQTX=WinStartO.

They are followed by the last data sent that have not yet been acknowledged (1011), starting from SSN=seq_TX 1020 to max_seq_TX 1021 (i.e. corresponding to the negotiated WinSize). Since the source node is blocked, data 1011 represent the maximum amount of data the source node has sent but for which it has not received acknowledgment; this flight-size of not-yet-acknowledged data corresponds to the window size constraining source node's data transmission (in the example it corresponds to the negotiated Winsize, e.g. of the sliding window at the receiving node). In BAR frame 410, the source node has requested acknowledgment of the MPDU5 starting from SSN=WinStartO.

Next to data 1011, data 1012 are MPDU5 waiting to be sent by the source node. Note that due to the sliding window constraint, the source node cannot send data 1012 so long as all or part of data 1011 has not been acknowleged by the receiving node.

Turning now to the RX scoreboard 1002, received data 1010 have already been acknowleged; received data 1011 have not yet been acknowledged. WinStartR 1030 is the current SSN defining the first MPDU of data 1011 to be acknowledged (and specified as such in BAR frame 410) and WinEndR 1031 defines the last MPDU in the current transmission window (WinEndR WinStaitR = WinSize, the amount of data received subject to acknowledgment).

Acknowledgment bitmap of the scoreboard is shown with reference 1051, covering the MPDU5 from WinStartR to WinEndR. This is this acknowledgment bitmap 422 which is conventionally included in BA frame 420 of known systems by the receiving node. Additional bits in the acknowledgment bitmap 422 to reach the size of 64 bits are set to 0 in case the flightsize is less than 64.

As explained above, the receiving node having delayed acknowledgment of data 1011 now enters in the process of Figure 9, i.e. decides when it wants to access the network medium and to relax transmission blocking constraint at the source node by a predetermined amount of data.

To do so, it determines the number ANMP 1013 of MPDU5 1011 to acknowledge and the SSN=seq_RX 412 to be included in BA frame 420 to limit the acknowledgment range (and the freeing of transmission capacity for the source node) to ANMP 1013 which is a subpart of the sliding window (WinSize) at the receiving node. This is step 906 described above using WinstartR 1030 as parameter seq_TX and using ANMP.

seQRX is thus used as SSN 421 in BA frame 420 instead of WinstartR 1030 which is conventionally used in IEEE 802.11 BA frames. The acknowledgment bitmap 422 thus included in BA frame 420 is shown as reference 1052, starting from seq_RX. As one may note, acknowledgment bitmap range 1051 for conventional known systems (as IEEEBO2.11 standard) is different from acknowledgment bitmap range 1052 according the present invention: the starting sequence number SSN and the acknowledgement bitmap 422 are set to acknowledge already-acknowledged received data (i.e. data 1010) and only the ANMP data 1013 from data 1011. As the bitmap in the scoreboard context only stores reception status of MPDU5 from SSN=WinStartR, the status of these already-acknowledged MPDUs 1010 is reported as successfully received, i.e. using bit 1' in acknowledgment bitmap 422.

Figure lOb shows the same source node's transmission buffer 1001 and receiving node's scoreboard 1002, but once BA frame 420 has been sent by the receiving node and received by the source node. This corresponds to the situation at the very beginning of TXOPsource (end of step 910).

Due to acknowledgment of the MPDUs 1013, the sequence parameters Winstarto 1020 and Max_seq_TX 1021 have shifted by a hop of size ANMP. Data between the old WinstartO and the new WinStartO are now data acknowledged, i.e. included in zone 1010.

Acknowledgment has restored transmission capacity at the source node by ANMP, which is converted into new MPDU5 allowed to be sent (zone 1013). These new MPDU5 will be sent during the currently allocated TXOPSOUICO using aggregation of an ANMP number of MPDUs into an A-MPDU 450. A BAR frame 410 will also be sent including the new Winstarto as SSN 411.

Turning now to the scoreboard 1002, WinStartR 1030 and WinEndR 1031 remain unchanged as long as BAR frame 410 has not been received. VThatever the case, the ANMP number of MPDUs 1013 is now considered as acknowledged MPDUs, and thus MPDUs 1013 are included in acknowledged data 1010.

The invention as described above uses conventional mechanisms of IEEE 802.11 but in a different way. This makes it possible to obtain the above defined advantages (improvement of collision avoidance and reduction of bandwidth waste) while keeping full compliance with IEEE 802.11 in particular for the source nodes that are conventional IEEE 802.11 communication nodes.

In one embodiment of the invention where the receiving node implements a plurality (e.g. 4) of access categories for which the receiving node receives respective data from source nodes, the access categories being associated with independent backoff counters of the Collision Avoidance mechanism for the receiving node to access the network medium, the receiving node, on accessing the network medium upon expiry of one of the backoff counters (i.e. for one AC), acknowledges data received for different access categories from two or more source nodes and allocates subparts of the granted transmission opportunity as transmission periods to the two or more source nodes for them to send new data.

This makes it possible to use a unique RTS/CTS medium reservation with the object of polling several source nodes having data flows pertaining to different AC queues. This contributes to further reducing the number of medium accesses onto the wireless medium, and thus risks of RTS collision (which further reduces bandwidth waste).

Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications which lie within the scope of the present invention will be apparent to a person skilled in the art. Many further modifications and variations will suggest themselves to those versed in the art upon making reference to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention as determined by the appended claims. In particular different features from different embodiments may be interchanged, where appropriate.

Claims (31)

1. CLAI MS1. A method of communicating in an ad-hoc wireless network including a source node and a receiving node, the source node sending data of a data stream to the receiving node using a sliding window protocol, wherein the receiving node delays acknowledgment of the received data to prevent, for a predetermined delay duration, the source node from requesting access to a network medium of the ad-hoc wireless network to send new data.
2. 2. The method of Claim 1, wherein the receiving node determines a time from which it decides to authorize the source node to send new data; and acknowledges a subset of the received data to the source node at the determined time so as to release source node's transmission blocking constraint due to the sliding window protocol.
3. 3. The method of Claim 2, wherein the receiving node sizes the subset of received data to acknowledge to an amount of new data it authorizes the source node to send.
4. 4. The method of Claim 2, wherein the subset of received data is acknowledged within a transmission opportunity granted to the receiving node in the ad-hoc wireless network; and a transmission period following the acknowledgment in the granted transmission opportunity is allocated to the source node by the receiving node for the source node to send the new data.
5. 5. The method of Claim 4, wherein a size of the subset of received data to acknowledge in the granted transmission opportunity is a function of a size of the allocated transmission period.
6. 6. The method of Claim 5, wherein the size of the subset of received data corresponds to less data than the amount of data that can theoretically be sent during the allocated transmission period, given a physical network bitrate.
7. 7. The method of Claim 4, wherein acknowledging the subset of received data comprises sending a Block Acknowledgment (BA) frame that includes a starting sequence number and an acknowledgement bitmap, in the granted transmission opportunity to the source node, wherein the starting sequence number and the acknowledgement bitmap are set to acknowledge already-acknowledged received data and the subset of received data only.
8. 8. The method of Claim 7, wherein seq_RX = seq_TX ÷ ANMP -WinSize, where seq_RX is the starting sequence number set in the BA frame, 5eQTX is a starting sequence number set in a Block Acknowledgment Request (BAR) frame sent by the source node with the sent data, ANMP is a size of the subset of received data, and WnSize is a size of the sliding window defining transmission constraint for the source node.
9. 9. The method of Claim 8, wherein the receiving node receives the data in data units, and ANMP = floor(N), where floorC) is the floor function and N is an estimated number of data units of the data stream that arrive at the receiving node during a predefined time or that are required by the receiving node.
10. 10. The method of Claim 8, wherein the receiving node receives the data in data units, which data units are aggregated into an aggregate data unit sent by the source device, and ANMP= floor( N I floor( Max_AMSDU_size I Nominal_MSDU_Size)), where floorC) is the floor function, N is a estimated number of data units of the data stream that arrive at the receiving node during a predefined time or that are required by the receiving node, Max_AMSDU_size is a maximum size of an aggregate data unit defined in the ad-hoc wireless network and Nominal_MSDU_Size is an expected size of the data units.
11. 11. The method of Claim 9 or 10, wherein N = minSl * MeanDataRate / Nominal_MSDU_Size, where minSl is a minimum Service Interval which defines the minimum allowed time between two theoretical medium access requests by the source node, taking into account specifications of the data stream, MeanDataRate is the mean throughput of the data stream, and Nominal_MSDU_Size is an expected size of the data units.
12. 12. The method of Claim 9 or 10, wherein N = amount_data / Nominal_MSDU_Size, where amount_data is an amount of data required by an application of the receiving node to use the data stream, and Nominal_MSDU_Size is an expected size of the data units.
13. 13. The method of Claim 4, wherein during the granted transmission opportunity, the receiving node sends a Block Acknowledgment (BA) frame to the source node to acknowledge the subset of received data, and, after the BA frame, sends a frame transferring transmission rights of the allocated transmission period so that the source node takes control for data transmission of data units over the ad-hoc wireless network during the allocated transmission period.
14. 14. The method of Claim 13, wherein sending a frame transferring transmission rights comprises sending a frame including an enabled Reverse Direction Grant flag according to IEEE 802.lln standard.
15. 15. The method of Claim 14, wherein the transferring transmission rights frame further includes a data field defining a size of the allocated transmission period, said size being equal to N * Nominal_MSDU_Size I R, where N is an estimated number of data units of the data stream that arrive at the receiving node during a predefined time or that are required by the receiving node, Nominal_MSDU_Size is an expected size of the data units, and R is a physical network bitrate of the ad-hoc wireless network.
16. 16. The method of Claim 14, wherein after the allocated transmission period in the granted transmission opportunity, the receiving node sends a second Block Acknowledgment (BA) frame to acknowledge a subset of received data from a second source node, and, after the second BA frame, sends a second frame transferring transmission rights of a second transmission period within the granted transmission opportunity so that the second source node takes control for data transmission of data units over the ad-hoc wireless network during the second transmission period.
17. 17. The method of Claim 4, wherein the receiving node implements a Collision Avoidance mechanism using a contention window to access the network medium and to be granted the transmission opportunity, the contention window being function of stream specifications of the data stream sent by the source node.
18. 18. The method of Claim 17, wherein the contention window CW is equal to minSl ITXOP_Limit, where minSl is a minimum Service Interval which defines the minimum allowed time between two theoretical medium access requests by the source node, taking into account specifications of the data stream, and TXOP_Limit is a maximum size of a transmission opportunity in the ad-hoc
19. 19. The method of Claim 17, wherein the receiving node implements a plurality of access categories for which the receiving node receives respective data from source nodes, the access categories being associated with independent backoff counters of the Collision Avoidance mechanism for the receiving node to access the network medium, and the receiving node, on accessing the network medium upon expiry of one of the backoff counters, acknowledges data received for different access categories from two or more source nodes and allocates subparts of the granted transmission opportunity as transmission periods to the two or more source nodes for them to send new data.
20. 20. The method of Claim 4, wherein the receiving node receives new data from the source node during the allocated transmission period of the granted transmission opportunity and delays acknowledgment of the received new data for another predetermined delay duration.
21. 21. A communication device in an ad-hoc wireless network, comprising: a communication module configured to receive data of a data stream sent by a source node using a sliding window protocol, an ack delay module configured to delay acknowledgment of the received data to prevent, for a predetermined delay duration, the source node from requesting access to a network medium of the ad-hoc wireless network to send new data.
22. 22. The communication device of Claim 21, wherein the ack delay module is configured to determine a time from which the communication device decides to authorize the source node to send new data; and to acknowledge a subset of the received data to the source node at the determined time so as to release source node's transmission blocking constraint due to the sliding window protocol.
23. 23. The communication device of Claim 22, wherein the ack delay module is configured to size the subset of received data to acknowledge to an amount of new data the communication node authorizes the source node to send.
24. 24. The communication device of Claim 22, wherein the ack delay module is configured to acknowledge the subset of received data within a transmission opportunity granted to the communication device in the ad-hoc wireless network; and the communication device comprises a TXOP allocator configured to allocate a transmission period following the acknowledgment in the granted transmission opportunity to the source node for the source node to send the new data.
25. 25. The communication device of Claim 24, wherein the ack delay module is configured to acknowledge the subset of received data by sending, in the granted transmission opportunity, a Block Acknowledgment (BA) frame that includes a starting sequence number and an acknowledgement bitmap to the source node, wherein the starting sequence number and the acknowledgement bitmap are set to acknowledge already-acknowledged received data and the subset of received data only.
26. 26. The communication device of Claim 24, wherein the ack delay module is configured, during the granted transmission opportunity, to send a Block Acknowledgment (BA) frame to the source node to acknowledge the subset of received data, and, after the BA frame, to send a frame transferring transmission rights of the allocated transmission period so that the source node takes control for data transmission of data units over the ad-hoc wireless network during the allocated transmission period.
27. 27. The communication device of Claim 26, wherein the ack delay module is configured, after the allocated transmission period in the granted transmission opportunity, to send a second Block Acknowledgment (BA) frame to acknowledge a subset of received data from a second source node, and, after the second BA frame, to send a second frame transferring transmission rights of the second transmission period within the granted transmission opportunity so that the second source node takes control for data transmission of data units over the ad-hoc wireless network during the second transmission period.
28. 28. The communication device of Claim 24, receiving new data from the source node during the allocated transmission period of the granted transmission opportunity, the ack delay module being configured to delay acknowledgment of the received new data for another predetermined delay duration.
29. 29. A non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a communication device of an ad-hoc wireless network, causes the communication device to perform the steps of receiving data of a data stream sent by a source node using a sliding window protocol, delaying acknowledgment of the received data to prevent, for a predetermined delay duration, the source node from requesting access to a network medium of the ad-hoc wireless network to send new data.
30. 30. A method for data communication in an ad-hoc wireless network substantially as herein described with reference to, and as shown in, Figure 8; Figure 9; Figures 8 and 9; Figures 8, 9 and 10 of the accompanying drawings.
31. 31. A communication device in an ad-hoc wireless network substantially as herein described with reference to, and as shown in, Figure 7 of the accompanying drawings.