« AnteriorContinuar »
METHOD AND SYSTEM FOR
FAULT-TOLERANT QUALITY OF SERVICE
FEDERALLY SPONSORED RESEARCH OR
MICROFICHE/COPYRIGHT REFERENCE [Not Applicable]
BACKGROUND OF THE INVENTION
The presently described technology generally relates to communications networks. More particularly, the presently described technology relates to systems and methods for providing a Quality of Service mechanism that is tolerant of an unreliable physical layer.
Communications networks are utilized in a variety of environments. Communications networks typically include two or more nodes connected by one or more links. Generally, a communications network is used to support communication between two or more participant nodes over the links and intermediate nodes in the communications network. There may be many kinds of nodes in the network. For example, a network may include nodes such as clients, servers, workstations, switches, and/or routers. Links may be, for example, modem connections over phone lines, wires, Ethernet links, Asynchronous Transfer Mode (ATM) circuits, satellite links, and/or fiber optic cables.
A communications network may actually be composed of one or more smaller communications networks. For example, the Internet is often described as network of interconnected computer networks. Each network may utilize a different architecture and/or topology. For example, one network may be a switched Ethernet network with a star topology and another network may be a Fiber-Distributed Data Interface (FDDI) ring.
Communications networks may carry a wide variety of data. For example, a network may carry bulk file transfers alongside data for interactive real-time conversations. The data sent on a network is often sent in packets, cells, or frames. Alternatively, data may be sent as a stream. In some instances, a stream or flow of data may actually be a sequence of packets. Networks such as the Internet provide general purpose data paths between a range of nodes and carrying a vast array of data with different requirements.
Communication over a network typically involves multiple levels of communication protocols. A protocol stack, also referred to as a networking stack or protocol suite, refers to a collection of protocols used for communication. Each protocol may be focused on a particular type of capability or form of communication. For example, one protocol may be concerned with the electrical signals needed to communicate with devices connected by a copper wire. Other protocols may address ordering and reliable transmission between two nodes separated by many intermediate nodes, for example.
Protocols in a protocol stack typically exist in a hierarchy. Often, protocols are classified into layers. One reference model for protocol layers is the Open Systems Interconnection (OSI) model. The OSI reference model includes seven layers: a physical layer, data link layer, network layer, trans
port layer, session layer, presentation layer, and application layer. The physical layer is the "lowest" layer, while the application layer is the "highest" layer. Two well-known transport layer protocols are the Transmission Control Proto
5 col (TCP) and User Datagram Protocol (UDP). A well known network layer protocol is the Internet Protocol (IP).
At the transmitting node, data to be transmitted is passed down the layers of the protocol stack, from highest to lowest. Conversely, at the receiving node, the data is passed up the
10 layers, from lowest to highest. At each layer, the data may be manipulated by the protocol handling communication at that layer. For example, a transport layer protocol may add a header to the data that allows for ordering of packets upon arrival at a destination node. Depending on the application,
15 some layers may not be used, or even present, and data may just be passed through.
One kind of communications network is a tactical data network. A tactical data network may also be referred to as a tactical communications network. A tactical data network
20 may be utilized by units within an organization such as a military (e.g., army, navy, and/or air force). Nodes within a tactical data network may include, for example, individual soldiers, aircraft, command units, satellites, and/or radios. A tactical data network may be used for communicating data
25 such as voice, position telemetry, sensor data, and/or realtime video.
An example of how a tactical data network may be employed is as follows. A logistics convoy may be in-route to provide supplies for a combat unit in the field. Both the
30 convoy and the combat unit may be providing position telemetry to a command post over satellite radio links. An unmanned aerial vehicle (UAV) may be patrolling along the road the convoy is taking and transmitting real-time video data to the command post over a satellite radio link also. At
35 the command post, an analyst may be examining the video data while a controller is tasking the UAV to provide video for a specific section of road. The analyst may then spot an improvised explosive device (IED) that the convoy is approaching and send out an order over a direct radio link to
40 the convoy for it to halt and alerting the convoy to the presence of the IED.
The various networks that may exist within a tactical data network may have many different architectures and characteristics. For example, a network in a command unit may
45 include a gigabit Ethernet local area network (LAN) along with radio links to satellites and field units that operate with much lower throughput and higher latency. Field units may communicate both via satellite and via direct path radio frequency (RF). Data may be sent point-to-point, multicast, or
50 broadcast, depending on the nature of the data and/or the specific physical characteristics of the network. A network may include radios, for example, set up to relay data. In addition, a network may include a high frequency (HF) network which allows long rang communication. A microwave
55 network may also be used, for example. Due to the diversity of the types of links and nodes, among other reasons, tactical networks often have overly complex network addressing schemes and routing tables. In addition, some networks, such as radio-based networks, may operate using bursts. That is,
60 rather than continuously transmitting data, they send periodic bursts of data. This is useful because the radios are broadcasting on a particular channel that must be shared by all participants, and only one radio may transmit at a time.
Tactical data networks are generally bandwidth-con
65 strained. That is, there is typically more data to be communicated than bandwidth available at any given point in time. These constraints may be due to either the demand for band3
width exceeding the supply, and/or the available communications technology not supplying enough bandwidth to meet the user's needs, for example. For example, between some nodes, bandwidth may be on the order of kilobits/sec. In bandwidth-constrained tactical data networks, less important 5 data can clog the network, preventing more important data from getting through in a timely fashion, or even arriving at a receiving node at all. In addition, portions of the networks may include internal buffering to compensate for unreliable links. This may cause additional delays. Further, when the 10 buffers get full, data may be dropped.
In many instances the bandwidth available to a network cannot be increased. For example, the bandwidth available over a satellite communications link may be fixed and cannot effectively be increased without deploying another satellite. 15 In these situations, bandwidth must be managed rather than simply expanded to handle demand. In large systems, network bandwidth is a critical resource. It is desirable for applications to utilize bandwidth as efficiently as possible. In addition, it is desirable that applications avoid "clogging the 20 pipe," that is, overwhelming links with data, when bandwidth is limited. When bandwidth allocation changes, applications should preferably react. Bandwidth can change dynamically due to, for example, quality of service, jamming, signal obstruction, priority reallocation, and line-of-sight. Networks 25 can be highly volatile and available bandwidth can change dramatically and without notice.
In addition to bandwidth constraints, tactical data networks may experience high latency. For example, a network involving communication over a satellite link may incur latency on 30 the order of half a second or more. For some communications this may not be a problem, but for others, such as real-time, interactive communication (e.g., voice communications), it is highly desirable to minimize latency as much as possible.
Another characteristic common to many tactical data net- 35 works is data loss. Data may be lost due to a variety of reasons. For example, a node with data to send may be damaged or destroyed. As another example, a destination node may temporarily drop off of the network. This may occur because, for example, the node has moved out of range, the 40 communication's link is obstructed, and/or the node is being jammed. Data may be lost because the destination node is not able to receive it and intermediate nodes lack sufficient capacity to buffer the data until the destination node becomes available. Additionally, intermediate nodes may not buffer 45 the data at all, instead leaving it to the sending node to determine if the data ever actually arrived at the destination.
Often, applications in a tactical data network are unaware of and/or do not account for the particular characteristics of the network. For example, an application may simply assume 50 it has as much bandwidth available to it as it needs. As another example, an application may assume that data will not be lost in the network. Applications which do not take into consideration the specific characteristics of the underlying communications network may behave in ways that actually exacer- 55 bate problems. For example, an application may continuously send a stream of data that could just as effectively be sent less frequently in larger bundles. The continuous stream may incur much greater overhead in, for example, a broadcast radio network that effectively starves other nodes from com- 60 municating, whereas less frequent bursts would allow the shared bandwidth to be used more effectively.
Certain protocols do not work well over tactical data networks. For example, a protocol such as TCP may not function well over a radio-based tactical network because of the high 65 loss rates and latency such a network may encounter. TCP requires several forms of handshaking and acknowledgments
to occur in order to send data. High latency and loss may result in TCP hitting time outs and not being able to send much, if any, meaningful data over such a network.
Information communicated with a tactical data network often has various levels of priority with respect to other data in the network. For example, threat warning receivers in an aircraft may have higher priority than position telemetry information for troops on the ground miles away. As another example, orders from headquarters regarding engagement may have higher priority than logistical communications behind friendly lines. The priority level may depend on the particular situation of the sender and/or receiver. For example, position telemetry data may be of much higher priority when a unit is actively engaged in combat as compared to when the unit is merely following a standard patrol route. Similarly, real-time video data from an UAV may have higher priority when it is over the target area as opposed to when it is merely in-route.
There are several approaches to delivering data over a network. One approach, used by many communications networks, is a "best effort" approach. That is, data being communicated will be handled as well as the network can, given other demands, with regard to capacity, latency, reliability, ordering, and errors. Thus, the network provides no guarantees that any given piece of data will reach its destination in a timely manner, or at all. Additionally, no guarantees are made that data will arrive in the order sent or even without transmission errors changing one or more bits in the data.
Another approach is Quality of Service (QoS). QoS refers to one or more capabilities of a network to provide various forms of guarantees with regard to data that is carried. For example, a network supporting QoS may guarantee a certain amount of bandwidth to a data stream. As another example, a network may guarantee that packets between two particular nodes have some maximum latency. Such a guarantee may be useful in the case of a voice communication where the two nodes are two people having a conversation over the network. Delays in data delivery in such a case may result in irritating gaps in communication and/or dead silence, for example.
QoS may be viewed as the capability of a network to provide better service to selected network traffic. The primary goal of QoS is to provide priority including dedicated bandwidth, controlled jitter and latency (required by some realtime and interactive traffic), and improved loss characteristics. Another important goal is making sure that providing priority for one flow does not make other flows fail. That is, guarantees made for subsequent flows must not break the guarantees made to existing flows.
Current approaches to QoS often require every node in a network to support QoS, or, at the very least, for every node in the network involved in a particular communication to support QoS. For example, in current systems, in orderto provide a latency guarantee between two nodes, every node carrying the traffic between those two nodes must be aware of and agree to honor, and be capable of honoring, the guarantee.
There are several approaches to providing QoS. One approach is Integrated Services, or "IntServ." IntServ provides a QoS system wherein every node in the network supports the services and those services are reserved when a connection is set up. IntServ does not scale well because of the large amount of state information that must be maintained at every node and the overhead associated with setting up such connections.
Another approach to providing QoS is Differentiated Services, or "DiffServ." DiffServ is a class of service model that enhances the best-effort services of a network such as the Internet. DiffServ differentiates traffic by user, service
requirements, and other criteria. Then, DiffServ marks packets so that network nodes can provide different levels of service via priority queuing or bandwidth allocation, or by choosing dedicated routes for specific traffic flows. Typically, a node has a variety of queues for each class of service. The 5 node then selects the next packet to send from those queues based on the class categories.
Existing QoS solutions are often network specific and each network type or architecture may require a different QoS configuration. Due to the mechanisms existing QoS solutions 10 utilize, messages that look the same to current QoS systems may actually have different priorities based on message content. However, data consumers may require access to highpriority data without being flooded by lower-priority data. Existing QoS systems cannot provide QoS based on message 15 content at the transport layer.
As mentioned, existing QoS solutions require at least the nodes involved in a particular communication to support QoS. However, the nodes at the "edge" of network may be adapted to provide some improvement in QoS, even if they 20 are incapable of making total guarantees. Nodes are considered to be at the edge of the network if they are the participating nodes in a communication (i.e., the transmitting and/or receiving nodes) and/or if they are located at chokepoints in the network. A chokepoint is a section of the network where 25 all traffic must pass to another portion. For example, a router or gateway from a LAN to a satellite link would be a choke point, since all traffic from the LAN to any nodes not on the LAN must pass through the gateway to the satellite link.
In many radio or wireless-based networks, the physical 30 links are somewhat unreliable resulting in frequent link failures. When this occurs, data may be lost during the period the network is down. Currently, one way of handling problems with an unreliable physical link is by using small data buffering. Small data buffering is when a radio (for example) in a 35 network provides small buffers that retain the data until successfully sent on a first in first out (FIFO) basis with no respect to the priority of the data (i.e., no QoS). When buffers are not used, some sort of data loss is accepted. Some applications tolerate data loss by continuing to send data regardless 40 of physical link status. Other applications stop sending data when a physical link is detected as failed (referred to as throttling).
Thus, there is a need for systems and methods providing a QoS mechanism that is tolerant of an unreliable physical 45 layer. More specifically, there is a need for adaptive, configurable QoS systems and methods in a tactical data network that provide a QoS-based buffering mechanism that can preserve large quantities of data sent by higher level applications until the physical link is returned to service. 50
BRIEF SUMMARY OF THE INVENTION
Certain embodiments of the present invention provide for a method for fault-tolerant QoS data communication. The 55 method includes differentiating one or more message data into a primary storage, storing the differentiated one or more message data in a secondary storage if the primary storage becomes exhausted, prioritizing the one or more message data, and communicating the one or more message data. The 60 one or more message data are differentiated based on one or more queue selection rules. The one or more message data are prioritized based on one or more queue sequencing rules. The one or more message data are communicated based at least in part on the prioritization of the one or more message data. 65
Certain embodiments of the present invention provide for a system for fault-tolerant QoS data communication. The sys
tern includes a differentiation component, a primary storage component, a secondary storage component, and a prioritization component. The differentiation component is adapted to differentiate one or more message data using one or more queue selection rules. The primary storage component is adapted to store the differentiated one or more message data. The secondary storage component is adapted to store the one or more message data if the primary storage component becomes exhausted. The prioritization component is adapted to prioritize the one or more message data using one or more queue sequencing rules.
Certain embodiments of the present invention provide for a computer-readable medium including a set of instructions for execution on a computer. The set of instructions includes a differentiation routine, a prioritization routine, and a communication routine. The differentiation routine is configured to differentiate one or more message data into one or more queues using one or more queue selection rules. The prioritization routine is configured to determine a priority for the one or more message data using one or more queue sequencing rules. The communication routine is configured to communicate the one or more message data based at least in part on the prioritization routine.
BRIEF DESCRIPTION OF SEVERAL VIEWS OF
FIG. 1 illustrates a tactical communications network environment operating with an embodiment of the present invention.
FIG. 2 shows the positioning of the data communications system in the seven layer OSI network model in accordance with an embodiment of the present invention.
FIG. 3 depicts an example of multiple networks facilitated using the data communications system in accordance with an embodiment of the present invention.
FIG. 4 illustrates a fault-tolerant QoS data communication system operating with an embodiment of the present invention.
FIG. 5 illustrates a flow diagram for a method for faulttolerant QoS data communication in accordance with an embodiment of the present invention.
The foregoing summary, as well as the following detailed description of certain embodiments of the present invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, certain embodiments are shown in the drawings. It should be understood, however, that the present invention is not limited to the arrangements and instrumentality shown in the attached drawings.
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 illustrates a tactical communications network environment 100 operating with an embodiment of the present invention. The network environment 100 includes a plurality of communication nodes 110, one or more networks 120, one or more links 130 connecting the nodes and network(s), and one ormore communication systems 150 facilitating communication over the components of the network environment 100. The following discussion assumes a network environment 100 including more than one network 120 and more than one link 130, but it should be understood that other environments are possible and anticipated.
Communication nodes 110 may be and/or include radios, transmitters, satellites, receivers, workstations, servers, and/ or other computing or processing devices, for example.