Patent Application
20110141888
The invention relates to a method and a system for transporting data having no delay constraints and also data that can be considered as priority data in an ad-hoc wireless network. It is used to protect the real-time or high-priority streams relative to other data streams.
The transport procedure according to the invention may be adopted in the case of ad-hoc networks or domestic infrastructures so as to protect the VoIP telephony and IPTV (IP television) services that are becoming increasingly widespread. The procedure may be implemented in mobile ad-hoc wireless networks, better known as wireless mesh networks.
Ad-hoc networks may be composed of communicating wireless entities such as portable computers, cellular telephones, or sensors. These various entities constitute the nodes of an ad-hoc network, in which the network observes the input and output of these entities. In these networks, communication is in general possible only between the nodes in wireless range. A routing protocol (for example the OLSR (Optimized Link State Routing) protocol or the AODV (Ad-hoc On Demand Vector) protocol then ensures the relaying of the IP packets in order to provide connectivity from end to end. The nodes in the network may or may not be mobile.
It is often difficult to obtain good performance in this type of network because of the great variability and unpredictability of the wireless conditions and because all the nodes share the same communication medium. In a context in which the ad-hoc network must support as a priority real-time traffic, such as voice over IP, which may correspond to an emergency intervention situation or to a tactical network, data transport using the usual protocols, for example the TCP protocol, proves to be ineffective, as it is deleterious to real-time or priority data streams by adding delay and causing packet losses. This is because real-time services generate traffic that is generally not very tolerant to data loss or packet loss and are greatly affected by high levels of IP congestion or competition for access to the communication medium that the use of protocols such as TCP engenders.
One of the problems of transporting data in ad-hoc networks, in which real-time data streams have to be protected, is to provide a procedure enabling data or a data stream to be transmitted from a source to a destination without degrading the performance of critical streams such as voice-over IP or VoIP streams or video streams.
The problems associated with ad-hoc networks have been studied by the IETF (Internet Engineering Task Force) research group called the MANET (Mobile Ad-hoc NETworks) group available via the Internet link: www.ietf.org/htlm.charters/manet-charter.htlm. Solutions improving TCP performance in ad-hoc wireless environments have been proposed [ATCP—Ad-hoc Transport Control Protocol], [SNOOP] [TCPF—Transport Control Protocol Feedback]. These solutions, most often operating only at the source, make it possible to improve the performance of data transport in ad-hoc mobile networks, but they do not protect critical streams such as those coming from the VoIP services. Moreover, other approaches modify the TCP protocol using what is called “hop-by-hop” congestion control mechanisms described, for example, in the publication by Y. Yi and S. Shakkottai “Hop-by-Hop Congestion Control over a Wireless Multi-hop Network” IEEE/ACM Transaction on Networking, June 2007. The intermediate nodes correspond to destination notifications from the preceding nodes in the path travelled by the message. These approaches allow more precise and more rapid TCP adaptation but do not deal with protecting the real-time streams. In addition, the retransmission mechanisms remain end-to-end mechanisms. Moreover, the conventional QoS (Quality of Service) IP mechanisms such as scheduling or shaping do not enable the aforementioned problem to be addressed. These mechanisms have too local a vision of the environment since a node has knowledge only about the status of its queues. The nodes have no precise knowledge about the level of competition for transmitting streams over the medium and the nature of the traffic in the medium.
Other solutions proposed by the prior art employ data transport of the “storage and transmission” type. When an entity receives a message, it stores it until it transmits it in turn to a relay node or to the destination. The information is transmitted atomically (transmitted entirely at each hop) and is, usually but not necessarily, self-sufficient. This is for example the case for an email, a video or a text document. The intermediate nodes therefore have a large amount of memory at their disposal. These communication paradigms are similar to those defined in the architecture of the Internet transporting emails [SMTP] or in the communication architecture intended for delay-tolerant networks [DTNRG]. In [OTT06], the authors show the potential of such transport within the context of mobile ad-hoc networks in terms of performance when the transport at each hop takes place using the UDP (user datagram protocol) under CBR (constant bit rate) conditions:
[OTT06] J. Ott, D. Kutscher and C. Dwertmann, “Integrating DTN and MANET routing,” in Proc. CHANTS, 2006;
[TCPF] K. Chandran, S. Raghunathan, S. Venkatesan and R. Prakash, “A feedback based scheme for improving TCP performance in ad-hoc wireless networks,” in Proceedings of the International Conference on Distributed Computing Systems (ICDCS'98), Amsterdam, The Netherlands, May 1998;
[ATCP] J. Liu and S. Singh, “ATCP: TCP for mobile ad-hoc networks,” IEEE JSAC, Vol. 19, No. 7, pp. 1300-1315, July 2001.
For example, the drawback of the transport solution described in [OTT06] is that it involves “hop by hop” atomic handovers between the source and the destination and uses a CBR UDP transport at each hop. It therefore proves to be too aggressive for real-time streams and is not robust since no retransmission mechanism is provided.
The subject of the present invention implements a new approach in which the information is transmitted not in the form of packets but in the form of messages containing information that can be self-sufficient, which is handed over from entity to entity atomically.
In an embodiment, the invention relates to a procedure for transporting data in an ad-hoc wireless network, the network comprising several nodes in a configuration at a given instant, namely a source node, a destination node and several intermediate nodes characterized in that it comprises at each of the nodes, at least the following steps:
Other features and advantages will become apparent on reading the following detailed description given by way of nonlimiting example in conjunction with the appended drawings which represent:
To make the subject of the present invention better understood, the procedure will be described in the case of voice-over-IP message transmission considered as a priority data stream compared with other types of data such as data for managing or updating certain databases in the system.
To illustrate the procedure, in the case of an application for a tactical network, it is possible to imagine that the priority stream is that of an emergency call compared with other information.
The procedure may be implemented in the form of software in a protocol stack. It may also be implemented in the form of onboard software.
The network in which the procedure according to the invention is implemented, described in
The source node 1 comprises an application layer C1, a layer C2, through which the messages to be transmitted pass, a transport layer C3, a network layer C4, a link layer C5 and a physical layer C6. These layers are known to those skilled in the art and will not be described in detail here.
The destination node 3 comprises the same number of layers as the source node 1.
The intermediate nodes, or relay nodes, forming part of the path travelled by a message do not include an application layer or, at the very least, this layer is not used.
The DTN application module 10 relates to applications located in the source (source node in this example) and located in the message destination (destination node). A module 10 generates and receives messages M consisting of information that may be self-sufficient, such as electronic messages or images, but not necessarily so. The messages M potentially have any size. These applications do not have real-time constraints.
10. DTN Application: Application generating data streams without real-time constraint.
11. API: The applications transmit and receive the messages via this API (Application Programming Interface).
12. Message database: The nodes of the network using the procedure are provided with a memory enabling them to store the messages in transit, i.e. those which are intended to be retransmitted to their destination node. This database is filled or read by the applications using the above API.
13. Routing table: This table contains the routes indicating which relay mode is chosen for reaching such or such a destination. This table is filled by a routing protocol that may be of the unicast IP type (e.g., OLSR) or of the DTN type (e.g., ProPhet—Probabilistic Routing Protocol using History of Encounters and Transitivity) [LIN04]. These mechanisms are known to those skilled in the art in the field of routing and will not be discussed in detail.
14. Neighborhood table: This table contains the list of nodes with which the current node is in contact (e.g. in wireless range). Likewise, the procedure uses conventional mechanisms for the neighborhood table.
15. Handover scheduling: This module serves to decide which message must now be handed over by the opportunistic handover module 16 described below. This decision is taken using the information provided by the routing and neighborhood tables and the optional mechanisms managing the priorities between the messages. A node should be involved only in one message handover at a time, although this property is not absolute.
16. Opportunistic transmission module: This module is responsible for transporting messages from one node to another. It splits the message to be transmitted into packets (for example, it may split the message into several IP packets). It is this module that takes the decision at each instant to give or not give the next waiting packet to the MAC layer depending on the information returned by the measurement module 8. This module comprises a counter 22 for monitoring the number of packets Pi transmitted.
17. Measurement module: This module returns the values of parameters measured locally or in the neighborhood to the opportunistic transmission module 16. For example, the measured parameters may be the average jitter and the average loss rate of the real-time streams in transit in the wireless coverage zone of the node or any other parameter that a person skilled in the art considers to be useful for deciding on transmitting the data. Thus, the opportunistic transmission module 16 is designed to evaluate whether dispatching packets that it is on the point of generating will cause competition that may degrade the real-time streams. The decision by the opportunistic handover module 16 to dispatch the next packet or not to dispatch it may be taken for example using thresholds on the values of the parameters measured by the present measurement module 17.
In general, the measurements that this module makes may incorporate local information, for example statistics returned by the “driver” 21 relating to the transmissions that have been made in the recent past, information relating to the real-time streams in transit at the current node or coming from the neighborhood (e.g. the real-time streams exchanged in the neighborhood, or statistics relating to air interfaces on the neighboring nodes obtained by a beaconing protocol). The measurement module may be based on the state of congestion of the network arteries or of the arteries linking with the node in question.
18. CAC: This module decides whether the current node is capable of accepting an incoming message handover. This decision is made by taking into account information about the size of the database 12, possible handovers that have been scheduled by 14, or information about the state of the node (e.g. energy).
19. Receiving module: The function of this module is to receive the data messages. It may or may not return acknowledgements to the transmitting node (e.g. ACK, SACK (Selective ACKnowledgement)). Once the message has been received in its entirety, this receiving module stores it in the message database 12.
20. Congestion control: This optional module serves to exchange messages between the nodes participating in the handovers so as to provide congestion control from end to end or in an overall manner in the network.
21. MAC layer: This module represents the layer for access to the medium, this layer being specific to each type of wireless interface. It is capable of providing the measurement module 17 with statistics and is capable of transmitting and receiving packets over the air interface.
22. Counter: This module represents the counter used when transmitting a message by the transport protocol (16).
The procedure implemented by the present invention comprises, for example, the following steps:
Once the application 10 has generated a message, it is sent to the application 11 that serves as interface of the database 12 in which the messages to be transmitted are stored. The message is then recovered by the scheduler 15 responsible for scheduling its handover. This scheduling is carried out using the information coming from the routing table 13 indicating the available route or routes for transmitting the message or messages and also information coming from the table containing the neighboring nodes 14 indicating whether the next node on the routes is available or not. The scheduler may also receive an acknowledgement or correct-reception message coming from the receiving module 19. Once the acknowledgement message has been received, the message that has been correctly transmitted, and therefore sent to its destination, may be removed from the database.
The messages coming from the scheduler 15 are then transmitted to the opportunistic handover module 16 responsible for handing over the message to the next hop. To do this it uses the measurements made by the measurement module 17 that takes into account the parameters measured in the wireless vicinity relating to the real-time streams that it is desired to protect.
The distributed algorithm of the decision to send messages within the context of the opportunistic transport protocol 16 comprises the steps described below and is implemented at each node constituting a network at a given instant.
The route used for transmitting a message is determined from the information contained in the routing table and in the table giving the closest neighbors using mechanisms or techniques known to those skilled in the art.
The message generated by the application 10 is placed in a main queue at a node.
A first step consists in dividing the message M into N packets P. The number N is known at the start. It is possible to use a counter set to zero or N depending on whether it is chosen to increment this counter or decrement it each time a packet Pi is transmitted.
A packet Pi is given to the network layer or to the MAC (Medium Access Control) layer.
As long as packets Pi remain to be transmitted:
The opportunistic handover module manages and orders the transmission times and the queuing times. The queuing time may be random if there is no coordination between the nodes. In other cases, the queuing time is zero and the attempt to retransmit a packet is virtually immediate.
The invention therefore makes it possible to transport information stored in the form of a message from a source to a destination, while protecting the real-time traffic such as voice-over-IP traffic.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0708547 | Dec 2007 | FR | national |
This application is the U.S. National Phase application under 35 U.S.C. §371 of International Application No. PCT/EP2008/066932, filed Dec. 5, 2008, and claims the benefit of French Patent Application No. 0708547, filed Dec. 7, 2007, all of which are incorporated by reference herein. The International Application was published on Jun. 11, 2009 as WO 2009/071688.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2008/066932 | 12/5/2008 | WO | 00 | 2/28/2011 |
