Handover of a device which uses another device as relay

A system (11) is configured to maintain a list of devices (1,9) associated with the system, wherein for each first device (1) of the list which uses a second device (9) of the list as a relay to the mobile communication network, the relation between the first device and the second device is recorded in the list and a security endpoint is recorded for the first device. The system is further configured to receive encrypted information from a device, determine from the list whether the device is used by a further device as a relay, forward the encrypted information to a security endpoint associated with the further device upon determining that the device is used by the further device as a relay and the security endpoint is not the system, and decrypt the encrypted information upon determining that the device is not used by a further device as a relay.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a national stage entry of, and claims priority to, PCT/EP2017/078380, filed on Nov. 7, 2017, which claims priority to European Patent Application EP 16197578.4, filed in the European Patent Office on Nov. 7, 2016, both of which are hereby incorporated in their entirety herein by reference.

FIELD OF THE INVENTION

The invention relates to a system for receiving encrypted information in a mobile communication network.

The invention further relates to a method of receiving encrypted information in a mobile communication network.

The invention also relates to a computer program product enabling a computer system to perform such a method.

BACKGROUND OF THE INVENTION

The amount of devices that is able to connect to the Internet is expected to grow enormously, especially as a result of everyday objects having network connectivity. Not only do users communicate via Internet-connected devices, but devices also send data, e.g. sensor data or maps, to other devices (machine-to-machine communication) over the Internet. It is estimated that by the year 2020 50 billion devices will be connected. Therefore, it is no surprise that industry efforts and investments are directed towards this field.

The category of mobile devices, e.g. mobile phones, tablets, wearable devices and devices embedded in vehicles, is an important category of devices that is able to connect to the Internet. In order to e.g. reduce power consumption, it is advantageous to tether certain devices, e.g. wearable devices, to other devices, e.g. smart phones. When these certain devices do not trust these other devices, but do trust the mobile communication network to which these other devices are connected, protection of data between these certain devices and the mobile communication becomes important.

WO 2016/003750 discloses techniques for securely receiving critical communication content associated with a critical communication service. A secure connection from the critical communication service to remote user equipment (UE) may be established through a relay UE in order for the remote UE to securely receive critical communication content from the critical communication service. The remote UE and the critical communication service agree on common key material that can be used to securely relay a master session key, which may be for use by only the remote UE to decrypt encrypted critical communication content sent from the critical communication service and routed through the relay UE.

A drawback of these techniques is that each service requires the setup of an own end-to-end secure tunnel. A solution in which a secure tunnel between a remote UE and the mobile communication network may be used for multiple services is preferable. 3GPP TS 33.401 (v13.4.0; System Architecture Evolution (SAE); Security architecture) specifies how to setup a secure tunnel between a UE and an eNodeB in an LTE mobile communication network. This secure tunnel can be used for multiple services. However, 3GPP TS 33.401 does not specify how the secure tunnel can be maintained or re-established between a remote UE and an eNodeB in case of a handover, e.g. when a remote UE switches to another relay UE or when a relay UE used by a remote UE connects to another eNodeB.

SUMMARY OF THE INVENTION

It is a first object of the invention to provide a system for receiving encrypted information in a mobile communication network, which helps a device which uses another device as relay maintain or re-establish a secure tunnel after a handover without requiring the device to setup a secure tunnel with each service separately.

It is a second object of the invention to provide a method of receiving encrypted information in a mobile communication network, which helps a device which uses another device as relay maintain or re-establish a secure tunnel after a handover without requiring the device to setup a secure tunnel with each service separately.

According to the invention, the first object is realized in that the system for receiving encrypted information in a mobile communication network comprises a communication interface and at least one processor configured to maintain a list of one or more devices associated with said system in a memory, wherein for each first device of said list which uses a second device of said list as a relay to said mobile communication network, said relation between said first device and said second device is recorded in said list and a security endpoint is recorded for said first device in said list, further configured to use said communication interface to receive encrypted information from a device, further configured to determine from said list whether said device is used by a further device as a relay to said mobile communication network, further configured to use said communication interface to forward said encrypted information to a security endpoint associated with said further device if said device is used by said further device as a relay to said mobile communication network and said security endpoint is not said system, and further configured to decrypt said encrypted information if said device is not used by a further device as a relay to said mobile communication network. The system may comprise, for example, a base station, e.g. an LTE eNodeB.

The inventors have recognized that by using a single security endpoint (in the mobile communication network) for devices which use another device as relay, a secure tunnel does not need to be setup for each service separately, while the secure tunnel can be maintained after a handover, because the security endpoint does not need to be the system (e.g. the eNodeB) that the other device (e.g. the relay UE) is connected to. The inventors have recognized that for devices which do not use another device as relay, it is beneficial to setup a secure tunnel between the device (e.g. UE) and the system (e.g. eNodeB) directly, e.g. in accordance with 3GPP TS 33.401. As an additional advantage, since the device that uses another device as relay does not need to be involved in maintaining or re-establishing a secure tunnel, the overhead that would be caused by such an involvement is avoided, which is especially beneficial in case of small data transfer.

Said at least one processor may be configured to decrypt said encrypted information if said device is used by a further device as a relay to said mobile communication network and said system is associated as a security endpoint with said further device. This allows the system e.g. a base station, to be the security endpoint. As long as the device does not switch to a further device that is connected to a different base station and the further device does not connect to a different base station, no forwarding may be needed.

Said at least one processor may be configured to use said communication interface to connect (i.e. to connect directly, e.g. by establishing a wireless link) to a second device which is used by a first device as a relay, said second device previously connecting to a further system, and to record in said list said further system as said security endpoint for said first device. Said at least one processor may be configured to use said communication interface to receive a notification that a first device is using or wants to use a second device connected to said system as a relay and if said first device previously used a third device as a relay and said third device was connected to a further system, to record in said list said further system as said security endpoint for said first device.

When the system and the further system are base stations, base stations can be used as security endpoints and if no security endpoint has been associated with the first device yet, the base station with which the first device is already associated may be used as security endpoint so that that encrypted communication is forwarded to this base station. The first device may be associated with another base station than the base station that the second device that it uses as a relay is connected to and recorded in the list of this other base station when the first device uses a second device as relay that previously connected to this other base station or when the first device is using or previously used a third device as relay which was connected to this other base station, for example.

Said at least one processor may be configured to use said communication interface to receive information identifying a security endpoint, e.g. a serving gateway, and to record said security endpoint for one or more devices associated with said system in said list. For example, said at least one processor may be configured to use said communication interface to receive information identifying a certain serving gateway for further devices that use a device as a relay to said mobile communication network from a mobility management function. The same serving gateway may be used for all devices that use another device as relay, for example. If the base station, e.g. eNodeB, is not used as security endpoint for devices that use another device as relay, then it does not have to perform decryption as often and may be able to serve more devices.

According to the invention, the second object is realized in that the method of receiving encrypted information in a mobile communication network comprises maintaining a list of one or more devices associated with a system of a mobile communication network, wherein for each first device of said list which uses a second device of said list as a relay to said mobile communication network, said relation between said first device and said second device is recorded in said list and a security endpoint is recorded for said first device in said list, receiving at said system encrypted information from a device, determining from said list whether said device is used by a further device as a relay to said mobile communication network, forwarding said encrypted information to a security endpoint associated with said further device if said device is used by said further device as a relay to said mobile communication network and said security endpoint is not said system, and decrypting said encrypted information if said device is not used by a further device as a relay to said mobile communication network.

Said method may further comprise decrypting said encrypted information if said device is used by a further device as a relay to said mobile communication network and said system is associated as a security endpoint with said further device.

Said method may further comprise connecting to a second device which is used by a first device as a relay, said second device previously connecting to a further system, and recording in said list said further system as said security endpoint for said first device.

Said method may further comprise receiving a notification that a first device is using or wants to use a second device connected to said system as a relay and if said first device previously used a third device as a relay and said third device was connected to a further system, recording in said list said further system as said security endpoint for said first device.

Said method may further comprise receiving information identifying a security endpoint, e.g. a serving gateway, and recording said security endpoint for one or more devices associated with said system in said list.

Said method may further comprise receiving information identifying a certain serving gateway for further devices that use a device as a relay to said mobile communication network from a mobility management function.

Moreover, a computer program for carrying out the methods described herein, as well as a non-transitory computer readable storage-medium storing the computer program are provided. A computer program may, for example, be downloaded by or uploaded to an existing device or be stored upon manufacturing of these systems.

A non-transitory computer-readable storage medium stores at least one software code portion, the software code portion, when executed or processed by a computer, being configured to perform executable operations comprising: maintaining a list of one or more devices associated with a system of a mobile communication network, wherein for each first device of said list which uses a second device of said list as a relay to said mobile communication network, said relation between said first device and said second device is recorded in said list and a security endpoint is recorded for said first device in said list, receiving at said system encrypted information from a device, determining from said list whether said device is used by a further device as a relay to said mobile communication network, forwarding said encrypted information to a security endpoint associated with said further device if said device is used by said further device as a relay to said mobile communication network and said security endpoint is not said system, and decrypting said encrypted information if said device is not used by a further device as a relay to said mobile communication network.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a device, a method or a computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit”, “module” or “system.” Functions described in this disclosure may be implemented as an algorithm executed by a processor/microprocessor of a computer. Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied, e.g., stored, thereon.

Corresponding elements in the drawings are denoted by the same reference numeral.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1shows a mobile device1(also referred to as remote UE in this description), devices7and9(also referred to as relay UEs in this description), which may relay the encrypted information for mobile device1to the mobile communication network, a first access point17and a second access point11(also referred to as eNBs in this description). Second access point11is an embodiment of a system for receiving encrypted information in a mobile communication network. First access point17may be an embodiment of the system for receiving encrypted information in a mobile communication network as well. First access point17and second access point11are nodes of the mobile communication network and are connected to the Core Network21. The Core Network21comprises a mobility management function (e.g. an LTE MME)25and a serving gateway (e.g. an LTE S-GW)23, amongst others.

The second access point11comprises a communication interface13and a processor15. The processor15is configured to maintain a list of one or more devices associated with the system in a memory14, wherein for each first device of the list which uses a second device of the list as a relay to the mobile communication network, the relation between the first device and the second device is recorded in the list and a security endpoint is recorded for the first device in the list. The processor15is further configured to use the communication interface13to receive encrypted information from the device9, determine from the list whether the device9is used by a further device, e.g. the mobile device1, as a relay to the mobile communication network, to use the communication interface13to forward the encrypted information to a security endpoint associated with the mobile device1upon determining that the device9is used by the mobile device1as a relay to the mobile communication network and the security endpoint is not the second access point11, and to decrypt the encrypted information upon determining that the device9is not used by a further device as a relay to the mobile communication network.

The mobile device1may be, for example, a wearable device like virtual reality glasses, a smart watch, augmented reality glasses, earphones, a hearing aid, a glucose sensor, a body temperature sensor, a blood pressure sensor, an insulin pump, a heart rate sensor, a GPS sensor or an accelerometer. Alternatively, the mobile device1may be, for example, a car that connects to the mobile device of the driver. The mobile device1may also be a device that the user may carry, use or interact with only occasionally and is connected to his/her mobile device only occasionally, e.g. a game console, a wireless toy, a wireless keyboard, a tablet, a screen, a beamer, or a musical instrument. The devices7and9may each be a smart phone, a laptop or a tablet, for example. The devices7and9may each have a slot for a UICC (also called a SIM card) or be provisioned with an embedded or enhanced version thereof for storage of credentials, for example.

In the embodiment shown inFIG. 1, the second access point11comprises one processor15. In an alternative embodiment, the second access point11comprises multiple processors. In the embodiment shown inFIG. 1, the memory14is part of the second access point11. In an alternative embodiment, the memory14is part of another device.

The communication interface13of the second access point11may use WiFi, Ethernet or one or more cellular communication technologies such as GPRS, CDMA, UMTS and/or LTE to communicate with the mobile device1and the further devices7and9, for example. The processor15is preferably a general-purpose processor, e.g. an Intel or an AMD processor. The processor15may comprise multiple cores, for example. The processor15may run a Unix-based or Windows operating system, for example. The second access point11may comprise other components typical for a component in a mobile communication network, e.g. a power supply and a random access memory. The memory14may comprise solid state memory, e.g. one or more Solid State Disks (SSDs) made out of Flash memory, and/or one or more hard disks, for example.

In a first embodiment of the second access point11, the processor15is configured to decrypt the encrypted information upon determining that the device9is used by the mobile device1as a relay to the mobile communication network and the second access point11is associated as a security endpoint with the mobile device1. The processor15may be configured to use the communication interface13to connect to the device9, which is used by the mobile device1as a relay, the device9previously connecting to a first access point17, and to record in the list the first access point17as the security endpoint for the mobile device1. The processor15may be configured to use the communication interface13to receive a notification that the mobile device1is using or wants to use the device9connected to the second access point11as a relay and if the mobile device1previously used a device7as a relay and the device7was connected to a first access point17, to record in the list the first access point system17as the security endpoint for the mobile device1.

In a second embodiment of the second access point11, the processor15is configured to use the communication interface13to receive information identifying a security endpoint and to record the security endpoint for one or more devices associated with the second access point11in the list. The security endpoint may comprise a serving gateway23. The processor15may be configured to use the communication interface13to receive information from a mobility management function25identifying the serving gateway23for further devices, including mobile device1, that use device9as a relay to the mobile communication network (and possibly for all further devices that use any device as a relay).

A flow diagram of a first embodiment of the method of receiving encrypted information in a mobile communication network of the invention is shown inFIG. 2. A step61comprising maintaining a list of one or more devices associated with a system of a mobile communication network, wherein for each first device of the list which uses a second device of the list as a relay to the mobile communication network, the relation between the first device and the second device is recorded in the list and a security endpoint is recorded for the first device in the list. In parallel, a step65comprises receiving at the system encrypted information from a device.

A step67comprises determining from the list whether the device is used by a further device as a relay to the mobile communication network. A step69comprises forwarding the encrypted information to a security endpoint associated with the further device upon determining that the device is used by the further device as a relay to the mobile communication network and the security endpoint is not the system. Alternatively, a step71may be performed. Step71comprises decrypting the encrypted information upon determining that the device is not used by a further device as a relay to the mobile communication network. After step69or step71has been performed, the method proceeds to step65again.

A flow diagram of a second embodiment of the method of receiving encrypted information in a mobile communication network is shown inFIG. 3. In the second embodiment, an additional step73comprises decrypting the encrypted information upon determining that the device is used by a further device as a relay to the mobile communication network and the system is associated as a security endpoint with the further device. Step73is an alternative to steps69and71. After step69, step71or step73has been performed, the method proceeds to step65again.

In the second embodiment, step61comprises a step81of connecting to a second device which is used by a first device as a relay, the second device previously connecting to a further system, and a step83of recording in the list the further system as the security endpoint for the first device. Step61further comprises a step85of receiving a notification that a first device is using or wants to use a second device connected to the system as a relay. Upon determining in decision point86that the first device previously used a third device as a relay and the third device was connected to a further system, a step87of recording in the list the further system as the security endpoint for the first device is performed.

A flow diagram of a third embodiment of the method of receiving encrypted information in a mobile communication network is shown inFIG. 4. In the third embodiment, step61comprises a step91of receiving information identifying a security endpoint and a step93of recording the security endpoint for one or more devices associated with the system in the list. The security endpoint may comprise a serving gateway, for example. In particular, step91may comprise receiving information identifying a certain serving gateway for further devices that use a device as a relay to the mobile communication network from a mobility management function.

The invention is explained in more detail with the help ofFIGS. 5 to 11. Although the provided examples are based on the LTE standard and refer to LTE components, the invention may also be used in other cellular communication networks and with similar components of those networks.

FIG. 5shows keys used for encryption between UE and eNB in LTE. RRC and NAS signaling may be encrypted using RRC and NAS keys, respectively. For user plane encryption, a KUP key may be used.

All key derivations described hereinafter are performed using the following formula (specified in 3GPP TS 33.220): derived key=HMAC-SHA-256 (Key, S).

For brevity, the formula is also denoted as “KDF (Key, S)”. The string S is built up from several components, one being an FC-value to separate the key derivations. Also, the String S often contains lengths (denoted Ln) in addition to the value itself. So, a string is constructed, for example, from the following values:FC=1P0=KPNP1=TNO-NLL0=3L1=6

The final string S is given by: S=FC∥P0∥L0∥P1∥L1=1KPN3TNO-NL6. Hereinafter, Len will refer to any Ln value and concatenation is denoted by ‘∥’ or ‘/’.

UE and eNodeB derive the user plane key KUPenc125and the RRC keys (KRRCint127and KRRCenc129) from KeNodeBin block107.

Ciphering on the link between the eNB and the UE may be used to prevent UE tracking based on cell level measurement reports, handover message mapping, or cell level identity chaining. Another reason to provide ciphering for the link between the eNB and the UE is to (optionally) protect the user plane.

The following situations are considered as hand overs:a) Switching between direct and relayed mode for the remote UEb) Handing over the relay UE and the remote UE togetherc) Hand over between relay UEs by the remote UE

Situation a) is depicted inFIG. 6as an example of the first embodiment. In step131, UE1attaches to the Core Network (CN) via eNB1in the normal way. In step133, UE1discovers a new relay (UE2) based on ProSe (Proximity Services) discovery. ProSe specifies that one of the UEs may broadcast and one of the UEs is listening and so either UE could be the broadcasting UE. Step133may involve UE2transmitting such a broadcast message or a series of messages to UE1. The broadcast message could be directed to UE1only, meaning that it could be addressed to UE1and be visible for everyone to see or that it could be protected by some encryption or obfuscation technique that allows only UE1to learn its contents. Ultimately, in case UE1and UE2are already on the same network, for example a local area network, the broadcast could be exchanged over the alternative network. Also, the broadcast message could be exchanged on an alternative radio network, such as short range networks like WiFi and Bluetooth. The method of message exchange does not matter as long as the message(s) exchanged between UE1and UE2contain(s) information that allows UE1to learn that UE2is a possible relay, by either exposing its capabilities, group memberships or by broadcasting a known identifier. In case UE1would broadcast, it would ask for a relay and UE2could simply answer by saying ‘yes’. Also note that the discovering UE may send a match report to the ProSe Function in order to determine whether the broadcast received is a relevant discovery. Alternatively, if UE1is broadcasting, UE2could reply to the broadcast and so the ‘broadcast’ (step133) and ‘connect’ (step135) arrows change direction. Proximity Services is specified in 3GPP TS 23.303 and TS 33.303.

In step135, UE1connects to UE2(it is assumed that UE2asks for relay resources from the network and obtains these relay resources from the network). In step137, UE2confirms to UE1that the connection has been established. If the direction of the arrow (i.e. of the broadcast) is reversed in step133, the direction of the arrows may need to be reversed in steps135and137as well.

In step139, UE1asks eNB1for a handover to UE2. Normally, the network is in charge of handovers, so UE may not be able to literally ask for a handover. Instead, it could send a ‘relay discovered’ message or it could send a measurement report which includes the signal from UE2as measurement. Also, a message could be used in which UE1literally sends a ‘please handover to discovered relay UE2’ message. Lastly, the handover could be initiated by the network after a ProSe match report was received from UE1or UE2. In that case, step139could be performed by the network instead.

In step141, eNB1starts a search to find out who UE2is. (1) One solution is that UE2has told UE1its radio identifier when they connected and UE1may have included the radio identifier. (2) Another option is that UE1forwards the ProSe identifier of UE2and that the eNB does a lookup of the identifier via the Core Network. (3) The eNB may also try to page UE2based on the identifier it got from UE1. (4) Yet another alternative is that UE2forwards the handover request to eNB1including its GUTI/TMSI or C-RNTI or even a bearer identifier of the bearer to be switched. In case step139is performed by the network, the eNB may still will have to make a mapping between the identifiers known in the Core Network and the identifiers known to the Core Network, or alternatively, the Core Network will have to map between the different identifiers of ProSe and EPS bearer identities in order to identify the respective eNBs that the UEs are connected to and inform the respective eNB (eNB1in this case) of the findings.

eNB1may also find out that UE2is connected to another eNB. This is described in relation toFIG. 7. In the flow diagram shown inFIG. 6, UE2is also connected to eNB1. Once eNB1has found out who UE2is, it will assign new radio resources to UE2and assign a DRB ID (Data Radio Bearer Identifier) to the bearer for those radio resources. It will also tell UE2that these radio resources are for relay of data from UE1in an RRC message in step143. The new radio bearer(s) for UE1traffic that are set up between eNB1and UE2may use ‘NULL’ encryption or may be unencrypted bearers. Also, eNB1may specify that no integrity protection is necessary. Instead, integrity protection for the RRC or UP (if used) may be provided by UE1.

UE1then switches to UE2relay in step148upon receiving a command thereto from the eNB1in step145. New keys are derived by UE1and eNB in steps146and147(in this example before switching to UE2) as follows: KeNB*=KDF(KeNB, FC∥Cell ID∥Len∥EARFCN_DL∥Len).

UE1establishes a PC-5 bearer between UE1and UE2in step149. UE2forwards traffic between the PC-5 bearer and the radio bearer for UE1. If there is no one-to-one relation between PC-5 bearers and radio bearers, UE1will have to indicate to UE2for which bearer the traffic is meant. UE2will then have to inspect each packet that it receives over the PC-5 bearer (possibly reassemble packets) and forward them to the correct radio bearer. In return, UE2will have to keep UE1informed about possible packet counters and retransmissions which may affect the counters (and therefore, the encryption).

FIG. 7shows what would change in the example ofFIG. 6when eNB1finds out in step141that UE2is connected to another eNB, eNB2in this case. eNB1now initiates a handover of UE1to eNB2in step151and optionally provides eNB2with the information that it had just obtained about the switched UE1. Next, UE1is informed in step153by eNB1that it should connect to eNB2to request the handover to UE2. In step155, UE1connects to eNB2and requests the handover to UE2. If eNB2did not receive information about who UE2is from eNB1in step151, it finds out in step157. Steps163to169correspond to steps143to149ofFIG. 6, but the role of eNB1is now assumed by eNB2.

Situation b) is depicted inFIG. 8for an example of the first embodiment. UE2is connected to eNB1, as shown inFIG. 6.

In step173, UE2signals eNB1the need for a handover. UE2may do this using measurement reports and eNB1may finally issue the command to handover. In step181, UE2and eNB2arrange the handover of UE2from eNB1to eNB2. In step183, eNB1and eNB2arrange the handover of UE1from eNB1to eNB2. UE1is not informed of the handover. In step185, eNB1informs eNB2that eNB2should forward encrypted information originating from UE1to eNB1. This allows eNB1to decrypt the encrypted information, route the decrypted information to a further network node in the Access, Core Network or further packet network in case the termination point of the information is not eNB1itself, and encrypt information received from a further node in the network that is meant to be received by UE1(now shown inFIG. 8). An example of such a further node is a Serving Gateway (S-GW), for example for user plane traffic, a mobility management function or entity for signaling and small data transfer or even another eNB, for example eNB2, for radio resource control signaling.

In step187, UE1transmits encrypted information to UE2. In step188, UE2relays the received encrypted information to eNB2, to which UE2is currently connected. In Step189, eNB2forwards the encrypted information to eNB1(the security endpoint), to which UE2was previously connected. No new keys need to be derived.

Situation c) is depicted inFIG. 9as an example of the first embodiment. Steps193to201are similar to steps133to141ofFIG. 6, but now it is UE3instead of UE2that UE1requests to use as a relay and UE3is connected to eNB2instead of to eNB1. UE1previously used UE2(which was connected to eNB1) as a relay, but UE2may now be out of range of UE1or UE2may no longer be available, e.g. switched off or in flight mode.

When eNB2finds out in step201that UE1is associated with eNB1, because UE1previously used UE2as relay and UE2was connected to eNB1, eNB2and eNB1arrange the handover of UE1to eNB2in step183. However, eNB1remains the security endpoint for UE1. In step185, eNB1informs eNB2that eNB2should forward encrypted information originating from UE1to eNB1. This allows eNB1to decrypt the encrypted information, route the decrypted information to a further network node in the Access, Core Network or further packet network in case the termination point of the information is not eNB1itself, and encrypt information received from a further node in the network that is meant to be received by UE1(not shown inFIG. 9). An example of such a further node is a Serving Gateway (S-GW), for example for user plane traffic, a mobility management function or entity for signaling and small data transfer or even another eNB, for example eNB2, for radio resource control signaling.

In step203, UE2is informed that UE1is gone so that it may clean up its resources. In step205, UE1transmits encrypted information to UE3. In step207, UE3relays the received encrypted information to eNB2, to which UE3is connected. In Step209, eNB2forwards the encrypted information to eNB1, to which UE2was connected when UE1used UE2as relay. No new keys need to be derived.

Situation a) is depicted inFIG. 10as an example of the second embodiment. In this second embodiment, a specific S-GW is used for the remote UEs. In this way, no KeNBis necessary, but a newly introduced KSGW.In this second embodiment, the user plane is encrypted and not the radio channel.

In step131, UE1attaches to the network. During the attach procedure, the MME recognizes UE1as a potential remote UE (for example, the subscription profile indicates that it is a low-power device) and so, the MME selects a specific S-GW for remote UEs. This specific S-GW should be security enhanced so that it can handle security contexts.

In step133, UE1discovers a relay, UE2, e.g. using Proximity Services. In Step135, UE1connects to UE2. In Step137, UE2confirms to UE1that the connection has been established. In step139, UE1asks eNB1for a handover to UE2. For the radio resource allocation, the eNB1finds out who UE2is in step141, so that it knows how to allocate the radio resources. At the same time, eNB1informs the MME in step211of the fact that UE1has requested to be relayed through UE2. In step213, the MME informs the S-GW of the pending hand over.

Once eNB1has found out who UE2is, it will assign new radio resources to UE2and assign a DRB ID (Data Radio Bearer Identifier) to the bearer for those radio resources. It will also tell UE2that these radio resources are for relay of data from UE1in an RRC message in step143. The new radio bearer(s) for UE1traffic that are set up between eNB1and UE2may use ‘NULL’ encryption or may be unencrypted bearers. Also, eNB1may specify that no integrity protection is necessary. Instead, integrity protection for the RRC or UP (if used) may be provided by UE1. UE1then switches to UE2in step148upon receiving a command thereto from the eNB1in step145.

The S-GW and UE1now start a security negotiation in step215, during which they agree on:Which algorithm(s) is/are used.Key derivation input parameters, which could be for example two randoms (nonces) agreed by the UE and the S-GW. If no negotiation is preferred, it could be the NAS Counter.

Alternatively, the role of the S-GW in step215could also be assumed by the MME, which may, after having derived the key, forward the key to the S-GW. Alternatively, eNB1forwards the key it has to the S-GW, no negotiation is necessary. The key may then be derived using an incrementing counter or something alike.

At the end of the security negotiation of step215, the S-GW sends back a ‘secure mode command’ to UE1to start encrypting and/or integrity protecting the user plane with the newly agreed key and algorithms. The S-GW also informs the eNB1in step216that the security context between the UE1and the S-GW has been established.

In steps217and219, the UE1and S-GW derive their respective keys. As described in relation to step215, the following key derivations may be used, for example: KSGW*=KDF(KASME, FC∥NONCE_SGW∥Len∥NONCE_UE∥Len, KSGW*=KDF(KASME, FC∥Counter∥Len) or KSGW*=KDF(KeNB, FC∥“S_GW”∥Len∥NONCE_SGW∥Len). In step221, a secure tunnel is established between the S-GW and UE1. The signaling between eNB1and UE1is done by signaling to UE2.

Situation b) is depicted inFIG. 11as an example of the second embodiment. UE2is connected to eNB1, as shown inFIG. 10.

In step231, UE1transmits encrypted information to UE2. In step233, UE2relays the received encrypted information to eNB1, to which UE2is currently connected. In Step235, eNB1forwards the encrypted information to the S-GW (the security endpoint).

In step173, UE2signals eNB1the need for a handover. UE2may do this using measurement reports and eNB1may finally issue the command to handover. In step181, UE2and eNB2arrange the handover of UE2from eNB1to eNB2. In step183, eNB1and eNB2arrange the handover of UE1from eNB1to eNB2. UE1is not informed of the handover. In step185, eNB1informs eNB2that eNB2should forward encrypted information originating from UE1to the S-GW. This allows the S-GW to decrypt the encrypted information and route the decrypted information to a further network node in the Access, Core Network or further packet network in case the termination point of the information is not S-GW itself, and encrypt information received from a further node in the network that is meant to be received by UE1(not shown inFIG. 11). An example of such a further node is a Packet Gateway, for example for user plane traffic. Another example of such a node is a MME or a node in the Access Network, such as an eNB. Even though the S-GW sits in the user plane, the embodiment includes the possibility to exchange signaling messages between nodes in the Core or Access Network and the UE1via the encrypted user plane between the UE1and the S-GW, for example by setting a flag in each message that indicates whether the message is user or control plane. The advantage of such an implementation would be that no further derivation of air interface keys may be required and no further signaling keys are required; another advantage is that the relaying UE (UE2) has only one endpoint to direct the communication of UE1to, namely the specified S-GW. Such a design would therefore be simple to implement. In the examples mentioned above, some signaling traffic goes via the user plane; similarly, it would be possible to send some user data via the control plane in case the role of the S-GW in this embodiment is assumed by a signaling entity, for example a Mobility Management Function in the Core Network or an MME in LTE.

In step237, UE1transmits encrypted information to UE2. In step239, UE2relays the received encrypted information to eNB2, to which UE2is currently connected. In Step241, eNB2forwards the encrypted information to the S-GW (the security endpoint). No new keys need to be derived.

Advantageously, this embodiment enables a situation where the UE1may temporarily be unavailable because it goes into some sort of battery saving mode. For example, in case that UE1is a smartwatch and UE2is a smartphone, the two UEs may assume that for most of the day they will remain in close proximity. As such, they may set a reasonable time interval of for example 5 minutes where they exchange a message to check that the other UE is still there. In the case that UE1would like to send data, it is only required to check that the UE2(or another associated UE) is proximity and available for data transfer. The UE1does not need to exchange further signaling with the network, for example because no mobility management is necessary, and can use the stored security context (the KSGWand other keys) to protect the data straight away.

In the telecommunications system500ofFIG. 12, three generations of networks are schematically depicted together for purposes of brevity. A more detailed description of the architecture and overview can be found in 3GPP Technical Specification TS 23.002 ‘Network Architecture’ which is included in the present application by reference in its entirety. Other types of cellular telecommunication system can alternatively or additionally be used, e.g. a 5G cellular telecommunication system.

The lower branch ofFIG. 12represents a GSM/GPRS or UMTS network.

For a GSM/GPRS network, a radio access network (RAN) system520comprises a plurality of nodes, including base stations (combination of a BSC and a BTS), not shown individually inFIG. 12. The core network system comprises a Gateway GPRS Support Node522(GGSN), a Serving GPRS Support Node521(SGSN, for GPRS) or Mobile Switching Centre (MSC, for GSM, not shown inFIG. 12) and a Home Location Register523(HLR). The HLR523contains subscription information for user devices501, e.g. mobile stations MS.

For a UMTS radio access network (UTRAN), the radio access network system520also comprises a Radio Network Controller (RNC) connected to a plurality of base stations (NodeBs), also not shown individually inFIG. 12. In the core network system, the GGSN522and the SGSN521/MSC are connected to the HLR523that contains subscription information of the user devices501, e.g. user equipment UE.

The upper branch of the telecommunications system inFIG. 12represents a next generation network, commonly indicated as Long Term Evolution (LTE) system or Evolved Packet System (EPS).

The radio access network system510(E-UTRAN), comprises base stations (evolved NodeBs, eNodeBs or eNBs), not shown individually inFIG. 12, providing cellular wireless access for a user device501, e.g. user equipment UE. The core network system comprises a PDN Gateway (P-GW)514and a Serving Gateway512(S-GW). The E-UTRAN510of the EPS is connected to the S-GW512via a packet network. The S-GW512is connected to a Home Subscriber Server HSS513and a Mobility Management Entity MME511for signalling purposes. The HSS513includes a subscription profile repository SPR for user devices501.

For GPRS, UMTS and LTE systems, the core network system is generally connected to a further packet network502, e.g. the Internet.

Further information of the general architecture of an EPS network can be found in 3GPP Technical Specification TS 23.401 ‘GPRS enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access’.

FIG. 13depicts a block diagram illustrating an exemplary data processing system that may perform the methods as described with reference toFIGS. 2 to 4andFIGS. 6 to 11.

As shown inFIG. 13, the data processing system600may include at least one processor602coupled to memory elements604through a system bus606. As such, the data processing system may store program code within memory elements604. Further, the processor602may execute the program code accessed from the memory elements604via a system bus606. In one aspect, the data processing system may be implemented as a computer that is suitable for storing and/or executing program code. It should be appreciated, however, that the data processing system600may be implemented in the form of any system including a processor and a memory that is capable of performing the functions described within this specification.

The memory elements604may include one or more physical memory devices such as, for example, local memory608and one or more bulk storage devices610. The local memory may refer to random access memory or other non-persistent memory device(s) generally used during actual execution of the program code. A bulk storage device may be implemented as a hard drive or other persistent data storage device. The processing system600may also include one or more cache memories (not shown) that provide temporary storage of at least some program code in order to reduce the number of times program code must be retrieved from the bulk storage device610during execution.

Input/output (I/O) devices depicted as an input device612and an output device614optionally can be coupled to the data processing system. Examples of input devices may include, but are not limited to, a keyboard, a pointing device such as a mouse, or the like. Examples of output devices may include, but are not limited to, a monitor or a display, speakers, or the like. Input and/or output devices may be coupled to the data processing system either directly or through intervening I/O controllers.

In an embodiment, the input and the output devices may be implemented as a combined input/output device (illustrated inFIG. 13with a dashed line surrounding the input device612and the output device614). An example of such a combined device is a touch sensitive display, also sometimes referred to as a “touch screen display” or simply “touch screen”. In such an embodiment, input to the device may be provided by a movement of a physical object, such as e.g. a stylus or a finger of a user, on or near the touch screen display.

As pictured inFIG. 13, the memory elements604may store an application618. In various embodiments, the application618may be stored in the local memory608, he one or more bulk storage devices610, or separate from the local memory and the bulk storage devices. It should be appreciated that the data processing system600may further execute an operating system (not shown inFIG. 13) that can facilitate execution of the application618. The application618, being implemented in the form of executable program code, can be executed by the data processing system600, e.g., by the processor602. Responsive to executing the application, the data processing system600may be configured to perform one or more operations or method steps described herein.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the implementations in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the present invention. The embodiments were chosen and described in order to best explain the principles and some practical applications of the present invention, and to enable others of ordinary skill in the art to understand the present invention for various embodiments with various modifications as are suited to the particular use contemplated.