Multiplex communications – Communication over free space – Having a plurality of contiguous regions served by...
Reexamination Certificate
2000-05-31
2004-05-18
Vanderpuye, Kenneth (Department: 2732)
Multiplex communications
Communication over free space
Having a plurality of contiguous regions served by...
C370S338000
Reexamination Certificate
active
06738361
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates to a method, apparatus and computer program for applying a predetermined transmission process to the transmission of Internet Protocol (IP) packets of a particular IP flow in an IP network.
The success of Internet Protocol (IP) based networks has created a need for major enhancements in the original best-effort IP service model. In addition to the traditional best-effort applications (email, ftp, etc.) the trend in IP based networks is towards more sophisticated multimedia applications and protocols, including real-time audio and video. In fact, real-time IP applications and protocols already exist, although the current IP standards are not suitable for effectively carrying real-time traffic. To better suit IP based networks for real-time traffic, IP standards are being enhanced with new Quality of Service (QoS) mechanisms. Therefore, it is quite safe to assume that in the near future IP networks will be able to carry different types of traffic over a single packet switched network infrastructure. It can also be assumed that the changes in the IP service model will be reflected in wireless networks, thereby creating a need for development of wireless networks capable of reliably carrying different types of IP applications over the shared radio links.
A conventional IP network
120
, as illustrated in
FIG. 5
, having an IP layer
1201
and a physical layer
1202
, interconnects a plurality of hosts
100
.
FIG. 5
illustrates a representative portion of each host
100
. The details of each host
100
are illustrated in FIG.
3
. As per
FIG. 3
each host
100
includes a RTP layer
1001
, an IP session management protocol layer
1002
, a UDP layer
1003
, a TCP layer
1004
, and an IP layer
1005
.
As per
FIG. 3
, if the host
100
is a wireless terminal, then a radio link layer
1011
is provided. Also, as illustrated in
FIG. 5
, each host
100
can, for example, include a physical layer
1012
which interconnects the host
100
to the IP network
120
, via its physical layer
1202
. Further, as illustrated in
FIG. 3
, each host
100
has, for example, Multimedia applications
1006
connected to the RTP layer
1001
and the IP session management protocol layer
1002
via data interface
1007
and a control interface
1008
respectively. Also each host
100
has, for example, legacy applications
1009
connected to the TCP layer via a data interface
1010
.
Each host
100
can be any one of a terminal whether wireless or otherwise, a server or any other such apparatus connected to the IP network
120
. If the host
100
is a wireless terminal, then a wireless access point is necessary to allow the wireless terminal to communicate with the IP network
120
, or any apparatus that operates within IP network
120
.
As shown in
FIG. 5
, IP session management protocols are conducted according to protocols such as H.323, SIP, etc. between hosts so as to setup and release sessions. There is no distinction made between packets that may contain real-time data, or packets that may contain non-real-time data. In the current apparatus, all packets receive best efforts service.
The IP session management protocols currently in use do not depend in any way on the emerging IP-level QoS mechanism. In the currently used IP session management protocols there is no guarantee of available bandwidth or delay experienced by the IP packets. The ideal situation would be to inform the IP and/or link layer QoS mechanisms of the application level IP session in order to provide different priorities for different types of IP sessions. Such a mechanism is particularly important when real-time IP sessions are to be conducted over wireless networks, specifically shared radio links having limited bandwidth.
The problem in transmitting real-time IP traffic over a wireless IP access network is, basically, how to identify and prioritize the IP packets of real-time IP sessions at the IP and radio link layers. In a traditional best-efforts IP packet routing model, all IP packets receive the same treatment despite the type of data the packets are carrying. Thus, the quality of service depends directly on the amount of traffic going through the network. Therefore, when network congestion occurs the quality of service is inevitably poor. To improve the quality of service and to minimize the delay experienced by the IP packets carrying real-time data, some mechanisms for IP packet prioritization are needed.
Since IP is a connectionless network technology, no natural relation between the application level IP sessions and the IP layer routing exists. Thus, there in no standard way to separate IP packets belonging to different IP sessions. Therefore, a mechanism is needed to map the application level IP session management information to QoS capable IP and radio layers.
FIG. 6
illustrates a conventional method of mapping IP QoS control information onto wireless IP transport layers. As shown in
FIG. 6
, IP applications
200
cause IP communications to be conducted over the IP network between hosts. Particularly, IP communication of IP packets from the IP applications
200
are conducted through IP layer
1003
. Further, wireless IP communications of IP packets from the IP applications
200
are conducted through the IP layer
1003
and radio link layer
2001
. If the IP communications is control IP packets then such IP communications are conducted through IP session management protocol
1001
, wherein control QoS information is transferred between the IP session management protocols
1001
of each of the hosts. In the conventional method of mapping IP QoS information onto wireless IP transport layers there is no standard way to identify IP packets belonging to different types of IP flows. Thus, it is difficult to obtain or set QoS information with respect to different types of IP sessions particularly, wireless IP sessions.
The identification of different types of IP flows, particularly real-time IP flows, is important in wireless IP networks, where limited resources and terminal mobility require effective management of the radio resources. Moreover, there can be several IP session management protocols (H.323, SIP, etc.), which need to be supported in wireless IP networks. It is very difficult to provide a system which offers a QoS interface capable of accommodating all possible IP session management protocols. Various alternative mechanisms have been proposed for identifying different types of IP flows and accommodating different IP session management protocols. However, these alternative mechanisms suffer from various disadvantages.
A first alternative mechanism has been proposed for detecting IP flows by monitoring the IP packet traffic and by applying certain rules to decide that IP packets containing certain header information create an IP flow. The detected IP flows can be given priority over best-effort IP traffic. The problem in this alternative is how to decide on the appropriate QoS for the detected IP flow since no application level signaling information can be used for the decision.
A second alternative mechanism has been proposed for use in third generation (3G) cellular networks where the terminals use Generic Packet Radio System (GPRS) signaling to create PDP contexts to carry IP data. This alternative can be unnecessarily complex for simpler network architectures, such as wireless Local Area Networks (LANs). It is also unclear how well the GPRS protocols are suited for real-time QoS provisioning, since GPRS was originally designed for traditional best-effort IP traffic.
A third alternative mechanism relies on Resource Reservation Protocol (RSVP) signaling that is used for reserving required resources from the IP network. In order to implement this alternative, mapping between the IP session management protocol and the RSVP protocols must be available. This alternative lacks mobility support and probably would require that some modifications be made to the RSVP protocol if applied in wireless IP networks.
A fourth alternative mechanism is disclos
Ala-Laurila Juha
Immonen Jukka
Seppälä Jukka
Nokia IP Inc.
Vanderpuye Kenneth
LandOfFree
Method, apparatus and computer program for IP traffic... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method, apparatus and computer program for IP traffic..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method, apparatus and computer program for IP traffic... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3269658