Method for protecting the integrity of messages in a mobile communications system

ES 2 364 638 T3

DESCRIPTION

Procedure for the protection of the integrity of messages transmitted in a mobile radiocommunication system.

The present invention relates generally to mobile radio communication systems.

The present invention has special application in third generation mobile radiocommunication systems, in particular of the UMTS type ("Universal Mobile Telecommunication System").

In general, mobile radiocommunication systems are subject to standardization and, for more information, the corresponding standards, published by the relevant standardization bodies, can be consulted.

The general architecture of these systems, which is reflected in figure 1, essentially comprises:

- a radio access network 1, or RAN (for «Radio Access Network»),

- a core network 4, or CN (for "Core Network").

The RAN is made up of base stations such as 2 and base station controllers such as 3.

The RAN is related, on the one hand, with mobile terminals such as 5, through an interface 6 also known as radio interface and, on the other hand, with the CN 4 through an interface 7. Inside the RAN , the base stations communicate with the base station controllers through an interface 8.

In UMTS-type systems, the RAN is called UTRAN ("UMTS Terrestrial Radio Access Network"), the base stations are called "Node B", the base station controllers are called RNC ("Radio Network Controller") and the terminals mobile phones are called UE ("User Equipment"). Radio interface 6 is called "Uu interface", interface 7 is called "Iu interface", interface 8 is called "Iub interface" and between RNCs an interface 9 can be provided, called "Iur interface".

For a given Node B, the RNC that controls it is also known as CRNC (for "Controlling Radio Network Controller"). The CRNC performs a radio resource allocation and load control function for the Node Bs it controls. For a given communication relating to a given UE, there is an RNC, called SRNC (for "Serving Radio Network Controller") that performs a control function for the communication in question. In the case of macrodiversity transmission (or “soft-handover” in English), a Node B connected to the UE but not controlled by the SRNC communicates with the SRNC through the controlling RNC, also known as DRNC (for «Drift RNC»), through the «Iur» interface.

In a UMTS-type system, in particular, an integrity protection function (or "integrity protection" in English) is provided for certain information transmitted on the radio interface, in this case signaling information exchanged in the context of communication protocols. mobility management, call management, session management, etc. Such information is transmitted on the radio interface within messages, called RRC messages, defined according to the signaling protocol between SRNC and UE, or RRC protocol ("Radio Resource Control").

For a description of the RRC protocol and this integrity protection function, one can refer in particular to the specifications 3G TS 25.331 and 3G TS 33.102, published by the 3GPP ("3rd Generation Partnership Project"). The mechanisms used to protect the integrity of messages exchanged between a sender (in the present case, uplink UE, or downlink SRNC) and a receiver (in this case, uplink SRNC, or UE) are briefly reviewed. downlink):

- For each message to be transmitted, the sender calculates a code called the Message Authentication Code, or MAC-I ("Message Authentication Code"), using an integrity protection algorithm called the UIA algorithm (for "UMTS Integrity Algorithm" ) and some input parameters of this algorithm, and then the sender inserts the MAC-I code thus calculated in the message to be transmitted,

- for each message received, the receiver recalculates the MAC-I code using the same algorithm and the same input parameters as the sender, and then the receiver compares the code thus recalculated with the code received and, if the two codes correspond , the receiver considers that the received message is intact and has indeed been transmitted by that sender.

The algorithm input parameters include a secret parameter and public parameters.

The secret parameter is also known as an integrity key ("IK", for "Integrity Key"). Public parameters include in particular:

ES 2 364 638 T3

- a pseudo-random value (corresponding to a parameter named "FRESH"),

- a sequence number (corresponding to a parameter called "COUNT-I"),

- the message to be transmitted (corresponding to a parameter called "MESSAGE"),

- the radio bearer identity or RB («Radio Bearer») in which the message is transmitted (corresponding to a parameter denoted as RB Id).

The COUNT-I sequence number includes an RRC sequence number, or RRC SN ("RRC Sequence Number") and an RRC hyperframe number, or RRC HFN ("RRC Hyper Frame Number").

Generally, standard message formats are used in open interfaces such as, in particular, the Uu interface for RRC messages. Thus, starting from different information that is going to be transmitted within a message, also known as IE («Information Element»), a sequence of bits is obtained to transmit following some encoding rules according to a syntax called abstract syntax, such as in particular ASN.1 («Abstract Syntax Notation 1»), which allows defining a data structure for the information to be transmitted, and a syntax called transfer syntax, that allows to make that in reception some data received are correctly recognized in the form of a stream of bytes or bits. For more details about this encoding, for example for the transmission of RRC messages on the Uu interface, the 3G TS 25.331 specification can be consulted in particular.

As reflected in Figure 2, the sequence of bits denoted as "RRC Message" corresponding to an RRC message transmitted on the Uu interface comprises:

- a bit denoted as OP that indicates whether it is a message whose integrity is protected,

- if it is a message whose integrity is protected, a sequence of bits denoted as «Integrity Check Info» corresponding to an IE called «Integrity check info»,

- some bits denoted as «Choice», which allow the receiver to know which of the different possible RRC messages that can be transmitted is transmitted in the present case,

- a sequence of useful bits, denoted "Message", corresponding to useful IE information elements,

- possibly, some padding bits, or “padding”, denoted as “RRC Padding”, so that the total length of the transmitted sequence is a multiple of 8 bits.

It should be remembered that the «Integrity check info» contains:

- an IE called "Message Authentication Code" corresponding to the MAC-I calculated in transmission,

- an IE named “RRC message sequence number” corresponding to the RRC SN used in transmission for that message.

The RRC SN is incremented with each transmission of a protected message and the IE "RRC message sequence number" is used in particular reception to update the RRC HFN with each new RRC SN cycle.

In general, procedures are provided by which the network communicates MAC-I calculation parameters to the UE (such as, in particular, the type of algorithm and the pseudo-random value FRESH).

During a communication, the SRNC function for that communication can be transferred from an RNC called a source SRNC (or "source SRNC" in English) to an RNC called a destination SRNC (or "target SRNC" in English), for various reasons, such as as in particular: optimization of transfer times, optimization of resource allocation, optimization of the relative load of the different RNCs, etc. Such a transfer is carried out according to a procedure called "relocation" (in English). Two types of "relocation" are distinguished:

- the "relocation" in which the UE is not involved (in English "UE not involved"): corresponding typically to the case in which the SRNC destination previously had a function of DRNC,

- the “relocation” in which the UE is involved (in English “UE involved”): corresponding typically to the case where the destination SRNC did not previously have a DRNC function.

In general, in the case of "relocation" in which the UE is involved, procedures are provided, by which the network communicates to the UE, while the latter is still under the control of the originating SRNC, different parameters that must be use when under the control of the destination SRNC, such as parameters related to new radio resources to be used and, if necessary, new MAC-I calculation parameters (such as, in particular, a new FRESH pseudo-random value and eventually a new kind of algorithm).

In the current state of the standard, such procedures are reflected in relation to figure 3.

ES 2 364 638 T3

A stage denoted 10 indicates that a "relocation" procedure has started. This "relocation" procedure comprises signaling exchanges between source SRNC, destination SRNC, CN and uE, as defined in particular in the 3G TS 25.413 and 3G TS 25.331 specifications published by the 3GPP. The 3G TS 25.413 specification relates to the RANAP (Radio Access Network Application Part) signaling protocol applicable on the Iu interface. The 3G TS 25.331 specification relates, as mentioned above, to the RRC ("Radio Resource Control") signaling protocol applicable on the Uu interface.

In a step denoted as 20, the destination SRNC creates information called RRC information. The corresponding information unit created by the destination SRNC is called "RRC information, target RNC to source RNC" (or, more simply in the following, RRC information unit). An RRC information unit is intended to be transmitted in messages other than messages on the Uu interface, for example messages on the Iu interface, or RANAP messages, for example the "RELOCATION REQUeSt ACKNOWLEDGE", "RELOCATION COMMAND" messages.

These RANAP messages contain an IE corresponding to an information container called "Target RNC to source RNC transparent container", which in turn contains an IE corresponding to an information container called "RRC container", which in turn contains the unit of information "RRC information, target RNC to source RNC". Thus, RRC information created by the destination SRNC is transferred to the source SRNC, which relays it to the UE, on the Uu interface, in an RRC message. Such RRC message can be in particular one of the following messages: RADIO BEARER SETUP, RADIO BEARER RECONFIGURATION, RADIO BEARER RELEASE, TRANSPORT CHANNEL RECONFIGURATION, PHYSICAL CHANNEL RECONFIGURATION.

The RRC information unit created by the destination SRNC includes in particular an IE called "Integrity protection mode info", which in turn can include in particular some MAC-I calculation parameters (such as the type of algorithm and the pseudo-random value "FRESH").

An encoding based on ASN.1 is also used and, as a result of this encoding, as illustrated in Figure 2:

• A sequence of bits denoted as "RRC information, target RNC to source RNC", corresponding to an information unit "RRC information, target RNC to source RNC" contains:

- some bits denoted as “Choice” that allow the receiver to know which of the different possible corresponding RRC messages is used in the present case,

- a sequence of bits denoted as "Message" corresponding to some useful IEs, • a sequence of bits denoted as "RRC container" contains:

- a sequence of bits corresponding to the sequence “RRC information, target RNC to source RNC”,

- possibly, some padding bits, denoted as «Container padding», so that the number of bits in the sequence «RRC container» (defined, according to the encoding rules used, as a string of octets or «OCTET STRING ») Is a multiple of 8 bits.

A stage denoted as 30 corresponds to the sending, by the destination SRNC towards the CN, of a "RELOCATION REQUEST ACKNOwLeDGE" message. This message contains in particular an IE called "Target RNC to Source RNC Transparent Container", which in turn contains an RRC container (or "RRC container"). This RRC container in turn contains, in the present case, an RRC information unit created in step 20.

A stage denoted as 40 corresponds to the sending, by the CN towards the originating SRNC, of ​​a "RELOCATION COMMAND" message. This message contains the IE "Target RNC to Source RNC Transparent Container" received by the CN from the destination SRNC.

In steps 30 and 40, the RRC information unit created in step 20 is thus transparently transferred from the destination SRNC to the source SRNC through the core network.

In a step denoted 50, the source SRNC decodes the received RRC information unit, in particular in order to check whether new MAC-I calculation parameters are transmitted. On the basis of the MAC-I calculation parameters, the originating SRNC calculates the MAC-I destined to be inserted in that message, for the protection of its integrity, for its transmission to the UE on the Uu interface.

Indeed, in the current state of the standard, and as illustrated in Figure 2, the sequence denoted as "Message" of the encoded RRC information unit corresponds to the sequence denoted as "Message" of an encoded RRC message and Consequently, the originating SRNC must calculate the MAC-I in order to constitute the sequence "Integrity check info" of the encoded RRC message. In step 50, after having calculated the MAC-I in this way, the source SRNC constitutes the sequence of bits corresponding to the encoded RRC message that is going to

ES 2 364 638 T3 be transmitted towards the UE on the Uu interface (as reflected in figure 2).

A stage denoted as 60 corresponds to the sending, by the originating SRNC towards the UE, of the RRC message thus obtained.

As the applicant has observed, such a procedure has the following drawbacks in particular:

- the source SRNC must decode the RRC information unit to check the MAC-I calculation parameters and then calculate the MAC-I on the basis of these parameters, which has the disadvantage of increasing the quantity and the complexity of the treatments in the original CRNS,

- the source SRNC must be capable of implementing the type of algorithm chosen by the destination SRNC, furthermore, this does not allow the destination SRNC to choose a different type of algorithm than the one implemented in the source SRNC or, in other words, this has the disadvantage of being relatively restrictive or lacking in flexibility,

- the destination SRNC must use, for the transfer of RRC information in RANAP messages, a format known to the source SRNC, furthermore, this does not allow the destination SRNC to choose a format other than the one known by the source SRNC or, In other words, this still has the disadvantage of being relatively restrictive or lacking in flexibility (for example, in the case where a new protocol version has been specified, but in which one of these two SRNC uses the new version and, the other, the old version).

In other words, in the current state of the standard, several conditions must be verified between the source SRNC and the destination SRNC:

- the source SRNC must be able to decode all the messages that can be sent, through the CN, from the destination SRNC,

- the source SRNC must know all the optional extensions that the destination SRNC can include in the message,

- the source SRNC must support a message version that uses the destination SRNC,

- the source SRNC must support the integrity protection mechanism chosen by the destination SRNC.

The present invention aims in particular to avoid all or part of these drawbacks. More generally, the present invention aims to optimize the implementation of integrity protection procedures in these systems, in particular in the case of "relocation" in which the UE is involved.

One of the objects of the present invention is a method for protecting the integrity of messages transmitted between a mobile terminal and a server radio access network controller in a mobile radio communication system, a procedure in which, by means of a calculated code in transmission, a transmitted message is protected, a procedure in which, in the event of a change in the radio server access network controller, from a controller called the source controller to a controller called the destination controller, a message transmitted to the mobile terminal by the source controller is protected by means of a code calculated in the destination controller, and intended to retransmit information created in the controller to the mobile terminal destination and then transferred by the destination controller to the source controller.

According to another feature, additional information is created in the target controller and then transferred from the target controller to the source controller.

According to another characteristic, said additional information includes additional information relative to the code calculated by the target controller.

According to another characteristic, said additional information includes additional information intended to allow the message constitution operations by the source controller and the code calculation operations by the destination controller to be consistent.

According to another characteristic, said additional information includes additional information intended to allow the source controller to determine the size of a sequence of bits received from the destination controller and corresponding to said information created by the destination controller.

According to another characteristic, said additional information indicates the amount of padding necessary to transfer said sequence of bits in a container of information of given size.

According to another characteristic, said additional information includes additional information intended to allow the identity of the radio medium used by the destination controller to calculate said code to correspond to the identity of the radio medium used by the origin controller to transmit said message to the mobile terminal.

ES 2 364 638 T3

According to another characteristic, said additional information includes additional information intended to allow a sequence number contained in the message transmitted to the mobile terminal to correspond to the sequence number used by the destination controller to calculate said code.

According to another characteristic, said additional information is transferred from the destination controller to the source controller in the same information unit as said information created by the destination controller.

According to another characteristic, said additional information is transferred from the destination controller to the source controller in an information container, called the first information container, which includes said information unit.

According to another characteristic, said additional information is transferred from the destination controller to the source controller in an information container, called a second information container, which includes said first information container.

According to another characteristic, said additional information is transferred from the destination controller to the source controller in a message transmitted between the destination controller and the core network, and then in a message transmitted between the core network and the source controller, these messages including said second host container. information.

According to another characteristic, said message transmitted from the originating controller to the mobile terminal corresponds to an RRC ("Radio Resource Control") message.

According to another characteristic, said information unit corresponds to an information unit called "RRC information, target RNC to source RNC".

According to another characteristic, said first information container corresponds to an information container called "RRC container".

According to another characteristic, said second information container corresponds to an information container called "Target RNC to Source RNC Transparent Container".

According to another characteristic, said messages that include said second information container correspond to RANAP messages ("Radio Access Network Application Part").

According to another characteristic, said information is intended to communicate to the mobile terminal different parameters to be used under the control of the destination controller.

According to another characteristic, said RRC message is one of the messages: RADIO BEARER SETUP, RADIO BEARER RECONFIGURATION, RADIO BEARER RELEASE, TRANSPORT CHANNEL RECONFIGURATION, PHYSICAL CHANNEL RECONFIGURATION.

According to another characteristic, said RANAP message transmitted between the destination controller and the core network is a RELOCATION REQUEST ACKNOWLEDGE message.

According to another characteristic, said RANAP message transmitted between the network core and the originating controller is a RELOCATION COMMAND message.

According to another characteristic, said code is a message authentication code, or MAC-I ("Message Authentication Code").

According to another characteristic, in the case of a change in the radio server access network controller, from said source controller to said destination controller, information created in the source controller is transferred to the destination controller and additional information is created in the source controller. which is then transferred from the source controller to the destination controller.

According to another characteristic, said additional information created in the source controller includes additional information intended to allow the identity of the radio support used by the destination controller to calculate said code to correspond to the identity of the radio support used by the source controller. to transmit said message to the mobile terminal.

According to another characteristic, said additional information is transferred from the source controller to the destination controller in the same information unit as said information created by the source controller.

ES 2 364 638 T3

According to another characteristic, said additional information is transferred from the source controller to the destination controller in an information container, called the first information container, which includes said information unit.

According to another characteristic, said additional information is transferred from the source controller to the destination controller in an information container, called a second information container, which includes said first information container.

According to another characteristic, said additional information is transferred from the source controller to the destination controller in a message transmitted between the source controller and the core network, and then in a message transmitted between the core network and the destination controller, these messages including said second host container. information.

According to another characteristic, said information unit corresponds to an information unit called "SRNS Relocation Info".

According to another characteristic, said first information container corresponds to an information container called "RRC container".

According to another characteristic, said second information container corresponds to an information container called "Source RNC to Target RNC Transparent Container".

According to another characteristic, said messages that include said second information container correspond to RANAP messages ("Radio Access Network Application Part").

According to another characteristic, said RANAP message transmitted between originating controller and network core is a RELOCATION REQUIRED message.

According to another characteristic, said RANAP message transmitted between the network core and the destination controller is a RELOCATION REQUEST message.

The present invention also has for its object, in addition to such a method, in particular a radio access network controller and a mobile radiocommunication system, comprising means for implementing such a method.

Other objects and characteristics of the present invention will become apparent upon reading the following description of exemplary embodiments, made in relation to the accompanying drawings, in which:

Figure 1 reflects the general architecture of a mobile radiocommunication system, in particular of the UMTS type, figure 2 reflects different data structures transferred in a system of the type illustrated in figure 1, figure 3 is intended to illustrate a procedure of according to the prior art, for the protection of the integrity of the transmitted message in the case of “relocation” in which the UE is involved, Figure 4 is intended to illustrate an example of a process according to the invention, Figure 5 is intended to illustrate another example of a process according to the invention.

An example of a method according to the invention is illustrated in figure 4, which more particularly corresponds, by way of example, like figure 3 described above, to the case of "relocation" in which the UE is involved.

A stage denoted 10 'indicates that a "relocation" procedure has started.

In a step denoted as 20 ', the destination SRNC creates RRC information. The corresponding RRC information unit created by the target controller includes, in addition to the information created in step 20 of FIG. 2, additional information, as will be explained below.

Step 20 'includes a MAC-I calculation by the destination SRNC. In general, for the MACI calculation, the destination SRNC can use calculation parameters such as calculation parameters that are communicated to it by the source SRNC during the relocation procedure and / or calculation parameters chosen by the destination SRNC and which can then be included in the IE "Integrity protection mode info" of the RRC information unit created in step 20 '. In general, additional information related to the MAC-I calculated by

ES 2 364 638 T3 the destination SRNC from the destination SRNC to the source SRNC in various ways, for example within or with one of the information units such as, in this example:

- an information unit "RRC information, Target RNC to source RNC",

- an information container «RRC container»,

- an information container "Target SRNC to Source SRNC transparent container",

- a RANAP message.

It can thus be envisaged, for example within or with the RRC information as it is created by the destination SRNC, or within the RRC information container that contains this RRC information, or directly within the RANAP message sent from the source SRNC to the CN, additional information that contains the MAC-I calculated by the destination SRNC. For instance:

- an additional IE may be provided in the information unit "RRC information, Target RNC to source RNC", corresponding, in this example, to the IE "Message Authentication Code",

- an extension mark may be provided (according to the usual notations according to coding techniques such as ASN.1) in a corresponding place within the sequence "RRC information, Target RNC to source RNC" (in the case of receiver not to use this protocol version),

- an extension mark may be provided (according to the usual notations according to coding techniques such as ASN.1) in a corresponding place within the sequence "RRC container" (for the case of the receiver that does not use this version of protocol),

- an extension mark (according to the usual notations according to coding techniques such as ASN.1) may be provided in a corresponding place within the sequence "Target RNC to Source RNC transparent container" (for the case of receiver that will not use this protocol version).

For example, an extension of the IE "Target RNC to Source RNC transparent container" of the RANAP container could be defined, containing a container defined in RRC where this additional information would be added.

A stage denoted as 30 'corresponds to the sending, by the destination SRNC towards the CN, of a RANAP message such as the "RELOCATION REQUEST ACKNOWLEDGE" message. This message differs from the one sent in step 30 of figure 3 in that it includes additional information corresponding to the MAC-I calculated by the destination controller, which has been denoted in figure 4 as “Relocation Request Acknowledge (target RNC to source RNC transparent container) + MAC-I ', this additional information can be transferred to the source SRNC, for example, in one of the ways indicated above.

A stage denoted as 40 'corresponds to the sending, by the CN towards the originating SRNC, of ​​a RANAP message such as the "RELOCATION COMMAND" message. This message differs from the one sent in step 40 of figure 3 in that it includes additional information corresponding to the MAC-I calculated by the destination controller, which has been denoted in figure 4 as "Relocation Command (target RNC to source RNC transparent container) + MAC-I », this additional information can be transferred to the source SRNC, for example, in one of the ways indicated above.

A stage denoted as 50 'corresponds to the constitution, by the source SRNC, of ​​the RRC message to be transmitted to the UE on the Uu interface. In this stage, unlike stage 50 of FIG. 3, therefore, no processing corresponding to a MAC-I calculation and a decoding of the received RRC information unit is necessary, prior to such calculation, which allows , therefore, in particular to avoid the aforementioned drawbacks.

A stage denoted as 60 'corresponds to the sending, by the origin SRNC towards the UE, of an RRC message thus obtained.

According to other aspects of the invention described below, the present invention also makes it possible to provide solutions to the following problems, also recognized by the applicant.

A first problem can be exposed as follows. As stated above, the SRNC must compose the RRC message to be transmitted to the UE on the Uu interface, in particular starting from the RRC information sequence that it receives from the destination SRNC. The message thus composed must have a size corresponding to a multiple of 8 bits. The originating SRNC then has to add some padding bits ("RRC padding") to the end of the message thus composed, for the transmission of the RRC message on the Uu interface. The amount of padding to be added is a function of the size of the “RRC information, target RNC to source RNC” sequence received from the destination SRNC.

Now, as a consequence of the fact that the RRC container that contains this sequence also contains padding (or "Container padding"), as mentioned above, it is necessary a priori for the source SRNC to decode this sequence in order to know its size. If the goal is still to prevent the source SRNc from having to decode

ES 2 364 638 T3 the received RRC information sequence, then other solutions must be found. It is noted that this first problem can also be considered independently of the problem discussed above.

An example of a solution to this first problem is the following. The destination SRNC transmits additional information to the source SRNC to allow the source SRNC to determine the size of the sequence “RRC information, target RNC to source RNC”. This additional information can be, for example, information related to the size of the "RRC information, target RNC to source RNC" sequence itself, or to the amount of "Container padding" added by the destination SRNC in the RRC container, or to the size from the sequence "Target RNC to source RNC transparent container", and so on.

Another example of a solution to this first problem is the following. The destination SRNC determines the amount of “RRC padding” that would be required to transmit the RRC message on the Uu interface (the destination SRNC has in particular to determine this when calculating the MAC-I, since one of the input parameters of the algorithm integrity is the MESSAGE parameter, as mentioned above). The destination SRNC then foresees enough "Container padding" padding so that the source SRNC can use the sequence "rRc container" as is, removing only, if necessary, "Container padding" padding bits in order to obtain the desired length. for the sequence “RRC Message”, thus avoiding having to calculate the number of stuffing bits, unlike the case where stuffing bits would have to be added again.

Of course other examples would be possible.

A second problem can be exposed as follows. As mentioned above, the identity of the radio bearer or RB used to transmit an RRC message on the Uu interface is one of the MAC-I calculation parameters. The MAC-I calculated is thus different depending on the RB over which the message is transmitted.

Now, the destination SRNC may choose a different RB than the one indicated by the source SRNC in an earlier stage.

Therefore, solutions must also be found so that the MAC-I calculated by the destination SRNC can be validly used by the source SRNC.

An example of a solution to this second problem is the following. The destination SRNC calculates a MAC-I for each possible Rb through which the message can be transmitted, and transmits the different MAC-I calculated, with the corresponding RB Id, to the source SRNC.

Another example of a solution to this second problem is the following. The destination SRNC indicates to the source SRNC the RB Id for which the MAC-I has been calculated and through which the message should be sent.

The present invention also proposes that the destination SRNC uses, for the MAC-I calculation, the RB Id that is indicated to it by the source SRNC and that corresponds to the RB Id through which the source SRNC is going to transmit the RRC message. The present invention also proposes that this RB Id be indicated by the source SRNC to the destination SRNC in an RRC information unit called "SRNS Relocation Information" transferred from the source SRNC to the destination SRNC through the core network during the "relocation" procedure. ». RANAP messages such as RELOCATION REQUIRED (transmitted between source SRNC and CN) and RELOCATiOn REQUEST (transmitted between destination Cn and SRNC) contain an IE corresponding to an information container called "Source RNC to target RNC transparent container", which in turn, it contains an IE corresponding to an information container called "RRC container", which in turn contains the information unit "SRNS Relocation Info". For instance:

- an additional IE may be provided in the “SRNS Relocation Information” information unit, corresponding in this example to the IE “RB Id”,

- an extension mark (in accordance with the usual notations according to coding techniques such as ASN.1) may be provided in a corresponding place within the corresponding encoded sequence, denoted as "SRNS Relocation Information" (in the case of receiver not to use this protocol version).

Of course other examples would be possible.

A third problem can be exposed as follows. As mentioned above, the RRC SN sequence number is one of the MAC-I calculation parameters. The calculated MAC-I is thus different according to the RRC SN sequence number of the transmitted message. However, the destination SRNC may choose a different RRC SN than the one chosen by the source SRNC. Therefore, solutions must also be found so that the MAC-I calculated by the destination SRNC can be validly used by the source SRNC.

An example of a solution to this third problem is the following. The destination SRNC calculates a MAC-I for each possible RRC SN through which the message can be transmitted, and transmits the different MAC-I calculated, with the

ES 2 364 638 T3 corresponding to RRC SN, to the original SRNC.

Another example of a solution to this third problem is the following. The destination SRNC indicates to the source SRNC the RRC SN for which the MAC-I has been calculated and which should be transmitted within the RRC message through the Uu interface towards the mobile terminal.

Of course other examples would be possible.

Figure 5 is intended to illustrate another example of a method according to the invention, which differs from that illustrated in Figure 4 in that a transfer of such other additional information from the destination controller to the source controller is provided, in addition to the additional information relative to the calculated MAC-I; This other additional information includes in this example:

- additional information intended to allow the source SRNC to determine the size of the sequence "RRC information, target RNC to source RNC", in this case additional information denoted as "Amount of padding" relative to the amount of padding added by the destination controller to an RRC information stream for transfer within an RRC container,

- additional information, denoted as "RB Id", intended to allow the code calculated by the destination controller to correspond to the identity of the radio bearer used to transmit said message to the mobile terminal,

- additional information, denoted as "RRC SN", intended to allow a sequence number contained in the message transmitted to the mobile terminal to correspond to the sequence number used by the destination controller to calculate said code.

Generally, such other additional information is intended to allow the message constitution operations by the source controller and the code calculation operations by the destination controller to be consistent.

In Figure 5, the steps of the procedure have been denoted as 10, 20, 30, 40, 60.

Step 10 may be similar to step 10 '.

Stage 20 may be similar to stage 20 ', except that it may include supplementary treatments for communication to the source SRNC of supplementary additional information, denoted as "Amount of padding", "RB Id", "RRC SN" , in addition to the additional information denoted as "MAC-I".

In general, such additional supplementary information, as denoted herein as "Amount of padding", "RB Id", "RRC SN", can be transferred from the destination SRNC to the source SRNC in various ways, such as For example, in one or other of the ways indicated above for the transfer of the additional information related to the “MAC-I”. For instance:

- Additional IEs may be provided in the information unit "RRC information, Target RNC to source RNC", corresponding in this example to the IE "Message Authentication Code", "Amount of padding", "RB Id", "RRC SN" ,

- an extension mark may be provided (according to the usual notations according to coding techniques such as ASN.1) in a corresponding place within the sequence "RRC information, Target RNC to source RNC" (in the case of receiver not to use this protocol version),

- an extension mark may be provided (according to the usual notations according to coding techniques such as ASN.1) in a corresponding place within the sequence "RRC container" (for the case of the receiver that does not use this version of protocol),

- an extension mark (according to the usual notations according to coding techniques such as ASN.1) may be provided in a corresponding place within the sequence "Target RNC to Source RNC transparent container" (for the case of receiver that will not use this protocol version).

For example, an extension of the IE "Target SRNC to Source SRNC transparent container" of the RANAP container could be defined, containing a container defined in RRC where this additional information would be added.

The stage denoted as 30 corresponds to the sending, by the destination SRNC towards the CN, of a RANAP message such as the "RELOCATION REQUEST aCkNOWLEDGE" message. This message differs from the one sent in step 30 of figure 3 in that it comprises additional information corresponding to MAC-I, Amount of Padding, RB Id, RRC SN, which has been denoted in figure 5 as "Relocation Request Acknowledge ( target RNC to source RNC transparent container) + MAC-I + Amount of Padding + RB Id + RRC SN », this additional information can be transferred to the source SRNC, for example, in one of the ways indicated above.

The stage denoted as 40 corresponds to the sending, by the CN towards the originating SRNC, of ​​a RANAP message such as the "RELOCATION COMMAND" message. This message differs from the one sent in step 40 of the

ES 2 364 638 T3 figure 3 in which it includes additional information corresponding to MAC-I, Amount of Padding, RB Id, RRC SN, which has been denoted in figure 5 as «Relocation Command (target RNC to source RNC transparent container) + MAC-I + Amount of Padding + RB Id + RRC SN », this additional information can be transferred to the source SRNC, for example, in one of the ways indicated above.

Stage 50 may include, in addition to the treatments carried out in stage 50 ', some treatments that make it possible to take into account, for the constitution of the message by the source SRNC, the additional supplementary information "Amount of padding", "RB Id" , "RRC SN", as described above.

Step 60 may be similar to step 60 '.

The example in figure 5 combines the solutions to the different problems discussed above, although it would naturally be possible to consider them separately or in the form of partial combinations.

Naturally, the invention is not limited to the examples described above with reference to Figures 4 and 5. In particular:

- the invention is not limited to the case of RRC message transmitted to the UE in the “relocation” case in which the UE is involved,

- the invention is not limited to the case in which the parameters to be used by the UE (such as the MAC-I calculation parameters) change in the case of a change in the server radio access network controller,

- the invention is not limited to the above-described examples of information and / or structures for the transfer of information,

- the invention is not limited to the case of the UMTS system.

The present invention also has for its object, in addition to such a method, in particular a radio access network controller and a mobile radiocommunication system comprising means for implementing such a method.

As the specific implementation of such means does not present a particular difficulty for the person skilled in the art, such means do not need to be described in this document in more detail than has been done previously, due to their function.