WO2012037958A1

WO2012037958A1 - Security for moving relay nodes

Info

Publication number: WO2012037958A1
Application number: PCT/EP2010/063780
Authority: WO
Inventors: Guenther Horn; Wolf-Dietrich Moeller; Bernhard Raaf; Simone Redana; Richard Waldhauser
Original assignee: Nokia Siemens Networks Oy
Priority date: 2010-09-20
Filing date: 2010-09-20
Publication date: 2012-03-29

Abstract

The present invention provides methods, apparatuses, and a computer program product for providing security for moving relay nodes. The present invention discloses setting up a security association between a relay node of a relay-enhanced access network and a target base station after a proxy functionality for the relay node has been relocated from a source base station to the target base station during a handover of the relay node and suspending sending packets via the relocated proxy functionality at the target base station until setting up of the security association is completed.

Description

DESCRIPTION

Security for Moving Relay Nodes Field of the invention

The present invention relates to the field of security, enhancements of the Evolved Packet System (EPS) , in

particular, relay node architectures, as well as to mobility management and fast handover of mobile nodes.

Background of the invention

The following abbreviations are used in the description:

3GPP 3rd Generation Partnership Project

CN Core Network

DeNB Donor eNB

eNB evolved Node B

EPC Evolved Packet Core

EPS Evolved Packet System

ESP Encapsulating Security Payload

E-UTRAN Evolved UTRAN

IKE Internet Key Exchange

IKEv2 Internet Key Exchange version 2

IPsec IP security - a collection of protocols and

algorithms for IP security including key management

IPsec IPsec Security Association: A unidirectional

SA logical connection created for security purposes.

All traffic traversing a SA is provided the same security protection. The SA itself is a set of parameters to define security protection between two entities. A IPsec Security Association includes the cryptographic algorithms, the keys, the duration of the keys, and other parameters.

L3 Layer 3

MME Mobile Management Entity

MME-UE MME that is controlling a dedicated UE from EPC point of view (in contrast to a MME-RN, which controls the RN from EPC point of view)

NB Node B (Base station) , in the figures for

solution 3 it also stand for DeNB

PDN Packet Data Network

P-GW PDN Gateway

P-GW-RN Packet Data Network Gateway which is assigned to provide services for a RN

RN Relay Node

RNA RN security anchor

SI Logical interface between eNB and MME/S-GW

Sll Reference point between MME and Serving GW

SI -MME Reference point for the control plane protocol between E-UTRAN and MME

si-u Reference point between E-UTRAN and Serving GW for the per bearer user plane tunnelling and inter eNodeB path switching during handover.

SEG Security Gateway

S-GW Serving Gateway

S-RNA Communication protocol between RNA and DeNB

TR Technical Report

UE User Equipment

Un Modified version of the E-UTRA radio interface that supports relaying by having a Relay Node (RN) wirelessly connect via Un to an eNB serving the RN, called Donor eNB (DeNB)

UTRAN Universal Terrestrial Radio Access Network

Uu E-UTRA radio interface

X2 Logical interface between two eNBs (note that a

DeNB is an eNB, too)

X2-C X2-Control plane

X2-U X2-User plane Currently, the 3^r Generation Partnership Project (3GPP) is in the process of defining an enhancement to Evolved Packet System (EPS) that introduces so-called Relay Nodes (RNs) into the EPS architecture. An EPS architecture including RNs is also called a (EPS) Relay Node Architecture. A particular EPS Relay Node Architecture has been selected by 3GPP for further elaboration. This selected architecture is documented in 3GPP TR 36.806 (vlO.0.0), where it is called "alternative 2". An overview of this architecture taken from TS 36.300 is

depicted in Fig. 1, which is explained in the following.

Fig. 1 shows an overview of an overall Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Architecture supporting RNs. An RN is a base station that relays traffic between a User Equipment (UE) and another base station, the donor base station. A base station in EPS is called eNB, therefore the donor base station is abbreviated as DeNB . Both the Uu interface between the UE and the RN and the Un

interface between the RN and the DeNB are radio interfaces. Uu and Un are very similar. Uu between a UE and an eNB in an EPS architecture without relay nodes is identical to Uu between a UE and an RN, i.e. the UE is not aware of the presence of the RN.

An RN has two faces: towards the UE it acts as an eNB; and towards the DeNB it acts like a UE . The UE characteristics of an RN come into play in particular when the connections over the radio interface Un are established during the so-called RN start-up phase, cf. R2-102085 (3GPP TSG-RAN WG2 Meeting #69_bis; 12 - 16 April 2010 in Beijing, China)

The RN attaches to the network, and the radio bearers on Un between the RN and its DeNB are established in the same way in which a UE attaches to the network and establishes radio bearers over the Uu interface between the UE and an eNB. In alternative 2 of 3GPP TR 36.806, the RN is hidden by the S1/X2 proxy at the DeNB so it appears to the Core Network (CN) as if it was a sector of the DeNB.

In 3GPP Rel-10, a relay node is assumed to be stationary while in operation. In future releases, however, a relay node may be moving, i.e. it may change its point of attachment to the network, the Donor eNB, while in operation. Only as an illustrating example and not considered to be limiting, it is noted that a possible use case for such a moving RN could be an RN mounted on e.g. a high-speed train enabling efficient communication over EPS for passengers.

The introduction of relay nodes into the EPS architecture also creates new security challenges. The current state of the security discussion in 3GPP can be found from the

document S3-100896, 3GPP TSG-SA3 (Security) SA3#60, 28-2 June/July 2010, Montreal, Canada. This document contains ten different proposals for security architecture for stationary relay nodes. Most of these proposals assume the use of IPsec to protect the integrity of SI and X2 signalling messages sent over the Un interface between the RN and the DeNB.

The use of IPsec between the RN and the DeNB, as described above, creates the following problem: When a relay nodes moves, its point of attachment may change, i.e. it may be handed over from a source DeNB to a target DeNB. When this happens, the old IPsec security association (SA) between the RN and the source DeNB cannot be used any more as it is tied to the endpoint "source DeNB". But the SI and X2 signalling messages that need to be protected by IPsec are now being sent between the RN and the target DeNB, and setting up a new IPsec SA between the RN and the target DeNB as part of the handover is time-consuming. It may even be the case, e.g. for an RN on a very fast moving train, that the time for setting up new IPsec SAs takes a significant portion, or is even longer than the time available for performing a handover or even the time during which the RN is connected to the target DeNB before handing over to the next DeNB. This is particularly an issue when the train travels with comparatively high speed through an area with comparatively small inter site distance. This may happen when the train runs through suburban areas, still at high speed but not yet far out in the countryside or when it runs (typically with somewhat lower speed) through an urban area, the latter scenario may also be relevant to ordinary "non-high speed" trains .

The problem to be solved hence is to find performance- optimized ways to satisfy the following two requirements:

- allowing fast handovers of relay nodes between Donor

eNBs while

- ensuring that SI and X2 signalling messages are always protected while being sent over the Un interface.

In the general setting, the problem is solved by running the IKE (RFC 2409) or IKEv2 (RFC 4306) protocols between the desired IPsec endpoints. These protocols are well-known and have been specifically designed for the purpose of setting up IPsec SAs . However, their performance limitations, which are to a great extent implementation-dependent plus a double message exchange (handshakes) and the associated delay on the links between the nodes, in the present case the wireless Un and the X2 between source and target DeNB, are also well- known. Consequently, an optimization for setting up IPsec SAs was developed for the case that one IPsec endpoint was moving and changing its IP address while the other endpoint remained fixed. This optimization is known by the name of MOBIKE (RFC 4555) . MOBIKE alleviates the performance problems as it uses only one handshake and reduced processing, but does not completely eliminate them.

Summary of the Invention

According to the present invention, there are provided methods, apparatuses and a computer program product for providing security for moving relay nodes. According to an aspect of the invention there is provided a method comprising:

setting up a security association between a relay node of a relay-enhanced access network and a target base station after a proxy functionality for the relay node has been relocated from a source base station to the target base station during a handover of the relay node and

suspending sending packets via the relocated proxy

functionality at the target base station until setting up of the security association is completed.

According to another aspect of the invention there is provided a method comprising:

relaying, during setting up a security association between a relay node of a relay-enhanced access network and a target base station after relocating a proxy functionality for the relay node from a source base station to the target base station during a handover of the relay node, packets from and to the target base station through the source base station as a temporary security server until setting up of the security association between the relay node and the target base station is completed.

According to further refinements of the invention as defined under the above aspects,

- relaying packets to the target base station comprises recognizing, at the source base station, that the packets are destined to a relocated proxy functionality, and

forwarding the packets to the target base station utilizing an existing, or a newly established, security association between the source base station and the target base station;

- relaying packets from the target base station comprises sending, by the target base station, the packets via an existing, or newly established, security association between the source base station and the target base station, recognizing, at the source base station, that the packets are destined to the relay node, and

forwarding the packets to the relay node utilizing an existing security association between the source base station and the relay node.

setting up a security association between a relay node of a relay-enhanced access network and a target base station during a handover of the relay node,

relaying packets from and to the target base station through a source base station as a security server until setting up of the security association between the relay node and the target base station is completed, and

after setting up of the security association between the relay node and the target base station is completed,

relocating a proxy functionality for the relay node from the source base station to the target base station.

- when a plurality of handovers for the relay node to a plurality of base stations are performed, packets to the relay node are relayed through the source base station via each of the plurality of base stations that handed over the relay node;

- each of the plurality of base stations to which the relay node is handed over initiates setup of a security association with the relay node;

- packets to the relay node are relayed from the base station that has set up a security association with the relay node via the base station that has started setup of the security association at the latest with at least some of the other intermediate base stations being not involved in relaying the packets ; - a base station to which the relay node is handed over initiates setup of the security association only if a setup of a security association of one of the base stations that previously handed over the relay node is completed;

- the base station to which the relay node is handed over stops setup of the security association if the setup is not completed when the base station hands over the relay node to another base station;

- when a base station has completed setup of the security association, the previous base station having the security association is discarded.

routing packets from and to a relay node via a security anchor, during and after setting up a secure connection between the relay node of a relay-enhanced access network and a target base station before and after relocating a proxy functionality for the relay node from a source base station to the target base station during a handover of the relay node, wherein

the security anchor verifies the security of the packets by having a security association with the relay node.

- the security anchor relays the packets to and from the source base station before handover and to and from the target base station after handover;

- packets from and to the base station are relayed through the security anchor using a communication protocol between the security anchor and the base station;

- the security association between relay node and security anchor via different base stations is updated by usage of a protocol according to MOBIKE;

- the method is operable at or by a relay node, and said relay node may be part of an evolved radio access network in accordance with LTE and/or LTE-Advanced specifications; - the method is operable at or by a donor base station controlling the relay node, and said donor base station may be part of an evolved radio access network in accordance with LTE and/or LTE-Advanced specifications;

- the method is operable at or by a relay node security anchor, and said relay node security anchor may be part of an evolved radio access network in accordance with LTE and/or LTE-Advanced specifications.

According to a still further aspect of the invention there is provided a computer program product including a program for a processing device, comprising software code portions for performing the steps of the methods as defined above when the program is run on the processing device.

According to a still further aspect of the invention there is provided a computer program product as defined above, wherein the computer program product comprises a computer-readable medium on which the software code portions are stored.

According to a still further aspect of the invention there is provided a computer program product as defined above, wherein the program is directly loadable into an internal memory of the processing device.

According to another aspect of the invention there is

provided an apparatus comprising:

a processor configured to be engaged in the set up of a security association between the apparatus and a target base station after relocating a proxy functionality for the apparatus from a source base station to the target base station during a handover of the apparatus and to suspend sending packets via the relocated proxy functionality at the target base station until the setting up of the security association is completed.

According to another aspect of the invention there is

provided an apparatus comprising: a processor configured to relay, after a proxy

functionality for a relay node of a relay-enhanced access network has been relocated from the apparatus to a target base station during a handover of the relay node, packets from and to a target base station through the apparatus as a temporary security server until setting up of a security association between the relay node and the target base station is completed.

- the processor is configured to

recognize that the packets are destined to a relocated proxy functionality, and

forward the packets to the target base station utilizing an existing, or a newly established, security association between the apparatus and the target base station;

- the processor is configured to

receive the packets from the target based station via an existing, or a newly established, security association between the apparatus and the target base station,

recognize that the packets are destined to the relay node, and

forward the packets to the relay node utilizing an existing security association between the apparatus and the relay node;

According to another aspect of the invention there is provided an apparatus comprising:

a processor configured to be engaged in the set up of a security association between a relay node of a relay-enhanced access network and the apparatus during a handover of the relay node,

receive and send packets from and to the relay node through a source base station as a security server until setting up of a security association between the relay node and the

apparatus during a handover of the relay node is completed, and relocate, after setting up of a security association between the relay node and the apparatus is completed, a proxy functionality for the relay node from the source base station to the apparatus .

a processor configured to verify security of packets sent to and from the relay node via a security association between the apparatus and the relay node, and

to relay the packets from and to a base station.

- the processor is configured to relay the packets from and to the base station using a communication protocol between the apparatus and the target base station;

- a communication protocol between the apparatus and the relay node uses MOBIKE;

- the apparatus is operable as or at a relay node, and said relay node may be part of an evolved radio access network in accordance with LTE and/or LTE-Advanced specifications;

- the apparatus is operable as or at a donor base station controlling the relay node, and said donor base station may be part of an evolved radio access network in accordance with LTE and/or LTE-Advanced specifications;

- the apparatus is operable as or at a relay node security anchor, RNA, and said relay node security anchor may be part of an evolved radio access network in accordance with LTE and/or LTE-Advanced specifications.

a processor means for being engaged in the set up of a security association between the apparatus and a target base station after relocating a proxy functionality for the apparatus from a source base station to the target base station during a handover of the apparatus and suspending sending packets via the relocated proxy functionality at the target base station until the setting up of the security association is completed.

a processor means for relaying, after a proxy

a processor means for being engaged in the set up of a security association between a relay node of a relay-enhanced access network and the apparatus during a handover of the relay node,

receiving and sending packets from and to the relay node through a source base station as a security server until setting up of a security association between the relay node and the apparatus during a handover of the relay node is completed, and

relocating, after setting up of a security association between the relay node and the apparatus is completed, a proxy functionality for the relay node from the source base station to the apparatus.

a processor means for verifying security of packets sent to and from the relay node via a security association between the apparatus and the relay node, and

relaying the packets from and to a base station. Brief Description of the Drawings

These and other objects, features, details and advantages will become more fully apparent from the following detailed description of embodiments of the present invention which is to be taken in conjunction with the appended drawings, in which :

Fig. 1 shows an overview of an overall Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Architecture supporting RNs .

Fig. 2 shows a schematic diagram of SI and user connections of a relay node before and after a handover based on a RN handover mechanism.

Fig. 3 shows an overview of a RN handover mechanism.

Fig. 4 shows an overview of RN handover with proxy relocation and IKEv2 set up according to exemplary embodiments of the present invention.

Fig. 5 shows an overview of forwarding of S1/X2 signalling traffic at the source DeNB according to exemplary embodiments of the present invention.

Fig. 6 is a time chart showing a plurality of handovers of a fast relay node according to exemplary embodiments of the present invention.

Fig. 7 is a time chart showing a plurality of handovers of a fast relay node with hop optimization according to exemplary embodiments of the present invention.

Fig. 8 is a time chart showing a plurality of handovers of a fast relay node with leapfrogging according to exemplary embodiments of the present invention. Fig. 9 is a time chart showing a plurality of handovers of a fast relay node with leapfrogging and early node termination according to exemplary embodiments of the present invention.

Fig. 10 is a time chart showing a plurality of handovers of a fast relay node with leapfrogging, early node termination and hop optimization according to exemplary embodiments of the present invention.

Fig. 11 is a time chart showing a plurality of handovers of a fast relay node with leapfrogging and early IPsec setup according to exemplary embodiments of the present invention.

Fig. 12 is a time chart showing a plurality of handovers of a fast relay node with leapfrogging, early node termination, hop optimization and early IPsec setup according to exemplary embodiments of the present invention.

Fig. 13 shows a schematic block diagram of an apparatus according to exemplary embodiments of the present invention.

Fig. 14 shows a schematic block diagram of an apparatus according to exemplary embodiments of the present invention.

Fig. 15 shows a schematic block diagram of an apparatus according to exemplary embodiments of the present invention.

Detailed Description

In the following, embodiments of the present invention are described by referring to general and specific examples of the embodiments. It is to be understood, however, that the description is given by way of example only, and that the described embodiments are by no means to be understood as limiting the present invention thereto.

The invention provides various solutions to the problem described above. Each of these solutions has different performance characteristics and may be, hence, better suited for a particular deployment scenario than other solutions. For all solutions, it is assumed that IPsec SAs are set up by means of IKEv2. For another solution according to embodiment 5 to be described later, it is assumed that they may be modified by MOBIKE. The solutions differ regarding the endpoints of the IPsec SAs, and the points in time when the IPsec SAs are set up and put to use.

There are several options how this can be done, and these options are described hereinafter as embodiments 1 to 5.

Further details on each solution and further refinements are discussed later.

In the simplest solution the processing of the HO procedure is interrupted until the new IPsec SA between the RN and the DeNB that is serving the RN is established and ready to securely transfer the S1/X2 traffic (embodiment 1) . However, this solution may include a heavy performance penalty because the time required for an RN handover is increased by the time required for the two IKEv2 handshakes and the IKEv2

processing time.

This disadvantage can be avoided by more elaborated solutions that are based on the following two principles.

The first principle is to introduce a so called ^xsecurity server' which is responsible to select already existing IPsec SA(s) until the new direct IPsec SA between the RN an the DeNB is established. This principle has no impact on the HO procedures itself. A security server is aware of the existing IPsec SA(s) that can be used until the new direct SA is available .

This principle can be applied using either a temporary security server or a permanent security server, i.e. a security anchor. The temporary security server can be applied according to embodiments 2 or 3 as described below, where typically the source DeNB is acting a security server. The permanent security server is described in more detail in embodiments 4 and 5. These sections also discuss specific protocol enhancements that can be used to realize the

communication with the security server, some of which may be applicable to embodiment 2 as well.

The second principle is to delay the path switching until the new direct IPsec SA is available. In contrast to the first principle, this has impact on the HO procedures because the path switch is delayed until the new IPsec SA is established (embodiment 3) .

According to aspects of the present invention there are provided further improvements especially when the RN is moving very quickly. This leads to the so called

'leapfrogging' variants described below in

"Variants/extensions to embodiment 2 and embodiment 3".

Basically this improvement considers the case of many

subsequent handovers and allows for shortcuts when the IPsec SA of handovers that occurred later in the chain of DeNB that were visited by the RN are established earlier than the IPsec SA of DeNB(s) that were contacted earlier by the moving RN. In that case the path switch may not consider DeNBs that have not yet managed to establish the required IPsec SA and may immediately connect the EPC to a DeNB further down in the chain of visited DeNBs that have already managed to establish said SA.

More details on each of these solutions are described in the following .

First, a handover of moving RNs from one DeNB to another one using the selected relay architecture is described with reference to Figs. 2 and 3.

Fig. 2 shows a schematic diagram of SI and user connections of a relay node before and after a handover based on a RN handover mechanism. The L3 connectivity prior to RN handover is denoted by a pipe shape on the left between the UE-part (IP-1) of the RN and the proxy of the source base station DeNBl, and the L3 connectivity after RN handover (and after proxy relocation) is denoted by a pipe shape on the right between the UE-part (IP-2) of the RN and the proxy of the target base station DeNB2.

After RN handover the proxy of the RN needs to be relocated from the source DeNB to the target DeNB. The P-GW switches to the target DeNB with the relocation of all bearers of the relayed UEs. The following three steps are considered:

In a first step, the RN hands over from the source DeNB to the target DeNB with standard UE handover procedure, traffic however is still routed via the old L3 and S I connection with the source DeNB (left pipe in Fig. 2) .

In a second step, the RN sets up a new L3 and S I connection to target DeNB (right pipe in Fig. 2) . During this step, the old L3 and S I connection with the source DeNB is kept and at the same time a L3 and S I connection with the target DeNB is set up.

In a third step, a path switch is performed from the old S I connection with the new S I connection so the DL and UL data are only between the CN and target DeNB and the old L3 and S I connection with the source DeNB can be dropped.

Fig. 3 shows an overview of a RN handover mechanism, in which the three steps are illustrated in relation to network elements being involved therein as well as the resulting situations at the end of the three steps, respectively.

As shown in Fig. 3, the first step may comprise a UE handover according to LTE Release 8 procedures being modified with an aspect of context transfer of UEs being relayed by the relay node to be handed over. In this regard, the source DeNB may send a handover request ("HO Request" message) to the target DeNB, which handover requests includes not only the context of the RN, but also all the contexts of the relayed UEs. When the target DeNB receives this modified "HO Request" message, it may store the contexts of the RN and all the UEs of this RN for subsequent usage for proxy relocation.

As shown in Fig. 3, the second step may comprise an

initiation of L3 and SI connections to the target base station, and the third step may comprise a relocation

operation including relocating proxy (S-/P-GW) functionality of the relay node as well as correspondingly switching data paths using the relocated proxy (S-/P-GW) functionality of the relay node. In this regard, when the RN accesses the target DeNB, the old L3 and SI connections with the source DeNB may be temporarily kept. At the same time, the RN may initiate the setup of new L3 and SI connections through the target DeNB, which will be used to carry RN' s associated UEs later (wherein this assumes that there is the possibility of having multiple SI connections between a RN and several

DeNBs . This basically results in that a L3 connection between the RN and the source DeNB is transparently routed through the target DeNB.

Once the new L3 and SI connections to the target DeNB are set up, the RN may switch all its UEs from the old SI connection to the new SI connection, which may for example be

accomplished by a standardized path switch procedure, e.g. by sending a Path Switch Request to the new proxy at the target DeNB. By using the stored contexts of the RN' s associated UEs, which had already been provided by the source DeNB in the preceding first step, the new proxy in the target DeNB may further forward this Path Switch Request to the UE-MME to ask the UE-MME to switch all the relayed UEs from old the SI connection with the source DeNB to the new SI connection with the target DeNB. This basically results in that a L3

connection between the RN and the target DeNB is established. That is, the old SI connection with the source DeNB may be relocated to the new SI connection with the target DeNB (by way of a corresponding relocation of proxy (S-/ P-GW) functionality of the relay node) , while at the same time all the (active) bearers of all the relayed UEs may be kept intact. Stated in other words, in addition to the S-GW, the P-GW may be relocated and switched to the target DeNB, together with the relocation and switching of all the bearers of the relayed UEs, in such a way that all the active bearers of the relayed UEs may stay active.

As shown in Fig. 3, the third step may comprise a

termination/disconnection of the old SI and L3 connections with the source base station. In this regard, once all the paths of all associated UEs are switched to the new path via the relocated proxy in the target DeNB, all the contexts and resources associated with the RN and its UEs may be released in the source DeNB, and the old SI connections may also be released .

As regards the relation between the actual RN handover process and the proxy relocation process, it is noted that the proxy relocation is not necessarily to be performed along with (during) the RN handover as such. While such a combined (simultaneous) execution of both processes may be especially beneficial in terms of an optimization feature, the RN handover as such may still be executed without proxy

relocation. That is, albeit leading to un-optimized SI and X2 paths after the RN handover process as such, the proxy relocation may be performed only after (completion of) the RN handover process. This may for example be beneficial in a case where the RN is moving fast and will be handed over from DeNBl to DeNB2 and then quickly afterwards to DeNB3, in which case it would make more sense (in terms of efficiency

considerations) to perform only the handover process without proxy relocation between DeNBl and DeNB2 and then between DeNB2 and DeNB3, and to perform the proxy relocation only once between DeNBl and DeNB3. Such logical/temporal separation of relocation and handover processes may for example be realized via timers, where the relocation process is started after a certain timer expires after (completion of) the handover process. A combined (simultaneous) execution of both processes may thus be considered as a specific realization where a timer value is 0.

First embodiment:

In the following, a first embodiment of the present invention will be described.

According to the first embodiment, new IPsec SA is set up immediately after proxy relocation, but before sending user plane packets via the new proxy located at the target DeNB, i.e. before the path switch. This is also shown in Fig. 4, which shows an overview of RN handover with proxy relocation and IKEv2 setup.

This is the simplest solution, but its disadvantage is that it may include a heavy performance penalty as the time required for an RN handover is increased by the time required for the two IKEv2 handshakes and the IKEv2 processing time.

Basically two principles can be applied to avoid the

disadvantage of the simple solution 1.

The first principle is to introduce a so called ^xsecurity server' which is responsible to select already existing IPsec SA(s) until the new direct IPsec SA between the RN an the DeNB is established (embodiment 2, security server is active only temporarily, or embodiments 4 and 5, security server is active permanently, to be described later) .

The second principle is to delay sending the path switching message depending on the availability of the new direct IPsec SA (embodiment 3) . Second embodiment:

The second embodiment applies the first principle as

mentioned above. The new IPsec SA may not be set up during, or even not set up until or some time after the proxy

relocation. According to embodiment 2 of the invention the S1/X2 signalling traffic experiences no interruption thereof because the SI / X2 signalling traffic between target DeNB and RN uses already existing or newly set up IPsec SAs as long as the newly required IPsec SA hasn't yet been

established. However, this requires S1/X2 message forwarding via the source DeNB.

As long as the new IPsec SA has not yet been established, the IP packets carrying SI and X2 signalling traffic are using the old, still existing, IPsec SAs and are routed via the target DeNB to the source DeNB, and are processed there. This processing algorithm at the source DeNB must recognize that these are S1/X2 messages destined to already relocated proxy functionality and forwards corresponding messages to the target DeNB. Basically there will be a detour of these messages via the source DeNB as a direct communication between RN and target DeNB would lack proper security. This forwarding utilizes an already existing IPsec SA between the source and target DeNBs . This IPsec SA is typically already set up when the X2 links are established between neighbouring eNBs . If no existing IPsec SA can be used between source and target DeNBs, e.g. when no X2 interface is configured between these DeNBs and the handover is performed using the SI interface, then a new IPsec SA between the target and source DeNBs needs to be established before transferring information directly between source and target DeNB over transport network. Alternatively, if the connection between source and target DeNB is completely within a secure operator network, then no additional IPsec SA is necessary. A processing algorithm at the target DeNB must be capable of receiving IP packets carrying S1/X2 messages via this existing or newly established IPsec SA until the new IPsec SA between target DeNB and RN is set up. For the other direction the processing algorithm that is located at the target DeNB will have to send IP packets carrying S1/X2 messages using the existing or newly established IPsec SA between target and source DeNB. The processing algorithm in the source DeNB in this case must recognize that it needs to forward these IP packets by using the existing IPsec SA between source DeNB and RN. IP packets using the IPsec SA between source DeNB and RN will be routed via the target DeNB, because the RN is connected to the target DeNB. This is shown in Fig. 5, for example.

The second embodiment has some similarities with the fourth embodiment described later, but in the latter a permanent security anchor is introduced while in the former the

previous DeNB provides that functionality. Therefore aspects and details of the fourth embodiment may also be applied to the second embodiment.

Third embodiment:

The third embodiment applies the second principle (delayed path switch), as mentioned above. The routing of SI / X2 traffic via some old proxy is continued until the IPsec SA set up to a new proxy is completed and only then the proxy relocation (path switch) is performed. Compared to the solutions applying the first principle (security server) , the old proxy is still in charge of handling communication with the RN, just the physical path is routed via the new DeNB, while according to the first principle the new proxy may already be in charge, but only due to the missing new direct IPsec SA, the S1/X2 messages are routed in a detour via the old proxy to take care of security.

Variants/extensions to embodiment 2 and embodiment 3:

The following variants are applicable both to embodiments 2 and 3, but are only described explicitly for one embodiment for simplicity. While the new IPsec SA is being set up, several RN handovers may have occurred in the meantime, and the new IPsec SA endpoint is located at a new proxy, but not necessarily the proxy residing on the target DeNB of the latest RN handover. This addresses the problem with embodiment 2 that the time required for IPsec SA set up may be higher than the time between two consecutive RN handovers. This is illustrated in Fig. 6.

Fig. 6 illustrates several DeNBs (named "NB" in the figure) and an RN. Time is running from top to bottom, time stamps (in arbitrary units) are displayed at the left. The RN travels from NB1 via the NBs 2, 3, 4 to NB5 and hands over to the next DeNB at times 2, 3, 4 and 6 respectively. A black circle indicates the DeNB that has the IPsec SA already set up and is serving the S1/X2 control traffic. Black rings indicate an DeNB when the RN hands over to it, and when the IPsec SA set up starts. Downlink traffic is indicated by horizontal arrows, arrow-heads indicate nodes that are involved in the traffic. Uplink traffic is not shown for simplicity, it can take the same route, or possibly take some shortcuts, forking off to the core nodes more directly. It is noted that when the same principles and similar procedures are used as for ordinary UE HO then the U-Plane traffic can take different routes for DL and UL until the path switch has been performed (path switch in the S-GW is always performed for the DL) . The UL U-Plane traffic can use already a more direct path. For Example a Packet that is destined to the S- GW can be directly forwarded to it from the (temporary) security server in the source DeNB, rather than being

forwarded via the target DeNB. More generally the last node to operate on such a packet can forward it directly to the S- GW, even if in the DL the S-GW does route packets on a less optimal path, e.g. it may switch the path later or earlier. The control traffic always runs between the IPsec SA endpoint of the currently active DeNB and the RN, the other end point. At time 2 the RN makes its first HO to DeNB2, but traffic is still routed via DeNBl until IPsec has been set up with DeNB2 which will however only happen at time 5. In the meantime however, the RN already does a handover to DeNB3 at time 3 and to DeNB 4 at time 4. Still the traffic flows from DeNBl via DeNB2, DeNB3 and DeNB4. So at time 4 we have not only DeNBl serving as one IPsec endpoint and the RN as the other endpoint, but also two intermediate nodes DeNB2 and DeNB3 that forward traffic, typically via the X2 interface.

At time 5 eventually IPsec has been set up at DeNB2,

indicated by the solid black circle, and the path can be switched to that DeNB (from the serving GW) . Then the traffic flows from DeNB2 via DeNB3 and DeNB4. At this time the DeNBl can terminate its service for the RN, indicated by the star. DeNB 1 was involved from time 1 to time 5 indicated by the thick perpendicular line.

At time 6 the RN hands over to DeNB 5 and at time 8 IPsec has been set up at DeNB3, DeNB 2 can terminate its service and the traffic flows from DeNB3 via DeNB4 and DeNB5. If the RN continues to move along, there may always be a chain of DeNBs serving it, where the "oldest" DeNB is the one IPsec

endpoint, and then there is a chain of intermediate nodes which have not yet completed the IPsec setup and which until then can only forward traffic to the current, newest DeNB with which the RN is connected via Un . If the RN moves faster from one DeNB to the next than IPsec can be set up, the forwarding chain gets longer and longer.

Whenever an IPsec SA set up has been successful, the RN tears down the old IPsec SA so that it is clear for the security policy which SA to use for the uplink control messages.

Addition to embodiment 3:

The above solution may result in a chain of DeNBs between the DeNB, where the moving RN currently has its radio connection to, and the DeNB hosting the S1/X2 proxy. If such a situation is expected more often, or if the latency introduced by this long chain is a problem (e.g. if the SI traffic is routed via X2 connections, which are not directly between DeNBs, but go via security gateways (SEGs) and CN) , then the following could be applied: An indication of the address of the DeNB hosting the proxy is always included in the messages sent from this DeNB to the RN, and also a counter of "hops", which is incremented on each DeNB in the chain. The DeNB nearest to the RN may then decide to send the next messages from RN to the proxy directly to the DeNB hosting the proxy if there is a direct connection available or may be established, e.g. by establishing an X2 connection. Packets in the other direction can then follow the same connection. Then also the DeNB hosting the proxy may send the next messages directly to the DeNB nearest to the RN. A mechanism to tear down the long chain (if needed) could be that a special message is sent by the DeNB hosting the proxy along the "old" chain telling the DeNBs in between that chain are no longer necessary. This may be the case when IPsec has been established with a "younger" DeNB. As this DeNB is not necessarily the currently serving DeNB because the RN may already have been handed over

further, at this time another direct X2 link may need to be set up, or, if this is not possible, the packets have to be forwarded again via multiple hops, using at least some of the hops that have been optimized away before. Consequently these "legacy" hops need to be memorized (either by the RN or the DeNB serving the RN directly) so they can be re-activated again if needed. This hop optimization is shown in Fig. 7. If there are no direct connections available between more distant nodes then it may not be possible to optimize away all the intermediate hops but at least some of the

intermediate hops. For example, if at time 4 no direct connection is available between DeNB 1 and DeNB 4, then DeNB 3 may need to remain in the chain, but at least DeNB 2 can be taken out of the chain. As shown in Fig. 7, at time 3 the RN is directly served by DeNB 3, but DeNB2 is taken out of the chain so that packets are forwarded directly from DeNBl to DeNB 3. Similarly a direct link is utilized from DeNBl to DeNB4 as indicated by the arrow heads in Fig. 7 at time 4. At time 5 another direct link is used from DeNB2 to DeNB4. The advantage of this approach is that only a single hop is required at any one time, however the intermediate nodes are still involved due to the setup of IPsec.

If the IPsec SA set up lags behind consistently, we could leapfrog one proxy e.g. go from the second (DeNB 2) straight to the fourth (DeNB 4) . This should solve problems to have too many dangling pipes and too many nodes involved which at least need to be memorized by RN or another DeNB.

This approach is visualized in Fig. 8.

Contrary to the previous cases, if a new DeNB appears, an IPsec setup is not immediately started, but initially the new DeNB just forwards data from the previous proxy which has already an IPsec SA. This is visualized by the white rings in Fig. 8. According to Fig. 8, at any time only a single pending IPsec setup is done, with DeNB 2 from time 2 to 5 and with DeNB 4 from Time 5 to 9. DeNB 3 is never getting an IPsec configured and therefore is only forwarding data, either directly to the RN (at time 3) or towards another DeNB in the chain (from time 4 to 9) . Eventually DeNB 3 can be taken out of the chain at time 9, when also DeNB2 isn't needed any more because DeNB 4 takes over to serve as one IPsec endpoint. The advantage of this approach is that only a single IPsec setup is running concurrently and some DeNBs don't need to run a setup at all, consequently the processing load is reduced and the RN and DeNBs need less storage to keep the corresponding context. Further more, less messages to setup IPsec e.g. the IKE messages need to be sent and thus less capacity is consumed for this task both on the RN air interface and on the X2 interfaces. A further advantage is that no matter how fast the RN moves, the chain of forwarding RNs does not get longer and longer because the next IPsec node is always selected to be the DeNB that directly serves the RN and thus the end of the chain can catch up multiple hops (in Figure 8 from DeNB 2 to DeNB 4) .

This scheme gets even more convincing when combined with at least partial hop optimization i.e. if nodes that will never mature to become IPsec endpoints are discarded from the forwarding chain immediately, here called early node

termination, as shown in Fig. 9.

This procedure is similar to the previous case, but at time 4 it is becoming apparent that DeNB 3 will not be selected to become IPsec endpoint, because node 4 is already established (depending on when DeNB2 finishes the IPsec setup, even DeNB5 could be the next but at time 4 it is already obvious that DeNB 3 will not be eligible) . Then DeNB3 is immediately discarded and taken out of the forwarding chain, the hops from DeNB 2 via DeNB3 to DeNB4 are replaced by a direct connection from DeNB2 to DeNB4. DeNB3 will not be needed any more and can be completely forgotten (i.e. no need to store any information in DeNB 3 regarding the RN or in any of the other nodes regarding DeNB3) . This saves storage and also complexity accordingly and avoids necessity for dynamic storage handling. It should be noted that with this approach at any time there are at most 3 nodes involved:

1) The node that currently serves as an IPsec endpoint;

2) A node that is currently setting up IPsec;

3) The node that is currently serving the RN via Un .

In this way, there is always a simple setup with at most three nodes. Some nodes are only involved for a short time like DeNB 3 in this example, which is only involved from time 3 to 4 as indicated by the short thick perpendicular line. Still there are up to two hops in the forwarding chain between these three DeNBs . This can be optimized to two hops by combining the approach with hop optimization as introduced earlier. This is visualized in Fig. 10.

Here the data are always directly forwarded from the IPsec endpoint to the DeNB currently serving the RN. Intermediate nodes are either completely forgotten as in the previous example (like DeN3 after time 4), or are bypassed i.e. the DeNB that is just running the IPsec setup but is no longer serving the RN directly is bypassed as well. Contrary to the case where hop optimization is applied alone, only that single node needs to be remembered keeping storage

requirements low.

There is one disadvantage involved with the leapfrogging approach, that is the IPsec setup is not started immediately when the RN hands over to a new DeNB, but only when the previous IPsec setup is completed. Then of course the new IPsec setup will be completed later as well and forwarding via the old IPsec endpoint needs to be done for a longer time. This is visible in the above figure, where DeNB 4 only starts serving as an IPsec endpoint from time 9 because the configuration was only begun at time 5, compared to the case without leapfrogging, where the DeNB 3 already started the IPsec setup at time 4 and consequently was ready already at time 8. Consequently the previous IPsec endpoint, i.e. DeNB 2 is engaged a bit longer until time 9 compared to time 8 and the total forwarding distance is a bit longer on average.

This disadvantage can be alleviated to some extent by

starting the IPsec setup immediately with a new node, but aborting it if it is not finished before yet another DeNB is coming into the play. This is visualized in Fig. 11.

Here IPsec setup is started immediately, indicated by the black ring at DeNB3 at time 3, but is abandoned when the RN hands over to a further DeNB while there is still a previous IPsec setup running concurrently, indicated by the white ring at DeNB3 at time 4. The IPsec setup at Node 4 however is not aborted, because at time 6, when the RN hands over to DeNB5, the previous IPsec setup at DeNB 2 has already been finished. While each node starts the IPsec setup immediately, at any time there are at most two IPsec setups running concurrently because the second youngest setup is aborted when a further one is started. Consequently the processing load is limited in this case, but is somewhat higher than for pure

leapfrogging .

Obviously also other subsets of the optimization techniques presented in the previous figures, or even all the

optimization techniques presented in the previous figures can also be combined as shown in Fig. 12.

According to Fig. 12, leapfrogging is combined with early node termination, hop optimization and early IPsec setup, combining the relevant advantages as well.

Fourth Embodiment :

According to the fourth embodiment, SI / X2 traffic is routed via an RN security anchor (RNA) that could be close to the core network.

The RNA would communicate only with DeNBs using a yet-to-be- defined protocol. In the following, this protocol is called S-RNA. The DeNB is the S-RNA client and the RNA is the S-RNA server. The service the RNA provides to the DeNB is

a) removing outer IP header (if IPsec tunnel mode is used) and ESP header and verifying IPsec ESP integrity protection for S1/X2 uplink messages from the RN to the MME-UE;

b) adding outer IP header (if IPsec tunnel mode is

used) and adding IPsec ESP integrity protection for S1/X2 downlink messages from the MME-UE to the RN; c) (only if alternative 1 (b) below is chosen) respond to IKEv2 requests from the RN forwarded by the DeNB.

This RNA would not move even when the RN moved from one DeNB to other DeNBs over time. Whether this solution has

advantages entirely depends on performance considerations. But it shows a way how very fast moving RNs could be realized even when IPsec security procedures over Un took much more time than the time between too consecutive handovers of an RN.

The link between the DeNB and the RNA may be protected by means of a fixed IPsec tunnel (different from the one used by the RN over Un) .

The RNA works as follows:

(1) Set-up phase: during, or immediately after, the RN attach procedure, the RN runs IKEv2 with the RNA and addresses the IKEv2 packets not to the DeNB, but to the RNA. The DeNB knows that it has to let this IP packet pass as the DeNB recognizes the IP address of the RNA. This requires that the RN can originate and send IP packets to certain destinations allowed by the DeNB, as well as receive IP packets destined to it from certain sources outside, as allowed by the DeNB. (The RN can do so in its role as a UE.) It further presupposes that the IP address of the RNA is known to the RN, e.g. by

configuration, and that the RN has an IP address that is unique at least in the operator network. This IP address is assigned by the P-GW-RN on the DeNB.

There are two ways for sending IKEv2 messages between RN and RNA:

(a) the IP addresses of RN and RNA are publicly routable and normal IP routing mechanisms are used; (b) as all packets from and to the RN are sent via the DeNB, the DeNB can use the S-RNA protocol to forward IKEv2 packets from the RN to the RNA and vice versa. This would still be compliant with the client-server model for the S-RNA protocol as RN is meant to be the IKEv2 initiator.

After completing the IKEv2 run the RN and the RNA have set up the IPsec security associations between them. There are two IPsec modes to be considered (only one and the same should be used in the end for all RNs) :

(c) IPsec ESP is used in tunnel mode. The inner IP address of the RN is assigned by the RNA while the outer IP address of the RN is the one assigned by the P-GW-RN on the DeNB, as described above. The selectors for the inbound Security Association (SA) at the RNA consist of the inner IP address of the RN as source address, and selectors for the outbound Security Association (SA) at the RNA consist of the inner IP address of the RN as destination address.

(d) IPsec ESP is used in transport mode. The IP address of the RN is the one assigned by the P-GW- RN on the DeNB, as described above. The selectors for the inbound Security Association (SA) at the RNA consist of the IP address of the RN as source address, and selectors for the outbound Security Association (SA) at the RNA consist of the IP address of the RN as destination address.

(2) Uplink SI operation: when the RN has to send an SI message to the MME-UE it protects it using the established IPsec ESP security association. It is distinguished between the operations for tunnel mode and transport mode. (A) IPsec ESP is used in tunnel mode.

The RN applies ESP integrity protection. The inner destination address is the IP address of the MME-UE, the outer

destination address is the IP add of the RNA. The inner and outer source IP

addresses are those from step (1) . The DeNB to which the RN is currently attached (i.e. where the SI proxy for the RN is currently located) encapsulates the IP packet

received from the RN in an S-RNA request to the RNA. The RNA verifies the integrity of the received IP packet and, if the IPsec verification was successful, strips the outer IP header and the ESP header off, and returns the resulting IP packet to the DeNB encapsulated in an S-RNA response. The DeNB then processes the SI message, as required, and sends the processed SI message to the MME-UE .

(B) IPsec ESP is used in transport mode.

The RN applies ESP integrity protection. The destination address is the IP address of the RNA. The source IP address is the one from step (1) . The DeNB to which the RN is currently attached (i.e. where the SI proxy for the RN is currently located) encapsulates the IP packet received from the RN in an S-RNA request to the RNA. The RNA verifies the integrity of the received IP packet and, if the IPsec verification was successful, strips the ESP header off, and returns the resulting IP packet to the DeNB encapsulated in an S-RNA response. The DeNB then processes the SI message, as required, replaces the destination IP address with that of the MME-UE, and sends the processed SI message to the MME-UE.

(3) Downlink SI operation: when the MME-UE has to send an SI message to the RN, it sends it to the DeNB with the SI proxy for the RN. (The MME-UE does not see the RN as a separate entity behind the DeNB.) The DeNB processes the SI message, as required. The further processing depends on the IPsec mode used .

(A) IPsec ESP is used in tunnel mode.

The DeNB replaces the destination IP address with the inner IP address of the RN (which it must have learnt somehow during IKEv2 negotiations, e.g. by the RNA explicitly including this inner IP address of the RN in the S-RNA response in step 1 (b) , and forwarding this IP address in handovers) and encapsulates this IP packet in an S-RNA request to the RNA. The RNA applies ESP integrity protection to the received IP packet and adds the outer IP header as required

according to step (1), and returns the resulting IP packet to the DeNB encapsulated in an S-RNA response. The DeNB forwards the IP packet over Un to the RN. The RN verifies the integrity of this packet .

(B) IPsec ESP is used in transport mode.

The DeNB replaces the destination IP address with the IP address of the RN used in IKEv2 negotiations with the RNA (which the DeNB must have learnt somehow during IKEv2 negotiations, remember that this IP address may have been assigned by a P-GW on a DeNB to which the RN was attached previously) and encapsulates this IP packet in an S-RNA request to the RNA. The RNA applies ESP integrity protection to the received IP packet, and returns the resulting IP packet to the DeNB encapsulated in an S-RNA response. The DeNB forwards the IP packet over Un to the RN. The RN verifies the integrity of this packet.

(4) Handling of IKEv2 maintenance messages (keep alives etc) .

It is proposed that all IKEv2 messages sent after the initial phase are forwarded by the DeNB using the S-RNA protocol as described in step (1) (b) as the IP address of the RN may have been assigned by a DeNB to which the RN was attached previously and may no longer be publicly routable.

An advantage of the fourth embodiment with respect to the fifth embodiment, to be described below, is shorter latency as the fifth embodiment requires one additional security- related roundtrip per handover (caused by MOBIKE) while the fourth embodiment does not require any such additional roundtrips .

Fifth embodiment:

In the fourth embodiment described above, the IP address of the RN used with IKEv2 and IPsec ESP security associations is an IP address assigned by the P-GW on the DeNB to which the RN attaches first. This IP address will, in general, not be usable to route packets to the RN via the DeNB to which the RN is currently attached. This is the reason for using the S- RNA protocol in the fourth embodiment.

The main difference between embodiments 5 and 4 is that not the S-RNA protocol, but an IP address of the RN routable in the operator network and newly assigned by the P-GW on each new DeNB, to which the RN attaches, is used to route messages between the RN and the RN security anchor (RNA) . But this RN IP address changes with each handover, so the originally established IPsec security association is no longer valid. This problem is solved in embodiment 5 by updating this security association using MOBIKE (RFC 4555) . MOBIKE uses a single roundtrip to communicate the new IP address of the initiator (i.e. here the RN) to the responder (i.e. here the RNA) and is not very computation intensive. The advantage of the fifth embodiment over the first embodiment is reduced latency, the advantage over the fourth embodiment is

simplified routing and handling in the DeNB .

The above-described procedures and functions may be

implemented by respective functional elements, processors, or the like, as described below.

While in the foregoing exemplary embodiments of the present invention are described mainly with reference to methods, procedures and functions, corresponding exemplary embodiments of the present invention also cover respective apparatuses, network nodes and systems, including both software and/or hardware thereof. Examples for such apparatuses or network nodes that execute a specific functionality that is related to the presented invention include: RN, DeNB which may be any one of source, target and intermediate DeNB, ^xsecurity server' , RNA. Note that any of these nodes or apparatuses can be designed to execute a crucial part of one of the methods presented above including e.g. initiating and/or being engaged in setting up a security association or aborting such a setup, forwarding packets to a node serving as a security server for doing security related processing, forwarding processed packets to or from a target DeNB. Any such

apparatus respectively node is considered to be covered by this invention, also if it needs to concert with other apparatuses or nodes in order to achieve the complete

functionality of the invention.

Figs. 13 to 15 show schematic block diagrams of apparatuses according to exemplary embodiments of the present invention.

In Figs. 13 to 15, the solid line blocks are basically configured to perform respective operations as described above. The entirety of solid line blocks are basically configured to perform the methods and operations as described above, respectively. With respect to Figs. 13 to 15, it is to be noted that the individual blocks are meant to illustrate respective functional blocks implementing a respective function, process or procedure, respectively. Such functional blocks are implementation-independent, i.e. may be

implemented by means of any kind of hardware or software, respectively. The arrows interconnecting individual blocks are meant to illustrate an operational coupling there^¬ between, which may be a physical and/or logical coupling, which on the one hand is implementation-independent (e.g. wired or wireless) and on the other hand may also comprise an arbitrary number of intermediary functional entities not shown. The direction of arrow is meant to illustrate the direction in which certain operations are performed and/or the direction in which certain data is transferred. The arrangement of the functional blocks of the devices is not construed to limit the invention, and the functions may be performed by one block or further split into sub-blocks.

Further, in Figs. 13 to 15, only those functional blocks are illustrated, which relate to any one of the above-described methods, procedures and functions. A skilled person will acknowledge the presence of any other conventional functional blocks required for an operation of respective structural arrangements, such as e.g. a power supply, a central

processing unit, respective memories or the like. Among others, memories are provided for storing programs or program instructions for controlling the individual functional entities to operate as described herein.

Fig. 13 shows a schematic block diagram of an apparatus according to exemplary embodiments of the present invention. The thus depicted apparatus may be implemented by or at a relay node. According to Fig. 13, the apparatus according to exemplary embodiments of the present invention is configured to

implement initiating and performing setup of a security association and/or managing of relaying packets in a

procedure as described in conjunction with Figures 4 to 12. Therefore, while basic operations are described hereinafter, reference is made to the above description for details.

Referring to Fig. 13, an apparatus according to embodiments of the present invention includes a processor and a

transmitter/receiver, and optionally also a memory. The processor is preferably configured to setup a security association and/or to relay packets during handover of a relay node of a relay-enhanced access network from a source base station to a target base station, thus representing means for setting up a security association and/or relaying packets. The transmitter/receiver is preferably configured to send and/or receive messages to and/or from any other network element, thus representing means for sending and/or receiving messages. The transmitter/receiver may be adapted to send and receive messages via a wireless or wired connection. The memory is preferably configured to store information relevant for proxy relocation in the context of relay node handover, thus representing means for storing relevant information.

Fig. 14 shows a schematic block diagram of an apparatus according to exemplary embodiments of the present invention. The thus depicted apparatus may be implemented by or at a (source/target) base station (e.g. DeNB) .

According to Fig. 14, the apparatus according to exemplary embodiments of the present invention is configured to

implement managing of relaying packets in a procedure as described in conjunction with Figures 5 to 12. Therefore, while basic operations are described hereinafter, reference is made to the above description for details. Referring to Fig. 14, an apparatus according to embodiments of the present invention includes a processor and a

transmitter/receiver, a network interface and optionally also a memory. The processor is preferably configured to relay packets during handover of a relay node of a relay-enhanced access network from a source base station to a target base station, thus representing means for relaying packets. The transmitter/receiver is preferably configured to send and/or receive messages to and/or from any other network element, thus representing means for sending and/or receiving

messages. The transmitter/receiver may be adapted to send and receive messages via a wireless or wired connection. The base station is connected to the network via the network

interface. The memory is preferably configured to store information relevant for relaying in the context of relay node handover, thus representing means for storing relevant information .

Fig. 15 shows a schematic block diagram of an apparatus according to exemplary embodiments of the present invention. The thus depicted apparatus may be implemented by or at a security anchor, RNA.

According to Fig. 15, the apparatus according to exemplary embodiments of the present invention is configured to

implement managing of relaying packets in a procedure as described above. Therefore, while basic operations are described hereinafter, reference is made to the above

description for details.

Referring to Fig. 15, an apparatus according to embodiments of the present invention includes a processor and a network interface and optionally also a memory. The processor is preferably configured to relay packets during handover of a relay node of a relay-enhanced access network from a source base station to a target base station, thus representing means for relaying packets. The security anchor is connected to other network elements via the network interface. The memory is preferably configured to store information relevant for relaying in the context of relay node handover, thus representing means for storing relevant information.

For the purpose of the present invention as described herein above, it should be noted that

- method steps likely to be implemented as software code portions and being run using a processor at a network control element or terminal (as examples of devices, apparatuses and/or modules thereof, or as examples of entities including apparatuses and/or modules therefore), are software code independent and can be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved;

- generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the embodiments and its modification in terms of the

functionality implemented;

- method steps and/or devices, units or means likely to be implemented as hardware components at the above-defined apparatuses, or any module (s) thereof, (e.g., devices

carrying out the functions of the apparatuses according to the embodiments as described above) are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components;

- devices, units or means (e.g. the above-defined

apparatuses, or any one of their respective units/means) can be implemented as individual devices, units or means, but this does not exclude that they are implemented in a

distributed fashion throughout the system, as long as the functionality of the device, unit or means is preserved; - an apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a

(software) module such as a computer program or a computer program product comprising executable software code portions for execution/being run on a processor;

- a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in

cooperation with each other or functionally independently of each other but in a same device housing, for example.

Software in the sense of the present description comprises software code as such comprising code means or portions or a computer program or a computer program product for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium such as a computer-readable (storage) medium having stored thereon a respective data structure or code

means/portions or embodied in a signal or in a chip,

potentially during processing thereof.

It is noted that the embodiments and general and specific examples described above are provided for illustrative purposes only and are in no way intended that the present invention is restricted thereto. Rather, it is the intention that all variations and modifications be included which fall within the scope of the appended claims.

Claims

1. A method, comprising:

suspending sending packets via the relocated proxy

2. A method, comprising:

3. The method according to claim 2, wherein relaying packets to the target base station comprises

recognizing, at the source base station, that the packets are destined to a relocated proxy functionality, and forwarding the packets to the target base station utilizing an existing, or a newly established, security association between the source base station and the target base station.

4. The method according to claim 2, wherein relaying packets from the target base station comprises

sending, by the target base station, the packets via an existing, or newly established, security association between the source base station and the target base station, recognizing, at the source base station, that the packets are destined to the relay node, and

5. A method, comprising:

6. The method according to any one of claims 2 to 5, wherein, when a plurality of handovers for the relay node to a plurality of base stations are performed, packets to the relay node are relayed through the source base station via each of the plurality of base stations that handed over the relay node.

7. The method according to claim 6, wherein each of the plurality of base stations to which the relay node is handed over initiates setup of a security association with the relay node .

8. The method according to claim 7, wherein packets to the relay node are relayed from the base station that has set up a security association with the relay node via the base station that has started setup of the security association at the latest with at least some of the other intermediate base stations being not involved in relaying the packets.

9. The method according to claim 6, wherein a base station to which the relay node is handed over initiates setup of the security association only if a setup of a security

association of one of the base stations that previously handed over the relay node is completed.

10. The method according to claim 7, 8 or 9, wherein the base station to which the relay node is handed over stops setup of the security association if the setup is not completed when the base station hands over the relay node to another base station .

11. The method according to any one of claims 7 to 10, wherein, when a base station has completed setup of the security association, the previous base station having the security association is discarded.

12. A method, comprising:

13. The method according to claim 12, wherein

the security anchor relays the packets to and from the source base station before handover and to and from the target base station after handover.

14. The method according to claim 13, wherein

packets from and to the base station are relayed through the security anchor using a communication protocol between the security anchor and the base station.

15. The method according to any of the claims 12 to 14, wherein

the security association between relay node and security anchor via different base stations is updated by usage of a protocol according to MOBIKE.

16. The method according to claim 1, wherein

the method is operable at or by a relay node, and said relay node may be part of an evolved radio access network in accordance with LTE and/or LTE-Advanced specifications.

17. The method according to any one of claims 2 to 11, wherein

the method is operable at or by a donor base station

controlling the relay node, and said donor base station may be part of an evolved radio access network in accordance with LTE and/or LTE-Advanced specifications.

18. The method according to any one of claims 12 to 15, wherein

the method is operable at or by a relay node security anchor, and said relay node security anchor may be part of an evolved radio access network in accordance with LTE and/or LTE-Advanced specifications.

19. Computer program product including a program for a processing device, comprising software code portions for performing the steps of any one of claims 1 to 18 when the program is run on the processing device.

20. Computer program product according to claim 19, wherein the computer program product comprises a computer-readable medium on which the software code portions are stored.

21. Computer program product according to claim 19, wherein the program is directly loadable into an internal memory of the processing device.

22. An apparatus, comprising:

23. An apparatus, comprising:

a processor configured to relay, after a proxy

24. The apparatus according to claim 23, wherein the

processor is configured to

recognize that the packets are destined to a relocated proxy functionality, and

forward the packets to the target base station utilizing an existing, or a newly established, security association between the apparatus and the target base station.

25. The apparatus according to claim 23, wherein the

processor is configured to

recognize that the packets are destined to the relay node, and

forward the packets to the relay node utilizing an existing security association between the apparatus and the relay node.

26. An apparatus, comprising:

apparatus during a handover of the relay node is completed, and

relocate, after setting up of a security association between the relay node and the apparatus is completed, a proxy functionality for the relay node from the source base station to the apparatus .

27. An apparatus, comprising:

to relay the packets from and to a base station.

28. The apparatus according to claim 27, wherein

the processor is configured to relay the packets from and to the base station using a communication protocol between the apparatus and the target base station.

29. The apparatus according to claim 27, wherein

a communication protocol between the apparatus and the relay node uses MOBIKE.

30. The apparatus according to claim 22, wherein

the apparatus is operable as or at a relay node, and said relay node may be part of an evolved radio access network in accordance with LTE and/or LTE-Advanced

specifications .

31. The apparatus according to any one of claims 23 to 27, wherein

the apparatus is operable as or at a donor base station controlling the relay node, and said donor base station may be part of an evolved radio access network in accordance with LTE and/or LTE-Advanced specifications.

32. The apparatus according to any one of claims 27 to 29, wherein

the apparatus is operable as or at a relay node security anchor, RNA, and said relay node security anchor may be part of an evolved radio access network in accordance with LTE and/or LTE-Advanced specifications.