Internet protocol stack for real time applications

Multiplex communications – Data flow congestion prevention or control – Control of data admission to the network

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C370S231000, C370S235000, C370S469000, C370S493000

Reexamination Certificate

active

06707791

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Technical Field of the Invention
The present invention relates in general to the telecommunications field and, in particular, to an Internet Protocol (IP) stack which is suitable for use with real-time telecommunications applications.
2. Description of Related Art
There is a significant need to improve the perceived quality of real-time communications for end users. For example, the perceived quality of such real-time applications as audio or video communications connected with packet-based networks that allow mixed services (e.g., voice, video, data, file sharing, etc.) needs to be improved. A good example of such a packet-based network that allows mixed services is the IP network typically used in the Internet and many companies' intranets.
Today's implementation of telephony over IP-based networks has developed into a multi-million dollar industry, wherein data communication companies such as Microsoft, Intel and 3Com are competing with traditional telecommunication companies such as Ericsson, Nokia and Lucent to market their respective products to the network operators. The network operators are not only the traditional companies such as Telia and Telstra, but they also include new companies entering this field, such as Delta Three and Telecom Finland which offer end users low-cost telephony services over IP-based networks. The lower cost for IP-telephony service results from the fact that IP-based communications equipment is less costly than traditional circuit-switched communications equipment. The reduction in costs for the IP-based equipment is due to the large mass market for IP products offered by different vendors, and the less complex components required for the IP-based equipment to complete their assigned tasks.
The typical end user has a great deal of confidence in the traditional telephony services that utilize circuit-switched networks. Users of these services seldom experience dropped calls or blocked calls due to a network overload. Also, the perceived quality of these traditional telephony services is relatively stable. Consequently, in order for IP-based network telephony services to become strongly competitive with the traditional telephony services, the end users will have to receive IP-based services which are similar in both reliability and quality to the traditional services being provided. However, an end user might discount such attractive features if other benefits are made available, such as, for example, lower costs or higher mobility. In fact, the advantages of higher mobility are the primary reasons why the cellular telephony field has grown enormously during the past few years.
From an end user's point of view, the perceived quality of the telephony services being provided depends on the end-to-end delay and packet losses experienced between the source encoder and decoder. Notably, a packet is assumed to be lost if it is delayed in reaching the decoder for more than a specified period. As such, it is desirable to keep the end-to-end delay as short as possible in all interactive applications (e.g., especially for telephony). A shorter delay improves the conversation possibilities when two persons are talking to each other. A shorter delay also reduces the complexity of the echo cancellers being used, because an echo associated with a shorter delay is less annoying to an end user. Consequently, less cancellation of the echo is needed (i.e., less complex cancellation algorithm). For example, echoes can occur whenever a mismatch exists somewhere in the analog part of the network. Also, echoes can be caused by acoustical coupling between an audio output stage (loudspeaker) and input stage (microphone) of a cellular phone.
As such, the end-to-end delay from an audio input stage to an audio output stage is illustrated by the following delay budget: (1) source encoder delay (including encoder look-ahead); (2) source encoder processing delay; (3) source encoder analysis data packetizing delay; (4) network access delay; (5) network transportation delay; (6) decoder unpacking delay; and (7) decoder synthesis delay. Each of these seven delay segments can introduce an addition to the end-to-end delay, and all of these segments except the source encoder delay (1) can introduce variations to the delay. At the decoder side, a terminal should be able to compensate for the end-to-end delay and the delay variations, or the transmitted packets from the encoder side will be lost.
Terminals used in IP-based networks typically have IP stacks implemented as shown in FIG.
1
. As illustrated by
FIG. 1
, there are various network bearers of IP packets (physical layer), including the Ethernet (most commonly used transport media for IP packets), Asynchronous Transfer Mode (ATM) networks, and wireless network bearers such as the data channels of the Global System for Mobile Communications (GSM) or the packet-based General Packet Radio Service (GPRS). Above the physical layer, the IP (network layer) performs two functions: addressing and fragmentation.
Above the physical layer is the transport layer. In that layer, the Telecommunications Control Protocol (TCP) is connection-oriented between two end-points, and thereby supports the re-transmission of packets which are lost in the chain between the two end-points. The User Datagram Protocol (UDP) is connection-less and used, for example, in real-time applications where re-transmissions would be useless because of the real-time requirements imposed.
IP-telephony applications can be executed in the application layer. An IP-telephony application performs a call setup procedure over the transport layer using the TCP, because it is important that the call be correctly connected. As soon as the connection is established, the application switches over to use the UDP for transmitting speech packets in real-time. As such, the IP stack is a unique resource at an end-point, and several applications can share the IP stack through addressing using the transport layer protocol.
A significant problem that exists for terminals with an IP stack implementation is that the stack functions in accordance with a first-in-first-out (FIFO) scheme, which can lead to undesirable results. For example, several different applications can share the same IP stack. Consequently, TCP packets, which have different real-time requirements than the UDP which is carrying interactive voice packets, can delay the transport of real-time packets through the network stack. Notably, this problem is exacerbated when the physical layer has limited bandwidth.
To illustrate such a problem, assume that a terminal is being used in a GPRS system with a maximum bit rate of 115 kbits/s. Also, assume that the terminal is providing a GSM (or similar system) speech service using a 13 kbits/s coder/decoder (codec). Every 20 ms, the codec packetizes the speech data into 260 bit packets for transmission over the radio channel. Simultaneously, the terminal's user initiates the transmission of a data file over the radio link. If the maximum packet size needed to obtain a reasonable payload is 132 bytes long (4 bytes and 128 bytes for compressed header and application data, respectively), it takes about 10 ms to transmit the packet containing the data file. If this data packet reaches the IP stack before the speech packet does (with its real-time requirements), the transport of the speech packet will be unnecessarily delayed. This additional transport delay of the speech packet becomes more severe for channels with lower bandwidths, or systems that utilize larger packets. In fact, an additional delay of 10 ms is relatively large compared to a delay requirement of less than 2 ms per router hop or 5-6 &mgr;s/km for transmissions between routers. As described in detail below, the present invention successfully resolves these delay problems and other related problems.
SUMMARY OF THE INVENTION
In accordance with a preferred embodiment of the present invention, a source encoder schedules its access to a network stack. During that scheduled

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Internet protocol stack for real time applications does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Internet protocol stack for real time applications, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Internet protocol stack for real time applications will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-3251918

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.