Changing XID/PDCP parameters during connection

Details Changing XID/PDCP parameters during connection Changing XID/PDCP parameters during connection

1999-12-22

2003-07-08

Le, Thanh Cong (Department: 2733)

Multiplex communications

Communication techniques for information carried in plural...

Adaptive

C370S468000

Reexamination Certificate

active

06590905

ABSTRACT:

FIELD OF THE INVENTION
The invention is related to packet traffic in both the General Packet Radio Service (GPRS) and the proposed Universal Mobile Telecommunications System (UMTS) for mobile telecommunication and, more particularly, to changing parameters during a connection.
BACKGROUND OF THE INVENTION
The proposed Universal Mobile Telecommunications System (UMTS) of
FIG. 1A
has a packet data protocol stack in the user plane, as shown in
FIG. 1B
that has some differences as compared to the prior General Packet Radio Service (GPRS) of
FIGS. 2A and 2B
, partly due to a new radio interface technology and partly due to much higher quality of service (QoS) requirements. In both systems, there is a need to negotiate certain parameters during setup, including compression algorithms. In GPRS the negotiated parameters are called exchange identification (XID), while in UMTS the negotiated parameters are called Packet Data Control Protocol (PDCP) parameters, which are more or less the same kind of parameters.
In the General Packet Radio Service (GPRS) of
FIG. 2A
, XID parameters are used in the Logical Link Control (LLC) and Subnetwork Dependent Convergence Protocol (SNDCP) layers of FIG.
2
B. These protocols are located in the mobile station (MS) and in the Serving GPRS Support Node (SGSN), as shown in FIG.
2
B. An example situation where there might be a need for renegotiation in GPRS is handover. New network elements don't necessarily have the same features as the old one(s), so there might be a need to renegotiate XID parameters.
In the UMTS of
FIGS. 1A and 1B
, the Packet Data Convergence Protocol (PDCP) (the old name shown in
FIG. 1B
is L
3
CE) corresponds to the SNDCP protocol of
FIG. 2B
(there is no protocol in UMTS that is similar to LLC). PDCP is located in the MS and the Radio Network Controller (RNC) of the Radio Access Network (RAN) of
FIGS. 1A and 1B
.
Typical XID/PDCP parameters are header compression methods, protocol version, etc. The negotiation is normally a two-way negotiation. First the initiator (in GPRS the initiator can be either the MS or network side element) requests XID/PDCP parameters which are suitable for it. Parameters are transferred to the peer entity, which selects suitable (parameters that it can support) XID/PDCP parameters and negotiates values within certain rules. Those negotiated XID/PDCP parameters are returned back to the initiator.
The main problem is that both ends have to know exactly when the new values have taken effect, i.e., when to start using the new XID/PDCP parameters. Some parameters don't cause a problem but, e.g., in compression algorithms, the receiver must know exactly when a new compression algorithm is used.
In UMTS as compared to GPRS, there are major differences related to handovers and protocol architecture. These changes reflect on PDCP negotiation. The main requirement still exists in UMTS, i.e., both ends have to know exactly when new PDCP parameters are to take effect for use. Architectural changes are the removing of the LLC layer and the new location of PDCP (corresponding to SNDCP layer), which is RNC.
There is a situation in UMTS called Serving Radio Network Subsystem (SRNS) relocation, i.e., inter Radio Network Controller (RNC) handover. Such would be, for instance, a change from one of the RNCs shown in
FIG. 1A
to the other. Execution of that handover is not allowed to disturb or suspend the user data transmission. The factors which ensure the reliability of transmission with high confidence have to be maximized. There should be means to renegotiate the PDCP parameters for such a relocation.
It would also be advantageous for such means to be able to be used any time, not necessarily during a handover or relocation, for both GPRS and UMTS applications, without requiring any reset type procedure.
SUMMARY OF INVENTION
The first solution according to the present invention is similar to GPRS.
In GPRS, this is handled by resetting the whole connection. So XID negotiation is made firstly and then connections are reset (LLC layer connections are re-established). After reset, the new XID parameters are taken up for use. Typically in GPRS, renegotiation is made during handover (inter SGSN handover). So XID negotiation is made during handover procedures, and after handover (LLC layer) connections are reset. When the handover procedure is finished, data transfer starts with renegotiated XID parameters. Data transmission is suspended the whole time of the handover procedure.
In UMTS, there is no LLC layer, but the Radio Link Control (RLC) layer can be used instead. By resetting RLC connections the same function can be achieved. So, according to a first aspect of the invention, PDCP negotiation is made, and then connections are reset to put into effect the new PDCP parameters for use. (Note: The RLC layer already has Reset-PDUs (Packet Data Units), which can be used to reset RLC links.) If during the SRNS relocation procedure the RLC links are reset, the reset can be used also for PDCP negotiation purposes.
There are dynamically created protocol entities in UMTS at the RLC and PDCP layers which have responsibility for functions of the layer. The location of these layers are in the RNC and in the User Equipment (UE), such as an MS. Those layer entities get initial values by help of which their actual functionality can be started. In cases where the SRNC is changed and a new SRNC is started up, i.e., the RLC and PDCP layers are relocated due to handover, it is therefore feasible to reset these protocol entities of the layers. This is done instead of copying the detailed entity information, i.e., state machines to the new SRNC. The reason for this is reduction of the complexity and to incrementally increase reliability. Thus the only information which is copied and has to be transferred between source and target SRNCs are the data packet buffers of the source SRNC. This speeds up the handover process which is an important feature especially for RT applications.
In conclusion, the reset procedure is used in GPRS and also in UMTS during handover, according to the first solution of the invention. However, if negotiation is needed to be made during a normal connection (not handover), the reset procedure is not very feasible. E.g., some packets have to be retransmitted and the reset causes some delay.
So, if the RLC links are not to be reset, the following second solution can be used during normal data transmission. The second solution for the problem, according to the invention, is to add a change indicator such as a bit (C-bit) or equivalent to the PDCP-PDU's header part. The sender informs on this bit that new parameter values are to take effect for use.
It should be noted that the change indicator may be used in other applications where there is need to change parameters during connection with the following underlying requirements (not necessarily only for PDCP/XID negotiation):
both ends must know exactly when the new values of the parameters are to take effect for use; and
new values cannot be directly derived from the packet.
The following describes in detail only one potential application of this invention. It should be realized however that the disclosed change indicator solution is applicable to indicate any kind of change in parameters. PDCP/XID negotiation is only an example for change indicator usage.
These and other objects, features and advantages of the present invention will become more apparent in light of the following detailed description of a best mode embodiment thereof, as illustrated in the accompanying drawing.


REFERENCES:
patent: 5339316 (1994-08-01), Diepstarten
patent: 5551068 (1996-08-01), Goldsmith et al.
patent: 5748915 (1998-05-01), Iijima
patent: 5805705 (1998-09-01), Gray et al.
patent: 5818871 (1998-10-01), Blakeney et al.
patent: 6118775 (2000-09-01), Kari et al.
patent: 6125122 (2000-09-01), Favichia et al.
patent: 0 827 312 (1997-07-01), None
patent: 0827312 (1998-03-01), None
3G TS 23.121 v3.2.0 (Jan. 2000), 3GPP; Technical Specification Group Services and System

Affiliated with

Also associated with

Rating

Changing XID/PDCP parameters during connection does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Changing XID/PDCP parameters during connection, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Changing XID/PDCP parameters during connection will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3073783