System and method of transferring communications between networks

Systems and methods of providing data from a first network to a second network are provided. When a first packet is received from the first network, it is determined whether the first packet includes state information. When the packet includes state information, a packet is transmitted to the first network in response to receipt of a first packet. The first packet can then be transmitted to the second network. The method can also involve removing the state information from the first packet prior to transmission to the second network and conversion of a transport layer of the first packet from a first protocol to a second protocol prior to transmission to the second network.

BACKGROUND OF THE INVENTION

There are a variety of different types of communication networks, such as terrestrial-based wireless communication networks and satellite communication networks. Terrestrial-based wireless communication networks are commonly known as cellular networks because the network topology revolves around a number of base stations each supporting wireless communication units within a defined region known as a cell. Compared to terrestrial-based wireless communication networks, satellite communication networks have a large number of drawbacks, including the expense of the satellites and the associated handsets. An additional problem with satellite communication networks is the large latency associated with the time required for information to travel between a land-based communication device and the satellite. This delay is then repeated for the transmission of the communication from the satellite back down to another communication device. The delay introduced due to the satellite communication links begins on the order of 500 ms and can exceed 2,500 ms.

SUMMARY OF THE INVENTION

The roundtrip delay time for satellite communications has always been known as a significant obstacle to the adoption of satellite communication networks for voice communications. It has been recognized that this roundtrip delay can also be problematic for data communications. Specifically, stateful packet-based protocols require the exchange of state information between the sending and receiving device in order to operate efficiently. If too large of a delay is introduced into the exchange of state information, a much reduced throughput of packets between a sending and receiving device can result. Thus, it is difficult to exchange communications between two networks in which one network employs a packet-based stateful protocol with a second network that does not have sufficient performance to support stateful packet-based protocols, such as satellite communications networks.

Accordingly, exemplary embodiments of the present invention provide systems and methods of providing data from a first network to a second network. When a first packet is received from the first network, it is determined whether the first packet includes state information. When the packet includes state information, a packet is transmitted to the first network in response to receipt of a first packet. The first packet can then be transmitted to the second network. The method can also involve removing the state information from the first packet prior to transmission to the second network and conversion of a transport layer of the first packet from a first protocol to a second protocol prior to transmission to the second network.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1is a block diagram of an exemplary system in accordance with the present invention. Exemplary embodiments provide an inter-working gateway120to couple a terrestrial-based wireless communication network105, such as WiMAX network, to a communication device124via a satellite network122. Communication device124can be any type of communication device that is capable of receiving signals from a satellite network, and in some cases can be capable of transmitting signals to the satellite network. For example, the communication device can be a stand-alone communication device (such as a handset, personal media equipment, computer and/or the like) or can be integrated with another device (such as being integrated into a motor vehicle, home appliance and/or the like). Communication device124can also include functionality for exchanging communications with terrestrial-based wireless communication network105.

The terrestrial-based communication network includes a number of application servers, such as an e-mail exchange server102, audio music server104, web server106, and streaming multi-media server108. The present invention is not limited to the application servers illustrated inFIG. 1, and can include other types of application servers, such as dispatch communication (also referred to as push-to-talk communication), other types of data services, telematics, geo-location services and/or the like. These services can be provided on a unicast (i.e., packets addressed to a particular receiver), multicast (i.e., packets addressed to a number of receivers) or broadcast (i.e., packets that are not addressed to any particular receiver) basis. It should be recognized that even in a broadcast scenario, the packets can be encrypted such that only particular receivers are able to decode the received packets.

One exemplary service that can be provided is streaming audio and/or video. This type of streaming media can originate from a web server, audio music server or streaming media server located on the Internet, a media head-end (such as a broadcast television or radio head-end, cable system head-end and/or the like), and/or can originate from a server located at a wireless communication network service provider's facilities.

The terrestrial-based communication network can also include a foreign agent110, home agent112and an authentication, authorization and accounting server114(AAA). The terrestrial-based communication network is coupled to gateway120via a wireless backhaul communication link118or a hard-wired communication link, such as fiber optic link116. The gateway120of the present invention allows communication device124to access application servers and other services provided by the terrestrial-based communication network105, even when device124is not located within radio frequency range of network105. Instead, communication device124can be located in an area in which it can only receive communications from a satellite communication network122, and data for the applications or other services of terrestrial-based communication network105are forwarded by gateway120via satellite network122. It should be recognized, however, that communication device124can exchange communications with the satellite communication network even when within the coverage area of a terrestrial-based.

FIG. 2is a detailed block diagram of an exemplary system in accordance with the present invention. The system includes application server202, gateway220, and receiver250. Application server202can be any of the application servers described above, and receiver250can be any type of communication device described above. Application server202is illustrated with its various protocol layers, including application layer204, a transport layer that includes transmission control protocol (TCP)206and universal datagram protocol (UDP)208, IP layer210, and lower protocol layers212. Data packets that are formatted in accordance with TCP or UDP protocols are transferred from application server202to gateway220, which are initially received by lower protocol layers222of gateway220.

TCP is a stateful protocol in which packets contain information about the state of the communication session between the sender and receiver, whereas UDP is a stateless protocol in which the packets do not include state information. Moreover, TCP is a synchronous protocol that provides flow control mechanisms, whereas UDP is an asynchronous protocol that provides no flow control mechanisms. Exemplary embodiments of the present invention provide a tweak filter that accounts for these differences between TCP and UDP protocols in order to provide optimal transfer of services from a terrestrial communication network to communication receiver by way of a satellite communication network.

The data packets are passed from lower layers222to tweak filter224which examines the transport layer of the packets to determine whether the packets are formatted according to a stateful or stateless protocol. For data packets of stateless protocols, such as UDP, tweak filter224passes the packets unmodified to transport protocol conversion (TPC) dynamic packetizer226. For stateful data packets, such as TCP data packets, tweak filter224performs spoofing to application server202in order to maintain the data packet state. Specifically, as part of TCP protocol, acknowledgements are returned from a receiver to the sender to confirm successful receipt of the packets. Accordingly, tweak filter224will send such acknowledgement packets with state information, even though the ultimate receiver250has not yet received the packets. Moreover, TCP flow control includes a so-called “slow start” mechanism where a few packets are initially sent and the sender increases or decreases the rate at which packets are sent in response to the rate at which acknowledgements are received. Thus, tweak filter224will control the timing of sending the acknowledgement packets to application server202in order to optimize the transmission of data packets from application server202to gateway220. Because tweak filter224determines whether a packet is formatted in accordance with a stateful protocol by examining the transport layer protocols, and the filter does not need to interpret any information from the application layer.

For stateful packets, tweak filter224forwards the payload data of the packet to TPC226, whereas for stateless packets, tweak filter224forwards the entire packet to TPC226. Upon receipt of the packets, TPC226examines the link status record (LSR)236in order to determine the size of the datagram for sending to a particular satellite beam. Context and control module (CCM)234updates LSR236with the datagram size. Accordingly, the present invention can dynamically increase/decrease the data size of the payload sent over the satellite link based on information stored in LSR236. LSR236estimates the datagram size for transmission based on measurements of data exchange with the satellite communication network during a particular period of time.

Satellite lower layers238subject each stream to header compression to eliminate redundancy in headers for the particular stream, and CCM234creates control messages with context information regarding the header compression and stream-related parameters. As described above, the present invention can support multicast and broadcast packet streams. Accordingly, this control message will be broadcast at regular intervals, or on a request basis, through a control channel, which allows new listeners, such as satellite receivers who just tuned their receiver to a particular stream, to build the header decompression context. CCM234also captures feedback control messages from active satellite receivers, where these messages contain the mapped geographic location information and status of the link delay, error rate (packet/frame). CCM234unpacks the feedback control messages and estimates the performance parameter table per stream, where this table contains the stream information, mapped geo-location information, satellite beam-related information, satellite status-like delay experienced, error rate, and the like. Based on this information, CCM module234determines the comprehensive correction parameter for each stream and updates the link status record236.

Receiver250includes satellite lower layers252, feedback control module (FBM)254, header decompression module (HDM)256, control message decoding (CMD) module258, GPS receiver260, IP layer262, transport layer that includes TCP264and UDP268, application layer270, and application parameter module (APM)272.

When receiver250is tuned to a particular streaming channel, the receiver can synchronize with the ongoing stream in a number of ways. One technique is for the receiver to send current context request messages in order to construct the header compression context. Once a response message is received, context decoding module258constructs the context for the ongoing stream and links the context with incoming compressed streams. Another alternative is for the receiver to listen to the broadcast control channel in order for the context decoding module258to receive and unpack a context control message, and thus construct the context for the ongoing stream and link the context with incoming compressed streams.

Header decompression module256modulates and reproduces the header with the actual transport protocol based on the context control message received for the stream, i.e., translated TCP streams will be reverted back for application transparency. Thus, application layer270can receive stateful messages both while within range of the terrestrial-based wireless communication network and within range of the satellite-based wireless communication network. APM272collects the performance parameters from both the application layer and lower layers. These parameters include delay and error rate. If key parameters hit maximum or minimum boundary values, then APM272triggers the feedback module254to send the feedback to gateway220. FBM254interfaces with GPS module260in order to include the current location of receiver250in the feedback messages.

It should be recognized that the various components of the application server202, gateway220and receiver250can be implemented in hardware and/or software. The hardware can include a processor such as a microprocessor, field programmable gate array (FPGA) and/or an application specific integrated circuit (ASIC). When the hardware is a processor, then the various functionality described above can be processor-executable code loaded from a memory.

FIG. 3is a flow diagram of an exemplary method in accordance with the present invention. Initially, gateway220receives a packet from the terrestrial-based wireless communication network (step305). Tweak filter224examines the transport layer to determine whether the packet is associated with a stateful protocol or a stateless protocol (step310). When the packet is associated with a stateful protocol (“Yes” path out of decision step310), then tweak filter224sends an acknowledgement packet to application server202in the first network (step315). Tweak filter224then removes the payload from the packet and forwards it to TPC226(step320).

After removing the payload of a stateful packet or when the packet is not a stateful packet (“No” path out of decision step310), then TPC226creates a structure for the stream identifiers (step325) and determines the datagram size based on information stored in LSR236(step330). TPC226converts the protocol of the payload (when the received packet is a stateful packet) (step335), header compression module (HCM)232performs header compression for the packet (step340) and satellite lower layers238generate the packet for transmission to the satellite network and transmit the packet to that network (steps345and350).

FIG. 4is a call flow diagram of an exemplary method in accordance with the present invention. When the tweak filter224of gateway220receives incoming stateful packets (TCP packets) or stateless packets (UDP packets), TPC226sends an update of stream-related information to be used for control messages to context and control module234. TPC226also obtains the current dynamic datagram size from link status record236. For TCP packets, TPC226converts the packet into UDP packets, sends the packet to header compression module232for header compression, and module232updates the context information with context and control module234.

Context and control module234broadcasts compressed streaming data context requests across the satellite network, which can be received by receiver250. Control message decoder258of receiver250sends a context request to context and control module234which replies with a decode context response in order for receiver250to build the decompression context. Based on that response, control message decoder258updates the decompression context with header decompression module256. Gateway220then sends the data packets to satellite-based communication network, which forwards to them to receiver250. Accordingly, receiver250performs decompression and application processing, by way of modules256and270. Application performance module272receives information from application270in order to track the performance of the application, and forwards application performance status updates to FBM254. FBM254receives the receiver's current geographic information from GPS260, and then sends feedback control messages by way of the satellite communication network to gateway220. Context and control module234receives these messages and updates the link status record236based upon the feedback control message. As illustrated by the dashed line inFIG. 4, the updated information in the link status record is used to control the current datagram size.