WO2011038779A1

WO2011038779A1 - Binding revocation in network-based mobility

Info

Publication number: WO2011038779A1
Application number: PCT/EP2009/062841
Authority: WO
Inventors: Jouni Korhonen; Jan KÅLL
Original assignee: Nokia Siemens Networks Oy
Priority date: 2009-10-02
Filing date: 2009-10-02
Publication date: 2011-04-07

Abstract

There are provided measures for binding revocation in network-based mobility. Such measures for binding revocation may for example comprise one or more of exchanging a mobile node's user traffic being indexed with a tunnel key via a transport tunnel between an originating tunnel endpoint and a terminating tunnel endpoint, searching a binding cache for a transport tunnel with said tunnel key for a binding between the mobile node's home and mobility addresses, exchanging a request for revoking the respective binding and revoking the respective binding at the originating tunnel endpoint, said request indicating said tunnel key, when the searching fails to find said tunnel key.

Description

Title Binding revocation in network-based mobility Technical Field

The present invention generally relates to techniques for binding revocation in network-based mobility. For example, the present invention may be applicable for revocation of bindings and/or release of mobility sessions in a network environment using a network-based mobility protocol.

Background

Generally, mobility support for mobile nodes is a key issue in modern and future communication networks including mobile/wireless communication networks, such as for example General Packet Radio Service (GPRS) ,

Universal Mobile Telecommunication System (UMTS) , Long- Term Evolution (LTE) , Long-Term Evolution Advance (LTE- A) , Wireless Interoperability for Microwave Access

(WiMAX) , or other 3GPP (3GPP: Third Generation

Partnership Project) or IETF (Internet engineering Task Force) networks.

Since the Internet Protocol (IP) is gaining more and more importance for communications in any kind of modern and future communication networks, mobility support in such networks is generally related to enabling IP mobility, in particular for IPv6 hosts operating on the basis of version 6 of the Internet Protocol (IPv6) . One approach in this regard is IP mobility for IPv6 hosts, which reguires client functionality in the IPv6 stack of a mobile node. Exchange of signaling messages between the mobile node and a home agent enables the creation and maintenance of a binding between the mobile node's home address and its care-of address. In this approach, it is reguired that the IP host sends IP mobility management signaling messages to the home agent, which is located in the network.

Another approach in this regard is network-based mobility enabling IP mobility for a host without reguiring its participation in any mobility-related signaling. The network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network, i.e. local mobility anchors (L A) and mobile access gateways (MAG) are responsible for tracking the movements of the host and initiating the reguired mobility signaling on its behalf. A proxy mobility agent in the network performs the signaling with the home agent and does the mobility management on behalf of the mobile node attached to the network. One common example for such network-based mobility management is referred to as Proxy Mobile IPv6 (PMIPv6) .

In practical network-based mobility deployments, user traffic of mobile node is transmitted between a local mobility agent (LMA) and a mobile access gateway (MAG) via a transport tunnel being identified by a specific tunnel key. In ΡΜΙΡνδ, there is usually applied a generic routing encapsulation (GRE) over such a transport tunnel thus being referred to as GRE tunnel. The GRE tunnel multiplexing is usually enabled with a pair of GRE keys for uplink and downlink direction wherein dynamic negotiation of these keys is enabled during proxy binding registration exchange. However, in practical network-based mobility deployments as outlined above, there are error situations being irresolvable on the basis of conventional specifications.

Such conventionally irresolvable error situations are based on a situation wherein the binding caches of a local mobility anchor (LMA) and a mobile access gateway (MAG) are not synchronized with respect to a certain mobile node (MN) or user eguipment (UE) . That is, the MAG may have a binding for some mobile node, which the LMA may not have, or vice versa.

In the case of the MAG having a binding for some mobile node lacking in the LMA, the MAG keeps sending uplink user data to the LMA, which may also be encapsulated inside the GRE tunnel there-between . As a result, the LMA keeps receiving GRE-tunneled user traffic being indexed with some GRE uplink key, but the LMA cannot find a GRE tunnel with that GRE uplink key in its binding cache. This error situation may for example happen when the LMA is (partially) recovering e.g. from a node failure, when the (GRE) tunnel is getting removed or corrupted for some reason, or when the LMA configuration is manually modified . In view of the above error situations, it has been proposed to use a Mobile IPv6 binding error (BE) message. This has, however, the problem that this BE message is defined to be used between a correspondent node (CN) and a mobile node (MN) , so that the semantics of the BE message and its content would have to be considerably changed in order to be properly applicable in a network- based mobility environment. Especially, the usage of the BE message as defined would not be sufficient for resolving error situations in case the mobile node has a home address of Internet Protocol version 4 (IPv4) . This is because IPv4 addresses may overlap in certain cases, thus reguiring additional information in the BE message than just the IPv4 address, which are usually not available.

In view of the above error situations, it has also been proposed to use an Internet control message protocol (ICMP) between the LMA and the MAG. This has, however, the problem that, while the specified "Destination

Unreachable" error might be used, a new and ΡΜΙΡνβ- specific ICMP type would probably be needed. Also, for IPv4 transport, the data carried by ICMP is restricted to the erroneous IP header plus 64 bits of original data (i.e. 8 octets), which might be insufficient to carry enough information, as the IP header in this case would probably be the ΡΜΙΡνβ tunnel header, and in this case there would not be enough space to carry both GRE header and even the source address (i.e. the home address) of the tunneled packet. This would result in the need for a special handling of ICMP just for purposes of network- based mobility, which is not desirable. Furthermore, ICMP messages get usually aggressively filtered by firewalls and routers, which makes its applicability further guestionable .

Accordingly, in view of the above, there is a need for technigues for binding revocation in network-based mobility so as to enable resolving above-outlined error situations .

Summary of exemplary embodiments of the invention

Embodiments of the present invention are made to provi for a feasible solution for a binding revocation in network-based mobility. In particular, but not

exclusively, embodiments of the present invention are made to overcome or at least mitigate above-outlined problems and drawbacks .

According to an exemplary first aspect of the present invention, there is provided a method comprising receiving a mobile node's user traffic being indexed with a tunnel key via a transport tunnel from an originating tunnel endpoint, searching a binding cache for a transport tunnel with said tunnel key for a binding between the mobile node's home and mobility addresses, and generating and sending a reguest for revoking the respective binding at the originating tunnel endpoint via said transport tunnel, said reguest indicating said tunnel key, when the searching fails to find said tunnel key .

According to further developments and/or modifications thereof, one or more of the following may apply:

- said reguest comprises a binding revocation

indication message containing a mobility option or tunnel key option field including an indication of said tunnel key,

- said binding revocation indication message further contains a revocation trigger field including an

indication of a wrong tunnel key option, - the method further comprises receiving a confirmation of revoking the respective binding via said transport tunnel from said originating tunnel endpoint

- said confirmation may be a binding revocation acknowledgement message containing an error code including an indication of a wrong tunnel key option,

- the method is operable on the basis of a network- based mobility protocol such as a proxy mobile IP protocol,

- the transport tunnel is based on a generic routing encapsulation protocol, said tunnel key being a generic routing encapsulation key,

- the method is operable at a local mobility anchor, the originating tunnel endpoint is a mobile access gateway, the user traffic is uplink user traffic, and the tunnel key is an uplink key being unigue for said local mobility anchor, and/or

- the method is operable at a mobile access gateway, the originating tunnel endpoint is a local mobility anchor, the user traffic is downlink user traffic, and the tunnel key is a downlink key being unigue for the pair of said mobile access gateway and said local mobility anchor. According to an exemplary second aspect of the present invention, there is provided an apparatus comprising a receiver configured to receive a mobile node' s user traffic being indexed with a tunnel key via a transport tunnel from an originating tunnel endpoint, a binding cache configured to store bindings between mobile nodes' home and mobility addresses for mobility sessions, a processor configured to search said binding cache for a transport tunnel with said tunnel key for a binding between the mobile node's home and mobility addresses, and to generate a reguest for revoking the respective binding at the originating tunnel endpoint, said reguest indicating said tunnel key, when failing to find said tunnel key, and a transmitter configured to send said reguest to the originating tunnel endpoint via said transport tunnel.

- said processor is configured to generate, as said reguest, a binding revocation indication message

containing a mobility option or tunnel key option field including an indication of said tunnel key,

- said processor is configured to generate, as said reguest, said binding revocation indication message further containing a revocation trigger field including an indication of a wrong tunnel key option,

- said receiver is configured to receive a confirmation of revoking the respective binding via said transport tunnel from said originating tunnel endpoint,

- said confirmation may be a binding revocation acknowledgement message containing an error code

including an indication of a wrong tunnel key option,

- the apparatus is part of a network-based mobility system such as a proxy mobile IP system,

- said network-based mobility system is at least one of a worldwide interoperability for microwave access system, an evolved high rate packet data system and an evolved packet core system,

- the apparatus is operable as or at a local mobility anchor, the originating tunnel endpoint is a mobile access gateway, the user traffic is uplink user traffic, and the tunnel key is an uplink key being unigue for said local mobility anchor, and/or

- the apparatus is operable as or at a mobile access gateway, the originating tunnel endpoint is a local mobility anchor, the user traffic is downlink user traffic, and the tunnel key is a downlink key being unigue for the pair of said mobile access gateway and said local mobility anchor.

According to an exemplary third aspect of the present invention, there is provided a method comprising sending a mobile node's user traffic being indexed with a tunnel key via a transport tunnel to a terminating tunnel endpoint, receiving a reguest for revoking a binding between the mobile node's home and mobility addresses in a binding cache via said transport tunnel from said terminating tunnel endpoint, said reguest indicating said tunnel key, and revoking the respective binding in said binding cache.

- the method further comprises identifying a mobility session concerned on the basis of said tunnel key, and releasing the identified mobility session,

- said reguest comprises a binding revocation

indication of a wrong tunnel key option, - the method further comprises generating and sending a confirmation of revoking the respective binding via said transport tunnel to said terminating tunnel endpoint,

- the method is operable at a mobile access gateway, the terminating tunnel endpoint is a local mobility anchor, the user traffic is uplink user traffic, and the tunnel key is an uplink key being unigue for said local mobility anchor, and/or

- the method is operable at a local mobility anchor, the terminating tunnel endpoint is a mobile access gateway, the user traffic is downlink user traffic, and the tunnel key is a downlink key being unigue for the pair of said mobile access gateway and said local mobility anchor. According to an exemplary fourth aspect of the present invention, there is provided an apparatus comprising a transmitter configured to send a mobile node' s user traffic being indexed with a tunnel key via a transport tunnel to a terminating tunnel endpoint, a binding cache configured to store bindings between mobile nodes' home and mobility addresses for mobility sessions, a receiver configured to receive a reguest for revoking a binding between the mobile node's home and mobility addresses in said binding cache via said transport tunnel from said terminating tunnel endpoint, said reguest indicating said tunnel key, and a processor configured to revoke the respective binding in said binding cache. According to further developments and/or modifications thereof, one or more of the following may apply:

- said processor is configured to identify a mobility session concerned on the basis of said tunnel key, and release the identified mobility session,

- said reguest comprises a binding revocation indication message containing a mobility option or tunnel key option field including an indication of said tunnel key,

indication of a wrong tunnel key option,

- said processor is configured to generate and said transmitter is configured to send a confirmation of revoking the respective binding via said transport tunnel to said terminating tunnel endpoint,

including an indication of a wrong tunnel key option.

- the apparatus is operable as or at a mobile access gateway, the terminating tunnel endpoint is a local mobility anchor, the user traffic is uplink user traffic, and the tunnel key is an uplink key being unigue for said local mobility anchor, and/or

- the apparatus is operable as or at a local mobility anchor, the terminating tunnel endpoint is a mobile access gateway, the user traffic is downlink user traffic, and the tunnel key is a downlink key being unigue for the pair of said mobile access gateway and said local mobility anchor. According to an exemplary fifth aspect of the present invention, there is provided a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the above first aspect or any one of the further developments and/or modifications thereof. The apparatus, on which said computer program product may be run, is the apparatus according to the above second aspect or any one of the further developments and/or modifications thereof.

According to an exemplary sixth aspect of the present invention, there is provided a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the above third aspect or any one of the further developments and/or modifications thereof. The apparatus, on which said computer program product may be run, is the apparatus according to the above fourth aspect or any one of the further developments and/or modifications thereof.

By way of exemplary embodiments of the present invention, there are provided technigues for binding revocation in network-based mobility, for example for revocation of bindings and/or release of mobility sessions in a network environment using a network-based mobility protocol.

By way of exemplary embodiments of the present invention, error situations in network-based mobility, which are based on unsynchronized binding caches, may be properly resolved. For example, such error situations in Ρ ΙΡνβ- based deployments may be properly resolved. Further details may become more apparent from the subsequent description of exemplary embodiments with reference to accompanying drawings.

Brief description of the drawings

In the following, the present invention will be described in greater detail by way of non-limiting examples with reference to the accompanying drawings, in which Figure 1 shows a signaling diagram of a first use case according to exemplary embodiments of the present invention,

Figure 2 shows a signaling diagram of a second use case according to exemplary embodiments of the present invention,

Figure 3 shows a flowchart of a method at a terminating tunnel endpoint according to exemplary embodiments of the present invention,

Figure 4 shows a flowchart of a method at an originating tunnel endpoint according to exemplary embodiments of the present invention, Figure 5 shows a schematic block diagram of an apparatus at a terminating tunnel endpoint according to exemplary embodiments of the present invention, and

Figure 6 shows a schematic block diagram of an apparatus at an originating tunnel endpoint according to exemplary embodiments of the present invention. Detailed description of exemplary embodiments of the invention

The present invention is described herein with reference to particular non-limiting examples. A skilled person will appreciate that the invention is not limited to these examples, and may be more broadly applied.

In particular, the present invention and its embodiments are mainly described in relation to IETF and 3GPP specifications being used as non-limiting examples for certain exemplary network configurations and deployments. In particular, network-based mobility on the basis of Proxy Mobile IPv6 (ΡΜΙΡνβ) is used as a non-limiting example. As such, the description of exemplary

embodiments given herein specifically refers to

terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples, and does naturally not limit the invention in any way. Rather, any other network

configuration or system deployment, etc. may also be utilized as long as compliant with the features described herein. In particular, embodiments of the present invention may be applicable in any system with network- based mobility support, for example for any ΡΜΙΡνβ-based mobility and tunneling protocols, irrespective of the underlying communication network environment. Such underlying communication network environment may for example be based on Wi AX, evolved high rate packet data (eHRPD) according to 3GPP2, and evolved packet core (EPC) according to 3GPP .

For example, embodiments of the present invention as described herein are applicable to Proxy Mobile IPv6 (ΡΜΙΡνβ) based mobility and tunneling specifications such as those according to 3GPP TS 29.275. Namely, embodiments of the present invention as described herein are

applicable over PMIP-based S2a, S2b, S5, and S8 reference points, and are thus applicable to serving gateway, PDN gateway, evolved packet data gateway (ePDG) , and trusted non-3GPP access .

In the following, various embodiments and implementations of the present invention and its aspects or embodiments are described using several alternatives. It is generally to be noted that, according to certain needs and

constraints, all of the described alternatives may be provided alone or in any conceivable combination (also including combinations of individual features of the various alternatives) .

For the following description, as outlined above, a system deployment on the basis of Proxy Mobile IPv6 (ΡΜΙΡνβ) with a generic routing encapsulation (GRE) tunnel is assumed as a non-limiting example for a network-based mobility environment. In the following, exemplary embodiments of the present invention are described with reference to methods, procedures and functions. Generally, according to exemplary embodiment of the present invention, ΡΜΙΡνβ nodes L A and MAG shall arrange for deleting or releasing a PDN (packet data network) connection (which may also be referred to as ΡΜΙΡνβ connection when ΡΜΙΡνβ is used as the network-based mobility protocol) or mobility session, when an unknown, undefined or misused (i.e. "wrong") tunnel key is received via a transport tunnel corresponding to the respective PDN connection or mobility session. To this end, it is proposed to use a binding revocation method as detailed below.

In this regard, it is to be noted that a PDN connection and mobility session may be regarded as synonyms, as a PDN connection according to 3GPP terminology corresponds to a mobility session according to IETF terminology. In particular, in the context of Proxy Mobile IPv6, the term mobility session refers to the creation or existence of a state associated with a mobile node's mobility binding (i.e. its binding between its home address and its current care-of address) on the local mobility anchor and on the serving mobile access gateway. A proxy care-of address (Proxy-CoA) is a global address configured on the egress interface of the mobile access gateway and is the transport endpoint of the tunnel between the local mobility anchor and the mobile access gateway. The local mobility anchor views this address as the care-of address of the mobile node and registers it in the binding cache entry for that mobile node. On a (ΡΜΙΡνβ) peer (i.e. MAG or LMA) , there is a one-to-one mapping between a PDN connection and a (ΡΜΙΡνβ) binding or mobility session.

There are two basic use cases in this regard. In a first use case, a LMA receives user traffic with an unknown, undefined or misused (i.e. "wrong") uplink tunnel (e.g. GRE) key. In a second use case, a MAG receives user traffic with an unknown, undefined or misused (i.e.

"wrong") downlink tunnel (e.g. GRE) key. In this context, user traffic may be plain IP traffic being encapsulated inside a (GRE) tunnel.

Figure 1 shows a signaling diagram of a first use case according to exemplary embodiments of the present invention .

In Figure 1, the MAG denoting an originating tunnel endpoint and the LMA denoting a terminating tunnel endpoint, as well as the GRE tunnel established therebetween are illustrated. Although not illustrated, the MAG is connected with a user's mobile node (MN) or user eguipment (UE) via a point-to-point link.

In Figure 1, it is presumed that a tunnel has already been established between MAG and LMA, thus also presuming that respective bindings and/or mobility session on the basis of the underlying network-based mobility protocol have already been set up.

In this connection, the following is to be noted. When GRE keys are used, the binding caches of both tunnel endpoints are normally extended to contain the GRE key of the respective tunnel in addition to the mobile node' s binding between its home address and its mobility address (i.e. care-of-address) . The GRE key is usable as (an additional) search key in the binding caches. When a mobility session (binding) is created, then also a new GRE tunnel with a specific GRE tunnel key for user traffic is set up between the MAG and the LMA. This is repeated for each new mobility session. So, when an uplink (UL) packet arrives from a mobile host at the MAG, the MAG forwards the packet to the correct established GRE tunnel . Each mobile node connects to the MAG through a unigue point-to-point link, so mapping uplink traffic to a proper GRE tunnel is readily feasible. When the LMA receives a packet from the GRE tunnel, it could look up the binding cache and can locate the correct binding cache entry solely based on the GRE key, as each uplink GRE key in the LMA is unigue. However, a combination of IPv6-HNP/IPv4-HoA and GRE key may also used for such lookups. After this, the LMA routes the

tunneled user traffic to the proper egress interface toward external networks in the LMA. Similar procedures also apply for downlink traffic, except that each downlink GRE key is unigue only between each MAG-LMA pair .

The procedure according to Figure 1 is directed to a case where the look-up of the received GRE key in the binding cache of the LMA fails, i.e. an error situation as mentioned above.

First, the LMA receives uplink user traffic (payload, not signaling) of a mobile node (not shown) from the MAG via a respective transport tunnel such as a GRE tunnel, said user traffic being indexed or marked with a tunnel key such as a uplink GRE key. Upon look-up of the received uplink GRE key in its binding cache, the LMA detects that it does not have a corresponding GRE tunnel or tunnel interface, since there is no corresponding binding cache entry with proper subscription information, i.e. there is no mobile node binding entry corresponding to a GRE tunnel or tunnel interface with this GRE key.

In this regard, it is to be noted that herein the

(non-) detection of a GRE tunnel or a GRE tunnel interface may be regarded as eguivalent . Namely, depending on an implementation of the LMA (or similarly the MAG, see below) , each GRE tunnel with a different GRE key may show up either as an individual interface or there may be one common interface for all GRE tunnels in which case the traffic is somehow internally separated using the GRE key .

Stated in other words, the LMA detects that the received GRE key is an unknown, undefined or misused (i.e.

"wrong") tunnel key. Then, the LMA generates and sends a corresponding binding revocation reguest for reguesting that the respective binding is revoked or deleted in the binding cache of the MAG, so that the binding caches of LMA and MAG are synchronized again.

According to the present example, the LMA generates such reguest in the form of a binding revocation indication (BRI) message, in which the wrong uplink GRE key is included as a parameter. For example, the wrong uplink GRE key, i.e. the uplink GRE key detected to be wrong, may be included in a (vendor-specific) mobility option field or alternatively in a GRE key option field, i.e. in a wrong key option field. Additionally, the BRI message also includes a revocation trigger field which may include either an existing code (such as e.g. 129:

Revoking Mobility Node Local Policy) or a specific code (such as e.g. a wrong tunnel key option) . A specific code has to have a value greater than 128 so as to indicate that a group revocation (without a mobile node ID) is concerned, as detailed below.

Upon receipt of the revocation reguest, e.g. the BRI message, the MAG revokes or deletes the respectively reguested binding in its binding cache. That is, its binding cache entry relating to the mobile node, its binding (mobility session, and the corresponding

transport tunnel with its specific tunnel key is deleted. In this context, the MAG also matches or identifies the (one) PDN connection (ΡΜΙΡνβ connection when ΡΜΙΡνβ is used as the network-based mobility protocol) or mobility session concerned, i.e. the PDN/PMIPv6 connection or mobility session for which the wrong tunnel key was used, on the basis of said tunnel key, and releases the identified PDN/PMIPv6 connection or mobility session. Then, the MAG generates and sends a binding confirmation for confirming the effected binding revocation towards the LMA.

According to the present example, the MAG generates such confirmation in the form of a binding revocation

acknowledgement (BRA) message, in which the wrong uplink GRE key is included as a parameter. For example, the wrong uplink GRE key may be included in a (vendor- specific) mobility option field or alternatively in a GRE key option field, i.e. in a wrong key option field.

Additionally, the BRI message also includes an error code which may include either an existing code or a specific code (e.g. a wrong tunnel key option such as "wrong GRE key" or "wrong GRE key option") . As is outlined above, according to exemplary embodiments of the present invention, the exchanged request and confirmation messages in the form of BRI and BRA messages have a specific construction.

As regards the revocation request in the form of a BRI message, the content of such BRI message may be as follows .

Revocation Trigger = 129 (Revoking Mobility Node Local Policy) or alternatively "wrong GRE key"

Flags: (G)=l, (A)=l, (V)=0, (P)=l

MN-ID optional

(could e.g. be just meaning match with all MNs)

Optional Alternate-CoA = MAG' s IP address when the BRI is sent by LMA

Home-Network-Prefix-Option or IPv4-Address- Acknowledgement-Option containing the HNP/IPv4-HoA (i.e. IPv6 home network prefix or IPv4 home address) of the MN (The LMA finds these from the IP packet encapsulated inside the GRE tunnel. The address is the source IP address of the encapsulated IP

packet . )

Vendor-Specific-Mobility-Option or alternatively GRE-Key-Option containing the GRE uplink key.

Such construction is beneficial in that it enables an unambiguous identification of the binding cache entry to be revoked even in cases where the HoA (home address of the mobile node) may match multiple subscriptions and th mobile node identifier (MN-ID) is not known. Especially, in IPv4-HoA cases, where the mobile node has a home address of Internet Protocol version 4 (IPv4), multiple MNs may have overlapping IPv4 addresses. Namely, (GRE-) tunneled user traffic may use overlapping private IPv4 addresses. Overlapping address spaces (and IP packets) are separated using keyed GRE tunnels. The IPv6 ULA (unigue local addresses) addressing has the same problems as with overlapping IPv4 addresses, so

embodiments of the present invention apply to IPv6 user traffic as well (wherein in that case IPv4-HoA is to be replaced with IPv6-HNP) . When the wrong GRE key error situation gets triggered on the receiving Ρ ΙΡνδ node, it cannot send a BRI with IPv4-HoA it found from the tunneled user traffic IP packet, because on the sender side that IP address may match to multiple subscribers. And because the receiving Ρ ΙΡνβ node only has an IPv4- HoA that can match multiple subscribers and a stale GRE key, it cannot find the N identifier for that user traffic packet. Therefore, the BRI specified herein, which is sent to the sending Ρ ΙΡνβ node, contains the IPv4-HoA information and the GRE key information, so that the Ρ ΙΡνβ node sending user traffic can identify exactly one subscriber (mobile node) that must be removed.

Thus, by way of a BRI message construction as outline above, particularly due to the indication of the wrong GRE uplink key, it is possible to revoke a single such binding because of enabling that a group revocation without a N-ID matches a single binding in the MAG.

As regards the revocation confirmation in the form of a BRA message, the content of such BRA message may be as follows .

• Status set according what LMA was able to do, e.g.

0 for success Flags: (P)=l, (G)=l, (V) =0

Optional N-ID optional (when included must be the N-ID of the revoked Ns)

Optional Home-Network-Prefix-Option or IPv4- Address-Acknowledgement-Option containing the HNP/IPv4-HoA (i.e. IPv6 home network prefix or IPv4 home address) of the revoked N.

Optional Vendor-Specific-Mobility-Option or alternatively GRE-Key-Option containing the GRE uplink key.

The specific construction of these exemplary BRI and BRA messages represent a particular data structure according to exemplary embodiments of the present invention.

Figure 2 shows a signaling diagram of a second use case according to exemplary embodiments of the present invention . The present second use case depicted in Figure 2

essentially differs from the above first use case depicted in Figure 1 in that the roles of the MAG and the LMA are interchanged such that the MAG denotes a

terminating tunnel endpoint and the LMA denotes an originating tunnel endpoint. That is, downlink user traffic instead of uplink user traffic is concerned.

Accordingly, a downlink GRE key replaces the uplink GRE key used in the above first use case, since the

bidirectional GRE tunnel between MAG and LMA is utilized in the downlink direction.

Since the procedures of the present second use case are similar to those of the above first use case, except for the entities carrying out the respective procedures being interchanged, reference is made to the detailed

description in connection with Figure 1 above.

As regards the revocation request in the form of message, the content of such BRI message may be

follows .

• Revocation Trigger = 129 (Revoking Mobility Node Local Policy) or alternatively "wrong GRE key"

• Flags: (G)=l, (A)=l, (V)=0, (P)=l

• MN-ID optional

(could e.g. be just "*" meaning match all MNs)

• Home-Network-Prefix-Option or IPv4-Address- Acknowledgement-Option containing the HNP/IPv4-HoA

(i.e. IPv6 home network prefix or IPv4 home address) of the MN (The MAG finds these from the IP packet encapsulated inside the GRE tunnel. The address is the destination IP address of the encapsulated IP packet . )

• Vendor-Specific-Mobility-Option or alternatively GRE-Key-Option containing the GRE downlink key.

Such construction is beneficial for the same effects and due to the same reasons as described in connection with Figure 1 above.

• Status set according what MAG was able to do, e.g.

0 for success

• Flags: (P)=l, (G)=l, (V) =0 • Optional N-ID optional (when included must be the N-ID of the revoked Ns)

• Optional Home-Network-Prefix-Option or IPv4- Address-Acknowledgement-Option containing the HNP/IPv4-HoA (i.e. IPv6 home network prefix or IPv4 home address) of the revoked N.

• Optional Vendor-Specific-Mobility-Option or

alternatively GRE-Key-Option containing the GRE downlink key.

The specific construction of these exemplary BRI and BRA messages represent a particular data structure according to exemplary embodiments of the present invention. According to exemplary embodiments of the present invention, which relate to both use cases described above, a (vendor-specific) mobility option usable in respective revocation reguests (BRI) and conformations (BRA) may, but does not necessarily have to be,

constructed as follows.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Type I Length |D| Reserved |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1 GRE Key Identifier I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The above format also represents a particular data structure according to exemplary embodiments of the present invention. The ^Ό' flag defines whether the GRE key is for uplink TD' = 1) or downlink ( 'D' = 0) .

Using the above-explained way of requesting binding revocations, for example by way of BRI messages as outlined above, it is possible for a L A or a MAG to initiate revoking a mobility session where only a wrong GRE key for user traffic (from the receiver point of view) and possibly an overlapping HNP/IPv4-HoA are known If the receiver of the BRI is able to match a stale mobility session based on the GRE key and the HNP/IPv4- HoA, then the mobility session is silently removed. The mobility session can be silently removed, as the other end (the sender of the revocation BRI message) did not have a matching mobility session in its binding cache anymore .

If the false GRE key on the user traffic is due to packet corruption, the lower layer carrying the IP packet should exclude this with their own error checking mechanisms. Alternatively, the optional checksum in the GRE header should catch errors due to packet corruption. Anyway, in order to avoid dropping valid mobility sessions because of the small possibility of packet corruption, the BRI should (already) not be sent after the first received user traffic IP packet with a wrong GRE key, but only after multiple user traffic IP packets with a wrong GRE key have been received.

As indicated above in the exemplary BRI/BRA message constructions, such BRI/BRA messages may optionally contain address information which is useful for the revocation process. That is, such BRI/BRA messages may optionally contain tunneled IP packet source/destination addresses (depending on the traffic direction) . Those tunneled IP addresses may contain either the IPv6-HNP or the IPv4-HoA address . Generally, it is to be noted that a GRE tunnel key for the uplink direction is unigue for each local mobility anchor, and that a GRE tunnel key for the downlink direction is unigue for each pair of a mobile access gateway and a local mobility anchor.

Figure 3 shows a flowchart of a method at a terminating tunnel endpoint according to exemplary embodiments of the present invention. In view of the above, the thus described method may be executed at a local mobility anchor in the first use case or at a mobile access gateway in the second use case, i.e. the entity receiving user traffic over the tunnel.

According to the exemplary embodiment depicted in Figure 3, a method at the receiving side of the tunnel may comprise the following procedures, while for details reference is made to the foregoing description in connection with Figures 1 and 2.

In operation S310, a mobile node's user traffic may be received, which is indexed with a tunnel key, e.g. a GRE uplink or downlink key, via a transport tunnel, e.g. a GRE tunnel, from an originating tunnel endpoint, e.g. a MAG or LMA. In operation S320, a local binding cache may be searched for a transport tunnel with the received tunnel key for a binding between the mobile node's home and mobility addresses. In operation S330, a reguest for revoking the respective binding at the originating tunnel endpoint may be generated so that said reguest indicates said tunnel key, when the searching fails to find said tunnel key. This reguest may be generated as a BRI message including said tunnel key identified to be wrong as a parameter as well as, optionally, a specific revocation trigger indicating a wrong tunnel key option. In operation S340, the previously generated reguest, e.g. the thus constructed BRI message, may be sent to the originating tunnel endpoint, e.g. the MAG or LMA.

Although not illustrated, the method may also comprise that a confirmation of revoking the respective binding is received via the transport tunnel from the originating tunnel endpoint. This confirmation may be a BRA message optionally including an indication of a wrong tunnel key option as an error code. The operation of receiving user traffic and/or a

revocation confirmation may be accomplished by a

receiver, the operation of searching a binding cache and generating a revocation reguest may be accomplished by a processor, and the operation of sending the revocation reguest may be accomplished by a transmitter.

Figure 4 shows a flowchart of a method at an originating tunnel endpoint according to exemplary embodiments of the present invention. In view of the above, the thus described method may be executed at a mobile access gateway in the first use case or at a local mobility anchor in the second use case, i.e. the entity sending user traffic over the tunnel. According to the exemplary embodiment depicted in Figure 4, a method at the sending side of the tunnel may comprise the following procedures, while for details reference is made to the foregoing description in connection with Figures 1 and 2. In operation S410, a mobile node's user traffic may be sent, which is indexed with a tunnel key, e.g. a GRE uplink or downlink key, via a transport tunnel, e.g. a GRE tunnel, to a terminating tunnel endpoint, e.g. a L A or MAG. In operation S420, a reguest for revoking a binding between the mobile node's home and mobility addresses in a binding cache, e.g. a correspondingly constructed BRI message, may be received via said transport tunnel from said terminating tunnel endpoint, i.e. the LMA or MAG, said reguest indicating said tunnel key. In operation S430, the respective binding may be revoked in said binding cache. Although not illustrated, the method may also comprise - for example as a sub-procedure of the binding revocation - that a mobility session concerned is identified on the basis of said tunnel key included in the received reguest, and the identified mobility session is released or deleted. Also, the method may also comprise that a confirmation of revoking the respective binding is generated, e.g. as a BRA message constructed as outlined above, and sent via said transport tunnel to said terminating tunnel endpoint, i.e. the LMA or MAG.

The operation of sending user traffic and/or a revocation confirmation may be accomplished by a transmitter, the operation of receiving a revocation reguest may be accomplished by a receiver, and the operations of revoking a binding, generating a revocation conformation, as well as identifying and releasing a mobility session may be accomplished by a processor. 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.

Respective exemplary embodiments of the present invention are described below referring to Figures 5 and 6, while for the sake of brevity reference is made to the detailed description of respective corresponding methods and operations according to Figures 1 to 4, respectively.

In Figures 5 and 6 below, 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 Figures 5 and 6, 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

trans ferred . Further, in Figures 5 and 6, 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 reguired 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.

Figure 5 shows a schematic block diagram of an apparatus at a terminating tunnel endpoint according to exemplary embodiments of the present invention. In view of the above, the thus described apparatus may be implemented by or at a local mobility anchor in the first use case or a mobile access gateway in the second use case, i.e. the entity receiving user traffic over the tunnel.

According to Figure 5, the apparatus according to exemplary embodiments of the present invention is configured to perform any method as described in

conjunction with the L A according to Figure 1, the MAG according to Figure 2, and the flow according to Figure 3. Therefore, while basic operations are described hereinafter, reference is made to the above description for details.

According to an exemplary embodiment depicted in Figure 5, the thus depicted apparatus comprises a receiver and a transmitter, both constituting an interface towards the sending tunnel endpoint, as well as a processor and a binding cache.

The receiver may be configured to receive a mobile node's user traffic being indexed with a tunnel key via the transport tunnel from the originating, i.e. sending, tunnel endpoint, thus representing means for receiving such user traffic. The binding cache may be configured to store bindings between mobile nodes' home and mobility addresses for mobility sessions, thus representing means for storing mobile node bindings according e.g. to any underlying network-based mobility protocol such as

Ρ ΙΡνβ. The processor may be configured to search said binding cache for a transport tunnel with the received tunnel key for a binding between the mobile node's home and mobility addresses, thus representing means for searching the storing means for a specific tunnel key and/or binding. The processor may also be configured to generate a reguest for revoking the respective binding at the originating tunnel endpoint, such as a specifically constructed BRI message, said reguest indicating said tunnel key, when failing to find said tunnel key, thus representing means for generating such binding revocation reguest . The transmitter may be configured to send the thus generated reguest, e.g. BRI message, to the originating tunnel endpoint via said transport tunnel, thus representing means for sending such binding revocation reguest.

The receiver may also be configured to receive a confirmation of revoking the respective binding via said transport tunnel from said originating tunnel endpoint, such as a specifically constructed BRA message, thus representing means for receiving such binding revocation confirmation .

Figure 6 shows a schematic block diagram of an apparatus at an originating tunnel endpoint according to exemplary embodiments of the present invention. In view of the above, the thus described apparatus may be implemented by or at a mobile access gateway in the first use case or a local mobility anchor in the second use case, i.e. the entity sending user traffic over the tunnel.

According to Figure 6, the apparatus according to exemplary embodiments of the present invention is configured to perform any method as described in

conjunction with the MAG according to Figure 1, the LMA according to Figure 2, and the flow according to Figure 4. Therefore, while basic operations are described hereinafter, reference is made to the above description for details.

According to an exemplary embodiment depicted in Figure 6, the thus depicted apparatus comprises a receiver and a transmitter, both constituting an interface towards the receiving tunnel endpoint, as well as a processor and a binding cache.

The transmitter may be configured to send a mobile node's user traffic being indexed with a tunnel key via the transport tunnel to the terminating, i.e. receiving tunnel endpoint, thus representing means for sending such user traffic. The binding cache may be configured to store bindings between mobile nodes' home and mobility addresses for mobility sessions, thus representing means for storing mobile node bindings according e.g. to any underlying network-based mobility protocol such as

ΡΜΙΡνβ. The receiver may be configured to receive a reguest for revoking a binding between the mobile node' s home and mobility addresses in said binding cache via said transport tunnel from said terminating tunnel endpoint, such as a specifically constructed BRI message, said reguest indicating said tunnel key, thus

representing means for receiving such binding revocation reguest . The processor may be configured to revoke the respective binding in said binding cache, thus

representing means for revoking such binding or tunnel or mobility session.

The processor may also be configured to identify a mobility session concerned on the basis of said tunnel key, thus representing means for identifying a mobility session or PDN/P IPv6 connection associated with the tunnel key used for indexing the user traffic sent, and to release or delete the identified mobility session, thus representing means for releasing or deleting the thus identified mobility session or PDN/P IPv6

connection .

According to exemplary embodiments of the present invention, the above-described apparatuses may constitute a part of a corresponding network element such as a L A and/or MAG, as well as a serving gateway (SGW) and/or a packet data gateway (PGW) . A set of correspondingly connected and/or interoperating apparatuses may

constitute a system according to exemplary embodiments of the present invention. Such apparatuses and/or network elements may form part of an underlying communication system, such as for example WiMAX, WiMAX 2.0, 3GPP2 eHRPD, 3GPP EPC, which uses a network-based mobility protocol such as Ρ ΙΡνβ for (IP) mobility support or management .

In general, it is to be noted that respective functional blocks or elements according to above-described aspects can be implemented by any known means, either in hardware or software or firmware or any combination of hardware and/or software and/or firmware, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device .

Generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention. Devices and means can be

implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the

functionality of the device is preserved. Such and similar principles are to be considered as known to a skilled person.

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.

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

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

- method steps, functions, and/or devices, apparatuses, units or means likely to be implemented as hardware components at a terminal or network element, or any module (s) thereof, are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as OS (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; in addition, any method steps and/or devices, units or means likely to be implemented as software components may for example be based on any security architecture capable e.g. of authentication, authorization, keying and/or traffic protection; - 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.

The present invention also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable.

There are provided measures for binding revocation in network-based mobility. Such measures for binding revocation may for example comprise one or more of exchanging a mobile node' s user traffic being indexed with a tunnel key via a transport tunnel between an originating tunnel endpoint and a terminating tunnel endpoint, searching a binding cache for a transport tunnel with said tunnel key for a binding between the mobile node's home and mobility addresses, exchanging a reguest for revoking the respective binding and revoking the respective binding at the originating tunnel endpoint, said request indicating said tunnel key, when the searching fails to find said tunnel key.

Even though the invention is described above with reference to the examples according to the accompanying drawings, it is to be understood that the invention is not restricted thereto. Rather, it is apparent to a skilled person that the present invention can be modified in many ways without departing from the scope of the inventive idea as disclosed herein.

Claims

1. A method comprising

receiving a mobile node's user traffic being indexed with a tunnel key via a transport tunnel from an

originating tunnel endpoint,

searching a binding cache for a transport tunnel with said tunnel key for a binding between the mobile node's home and mobility addresses, and

generating and sending a reguest for revoking the respective binding at the originating tunnel endpoint via said transport tunnel, said reguest indicating said tunnel key, when the searching fails to find said tunnel key .

2. The method of claim 1, wherein

said reguest comprises a binding revocation

indication message containing a mobility option or tunnel key option field including an indication of said tunnel key.

3. The method of claim 2, wherein

said binding revocation indication message further contains a revocation trigger field including an

indication of a wrong tunnel key option.

4. The method of any one of claims 1 to 3, further comprising

receiving a confirmation of revoking the respective binding via said transport tunnel from said originating tunnel endpoint,

wherein said confirmation may be a binding

revocation acknowledgement message containing an error code including an indication of a wrong tunnel key option .

5. The method of any one of claims 1 to 4, wherein

the method is operable on the basis of a network- based mobility protocol such as a proxy mobile IP protocol, and/or

the transport tunnel is based on a generic routing encapsulation protocol, said tunnel key being a generic routing encapsulation key.

6. The method of any one of claims 1 to 5, wherein

the method is operable at a local mobility anchor, the originating tunnel endpoint is a mobile access gateway, the user traffic is uplink user traffic, and the tunnel key is an uplink key being unigue for said local mobility anchor, or

the method is operable at a mobile access gateway, the originating tunnel endpoint is a local mobility anchor, the user traffic is downlink user traffic, and the tunnel key is a downlink key being unigue for the pair of said mobile access gateway and said local mobility anchor.

7. An apparatus comprising

a receiver configured to receive a mobile node's user traffic being indexed with a tunnel key via a transport tunnel from an originating tunnel endpoint, a binding cache configured to store bindings between mobile nodes' home and mobility addresses for mobility sessions,

a processor configured to search said binding cache for a transport tunnel with said tunnel key for a binding between the mobile node's home and mobility addresses, and to generate a reguest for revoking the respective binding at the originating tunnel endpoint, said reguest indicating said tunnel key, when failing to find said tunnel key, and

a transmitter configured to send said reguest to the originating tunnel endpoint via said transport tunnel.

8. The apparatus of claim 7, wherein

said processor is configured to generate, as said reguest, a binding revocation indication message containing a mobility option or tunnel key option field including an indication of said tunnel key.

9. The apparatus of claim 8, wherein

said processor is configured to generate, as said reguest, said binding revocation indication message further containing a revocation trigger field including an indication of a wrong tunnel key option.

10. The apparatus of any one of claims 7 to 9, wherein said receiver is configured to receive a

confirmation of revoking the respective binding via said transport tunnel from said originating tunnel endpoint, wherein said confirmation may be a binding

11. The apparatus of any one of claims 7 to 10, wherein the apparatus is part of a network-based mobility system such as a proxy mobile IP system, and/or

12. The apparatus of claim 11, wherein

said network-based mobility system is at least one of a worldwide interoperability for microwave access system, an evolved high rate packet data system and an evolved packet core system.

13. The apparatus of any one of claims 7 to 12, wherein the apparatus is operable as or at a local mobility anchor, the originating tunnel endpoint is a mobile access gateway, the user traffic is uplink user traffic, and the tunnel key is an uplink key being unigue for said local mobility anchor, or

the apparatus is operable as or at a mobile access gateway, the originating tunnel endpoint is a local mobility anchor, the user traffic is downlink user traffic, and the tunnel key is a downlink key being unigue for the pair of said mobile access gateway and said local mobility anchor.

14. A method comprising

sending a mobile node's user traffic being indexed with a tunnel key via a transport tunnel to a terminating tunnel endpoint,

receiving a reguest for revoking a binding between the mobile node's home and mobility addresses in a binding cache via said transport tunnel from said terminating tunnel endpoint, said reguest indicating said tunnel key, and

revoking the respective binding in said binding cache .

15. The method of claim 14, further comprising identifying a mobility session concerned on the basis of said tunnel key, and

releasing the identified mobility session.

16. The method of claim 14 or 15, wherein

said reguest comprises a binding revocation

indication message containing a mobility option or tunnel key option field including an indication of said tunnel key .

17. The method of claim 16, wherein

indication of a wrong tunnel key option.

18. The method of any one of claim 14 to 17, further comprising

generating and sending a confirmation of revoking the respective binding via said transport tunnel to said terminating tunnel endpoint, wherein

said confirmation may be a binding revocation acknowledgement message containing an error code including an indication of a wrong tunnel key option.

19. The method of any one of claims 14 to 18, wherein the method is operable on the basis of a network- based mobility protocol such as a proxy mobile IP protocol, and/or

20. The method of any one of claims 14 to 19, wherein the method is operable at a mobile access gateway, the terminating tunnel endpoint is a local mobility anchor, the user traffic is uplink user traffic, and the tunnel key is an uplink key being unigue for said local mobility anchor, or

the method is operable at a local mobility anchor, the terminating tunnel endpoint is a mobile access gateway, the user traffic is downlink user traffic, and the tunnel key is a downlink key being unigue for the pair of said mobile access gateway and said local mobility anchor.

21. An apparatus comprising

a transmitter configured to send a mobile node's user traffic being indexed with a tunnel key via a transport tunnel to a terminating tunnel endpoint,

a binding cache configured to store bindings between mobile nodes' home and mobility addresses for mobility sessions,

a receiver configured to receive a reguest for revoking a binding between the mobile node' s home and mobility addresses in said binding cache via said transport tunnel from said terminating tunnel endpoint, said reguest indicating said tunnel key, and

a processor configured to revoke the respective binding in said binding cache.

22. The apparatus of claim 21, wherein said processor is configured to

identify a mobility session concerned on the basis of said tunnel key, and

release the identified mobility session.

23. The apparatus of claim 21 or 22, wherein said request comprises a binding revocation

24. The apparatus of claim 23, wherein

indication of a wrong tunnel key option.

25. The apparatus of any one of claim 21 to 24, wherein said processor is configured to generate and said transmitter is configured to send a confirmation of revoking the respective binding via said transport tunnel to said terminating tunnel endpoint, wherein

26. The apparatus of any one of claims 21 to 25, wherein the apparatus is part of a network-based mobility system such as a proxy mobile IP system, and/or

27. The apparatus of claim 26, wherein

28. The apparatus of any one of claims 21 to 27, wherein the apparatus is operable as or at a mobile access gateway, the terminating tunnel endpoint is a local mobility anchor, the user traffic is uplink user traffic, and the tunnel key is an uplink key being unigue for said local mobility anchor, or

the apparatus is operable as or at a local mobility anchor, the terminating tunnel endpoint is a mobile access gateway, the user traffic is downlink user traffic, and the tunnel key is a downlink key being unigue for the pair of said mobile access gateway and said local mobility anchor.

29. A computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to any one of claims 1 to 6.

30. A computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to any one of claims 14 to 20.