WO2012113155A1

WO2012113155A1 - Method for managing a data path, mobility controller and communication system

Info

Publication number: WO2012113155A1
Application number: PCT/CN2011/071312
Authority: WO
Inventors: Qing Zhou; Konstantinos Pentikousis; Cornel Pampu; Marius CORICI; Dragos VINGARZAN; Thomas MAGEDANZ
Original assignee: Huawei Technologies Co Ltd; Fraunhofer Gesellschaft zur Foerderung der Angewandten Forschung eV
Current assignee: Huawei Technologies Co Ltd; Fraunhofer Gesellschaft zur Foerderung der Angewandten Forschung eV
Priority date: 2011-02-25
Filing date: 2011-02-25
Publication date: 2012-08-30
Anticipated expiration: 2013-08-25
Also published as: CN102893662A

Abstract

In a method for managing a data path for a mobile entity (110) attached to a communication network, the communication network has a plurality of mobility binding entities (161, 162) for forwarding data traffic. A first mobility binding entity of the plurality of mobility binding entities (161, 162) is allocated to the data path for the mobile entity (110). In response to an update request for allocating mobility binding entity to the mobile entity (110), a second mobility binding entity of the plurality of mobility binding entities (161, 162) is allocated to the data path for the mobile entity (110). The allocation is based on at least one mobility parameter of the mobile entity (110).

Description

DESCRIPTION

Method for managing a data path, mobility controller and communication system

TECHNICAL FIELD

The invention relates to the field of communication networks and in particular to mobile communication networks.

BACKGROUND OF THE INVENTION

In current communication networks it is possible to connect to a packet data network, for example the Internet, by means of 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 a GPRS support node (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. SUMMARY OF THE INVENTION

It is the object of the present invention to provide an efficient concept for managing a data path for mobile communications.

This object is achieved by the features of the independent claims. Further embodiments are apparent from the dependent claims. The present invention is based on the finding that a quality and efficiency of a data path of a mobile entity connected to a communication network may depend on various parameters of the mobile entity which can change during the time of the mobile entity being attached to the network. If another data path can be found that suits better to the momentary parameters of the mobile entity, a data path can be altered while a connection of the mobile entity to the communication network remains established. Hence, the data path can be changed for the mobile entity without the need for detaching the mobile entity from the network and loosing a connection, for example, to a packet data network. According to a first aspect, the invention relates to a method for managing a data path for a mobile entity attached to a communication network. The communication network has a plurality of mobility binding entities for forwarding data traffic. A first mobility binding entity of the plurality of mobility binding entities is allocated to the data path for the mobile entity. In response to an update request for allocating a mobility binding entity to the mobile entity, a second mobility binding entity of the plurality of mobility binding entities is allocated to the data path for the mobile entity. The allocation, in particular the allocation of the second mobility binding entity, is based on at least one mobility parameter of the mobile entity. Hence, the at least one mobility parameter of the mobile entity determines which of the available mobility binding entities is selected and allocated to the data path for the mobile entity. For example, the mobile entity remains attached to the communication network during allocation of the second mobility binding entity. Hence, existing data connections of the mobile entity may not be dropped or lost through the change of the data path.

According to a first implementation form of the first aspect, the invention relates to a method, wherein the at least one mobility parameter includes at least one of the following: an identity of a subscriber using the mobile entity, a location of the mobile entity, a subscription profile of the mobile entity, a required Quality of Service, QoS, of the mobile entity, mobility characteristics of the mobile entity, resource characteristics of the mobile entity.

For example, a subscriber has several mobile entities but only one contract that allows him to use all of his mobile entities for data connections. If the entity that performs the allocation recognizes the identity of the subscriber, the decision which mobility binding entity to allocate can be made based on known contract parameters of the identified subscriber. If the mobile entity has attached to the communication network at one location and, for example, is moved to another location, a data path may become sub-optimal due to the changed location of the mobile entity. Hence, another mobility binding entity can be selected and allocated to the data path, which may be better suitable for the changed location.

The allocation decision may be made depending on contract parameters of the mobile entity like the subscription profile or a required QoS. For example, different mobility binding entities may be allocated if the subscriber of the mobile entity has a premium contract, in contrast to a prepaid contract. Furthermore, some mobility binding entities may be reserved for mobile entities having special data contracts according to some implementation forms. The mobility characteristics may include whether the mobile entity is used in a static position or in a moving position. For example, if the mobile entity is attached to the communication network with an assumed static profile, a first mobility binding entity suitable for static locations may be allocated. If the mobile entity starts to moving around, for example in a car or a train, a second mobility binding entity can be allocated to the data path for the mobile entity which suits better for moving positions. According to some implementation forms, the allocation decision can also be made based on the data rates which are needed by the mobile entity. For example, a first mobility binding entity is allocated for data traffic with lower data rates like e- mail or instant messaging, while a second mobility binding entity may be adapted for higher data rates like video streaming etc. The second mobility binding entity may then be allocated, if the mobile entity starts using or requesting higher data rates.

As described before, the allocation of the second mobility binding entity can be based on the mobility parameter of the mobile entity. However, according to some implementation forms, also the allocation of the first mobility binding entity may be based on the above described mobility parameter of the mobile entity. Hence, for the initial allocation of a mobility binding entity to a data path for the mobile entity, a data path suitable for the mobile entity can be selected, in contrast to a static selection depending on network parameters only.

According to a second implementation form of the first aspect, the invention relates to a method, wherein the first mobility binding entity is deallocated after allocation of the second mobility binding entity. Hence, data traffic is forwarded via the first mobility binding entity before the allocation of the second mobility binding entity, and via the second mobility binding entity after its allocation. Accordingly, the resources of the first mobility binding entity can be set free as the data path over the first mobility binding entity is not needed after allocation of the second mobility binding entity.

According to another implementation form, the invention relates to a method wherein the mobile entity data traffic can be handed over from the first mobility binding entity to the second mobility binding entity while the two mobility binding entities are allocated.

According to a third implementation form of the first aspect, the invention relates to a method, wherein the communication network includes a plurality of forwarding entities. At least one of the plurality of forwarding entities is assigned to the mobile entity. An information about the allocation is transmitted to the one forwarding entity. For example, a data connection is established on the data path between the allocated mobility binding entity and the one forwarding entity. According to some implementation forms, the data path includes the one forwarding entity and the first mobility binding entity before the second mobility binding entity is allocated, and includes the one forwarding entity and the second mobility binding entity after its allocation. For example, data traffic is forwarded from the one forwarding entity to the respective mobility binding entity allocated to the data path.

According to some implementation forms, the update request is made by the one forwarding entity. For example, the request is made by the one forwarding entity, if a sub-optimal data path configuration is detected by the one forwarding entity.

According to some implementation forms, the update request is made in response to a change of assignment from a further forwarding entity of the plurality of forwarding entities to the one forwarding entity. For example, the further forwarding entity has been assigned to the mobile entity. Due to a configurational change, the assignment of the further forwarding entity is changed such that the assignment is made for the one forwarding entity. Hence, a new mobility binding entity may be allocated to the data path which may be better suitable for the newly assigned forwarding entity. According to a fourth implementation form of the first aspect, the invention relates to a method, wherein the update request includes a proposal for a mobility binding entity to be allocated. Accordingly, the entity which makes the request proposes a mobility binding entity which is assumed suitable for the entities on the data path. Hence, the proposed mobility binding entity can be allocated as the mobility binding entity for the data path of the mobile entity. However, the entity which makes the allocation decision may find that according to the at least one mobility parameter of the mobile entity, a different mobility binding entity is to be selected and allocated. According to some implementation forms, the update request is transmitted through the proposed mobility binding entity. For example, the request including the proposal may be sent from one of the forwarding entities that has a standard mobility binding entity that is proposed for allocation. To inform also the proposed mobility binding entity about the proposal, the request including the proposal can be sent to the proposed mobility binding entity, which may forward the request to the entity performing the allocation, e.g. the mobility controller.

According to some implementation forms, the allocated mobility binding entity is informed about the allocation through the proposed mobility binding entity, if the proposed mobility binding entity is not allocated. Thus, the proposed mobility binding entity not being allocated is informed about its non-allocation.

According to a fifth implementation form of the first aspect, the invention relates to a method, wherein the at least one mobility parameter is included by the update request. Hence, the mobility parameter on which the allocation decision is based can represent an actual status of the mobile entity. According to a sixth implementation form of the first aspect, the invention relates to a method, wherein the communication network includes a mobility controller, and wherein the allocation is performed by the mobility controller. For example, the mobility controller is a central entity of the communication network. Accordingly, the mobility controller can handle the managing of the data path for various mobile entities attached to the communication network.

According to a second aspect, the invention relates to a mobility controller for a communication network with a plurality of mobility binding entities for forwarding data traffic. The mobility controller is configured to allocate a first mobility binding entity of the plurality of mobility binding entities to a data path for a mobile entity attached to the communication network. The mobility controller is further configured to allocate, in response to an update request for allocating a mobility binding entity to the mobile entity, a second mobility binding entity of the plurality of mobility binding entities to the data path for the mobile entity. The allocation is based on at least one mobility parameter of the mobile entity.

Various implementation forms of the mobility controller become apparent from the allocation-related implementation forms of the first aspect of the invention.

According to some implementation forms of the second aspect, the mobility controller is configured to perform the method of the first aspect. For example, the mobility controller includes a processor that is configured to perform the method of the first aspect

According to a third aspect, the invention relates to a communication system for a communication network. The communication system comprises a plurality of mobility binding entities for forwarding data traffic, and a mobility controller according to the second aspect of the invention. Further embodiments of the invention will be described with reference to the following figures, in which:

Fig. 1 shows a communication network according to an implementation form;

Fig. 2 shows a communication network according to an implementation form; Fig. 3 shows a flowchart of a method according to an implementation form; and Fig. 4 shows a flowchart of a method according to an implementation form. DESCRIPTION OF THE DRAWINGS

Fig. 1 shows a communication network according to an implementation form. In the communication network, a mobile entity which is embodied as mobile node, MN, 1 10 is connected to a mobility controller, MC, 120 with a signal path that is shown as a dashed line. The MC 120 is part of a provider network 130 which is connected to a data network 140. The provider network 130 comprises a first and a second forwarding entity, FE, 151 , 152 and a first and a second mobility binding entity, MBE, 161 , 162. The provider network 130 can have further forwarding entities and further mobility binding entities which are not shown here for reasons of a better overview.

The MN 110 is connected to the provider network 130 by a mobile connection shown as a solid line. The provider network 130 further has a data connection to the data network 140 shown as a solid line. The data network 140 may be a packet data network, PDN. The FEs 151 , 152 and the MBEs 161 , 162 are connected with each other with data connections, shown as solid lines, and each to the MC 120 by means of a signalling connection shown as dashed lines. One or more of the entities 151 , 152, 161 , 162 may have a connection to the data network 140, thus serving as a data network gateway of the provider network 130. Upon attachment of the MN 1 10 to the network 130, the MN 1 10 may be registered with the MC 120. No data path is bound to the MN 1 10 upon this attachment. If data traffic is to be transmitted for the MN 1 10, a data path including one of the FEs 151 , 152 and one of the MBEs 161 , 162 has to be established. To this end, one of the MBEs 161 , 162 is allocated to the data path for the MN 1 10 by the MC 120. Such allocation can be performed during an establishment of a connection to the data network 140, in particular during an initial establishment of the connection. Furthermore, the allocation of one of the MBEs 161 , 162 can be performed after establishment of the PDN connection, for example due to a resource change, maintenance, change of location of the MN 1 10 etc. However, before an MBE is allocated to the data path, various information required for the allocation may be provided to the MC 120. For example one or more mobility parameters of the MN 110 are provided, on which the allocation decision is based. Hence, a dynamic selection and reselection of MBEs is made possible.

The communication with the MC 120 regarding the dynamic selection and reselection of MBEs can be made through the control plane, for example the dashed signalling paths according to some implementation forms. According to further implementation forms, the data path communication through a default or previously selected MBE can be used for communicating with the MC 120.

According to some implementation forms, the MC 120 selects and reselects the MBEs and allocates the selected MBEs to a data path for the MN 1 10. The allocation decision is based on one or more mobility parameters of the mobile entity which for example include at least one of the following an identity of a subscriber using the mobile entity, a location of the mobile entity, a subscription profile of the mobile entity, a required Quality of Service, QoS, of the mobile entity, mobility characteristics of the mobile entity, and resource characteristics of the mobile entity. The MC 120 transmits its decision to one of the FEs 151 , 152. The FE binds the communication of the MN 1 10 to the allocated MBE. According to some implementation forms, a communication with the MC 120 uses the signalling paths. For the following explanation, it is assumed that for an initial selection or allocation, no allocation was previously executed. Hence, when the MC 120 is requested for selecting an MBE for the MN 1 10 attached to the provider network 130, the MC 120 initiates its internal MBE allocation procedures. For example, the allocation may be requested by an FE for the MN 1 10 by respective message from the FE to the MC 120. However, according to other implementation forms, the request may be sent by a network management system not shown here.

The MC 120 makes a policy-based decision which MBE to allocate, wherein the decision is based on the above described mobility parameter of the MN 1 10. The MC 120 communicates its decision directly to the FE and/or to the MBE which was allocated for the data path of the MN 1 10. Accordingly, the FE which has received the allocation information is enabled to forward data traffic through the selected and allocated MBE.

If at a later time a reallocation is requested by an update request, the MC 120 makes a further allocation decision regarding an MBE to be selected. For example, the allocation decision is based on the mobility parameter which may have changed between the first allocation of the MBE and the update request.

If a different MBE is selected in response to the update request, a different data path is established for the MN 1 10. However, a connection to the data network 140 is maintained transparently for the MN 1 10 and its communication

counterparts.

According to some implementation forms, the data connections are used for allocating entities to the data path. For the following description it is assumed that no MBE was allocated for the MN 1 10 so far. For example, an FE, e.g. FE 151 assigned to the MN 1 10 selects the first MBE 161 as its default MBE for the MN 1 10. The MBE 161 is informed about this selection. The MBE 161 then announces to the MC 120 that the MN 1 10 has a mobility binding through MBE 161 . The MC 120 makes a policy-based decision on the MBE based on the above described mobility parameter of the MN 1 10, and allocates one of the MBEs for the data path for the MN 1 10. The allocation decision is communicated to the default MBE 161 selected by FE 151 before. The default MBE 161 communicates to the FE 151 either that it is the MBE being allocated, or the identity of another MBE, e.g. MBE 162, being allocated to the data path for the MN 1 10. Accordingly, the FE 151 is informed which MBE is allocated for data forwarding. Hence, FE 151 transparently uses the allocated MBE for all communication assigned to the MN 1 10.

Fig. 2 shows a communication network according to a further implementation form. A mobile entity or mobile node 110 may be connected to a first or a second base station 21 1 , 212 which may be embodied as eNodeBs of an evolved packet core, EPC. Through these base stations 21 1 , 212 the MN 1 10 can connect to a provider network 230 and to a packet data network, PDN, 240. The provider network 230 comprises the MC 120 and several entities 251 , 252, 261 , 262 having gateway functionality. For example, entities 251 , 262 are serving gateways, S-Gateways, and entities 252, 261 are PDN gateways. An S-Gateway and a corresponding PDN gateway may form an SAE gateway. Each of the S-Gateways 251 , 262 is connected to both base stations 211 , 212. The PDN gateways 252, 261 have a connection to the packet data network 240.

Referring to Fig. 1 , an MBE can be represented by an eNodeB or another access point or another base station for download data traffic, by a S-Gateway or another access network specific gateway for download and upload data traffic, by a PDN gateway or another generic gateway for download and upload data traffic, or by a forwarding entity at a border of an operator domain like the provider network 230 for upload data traffic. Similarly, an FE can be represented by an eNodeB or other access point or base station for upload data traffic, by a S-Gateway or another access network specific gateway for upload and download data traffic, by a PDN gateway or another generic gateway for upload and download data traffic, by a backhaul entity forwarding data packets towardS-Gateways for download and upload data traffic or by a forwarding entity at the border of the operator domain for download data traffic.

In the following, several procedures according to various implementation forms will be described with respect to Fig. 2. However, the entities shown in Fig. 2 should not be taken limiting but only for a better explanation.

Fig. 3 shows a flowchart of an operation according to an implementation form with a mobile entity 301 , that is embodied as an user equipment UE, a source and a target S-Gateway 303, 304 which may represent forwarding entities, a mobility controller 305, and a source and a target PDN gateway 307, 308, which may represent MBEs.

In step 320, a handover request is received by the mobility controller 305, for example from a source eNodeB. In step 322, an S-Gateway reselection procedure is executed. According to the present example it is considered that the S-Gateway needs to be reselected. Accordingly, a PDN context relocation decision is triggered in the mobility controller 305 having as parameters at least a

communication identifier of the UE 301 , for example an IMSI.

In step 324, the mobility controller 305 makes a policy-based decision whether the PDN gateway needs to be reselected considering other possible mobility parameters of the UE 301 such as the location of the UE 301 , the subscription profile, mobility characteristics etc. The mobility controller 305 selects a PDN gateway and determines an identifier of the selected PDN gateway. In this example, an allocation is changed from the source PDN gateway 307 to the target PDN gateway 308. Accordingly, the mobility controller 305 may determine the IP address of the target PDN gateway 308.

In step 326, the mobility controller 305 transmits the request towards the target S- Gateway 304 including the IP address of the target PDN gateway 308. In step 328, the target S-Gateway 305 sends a create session request to the target PDN gateway 308. In response to this request, the target PDN gateway 308 initiates a session establishment in step 330. In step 332, a response to the create session request is sent to the target S-Gateway 304. Accordingly, in steps 328, 330 and 332, the PDN connectivity is transferred. This presumes that the target S-Gateway 304 maintains the binding between the UE 301 and the target PDN gateway 308.

The response of the target PDN gateway 308 sent in step 332 is forwarded to the mobility controller 305 in step 334. In step 338, the mobility controller 305 further forwards the response to the target eNodeB, which is not shown here, as a handover request.

In step 340, an indirect tunnel between the source S-Gateway 303 and the target S-Gateway 304 is established. In step 342, the handover command is transmitted to the source eNodeB and a handover is executed.

In the following steps 346, 348, 350 and 352, the handover is notified and the procedure is terminated. As effect of the procedure, upon receiving packets from the UE 301 , the target S-Gateway 304 forwards them to the target PDN gateway 308.

According to the above description, an assignment of a forwarding entity is changed from the source S-Gateway 303 to the target S-Gateway 304, and reallocation of an MBE is performed from the source PDN gateway 307 as the first MBE to the target PDN gateway 308 as second MBE. According to further implementation forms, a decision that the PDN gateway needs to be reselected is made by the mobility controller 305 in step 320 above. It is hence assumed that the eNodeB remains unchanged. Accordingly, the S- Gateway may be reselected. If the S-Gateway is not reselected, steps 326, 328, 330, 332, 334 are executed as described above. Steps 338, 340, 342 and 344 can be omitted, as the S-Gateway remains the same. Steps 346, 348, 350 and 352 are executed as described above.

Fig. 4 shows a flow chart of an operation according to some implementation forms. In Fig. 4 there are depicted several entities like an UE 401 , an eNodeB 403, a mobility controller 405, a source generic gateway, GG, 407 and a target GG 409. The operation of this example may be performed in a flat mobility architecture.

It is assumed that the eNodeB 403 includes FE functionality and therefore embodies an FE. Furthermore, the eNodeB 403 includes authentication and authorization functionality. The GGs 407, 409 represent MBEs, which for example are represented by an SAE gateway having S-Gateway and PDN gateway functionality in the EPC. It is further assumed that the GGs are located closely to the UEs. It may be assumed that reselections are often required, in particular due to mobility of the UEs attaching to the network. The eNodeB 403 contains a default list with a set of GGs ordered by priority. A default GG is usually selected and the default GG is usually the best for serving the UE. Such default list may be received through dynamic name service, DNS, mechanisms, in particular for all the subscribers once.

For the case of initial selection, PDN connectivity is established through a default GG, namely the source GG 407. In the case of subsequent selections, the PDN connectivity is assumed to be previously established through the source GG 407. The procedure may be triggered by the initial or subsequent attachment of the UE 401 to an access network by an UE handover, by management triggers, e.g. in response to congestion, and by administrative triggers, e.g. because of failure of a GG.

In step 420, the MC 405 makes a GG reselection decision based on at least one mobility parameter of the UE 401 , and allocates, initially or subsequently, one of the GGs 407, 409 as an MBE for a data path for the UE 401 .

In steps 422 and 424, an indirection tunnel is created between the source and the target GG 407, 409. In step 426, a handover request containing the identity of the subscriber and the address of the target GG 409 is transmitted to the source GG 407. This request is sent for both the initial and subsequent cases, as in the initial case, a PDN connection was established through the source GG 407.

In step 428, the source GG 407 determines the eNodeB 403 and forwards the handover request to the eNodeB 403.

In steps 430, 432, 434 and 436, the eNodeB 403 initiates the PDN context transfer to the target GG 409, which includes also the communication with the mobility controller 405.

The success of the GG reselection procedure is transmitted to the source GG 407 in step 440 and forwarded from the source GG 407 to the MC 405 in step 442.

According to various implementation forms, the MBE used for each MN can be reselected. In particular, the decision for the MBE reselection is able to consider several parameters together with the connectivity of the MN such as subscription profile, available and required resources, mobility characteristics etc. as described above. The MBE selection and reselection can be considered for each subscriber or each MN separately with respect to momentary cost, resources, load, mobility etc., in contrast to a permanent selection based on static information only. The data traffic passing through the operator core network is dynamically controlled by using variable data paths in contrast to always having a fixed path between MN and MBE.

In case of failover or congestion, another MBE can be used for the same MN without the need of deattaching the MN from the communication network and causing a service termination.

According to some implementation forms, for example for 3GPP EPC, a PDN gateway reselection is possible while maintaining the same PDN connectivity.

According to some implementation forms, for flat mobility architecture, GG reselection is made possible in the following cases: the GG is closely located to the base stations, for example through a default MBE. Furthermore, the GG can be located closely to the border of the operator domain, wherein a communication with a mobility controller for example is made through direct communication.

Claims

CLAIMS:

Method for managing a data path for a mobile entity (1 10) attached to a communication network, the communication network having a plurality of mobility binding entities (161 , 162) for forwarding data traffic, the method comprising:

- allocating a first mobility binding entity of the plurality of mobility binding entities (161 , 162) to the data path for the mobile entity (110); and

- allocating, in response to an update request for allocating a mobility binding entity to the mobile entity (1 10), a second mobility binding entity of the plurality of mobility binding entities (161 , 162) to the data path for the mobile entity (1 10), the allocation being based on at least one mobility parameter of the mobile entity (110). 2. Method according to claim 1 ,

wherein the at least one mobility parameter includes at least one of the following:

- an identity of a subscriber using the mobile entity (1 10);

- a location of the mobile entity (1 10);

- a subscription profile of the mobile entity (1 10);

- a required Quality of Service, QoS, of the mobile entity (1 10);

- mobility characteristics of the mobile entity (110);

- resource characteristics of the mobile entity (110).

Method according to claim 1 or 2,

wherein the mobile entity (1 10) remains attached to the communication network during allocation of the second mobility binding entity.

Method according to one of the preceding claims,

wherein the first mobility binding entity is deallocated after allocation of the second mobility binding entity. Method according to one of the preceding claims,

wherein the communication network includes a plurality of forwarding entities (151 , 152), at least one of the plurality of forwarding entities (151 , 152) being assigned to the mobile entity (110), and wherein an information about the allocation is transmitted to the one forwarding entity.

Method according to claim 5,

wherein a data connection is established on the data path between the allocated mobility binding entity (161 , 162) and the one mobility binding entities (161 , 162).

7. Method according to one of claims 5 or 6,

wherein the update request is made by the one mobility binding

entities (161 , 162).

Method according to one of claims 5 to 7,

wherein the update request is made in response to a change of assignment from a further forwarding entity of the plurality of forwarding entities (151 , 152) to the one forwarding entity.

9. Method according to one of the preceding claims,

wherein the update request includes a proposal for a mobility binding entity (161 , 162) to be allocated.

10. Method according to the preceding claim,

wherein the update request is transmitted through the proposed mobility binding entity (161 , 162). 1 1 . Method according to one of claims 9 or 10,

wherein, if the proposed mobility binding entity is not allocated, the allocated mobility binding entity is informed about the allocation through the proposed mobility binding entity.

12. Method according to one of the preceding claims,

wherein the at least one mobility parameter is included by the update request.

13. Method according to one of the preceding claims,

wherein the communication network includes a mobility controller (120), and wherein the allocation is performed by the mobility controller (120).

14. Mobility controller (120) for a communication network with a plurality of mobility binding entities (161 , 162) for forwarding data traffic, the mobility controller (120) being configured to:

- allocate a first mobility binding entity of the plurality of mobility binding entities (161 , 162) to a data path for a mobile entity (1 10) attached to the communication network; and

- allocate, in response to an update request for allocating a mobility

binding entity to the mobile entity (1 10), a second mobility binding entity of the plurality of mobility binding entities (161 , 162) to the data path for the mobile entity (1 10), the allocation being based on at least one mobility parameter of the mobile entity (110).

15. Communication system for a communication network, the communication system comprising a plurality of mobility binding entities (161 , 162) for forwarding data traffic, and a mobility controller (120) according to the preceding claim.