Telecommunications – Radiotelephone system – Zoned or cellular telephone system
Reexamination Certificate
2000-05-05
2003-11-25
Trost, William (Department: 2746)
Telecommunications
Radiotelephone system
Zoned or cellular telephone system
C455S451000, C455S452200, C455S062000, C455S422100, C370S347000, C370S348000, C370S443000, C370S461000, C370S462000, C709S214000, C709S226000
Reexamination Certificate
active
06654610
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to telecommunication systems, and more particularly to packet data protocols for use in such systems.
BACKGROUND OF THE INVENTION
In third generation telecommunication systems, such as the Universal Mobile Telecommunication System (UMTS), broad bandwidth is provided for services such as data and multimedia in addition to voice. It is desirable in such systems to provide users with an ability to establish a required Quality of Service (QoS). However, QoS cannot be guaranteed in certain types of networks, such as Internet Protocol (IP) networks or more generally the Internet, unless resources are reserved.
An end-to-end protocol known as Resource Reservation Protocol (RSVP) is currently used to allow these and other types of networks to reserve the resources required to provide a desired QoS. RSVP is described in Internet Engineering Task Force (IETF) RFC
2205
, Resource Reservation Protocol (RSVP), R. Braden et al., September 1997, which is incorporated by reference herein.
FIG. 1
illustrates the operation of RSVP. A transmitting user
10
sends to a receiving user
12
a PATH message. The PATH message carries traffic characteristics information such as information commonly known as “TSpecs” to indicate characteristics of the traffic that is to be sent from the transmitting user
10
. When the receiving user
12
receives the PATH message, it sends a RESV message that contains a QoS request such as that commonly known as “FlowSpecs.” In practice, the transmitting and receiving users
10
and
12
can be located remotely so that the PATH and RESV messages pass through several nodes of a network. As each node receives both messages, it makes the decision as to whether adequate resources in that node can be reserved. If this is possible, then the messages are relayed to the next hop for the PATH message and the previous hop for the RESV message. When the RESV message reaches the transmitting user
10
, it begins to transmit data. Periodic refresh messages are sent subsequently to maintain the QoS status at each node that has been set up.
European Patent Application No. 00301782.9, filed Mar. 3, 2000 in the name of inventor X. Chen and entitled “Resource Reservation in 3G or Future Generation Telecommunication Network,” subsequently published on May 9, 2001 as European Patent Application EP 1 130 931 A1, describes methods for reserving resources in third or future generations of wireless mobile networks such as UMTS. Advantageously, the methods described therein have no or minimal impact on existing architecture or QoS procedures, and minimize any extra signaling traffic associated with supporting RSVP in UMTS.
As indicated in
FIG. 1
, conventional RSVP is a unidirectional QoS signaling protocol that delivers a QoS request from a traffic receiver to a traffic transmitter. The negotiated QoS set up via RSVP applies only to the traffic flowing in the direction from the traffic transmitter to the receiver. For the negotiation of the QoS requirement of the traffic in the opposite direction, a separate RSVP session must be initiated.
A problem which arises in the implementation of RSVP in UMTS and other types of systems is that such systems generally make clear distinctions between QoS for traffic flowing in an uplink direction from a Mobile Terminal (MT) to the network and traffic flowing in a downlink direction from the network to the MT. For example, such a distinction is made in the QoS Information Element (IE) of the Packet Data Protocol (PDP) Context of the UMTS standard.
Direct extension of the existing one-way PDP Context to cover both uplink and downlink traffic can lead to a “racing” problem. More particularly, users may send RSVP messages for QoS control in the uplink direction independently from corresponding RSVP messages for QoS control sent in the downlink direction. Therefore, when a given MT and a corresponding Gateway GPRS (General Packet Radio Service) Support Node (GGSN) receive RSVP messages, different PDP context control procedures need to be initiated for the RSVP session associated with each direction. This may result in a successfully established PDP context in one direction but a failed PDP context in the opposite direction for a session that desires reserved resources in both directions.
It is therefore apparent that a need exists in UMTS or another type of telecommunication system for a two-way PDP context procedure that applies to both uplink and downlink traffic and which solves the above-described racing problem.
SUMMARY OF THE INVENTION
The present invention provides two-way packet data protocol (PDP) techniques for use in UMTS and other telecommunication systems.
In accordance with the invention, a determination is made as to whether a user requires resource reservations in both an uplink direction and a downlink direction within the system. If the user requires the two-way resource reservations, a two-way protocol is implemented to establish the required resource reservations. The two-way protocol integrates resource negotiation procedures for both the uplink direction and the downlink direction so as to ensure that the required resource reservations are provided for both directions. The two-way protocol may be a Packet Data Protocol (PDP) based on a Resource Reservation Protocol (RSVP) resource negotiation procedure.
The above-noted determination as two whether the user requires two-way resource reservations may be based on one or more flag bits which identify whether the user requires resource reservations for both the uplink and downlink directions. The flag bits may be associated with a Quality of Service (QoS) Information Element (IE) of the system, and may be used to permit the user to select between application of the two-way protocol and application of a one-way protocol. For example, a pair of flag bits may be used, with the values of the bits indicating whether the user needs no resource reservations in either the uplink direction or the downlink direction, resource reservations in only the uplink direction, resource reservations in only the downlink direction, or resource reservations in both the uplink and downlink directions. As another example, a single flag bit may be used to indicate for a given direction of resource reservation requirement whether or not the resource reservation requirement is coupled with a corresponding resource reservation requirement in the opposite direction.
Advantageously, the two-way protocol techniques of the present invention efficiently handle resource reservations for both uplink and downlink traffic, and overcome the racing problem inherent in the implementation of QoS in the current one-way PDP context of UMTS.
REFERENCES:
patent: 5590133 (1996-12-01), Billstrom
patent: 5995503 (1999-11-01), Crawley et al.
patent: 6031827 (2000-02-01), Rikkinen
patent: 6134231 (2000-10-01), Wright
patent: 6240083 (2001-05-01), Wright et al.
patent: 6377803 (2002-04-01), Ruohonent
patent: 6453349 (2002-09-01), Kano et al.
patent: 6496479 (2002-12-01), Shionozaki
patent: 2001/0054103 (2001-12-01), Chen
patent: 1 130 931 (2001-09-01), None
patent: WO 00/10357 (2000-02-01), None
R. Braden, Editor, “Resource Reservation Protocol (RSVP),” Version 1 Functional Specification, RFC 2205, http://www.ietf.org/rfc/rfc2205, Sections 1 and 2, 28 pages, Sep. 1997.
A. Eriksson, “Real-Time Services Over the Internet,” XVI World Telecom Congress Proceedings, pp. 173-179, 1997.
Chen Xiaobao X.
Chuah Mooi Choo
Le Danh
Lucent Technologies - Inc.
Trost William
LandOfFree
Two-way packet data protocol methods and apparatus for a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Two-way packet data protocol methods and apparatus for a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Two-way packet data protocol methods and apparatus for a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3165639