|Publication number||US7664265 B2|
|Application number||US 10/362,002|
|Publication date||Feb 16, 2010|
|Filing date||Jul 31, 2001|
|Priority date||Aug 18, 2000|
|Also published as||EP1310111A2, US20040039910, WO2002015600A2, WO2002015600A3|
|Publication number||10362002, 362002, PCT/2001/8856, PCT/EP/1/008856, PCT/EP/1/08856, PCT/EP/2001/008856, PCT/EP/2001/08856, PCT/EP1/008856, PCT/EP1/08856, PCT/EP1008856, PCT/EP108856, PCT/EP2001/008856, PCT/EP2001/08856, PCT/EP2001008856, PCT/EP200108856, US 7664265 B2, US 7664265B2, US-B2-7664265, US7664265 B2, US7664265B2|
|Inventors||Jari Isokangas, Sinikka Sarkkinen|
|Original Assignee||Nokia Siemens Networks Oy|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (14), Non-Patent Citations (1), Referenced by (7), Classifications (11), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention relates to communication system and in particular, but not exclusively, to relocation of functions controlling ciphered communications between stations from a first controller to a second controller.
Communication networks typically operate in accordance with a given standard or specification which sets out what the elements of the network are permitted to do and how that should be achieved. The communication in the networks typically follows predefined rules which are referred to in the following as protocols. The protocols to be used are defined in the associated standards or specifications. The protocols can be used for transmission of necessary control information between the various network elements.
A communication network is a cellular radio network consisting of access entities referred to as cells. In most cases the cell consists of a certain radio access area covered by one or several base transceiver stations (BTS) serving mobile stations (MS) via a radio interface and connected to a base station subsystem (BSS). Several cells cover a larger area, and form the coverage area of a cellular radio network. The cell (or group of cells) and thus the mobile station (MS) (that is sometimes referred to as user equipment UE) within one of the cells of the system can be controlled by a node providing control function. An example of such controller is a radio network controller (RNC) of a universal mobile telecommunication system (UMTS) terrestrial radio access network (UTRAN). The RNC controls the communication between the base station and the mobile station based on predefined protocols, such as Radio Resource Control (RRC) or Medium Access Control (MAC) or Radio Link Control (RLC) protocols. An example of a controller node implemented in the core network (CN) side of the cellular network is a mobile switching center (MSC).
For example, in the 3rd generation UMTS a RNC can be connected further to a serving GPRS support node (SGSN) which in turn is connected to a gateway or linking node, for example a gateway GPRS support node (GGSN) or gateway mobile switching center (GMSC), linking the cell to the other parts of the communication system and/or other communication networks, such as to a PSTN (Public Switched Telecommunications Network) or to a data network, such as to a X.25 based network or to an IP (Internet Protocol) based network.
The wireless interface between the mobile station MS and the base station is typically controlled by only one access network controller at time. However, the MS may also be simultaneously controlled by several controller nodes. This may occur e.g. when the cells overlap or in so called soft handoff mode, where the MS may be in communication with two base stations which may be connected to different controllers, or when one controller is controlling another controller controlling the MS. One controller of the plurality of controllers in the system can be defined as a serving (main) controller whereas the others may act as drift i.e. secondary controllers.
The responsibility of controlling a connection between the mobile station and the network may change during an ongoing connection. It is therefore necessary to relocate at least part of the control functions associated with the connection from one controller to another such that the connection will not become disconnected an/or that the quality of the connection remains in an acceptable level. When relocation is decided to be performed, the serving controller or another node of the communication system may initiate the necessary proceeding for the relocation. The relocation of the control function can be refereed to as handover.
For example, in the current third generation partnership project (3GPP) Specifications it is defined that the core network (CN) can request the UTRAN to change the used ciphering and/or integrity protection keys for the air interface. This security procedure is initialised when the core network sends a radio access network application part (RANAP) message ‘SECURITY MODE COMMAND’ to the UTRAN. Based on this message the UTRAN, and more particularly, the access network controller thereof shall initialise the corresponding security procedure for the air interface. From the CN point of view this security procedure has been completed when the CN receives the RANAP message ‘SECURITY MODE COMPLETE’ from the UTRAN. Based on this information the CN can be sure that either the new ciphering key has been taken into use for the air interface or the mobile station has rejected the request for ciphering key change. The core network controller will also conclude from the acknowledgement message that the procedure has been terminated at the UTRAN side.
In the presently proposed arrangements the current i.e. ongoing security procedure assumes that the earlier initialised security procedure has already been terminated when the serving RNC requests the core network controller to perform a serving radio network subsystem (SRNS) relocation, i.e. handover between two access network controllers. However, the inventors have found that this may not always be the case. For example, it is possible that the security procedure is not completed if the defined activation time for the key change was originally defined to be a far a way from the current radio link controller sequence number (RLC SN) position. That is, the UTRAN keeps on operating with the “old” key until the timer functions indicates that it is time to change the key. In addition, since the reset procedures in the radio link controller (RLC) will start the transmission of frames from the beginning (from frame No. 0), sequentially occurring RLC reset procedures may have continuously postponed the elapsing of the new ciphering key activation time. The reset procedures is initiated e.g. when the connection quality is found to become poor. Thus it is possible that the mobile station has already acknowledged the ciphering key exchange by sending the RRC acknowledgement message ‘SECURITY MODE COMPLETE’ to the UTRAN (and which message the UTRAN has subsequently received) and that the new key activation time has not yet elapsed at the mobile station at the time when the serving radio network subsystem relocation procedure is initialised. This is a problem since it may lead into situation where the mobile station and the new or target radio access network controller have different ciphering keys. It is then possible that the relocation procedure fails as the mobile station and the new radio access network are not able to understand each other.
For example, the current RANAP message ‘RELOCATION REQUIRED’ contains the currently used ciphering key on the air interface inside a “IE: ciphering” key field. This field does not enable the serving RNC to indicate to the target RNC that the earlier generated security procedure was not terminated before the SRNS relocation procedure was started. The inventors have realised that the serving RNC should be able to transmit to the target RNC also that ciphering key which was already agreed with the mobile station in addition to the currently used (i.e. the “old”) ciphering key. This feature is, however, not supported in e.g. the current third generation specifications. The current security modes may not be able to handle properly a situation where the new ciphering key has not yet been taken into a use due to “late” activation time and the serving controller is forced to initialise a relocation procedure. This may happen e.g. if the RRC message ‘SECURITY MODE COMPLETE’ has been received by the SRNC before the initialisation of the SRNS relocation and before the activation timer at the mobile station has elapsed, i.e. while the mobile station and the currently serving RNC are still using the “old” key. The
Embodiments of the present invention aim to address one or several of the above problems.
According to one aspect of the present invention, there is provided a method for relocation from a first communication system controller to a second communication system controller of the control of communication between a first station and a second station, the communication being ciphered by means of a first ciphering key, the method comprising: initiating relocation of control of the communication from the first controller to the second controller; and transmitting a request for relocation to the second controller, the request containing the first ciphering key and at least one other ciphering key.
According to another aspect of the present invention there is provided an arrangement in a communication system, comprising: a first entity for adapted control of communication between a first station and a second station, the communication being ciphered by means of a first ciphering key; a second entity adapted for continuing the control of the communication after said communication has been changed to occur between a third station and the second station; an entity for initiating relocation of the control of the communication from the first entity to the second entity; and an entity for generating and transmitting a request for relocation to the second entity, the request containing the first ciphering key and at least one other ciphering key.
According to a more specific embodiment the location request contains information regarding the timing when a ciphering key should be replaced by another key.
The embodiments of the invention may decrease the risk for disconnection of a ciphered connection during handover thereof from one access network controller to another. The transmission of data and/or signalling messages after the relocation may continue normally since in accordance with some embodiments the new controller may be made aware of ciphering key activation times for the radio bearers and the new controller may therefore be made aware of the time when it should change the ciphering key for the radio interface. Some of the embodiments may avoid unnecessary initialisation of security procedures. The embodiments may prevent any additional delays to the start of the data transmission from the new controller to the mobile station. The embodiments may also be used to ensure that the old and the new ciphering keys do not contradict when data transmission is initialised after the completion of the relocation procedure. The relocation may be made faster. This in turn may save radio resources since it the faster relocation enables use of smaller power levels at the new base station. This in turn may decrease the interference caused for the other users in the new cell.
For better understanding of the present invention, reference will now be made by way of example to the accompanying drawings in which:
Reference will be first made to
Reference is now made to
The RNC 10 is arranged to control the base station 4, either directly or through an intermediate node (not shown). The controller 10 passes on data to be transmitted to the mobile station 6 by the base station. The controller 10 will also receive from the base station data which the base station has received from the mobile station. The implementation of the communication on between the base station, the mobile station and the controller is known, and will thus not be discussed in detail herein. It is sufficient to note that the interface may comprise channels in both uplink and downlink directions. The data may be sent between the mobile station and the controller in any suitable format. The messages sent from the mobile stations may include information identifying the mobile station (for instance, MS ID and/or IMSI (Mobile Station Identity and/or International Mobile Subscriber Identity, respectively)).
In addition to the serving controller (RNC 10), the cellular telecommunications system of
In order to ensure a proper operation of the system and to avoid disconnecting a possibly ongoing call, at least some of the functions of the network elements have to be relocated for the connection. For example, when a SRNC functionality is to be located from the first RNC 10 to the second RNC 11 at least some protocol termination points of an ongoing connection (such as RRC, RCL and/or MAC protocols) may need to be changed from the first RNC to the second RNC.
The wireless communication, and more particularly, radio bearers (BR) between the base stations and the mobile station is ciphered by means of a ciphering key. The use of different kinds of ciphering keys and techniques for ciphering data is known by the skilled person and will thus not be explained in more detail herein. The ciphering functions may be controlled by a control unit 20 at the serving controller 10 and by a control unit 21 at the target controller 11. The same controllers may be used for performing e.g. the RRC, RLC and MAC functions. The new RNC needs also information regarding the used ciphering key The following describes in more detail an embodiment in which the serving RNC 10 is enabled to send the new and the currently used ciphering keys to the target RNC 11. In addition, it is also described how it is possible to transmit activation times that are defined for each radio bearer (RB) to the target RNC 11.
The relocation request, such as the RANAP ‘RELOCATION REQUIRED’ message, is typically transmitted from the UTRAN to the core network CN over the lu interface when the serving RNS relocation procedure is to be initialised by the UTRAN. As explained above, the conventional relocation requests contain only the currently used ciphering key inside a predefined field, such as in the “IE: ciphering” key field. Therefore the serving RNC 10 is not capable to indicate to the target RNC 11 that the mobile station will change the key after a certain period, for example since the earlier generated security procedure was not terminated before the serving RNS relocation procedure was started. Therefore the target RNC 11 may receive the “old” key which will not be used by the mobile station 6 after the timer function 7 thereof has triggered a change from the “old” key to a “new” key.
The handover procedure may be Initiated by a ‘HO_REQUIRED’ message, which the RNC 10 sends to the MSC/SGSN 14. The message may comprise information necessary for setting up the handover, namely identification of the target RNC 11, possible identifiers for the lur interface connections between RNC 10 and RNC 11, and any necessary protocol control block information specifying the protocols and the current state of the protocols in use. Upon reception of the ‘HO_REQUIRED’ message the controller 14 starts to create new lu connections to the target RNC 11. The core network controller 14 also sends a ‘HO_REQUEST’ message to RNC 11 over the lu interface 19, which message includes the same information necessary for setting up the handover at the target controller 11.
As shown by the flowchart of
The new ciphering key field may also be used to indicate for the core network CN side that the timer setup for the security procedure shall be stopped for the duration of the serving RNS relocation procedure and that no new request for key changes, such as RANAP ‘SECURITY MODE COMMAND’ should be sent to the serving RNC 10 during that time.
The new key field may be required only in instances where the termination of the security procedure has been interrupted by the serving RNS relocation procedure. Therefore it may be preferred to implement this field as an optional field in the RANAP ‘RELOCATION REQUIRED’ message.
If the mobile station 6 has accepted the new ciphering key and the activation timing for the radio bearer (RB) upon the RRC security mode procedure, the mobile station expects the ciphering key to be changed when the activation time expires. This may cause problems on the network side, because the current source RNC 10 should inform the target RNC 11 about the new ciphering key and the agreed activation time for it. Therefore it may be required that the serving RNC and the target RNC also exchange information regarding the agreed activation times for each radio bearer (RB) in addition to the information associated with the different keys. Thus in the preferred embodiment mechanism the information between the source RNC 10 and the target RNC 11 comprises information of the new and the old ciphering keys and the agreed activation times of each radio bearers for the new ciphering key.
The activation time information was already sent to the mobile station 6 inside the RRC ‘SECURITY MODE REQUEST’ message, and therefore the mobile station assumes that the ciphering key is going to be changed based on the agreed activation times. Upon the serving RNS relocation procedure this information may be sent to the target RNC 11 inside the RRC initialisation information (for more information about this feature, see e.g. 3GTS 25.331, chapter 14.10). The RRC initialisation information contains a set of parameters on which the target RNC 11 may base the configuration of e.g. the radio resource control protocol (RRC), medium access control protocol (MAC), radio link control protocol (RLC), and/or packet data convergence protocol (PDCP) entities.
According to a possibility the timing is indicated by a data frame sequence number. That is, the information includes the number of the frame from which on (either including the indicated data frame or from the next one) the ciphering key should be changed. A possibility is to add a separate RLC sequence number field into the relocation request information. One field is preferably added for each radio bearer from the corresponding CN domain. This field may then be used to indicate to the target RNC 11 the RLC sequence number from which on the new ciphering key shall be taken into a use. In other words, to indicate the time when the given activation times for the RB(s) elapse at the mobile station.
It should be appreciated that it is possible to transmit information about more than two keys between the controllers. This may be required e.g. if several keys are used simultaneously for communication between the mobile station and the base station (e.g. for simultaneous voice and data calls) or when several subsequent relocations and/or security mode request have lead to a situation where it is possible that several different possible keys exist at the same time.
In an embodiment initialisation of the SRNS relocation procedure is forbidden until a RANAP message ‘SECURITY MODE COMPLETE’ has been sent to the core network. It is also possible that before the initialisation of the SRNS relocation procedure the serving RNC repeats the security procedure for the air interface and advances the activation time for the new ciphering key by sending the new activation time to the mobile station. After this the RNC waits until the new ciphering has been taken into a use in order to send the RANAP message ‘SECURITY MODE COMPLETE’ to the core network. According to a still further possibility a new RRC message is created for calling the previously generated security procedure off. The SRNS relocation procedure can be initialised after the mobile station has acknowledged this message.
It should be appreciated that whilst embodiments of the present invention have been described in relation to mobile stations, embodiments of the present invention are applicable to any other suitable type of user equipment.
The exemplifying cellular telecommunications network has been described by using the terminology of a proposed Universal Mobile Telecommunications System (UMTS) standard. However, it is to be appreciated that the invention is not restricted to UMTS but can be implemented in any standard. Examples of these include, without any intention to restrict the possible communication systems to these, any of the code division multiple access (CDMA) based systems or any of the time division multiple access (TDMA) based systems or any of the frequency division multiple access (FOMA) based systems or any hybrids thereof.
It should also be appreciated that base stations can sometimes be referred to as node B. In addition, the term cell is intended to cover also a group of cells in instances where more than one cell is controlled by a controller entity (for instance a URA update).
The above discusses the transfer of information between two radio network controllers and the between the radio network controller and the core network controller. Embodiments of the present invention can be applicable to other network elements where applicable.
It is also noted herein that while the above describes exemplifying embodiments of the invention, there are several variations and modifications which may be made to the disclosed solution without departing from the scope of the present invention as defined in the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5081679 *||Jul 20, 1990||Jan 14, 1992||Ericsson Ge Mobile Communications Holding Inc.||Resynchronization of encryption systems upon handoff|
|US5204902 *||Sep 13, 1991||Apr 20, 1993||At&T Bell Laboratories||Cellular telephony authentication arrangement|
|US5293423 *||Dec 7, 1992||Mar 8, 1994||Telefonaktiebolaget L M Ericsson||Synchronizing method in a mobile radio system|
|US5377267 *||Aug 16, 1993||Dec 27, 1994||Nippon Telegraph And Telephone Corporation||Method of authentication with improved security for secrecy of authentication key|
|US5390252 *||Dec 22, 1993||Feb 14, 1995||Nippon Telegraph And Telephone Corporation||Authentication method and communication terminal and communication processing unit using the method|
|US5778075 *||Aug 30, 1996||Jul 7, 1998||Telefonaktiebolaget, L.M. Ericsson||Methods and systems for mobile terminal assisted handover in an private radio communications network|
|US5974036 *||Dec 24, 1996||Oct 26, 1999||Nec Usa, Inc.||Handoff-control technique for wireless ATM|
|US6418130 *||Jan 21, 1999||Jul 9, 2002||Telefonaktiebolaget L M Ericsson (Publ)||Reuse of security associations for improving hand-over performance|
|US6771776 *||Nov 11, 1999||Aug 3, 2004||Qualcomm Incorporated||Method and apparatus for re-synchronization of a stream cipher during handoff|
|US6961571 *||Apr 5, 2000||Nov 1, 2005||Telefonaktiebolaget Lm Ericsson (Publ)||Relocation of serving radio network controller with signaling of linking of dedicated transport channels|
|US7065340 *||Jun 2, 2000||Jun 20, 2006||Nokia Networks Oy||Arranging authentication and ciphering in mobile communication system|
|US7123719 *||Feb 16, 2001||Oct 17, 2006||Motorola, Inc.||Method and apparatus for providing authentication in a communication system|
|WO1999051051A2||Mar 31, 1999||Oct 7, 1999||Nokia Netwoks Oy||A method for controlling connections to a mobile station|
|WO2000036860A1||Dec 7, 1999||Jun 22, 2000||Nokia Networks Oy||A method for controlling connections to a mobile station|
|1||ETSI: "TS 125 413 Universal Mobile Telecommunications System (IMTS); UTRAN Iu Interface RANAP Signalling (3G TS 24.413 Version 3.0.0 Release1999)," ETSI TS 125 413 V3.0.0, XX, XX, Jan. 2000, pp. 1-147.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8155660||Dec 6, 2010||Apr 10, 2012||Lg Electronics Inc.||MBMS dual receiver|
|US8331906 *||Dec 8, 2008||Dec 11, 2012||Nokia Corporation||Methods, apparatuses, system, and related computer program products for handover security|
|US8832449 *||Mar 21, 2007||Sep 9, 2014||Lg Electronics Inc.||Security considerations for the LTE of UMTS|
|US20100235634 *||Mar 21, 2007||Sep 16, 2010||Patrick Fischer||Security considerations for the lte of umts|
|US20110080861 *||Dec 6, 2010||Apr 7, 2011||Patrick Fischer||Mbms dual receiver|
|US20110201337 *||Dec 8, 2008||Aug 18, 2011||Nokia Corporation||Methods, apparatuses, system, and related computer program products for handover security|
|US20120009910 *||Sep 8, 2011||Jan 12, 2012||Research In Motion Limited||Apparatus and method for applying ciphering in a universal mobile telecommunications system|
|U.S. Classification||380/247, 455/411, 455/436, 380/272, 455/437|
|International Classification||H04W36/00, H04K1/00, H04L9/00, H04W36/12|
|Aug 25, 2003||AS||Assignment|
Owner name: NOKIA CORPORATION, FINLAND
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ISOKANGAS, JARI;SARKKINEN, SINIKKA;REEL/FRAME:014477/0307;SIGNING DATES FROM 20030728 TO 20030812
Owner name: NOKIA CORPORATION,FINLAND
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ISOKANGAS, JARI;SARKKINEN, SINIKKA;SIGNING DATES FROM 20030728 TO 20030812;REEL/FRAME:014477/0307
|Feb 21, 2008||AS||Assignment|
Owner name: NOKIA SIEMENS NETWORKS OY, FINLAND
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NOKIA CORPORATION;REEL/FRAME:020550/0001
Effective date: 20070913
Owner name: NOKIA SIEMENS NETWORKS OY,FINLAND
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NOKIA CORPORATION;REEL/FRAME:020550/0001
Effective date: 20070913
|Aug 9, 2013||FPAY||Fee payment|
Year of fee payment: 4