[go: up one dir, main page]

WO2008152611A1 - Apparatus, method and computer program product providing transparent container - Google Patents

Apparatus, method and computer program product providing transparent container Download PDF

Info

Publication number
WO2008152611A1
WO2008152611A1 PCT/IB2008/052352 IB2008052352W WO2008152611A1 WO 2008152611 A1 WO2008152611 A1 WO 2008152611A1 IB 2008052352 W IB2008052352 W IB 2008052352W WO 2008152611 A1 WO2008152611 A1 WO 2008152611A1
Authority
WO
WIPO (PCT)
Prior art keywords
user equipment
network node
identifier
transparent container
nonce
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/IB2008/052352
Other languages
French (fr)
Inventor
Benoist Sebire
Leping Huang
Jukka Ranta
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Inc
Original Assignee
Nokia Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Inc filed Critical Nokia Inc
Publication of WO2008152611A1 publication Critical patent/WO2008152611A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H04W36/0038Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information of security context information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03Protecting confidentiality, e.g. by encryption
    • H04W12/037Protecting confidentiality, e.g. by encryption of the control plane, e.g. signalling traffic

Definitions

  • the exemplary and non-limiting embodiments of this invention relate generally to wireless communications systems and, more specifically, relate to handovers of a user equipment/mobile station from one network node to another.
  • DL downlink e-/E- evolved also known as LTE
  • LTE long term evolution also known as 3.9G
  • This invention is related to mobility handling in a wireless communication network, and embodiments are detailed in the context of E-UTRAN (e.g., 3GPP Release 8).
  • E-UTRAN e.g., 3GPP Release 8
  • the current assumption in E-UTRAN is to have a network-prepared and network-controlled handover procedure, which is also known as a backward handover procedure (BHO).
  • BHO backward handover procedure
  • This is stated explicitly in 3GPP TS 36.300 V8.0.0 (2007-03) at Section 10.1.2.1 HANDOVER: "The intra E-UTRAN HO in RRC_CONNECTED state is UE assisted NW controlled HO, with HO preparation signalling in E-UTRAN.”
  • a detailed description of the handover procedure for E- UTRAN can be found at subclause 10.1.2.1. Relevant portions of 3GPP TS 36.300 V8.0.0 (2007-03) are attached hereto as Exhibit A.
  • the E-UTRAN network includes a plurality of eNBs 12a, 12b, 12c that communicate with one another via a X2 interface or link. Each is coupled to one or more MME/SAE Gateways 14a, 14b via a S1 interface or link. Each of the eNBs 12a-c control one or more UEs (not shown) in its cell. In the prior art, BHOs are initiated by one of the eNBs 12a-c for handing over a specific UE within its cell to another eNB 12a-c.
  • the source eNB refers to the BS (or more generically the network node) from which the UE moves and the target eNB refers to the BS (or more generically the network node) under whose control the UE is moving.
  • an FHO procedure is not network- prepared but instead it is the user equipment UE that selects the target eNB and it is the UE which initiates the handover procedure from the source eNB to the target eNB.
  • the target eNB needs to learn the UE context. In the E-UTRAN system this encompasses the security context, UE capability context and QoS context.
  • One problem related to FHO is how to establish a secure communication between the UE and the source eNB through the target eNB. Because FHO is user-initiated, the target eNB does not have the UE's context initially, and cannot communicate securely with the UE until given it.
  • a method that includes establishing with a serving network node an identifier for a user equipment, and at the user equipment generating a transparent container and encrypting the generated transparent container with a security context of the user equipment that is known to the serving network node. Further in the method is sent to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context, and thereafter the user equipment is handed over to the target network node.
  • the invention is a memory embodying a program of instructions that are executable by a processor for performing actions directed toward executing a handover.
  • the actions include establishing with a serving network node an identifier for a user equipment, generating a transparent container and encrypting the generated transparent container with a security context of the user equipment that is known to the serving network node, sending to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context, and thereafter handing over to the target network node.
  • an apparatus that includes a first module (e.g., transceiver circuitry that includes a transmitter and receiver) and a second module (e.g., processor circuitry).
  • the first module is configured to establish with a serving network node an identifier for the apparatus.
  • the second module is configured to generate a transparent container and to encrypt the generated transparent container with a security context of the apparatus that is known to the serving network node.
  • the first module is further configured to send to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context so as to handover the apparatus to the target network node.
  • this apparatus is the user equipment or an integrated circuit configured for use within the user equipment.
  • an apparatus that includes communicating means (such as a transceiver that includes a transmitter and a receiver) for establishing with a serving network node an identifier for the apparatus, and computing means (such as a processor) for generating a transparent container and encrypting the generated transparent container with a security context of the apparatus that is known to the serving network node.
  • the communicating means is further for sending to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context so as to handover the apparatus to the target network node.
  • a target network node receiving from a user equipment an encrypted transparent container and an identifier for the user equipment.
  • the received identifier is unencrypted.
  • the encrypted transparent container and the unencrypted identifier are forwarded from the target network node to a source network node, a context for the user equipment is received at the target network node from the source network node, and thereafter the target network node receives handover of the user equipment.
  • a memory embodying a program of instructions that are executable by a processor for performing actions directed to executing a handover.
  • the actions include receiving from a user equipment an encrypted transparent container and an identifier for the user equipment (the received identifier is unencrypted), forwarding to a source network node the encrypted transparent container and the unencrypted identifier, receiving from the source network node a context of the user equipment, and thereafter receiving handover of the user equipment.
  • an apparatus that includes a first module (e.g., a receiver of a transceiver) and a second module (e.g., a modem) and a third module (e.g., a processor).
  • the first module is configured to receive from a user equipment an encrypted transparent container and an identifier for the user equipment, where the received identifier is unencrypted.
  • the second module is configured to forward to a source network node the encrypted transparent container and the unencrypted identifier.
  • the second module is further configured to receive from the source network node a context of the user equipment.
  • the third module is configured to receive handover of the user equipment.
  • this apparatus is a target network node or an integrated circuit configured for use within a target network node.
  • an apparatus that includes receive means (such as a receiver), communication means different from the receive means (such as a modem) and computing means (such as a processor).
  • receive means such as a receiver
  • communication means different from the receive means such as a modem
  • computing means such as a processor.
  • the receive means is for receiving from a user equipment an encrypted transparent container and an identifier for the user equipment, where the received identifier is unencrypted.
  • the communication means is for forwarding to a source network node the encrypted transparent container and the unencrypted identifier, and further for receiving from the source network node a context of the user equipment.
  • the computing means is for receiving handover of the user equipment.
  • [0015] in accordance with another exemplary embodiment of the invention is a method that includes establishing with a user equipment an identifier for the user equipment, receiving from a target network node an encrypted transparent container and the identifier for the user equipment which is unencrypted, decrypting the transparent container received from the target network node with a security context of the user equipment, and responsive to matching the established identifier with the identifier received from the target network node, sending to the target network node a context of the user equipment.
  • the invention is a memory embodying a program of instructions that are executable by a processor for performing actions directed to executing a handover.
  • the actions include establishing with a user equipment an identifier for the user equipment, receiving from a target network node an encrypted transparent container and the identifier for the user equipment which is unencrypted, decrypting the transparent container received from the target network node with a security context of the user equipment, and responsive to matching the established identifier with the identifier received from the target network node, sending to the target network node a context of the user equipment.
  • an apparatus that includes a first module (e.g., a transceiver), a second module (e.g., a modem), and a third module (e.g., a processor).
  • the first module is configured to establish with a user equipment an identifier for the user equipment.
  • the second module is configured to receive from a target network node an encrypted transparent container and the identifier for the user equipment, which identifier is received unencrypted.
  • the third module is configured to match the established identifier with the identifier received from the target network node and to decrypt the transparent container received from the target network node with a security context of the user equipment.
  • the first module is further configured, responsive to the third module matching the established identifier with the received identifier, to send to the target network node a context for the user equipment.
  • this apparatus is a serving network node or an integrated circuit configured for use within a serving network node.
  • first communication means such as a transceiver
  • second communication means such as a modem
  • processing means such as a processor
  • the first communication means is for establishing with a user equipment an identifier for the user equipment.
  • the second communication means is for receiving from a target network node an encrypted transparent container and the identifier for the user equipment, where the received identifier is unencrypted.
  • the processing means is for matching the established identifier with the identifier received from the target network node, and for decrypting the transparent container received from the target network node with a security context of the user equipment. Responsive to the processor matching the established identifier with the received identifier, the first communication means is further for sending to the target network node a context for the user equipment.
  • a method that includes establishing a nonce between a serving access node and a user equipment, wherein establishing may be by receiving the nonce from the user equipment or by the serving access node generating the nonce and sending the generated nonce to the user equipment. Further in the method, from a target network node is received a transparent container that is encrypted with a security context of the user equipment that is valid between the user equipment and the serving access node, and also from the target network node is received a nonce that is unencrypted.
  • the transparent container is from the user equipment by matching the nonce received from the target network node with the nonce established with the user equipment, decrypting the transparent container using the security context of the user equipment, and conditional on the matching, sending to the target network node a context for the user equipment.
  • Figure 1A is a prior art E-UTRAN system architecture overview, reproduced from Figure 4 at section 4 of 3GPP TS 36.300, V8.0.0 (2007-03).
  • Figure 1 B is a prior art E-UTRAN signaling protocol for an Intra-MME/SAE Gateway HO (BHO) of a UE from a source eNB to a target eNB, reproduced from Figure 10.1.2.1 at Section 10.1.2.1.1 of 3GPP TS 36.300, V8.0.0 (2007-03).
  • BHO Intra-MME/SAE Gateway HO
  • Figure 2 shows high-level schematic block diagrams of apparatus in which embodiments of the invention may be implemented.
  • Figure 3 is a signaling diagram for a forward handover procedure according to an embodiment of the invention.
  • Figure 4 is a diagram of method steps executed by the source eNB of Figure 2 according to an exemplary embodiment of the invention.
  • Figure 5 is a diagram of method steps executed by the target eNB of Figure 2 according to an exemplary embodiment of the invention.
  • Figure 6 is a diagram of method steps executed by the UE of Figure 2 according to an exemplary embodiment of the invention.
  • the UE sends a transparent container for the source eNB to the target eNB during the FHO procedure.
  • the transparent container is encrypted with security keys of the UE's context (e.g., the UE's security context), and so the content of the transparent container can be understood/deciphered by the source eNB with which the UE has been communicating securely, but not by the target eNB which has not yet securely communicated with the UE.
  • the target eNB sends the transparent containerto the source eNB, where the UE originating the transparent container is authenticated and the transparent container itself is deciphered.
  • the source eNB then sends the UE context to the target eNB and handover of the UE is completed so that the UE is under control of the target eNB and no longer under control of the source eNB.
  • Certain messages of Figure 1 B e.g., handover confirm, handover complete, ACK, release resource, data forwarding, etc.
  • the source eNB then provides the UE context to the target eNB so that it may communicate securely with the UE, completing the forward handover.
  • ciphering/deciphering refers to security-related encryption/decryption, as distinct from non-security related wireless signal processing such as coding/decoding for error control.
  • a wireless network 20 is adapted for communication with a UE 22 via a source eNB [designated eNB (S)] 24 and also via a target eNB 26 [designated eNB (T)].
  • the network 20 may include a serving MME/SAE/radio network controller RNC 28 or other radio controller function known by various terms in different wireless communication systems.
  • the UE 22 includes a digital processor (DP) 2A, a memory (MEM) 22B that stores a program (PROG) 22C, and a suitable radio frequency (RF) transceiver 22D coupled to one or more antennas 22E (one shown) for bidirectional wireless communications over one or more wireless links 21 A, 21 B with the source eNB 24 and with the target eNB 26.
  • DP digital processor
  • MEM memory
  • PROG program
  • RF radio frequency
  • Each of the eNBs 24, 26 also includes a DP 24A, 26A, a MEM 24B, 26B that stores a PROG 24C, 26C, and a suitable RF transceiver 24D, 26D coupled to one or more antennas 24E, 26E.
  • Each of the eNBs 24, 26 may be coupled via a data path 30 (e.g., lub or S1 interface) to the serving or other MME/RNC 28.
  • the MME/RNC 28 includes a DP 28A, a MEM 28B that stores a PROG 28C, and a suitable modem and/or transceiver (not shown separately from the DPs) for communication with either or both of the eNBs 24, 26 over the lub link 30.
  • the source eNB 24 and the target eNB 26 are coupled to one another via a separate bidirectional data link 32 (e.g., X2 interface), and may communicate directly with one another independent of the MME/SAE/RNC 28.
  • a separate bidirectional data link 32 e.g., X2 interface
  • the communications detailed below between the source eNB 24 and the target eNB 26 with respect to embodiments of this invention may be communicated via the S1 interface(s) and via the MME/RNC 28 without loss of generality.
  • communications between the eNBs 24, 26, whether directly or through the MME 28, are via modems at the respective devices which as shown are a part of the illustrated DPs 24A, 26A.
  • a security block 22F that stores a ciphering/deciphering program and related security keys as will be detailed below.
  • the source eNB 24 and the target eNB 26 include similar security blocks 24F, 26F.
  • the MME/RNC 28 may in certain embodiments also include a similar security block, such as where the MME acts as more than a passive conduit for communications between the source eNB 24 and the target eNB 26 for the messages detailed below.
  • each of the UE 22, source eNB 24 and target eNB 26 include a similar security block does not imply that they each store at the same times the same security keys or means to decode/decipher a particular message; in the described embodiments security is enhanced by passing certain security keys between the source eNB 24 and target eNB via the X2 interface 32 (or passively through the MME/SEA 28 where no viable X2 interface is available).
  • At least one of the PROGs 22C, 24C and 26C is assumed to include program instructions that, when executed by the associated DP, enable the electronic device to operate in accordance with the exemplary embodiments of this invention, as will be discussed below in greater detail.
  • Inherent in the DPs 22A, 24A, and 26A is a clock to enable synchronism among the various apparatus for transmissions and receptions within the appropriate time intervals and slots required, and to determine time-validity of the authentication nonce for those embodiments.
  • the PROGs 22C, 24C, 26C may be embodied in software, firmware and/or hardware, as is appropriate.
  • the exemplary embodiments of this invention may be implemented by computer software stored in the MEM 22B and executable by the DP 22A of the UE 22 and similar for the other MEMs and DPs of the eNBs 24, 26, or by hardware, or by a combination of software and/or firmware and hardware in any or all of the devices shown.
  • the various embodiments of the UE 22 can include, but are not limited to, mobile stations, cellular telephones, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions.
  • PDAs personal digital assistants
  • portable computers having wireless communication capabilities
  • image capture devices such as digital cameras having wireless communication capabilities
  • gaming devices having wireless communication capabilities
  • music storage and playback appliances having wireless communication capabilities
  • Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions.
  • the MEMs 22B, 24B and 26B may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.
  • the DPs 22A, 24A and 26A may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples.
  • a transparent container is sent from the UE to the target eNB, which cannot decipher its contents.
  • the following detailed implementation is in the context of E-UTRAN and references specific terminology and messages known for that wireless system protocol, but the more general principles of the invention are not limited to only E-UTRAN systems.
  • the FHO procedures detailed below can be compared to having cell re- reselection in the RRC_CONNECTED / LTE_ACT!VE state, but with the addition of the transparent container.
  • the various names used forthe network entities, connection states, and the messages exchanged herein are not intended to be limiting in any respect, as these entities and states and messages may be identified by any suitable names.
  • One way to implement this embodiment is in a standard (e.g., 3GPP TS) that defines the specific content of the transparent container, and how the source eNB 24 (which receives the transparent container from the target eNB 26) determines from the transparent container exactly which UE 22 originated it and is initiating a FHO.
  • 3GPP TS 3rd Generation Partnership Project
  • Figure 3 is a signalling diagram according to a particular embodiment specific to E-UTRAN implementation, showing the UE 22, source eNB 24, and target eNB 26 from Figure 2.
  • Figure 3 begins with the UE 22 under control of the source eNB 24 as normal, prior to any FHO initiation.
  • the UE 22 and eNB 24 agree in the interchange of message 302 on a UE authenticating nonce, a C-RNTI, or some other identifier for the UE such as a NAS level identity (e.g., IMSI).
  • a NAS level identity e.g., IMSI
  • the UE 22 accesses the target eNB 26, while still under control of the source eNB 24, by performing a random access procedure (see for example 3GPP TS 36.300 subclause 10.1.5), modified with the transparent container as seen in Figure 3.
  • the UE 22 sends a random access RA preamble 304 on the RACH to the target eNB 26 as is known.
  • the target eNB 26 sends to the UE 22 a RA RESPONSE message 306 on the DL- SCH as is known.
  • the UE 22 then sends back to the target eNB 26 a RA CONNECTION REQUEST message 308.
  • RRC CONNECTION REQUEST message 308 generated by the RRC layer at the UE 22 and transmitted via CCCH on UL-SCH to the target eNB 26, a transparent container aimed at the source eNB 24 is included.
  • the transparent container is ciphered and integrity protected with the security keys known to both the UE 22 and the source eNB 24, but not known to the target eNB 26. This ensures that the content of the container cannot be read by the target eNB 26, or by any other network node or other UEs apart from the source eNB 24.
  • the transparent container is sent 310 by the target eNB 26 to the source eNB
  • the target eNB 26 identifies the source eNB 24 by any of various methods, for example having the UE 22 indicate the source eNB 24 identity to the target eNB 26 in the RA CONNECTION REQUEST message or via some other explicit signaling.
  • the source eNB 24 receives 310 from the target eNB 26 the transparent container over the X2 interface. To be able to decipher its content and check the originator (integrity protection), the identity of the UE is given with the message bearing the transport container (308 and 310). Three specific alternatives for that UE identification are detailed: • Before handover, the UE and the source eNB agree on a one time nonce. This nonce is used to authenticate UE, and is updated whenever it is used (or whenever it expires). It is included in plain text (i.e. non-ciphered) in the transparent container. • The C-RNTI used by the UE in the source eNB is included in plain text (i.e. non-ciphered) in the transparent container.
  • a NAS level identity of the UE e.g. IMSI or some mathematical operation on IMSl such as IMSImod128 that protects security of the IMSI itself
  • plain text i.e. non-ciphered
  • the source eNB 24 knows the IMSI or IMSImodi 28 (or similar) already from network access and subscriber identification, it knows the C-RNTI because it assigns it to the UE 22, and it knows the UE authenticating nonce due to explicit signaling at 302 added by embodiments of this invention that use the nonce option to identify the UE 22.
  • the UE authenticating nonce option provides additional security in that tracking movement of the UE 22 is not possible; only the UE 22 and the source eNB 24 know that the particular UE 22 is associated with that particular nonce.
  • An authenticating nonce is generally a number or bit string or initialization vector for the encryption that is used only once, often a random or pseudo-random number/vector issued in an authentication protocol to ensure that old communications are not subject to a replay attack. To ensure that a nonce is used only once, they are often made time-variant and possibly including a suitably granular timestamp in its value, or generated with enough random bits to ensure a probabilistically insignificant chance of repeating a previously generated value.
  • a suitable authentication nonce for the FHO/transparent container purposes detailed herein may be a randomly generated initialization vector or bit string with or without a time stamp.
  • the entity issuing the nonce (the UE 22 or the eNB 24) can simply re-issue to the other entity a new authentication nonce with a refreshed validity period.
  • the source eNB 24 can authenticate the UE 22 and find out the security context (Keys and serial number SN) associated with that UE 22.
  • the source eNB 24 uses those security keys (e.g. K_ ⁇ RRC ⁇ ) and SN to decipher and authenticate 312 the protected content of the transparent container.
  • the exact content of the transparent container itself may vary widely in various implementations, but one embodiment includes a forward handover command included within the transparent container.
  • the source eNB 24 Upon decryption 312 of the container, the source eNB 24 forwards the UE context 314 to the target eNB 26, including keying materials for the security keys. From that message 314 onward, the target eNB 26 has all the information it needs to communicate securely with the UE 22.
  • the same handover is repeated within a short period of time, i.e. the UE 22 moves back to the source eNB 24 and tries the same handover again. This is to be expected in the case of a handover failure.
  • the encryption keys are not necessarily updated in between these events, so it is advantageous to avoid using the same encryption parameters again to cipher the transparent container.
  • a new nonce could be generated in the UE and included as plaintext in the message (e.g., repeat of message 308) carrying the transparent container in such instances.
  • the specifics of how the nonce is used in the initialization vector depends on the encryption algorithm being used, and will vary widely in different implementations of this invention.
  • the COUNT parameter of the Snow algorithm can be set to be the value of the nonce, [see ETSI TC SAGE Specification: "Specification of the 3GPP Confidentiality and Integrity Algorithms UEA2 & UIA2; Document 2: SNOW 3G specification" version 1.0, 2006-01-10.
  • the above ETSI document is referenced at 3GPP TS 35.216 V7.0.0 (2006-06).
  • SNOW 3G is a word-oriented stream cipher that generates a sequence of 32-bit words under the control of a 128-bit key and a 128-bit initialization variable.]
  • Figure 4 is a diagram of method steps executed by the source eNB 24 of
  • the source eNB 24 stores some predetermined identifier for the UE initiating the FHO, of which the three options detailed above are listed as examples. Also at block 402 the source eNB 24 stores the UE context, which it uses for communicating securely with the UE 22.
  • the source eNB 24 receives from a neighboring eNB 26 (the UE's target eNB 26) a transparent container.
  • the message bearing that transparent container may include, unencrypted/plain text, the C-RNTI or the IMSI for the UE 22 or the nonce that was previously arranged/agreed with the source eNB 24 and the UE 22.
  • the source eNB 24 determines from the IMSI/C- RNTI/nonce the UE to which the transparent container applies, and at block 408 the source eNB 24 authenticates the UE that sent the transparent container and deciphers it using the keying materials and security keys of the UE context.
  • the source eNB 24 then sends at block 410 the UE context, including the keying materials and the security keys, to the neighbor eNB which is the target eNB 26.
  • the target eNB 26 then has all the information it needs to communicate securely with the UE 22, and the source eNB 24 deletes the UE 22 from its list of UEs for which it currently is the serving eNB.
  • Figure 5 is a diagram of method steps executed by the target eNB 26 of Figure
  • the target eNB 26 receives from a UE 22, which is not served at that time by the target eNB 26, a random access preamble on the RACH. in reply at block 504 the target eNB 26 sends to the UE 22 a RA RESPONSE message on the DL-SCH, which is a common control channel CCCH.
  • the target eNB 26 receives from the UE 22 a RA CONNECTION REQUEST message that includes a transparent container. As above, this message may include, unencrypted/plain text, the C-RNTI or IMSI or authenticating nonce as plain text identifiers for the UE 22.
  • the target eNB 26 determines which is the source eNB 24 for that UE 22 (e.g., from that RA CONNECTION REQUEST message or from other signalling). Once determined, the target eNB 26 sends at block 510 to the source eNB 24 the transparent container, as well as the C-RNTI or IMSI of the UE 22 or the nonce, whichever predetermined UE identifier is used for FHO and included unencrypted in the transparent container or message bearing that container. At block 512 the target eNB 26 receives from the source eNB 24 the UE context, including security keys and keying materials. The target eNB 26 now has all the information it needs to communicate securely with the UE 22, which it then does at block 514 where the FHO to the target eNB 26 is complete.
  • Figure 6 is a diagram of method steps executed by the UE of Figure 2 according to an exemplary embodiment of the invention.
  • the UE 22 stores at block 602 of Figure 6 the predetermined identifier used for the FHO/transparent container.
  • the predetermined identifier used for the FHO/transparent container.
  • certain security advantages are realized by using the UE authenticating nonce implementation, where the UE itself generates the nonce initialization vector.
  • the UE 22 sends to its chosen target eNB 26 a random access preamble on the RACH.
  • the UE 22 receives from that target eNB 26 a RA RESPONSE message on the DL-SCH, and thereafter at block 608 the UE 22 sends to the target eNB 26 a RA CONNECTION REQUEST message that includes the transparent container.
  • the message from block 608 may also include the C-RNTI or IMSI or nonce as the plain text identifier of the UE 22.
  • the target eNB 26 at this point does not yet have the UE context and its related security keys (from the UE's security context) to decipher the transparent container.
  • the eNB 26 receives those as detailed above with respect to Figure 5, which enables the UE 22 to communicate securely with the target eNB 26 at block 610 using the UE context/security keys that were previously used with the source eNB 24 at block 602.
  • the user equipment e.g., UE 22
  • the message identifies the UE by an unencrypted IMSI or an unencrypted C-RNTI for a cell other than that of the target network node, or an unencrypted authentication nonce.
  • the UE sends the transparent container to the target network node in a RA CONNECTION REQUEST message.
  • the UE prior to initiating FHO the UE exchanges the nonce with a source network node, stores the UE authenticating nonce, and sends it as an identifier of the UE in the same message with (alongside or as part of) the transparent container.
  • the target network node e.g., target eNB 26
  • a method, an apparatus, and a computer program embodied on a computer readable memory and executable by a processor configured to receive from a UE not currently served by the target network node a message that includes an identifier of the UE and a transparent container that is encrypted with a context of the UE, to forward the identifier of the UE and the transparent container to a source network node of the UE without decrypting the container, to receive from the source network node the context of the UE, and thereafter to use the context of the UE to communicate securely with the UE.
  • the transparent container is included in a RA CONNECTION REQUEST message received after the target network node sends to the UE a RA RESPONSE message.
  • the identifier of the UE is one of an IMSI or a C-RNTI for the UE or a nonce which was received in the RA CONNECTION REQUEST message, where for the case of the C-RNTI the C-RNTI is for a cell other than that of the target network node.
  • the source network node e.g., source eNB 24
  • the message comprising the transparent container includes, unencrypted, one of an authentication nonce or the UE's IMSI or the UE's C-RNTI, where the C-RNTI is for the cell of the source network node.
  • the UE authentication nonce is received from the UE at the source network node, or the source network node generates the UE authentication nonce and sends it to the UE, prior to the time the source network node receives from the target network node the message comprising the transparent container.
  • the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof.
  • some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto.
  • firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto.
  • While various aspects of the invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
  • Embodiments of the inventions may be practiced in various components such as integrated circuit modules.
  • the design of integrated circuits is by and large a highly automated process.
  • Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

An identifier (e.g., IMSI, IMSI mod 128, C-RNTI, or a nonce) is established between a serving access node s-BS and a user equipment UE. The UE generates and encrypts a transparent container with its security context, which is known to the s-BS. The UE sends the encrypted transparent container, appended with the unencrypted identifier, to a target access node t-BS. For a forward handover FHO, these are sent in a random access procedure along with an identifier for the s-BS. The t-BS reads the s-BS identifier, and forwards to the s-BS the encrypted container with the appended UE identifier. The s-BS matches the received UE identifier with the established one, decrypts the transparent container received from the t-BS with the UE's security context, and based on the matching sends to the t-BS a context for the UE. The UE's security context is kept secure and FHO proceeds only to the UE-selected t- BS.

Description

APPARATUS, METHOD AND COMPUTER PROGRAM PRODUCT PROVIDING
TRANSPARENT CONTAINER
TECHNICAL FIELD:
[0001] The exemplary and non-limiting embodiments of this invention relate generally to wireless communications systems and, more specifically, relate to handovers of a user equipment/mobile station from one network node to another.
BACKGROUND:
[0002] Various abbreviations that appear in the specification and/or in the drawing figures are defined as follows:
3GPP third generation partnership project
ACK acknowledgement message
CCCH common control channel
C-RNTI cell radio network temporary identifier
DL downlink e-/E- evolved (also known as LTE)
HO/BHO/FHO handover/backward handover/forward handov
IMSI international mobile subscriber identity
LTE long term evolution (also known as 3.9G)
MME mobility management entity
NAS non-access stratum
Node B/NB base station or BS
NW network
QoS quality of service
RACH random access channel
RAN radio access network
RRC radio resource control
SAE system architecture evolution
SCH synchronization channel
UE user equipment
UL uplink
UMTS universal mobile telecommunications system
UTRAN UMTS terrestrial radio access network
[0003] This invention is related to mobility handling in a wireless communication network, and embodiments are detailed in the context of E-UTRAN (e.g., 3GPP Release 8). The current assumption in E-UTRAN is to have a network-prepared and network-controlled handover procedure, which is also known as a backward handover procedure (BHO). This is stated explicitly in 3GPP TS 36.300 V8.0.0 (2007-03) at Section 10.1.2.1 HANDOVER: "The intra E-UTRAN HO in RRC_CONNECTED state is UE assisted NW controlled HO, with HO preparation signalling in E-UTRAN." A detailed description of the handover procedure for E- UTRAN can be found at subclause 10.1.2.1. Relevant portions of 3GPP TS 36.300 V8.0.0 (2007-03) are attached hereto as Exhibit A.
[0004] The general system architecture 10 is shown at Figure 1 , reproduced from
Figure 4 at Section 4 of the above-referenced specification 3GPP TS 36.300. The E-UTRAN network includes a plurality of eNBs 12a, 12b, 12c that communicate with one another via a X2 interface or link. Each is coupled to one or more MME/SAE Gateways 14a, 14b via a S1 interface or link. Each of the eNBs 12a-c control one or more UEs (not shown) in its cell. In the prior art, BHOs are initiated by one of the eNBs 12a-c for handing over a specific UE within its cell to another eNB 12a-c. Signalling procedures for such a prior art BHO are shown at Figure 1 B, reproduced from Figure 10.1.2.1 (Intra-MME/SAE Gateway HO) at Section 10.1.2.1.1 of the above-referenced 3GPP TS 36.300. Sections 10.1.2.1.1 through 10.1.2.3 of 3GPP TS 36.300 provide further details concerning the messages and decisions shown in Figure 1 B.
[0005] There is a growing interest, specifically in developing 3GPP radio access network RAN procedures, for a forward handover procedure (FHO) in addition to the agreed BHO procedure noted above and at Figure 1 B. Conventionally and as used herein, the source eNB refers to the BS (or more generically the network node) from which the UE moves and the target eNB refers to the BS (or more generically the network node) under whose control the UE is moving. As opposed to BHO, an FHO procedure is not network- prepared but instead it is the user equipment UE that selects the target eNB and it is the UE which initiates the handover procedure from the source eNB to the target eNB. In FHO, the target eNB needs to learn the UE context. In the E-UTRAN system this encompasses the security context, UE capability context and QoS context. One problem related to FHO is how to establish a secure communication between the UE and the source eNB through the target eNB. Because FHO is user-initiated, the target eNB does not have the UE's context initially, and cannot communicate securely with the UE until given it.
[0006] What is needed is a way to employ FHO without compromising security, and without adding excessive signaling overhead to the wireless system.
SUMMARY:
[0007] In accordance with one exemplary embodiment of the invention is a method that includes establishing with a serving network node an identifier for a user equipment, and at the user equipment generating a transparent container and encrypting the generated transparent container with a security context of the user equipment that is known to the serving network node. Further in the method is sent to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context, and thereafter the user equipment is handed over to the target network node.
[0008] In accordance with another exemplary embodiment of the invention is a memory embodying a program of instructions that are executable by a processor for performing actions directed toward executing a handover. In this embodiment the actions include establishing with a serving network node an identifier for a user equipment, generating a transparent container and encrypting the generated transparent container with a security context of the user equipment that is known to the serving network node, sending to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context, and thereafter handing over to the target network node.
[0009] In accordance with still another exemplary embodiment of the invention is an apparatus that includes a first module (e.g., transceiver circuitry that includes a transmitter and receiver) and a second module (e.g., processor circuitry). The first module is configured to establish with a serving network node an identifier for the apparatus. The second module is configured to generate a transparent container and to encrypt the generated transparent container with a security context of the apparatus that is known to the serving network node. The first module is further configured to send to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context so as to handover the apparatus to the target network node. In an embodiment this apparatus is the user equipment or an integrated circuit configured for use within the user equipment.
[0010] In accordance with yet another exemplary embodiment of the invention is an apparatus that includes communicating means (such as a transceiver that includes a transmitter and a receiver) for establishing with a serving network node an identifier for the apparatus, and computing means (such as a processor) for generating a transparent container and encrypting the generated transparent container with a security context of the apparatus that is known to the serving network node. The communicating means is further for sending to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context so as to handover the apparatus to the target network node.
[0011] In accordance with another exemplary embodiment of the invention is a method that includes a target network node receiving from a user equipment an encrypted transparent container and an identifier for the user equipment. The received identifier is unencrypted. Further in the method the encrypted transparent container and the unencrypted identifier are forwarded from the target network node to a source network node, a context for the user equipment is received at the target network node from the source network node, and thereafter the target network node receives handover of the user equipment.
[0012] In accordance with still another exemplary embodiment of the invention is a memory embodying a program of instructions that are executable by a processor for performing actions directed to executing a handover. In this embodiment the actions include receiving from a user equipment an encrypted transparent container and an identifier for the user equipment (the received identifier is unencrypted), forwarding to a source network node the encrypted transparent container and the unencrypted identifier, receiving from the source network node a context of the user equipment, and thereafter receiving handover of the user equipment.
[0013] In accordance with a further exemplary embodiment of the invention is an apparatus that includes a first module (e.g., a receiver of a transceiver) and a second module (e.g., a modem) and a third module (e.g., a processor). The first module is configured to receive from a user equipment an encrypted transparent container and an identifier for the user equipment, where the received identifier is unencrypted. The second module is configured to forward to a source network node the encrypted transparent container and the unencrypted identifier. The second module is further configured to receive from the source network node a context of the user equipment. The third module is configured to receive handover of the user equipment. In an embodiment this apparatus is a target network node or an integrated circuit configured for use within a target network node.
[0014] In accordance with a still further exemplary embodiment of the invention is an apparatus that includes receive means (such as a receiver), communication means different from the receive means (such as a modem) and computing means (such as a processor). The receive means is for receiving from a user equipment an encrypted transparent container and an identifier for the user equipment, where the received identifier is unencrypted. The communication means is for forwarding to a source network node the encrypted transparent container and the unencrypted identifier, and further for receiving from the source network node a context of the user equipment. Thereafter the computing means is for receiving handover of the user equipment.
[0015] In accordance with another exemplary embodiment of the invention is a method that includes establishing with a user equipment an identifier for the user equipment, receiving from a target network node an encrypted transparent container and the identifier for the user equipment which is unencrypted, decrypting the transparent container received from the target network node with a security context of the user equipment, and responsive to matching the established identifier with the identifier received from the target network node, sending to the target network node a context of the user equipment.
[0016] In accordance with yet another exemplary embodiment of the invention is a memory embodying a program of instructions that are executable by a processor for performing actions directed to executing a handover. In this embodiment the actions include establishing with a user equipment an identifier for the user equipment, receiving from a target network node an encrypted transparent container and the identifier for the user equipment which is unencrypted, decrypting the transparent container received from the target network node with a security context of the user equipment, and responsive to matching the established identifier with the identifier received from the target network node, sending to the target network node a context of the user equipment.
[0017] In accordance with a further exemplary embodiment of the invention is an apparatus that includes a first module (e.g., a transceiver), a second module (e.g., a modem), and a third module (e.g., a processor). The first module is configured to establish with a user equipment an identifier for the user equipment. The second module is configured to receive from a target network node an encrypted transparent container and the identifier for the user equipment, which identifier is received unencrypted. The third module is configured to match the established identifier with the identifier received from the target network node and to decrypt the transparent container received from the target network node with a security context of the user equipment. The first module is further configured, responsive to the third module matching the established identifier with the received identifier, to send to the target network node a context for the user equipment. In an embodiment this apparatus is a serving network node or an integrated circuit configured for use within a serving network node.
[0018] In accordance with yet another exemplary embodiment of the invention is a device that includes first communication means (such as a transceiver), second communication means (such as a modem), and processing means (such as a processor). The first communication means is for establishing with a user equipment an identifier for the user equipment. The second communication means is for receiving from a target network node an encrypted transparent container and the identifier for the user equipment, where the received identifier is unencrypted. The processing means is for matching the established identifier with the identifier received from the target network node, and for decrypting the transparent container received from the target network node with a security context of the user equipment. Responsive to the processor matching the established identifier with the received identifier, the first communication means is further for sending to the target network node a context for the user equipment.
[0019] In accordance with yet another exemplary embodiment of the invention is a method that includes establishing a nonce between a serving access node and a user equipment, wherein establishing may be by receiving the nonce from the user equipment or by the serving access node generating the nonce and sending the generated nonce to the user equipment. Further in the method, from a target network node is received a transparent container that is encrypted with a security context of the user equipment that is valid between the user equipment and the serving access node, and also from the target network node is received a nonce that is unencrypted. Still further in the method it is determined that the transparent container is from the user equipment by matching the nonce received from the target network node with the nonce established with the user equipment, decrypting the transparent container using the security context of the user equipment, and conditional on the matching, sending to the target network node a context for the user equipment.
[0020] These and other aspects are detailed with particularity below.
BRIEF DESCRIPTION OF THE DRAWINGS:
[0021] Embodiments of the invention are detailed below with particular reference to the attached drawing Figures.
[0022] Figure 1A is a prior art E-UTRAN system architecture overview, reproduced from Figure 4 at section 4 of 3GPP TS 36.300, V8.0.0 (2007-03).
[0023] Figure 1 B is a prior art E-UTRAN signaling protocol for an Intra-MME/SAE Gateway HO (BHO) of a UE from a source eNB to a target eNB, reproduced from Figure 10.1.2.1 at Section 10.1.2.1.1 of 3GPP TS 36.300, V8.0.0 (2007-03).
[0024] Figure 2 shows high-level schematic block diagrams of apparatus in which embodiments of the invention may be implemented.
[0025] Figure 3 is a signaling diagram for a forward handover procedure according to an embodiment of the invention.
[0026] Figure 4 is a diagram of method steps executed by the source eNB of Figure 2 according to an exemplary embodiment of the invention.
[0027] Figure 5 is a diagram of method steps executed by the target eNB of Figure 2 according to an exemplary embodiment of the invention.
[0028] Figure 6 is a diagram of method steps executed by the UE of Figure 2 according to an exemplary embodiment of the invention.
DETAILED DESCRIPTION:
[0029] As a brief overview, according to an embodiment of the invention the UE sends a transparent container for the source eNB to the target eNB during the FHO procedure. The transparent container is encrypted with security keys of the UE's context (e.g., the UE's security context), and so the content of the transparent container can be understood/deciphered by the source eNB with which the UE has been communicating securely, but not by the target eNB which has not yet securely communicated with the UE. The target eNB sends the transparent containerto the source eNB, where the UE originating the transparent container is authenticated and the transparent container itself is deciphered. The source eNB then sends the UE context to the target eNB and handover of the UE is completed so that the UE is under control of the target eNB and no longer under control of the source eNB. Certain messages of Figure 1 B (e.g., handover confirm, handover complete, ACK, release resource, data forwarding, etc.) may be incorporated into the FHO signalling specifically shown (e.g., Figure 3) for embodiments of this invention.
[0030] This solves a serious security problem that is otherwise present in forward handovers (FHO). It is important to ensure that the UE's context, which has the keying information and security keys used for communicating securely with the UE, is only fetched if the UE has been properly identified. Identification of the UE cannot be made in the target eNB before fetching the context (and keying material for security) from the source eNB. This invention provides that the source eNB, which already has the UE's context, decipher the transparent container sent to it by the target eNB (and originated by the UE initiating the FHO). By doing so the source eNB authenticates the UE that originated the transparent container. The source eNB then provides the UE context to the target eNB so that it may communicate securely with the UE, completing the forward handover. In the context of these teachings, ciphering/deciphering refers to security-related encryption/decryption, as distinct from non-security related wireless signal processing such as coding/decoding for error control. It is the security context of the overall UE context that include keying parameters and security keys, particularly noted below, that enable communications between the UE and a network node to be secure. See for example Section 14 of 3GPP 36.300 V8.0.0 (Exhibit A). At least one of these security keys/security parameters of the UE's security context is used to cipher the transparent container at the UE 22, and to decipher the transparent container at the source eNB 24.
[0031] Reference is now made to Figure 2 for illustrating a simplified block diagram of various electronic devices that are suitable for use in practicing the exemplary embodiments of this invention. In Figure 2 a wireless network 20 is adapted for communication with a UE 22 via a source eNB [designated eNB (S)] 24 and also via a target eNB 26 [designated eNB (T)]. The network 20 may include a serving MME/SAE/radio network controller RNC 28 or other radio controller function known by various terms in different wireless communication systems. The UE 22 includes a digital processor (DP) 2A, a memory (MEM) 22B that stores a program (PROG) 22C, and a suitable radio frequency (RF) transceiver 22D coupled to one or more antennas 22E (one shown) for bidirectional wireless communications over one or more wireless links 21 A, 21 B with the source eNB 24 and with the target eNB 26.
[0032] Each of the eNBs 24, 26 also includes a DP 24A, 26A, a MEM 24B, 26B that stores a PROG 24C, 26C, and a suitable RF transceiver 24D, 26D coupled to one or more antennas 24E, 26E. Each of the eNBs 24, 26 may be coupled via a data path 30 (e.g., lub or S1 interface) to the serving or other MME/RNC 28. The MME/RNC 28 includes a DP 28A, a MEM 28B that stores a PROG 28C, and a suitable modem and/or transceiver (not shown separately from the DPs) for communication with either or both of the eNBs 24, 26 over the lub link 30. The source eNB 24 and the target eNB 26 are coupled to one another via a separate bidirectional data link 32 (e.g., X2 interface), and may communicate directly with one another independent of the MME/SAE/RNC 28. Alternatively, the communications detailed below between the source eNB 24 and the target eNB 26 with respect to embodiments of this invention may be communicated via the S1 interface(s) and via the MME/RNC 28 without loss of generality. Generally, communications between the eNBs 24, 26, whether directly or through the MME 28, are via modems at the respective devices which as shown are a part of the illustrated DPs 24A, 26A.
[0033] Also within the UE 22 is a security block 22F that stores a ciphering/deciphering program and related security keys as will be detailed below. The source eNB 24 and the target eNB 26 include similar security blocks 24F, 26F. Though not shown, the MME/RNC 28 may in certain embodiments also include a similar security block, such as where the MME acts as more than a passive conduit for communications between the source eNB 24 and the target eNB 26 for the messages detailed below. As will be seen from the description below, the fact that each of the UE 22, source eNB 24 and target eNB 26 include a similar security block does not imply that they each store at the same times the same security keys or means to decode/decipher a particular message; in the described embodiments security is enhanced by passing certain security keys between the source eNB 24 and target eNB via the X2 interface 32 (or passively through the MME/SEA 28 where no viable X2 interface is available).
[0034] At least one of the PROGs 22C, 24C and 26C is assumed to include program instructions that, when executed by the associated DP, enable the electronic device to operate in accordance with the exemplary embodiments of this invention, as will be discussed below in greater detail. Inherent in the DPs 22A, 24A, and 26A is a clock to enable synchronism among the various apparatus for transmissions and receptions within the appropriate time intervals and slots required, and to determine time-validity of the authentication nonce for those embodiments.
[0035] The PROGs 22C, 24C, 26C may be embodied in software, firmware and/or hardware, as is appropriate. In general, the exemplary embodiments of this invention may be implemented by computer software stored in the MEM 22B and executable by the DP 22A of the UE 22 and similar for the other MEMs and DPs of the eNBs 24, 26, or by hardware, or by a combination of software and/or firmware and hardware in any or all of the devices shown.
[0036] In general, the various embodiments of the UE 22 can include, but are not limited to, mobile stations, cellular telephones, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions.
[0037] The MEMs 22B, 24B and 26B may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The DPs 22A, 24A and 26A may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples.
[0038] As noted above, for embodiments of this invention a transparent container is sent from the UE to the target eNB, which cannot decipher its contents. The following detailed implementation is in the context of E-UTRAN and references specific terminology and messages known for that wireless system protocol, but the more general principles of the invention are not limited to only E-UTRAN systems. In genera! for an E-UTRAN implementation, the FHO procedures detailed below can be compared to having cell re- reselection in the RRC_CONNECTED / LTE_ACT!VE state, but with the addition of the transparent container. Further in this regard, the various names used forthe network entities, connection states, and the messages exchanged herein are not intended to be limiting in any respect, as these entities and states and messages may be identified by any suitable names.
[0039] One way to implement this embodiment is in a standard (e.g., 3GPP TS) that defines the specific content of the transparent container, and how the source eNB 24 (which receives the transparent container from the target eNB 26) determines from the transparent container exactly which UE 22 originated it and is initiating a FHO. As will be seen, three options are detailed as to how the UE identification may be done, though the description of three specific options does not preclude other ways to identify the UE consistent with the transparent container model for FHO detailed herein.
[0040] Figure 3 is a signalling diagram according to a particular embodiment specific to E-UTRAN implementation, showing the UE 22, source eNB 24, and target eNB 26 from Figure 2. Figure 3 begins with the UE 22 under control of the source eNB 24 as normal, prior to any FHO initiation. The UE 22 and eNB 24 agree in the interchange of message 302 on a UE authenticating nonce, a C-RNTI, or some other identifier for the UE such as a NAS level identity (e.g., IMSI). This agreed identifier is used throughout the system to identify the UE source of a particular transparent container, as will be detailed below. Now the UE 22 decides to initiate a FHO. In accordance with this embodiment, the UE 22 accesses the target eNB 26, while still under control of the source eNB 24, by performing a random access procedure (see for example 3GPP TS 36.300 subclause 10.1.5), modified with the transparent container as seen in Figure 3. The UE 22 sends a random access RA preamble 304 on the RACH to the target eNB 26 as is known. In response to receiving the RA preamble, the target eNB 26 sends to the UE 22 a RA RESPONSE message 306 on the DL- SCH as is known. The UE 22 then sends back to the target eNB 26 a RA CONNECTION REQUEST message 308. In that RRC CONNECTION REQUEST message 308 generated by the RRC layer at the UE 22 and transmitted via CCCH on UL-SCH to the target eNB 26, a transparent container aimed at the source eNB 24 is included.
[0041] The transparent container is ciphered and integrity protected with the security keys known to both the UE 22 and the source eNB 24, but not known to the target eNB 26. This ensures that the content of the container cannot be read by the target eNB 26, or by any other network node or other UEs apart from the source eNB 24.
[0042] The transparent container is sent 310 by the target eNB 26 to the source eNB
24. The target eNB 26 identifies the source eNB 24 by any of various methods, for example having the UE 22 indicate the source eNB 24 identity to the target eNB 26 in the RA CONNECTION REQUEST message or via some other explicit signaling.
[0043] The source eNB 24 receives 310 from the target eNB 26 the transparent container over the X2 interface. To be able to decipher its content and check the originator (integrity protection), the identity of the UE is given with the message bearing the transport container (308 and 310). Three specific alternatives for that UE identification are detailed: • Before handover, the UE and the source eNB agree on a one time nonce. This nonce is used to authenticate UE, and is updated whenever it is used (or whenever it expires). It is included in plain text (i.e. non-ciphered) in the transparent container. • The C-RNTI used by the UE in the source eNB is included in plain text (i.e. non-ciphered) in the transparent container.
• A NAS level identity of the UE (e.g. IMSI or some mathematical operation on IMSl such as IMSImod128 that protects security of the IMSI itself) is included in plain text (i.e. non-ciphered) in the transparent container.
[0044] As seen in Figure 3, whichever of these that the source eNB 24 uses to identify the UE 22 is known in advance of the source eNB 24 receiving 310 the transparent container from the exchange at message 302. The source eNB 24 knows the IMSI or IMSImodi 28 (or similar) already from network access and subscriber identification, it knows the C-RNTI because it assigns it to the UE 22, and it knows the UE authenticating nonce due to explicit signaling at 302 added by embodiments of this invention that use the nonce option to identify the UE 22. Note that the UE authenticating nonce option provides additional security in that tracking movement of the UE 22 is not possible; only the UE 22 and the source eNB 24 know that the particular UE 22 is associated with that particular nonce.
[0045] An authenticating nonce is generally a number or bit string or initialization vector for the encryption that is used only once, often a random or pseudo-random number/vector issued in an authentication protocol to ensure that old communications are not subject to a replay attack. To ensure that a nonce is used only once, they are often made time-variant and possibly including a suitably granular timestamp in its value, or generated with enough random bits to ensure a probabilistically insignificant chance of repeating a previously generated value. A suitable authentication nonce for the FHO/transparent container purposes detailed herein may be a randomly generated initialization vector or bit string with or without a time stamp. Where the UE remains under control of the same source eNB 24 as the term of the time stamp validity nears and end, the entity issuing the nonce (the UE 22 or the eNB 24) can simply re-issue to the other entity a new authentication nonce with a refreshed validity period.
[0046] Returning to Figure 3, once the source eNB 24 determines the identity of the
UE 22, the source eNB 24 can authenticate the UE 22 and find out the security context (Keys and serial number SN) associated with that UE 22. The source eNB 24 then uses those security keys (e.g. K_{RRC}) and SN to decipher and authenticate 312 the protected content of the transparent container.
[0047] The exact content of the transparent container itself may vary widely in various implementations, but one embodiment includes a forward handover command included within the transparent container.
[0048] Upon decryption 312 of the container, the source eNB 24 forwards the UE context 314 to the target eNB 26, including keying materials for the security keys. From that message 314 onward, the target eNB 26 has all the information it needs to communicate securely with the UE 22.
[0049] It is possible that the same handover is repeated within a short period of time, i.e. the UE 22 moves back to the source eNB 24 and tries the same handover again. This is to be expected in the case of a handover failure. The encryption keys are not necessarily updated in between these events, so it is advantageous to avoid using the same encryption parameters again to cipher the transparent container. To guarantee a unique initialization vector for the encryption, a new nonce could be generated in the UE and included as plaintext in the message (e.g., repeat of message 308) carrying the transparent container in such instances. The specifics of how the nonce is used in the initialization vector depends on the encryption algorithm being used, and will vary widely in different implementations of this invention. As an example, the COUNT parameter of the Snow algorithm can be set to be the value of the nonce, [see ETSI TC SAGE Specification: "Specification of the 3GPP Confidentiality and Integrity Algorithms UEA2 & UIA2; Document 2: SNOW 3G specification" version 1.0, 2006-01-10. The above ETSI document is referenced at 3GPP TS 35.216 V7.0.0 (2006-06). SNOW 3G is a word-oriented stream cipher that generates a sequence of 32-bit words under the control of a 128-bit key and a 128-bit initialization variable.]
[0050] Figure 4 is a diagram of method steps executed by the source eNB 24 of
Figure 2 according to an exemplary embodiment of the invention. At block 402, the source eNB 24 stores some predetermined identifier for the UE initiating the FHO, of which the three options detailed above are listed as examples. Also at block 402 the source eNB 24 stores the UE context, which it uses for communicating securely with the UE 22. At block 404 the source eNB 24 receives from a neighboring eNB 26 (the UE's target eNB 26) a transparent container. The message bearing that transparent container may include, unencrypted/plain text, the C-RNTI or the IMSI for the UE 22 or the nonce that was previously arranged/agreed with the source eNB 24 and the UE 22. Any of these or other options may be used as a plain text identifier of the UE 22 in the transparent container or in the message bearing the transparent container. At block 406 the source eNB 24 determines from the IMSI/C- RNTI/nonce the UE to which the transparent container applies, and at block 408 the source eNB 24 authenticates the UE that sent the transparent container and deciphers it using the keying materials and security keys of the UE context. The source eNB 24 then sends at block 410 the UE context, including the keying materials and the security keys, to the neighbor eNB which is the target eNB 26. The target eNB 26 then has all the information it needs to communicate securely with the UE 22, and the source eNB 24 deletes the UE 22 from its list of UEs for which it currently is the serving eNB.
[0051 ] Figure 5 is a diagram of method steps executed by the target eNB 26 of Figure
2 according to an exemplary embodiment of the invention. At block 502 the target eNB 26 receives from a UE 22, which is not served at that time by the target eNB 26, a random access preamble on the RACH. in reply at block 504 the target eNB 26 sends to the UE 22 a RA RESPONSE message on the DL-SCH, which is a common control channel CCCH. At block 506 the target eNB 26 receives from the UE 22 a RA CONNECTION REQUEST message that includes a transparent container. As above, this message may include, unencrypted/plain text, the C-RNTI or IMSI or authenticating nonce as plain text identifiers for the UE 22. At block 508 the target eNB 26 determines which is the source eNB 24 for that UE 22 (e.g., from that RA CONNECTION REQUEST message or from other signalling). Once determined, the target eNB 26 sends at block 510 to the source eNB 24 the transparent container, as well as the C-RNTI or IMSI of the UE 22 or the nonce, whichever predetermined UE identifier is used for FHO and included unencrypted in the transparent container or message bearing that container. At block 512 the target eNB 26 receives from the source eNB 24 the UE context, including security keys and keying materials. The target eNB 26 now has all the information it needs to communicate securely with the UE 22, which it then does at block 514 where the FHO to the target eNB 26 is complete.
[0052] Figure 6 is a diagram of method steps executed by the UE of Figure 2 according to an exemplary embodiment of the invention. Like block 402 of Figure 4, the UE 22 stores at block 602 of Figure 6 the predetermined identifier used for the FHO/transparent container. As noted above, certain security advantages are realized by using the UE authenticating nonce implementation, where the UE itself generates the nonce initialization vector. At block 604 the UE 22 sends to its chosen target eNB 26 a random access preamble on the RACH. At block 606 the UE 22 receives from that target eNB 26 a RA RESPONSE message on the DL-SCH, and thereafter at block 608 the UE 22 sends to the target eNB 26 a RA CONNECTION REQUEST message that includes the transparent container. As above, in certain implementations the message from block 608 may also include the C-RNTI or IMSI or nonce as the plain text identifier of the UE 22. The target eNB 26 at this point does not yet have the UE context and its related security keys (from the UE's security context) to decipher the transparent container. The eNB 26 receives those as detailed above with respect to Figure 5, which enables the UE 22 to communicate securely with the target eNB 26 at block 610 using the UE context/security keys that were previously used with the source eNB 24 at block 602.
[0053] In accordance with the described exemplary embodiments of the invention, there is provided with respect to the user equipment (e.g., UE 22) a method, an apparatus, and a computer program embodied on a computer readable memory and executable by a processor, that are configured to send, to a target network node that is not currently serving the user equipment, a message that identifies the UE and that comprises a transparent container that is encrypted using a context of the UE, and to communicate securely with the target network node using the context of the UE without the UE providing that context to the target network node directly. In embodiments, the message identifies the UE by an unencrypted IMSI or an unencrypted C-RNTI for a cell other than that of the target network node, or an unencrypted authentication nonce. In an embodiment the UE sends the transparent container to the target network node in a RA CONNECTION REQUEST message. In an embodiment, prior to initiating FHO the UE exchanges the nonce with a source network node, stores the UE authenticating nonce, and sends it as an identifier of the UE in the same message with (alongside or as part of) the transparent container.
[0054] In accordance with the described exemplary embodiments of the invention, there is provided with respect to the target network node (e.g., target eNB 26) a method, an apparatus, and a computer program embodied on a computer readable memory and executable by a processor, configured to receive from a UE not currently served by the target network node a message that includes an identifier of the UE and a transparent container that is encrypted with a context of the UE, to forward the identifier of the UE and the transparent container to a source network node of the UE without decrypting the container, to receive from the source network node the context of the UE, and thereafter to use the context of the UE to communicate securely with the UE. In embodiments, the transparent container is included in a RA CONNECTION REQUEST message received after the target network node sends to the UE a RA RESPONSE message. In embodiments, the identifier of the UE is one of an IMSI or a C-RNTI for the UE or a nonce which was received in the RA CONNECTION REQUEST message, where for the case of the C-RNTI the C-RNTI is for a cell other than that of the target network node. [0055] In accordance with the described exemplary embodiments of the invention, there is provided with respect to the source network node (e.g., source eNB 24) a method, an apparatus, and a computer program embodied on a computer readable memory and executable by a processor, configured to receive from a target or neighbor network node a message that includes a transparent container that is encrypted with a context of a UE, to identify a UE that originated the transparent container from the message and to decipher the transparent container with a context of that UE stored in a local memory, and to send to the target network node the UE context. In embodiments, the message comprising the transparent container includes, unencrypted, one of an authentication nonce or the UE's IMSI or the UE's C-RNTI, where the C-RNTI is for the cell of the source network node. In embodiments, the UE authentication nonce is received from the UE at the source network node, or the source network node generates the UE authentication nonce and sends it to the UE, prior to the time the source network node receives from the target network node the message comprising the transparent container.
[0056] Further, while described in the context of E-UTRAN (LTE), it is within the scope of the exemplary embodiments of this invention to use the above described UE 22, target eNB 26 and source eNB 24 procedures for other types of wireless communication systems, such as GSM, WiMAX, and other such systems that use geographically limited network nodes to control UEs moving through their cells. Such cell-based systems can be readily adapted by these teachings to employ FHOs initiated by the UE 22 from the source eNB 24 to the target eNB.
[0057] !n general, the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. While various aspects of the invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
[0058] Embodiments of the inventions may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.
[0059] Various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications of the teachings of this invention will still fall within the scope of the non-limiting embodiments of this invention.
[0060] Furthermore, some of the features of the various non-limiting embodiments of this invention may be used to advantage without the corresponding use of other features. As such, the foregoing description should be considered as merely illustrative of the principles, teachings and exemplary embodiments of this invention, and not in limitation thereof.

Claims

Claims: We claim:
1. A method comprising: establishing with a serving network node an identifier for a user equipment; at the user equipment, generating a transparent container and encrypting the generated transparent container with a security context of the user equipment that is known to the serving network node; sending to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context; and thereafter handing over to the target network node.
2. The method of claim 1 , wherein: the user equipment sends the encrypted transparent container and the unencrypted identifier for the user equipment to the target network node in a RANDOM ACCESS CONNECTION REQUEST message during a random access procedure; and the user equipment sends to the target network node an identifier for the serving network node during the random access procedure.
3. The method of claim 1 , wherein the identifier for the user equipment is one of an international mobile subscriber identity IMSI, an operation performed on the IMS!, a radio network temporary identifier C-RNTI assigned by the serving network node, or a nonce.
4. The method of claim 1 , wherein: handing over to the target network node comprises communicating securely with the target network node using a context of the user equipment without the user equipment providing the context to the target network node via direct signaling.
5. The method of claim 1 , wherein the identifier for the user equipment is sent to the target network node in a same message with the encrypted transparent container.
6. The method of claim 1 , wherein the identifier for the user equipment is a nonce.
7. The method of claim 6, wherein the nonce is generated by the user equipment and wherein establishing the identifier with the serving network node comprises sending the nonce to the serving network node.
8. The method of claim 1 , executed by a digital processor running a program tangibly stored on a memory for use within the user equipment.
9. An apparatus comprising: a first module configured to establish with a serving network node an identifier for the apparatus; a second module configured to generate a transparent container and to encrypt the generated transparent container with a security context of said apparatus that is known to the serving network node; the first module configured to send to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context so as to handover the apparatus to the target network node.
10. The apparatus of claim 9, wherein: the first module is configured to send the encrypted transparent container and the unencrypted identifier for the apparatus to the target network node in a RANDOM ACCESS CONNECTION REQUEST message during a random access procedure; and the first module is configured to send to the target network node an identifier for the serving network node during the random access procedure.
11. The apparatus of claim 9, wherein the identifier for the apparatus is one of an international mobile subscriber identity IMSI, an operation performed on the IMSI, a radio network temporary identifier C-RNT! assigned by the serving network node, or a nonce.
12. The apparatus of claim 9, wherein: upon the apparatus being handed over to the target network node, the apparatus is configured to communicate securely with the target network node using a context of the apparatus without having sent the context to the target network node via direct signaling.
13. The apparatus of claim 9, wherein the first module is configured to send the identifier for the apparatus to the target network node in a same message with the encrypted transparent container.
14. The apparatus of claim 9, wherein the identifier for the apparatus is a nonce.
15. The apparatus of claim 14, wherein the second module is configured to generate the nonce and wherein the first module is configured to establish the identifier with the serving network node by sending the nonce to the serving network node.
16. A method comprising: a target network node receiving from a user equipment an encrypted transparent container and an identifier for the user equipment, the identifier being unencrypted; forwarding from the target network node to a source network node the encrypted transparent container and the unencrypted identifier; receiving at the target network node from the source network node a context of the user equipment; and thereafter the target network node receiving handover of the user equipment.
17. The method of claim 16, wherein the encrypted transparent container and the unencrypted identifier for the user equipment are received in a RANDOM ACCESS CONNECTION REQUEST message during a random access procedure in which is also received from the user equipment an identifier for the serving network node.
18. The method of claim 16, wherein the identifier for the user equipment is one of an international mobile subscriber identity IMSI, an operation performed on the IMSI, a radio network temporary identifier C-RNTI assigned by the serving network node, or a nonce.
19. The method of claim 16, wherein the target network node receiving handover of the user equipment comprises the target network node communicating securely with the user equipment using the context of the user equipment that was received from the serving network node.
20. The method of claim 16, wherein the target network node receives in a same message from the user equipment the unencrypted identifier for the user equipment and the encrypted container.
21. The method of claim 16, wherein the identifier is a nonce.
22. The method of claim 16, executed by a digital processor running a program tangibly stored on a memory for use within the target network node.
23. An apparatus comprising: a first module configured to receive from a user equipment an encrypted transparent container and an identifier for the user equipment, the identifier being unencrypted; a second module configured to forward to a source network node the encrypted transparent container and the unencrypted identifier; the second module further configured to receive from the source network node a context of the user equipment; a third module configured to receive handover of the user equipment.
24. The apparatus of claim 23, wherein the first module is configured to receive the encrypted transparent container and the unencrypted identifier for the user equipment in a RANDOM ACCESS CONNECTION REQUEST message during a random access procedure in which the first module also receives from the user equipment an identifier for the serving network node.
25. The apparatus of claim 23, wherein the identifier for the user equipment is one of an international mobile subscriber identity IMSI, an operation performed on the IMSI, a radio network temporary identifier C-RNTI assigned by the serving network node, or a nonce.
26. The apparatus of claim 23, wherein the third module configured to receive the handover comprises the apparatus being configured to communicate securely with the user equipment using the context of the user equipment received from the serving network node by the first module.
27. The apparatus of claim 23, wherein the first module is configured to receive in a same message from the user equipment the unencrypted identifier for the user equipment and the encrypted transparent container.
28. The apparatus of claim 23, wherein the identifier is a nonce.
29. A method comprising: establishing with a user equipment an identifier for the user equipment; receiving from a target network node an encrypted transparent container and the identifier for the user equipment which is unencrypted; responsive to matching the established identifier with the identifier received from the target network node, decrypting the transparent container received from the target network node with a security context of the user equipment; and sending to the target network node a context of the user equipment.
30. The method of claim 29, wherein the identifier for the user equipment is one of an international mobile subscriber identity IMSI, an operation performed on the IMSI, a radio network temporary identifier C-RNTI assigned by the serving network node, or a nonce.
31. The method of claim 29, wherein the identifier for the user equipment is a nonce and wherein establishing the identifier comprises generating the nonce and sending the nonce to the user equipment.
32. The method of claim 29, executed by a digital processor running a program tangibly stored on a memory.
33. An apparatus comprising: a first module configured to establish with a user equipment an identifier for the user equipment; a second module configured to receive from a target network node an encrypted transparent container and the identifier for the user equipment which is unencrypted; a third module configured to match the established identifier with the identifier received from the target network node, and configured to decrypt the transparent container received from the target network node with a security context of the user equipment; and the first module being further configured, responsive to the third module matching the established identifier with the received identifier, to send to the target network node a context of the user equipment.
34. The apparatus of claim 33, wherein the identifier for the user equipment is one of an international mobile subscriber identity IMSI, an operation performed on the IMSI, a radio network temporary identifier C-RNTI assigned by the serving network node, or a nonce.
35. The apparatus of claim 33, wherein the identifier for the user equipment is a nonce and wherein the third module is configured to generate the nonce and the first module is configured to establish the identifier by sending the nonce to the user equipment.
36. A method comprising: establishing a nonce between a serving access node and a user equipment, wherein establishing comprises either receiving the nonce from the user equipment or the serving access node generating the nonce and sending the generated nonce to the user equipment; receiving from a target access node a transparent container that is encrypted with a security context of the user equipment that is valid between the user equipment and the serving access node and also a nonce that is unencrypted; and determining that the transparent container is from the user equipment by matching the nonce received from the target access node with the nonce established with the user equipment; decrypting the transparent container using the security context of the user equipment; and conditional on the matching, sending to the target network node a context for the user equipment.
PCT/IB2008/052352 2007-06-15 2008-06-13 Apparatus, method and computer program product providing transparent container Ceased WO2008152611A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US93482107P 2007-06-15 2007-06-15
US60/934,821 2007-06-15

Publications (1)

Publication Number Publication Date
WO2008152611A1 true WO2008152611A1 (en) 2008-12-18

Family

ID=39811751

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2008/052352 Ceased WO2008152611A1 (en) 2007-06-15 2008-06-13 Apparatus, method and computer program product providing transparent container

Country Status (1)

Country Link
WO (1) WO2008152611A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014099886A (en) * 2009-08-10 2014-05-29 Nec Corp Method for creating network security key in communications device and communications device
US10091649B2 (en) 2015-07-12 2018-10-02 Qualcomm Incorporated Network architecture and security with encrypted client device contexts
US10097995B2 (en) 2015-07-12 2018-10-09 Qualcomm Incorporated Network architecture and security with encrypted network reachability contexts
CN110583049A (en) * 2017-05-03 2019-12-17 瑞典爱立信有限公司 UE handling in RAN
WO2020248624A1 (en) * 2019-06-13 2020-12-17 华为技术有限公司 Communication method, network device, user equipment and access network device

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1708423A1 (en) * 2005-03-29 2006-10-04 Matsushita Electric Industrial Co., Ltd. Inter-domain context transfer using context tranfer managers
US20060233376A1 (en) * 2005-04-15 2006-10-19 Nokia Corporation Exchange of key material

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1708423A1 (en) * 2005-03-29 2006-10-04 Matsushita Electric Industrial Co., Ltd. Inter-domain context transfer using context tranfer managers
US20060233376A1 (en) * 2005-04-15 2006-10-19 Nokia Corporation Exchange of key material

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
QUALCOMM EUROPE: "Cell Switching in LTE_Active State", 3GPP TSG-RAN WG2, 12 May 2006 (2006-05-12), MEETING #53, Shanghai, China, pages 1 - 5, XP002499600, Retrieved from the Internet <URL:http://www.quintillion.co.jp/3GPP/TSG_RAN/TSG_RAN2006/TSG_RAN_WG2_RL2_5.htm> *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014099886A (en) * 2009-08-10 2014-05-29 Nec Corp Method for creating network security key in communications device and communications device
US10091649B2 (en) 2015-07-12 2018-10-02 Qualcomm Incorporated Network architecture and security with encrypted client device contexts
US10097995B2 (en) 2015-07-12 2018-10-09 Qualcomm Incorporated Network architecture and security with encrypted network reachability contexts
US11172357B2 (en) 2015-07-12 2021-11-09 Qualcomm Incorporated Network architecture and security with encrypted client device contexts
CN110583049A (en) * 2017-05-03 2019-12-17 瑞典爱立信有限公司 UE handling in RAN
CN110583049B (en) * 2017-05-03 2021-12-21 瑞典爱立信有限公司 UE handling in RAN
US11523444B2 (en) 2017-05-03 2022-12-06 Telefonaktiebolaget Lm Ericsson (Publ) UE handling in RAN
WO2020248624A1 (en) * 2019-06-13 2020-12-17 华为技术有限公司 Communication method, network device, user equipment and access network device

Similar Documents

Publication Publication Date Title
JP4820429B2 (en) Method and apparatus for generating a new key
US8627092B2 (en) Asymmetric cryptography for wireless systems
EP3449608B1 (en) Enhanced non-access stratum security
CN101682931B (en) Method for generating mobile station, base station and traffic encryption key
US20080039096A1 (en) Apparatus, method and computer program product providing secure distributed HO signaling for 3.9G with secure U-plane location update from source eNB
CN101405987B (en) Asymmetric cryptography for wireless systems
US20070224993A1 (en) Apparatus, method and computer program product providing unified reactive and proactive handovers
CN101945386B (en) A kind of method and system realizing safe key synchronous binding
US20090209259A1 (en) System and method for performing handovers, or key management while performing handovers in a wireless communication system
KR101270342B1 (en) Exchange of key material
JP5774096B2 (en) Air interface key update method, core network node, and radio access system
KR20130114561A (en) Local security key update at a wireless communication device
CN101309503A (en) Wireless handover method, base station and terminal
WO2008152611A1 (en) Apparatus, method and computer program product providing transparent container
KR20100126691A (en) System and method for performing key management while performing handovers or performing handovers in a wireless communication system
CN101835151B (en) The update method of air interface key and wireless access system
CN101902736B (en) Update method, core net node and the wireless access system of air interface key
JP6499315B2 (en) Mobile communication system and communication network

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08763339

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08763339

Country of ref document: EP

Kind code of ref document: A1