Method and device for adapting a data path for a mobile entity in a communication network

BACKGROUND OF THE INVENTION

The present invention relates to communications in a communication network, in particular to radio communication systems such as a 2nd generation system, e.g. a Global System for Mobile Communications (GSM) or a 3rd Generation

Partnership Project (3GPP) system, e.g. a Universal Mobile Telecommunications System (UMTS) or Long Term Evolution (LTE). In current communication networks it is possible to connect to a packet data network, for example the Internet, by means of a mobile entity like a mobile terminal. To this end, a mobile communication provider usually provides several entities like gateways that establish a connection to the packet data network for the mobile terminal.

For example, if a mobile terminal connects to a communication network via GPRS support nodes (GSN), e.g. a base station, a data path is fixedly allocated and established for the mobile terminal. In particular, every entity, over that data packets from and to the mobile terminal are to be transmitted, are set upon connection of the mobile terminal to the base station.

Hence, a data path is always allocated even when no data packets are present to be transmitted over the data path. Furthermore, the entities on the data path cannot be exchanged as long as the mobile terminal maintains its connection to the base station. Hence, if parameters of the network change during the connection of the mobile terminal, then the established data path may become sub-optimal. Accordingly, if a new data path should be allocated for the mobile terminal, then a connection of the mobile terminal to the base station is interrupted, thus temporarily losing a connection to the packet data network. In conventional communication systems like packet switched mobile systems, the standardization organisations like 3GPP and IETF considered for any mobile node, given a data path, that a strict length of the data path is used for mobility managed forwarding of data traffic. As a result, a single mobility binding entity (MBE) may be chosen by a packet data network (PDN) gateway (GW). A set of tunnels may be established between the mobile node and mobility binding entity.

Due to the strict conventional binding between the mobile node and the mobility binding entity, the mobility domain is fixed in size, independent on any mobility- related characteristics or mobility patterns of the mobile node. For example, wireless connected devices that do not move and, therefore, have a fixed location, have the same mobility domain as fully mobile devices.

For example, in the 3GPP EPC (Evolved Packet Core) standard, for each PDN connection of a mobile entity or mobile node, like user equipment (UE), a PDN gateway (GW) is chosen and a set of tunnels is established between the UE and the PDN GW. Here, it may be noted that more than one PDN data path may be established. However, the data traffic may be not seamlessly and dynamically balanced over these multiple PDN data paths. Moreover, 3GPP EPC provides a fixed mobility domain, i.e. optimal data path and transparent mobility using the same PDN GW, regardless of the mobility patterns of the user equipments. That means that the mobility domain size is the same, e.g. house appliances and smart phones have the same mobility domain. In both cases, for fully mobile UEs and those with restricted mobility, the same number of entities has to maintain mobility management associations, e.g. eNodeB, Serving- GW (S-GW), and PDN GW. Further, tunnels have to be established between the same numbers of entities.

For offloading traffic, 3GPP may flexibly select a PDN GW based on access point name (APN). Said offloading may be not adjusted dynamically.

Recapitulating, a fixed mobility domain is conventionally defined for each UE and for each PDN connection. Thus, a pre-configuration is needed dependent on offline network planning and dimensioning. For example, nearly-fixed devices, including those with restricted mobility, are handled the same way with respect to mobility management functionality with mobile devices. The mobility domain is fixed, needs to be preconfigured for deployment independent on the mobility pattern of the users. Moreover, new PDN connections have to be established for parts or complete data traffic in case the mobility domain has to be modified, e.g. for offloading data traffic.

SUMMARY OF THE INVENTION

A goal to be achieved by the present invention is to provide an improved data path binding in a communication network.

According to a first aspect, a method for adapting a data path for a mobile entity in a communication network is suggested. The communication network has at least one forwarding entity for providing data packets for the data path and a plurality of mobility binding entities for forwarding data packets on the data path, wherein a first mobility binding entity is allocated to the data path for the mobile entity according to binding information for the mobile entity. The method has a step of receiving a re-allocation request for re-allocating a second mobility binding entity to the data path for the mobile entity, a step of updating the binding information for the mobile entity on the basis of the received re-allocation request, a step of forwarding data packets received from the forwarding entity by the first mobility binding entity to the second mobility binding entity until the updated binding information is received at the forwarding entity, and/or a step of forwarding data packets from the forwarding entity to the second mobility binding entity after the updated binding information is received at the forwarding entity.

As a result, a self-adaptive procedure for data path binding maintenance in a communication network is provided which reactively updates the binding

information on the forwarding entities. Because the binding of the data path is changed from the first mobility binding entity to the second mobility binding entity (MBE), the first mobility binding entity may be also called source MBE and the second mobility binding entity may be called target MBE. The re-allocation request may be a request for substituting the source MBE by the target MBE in the data path for the mobile entity.

The re-allocation request may include an identity indication indicating the target MBE. The re-allocation request may be received by the source MBE. The source MBE may then have the identity indication of the target MBE. Because the source MBE knows the identity indication and therefore the identity of the target MBE, the source MBE may forward data packets to the target MBE. In the time interval between the reception of the re-allocation request and the reception of the updated binding information by the forwarding entity, the forwarding entity may remain unaware of the MBE re-allocation. Thus, the forwarding entity may continue to send packets to the source MBE. Because the source MBE may create a binding with the target MBE to forward the data packets to the target MBE, the packets are not omitted. In other words, because the data packets sent from the forwarding entity to the source MBE are forwarded from the source MBE to the target MBE, packet losses are prevented. In detail, the data path may be re-allocated without packet loss, because data packets follow the data path binding through the forwarding entity, the source mobile entity and the target mobile entity until the forwarding entity receives the updated binding information. When the forwarding entity received the update binding information, the data path is shifted to the sequence of the forwarding entity and target MBE.

According to some implementations the method may also receive the re-allocation request at the forwarding entity from the first mobility binding entity, update the binding information for the mobile entity on the forward entity and/or forward data packets toward the mobile entity from the forwarding entity to the second mobility binding entity.

According to some implementation, this procedure may not influence the packets in transit. Thus, no buffering of data packets may be required. According to some implementations, the mobility binding entity (MBE) is only reallocated after receiving a re-allocation request. Thus, the data path is only updated when required. Further, according to some implementations, no data path may be established through the target MBE unless data traffic has to be forwarded even though a target MBE is selected for the mobile entity.

According to some implementations, the updated binding information may be transmitted as a reaction to the forwarding entity forwarding a packet to or from the mobile entity. Moreover, according to some implementations, no binding information or mobile binding information may be updated in a forwarding entity, unless this forwarding entity forwarded at least one data packet to or from the mobile entity.

According to some implementations, the re-allocation request may be a re- selection request. Re-allocation may include that one mobility binding entity is already allocated to the data path for the mobile entity and the already allocated mobility binding entity is substituted by another mobility binding entity.

According to some implementations, a decision of data path self-adaptation or re- allocation may be dynamically taken based on different parameters, such as network load, mobile entity, mobility or the like.

By the present self-adaptive procedure for data path binding, data traffic forwarded through an operator network may be more dynamically controlled, in particular at different levels of granularity. In particular, the source MBE may use Traffic Flow Template (TFT) to differentiate data traffic that has to be sent to the target MBE. Furthermore, the forwarding entity may forward traffic through traffic filtering to multiple MBEs at the same time. According to some implementations, the present procedure may provide reduced signalling in case that there is no data traffic from or to the mobile entity.

Moreover, according to some implementations, no modification of the network forwarding mechanism such as IP routing is necessary. According to some implementations, the present procedure may be used on top of a variety of forwarding mechanisms and may not modify forwarding mechanism of the underlying network transport.

According to some implementations, a mobility binding entity (MBE) may be any entity which is configured to forward data packets on the data path. Further, the forwarding entity may be any entity which is configured to provide data packets for the data path. The mobile entity may be a mobile node, for example a user equipment, a mobile phone or a smart phone. According to a first implementation form of the first aspect, the method has a step of receiving the re-allocation request at the first mobility binding entity, a step of updating the binding information for the mobile entity on the basis of the received re-allocation request by the first mobility binding entity, and a step of transmitting the updated binding information from the first mobility binding entity to the forwarding entity.

In the first implementation form, the first or source MBE may be the entity which receives the re-allocation request. The re-allocation request may be the event triggering the data path binding update. In detail, the source MBE may receive data packets from the forwarding entity, because this may be the only known path between the forwarding entity and the MBE for their specific mobile entity. The data packets may be sent from the mobile entity or to the mobile entity. This means uplink and downlink is possible.

Since the received packet is for or from the mobile entity that has changed its MBE association as a result of the re-allocation request from source MBE to target MBE, the source MBE proceeds with the update of the data path binding. That means that the source MBE is the entity for updating the binding information in this first implementation form. Further, the source MBE forwards the data packets received from the forwarding entity to the target MBE using the data path binding

information, in particular an identity indication indicating the identity of the target MBE. Said identity indication may be part of the re-allocation request. Further, the source MBE may send the forwarding entity the new binding information in the form of the updated binding information for the specific mobile entity. For the time interval between a first instance of time when receiving the reallocation request by the source MBE and the second instance of time when the updated binding information is received at the forwarding entity, data packets are passing through the data path [forwarding entity - source MBE - target MBE], for both uplink and downlink. Further, when the forwarding entity receives the transmitted updated binding information from the source MBE, the forwarding entity replaces the data path binding information with the newly received updated binding information. This may enable the forwarding entity to forward packets to the target MBE instead of the source MBE for the specific mobile entity. Thus, after receiving the updated binding information, the forwarding entity may forward data packets to the target MBE. Thus, for both uplink and downlink, data packets may pass through the data path [forwarding entity - target MBE].

According to a second implementation form of the first aspect, the method has a step of receiving the re-allocation request at the first mobility binding entity, said re-allocation request including an identity indication indicating an identity of the second mobility binding entity, a step of extracting the identity indication from the received re-allocation request, and a step of forwarding data packets received from the forwarding entity by the first mobility binding entity to the second mobility binding entity on the basis of the extracted identity indication until the updated binding information is received at the forwarding entity.

According to a third implementation form of the first aspect, the method has a step of receiving the re-allocation request at the second mobility binding entity, a step of updating the binding information for the mobile entity on the basis of the received re-allocation request by the second mobility binding entity, and a step of transmitting the updated binding information from the second mobility binding entity to the first mobility binding entity and to the forwarding entity. According to a fourth implementation form of the first aspect, the method has a step of creating a binding between the first mobility binding entity and the second mobility binding entity for a time interval between a first instance of time when receiving the re-allocation request and a second instance of time when the updated binding information is received at the forwarding entity. The binding may be a mobile binding, in particular including a mobile context. The mobile context may include at least one of the following: a Policy and

Charging Control (PCC), a Quality of Service (QoS) rule and/or an Internet Protocol (IP) tunnel establishment. According to a fifth implementation form of the first aspect, the data path is allocated for the data traffic such that the data path has the mobile entity, the one forwarding entity and the first mobility binding entity and/or the second mobility binding entity.

According to a sixth implementation form of the first aspect, the data path is allocated for the data traffic in dependence on the binding information for the mobile entity such that the data path has different entities in different times. Before the first instance of time when the re-allocation request is received, the data path has the mobile entity, the one forwarding entity and the first mobility binding entity. Between the first instance of time and the second instance of time when the updated binding information is received at the forwarding entity, the data path has the mobile entity, the one forwarding entity, the first mobility binding entity and the second mobility binding entity. After the second instance of time, the data path has the mobile entity, the one forwarding entity and the second mobility binding entity. According to a seventh implementation form of the first aspect, the data traffic is transmitted on the data path from the mobile entity to the allocated mobility binding entity via the one forwarding entity, if the data traffic originates from the mobile entity. Thus, the data traffic is transmitted over an uplink data path. According to an eighth implementation form of the first aspect, the data traffic is transmitted on the data path from the one forwarding entity to the mobile entity via the allocated mobility binding entity, if the data traffic is targeted at the mobile entity. Therefore, the data traffic is transmitted over a downlink data path.

According to a ninth implementation form of the first aspect, a first data path is allocated for uplink data traffic and a second data path is allocated for downlink data traffic, wherein the binding information for the first data path and the second data path are updated simultaneously.

According to a tenth implementation form of the first aspect, when the one forwarding entity receives a data packet from a certain mobility binding entity, the one forwarding entity establishes a reverse data path through the certain mobility binding entity.

According to an eleventh implementation form of the first aspect, a plurality of independent forwarding entities is provided for allocating a plurality of data paths to the mobile entity.

In detail, for both uplink and downlink, the forwarding entities may be independent of each other. Thus, multiple data paths may be used simultaneously and may be seamlessly interchanged. For example, if the forwarding entities are embodied as eNodeBs or access points and the MBEs are gateways inside an operator domain, the mobile entity may be connected simultaneously over multiple access networks, e.g. multi-interface mobile nodes. Further, if the forwarding entities are entities at the border of the operator domain and the MBEs are gateways located close to the mobile entity, then the data traffic of the mobile entity may be received from the IP domain over multiple core network links without requiring indirection to any central entity such as a Proxy Gateway (P-GW). Moreover, multiple MBEs may be used simultaneously for the same mobile entity if a policy-based decision is made, e.g. multi-path support permission.

Furthermore, a splitting or a merging of mobile node data traffic may be possible, in particular if the gateways have flow-based detection functionality. As a result, multiple data paths may be used at the same time through one single MBE. According to a twelfth implementation form of the first aspect, the mobility binding entity is embodied by an access network gateway, an access router, an eNodeB, an access point/base station or a forwarding entity at a border of an operator domain.

According to a thirteenth implementation form of the first aspect, the forwarding entity is embodied by an eNodeB, an access point/base station, an access router or an backhaul entity for forwarding data packets towards at least one gateway. Any implementation form of the first aspect may be combined with any

implementation form of the first aspect to obtain another implementation form of the first aspect.

According to a second aspect, the invention relates to a computer program comprising a program code for executing the method for adapting a data path for a mobile entity in a communication network when run on at least one computer.

According to a third aspect, a device for adapting a data path for a mobile entity in a communication network having at least one forwarding entity for providing data packets for the data path and a plurality of mobility binding entities for forwarding data packets on the data path, a first mobility binding entity being allocated to the data path for the mobile entity according to binding information for the mobile entity, the device comprising:

a receiving entity for receiving a re-allocation request for re-allocating a second mobility binding entity to the data path for the mobile entity,

an updating entity for updating the binding information for the mobile entity on the basis of the received re-allocation request,

a first forwarding entity for forwarding data packets received from the forwarding entity by the first mobility binding entity to the second mobility binding entity until the updated binding information is received at the forwarding entity, and a second forwarding entity for forwarding data packets from the forwarding entity to the second mobility binding entity after the updated binding information is received at the forwarding entity.

The receiving entity may be any receiver or any receiving means. Furthermore, the updating entity may be any updating means. Moreover, the respective forwarding entity may be any forwarding means.

The respective means, in particular the receiving entity, the updating entity and the respective forwarding entity, may be implemented in hardware or in software. If said means are implemented in hardware, it may be embodied as a device, e.g. as a computer or as a processor or as a part of a system, e.g. a computer system. If said means are implemented in software it may be embodied as a computer program product, as a function, as a routine, as a program code or as an executable object.

According to a fourth aspect, a system, in particular a communication system is suggested, said system comprising at least one device for adapting a data path for mobile entity in a communication network. BRIEF DESCRIPTION OF THE DRAWINGS

Further embodiments of the invention will be described with respect to the following figures in which: Fig. 1 shows an implementation form of a method for adapting a data path for a mobile entity in a communication network,

Fig. 2 shows an implementation form of an arrangement for carrying out the steps of Fig.1 , Fig. 3 shows an implementation form of a data path according to the third step of Fig. 1 ,

Fig. 4 shows an implementation form of a data path according to the fourth step of Fig. 1 ,

Fig. 5 shows a preparation procedure according to an implementation form,

Fig. 6 shows an operation procedure for downlink data according to an

implementation form,

Fig. 7 shows an operation procedure for uplink data according to an

implementation form, and Fig. 8 shows an implementation form of a device for adapting a data path for a mobile entity in a communication network.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION In Fig. 1 , an embodiment of a method for adapting a data path for a mobile entity in a communication network is depicted.

The implementation form of the method of Fig. 1 has the method steps 101 , 103, 105 and 107 and is described with reference to the arrangement 200 of Fig. 2, said arrangement 200 of Fig. 2 being configured to carry out the steps 101 -107 of Fig. 1 .

The arrangement 200 of Fig. 2 shows a mobile node (MN) 201 , a forwarding entity (FE) 203 coupled to the MN 201 and a further forwarding entity (FE) 205. Between the two forwarding entities (FE) 203 and 205, there are two mobility binding entities (MBE) 207 and 209 coupled. With attaching the MN 201 to the arrangement 200, exemplarily embodied by a communication network, the MBE 207 is allocated to the MN 201 . Thus, the MBE 207 is also called source MBE 207.

The source MBE 207 is allocated to the data path for the MN 201 according to binding information for the mobile entity 201 .

In step 101 , a re-allocation request for re-allocating a second or target MBE 209 to the data path for the MN 201 is received. Re-allocation may mean that the allocation of the source MBE 207 to the data path for the MN 201 is deleted and the target MBE 209 is allocated to said data path instead. For example, said reallocation request may be received by the source MBE 207. In step 103, the binding information for the MN 201 is updated on the basis of the received re-allocation request. Said updating may be performed by the source MBE 207.

In step 105, data packets received from the forwarding entity 203 or 205 are forwarded by the source MBE 207 to the target MBE 209 until the updated binding information is received at the forwarding entity 203 or 205. For uplink, it is the forwarding entity 203. In contrast, for downlink, it is the forwarding entity 205.

In this regard, Fig. 3 shows an implementation form of a data path 300 according to the third step of Fig. 1 . In the case of Fig. 3, a binding between the source MBE 207 and the target MBE 209 may be created at least for a time interval between a first instance of time when the re-allocation request is received and a second instance of time when the updated binding information is received at the forwarding entity 203 (for uplink) or 205 (for downlink; not shown). In step 107, data packets from the forwarding entity 203 or 205 are forwarded to the target MBE 209 after the updated binding information is received at the forwarding entity 203 or 205. As above, for uplink, this is the forwarding entity 203. In contrast, for downlink, it is the forwarding entity 205.

Further, Fig. 4 shows an implementation of a data path according to the step 107. Data packets - illustrated by the arrows - are received by a forwarding entity 203 (uplink) or 205 (downlink, not shown) and directly forwarded to the target MBE 209 which may forward it to further entities in the communication network. A bridge over the source MBE 207 may be not necessary in step 107, because the forwarding entity 203 has already received the updated binding information and knows the identity of the target MBE 209.

Recapitulating, the data path is allocated for the data traffic in dependence on the binding information for the MN 201 such that the data path may have different entities in different times. Before the first instance of time when the re-allocation request is received, the data path has the mobile entity 201 , the forwarding entity 203 or 205 and the source MBE 207. Between the first instance of time and the second instance of time, when the updated binding information is received at the forwarding entity 203 or 205, the data path has the mobile entity 201 , the forwarding entity 203 and the forwarding entity 205, the source MBE 207 and the target MBE 209. After the second instance of time, the data path has the mobile entity 201 , the one forwarding entity 203 or 205 and the target MBE 209. The source MBE 207 and the target MBE 209 may be embodied by an access network gateway, an access router, eNodeB, an access point/base station or a forwarding entity at a border of an operator domain, respectively. Further, the forwarding entities 203 and 205 may be embodied by an eNodeB, an access point/base station, an access router or a backhaul entity for forwarding data packets towards at least one gateway, respectively. In Fig. 5, a preparation procedure according to an implementation form is illustrated.

Fig. 5 shows a preparation procedure according to an implementation form which may be performed by a communication system 500. The communication system 500 of Fig. 5 has a mobile node (MN) 501 , a base station (BS) 503, a source MBE 505, a target MBE 507 and forwarding entities border (FE-BR) 509, 51 1 , 513. Without loss of generality, Fig. 5 shows three forwarding entities border (FE-BR) 509, 51 1 , 513. In Fig. 5, the drawn-through double arrows show that strict forwarding information is available. Further, the dashed double arrow shows that loose information is available. The single arrow shows an active procedure step.

The example of Fig. 5 shows a strict binding between the MN 501 and the BS 503 and a loose path towards the IP domain. The strict binding is shown by a UL & DL connection. The loose paths towards the IP domain are shown by a respective loose DL connection (dashed double arrow).

The BS 503 represents the entity to which the MN 501 is strictly bound to for communication. For the example of an Evolved Packet Core (EPC), the BS 503 may be represented by an eNodeB.

The respective MBE 505 and 507 represents a data path gateway to which the MN 501 has to maintain a mobility binding. For the example EPC, the MBE 505 and 507 may be represented by a PDN (Packet Data Network) GW (Gateway) or a PDN & Serving GW. Further, the MBE 505 and 507 may be required for subscriber-based bearer allocation and Policy and Charging Control (PCC).

Moreover, the forwarding entity border (FE-BR1 , FE-BR2, FE-BR3) 509, 51 1 , 513 is a function which forwards data traffic from/to the MN 501 to/from the IP domain. As indicated above, in the example of Fig. 5, three FE-BRs 509, 511 , 513 are considered. The FE-BRs 509, 51 1 , 513 are able to forward data traffic to the MN 501 through the source MBE 505 having a data path binding for the MN 501. This is referred to as a loose DL connection. The MN 501 may be bound to more than one BS 503 at the same time. However, in this example, it is considered that the MN 501 is bound to only one BS 503. This presumes that the downlink (DL) data traffic has to reach that specific BS 503 in order to be forwarded to the MN 501 . The path BS-MN may have a 1 -to-1 binding. In the following, two different examples of operation are given. Fig. 6 shows an example for uplink (UL), and Fig. 7 shows an example for downlink (DL).

Thus, a UL and a DL path may be established between the BS 503 and the source MBE 505. Optionally, it may include PCC procedures on the BS 503 and on the source MBE 505. The source MBE 505 receives data packets addressed to the MN 501 from any FE-BR 509, 511 , 513. The source MBE 507 may forward data packets to any FE-BR 509, 51 1 , 513 according to an underlying routing

mechanism. The source MBE 505 maintains for the MN 501 the binding:

[MN identity, IP address, IMSI, BS, ^* ],

wherein DL data traffic for the MN 501 is to be forwarded to the BS 503 illustrated by BS in the above binding, and UL data traffic may be sent to any FE-BR 509, 51 1 , 513 illustrated by ^* .

In step 1 of Fig. 5, a re-selection decision is made by the source MBE 505 for the MN 501 to use the target MBE 507. The re-selection or re-allocation decision may be received from exterior triggers such as from the target MBE 507 as an attachment of the MN 501 through another BS (not shown), i.e. access network handover. Further, administrative means such as maintenance operations may be used. In step 2, the source MBE 505 transmits the forwarding information for the MN 501 to the target MBE 507: [MN identity, IP address, IMSI, BS, ^* ],

wherein the UL data traffic for the MN 501 has to be forwarded to BS 503, and where the data traffic may be sent to any FE-BR 509, 51 1 , 513 illustrated by ^* . Further, the target MBE 507 stores the transmitted forwarding information and knows where to send the data traffic from/to the MN 501 .

In step 3, the source MBE 505 stores the identity of the target MBE 507 in the following forwarding entry:

[MN identity, IP address, IMSI, target MBE, target MBE],

wherein the first mentioned target MBE means that the data traffic for the MN 501 has to be forwarded to the target MBE 507, and wherein the second mentioned target MBE means that UL data traffic may be sent to the target MBE 507.

As a result, all data packets associated to the MN 501 will now be forwarded through the target MBE 507.

It may be noted that in step 2, the target MBE 507 may request PCC rules from the PCRF (Policy Control and Charging Rules Function). As the data traffic may all be forwarded through the target MBE 507, a single PCEF (Policy Control and Charging Enforcement Function) may be used for charging - the one on the target MBE 507 after step 2.

As already indicated above, Fig. 6 shows an operation procedure for downlink data according to an implementation form which may be performed by the communication system 500. The communication system 500 of Fig. 6 corresponds to that of Fig. 5.

The prerequisites for the example of Fig. 6 are that the preparation procedure of Fig. 5 was executed and the following information is available:

BS: [MN Identity, IP Address, IMSI, MN, source MBE]

Source MBE: [MN Identity, IP Address, IMSI, target MBE, Target MBE] Target MBE: [MN Identity, IP Address, IMSI, BS, ^* ]

FE-BRs: [MN Identity, IP Address, IMSI, source MBE, ^* ]

In step 1 , an UL data packet is sent by the MN 501 to the BS 503.

In step 2, the BS 503 sends the data packet to the source MBE 505 according to its UL mobility binding information.

In step 3, the source MBE 505 checks the data path information and sends the data packet to target MBE 507 according to its UL mobility binding information.

In step 4, the data packet is received by the target MBE 507, a forwarding decision is made and it is forwarded to the appropriate FE-BR, e.g. FE-BR1 509, which subsequently sends it to the IP domain.

In step 5, the source MBE 505 sends a forwarding information message to the BS including: [MN identity, IP address, IMSI, MN, target MBE]

In step 6, the BS 503 stores the new forwarding information to forward UL packets to target MBE 507. As a result, the BS 503 is forwarding UL data packets directly to the target MBE 507.

In step 7, based on the data packet received from the target MBE 507 to be forwarded to the IP domain, the FE-BR1 509 may optionally determine that the new MBE of the MN 501 is the target MBE 507 and to change internally its data path binding information to [MN Identity, IP Address, IMSI, target MBE, ^* ].

As a result, the FE-BR1 509 is forwarding the DL data packets to the target MBE 507. Fig. 7 shows an operation procedure for uplink data according to an implementation form which may be performed by a communication system 500 corresponding to that of Figs. 5 and 6. The prerequisite for the example of Fig. 7 are that the preparation procedure of Fig. 5 was executed and the following information is available:

BS: [MN Identity, IP Address, IMSI, MN, source MBE]

Source MBE: [MN Identity, IP Address, IMSI, target MBE, target MBE]

Target MBE: [MN Identity, IP Address, IMSI, BS, ^* ]

FE-BRs: [MN Identity, IP Address, IMSI, source MBE, ^* ]

[ ^* , ^* , ^* MBE1 , MBE1]

In step 1 , the DL packet is received by FE-BR2 51 1 from the IP domain addressed to the MN 501 .

In step 2, the FE-BR2 51 1 sends the data packet to the source MBE 505

according to its DL mobility binding information.

In step 3, the source MBE 505 checks the data path binding information and sends the data packet to the target MBE 507 according to its DL mobility binding information.

In step 4, the data packet is received by the target MBE 507, a forwarding decision is made and is forwarded to the BS 503 which sends it to the MN 501 .

In step 5, the source MBE 505 sends a forwarding information message to the FE- BR2 51 1 including: [MN Identity, IP Address, IMSI, target MBE, ^* ].

In step 6, the FE-BR2 51 1 stores the new forwarding information to forward DL data packets to target MBE 507. As a result, the FE-BR2 511 is forwarding data packets directly to the target MBE 507. As no data traffic was received over FE-BR1 509 or FE-BR3 513, the loose DL routes for these entities remain on the source MBE 505. In step 7, based on the data packet received from the target MBE 507 to be forwarded to the MN 501 , the BS 503 may optionally determine that a new MBE is the target MBE 507 and to change internally its data path binding information to: [MN Identity, IP Address, IMSI, MN, target MBE]. This information is already available in case of an uplink data transfer previous to the downlink data transfer.

According to some implementations, the present self-adaptation of the binding may be easily deployed even in transition stages from EPC (Evolved Packet Core) to flat architectures. This may be employed, for example, with:

FE in eNodeB and MBE in S-GW/PDN GW (for UL), and

FE in IP domain of operator and MBE on PDN GW (for DL).

Fig. 8 shows an implementation form of a device 801 for adapting a data path for a mobile entity in a communication network. The communication network has at least one forwarding entity for providing data packets for the data path and a plurality of mobility binding entities for forwarding data packets on the data path. A first mobility binding entity is allocated to the data path for the mobile entity according to binding information for the mobile entity.

The device 801 has a receiving entity 803, an updating entity 805, a first forwarding entity 807, and a second forwarding entity 809.

The receiving entity 803 is configured to receive a re-allocation request for reallocating a second mobility binding entity to the data path for the mobile entity. The updating entity 805 is configured to update the binding information for the mobile entity on the basis of the received re-allocation request. Further, the first forwarding entity 807 is configured to forward data packets received from the forwarding entity by the first mobility binding entity to the second mobility binding entity until the updated binding information is received at the forwarding entity.

Moreover, the second forwarding entity 809 is configured to forward data packets from the forwarding entity to the second mobility binding entity after the updated binding information is received at the forwarding entity.