Relocating context information in header compression

Abstract

A method of relocating the header compression context in a packet network which transmits packets having compressed headers. A connection is established between a mobile terminal and a first network entity and context information used with compression and decompression of the headers of the packets is stored at the mobile terminal and the first network entity. The context information updating is stopped in the mobile terminal and in the first network entity and after that, a snapshot of the compression and decompression context information is taken and stored in the first network entity. The connection between the first network entity and the mobile terminal is changed to a connection between the mobile terminal and a second network entity. The context information snapshot stored by the first network entity is transferred to the second network entity to be stored therein as the context information of the second network entity. The stored context information at the mobile terminal and the second network entity is then used for compression and decompression of the headers of the packets.

Description

compressor decompressor of the old network entity not to send any acknowledgements during the relocation procedure. Because all acknowledgements are either discarded or not sent by the old network entity, the context of the mobile terminal compressor is not updated but the mobile terminal will continue to compress and transmit the uplink data with the previous context information. After this, a snapshot of the compression and decompression context information is taken in the old network entity and transmitted to the new network entity to be stored therein. The mobile compressor compresses at least one header of at least one packet with the said context information and transmits the compressed at least one header of at least one packet to the new network entity. Then the new network entity decompresses the received at least one packet of the at least one header with the stored decompression context information. This embodiment enables the header compression context relocation to be performed also in conditions, where it might be impossible to inform the mobile terminal about the handover in advance. If ROHC header compression mechanism is used herewith, the process of discarding the acknowledgements will preferably take place in the protocol layer below the ROHC implementation, since ROHC definitions does not include any implementation interface for enabling the required configuration. If the compressor decompressor of the old network entity is alternatively configured not to send any acknowledgements during the relocation procedure, this can also be implemented easily by adding a predefined interface between the compressor and the lower layers.

The signalling mechanism of mobile networks is typically defined so that it does not support context relocation very efficiently, since the structure of packet radio networks is mainly designed for non-real-time data transfer. Therefore, according to the known solutions, the transmitting of the context information snapshot from the old network entity to the new network entity would take place in the same message, which would also contain the command for shifting the actual control of the connections to the new network entity. The message can be called Relocation_commit message, which is typically the last message transmitted from the old network entity to the new network entity during the relocation process. Because the new network entity receives the context information snapshot from the old network entity simultaneously with the command to take over the control of the connections, this will result in break in data compression/decompression, since there is always a non-zero preparation time for the new network entity to store said received context information and to configure its compressor and decompressor according to the received context information. Also transferring the context information from the old network entity to the new network entity takes some time.

Said break can be minimised and the above-mentioned embodiments further enhanced according to a preferred embodiment of the invention, wherein a further message containing the context information snapshot is transmitted from the old network entity to the new network entity after the relocation process has started but before the command to take over the control of the connections. This enables the new network entity to store said received context information and to configure its compressor and decompressor before the actual control is handed over by the Relocation_commit message. This way the context relocation can be performed efficiently, so that no break occurs in data compression/decompression but it can be continued seamlessly when the control is given by the Relocation_commit message.

In the third embodiment of the invention described above, where all acknowledgements are discarded by the old network entity, there may occur a situation during the relocation process wherein the mobile terminal should update its context information, e.g. due to disturbance on the radio interface, and it sends context update request to the old network entity, but the update is not possible because acknowledgements are not allowed to trigger any events on the network side. This results in the fact that the context information of the mobile terminal is out-of-synchronism in respect to the snapshot context information currently being updated to the new network entity. Again a break will take place in the data compression/decompression, when the context information of the mobile terminal and the new network entity are synchronised.

The synchronisation can be speeded up by a preferred embodiment of the invention, wherein the context update request sent by the mobile terminal is detected by the old network entity, which attaches this indication to any message (e.g. Relocation_commit message) to be sent to the new network entity after the snapshot of the context information has been taken. This way the new network entity receives information about the needed context update and after the relocation is accomplished, the new network entity can send the first packet to the mobile terminal as a context update message. The mobile terminal updates its context information according to the context information received said packet containing the context update message. Then mobile decompressor decompresses the received at least one packet of the at least one header with the stored decompression context information and updates it context information according to the received context update message. This will speed up the context re-synchronisation if the compression synchronisation has been lost during relocation procedure.

Similarly, the old network entity may as well end up in a situation during the relocation process wherein it should update its context information, but the update is not possible because it cannot send any acknowledgements to the mobile terminal. Also in this situation the above-mentioned embodiment of the invention can be utilised, wherein the context update indication is attached to any message (e.g. Relocation_commit message) to be sent to the new network entity after the snapshot of the context information has been taken. Again, the new network entity receives information about the needed context update, which will be further indicated to the mobile terminal, when the relocation process has been accomplished. Alternatively, said context update indication attached to the message (e.g. Relocation_commit message) and sent by the old network entity to the new network entity can used as a trigger in decompressor of the new network entity to initiate immediately a context refresh update.

The method and its embodiments described above can preferably be applied for instance to third-generation mobile systems called UMTS (Universal Mobile Telecommunication System) and IMT-2000 (International Mobile Telephone System), and in the further development projects of the second-generation mobile systems, such as GERAN (GSM Edge Radio Access Network).

In the following, the invention will be illustrated by means of an example in connection with a packet radio service of the UMTS system, particularly in connection with internal handover between radio network subsystems of the UMTS (SRNS Relocation), during which also the header compression context information must be relocated from the old radio network controller RNC to the new radio network controller. However, the invention is not limited to the UMTS system, but may be applied to any packet-switched data transmission method in which the header compression context information relocation must be performed.

The structure of the UMTS mobile communication system will be described with reference to FIG. 3. FIG. 3 includes only the blocks relevant to describing the invention but it is obvious to a person skilled in the art that a conventional mobile communication system also comprises other functions and structures that need not be explained more closely in this context. The main elements of a mobile communication system are a core network CN and a UMTS terrestrial radio access network UTRAN, which form the fixed network of the mobile communication system, and a mobile terminal or user equipment UE. The interface between the CN and the UTRAN is called lu and the interface between the UTRAN and the UE is known as Uu.

The UTRAN typically consists of several radio network subsystems RNS between which there is an interface called lur (not shown). The RNS consists of radio network controllers RNC and one or more base stations BS, which are also called node Bs. The interface between the RNC and the BS is called lub. The base station BS is typically responsible for implementation of the radio path, and the radio network controller RNC at least for the following matters: radio resource management, controlling of handover between cells, power control, timing and synchronization, paging of subscriber terminals.

The core network CN consists of infrastructure belonging to a mobile communication system outside the UTRAN. In the core network, a mobile switching centre/visitor location register 3G-MSC/VLR communicates with a home location register HLR and preferably also with a service control point SCP of the intelligent network. The home location register HLR and the visitor location register VLR contain information on mobile subscribers: the home location register HLR contains information on all subscribers of the mobile communication network and on the services ordered by them, and the visitor location register VLR contains information on mobile stations which visit the area of a certain mobile switching centre MSC. The connection to a serving GPRS support node 3G-SGSN of the radio system is established via a Gs' interface and to a public switched telephone network PSTN/ISDN via a gateway mobile switching centre GMSC (Gateway MSC, not shown). A connection is established from the serving support node 3G-SGSN to the gateway GPRS support node GGSN via a Gn interface, and further from the GGSN to external data networks PDN. Both the mobile switching centre 3G-MSCNLR and the serving support node 3G-SGSN communicate with the radio network UTRAN (UMTS Terrestrial Radio Access Network) via the lu interface.

The UMTS system thus also comprises a packet radio system which is implemented to a great extent in accordance with the GPRS system connected to the GSM network, for which reason the names of the network elements contain references to the GPRS system. The packet radio system of the UMTS may comprise several serving support nodes and gateway support nodes, and typically several serving support nodes 3G-SGSN are connected to one gateway support node 3G-GGSN. Both the 3G-SGSN node and the 3G-GGSN node function as routers which support mobility of the mobile terminal and control the mobile communication system and route data packets to mobile terminals regardless of their location and the protocol used. The serving support node 3G-SGSN communicates with a mobile terminal UE via the radio network UTRAN. The function of the serving support node 3G-SGSN is to detect mobile terminals capable of packet radio connections in its area, send data packets to and receive them from these mobile terminals and to monitor the location of the mobile terminals in its service area. In addition, the serving support node 3G-SGSN communicates with the mobile switching centre 3G-MSC and the visitor location register VLR via the signalling interface Gs' and with the home location register HLR via the Gr interface. The home location register HLR also contains records which are related to the packet radio service and include the contents of subscriber-specific packet data protocols.

The gateway support node 3G-GGSN functions as a gateway between the packet radio system of the UMTS network and an external data network PDN (Packet Data Network). External data networks include a UMTS or a GPRS network of another network operator, the Internet, an X.25 network or a private local area network. The gateway support node 3G-GGSN communicates with these data networks via a Gi interface. The data packets to be transmitted between the gateway support node 3G-GGSN and the serving support node 3G-SGSN are always encapsulated according to a gateway tunnelling protocol GTP. The gateway support node 3G-GGSN also contains the PDP addresses (Packet Data Protocol) of mobile terminals and the routing data, i.e. 3G-SGSN addresses. Thus the routing data are used for linking data packets between the external data network and the serving support node 3G-SGSN. The network between the gateway support node 3G-GGSN and the serving support node 3G-SGSN is a network which utilizes the IP protocol, preferably IPv6 (Internet Protocol, version 6).

In the UMTS, a protocol stack according to FIG. 4 is used in the transmission of packet-switched user data (user plane). At the interface Uu between the radio network UTRAN and the mobile terminal UE, lower-level data transmission is carried out according to the WCDMA or TD-CDMA protocol in the physical layer. Data packets are transmitted between the physical layer and the RLC layer (Radio Link Control) by a MAC layer (Media Access Layer) which is above the physical layer, and the RLC layer is responsible for logical management of radio links of different radio bearers. The functionalities of the RLC include segmentation of user data to be transmitted (RLC-SDU, Service Data Unit) into one or more RLC data packets RLC-PDU. The data packets (PDCP-PDU) of the PDCP layer on top of the RLC and the header fields related to them can be compressed, if desired, by using any header compression method supported by the radio network UTRAN and the mobile terminal UE. After this, the PDCP-PDUs, which correspond to one RLC-SDU, are supplied to the RLC. The user data and the RLC-SDUs are segmented and transmitted in RLC frames to which address and control information necessary for data transmission has been added. The RLC layer is also responsible for retransmission of damaged frames. The serving support node 3G-SGSN is responsible for routing the data packets arriving from the mobile terminal UE via the radio network RAN further to the correct gateway support node 3G-GGSN. This connection uses the tunnelling protocol GTP, which encapsulates and tunnels all the user data and signalling transmitted via the core network. The GTP protocol is run above the IP used by the core network.

When the radio bearer for packet-switched user data is established (RB establishment) or reconfigured between the mobile terminal and the radio network, both peers negotiate the parameters of the radio bearer using signalling according to a radio resource control protocol RRC. The radio resource control protocol RRC is responsible e.g. for establishing, configuring, maintaining and terminating radio connections between the mobile terminal and the radio network UTRAN and for transmitting control information transmitted from the core network CN and the radio network RAN to the mobile terminals UE. One of the parameters defining the radio bearer is the header compression method used by the terminal. Compressing the headers of data packets to be transmitted and decompressing received data packet headers is in the UMTS system performed on the packet data convergence protocol PDCP layer belonging to the packet data protocol. The tasks of the PDCP layer include functions related to improving channel efficiency, which are typically based on different optimisation methods, such as the utilisation of data packet header compression algorithms. Because currently the network-level protocols designed for UMTS are IP protocols, the compression algorithms used are those standardised by IETF (Internet Engineering Task Force). Thus, the ROHC compression method is especially well-suited for the UMTS system.

The implementation of the invention in the UMTS system will be explained by referring to FIGS. 5 to 7 in regard to serving radio network subsystem (SRNS) relocation.

In the UMTS system, when a mobile terminal UE is handed over to another radio cell served by radio network controller RNC, the relocation of context information to the new radio network controller RNC must be performed as well. According to a known solution, this can be done by taking a snapshot of the compression and decompression context information used between the old radio network controller (source RNC) and the mobile terminal and delivering this snapshot to the new radio network controller (target RNC) to be used as the compression and decompression context information. The transmission of the snapshot is performed as included in the signalling messages of the SRNS relocation signalling according to the UMTS system. The compression and decompression are stopped for the time required for taking the snapshot and transferring it to the target RNC.

According to the invention, the out-of-synchronism of the contexts in the UMTS system is prevented, while simultaneously minimising the break in the compression/decompression process in time domain by stopping, in response to the decision to perform SRNS relocation, the context updating of the compressor and decompressor in both the mobile terminal and the source radio network controller (source RNC), which ensures that both the mobile terminal and the source RNC use the same context, after which a snapshot of the compression and decompression context information is taken in the source RNC and transmitted to the target radio network controller (target RNC) to be stored therein. The mobile compressor compresses at least one header of at least one packet with the said context information and transmits the compressed at least one header of at least one packet to the target RNC. Then the target RNC decompresses the received at least one packet of the at least one header with the stored decompression context information. Because the context information has not changed during the relocation process, the compressor of the mobile terminal and the decompressor of the target RNC are automatically in synchronism and the data transfer can be continued.

The implementation of the first preferred embodiment of the invention in the UMTS system will be further explained with reference to FIG. 5. On the basis of the movements of the mobile terminal UE or changes in radio conditions, for example, a decision is made in the radio resource controller RRC to perform SRNS relocation (500, 502). According to the invention, radio resource controller RRC signals to the mobile terminal UE that handover (and thus the context relocation as well) will happen shortly (504), in response to which the mobile terminal UE stops updating the context information. The signalling to the mobile terminal UE can be preferably carried out either as RRC signalling or as inband signalling on the PDCP layer. The updating of the context information can be prevented by disabling both the mobile terminal and the source RNC decompressors from sending any acknowledgements to the compressor on the opposite side. Because no acknowledgements are sent by the decompressors, the context of the compressors are not updated and both the mobile terminal and the source RNC compressors use the same context information for the compression of new packets. After this, the source RNC starts a prior known SRNS relocation procedure by sending a Relocation_required message to the old SGSN (506), which is further forwarded via the new SGSN (508) to the target RNC (510). Radio bearers are established between the new SGSN and the target RNC according to the instructions given by the RRC (512). The target RNC sends an acknowledgement to the relocation request, which acknowledgement is routed via the new SGSN (514) to the old SGSN (516) and further to the source RNC as a Relocation_command message (518). During the SRNS relocation procedure a snapshot of the compression and decompression context information is taken in the source RNC (520) and transmitted from the source RNC to the target RNC at latest in a Relocation_commit message (522) to be stored in the target RNC. The source RNC will forward the possible downlink data to be sent to the mobile terminal UE to the target RNC (524), which confirms the relocation by sending Relocation_detect message to the new SGSN (526). The target RNC also sends a RNTI_reallocation message (528) to the mobile terminal UE, which indicates the identification of the new RNC to the mobile terminal and in which the target RNC compressor preferably transmits an indication of the context update, if required. This can be done only if the source RNC is already released from the connection after the snapshot has been transmitted to the target RNC (522). Otherwise, the context update has to be performed in connection of some later signalling between the target RNC and the mobile terminal UE. The mobile terminal UE acknowledges the change of RNC by sending a confirmation as a RNTI_reallocation_complete message (530). Now the relocation of the context information to the target RNC is performed successfully, while simultaneously preventing the out-of-synchronism of the contexts and minimising the break in the compression/decompression process. Meanwhile, the new SGSN has updated the PDP context to the GGSN (532, 534). The target RNC confirms the relocation by sending a Relocation_complete message to the new SGSN (536), which is further forwarded to the old SGSN (538) and acknowledged back to the new SGSN (540). After this, the connection between the source RNC and the old SGSN is disconnected (542, 544).

The implementation of the second preferred embodiment of the invention in the UMTS system will be further explained with reference to FIG. 6. Again, a decision is made in the radio resource controller RRC to perform SRNS relocation (600, 602). According to this embodiment of the invention, radio resource controller RRC signals to the mobile terminal UE that handover (and thus the context relocation as well) will happen shortly (604), in response to which the mobile terminal UE will stop compressing and transmitting uplink data and the source RNC will stop compressing and transmitting downlink data. The signalling to the mobile terminal UE and to the source RNC can be preferably carried out either as RRC signalling or as inband signalling on the PDCP layer. This results in the context information not being updated any more. The current context information is stored in the mobile terminal UE, which is thus ready to refresh said context information from the memory and use it for the compression of new packets, when needed. After this, the source RNC starts a prior known SRNS relocation procedure, similar to what is described already above with respective reference numbers and therefore, it is not necessary to explain again herewith. A snapshot of the compression and decompression context information is taken in the source RNC, preferably during said SRNS relocation procedure and after a certain delay, and transmitted to the target RNC at latest in a Relocation_commit message (622) to be stored in the target RNC. By waiting a reasonable time of said delay a certainty can be had that all packets compressed and sent by the mobile terminal UE are received and decompressed correctly by the decompressor of the source RNC. The source RNC will forward the possible downlink data to be sent to the mobile terminal UE to the target RNC (624), which confirms the relocation by sending Relocation_detect message to the new SGSN (626). The target RNC also sends a RNTI_reallocation message (628) to the mobile terminal UE, which indicates the identification of the new RNC to the mobile terminal and in which the target RNC compressor preferably transmits an indication of the context update, if required. This can be done only if the source RNC is already released from the connection after the snapshot has been transmitted to the target RNC (622). Otherwise, the context update has to be performed in connection of some later signalling between the target RNC and the mobile terminal UE. The mobile terminal UE acknowledges the change of RNC by sending a confirmation as a RNTI_reallocation_complete message (630). Now the relocation of the context information to the target RNC is performed successfully, while simultaneously preventing the out-of-synchronism of the contexts and minimising the break in the compression/decompression process.

The implementation of the third preferred embodiment of the invention in the UMTS system will be further explained with reference to FIG. 7, in which the mobile terminal is not informed in forehand about the relocation. Again, a decision is made in the radio resource controller RRC to perform SRNS relocation (700, 702), but the mobile terminal UE is not informed about this. The mobile terminal UE will continue to run the header compression and decompression normally, but the context updating of the mobile terminal context information is prevented by discarding in the source RNC compressor/decompressor any acknowledgements from the compressor/decompressor of the mobile terminal or by configuring the compressor decompressor of the source RNC not to send any acknowledgements during the relocation procedure. The process of discarding the acknowledgements will preferably take place logically in the PDCP layer on which the ROHC compression algorithm is run, since ROHC definitions does not include any implementation interface for enabling the required configuration. The source RNC is preferably informed about the discarding via the RRC (704). Because all acknowledgements are discarded by the source RNC, the context of the mobile terminal compressor is not updated but the mobile terminal will continue to compress and transmit the uplink data with the previous context information. After this, the source RNC starts a prior known SRNS relocation procedure, similar to what is described already above with respective reference numbers and therefore, it is not necessary to explain again herewith. A snapshot of the compression and decompression context information is taken in the source RNC, preferably during said SRNS relocation procedure, and transmitted to the target RNC at latest in a Relocation_commit message (722) to be stored in the target RNC. The process of accomplishing the SRNS and context information relocation is similar to what is described above. After the relocation procedure is finished, the RNC, which previously functioned as the source RNC will continue to function normally, i.e. it does not discard any acknowledgements from the compressor/decompressor of the mobile terminal UE. This embodiment enables the header compression context relocation to be performed also in conditions, where it might be impossible to inform the mobile terminal UE about the handover in advance.

An implementation of a further preferred embodiment of the invention in the UMTS system can be described with reference to FIG. 5, for example, wherein the context information snapshot is transmitted from the source RNC to the target RNC after the relocation process has started but before the command to take over the control of the connections (522, Relocation_commit message). The context information snapshot will preferably be transmitted with a prior known message, such as in Relocation_required message (506) or Relocation_request message (510), but the context information snapshot can also be transmitted as a further separate message. This further message will preferably take place after the in Relocation_required message (506), but in any case before the Relocation_commit message (522). However, the place of the message which transmits the context information snapshot is not restricted by any other means, but it can be sent any time after the relocation process has started but before the Relocation_commit message (522). This enables the target RNC to store said received context information and to configure its compressor and decompressor before the actual control is handed over by the Relocation_commit message. This way the context relocation can be performed efficiently, so that no break occurs in data compression/decompression but it can be continued seamlessly when the control is given by the Relocation_commit message.

If all acknowledgements are discarded by the source RNC, as is described in the third embodiment of the invention, there may occur a situation during the relocation process wherein the mobile terminal UE should update its context information, e.g. due to disturbance on the radio interface, and it sends context update request to the source RNC, but the update is not possible because the acknowledgements are discarded in the network and therefore the network does not send any update information. As a result, the context information of the mobile terminal UE is out-of-synchronism in respect to the snapshot context information currently being updated to the target RNC. Again a break will take place in the data compression/decompression. when the context information of the mobile terminal and the target RNC are synchronised.

According to a preferred embodiment of the invention, the synchronisation can be speeded up in the UMTS system by detecting the context update request sent by the mobile terminal in the source RNC, which attaches this indication to any message (e.g. Relocation_commit, 522 in FIG. 5) to be sent to the target RNC after the context update request has been detected. This way the target RNC receives information about the needed context update and after the relocation is accomplished, the target RNC can send the first packet to the mobile terminal as a context update message. Then mobile decompressor decompresses the received at least one packet of the at least one header with the stored decompression context information and updates it context information according to the received context update message. This will speed up the context re-synchronisation if the compression has failed during relocation procedure.

Similarly, the source RNC may as well end up in a situation during the relocation process wherein it should update its context information, but the update is not possible because it cannot send any acknowledgements to the mobile terminal UE. Also in this situation the above-mentioned embodiment of the invention can be utilised, wherein the context update indication is attached to any message (e.g. Relocation_commit) to be sent from the source RNC to the target RNC after the context update request has been detected. Again, the target RNC receives information about the needed context update, which will be further indicated to the mobile terminal, when the relocation process has been accomplished. Alternatively, said context update indication attached to the Relocation_commit message and sent by the source RNC to the target RNC can be used as a trigger in decompressor of the target RNC to initiate immediately a context refresh update.

The procedure of the embodiment can be performed, for example, in the following way: the context update need is indicated in the message sent from the source RNC to target RNC e.g. by two bits, such that a bit combination 00 means that no update is needed, a bit combination 01 means that the context of the decompressor of the mobile terminal UE is out-of-synchronisation, a bit combination 10 means that the contexts of the decompressors on the network side are out-of-synchronisation, and a bit combination 11 means that both the context of the decompressor of the mobile terminal UE and the contexts of the decompressors on the network side are out-of-synchronisation. Once this information is received by target RNC, it can start the context update procedure by sending context update packet to the mobile terminal UE (context update indication 01), by updating the context information of the source RNC by sending a context update request to the mobile terminal UE (context update indication 10), or respectively performing both of the above-mentioned operations (context update indication 11).

It is obvious to a person skilled in the art that while technology advances, the basic idea of the invention can be implemented in many different ways. The invention and its embodiments are thus not restricted to the examples described above, but can vary within the scope of the claims.

Claims

1. A method of relocating the header compression context in a packet network which transmits packets having compressed headers, said method comprising:

establishing a connection between a mobile terminal and a first network entity including storing context information used with compression and decompression of the headers of the packets at the mobile terminal and the, first network entity;

stopping the context information updating in the mobile terminal and in the first network entity;

taking a snapshot of the compression and decompression context information in the first network entity including storing said context information snapshot in the first network entity; and

changing the connection between the first network entity and the mobile terminal to a connection between the mobile terminal and a second network entity including transferring the context information snapshot stored by the first network entity to the second network entity which is stored by the second network entity as the context information of the second network entity and using the stored context information at the mobile terminal and the second network entity for compression and decompression of the headers of the packets.

2. A method in accordance with claim 1 wherein:

said context information updating is stopped by disabling the mobile terminal and the first network entity decompressors from sending acknowledgements to the compressor of the opposite side.

3. A method in accordance with claim 1 wherein:

said context information updating is stopped by stopping the mobile terminal to compress and transmit uplink data and stopping the first network entity to compress and transmit downlink data.

4. A method in accordance with claim 3 wherein:

said taking a snapshot of the compression and decompression context information in the first network entity is delayed until said transmitted uplink data and downlink data has been received and decompressed.

5. A method in accordance with claim 1 wherein:

said context information updating is stopped by discarding in the first network entity compression/decompression acknowledgements from the mobile terminal.

6. A method in accordance with claim 1 wherein:

said context information updating is stopped by disabling in the first network entity to send compression/decompression acknowledgements to the mobile terminal.

7. A method in accordance with claim 5 wherein:

sending a context update request from the first network entity to the second network entity, in response to a detection of a context update request sent by the mobile terminal in the first network entity; and

sending the first packet from the second network entity to the mobile terminal as a packet containing said context update request.

8. A method in accordance with claim 5 wherein:

sending a context update request from the first network entity to the second network entity, in response to a detection of out-of synchronism of the context information in the first network entity; and

sending the first packet from the second network entity to the mobile terminal as a packet containing said context update request.

9. A method in accordance with claim 1 wherein:

transferring the context information snapshot stored by the first network entity to the second network entity before changing the connection between the first network entity and the mobile terminal to a connection between the mobile terminal and a second network entity.

10. A method in accordance with claim 1 wherein:

said method is used in accordance with Robust header compression (ROHC) implemented in a UMTS system.

11. A method in accordance with claim 10 wherein:

performing said relocation overlapping with serving radio network subsystem (SRNS) relocation.

12. A packet network in which packets having compressed headers are transmitted between a mobile terminal and network entities, said network comprising:

a connection is arranged to established between a mobile terminal and a first network entity;

context information used with compression and decompression of the headers of the packets is arranged to be stored at the mobile terminal and the first network entity;

the context information updating in the mobile terminal and in the first network entity is arranged to be stopped;

a snapshot of the compression and decompression context information is arranged to be taken at and stored in the first network entity;

the connection between the first network entity and the mobile terminal is arranged to be changed to a connection between the mobile terminal and a second network entity, whereby the context information snap-shot stored by the first network entity is arranged to be transmitted to and stored in the second network entity as the context information of the second network entity; and

the stored context information at the mobile terminal and the second network entity is arranged to be used for compression and decompression of the headers of the packets.

13. A packet network in accordance with claim 12 wherein:

said context information updating is arranged to be stopped by disabling the mobile terminal and the first network entity decompressors from sending acknowledgements to the compressor of the opposite side.

14. A packet network in accordance with claim 12 wherein:

said context information updating is arranged to be stopped by stopping the mobile terminal to compress and transmit uplink data and stopping the first network entity to compress and transmit downlink data.

15. A packet network in accordance with claim 14 wherein:

said taking a snapshot of the compression and decompression context information in the first network entity is arranged to be delayed until said transmitted uplink data and downlink data has been received and decompressed.

16. A packet network in accordance with claim 12 wherein:

said context information updating is arranged to be stopped by discarding in the first network entity compression/decompression acknowledgements from the mobile.

17. A packet network in accordance with claim 12 wherein:

said context information updating is arranged to be stopped by disabling in the first network entity to send compression/decompression acknowledgements to the mobile terminal.

18. A packet network in accordance with claim 16 wherein:

a context update request is arranged to be sent from the first network entity to the second network entity, in response to a detection of a context update request sent by the mobile terminal in the first network entity;

the first packet is arranged to be sent from the second network entity to the mobile terminal as a packet containing said context update request.

19. A packet network in accordance with claim 16 wherein:

a context update is arranged to be sent request from the first network entity to the second network entity, in response to a detection of out-of-synchronism of the context information in the first network entity; and

the first packet is arranged to be sent from the second network entity to the mobile terminal as a packet containing said context update request.

20. A packet network in accordance with claim 12 wherein:

the context information snapshot stored by the first network entity is arranged to be transferred to the second network entity before changing the connection between the first network entity and the mobile terminal to a connection between the mobile terminal and a second network entity.

21. A packet network in accordance with claim 12 wherein:

said packet network is a UMTS system, wherein Robust header compression (ROHC) is implemented.

22. A method comprising:

establishing a connection between a mobile terminal and a first network entity, wherein the first network entity includes a transmitter having a compressor that compresses packet headers and a receiver having a decompressor that decompresses packet headers;

storing context information used with the compressing and decompressing of the packet headers in the first network entity;

stopping acknowledgments to the mobile terminal to stop context information updating at a compressor of the mobile terminal;

stopping the context information updating in the compressor of the first network entity;

taking a snapshot of the stored context information; and

transmitting the context information snapshot to a second network entity to be used as the context information for compression and decompression of the headers of the packets in the second network entity for communication between the mobile terminal and the second network entity.

23. The method of claim 22, further comprising:

sending an indication to the mobile terminal of a handover of the communication connection from the first network entity to the second network entity.

24. The method of claim 23, comprising transmitting the snapshot of the context information to the second network entity before sending the indication of handover to the mobile terminal.

25. The method of claim 22 wherein the stopping acknowledgments to the mobile terminal occurs after taking the snapshot of the stored context information.

26. The method of claim 22, comprising transmitting the snapshot of the context information to the second network entity before handover of the communication connection from the first network entity to the second network entity.

27. A method of communication in a first network entity, the method comprising:

communicating with a mobile terminal, wherein the first network entity includes a transmitter having a compressor that compresses packet headers and a receiver having a decompressor that decompresses packet headers;

storing context information used with the compressing and decompressing of packet headers in the first network entity for communication between the first network entity and the mobile terminal;

disabling acknowledgments sent to a compressor of the mobile terminal to stop context information updating at the compressor of the mobile terminal;

stopping the context information updating in the compressor of the first network entity;

taking a snapshot of the stored context information; and

transmitting the context information snapshot to a second network entity to be used as the context information for compression and decompression of the headers of the packets in the second network entity for communication between the mobile terminal and the second network entity.

28. The method of claim 27, further comprising:

sending an indication to the mobile terminal of handover of the communication connection from the first network entity to the second network entity.

29. The method of, claim 27, wherein the snapshot of the context information is transmitted to the second network entity before handover of the communication connection from the first network entity to the second network entity.