Method for controlling handover in a mobile radiocommunications network

The present invention relates to the field of radiocommunications, and in particular the encryption techniques used in cellular networks.

The invention is particularly applicable in third-generation cellular networks of the UMTS ("Universal Mobile Telecommunication System") type using code division multiple access (CDMA) techniques.

The invention is described below in its application to a UMTS network, of which Figure 1 shows the architecture.

The switches of the mobile service 10, belonging to a core network (CN, "Core Network"), are connected on the one hand to one or more fixed networks 11 and on the other hand, by means of a so-called interface <i>read,</i> to control equipment 12, or RNC ("Radio Network Controller"). Each RNC 12 is connected to one or more base stations 13 by means of a so-called interface<i>lub</i>. The base stations 13, distributed over the coverage territory of the network, are able to communicate by radio with the mobile terminals 14, 14a, 14b called UE ("User Equipment"). Base stations can be grouped together to form nodes called "node B". Some RNCs 12 can further communicate with each other by means of a so-called interface<i>lur</i>. RNCs and base stations form an access network called UTRAN ("UMTS Terrestrial Radio Access Network").

The UTRAN includes elements of layers 1 and 2 of the ISO model to provide the required links on the radio interface (called <i>Uu)</i> and a Layer 3 radio resource control (RRC) stage 15A as described in Technical Specification 3G TS 25.301, "Radio Interface Protocol", version 3.4.0, published in March 2000 by 3GPP (3^rd Generation Partnership Project). Seen from the upper layers, UTRAN acts simply as a bridge between the EU and CN.

Figure 2 shows the RRC stages 15A, 15B and the lower layer stages which belong to the UTRAN and a UE. On each side, the layer 2 is subdivided into a radio link control stage (RLC) 16A, 16B and a Medium Access Control (MAC) stage 17A, 17B. ). The layer 1 comprises a coding and multiplexing stage 18A, 18B. A radio stage 19A, 19B ensures the transmission of the radio signals from the symbol trains supplied by the stage 18A, 18B, and the reception of the signals in the other direction.

There are different ways to adapt the protocol architecture according to Figure 2 to the hardware architecture of the UTRAN according to Figure 1, and in general different organizations can be adopted depending on the types of channels (see section 11.2 of the specification). technical 3G TS 25.401, "UTRAN Overall Description", version 3.1.0 released in January 2000 by the 3GPP). The RRC, RLC and MAC stages are in RNC 12. The layer 1 is for example in the node B. Part of this layer can, however, be in RNC 12.

When multiple RNCs are involved in a communication with a UE, there is usually a serving RNC called SRNC (Serving RNC), where Layer 2 (RLC and MAC) modules are located, and at least one RNC relay called DRNC ("Drift RNC") to which is connected a base station with which the UE is in radio link. Appropriate protocols ensure the exchanges between these RNCs on the interface<i>lur,</i> for example ATM ("Asynchronous Transfer Mode") and AAL2 ("ATM Adaptation Layer No. 2"). These same protocols can also be used on the interface lub for the exchanges between a node B and its RNC.

Layers 1 and 2 are each controlled by the RRC sublayer, the characteristics of which are described in the technical specification 3G TS 25.331, "RRC Protocol Specification", version 3.1.0 released in October 1999 by 3GPP. The RRC stage 15A, 15B supervises the radio interface. It also processes flows to be transmitted to the remote station according to a "control plan", as opposed to the "user plane" which corresponds to the processing of user data from layer 3.

The RLC sublayer is described in the technical specification 3G TS 25.322, "RLC Protocol Specification", version 3.2.0 released in March 2000 by 3GPP. In the direction of transmission, the RLC stage 16A, 16B receives, according to respective logical channels, data streams consisting of service data units (RLC-SDU) from the layer 3. An RLC module of the stage 16A, 16B is associated with each logical channel to perform in particular a segmentation of the RLC-SDU units of the stream into protocol data units (RLC-PDU) addressed to the MAC sub-layer and comprising a optional RLC head. In the sense of reception, an RLC module conversely performs a reassembly of the RLC-SDUs of the logical channel from the data units received from the MAC sublayer.

The RLC stage 16A, 16B may have several modes of operation depending in particular on the type of logical channel. In the remainder of the present description, we will consider the transparent mode of the RLC sublayer, which is suitable for a logical channel relating to a circuit mode communication. In this transparent mode, the RLC performs the segmentation and reassembly operations when necessary, and it does not introduce any header in the RLC-PDUs.

The MAC sublayer is described in the technical specification 3G TS 25.321, "MAC Protocol Specification", version 3.3.0 released in March 2000 by 3GPP. It transposes one or more logical channels on one or more TrCH transport channels ("Transport CHannel"). In the direction of transmission, the MAC stage 17A, 17B can multiplex one or more logical channels in the same transport channel. On such a transport channel, the MAC stage 17A, 17B delivers successive transport blocks TrBk ("Transport Block") each consisting of an optional MAC header and an RLC-PDU unit derived from an associated logical channel.

For each TrCH, the RRC sublayer provides the MAC sublayer with a Transport Format Set (TFS). A transport format includes a transmission time interval (TTI) equal to 10, 20, 40 or 80 ms, a transport block size, a transport block set size and parameters defining the protection scheme to be applied in the TrCH by layer 1 to detect and correct transmission errors. Based on the current rate on the logical channel (s) associated with the TrCH, the MAC stage 17A, 17B selects a transport format in the TFS assigned by the RRC sublayer, and delivers in each TTI a set of transport blocks according to the selected format, indicating this format at layer 1.

Layer 1 can multiplex several TrCHs on a given physical channel. In this case, the RRC sublayer assigns a set of Transport Format Combination Set (TFCS) to the physical channel, and the MAC sublayer dynamically selects a combination of transport formats in this TFCS set. , which defines the transport formats to be used in the various multiplexed TrCHs.

UMTS uses the CDMA technique of spread spectrum, that is to say that the transmitted symbols are multiplied by spreading codes consisting of samples called "chips" whose rate (3.84 Mchip / s in the case of UMTS) is greater than that of transmitted symbols. The spreading codes distinguish different PhCH physical channels which are superimposed on the same transmission resource constituted by a carrier frequency. The auto- and cross-correlation properties of the spreading codes allow the receiver to separate the PhCHs and extract the symbols intended for it. For UMTS in FDD mode ("Frequency Division Duplex") on the downlink, a scrambling code is allocated to each base station, and different physical channels used by this base station are distinguished by mutually orthogonal channelization codes. The base station may also use several mutually orthogonal scrambling codes. On the uplink, the base station uses the scrambling code to separate the transmitting UEs, and possibly the channel code to separate the physical channels from the same UE. For each PhCH, the overall spreading code is the product of the channel code and the scrambling code. The spreading factor (equal to the ratio between the chip rate and the symbol rate) is a power of 2 between 4 and 512. This factor is chosen according to the symbol rate to be transmitted on the PhCH.

The different physical channels are organized in frames of 10 ms which succeed each other on the carrier frequency used by the base station. Each frame is subdivided into 15 timeslots of 666 μs. Each slice may carry the superimposed contributions of one or more physical channels, including common channels and dedicated DPCH ("Dedicated Physical CHannel") channels. Each DPCH conveys with the data an indication of a Transport Format Combination Indicator (TFCI) transport format combination resulting from the MAC sublayer, enabling the destination MAC module to retrieve the TrBk structure.

It is possible, for the same communication, to establish several DPCH corresponding to different channel codes, the spreading factors may be equal or different. This situation is particularly encountered when a DPCH is not sufficient to provide the transmission rate required by the application. Moreover, this same communication can use one or more transport channels. The coding and multiplexing of information symbol streams from TrCHs on PhCHs are described in detail in Technical Specification 3G TS 25.212, "Multiplexing and channel coding (FDD)", version 3.0.0 published in October 1999 by the 3GPP.

With regard to each logical channel for which the processing module of the RLC sublayer operates in transparent mode, the MAC stage 17A, 17B furthermore ensures encryption of the transmitted information and decryption of the received information. On the corresponding transport channel, the TrBks relating to this logical channel each consist of a RLC-PDU unit encrypted according to a mechanism described in Chapter 8 of the aforementioned 3G TS 25.301 specification.

FIG. 3 illustrates the encryption module 20 of the MAC stage 17A, 17B of the RNC or the UE, used for a logical channel. An encryption algorithm 21 is executed to generate a bitmask that is combined with the information bits of the RLC-PDU received in transparent mode of the RLC, by an exclusive OR operation (gate 22). An identical module can be used for decryption. The algorithm 21 calculates the mask based on the following parameters:<ul id="ul0001" list-style="dash" compact="compact"><li>CK: secret encryption key of M = 32 bits, defined in a previous authentication phase between the core network and the UE;</li><li>CSN: Ciphering Sequence Number (Ciphering Sequence Number) consisting of M = 32 bits;</li><li>BEARER: logical channel identifier, used to generate different masks for the different logical channels;</li><li>DIRECTION: bit indicating the direction of transmission (rising or falling), used to generate different masks in both directions;</li><li>LENGTH: length of the mask in number of bits, given by the RRC stage according to the transport format.</li></ul>

Algorithm 21 combines the M bit number CSN with the key CK in order to prevent the same mask from being used to encrypt different blocks. This CSN number is incremented at the rate of the 10 ms radio frames. FIG. 3 thus shows the 32-bit counter 23 which delivers the CSN parameter. This counter increments the CSN number by an amount N to each new block of the logical channel, where N is the number of frames per TTI on the transport channel carrying this logical channel (N = 1, 2, 4 or 8). The counter is incremented by 1 every 10 ms, every 2 ms, every 4 ms, or every 8 ms. Upon initialization of the encrypted communication, the RRC stage provides an initial value CSN₀ the CSN number and a start command of the counter 23 (START). These operations are performed both in the RNC where the MAC task is performed and in the UE.

A problem considered in the present invention is that of the transfer of CSN counters during a displacement of the MAC module ensuring the encryption function in the network infrastructure. Such a move takes place as part of a transfer procedure involving a change of radio access resource (handover). The transfer procedure can thus result in a change in SRNC, which requires that the CSN counter of the new SRNC be synchronized with that of the previous SRNC (and the UE), while the interfaces <i>read</i> and or <i>lur</i> RNCs can communicate with each other asynchronously. One can also consider cases where the displacement of the MAC module would take place within the same RNC, if it uses different circuits to manage the access resources used before and after the transfer.

Different possible scenarios for the transfer procedure are described in the technical specification 3G TR 25.832, "Manifestations of Handover and SRNS Relocation", version 3.0.0 published in October 1999 by 3GPP. We distinguish on the one hand handover smoothly, or SHO ("soft handover"), which uses a macrodiversity mode and which can possibly be followed by a change of SRNC called "relocation" and on the other hand the abrupt handover, or HHO ("hard handover"), which corresponds, for example, to a change of carrier frequency (with or without a change of RNC) and / or to a transfer between two RNCs (of the same access network or of different access networks) that can not communicate with each other through an interface <i>lur.</i> An HHO may take place within a UTRAN if more than one carrier frequency is allocated to the operator of that UTRAN or if interfaces <i>lur</i> are not provided between all the RNCs of this UTRAN. An HHO may also take place between two distinct access networks, for example between two UTRANs or between a UTRAN and a system of a different nature based on a similar functional architecture, making it possible in particular to use the same encryption procedures, such as a GERAN type system ("GSM / EDGE Radio Access Network").

UMTS in FDD mode supports a macrodiversity technique, which consists in providing that a UE can simultaneously communicate with separate base stations in such a way that, in the downstream direction, the UE receives the same information several times and that in the uplink direction, the radio signal emitted by the UE is picked up by the base stations to form different estimates then combined in the UTRAN.

Macrodiversity provides a reception gain that improves the performance of the system through the combination of different observations of the same information. It also allows for soft handoffs (SHO) when the UE is moving.

In macrodiversity, the routing of the transport channels for the multiple transmission from the UTRAN or the UE and the combination of these transport channels in reception are operations which are incumbent on a selection and combination module belonging to the layer 1 This module interfaces with the MAC sublayer and is located in the RNC serving the EU. If the base stations involved depend on different RNCs communicating through the interface<i>lur</i>one of these RNCs acts as SRNC and the other as DRNC.

When an SHO is completed, the radio link between the UE and the home base station is broken. It may be that no base station within which the EU is located is in dependence on the SRNC.

The UTRAN may very well continue to support communication in this way. However, this is not optimal since it is possible to dispense with the exchanges intervening on the interface<i>lur</i> and release the previous NRPC, ensuring that DRNC becomes the new NRPC for ongoing communication. This is the object of the relocation procedure ("SRNS Relocation", see section 7.2.3.2 of the aforementioned 3G TS 25.401 specification), triggered on the initiative of the previous SRNC.

This relocation procedure involves the transfer of the RLC and MAC instances (as well as the layer 1 selection and recombination module if the macrodiversity is maintained) from the previous SRNC to the previous DRNC.

A problem that this poses is the transfer of the CSN counter used by the encryption algorithm in transparent RLC mode. Indeed, this counter must remain synchronous with the one located in the MAC layer on the EU side, while the links between the RNCs (through the interface<i>read</i> and the backbone or through the interface <i>lur</i>) are in principle asynchronous.

The 32-bit CSN number may be decomposed into a Connection Frame Number (CFN) corresponding to the P least significant bits of CSN and a corresponding HyperFrame Number (HFN). the 32-P most significant bits (P = 8 according to Chapter 8 of the aforementioned 3G TS 25.301 specification).

The RNC supervising each cell served by a base station 13 maintains for this cell a system frame number SFST ("System Frame Number"), coded on Q = 12 bits, which is incremented with each new 10 ms radio frame. . This SFN number is broadcast by the base station on its common control channels.

A UE measures the time difference between the signals it receives from cells close to its current cell and its own clock. Before an SHO is triggered to a target cell, the UE provides its SRNC with the offset it has measured for that target cell, which is the offset, in a range of 2^P × 10 ms (2.56 s), between the SFN counter of the target cell, obtained on the common channel, and its own CFN counter. This offset is determined, on the basis of a synchronization pattern detection, with a time precision much finer than 10 ms, for example of the order of the symbol time. It is used to temporally block the transmission of the new base station, to which it is addressed through the interface<i>lur</i>so that in macrodiversity mode, the information received by the UE from the different stations is not too offset from each other, which would require an excessive amount of memory to operate the combination of observations.

Due to the provision of this offset, the DRNC knows a priori the P low-order bits of the counter CSN to be used for encryption and decryption. But that does not provide the most significant bits (HFN). The current 3GPP specifications state that the relocation procedure involves sending the SRNC a "Relocation_Required" message on the interface.<i>read</i>in which is inserted the HFN number so that the DRNC can synchronize its encryption sequence counter. Upon receipt of this message, the core network initiates the task that will lead to the referral of the communication to the DRNC, and transparently retransmits the HFN to the latter.

These provisions do not solve the aforementioned problem because between the time the SRNC transmits the value of HFN and that the DRNC receives it, the HFN in force on the EU side could be incremented. This occurs whenever the HFN takes more than 2.56 s to be received by the DRNC, which is difficult to avoid with certainty given the queues that may be encountered by messages in the asynchronous backbone and processing time of the "Relocation_Required" message by the switches 10. Errors can also occur if the HFN takes less time to arrive at the DRNC: if it is issued at a time when CFN is 255 for example, it is very likely that it will be received by the DRNC once the value of HFN will have increased at EU level.

The above problem is encountered, even more acutely, in HHOs that are executed without using the macrodiversity mode.

In an HHO, there is generally a dual broadcast phase during which the same downlink information is transmitted simultaneously on both access resources. This allows the UE to receive the information destined for it without interruption as soon as it passes over the second access resource. It is therefore necessary that the RNC in charge of the target cell is quickly aware of the CSN encryption sequence counter relating to the UE when an HHO is to be executed. On the other hand, the RNC of the target cell, if different from the previous SRNC, generally has no previous knowledge of the CFN counter since there is no macrodiversity. The value sent by the previous SRNC must therefore cover up to the least significant bits of CSN so that it will most likely be obsolete when received by the RNC of the target cell, given the delay in routing. in the asynchronous network. This disadvantage is difficult to eliminate in the absence of base station synchronization, which is not necessary for the operation of a UMTS network and is not exploited by the standard.

It should be noted that in the non-transparent modes of the RLC sublayer, the problem considered above does not arise. These non-transparent modes are intended for packet transmissions, for which it is generally not inconvenient to temporarily interrupt the transmission during a handover or a relocation procedure to ensure, for example by a mechanism acknowledgment that the correct counter value has been received. On the other hand, it is the RLC sublayer that performs the function of encryption / decryption in non-transparent mode, by using a sequence number of the header of each RLC-PDU to encrypt the data contained in this RLC-PDU unit. This sequence number is transmitted in clear, so that the cipher counters do not need to be synchronized at both ends.

In second generation GSM systems using Time Division Multiple Access (TDMA) techniques, encryption is performed only on the air interface. The incrementation of the encryption key is based on the synchronization with respect to the TDMA hyperframes, which is unambiguously obtained on both sides of the radio link as part of the temporal multiplex scheme. As a result, the above problem does not arise either.

WO98 / 09458 discloses a radio access system derived from GSM, wherein the encryption of communications is provided only on the air interface. This system has the constraint of requiring a synchronization of base stations at the TDMA multiframe scale. In addition, the synchronization of the encryption counters is faulted when the exchanges planned between the base stations take more time than the relatively short duration of a multiframe (120 ms).

An object of the present invention is to provide a solution to the problem of synchronization of encryption counters described above.

The invention thus proposes a method for controlling a circuit mode communication logical channel as set forth in claim 1.

This makes it possible to preserve the continuity of the incrementation of the encryption sequence number at the radio terminal. The second controller processes the adjustment data received from the first controller to align the incremental enciphering sequence number with that incremented autonomously by the radio terminal. The execution of the transfer procedure can therefore be transparent for the MAC layer of the terminal.

The offset between the encryption sequence number and the time reference available to the second controller is preferably measured by the terminal on the basis of radio signals received from a base station connected to the second controller and carrying information. relating to said time reference. This time reference advantageously corresponds to a frame counter held for a base station connected to the second controller.

In the case of a relocation procedure following an SHO, this shift may have been at least partly provided to the second controller during the establishment of a new communication path passing through a base station connected to this second controller. Thus, in one embodiment of the method, the transfer procedure comprises:<ul id="ul0002" list-style="dash" compact="compact"><li>a phase of establishing at least a first additional path between the core network and the radio terminal, passing through a base station connected to the second controller and by the second controller in addition to the first controller constituting the master controller, during which at least a portion of the adjustment data representative of said offset is transmitted from the first controller to the second controller;</li><li>a macrodiversity phase during which information belonging to the logical channel is transmitted simultaneously along at least two first communication paths including said first additional path; and</li><li>a relocation phase during which the setting data representative of the current value of the encryption sequence number is transmitted from the first controller to the second controller, after which each first path is replaced by a second path not passing through the first controller.</li></ul>

To simplify the procedure, the relocation phase will generally be performed after a phase of deletion of each first path not passing through the second controller.

When there is a macrodiversity phase, the adjustment data are advantageously transmitted from the first controller to the second controller through an interface provided between the radio network controllers, without passing through the core network. This avoids that the messages carrying the offset data have to be processed by the switches of the core network, which minimizes the transmission time adjustment data and therefore the risk that they arrive late to the second controller.

Alternatively, the adjustment data transmitted during the establishment phase of the first additional path may be transmitted through the interface provided between the radio network controllers, without passing through the core network, while the remainder of the tuning data is transmitted during the relocation phase via the core network. This is particularly appropriate when the offset is represented on a number of bits greater than what is necessary for the execution of the SHO. The risk of obsolescence of the setting data transmitted through the core network is then reduced because these data can be validated as soon as they do not reach the second controller with a delay greater than one cycle of offset values.

In another embodiment of the method, the first and second paths have radio links supported by different access resources, for example different carrier frequencies (case of HHO). The transfer procedure can then include:<ul id="ul0003" list-style="dash" compact="compact"><li>sending the adjustment data from the first controller to the second controller after the terminal is in radio range of a base station of the second path connected to the second controller;</li><li>a simultaneous transmission phase of radio signals carrying the same information encrypted by the respective base stations of the first and second paths;</li><li>switching the terminal of the radio link from the first path to the radio link of the second path; and</li><li>the deletion of the first path, the terminal transmitting and receiving the encrypted information according to the second path.</li></ul>

In this case, the adjustment data is generally transmitted from the first controller to the second controller via the core network.

Another aspect of the present invention relates to an access network of a cellular radio system as set forth in claim 18.

Other features and advantages of the present invention will become apparent in the following description of nonlimiting exemplary embodiments, with reference to the appended drawings, in which:<ul id="ul0004" list-style="dash" compact="compact"><li>Figure 1, previously commented, is a diagram of a UMTS network;</li><li>FIG. 2, previously commented on, is a diagram showing the layered organization of communication protocols used on the UMTS radio interface;</li><li>Figure 3, previously commented, is a block diagram of an encryption module used in the MAC layer of a UMTS network;</li><li>FIG. 4 is a simplified diagram of a UMTS network to which the invention can be applied;</li><li>Figures 5 to 8 are diagrams of the network of Figure 4 showing the active links at different times of a communication;</li><li>Figures 9 and 10 are flowcharts of steps of a relocation procedure respectively performed by a source RNC and a target RNC;</li><li>Fig. 11 is a schematic diagram of another UMTS network to which the invention is applicable;</li><li>Figures 12 to 14 are diagrams of the network of Figure 11 showing the active links at different times of a communication.</li></ul>

Figure 4 shows a UMTS network infrastructure supporting the macrodiversity mode between several SRNSs. The drawn infrastructure has a deliberately simplified configuration to clarify the explanation of the invention. The core network comprises a mobile service switching center (MSC) for the circuit mode, connected by interfaces<i>read</i> two radio network subsystems (RNSS) each having an RNC 40, 41. The two RNCs 40, 41 communicate with each other via an interface <i>lur,</i> and respectively control base stations 50, 51 (node ​​B) through interfaces <i>lub</i>.

Figures 5 to 8 show active communication paths between the core network and a UE 14 when it moves. In the situation of FIG. 5, a first path has been conventionally established between MSC 30 and UE 14 through RNC 40 acting as SRNC and base station 50. The SRNC 40 and the UE each have a MAC instance which, for each dedicated logical channel in circuit mode and each communication direction, performs the functions of encrypting and decrypting the information transmitted on this first path, as indicated. with reference to FIG. The static parameters (CK, BEARER, DIRECTION, LENGTH) of the module 20 and the initialization parameters of the counter 23 have been provided by the RRC stage.

In the situation of FIG. 6, another path has been established in macrodiversity between the MSC 30 and the UE 14 through the RNC 40, the RNC 41 acting as the DRNC and the base station 51. Before establishing this other path, the UE 14 measured the time shift Δ between its own CSN encryption sequence number and the SFN frame number broadcast by the base station 51 on its downstream common channels. This Δ offset is measured with a finer resolution than the 10 ms frames. Its value is reported by the UE to the SRNC 40 (RRC layer), and the SRNC 40 transmits it to the DRNC 41 on the interface <i>lur</i> in the macrodiversity setting procedure, so that the base station 51 has, with respect to the UE 14, an emission aligned with that of the base station 50 on a scale of the order of the symbol time.

In the current state of the specifications, the EU RRC layer communicates the value of Δ modulo 2 to that of its SRNC.^P × 10 ms = 2.56 s. We denote Δ_k = (CSN - SFN) mod 2^k the number represented by the k least significant bits of the integer part of the offset Δ expressed in units of 10 ms (1 ≤ k ≤ Q). Since the CSN is on M = 32 bits and the SFN on Q = 12 bits, the UE measures Δ_Q = Δ₁₂. But it only reports to the UTRAN of Δ_P = Δ₈.

In the situation of FIG. 6, the logical channel is encrypted on each of the two paths by the same encryption / decryption modules located in the MAC sub-layers of the SRNC 40 and the UE 14. A selection and combination module has was created in layer 1, on the one hand in SRNC 40 and on the other hand in EU 14.

In the situation of Figure 7, the path through the base station 50 has been removed, the radio link is no longer of good enough quality. RNC 40 still plays the role of SRNC although it no longer has any base stations in radio communication with the EU. On the other hand, the other path is maintained (there may of course still be other paths through DRNC 41 in macrodiversity, and the path that was first established through DRNC 41 may have been removed. ).

The specifications provide that in such a situation, the SRNC 40 may request a relocation leading to the situation illustrated in FIG. 8: the former DRNC 41 becomes the new SRNC to which the MSC 30 switches the communication. The request is made in a "Relocation_Required" message issued to the MSC on the interface<i>read</i> and containing a field to be transparently transmitted from the RRC layer of the source RNC 40 to that of the target RNC 41. Based on current specifications, this field contains the current HFN, that is, the MP = 24 most significant bits of the CSN encryption sequence number used by RNC 40 and UE 14. The core network processes the "Relocation_Required" message and transparently transmits the value of HFN to the RNC 41, which can complement it with the current value of the CFN deduced from the SFN counter of the target cell and the offset Δ₈ previously received: CFN = (SFN + Δ₈) mod 2⁸. The CSN number thus completed can be used by the new MAC instance created in the RNC 41 for the logical channel. But this CSN is erroneous if the HFN has been modified at EU level during the transit time of the HFN between RNC 40 and 41.

To avoid these errors, the RNCs 40, 41 can apply the relocation procedure of FIGS. 9 and 10 that can be executed in the RRC layer.

Once the relocation has been decided (step 100 of FIG. 9), the source RNC 40 notes the current value CSNE of the encryption sequence number CSN (step 101) and sends it to the target RNC 41 in a message that can furthermore be received. contain all or part of the bits of a quantity Δ_k with k ≤ Q (step 102), after which it waits for an acknowledgment of this message (step 103).

If k ≤ P, it is not necessary to include Δ_k in the message since Δ_P is already known at RNC 41.

If P &lt;k ≤ Q, we can include Δ_k or only its kP most significant bits. This can be done by adapting the measurement report sent to the SRNC by the UE on the RRC connection so that this report includes Δ_k (which is measured) and not only Δ_P.

When it receives this message (step 110 of FIG. 10), the target RNC 41 reads in step 111 the value CSNE that it contains and, if appropriate, the information on the offset Δ_k, then in step 112 it calculates two TE frame indexes_k and TR_k according to:<maths id="math0001" num=""><math display="block"><mrow><msub><mrow><mtext>YOU</mtext></mrow><mrow><mtext>k</mtext></mrow></msub><msup><mrow><mtext> = (CSNE + δ) mod 2</mtext></mrow><mrow><mtext>k</mtext></mrow></msup></mrow></math><img file="EP1158828B1_D0001.tif" /></maths><maths id="math0002" num=""><math display="block"><mrow><msub><mrow><mtext>TR</mtext></mrow><mrow><mtext>k</mtext></mrow></msub><msub><mrow><mtext> = (SFN + Δ</mtext></mrow><mrow><mtext>k</mtext></mrow></msub><msup><mrow><mtext>) mod 2</mtext></mrow><mrow><mtext>k</mtext></mrow></msup></mrow></math><img file="EP1158828B1_D0002.tif" /></maths> where SFN is the current value of the frame counter of the target cell, corresponding to the frame for which the counter 23 of the RNC 41 will be initialized to a CSN value₀. The TE index_k represents, in a cycle of 2^k frames detected with respect to the CSN count by the UE, the time from which the message is expected to the target RNC. The positive or zero integer δ denotes a minimum duration of routing of the message in units of 10 ms. If we have no prior information on this minimum duration, we take δ = 0. The index TR_k represents, in the same cycle, the current value of the k least significant bits of the CSN number at the UE. The assignment of TR_k to the k least significant bits of CSN₀ is performed in step 113, where the Mk high-order bits of CSNE are further assigned to those of CSN₀.

If the index TR_k is smaller than the TE index_k (Step 114), there has been an overflow in the k least significant bits of the CSN counter held by the UE during the routing of the message, so that the most significant bits must be updated. For this, the CSN initialization value₀ is increased by 2^k, modulo 2^M, at step 115. If TR_k ≥ TE_k in step 114, the initialization value CSN₀ obtained in step 113 is correct.

The target RNC 41 can then start the MAC instance for the current communication, and in particular the encryption module 20 and its associated counter 23 (step 116). It also creates a selection and combination module if the UE is in macrodiversity in the target SRNS. It then returns an acknowledgment to the source RNC 40 (step 117) to indicate that the relocation has been performed.

On receipt of this acknowledgment, the source RNC deletes its MAC instance relating to UE 14, and if necessary its selection / combination module (step 104). If the acknowledgment is not received within a specified period, he may repeat the procedure in Figure 9 or waive the request for relocation.

The procedure of Figures 9 and 10 correctly aligns the encryption process in the target RNC with that performed in the UE, as long as the routing delay from the source RNC message to the target RNC does not exceed (2).^k + δ) × 10 ms.

This condition is easy to fill. We can for example take k = Q = 12, which allows delays up to at least 40 s. For this, the offset communicated to the DRNC in the preparation of the macro-diversity can be expanded to Q bits. Alternatively, the missing high-order QP bits can be provided with the CSNE value. The message of FIGS. 9 and 10 can then be the "Relocation_Required" message transmitted via the core of the network, the CSNE value and possibly the QP most significant bits of Δ._Q being placed in the field transparently transmitted to the RRC layer of the target RNC.

On the other hand, it is possible to transmit the message of FIGS. 9 and 10 on the interface <i>lur</i>. This interface is also asynchronous, but it usually allows shorter routing times because the backbone does not have to process the messages. In this case, we can afford to reduce the number k, taking for example k = P = 8, which avoids modifying the reporting messages sent back by the UEs.

The procedure of FIGS. 9 and 10 is also suitable in the case of a relocation carried out as part of an HHO. This may occur in the schematic configuration of Figure 11 which is similar to that of Figure 4 except that there is no interface<i>lur</i> between the two RNCs involved 60, 61. Note that there could be such an interface <i>lur</i>, but not used for handover, for example because it is between two different carrier frequencies. In another embodiment, the RNCs 60, 61 belong to different access networks (a UTRAN and a GERAN, for example).

A typical HHO scenario is illustrated in Figures 12 to 14 in the network configuration of Figure 11. Initially (FIG. 12), a path is conventionally established between the MSC 30 of the core network and the UE 14 through the source RNC 60 and the base station 70 which depends on it. The UE performs the measurements prescribed on the common channels of neighboring cells of his own, in particular those of the base station 71 connected to the RNC 61 in the situation illustrated in FIG. 12. When the analysis of these measurements shows that an HHO is desirable towards the base station 71, the SRNC 60 sends to its MSC 30 an HHO request message ("Handover_Prepare") designating the target RNC 61.

When the handover is triggered, a second path is established starting from the downward direction (Figure 13). The same logical channel information is transmitted twice from the MSC 30 (or more MSCs), once through the RNC 60 and the base station 70 and once through the RNC 61 and the base station 71. In the upstream direction, the terminal 14 keeps the physical channel parameters of the first path until it receives a "Handover_Command" message requesting it to switch to the other base station 71. On receipt of this message, the UE 14 executes the command, which once the synchronized network completes the establishment of the second path. The first path is then deleted (Figure 14).

In the situation illustrated in Figure 13, the downlink information is encrypted on both paths between the RNC and the UE. The MAC instance of the target RNC 61 has started its counter 23 with an initial value CSN₀ provided by the procedure of Figures 9 and 10. The values ​​CSNE and Δ_k can be included by the source RNC 60 in the message "Handover_Prepare" and relayed by the core network to the target RNC 61. The EU must therefore have measured Δ_k and reported to his NRPC. We will preferably take k = Q = 12.

As soon as it switches to base station 71, the UE has its CSN number synchronized without having to modify it. It can therefore immediately receive the descending information and transmit the rising information with the correct encryption. Once the base station 61 has acquired the synchronization, the second path is completed.

In some cases, the UE may have had a macrodiversity phase between source and target RNCs on a first carrier frequency before performing a carrier change HHO to the target RNC. In such a case, the target RNC already has the offset Δ_k or Δ_P, so it is not mandatory to repeat it at the time of the HHO.

It is also possible that another EU had a macrodiversity phase between source (SRNC) and target (DRNC) RNCs. When the HHO procedure begins for the UE 14, the source RNC 60 can then determine the relevant value of the offset Δ_k without having necessarily received it from the EU 14: it deduces it from the CFN of the two UEs and from the measured offset indicated by the other UE.

It should be noted that the controllers 60 and 61 operating in the manner described above with reference to FIGS. 11 to 14 could, according to a variant of the invention, be two distinct parts of an equipment located at a given node of the network. . This equipment can be of the RNC type in the UMTS architecture, and the two distinct parts can be circuits separately managing the two paths with respect to at least the MAC layer, these circuits communicating with each other asynchronously. These circuits are for example carried by two different cards or contained in two different cabinets of the RNC.

It will be further appreciated that the procedure of FIGS. 9 and 10 may take various equivalent forms. So, rather than explicitly containing CSNE and Δ_kthe message (s) sent to the target RNC could contain any combination allowing the latter to retrieve these parameters.

For example, in a relocation subsequent to an OHSS where the target RNC already has the offset Δ_P, the message sent to the target RNC may contain the current HFN value of the HFN and a SFNE number_k represented by the k least significant bits of the current SFN of the target cell (P &lt;k ≤ Q), ie SFNE_k = (CSNE - Δ_k) mod 2^k. The target RNC can then operate as previously with Δ_k = (HFNE × 2^P - SFNE_k + Δ_P) mod 2^k and CSNE = (HFNE × 2^P + Δ_P) mod 2^M.

In another variant, which is particularly suitable for the case of the HHO, the message sent to the target RNC contains the current value CSNE of the CSN and the number SFNE_k aforementioned (P &lt;k ≤ Q). The target RNC can operate in the same way with Δ_k = (CSNE - SFNE_k) mod 2^k.

On the other hand, the time reference available to the second RNC 41 or 61, with respect to which the offset Δ is expressed._k or any quantity related to this shift, could be different from the SFN of the target cell, for example:<ul id="ul0005" list-style="dash" compact="compact"><li>the SFN of another base station connected to the target RNC, whose common control channel has been detected by the UE (or another UE supervised by the source RNC), which allows the measurement of the offset Δ_k relating to this other station. As the target RNC knows the differences between the SFs of the base stations it supervises, it can thus find the correct value of Δ_k ;</li><li>the SFN of any base station, in particular that of the source cell, if the RNCs are aware of the SFN gaps between the different cells, which is sometimes used in subscriber location services;</li><li>a time reference common to the RNCs, obtained for example by means of GPS-type receivers or the like capturing synchronized signals transmitted by a constellation of satellites.</li></ul>

In another embodiment of the invention, the source RNC explicitly transmits only a high-order portion of the CSN, for example the HFN, while doing so when the remaining low weight part, namely the CFN, has a known determined value of the target RNC (for example 0), which amounts to providing this value implicitly. This way of proceeding may be appropriate in the case of relocation following an OHSS because the execution time of such relocation is not critical.