Data transfer method for wire real-time communications

Details Data transfer method for wire real-time communications Data transfer method for wire real-time communications

1998-07-16

2002-12-17

Cangialosi, Salvatore (Department: 2661)

Multiplex communications

Diagnostic testing

Fault detection

C370S310000

Reexamination Certificate

active

06496481

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to a network and method of transmitting data packets, and, more particularly, relates to a network and transport protocol method of transmitting data packets over a wireless link for use in real-time multimedia applications.
BACKGROUND OF THE INVENTION
Wireless communication systems are now looking towards broadband solutions for future multimedia transmission. Wireless extension of broadband communications provides a radio access for the customers to enjoy integrated multimedia services. Technologies supporting such services include local area networks (LANs), wide area networks (WANs), wireless ATM, LMDS (Local Multipoint Distribution Service), MMDS (Multipoint Multichannel Distribution Service, or wireless cable), and broadband satellite communications. All of these systems are aimed to transmit data at a transmission speed from several Mega to several hundreds of Mega bits per seconds.
As compared with wired broadband systems, there are additional factors that make the design of the wireless broadband system more difficult. For example, wireless communication systems are less reliable then wired systems due to a higher bit error rate, a comparatively longer propagation delay (especially as the transmission speed getting higher), and a higher packet error rate caused by less reliable links and movement of the mobile stations. It has been shown that the cell loss rate in a wireless ATM system is around 10
−3
to 10
−5
with a bit error rate range 10
−4
to 10
−6
. Further, in a wireless ATM system having a transmission speed of 25 Mbps, it takes about 20 &mgr;sec to transmit a cell. This implies that the propagation delay may equal the time it takes to of transmit several cells in a wireless LAN or the time it takes to transmit several tens of cells in a wireless WAN. These factors will affect the throughput of a flow-controlled transport protocol.
Another issue is the asymmetry in wireless communication systems. Many studies have shown that the communication protocol between a wireless station and its wired access point should be asymmetric because of the limited resources on a wireless station (e.g., a lightweight handheld device). They suggest that the complicated part of a transport protocol should be put on the wired access point which may have more power to handle the tasks. However, performance tends to decrease as complicated tasks are removed from the wireless station. Accordingly, it has been recently recommended that the end-to-end transport protocol over wireless access network be divided into two parts in order to have a better performance, i.e., Indirect-TCP, and Mobile-TCP. This approach uses traditional transport protocols such as TCP on the wired part and requires a new design on transport and data link protocol for the wireless part. At the wireless access point (or base station), some protocol will also be necessary.
A further issue regarding the data transfer between two entities over a communication network requires careful flow controls on both sides to prevent the loss of packets due to, e.g., a shortage of buffers, a mismatch of processing rate, etc. Typical schemes can be classified into rate-based and quantum-based approaches. In the rate-based approach, the speed of sending packets is determined by its rate, i.e., by controlling the delay time gap between the sending of two consecutive packets. In the quantum-based scheme, the speed of sending packets is based on the receiver's available resources, such as buffers. As shown in
FIG. 17
, the receiver grants a window (W packets) for the transmitter via a control packet. Typically, this control packet is called an ACK packet (acknowledgment packet). However, the performance of this scheme is poor when the network link can process a large number of packets. In this case the network will have to wait for each packet to enter the receiving buffer. Further, control packets will also take a lot of time to arrive at the transmitter. In addition, during the sending of the control packet, other packets are not permitted to be sent. The well-known Internet protocol TCP/IP is currently using this method.
In U.S. Pat. No. 5,084,877 and in the I.E.E.E. article entitled, “Design and Implementation of a High Speed Transport Protocol”, I.E.E.E. Transactions on Communications, Vol. 38, No. 11, November 1990, pp.2010-2023 by A. N. Netravali, et al. a more aggressive approach has been proposed. In this method, the maximum possible number of outstanding packets is estimated, such that the packets may be sent earlier with a hope that the receiver will release new resources as the packets are received. With reference to
FIG. 18
, the control packet will carry available buffer information and maximum packet sequence number received information, W and LW
r
, respectively, to the sending site. Let UW
l
, be the packet sequence number which is about to be sent. Then NOB can be estimated by
UW
l
−LW
r
At the transmitter, the rules for permitting the transmission of a packet would be based on a control window L. When NOB<L and W-NOB>O, then a new packet can be sent. This scheme can improve the throughput of sending large continuous and burst data. However, when the network link, e.g., a wireless link, has a high packet error rate, then it is likely that packets will be dropped. If a packet is dropped, then it needs to be retransmitted. The traffic load brought by retransmission may lower the throughput of sending normal packets. Since the network capacity is large (which exhibits a long propagation delay), the receiver state cannot quickly feed back to the transmitter due to the delay of control packets. Further, the NOB may be overestimated and pause the transmission. Thus, the system will be forced to idle before new control packet arrive. In this case, using a large control window L value and a large receiver buffer may relieve the problems but requires more space and expense.
In U.S. Pat. No. 5,130,986, a two-window scheme was proposed to improve the above drawbacks. In this scheme, illustrated in
FIG. 19
, a receiver status map (RSM) is utilized having L bits, where each bit denotes the receiving status of the recently or soon to be received L packets. A bit
1
(0) represents that the packet is correctly (incorrectly) received and has been (not yet) stored in one of the L packet buffer spaces. Let N (RSM) denote the sum of all 1 bits in RSM. Thus, N (RSM) represents the current uncorrupted packets received but having not been acknowledged yet. Note, only when all packets are reassembled in sequence, can they be put on upper application processes. If there are still some sequence numbers missing, then the packets they should remain in the buffer.
In this scheme, a better estimation of NOB is:
NOB−N
(
RSM
)
By using two windows L
1
, and L
2
, and letting L
2
be very large and L
1
be approximately the network capacity, the performance can be improved.
With respect to the transport protocol, two control windows are used for controlling the volume of transmitted information, e.g., the number of packets. The first window, called the network window, is used to limit the data in the network so that network buffer resources can be sized economically and to prevent excessive packet loss. The second window, called the receiver flow control window, is used to assure that packets are not dropped. However, this only inhibits packet loss due to the shortage of buffers. When the network itself is lossy, the retransmission traffic will become heavy. This is especially true when the network capacity is large. In such a case, the effect will make the throughput worse since the exchange of control packets will take more time. In a more serious case, when the control packet is lost, the system will be forced to idle and can only be resumed by a timer.
U.S. Pat. Nos. 5,222,061 and 4,439,859 are related to the retransmission protocols where a major concern is the packet receiving sequence. U.S. Pat. Nos. 4,712,214, 4,928,096 and 4,975,952

Affiliated with

Also associated with

Rating

Data transfer method for wire real-time communications does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Data transfer method for wire real-time communications, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Data transfer method for wire real-time communications will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2997873