WO2012113156A1 - Method for establishing a data path, device and communication system - Google Patents

Method for establishing a data path, device and communication system Download PDF

Info

Publication number
WO2012113156A1
WO2012113156A1 PCT/CN2011/071315 CN2011071315W WO2012113156A1 WO 2012113156 A1 WO2012113156 A1 WO 2012113156A1 CN 2011071315 W CN2011071315 W CN 2011071315W WO 2012113156 A1 WO2012113156 A1 WO 2012113156A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
forwarding
binding
allocated
mobility
Prior art date
Application number
PCT/CN2011/071315
Other languages
French (fr)
Inventor
Qing Zhou
Konstantinos Pentikousis
Cornel Pampu
Marius CORICI
Dragos VINGARZAN
Thomas MAGEDANZ
Original Assignee
Huawei Technologies Co., Ltd.
Fraunhofer-Gesellschaft Zur Forderung Der Angewandten Forschung E. V.,
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd., Fraunhofer-Gesellschaft Zur Forderung Der Angewandten Forschung E. V., filed Critical Huawei Technologies Co., Ltd.
Priority to PCT/CN2011/071315 priority Critical patent/WO2012113156A1/en
Priority to CN201180005033.XA priority patent/CN103069917B/en
Priority to EP11815838A priority patent/EP2507955A4/en
Publication of WO2012113156A1 publication Critical patent/WO2012113156A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/34—Modification of an existing route
    • H04W40/36—Modification of an existing route due to handover
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer

Definitions

  • the invention relates to the field of communication networks and in particular to mobile communication networks.
  • a mobile communication provider In current communication networks it is possible to connect to a packet data network, for example the Internet, by means of a mobile terminal.
  • a mobile communication provider usually provides several entities like gateways that establish a connection to the packet data network for the mobile terminal.
  • a mobile terminal connects to a communication network via a base station
  • a data path is fixedly allocated and established for the mobile terminal.
  • 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.
  • 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.
  • the invention is based on the finding that a data path for a mobile entity being connected to a communication network can be established at the time at which data traffic assigned to the mobile entity is present. Accordingly, a data path for the mobile entity is established on demand. Hence, as long as no data traffic related to the mobile entity is present, resources of an else unused data path in the communication network can be saved. Furthermore, an optimal data path can be selected at the time when it is actually needed. It is also possible to select different data paths for upload data traffic originating from the mobile entity and download data traffic targeting at the mobile entity.
  • a communication network comprises one or more forwarding entities for providing data packets for a data path and a plurality of mobility binding entities for forwarding data packets on the data path.
  • a data path may then only be established, if a forwarding entity requests a data path because the forwarding entity has data traffic to be forwarded.
  • the invention relates to a method for establishing a data path for a mobile entity in a communication network.
  • the communication network has one or more forwarding entities for providing data packets for a data path and a plurality of mobility binding entities for forwarding data packets on the data path.
  • One forwarding entity of the one or more forwarding entities receives data traffic assigned to the mobile entity.
  • Binding information assigned to the mobile entity is requested by a request of the one forwarding entity.
  • a mobility binding entity of the plurality of mobility binding entities is allocated. Then the requested binding information is provided, the binding information including an identity of the allocated mobility binding entity.
  • the one forwarding entity forwards, in
  • the data traffic to the allocated mobility binding entity.
  • the communication network comprises a mobility controller, which for example manages data traffic of mobile entities attached to the communication network. Accordingly, the allocating of the mobility binding entity may be
  • a mobile entity is attached to the communication network and registered with the mobility controller.
  • registering includes receiving a network address like an IP address.
  • No data path is allocated or established at the time of registering.
  • the request of the one forwarding entity may be sent to the mobility controller which allocates, in response to receiving the request, the mobility binding entity.
  • the requested binding information including an identity identifier of the allocated mobility binding entity is transmitted from the mobility controller to the one forwarding entity.
  • the allocating can be performed within the one forwarding entity.
  • the one forwarding entity has a memory or a cache with several mobility binding entities which can be selected for allocation. Accordingly, the binding information is provided by the one forwarding entity itself.
  • the allocation of the mobility binding entity is performed by the mobility controller.
  • the binding information including the identity of the allocated mobility binding entity is stored in a cache of the one forwarding entity and/or caches of other forwarding entities.
  • a forwarding entity if a forwarding entity has data traffic assigned to the mobile entity to be forwarded, it can look up the mobility binding entity to which the data traffic is to be forwarded in its cache, once the mobility binding entity has been allocated by the mobility controller.
  • the invention relates to a method, wherein, in response to an update request for updating the binding information, a further mobility binding entity of the plurality of mobility binding entities is allocated to the mobile entity.
  • the updated binding information is provided to the one forwarding entity, wherein the updated binding information includes an identity of the allocated further mobility binding entity assigned to the mobile entity.
  • the update request may be received from the
  • the update request is received through administrative means, for example, for maintenance purposes.
  • the update request can be triggered internally in a mobility controller, for example, for load balancing purposes.
  • a new data path can be established and data traffic can be forwarded on the new data path.
  • data traffic sent on the previous data path not necessarily has to be resent.
  • the identity of the allocated further mobility binding entity is provided to the previously allocated mobility binding entity. Accordingly, the previously allocated mobility binding entity forwards incoming data traffic, which is assigned to the mobile entity, to the allocated further mobility binding entity. Hence, data traffic on the previously allocated data path will be redirected to the mobility binding entity of the newly allocated data path.
  • the invention relates to a method, wherein a data path is allocated for the data traffic, the data path including the mobile entity, the one forwarding entity and the allocated mobility binding entity.
  • the data traffic is transmitted on a 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. It is furthermore possible that data traffic is transmitted on a 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. If the data traffic originates from the mobile entity, it can be called upload data traffic. Accordingly, if the data traffic is targeted at the mobile entity, it can be called download data traffic. It is hence possible to allocate at least two separate data paths, namely one download data path for download data traffic and one upload data path for upload data traffic.
  • the invention relates to a method, wherein, in response to a termination request, the allocation of the allocated mobility binding entity is deleted, and an updated binding information is provided to the mobility binding entity, whose allocation is deleted, the updated binding information including the deleted allocation. Accordingly, if the data path is not needed, for example, because no data traffic assigned to the mobile entity is present, resources used in the allocated data path can be set free.
  • the updated binding information encoding the deleted allocation is further provided to the forwarding entities, to which a binding information was provided before. Accordingly, if a forwarding entity receives data traffic assigned to the mobile entity after the deletion of the allocation, a new request for a binding information is made by the forwarding entity.
  • the invention relates to a method in which data traffic targeted at the mobile entity is received by a further forwarding entity of the plurality of forwarding entities.
  • the further forwarding entity requests the binding information assigned to the mobile entity.
  • the requested binding information is provided to the further forwarding entity, the binding information comprising the identity of the allocated mobility binding entity.
  • the further forwarding entity forwards the data traffic to the allocated mobility binding entity.
  • the information about the allocation namely the identity of the allocated mobility binding entity can be provided to other forwarding entities which receive download data traffic for the mobile entity.
  • the binding information with the allocated mobility binding entity is stored in a cache of a mobility controller and/or in a cache of another forwarding entity, that for example is a forwarding entity which made the request resulting in the allocation of the mobility binding entity.
  • the invention relates to a method, wherein, after a binding information is provided to a forwarding entity, a mobility connection is registered between the forwarding entity and the allocated mobility binding entity. For example, one or multiple bearers are established between the forwarding entity and the mobility binding entity, including a default bearer.
  • registering of the mobile connection can comprise the establishment or a definition of at least one of the following: a Policy and Charging Control, PCC, a Quality of Service, QoS, rule, an Internet Protocol, IP, tunnel establishment.
  • PCC Policy and Charging Control
  • QoS Quality of Service
  • IP Internet Protocol
  • registering of the mobile connection is supported by a mobility controller. Further, the mobility controller can perform the update of the binding information in the forwarding entities.
  • the invention relates to a method, wherein the mobile entity is registered with a mobility controller and registering includes transmitting a communication identifier to the mobility controller.
  • the communication identifier includes at least one of the following parameters of the mobile entity: a Media Access Control, MAC, address, an International Mobile Subscriber Identity, IMSI, an Internet Protocol, IP, address, a device identifier, a subscriber identifier, a subscriber identity.
  • the mobility controller receives information needed to identify that data traffic is assigned to the mobile entity.
  • the invention relates to a method, wherein the allocated mobility binding entity forwards the data traffic received from the forwarding entity to a gateway entity of a packet data network, the gateway entity being one of the plurality of mobility binding entities or one of one or more forwarding entities.
  • the invention relates to a device for a
  • the device having one or more forwarding entities for providing data packets for a data path and a plurality of mobility binding entities for forwarding data packets on the data path.
  • the device is configured to register a mobile entity attached to the communication network.
  • the device is further configured to allocate a mobility binding entity of the plurality of mobility binding entities in response to a request for a binding information assigned to the mobile entity, the request being received from one forwarding entity of one or more forwarding entities.
  • the device is further configured to transmit the requested binding information to the one forwarding entity, the binding information including an identity of the allocated mobility binding entity, to which data traffic assigned to the mobile entity is to be forwarded by the one forwarding entity.
  • the device is embodied as a mobility controller as described for the first aspect of the invention .
  • the device can be configured to handle an update request for updating the binding information as described for the first aspect of the invention.
  • the device can further be configured to handle a termination request as described for the first aspect of the invention.
  • the device configured to perform the method of the first ascpect.
  • the invention relates to a communication system for a communication network, the communication system comprising one or more forwarding entities for providing data packets for a data path, a plurality of mobility binding entities for forwarding data packets on the data path, and a device according to the second aspect of the invention.
  • 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
  • Fig. 5 shows a flowchart of a method according to an implementation form
  • Fig. 6 shows a flowchart of a method according to an implementation form
  • Fig. 7 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.
  • 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 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.
  • the MN 110 connects to the provider network 130 and the data network 140 respectively, and how data traffic is transmitted from and to the MN 1 10.
  • the MN 1 10 is registered with the MC 120. No data path is bound to the MN 1 10 upon this attachment.
  • the MC 120 selects one of the MBEs 161 , 162.
  • the MC 120 establishes a data path for the MN 110 between the one FE and the selected MBE.
  • the MBE changes for example, upon changes in the provider network 130, the MC 120 is notified.
  • the MC 120 then notifies the FEs which have data traffic assigned to the MN 1 10.
  • the MN 1 10 requests and receives a network context, such as a reachable IP address or any other network address clearly identifying the attached MN 1 10.
  • the MC 120 creates and stores a mobility binding containing, for example, a mapping between a communication identifier of the MN 1 10, wherein the communication identifier includes at least one of the following parameters of the mobile entity: a MAC address, an IMSI, an IP address, a device identifier, a subscriber identifier, a subscriber identity.
  • the MC 120 may optionally store a locator identity for a data path, for example a fixed entity, to which the MN 1 10 is connected like a base station etc.
  • the MC 120 in the control plane is the only entity in the system, namely the provider network 130, which is aware of the mobility binding of the MN 1 10. However, no strict data paths are allocated to the MN 1 10.
  • the respective FE requests from the MC 120 a binding information corresponding to an identifier of the MN 1 10. For example, the FE asks the MC 120 where to send the data traffic.
  • the MC 120 allocates one of the MBEs 161 , 162 on the data path to the MN 1 10. For example, the MC 120 allocates an MBE which will receive the data traffic to or from the MN 1 10.
  • the MC 120 may optionally maintain a cache containing the binding information between the identifier of the MN 1 10 and the allocated MBE.
  • an MBE is selected or allocated for the MN 1 10 only when data traffic assigned to the MN 1 10 has to be forwarded.
  • the MC 120 may transmit the identity of the allocated MBE to the FE which has sent the request. For example, the MC 120 tells the FE to which MBE to send the data traffic to.
  • the identity of the allocated MBE may be transmitted in a binding information. The message including the binding
  • the MC 120 can inform the allocated MBE to establish a context towards the respective FE. For example, one or multiple bearers are established between the respective FE and the allocated MBE, including a default bearer.
  • the MC 120 may initiate the establishment of a subscriber-based Quality of Service, QoS, rule and a Policy and Charging Control, PCC. Both a download data path and an upload data path may be established in a single operation step. However, upload data path and download data path may include different entities of the provider network 130. As a result, an entity on the data path is selected for data packet forwarding.
  • the respective FE forwards the data traffic to the allocated MBE. For example, data packets are transmitted to the allocated MBE.
  • the MC 120 may receive an update request or change request for the data path of the MN 1 10 wherein the request may be received from the network 130, from the allocated MBE etc.
  • the request can be received also by administrative means, for example, for maintenance purposes.
  • the request may be triggered internally in the MC 120, for example for load balancing purposes.
  • the MC 120 allocates a new MBE on the data path for the MN 1 10. For example, the MC 120 allocates a new MBE which will receive the data traffic to or from the MN 110. It should be noted that is similar to the first allocation of the MBE described above, besides being a re-allocation of an MBE.
  • the MC 120 may optionally update the cache containing the binding information between the identifier of the MN 1 10 and the allocated MBE.
  • the MC 120 may send the identity of the newly allocated MBE to one or more FEs. For example, the MC 120 sends the updated binding information to all FEs. However, the MC 120 may send such updated binding information only to those FEs which have requested binding information before. A message including the updated binding information may be sent from the MC 120 to the FE either directly or through the newly or through the former allocated MBEs. The MC 120 can inform the newly allocated MBE to establish a context towards the FE. For example, one or multiple bearers are established between the FE and the newly allocated MBE, including a default bearer. If according to some implementation forms the FEs have a cache for the binding information for the MN 1 10, the binding information can be updated in such cache.
  • FIG. 2 shows a communication network according to a further implementation form.
  • a mobile entity or mobile node 1 10 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.
  • 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.
  • 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.
  • 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.
  • a strict binding between the MN 1 10 and a base station is assumed, while towards an IP domain , represented by the PDN 240, a loose data path is assumed.
  • the base station represents the entity to which the MN 1 10 is strictly bound to for communication.
  • the base station can be represented by an eNodeB for EPC.
  • a generic gateway, GG represents a gateway on the data path to which a mobility binding for the MN 1 10 is maintained.
  • the GG can be represented by a PDN gateway or by a PDN and a S-Gateway.
  • the GG may be required for subscriber-based bearer allocation and PCC.
  • a forwarding entity at a border, FE-BR, is a function which may forward data traffic and/or to the MN 110 to and/or from the IP domain.
  • the MC is represented by a separate functionality, for example an MME.
  • the MN 1 10 may be bound to more than one base station at the same time. However, in the following examples it is considered that the MN 1 10 is bound only to one base station. Accordingly, download data traffic has to reach that specific base station in order to be forwarded to the MN 1 10.
  • Fig. 3 shows a flow chart of an operation according to some implementation forms. Described are communication and operation of a MN 301 , which may be
  • a user equipment UE
  • a base station 303 which may be embodied as an eNodeB
  • a first and a second GG 305, 307 which may be embodied as PDN gateways
  • a mobility controller 309 which may be embodied as an MME with enhanced functionality
  • Fes at the border of the operator domains FE-BRs ⁇ 31 1 , 313.
  • step 320 the MN 301 establishes its connectivity with the base station 303.
  • step 322 the base station sends to the MC 309 an identifier of the MN 301 and an identity of the base station 303 as allocation information.
  • the base station 303 may require from the MC 309 an IP address to be allocated for the MN 301 .
  • step 324 the MC 309 receives the information from the base station 303 and adds cache entries to its cache. For example, the MC 309 stores that all download data traffic for the MN 301 has to be forwarded to base station 303.
  • step 326 the MC 309 sends to the base station 303 an acknowledgment. If the MC 309 allocates the IP address, then the acknowledgement contains the IP address. As a result, the MN 301 has its reachability information stored in the MC 309. No MBE has been selected at this stage.
  • Fig. 4 describes an operation regarding upload data traffic according to some implementation forms.
  • entities 401 , 403, 405, 407, 409, 411 , 413 are shown which may correspond to the respective entities 301 to 313 of Fig. 3. It is assumed that a procedure of attachment according to Fig. 3 was executed.
  • the MN 401 is connected to the network and the MC 409 has the reachability information.
  • the MN 401 announces the base station 403 of its intention to communicate. For example the announcing is performed through getting into connecting state or sending an upload data packet to the base station 403.
  • step 422 the base station 403 checks if a PCC and a mobility context are established with any GG assuming that no data traffic was transmitted before.
  • step 424 the base station 403 requests forwarding information or binding information from the MC 409.
  • step 426 the MC 409 checks if binding
  • step 428 the forwarding information is transmitted to the GG 405 and optionally to the base station 403.
  • the forwarding information enables the GG 405 to know that a connection with a base station is required for the MN 401 . Furthermore, the forwarding information can enable the GG 1 to know that it can forward the data traffic to any FE-BR.
  • step 430 the PCC and mobility context are established between the base station 403 and the GG 405.
  • the establishment may be initiated by the GG 405.
  • the mobility connection or mobility context may include the PCC and QoS rules and IP forwarding tunnel establishment. If the forwarding information was transmitted to the base station 403 in step 428, the PCC and mobility context establishment can be initiated by the base station 403. As a result of this operation, a temporary upload and download connection is established on the path from the mobile node 401 to the GG 405 via the base station 403.
  • step 432 which is an optional step, the GG 405 can take a forwarding decision, namely to which of the FE-BRs 41 1 , 413 data traffic shall be forwarded. Otherwise, the forwarding to the FE-BR can be executed statically through the existing IP routine mechanisms. It should be noted that only upload data traffic has to follow the allocated data paths.
  • Fig. 5 shows a flowchart of an operation according to some implementation forms, the operation relating to download data traffic for the MN.
  • Fig. 5 shows the entities 501 , 503, 505, 507, 509, 511 , 513 which may correspond to previously described entities 301 to 313 or 401 to 413, respectively. It is assumed that an attachment operation according to Fig. 3 has been executed, the MN 501 is connected to the network and the MC 509 has a reachability information for the MN 501 .
  • the FE-BR 513 receives a download packet for the MN 501 .
  • the FE- BR 513 checks if it has a cache entry relating to the MN 501 . Assuming that no forwarding info is cached the FE-BR 513, the FE-BR 513 requests, in step 524, a binding information relating to the MN 501 from the MC 509. Similar to step 426, in step 526 the MC 509 checks the binding information and finds, for example, that all download traffic has to be forwarded to the base station 503, but no MBE has been allocated. The MC 509 then allocates the GG 505 as an MBE for the download data path for the MN 501 .
  • the MC 509 transmits the forwarding information or binding information , e.g., to the FE-BR 513. Furthermore, if no MBE was previously allocated, the forwarding information or binding information is also provided to the allocated MBE, namely the GG 505.
  • the FE-BR 513 creates a cache entry which includes the information received from the MC 509.
  • step 532 which is an optional step, the forwarding information or binding information can be provided to the base station 503.
  • This information enables the base station 503 to know that a connection with the GG 505 is required for the MN 501 . This may be helpful for example for triggering the MN 501 to get into connected state.
  • step 534 the PCC and mobility context or mobility connection is established between the base station 503 and the GG 505. The establishment may be initiated by the GG 505 or, if the base station 503 has the forwarding information, also by the base station 503.
  • Fig. 6 shows a flowchart of an operation according to some implementation forms. The operation relates to the re-selection of an MBE.
  • Fig. 6 shows entities 601 , 603, 605, 607, 609, 61 1 , 613 which may correspond to the previously shown entities of Figs. 3 to 5. It is assumed that an attachment procedure according to Fig. 3 was executed and the MC 509 maintains reachability information. It is furthermore assumed that the MN 601 is connected to the network through the base station 603 and the GG 605. An upload binding information defines the gateway 605 as the allocated MBE for upload data traffic. Furthermore, for download data traffic it is defined that data traffic arriving at one of the FE-BRs 61 1 , 613 as forwarding entities has to be forwarded to the GG 605.
  • an MBE reallocation decision is made such that the MC 609 has to execute an MBE reallocation procedure.
  • This can, for example, be triggered by the attachment of the MN 601 through another base station, namely an access network handover.
  • the reallocation procedure can further be triggered by administrative means such as maintenance operations, as depicted in Fig. 6.
  • this MC 609 decides to select the second GG 607 as a new MBE for the MN 601 .
  • the MC 609 replaces them such that upload data traffic has to be forwarded from the base station 603 to the GG 607, and download data traffic received from one of the FE- BRs 61 1 , 613 has to be forwarded to the GG 607.
  • step 622 which is an optional step, the forwarding information or binding information is provided to the newly allocated MBE, the GG 607.
  • the information may be transmitted also to the base station 603.
  • the information enables the base station 603 to know that a connection with the GG 607 is required for the MN 601 .
  • the information may also be transmitted to the previously allocated MBE, namely the GG 605. This information enables the GG 605 to delete the PCC and mobility context and to forward data addressed to MN 601 to the GG 607.
  • the PCC and mobility context is established between the base station 603 and the GG 607, which is initiated by the GG 607.
  • the mobility context includes the PCC and QoS rules and IP forwarding tunnel establishment.
  • the information was also sent to the base station 603, the PCC and mobility context establishment can also be initiated by the base station 603. As a result of this operation, a temporary upload and download connection is
  • Fig. 7 shows a flowchart of an operation according to some implementation forms. The operation relates to the termination of a binding.
  • the entities 701 , 703, 705, 707, 709, 71 1 , 713 may correspond to the previously described entities of the Figs. 3 to 6.
  • GG 705 is allocated as an MBE for upload and download connections, and the MN 701 is connected to the network.
  • a decision to free the MBE allocation is made.
  • the MC 709 has to execute an MBE free procedure. This can be triggered by, for example, the MN 701 being in an idle mode or not communicating for a predefined period of time. Other triggers could be the attachment of the MN 701 from any network.
  • the MC 709 decides to delete the MBE bindings of the MN 701 such that no MBE is allocated for the MN as well for upload data traffic and download data traffic.
  • step 722 the MC 709 checks which of the FE-BRs 711 , 713 require termination information.
  • the MC sends to the FE-BRs 711 , 713 an updated binding
  • step 724 the FE-BRs 71 1 , 713 delete the respective information in their caches.
  • the MC 709 sends the termination information also to the previously allocated GG 705. Furthermore, the information may also be transmitted to the base station 703.
  • the PCC and mobility context between the base station 703 and the allocated GG 705 is terminated, initiated by the GG 705. If the updated binding information was also transmitted to the base station 703 in step 726, the termination of the mobility context can also be initiated by the base station 703.
  • upload and download data paths can be allocated separately. However, to simplify the allocation procedure, both the upload and the download data path can be allocated simultaneously. For both the upload and download data paths, the FEs may be independent of each other. Therefore, multiple data paths can be used simultaneously and can be seamlessly interchangeable.
  • the MN can be connected simultaneously over multiple access networks, so- called multi-interface MNs.
  • the FEs are entities at the border of the operator domain, so-called FE-BRs, and the MBEs are gateways located close to the MN, then the data traffic of the MN can be received from the IP domain over multiple core network links without requiring indirection to any central entity such as a PDN gateway.
  • Multiple MBEs may be used simultaneously for the same MN, e.g., if a policy-based decision is made either on the MC or through the PCC. Therefore, also split or merge of data traffic of a MN is possible, for example, if fine-grained traffic detection is executed by the gateways and/or FEs.
  • a decision of a data path optimization can be dynamically taken based on different events such as network load, mobility of the MN etc.
  • Data traffic forwarded to the operator network can be controlled more dynamically, at the following levels of granularity: for one or more data packets, for one or more data flows, for the complete communication of the MN.
  • a data path may be allocated on demand, only when it is required.
  • the data path can be reallocated seamlessly. For example, data path reallocation does not influence the data packets in transit, namely data packets already been forwarded on another data path. Furthermore, data path reallocation may be executed on the FE between two data packets without a requirement of buffering.
  • the data path may be reallocated only when required. No reallocation of a data path may be executed unless an FE requests this. Reallocation information may be transmitted only to the FEs which have or had data packets to be forwarded for the MN.
  • the above described implementation forms allow that multiple data path can be used at the same time. Furthermore, reduced signalling in specific situation can be achieved. No messages may be transmitted to the data path entities unless the MN is communicating. The messages my be transmitted only to the FEs which have or had forwarded data traffic for or from the MN.
  • the above described implementation forms do not require a modification of the network forwarding mechanisms such as IP routing.
  • the described implementation forms can be used on top of a variety of forwarding mechanisms and does not modify the forwarding mechanism of the underlying network transport.
  • the described implementation forms can be deployed even in transition stages from EPC to flat architectures.
  • the procedures described above can be deployed with the FE in an eNodeB and an MBE in an S-Gateway/PDN gateway for upload data traffic and with an FE in IP domain of the operator and a MBE on the PDN gateway for download data traffic.

Abstract

In a method for establishing a data path for a mobile entity (110) in a communication network having one or more forwarding entities (151, 152) for providing data packets for a data path and a plurality of mobility binding entities (161, 162) for forwarding data packets on the data path, data traffic assigned to the mobile entity (110) is received by one forwarding entity (151, 152) of one or more forwarding entities (151, 152). A binding information assigned to the mobile entity (110) is requested by a request of the one forwarding entity (151, 2). In response to receiving the request of the one forwarding entity (151, 152), a mobility binding entity (161, 162) of the plurality of mobility binding entities (161, 62) is allocated. The requested binding information is provided including an identity of the allocated mobility binding entity (161, 162). The one forwarding 1 entity (151, 152) forwards the data traffic to the allocated mobility binding entity (161, 162) in dependence on the binding information.

Description

DESCRIPTION
Method for establishing a data path, device 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 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 establishing 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 invention is based on the finding that a data path for a mobile entity being connected to a communication network can be established at the time at which data traffic assigned to the mobile entity is present. Accordingly, a data path for the mobile entity is established on demand. Hence, as long as no data traffic related to the mobile entity is present, resources of an else unused data path in the communication network can be saved. Furthermore, an optimal data path can be selected at the time when it is actually needed. It is also possible to select different data paths for upload data traffic originating from the mobile entity and download data traffic targeting at the mobile entity. For example, a communication network comprises one or more forwarding entities for providing data packets for a data path and a plurality of mobility binding entities for forwarding data packets on the data path. A data path may then only be established, if a forwarding entity requests a data path because the forwarding entity has data traffic to be forwarded.
According to a first aspect, the invention relates to a method for establishing a data path for a mobile entity in a communication network. The communication network has one or more forwarding entities for providing data packets for a data path and a plurality of mobility binding entities for forwarding data packets on the data path. One forwarding entity of the one or more forwarding entities receives data traffic assigned to the mobile entity. Binding information assigned to the mobile entity is requested by a request of the one forwarding entity. In response to receiving the request of the one forwarding entity, a mobility binding entity of the plurality of mobility binding entities is allocated. Then the requested binding information is provided, the binding information including an identity of the allocated mobility binding entity. The one forwarding entity forwards, in
dependence on the binding information, the data traffic to the allocated mobility binding entity.
For example, the communication network comprises a mobility controller, which for example manages data traffic of mobile entities attached to the communication network. Accordingly, the allocating of the mobility binding entity may be
performed by the mobility controller. For example, a mobile entity is attached to the communication network and registered with the mobility controller. For example, registering includes receiving a network address like an IP address. No data path is allocated or established at the time of registering. The request of the one forwarding entity may be sent to the mobility controller which allocates, in response to receiving the request, the mobility binding entity. After the allocation, the requested binding information including an identity identifier of the allocated mobility binding entity is transmitted from the mobility controller to the one forwarding entity.
According to some implementation forms, the allocating can be performed within the one forwarding entity. For example, the one forwarding entity has a memory or a cache with several mobility binding entities which can be selected for allocation. Accordingly, the binding information is provided by the one forwarding entity itself.
According to some implementation forms, the allocation of the mobility binding entity is performed by the mobility controller. The binding information including the identity of the allocated mobility binding entity is stored in a cache of the one forwarding entity and/or caches of other forwarding entities. Hence, if a forwarding entity has data traffic assigned to the mobile entity to be forwarded, it can look up the mobility binding entity to which the data traffic is to be forwarded in its cache, once the mobility binding entity has been allocated by the mobility controller.
According to a first implementation form of the first aspect, the invention relates to a method, wherein, in response to an update request for updating the binding information, a further mobility binding entity of the plurality of mobility binding entities is allocated to the mobile entity. The updated binding information is provided to the one forwarding entity, wherein the updated binding information includes an identity of the allocated further mobility binding entity assigned to the mobile entity. For example, the update request may be received from the
communication network, from the previously allocated mobility binding entity etc. It is also possible that the update request is received through administrative means, for example, for maintenance purposes. Furthermore, the update request can be triggered internally in a mobility controller, for example, for load balancing purposes.
As soon as the one forwarding entity receives the updated binding information, a new data path can be established and data traffic can be forwarded on the new data path. However, data traffic sent on the previous data path not necessarily has to be resent.
According to some implementation forms, the identity of the allocated further mobility binding entity is provided to the previously allocated mobility binding entity. Accordingly, the previously allocated mobility binding entity forwards incoming data traffic, which is assigned to the mobile entity, to the allocated further mobility binding entity. Hence, data traffic on the previously allocated data path will be redirected to the mobility binding entity of the newly allocated data path.
According to a second implementation form of the first aspect, the invention relates to a method, wherein a data path is allocated for the data traffic, the data path including the mobile entity, the one forwarding entity and the allocated mobility binding entity.
For example, the data traffic is transmitted on a 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. It is furthermore possible that data traffic is transmitted on a 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. If the data traffic originates from the mobile entity, it can be called upload data traffic. Accordingly, if the data traffic is targeted at the mobile entity, it can be called download data traffic. It is hence possible to allocate at least two separate data paths, namely one download data path for download data traffic and one upload data path for upload data traffic. According to a third implementation form of the first aspect, the invention relates to a method, wherein, in response to a termination request, the allocation of the allocated mobility binding entity is deleted, and an updated binding information is provided to the mobility binding entity, whose allocation is deleted, the updated binding information including the deleted allocation. Accordingly, if the data path is not needed, for example, because no data traffic assigned to the mobile entity is present, resources used in the allocated data path can be set free.
For example, the updated binding information encoding the deleted allocation is further provided to the forwarding entities, to which a binding information was provided before. Accordingly, if a forwarding entity receives data traffic assigned to the mobile entity after the deletion of the allocation, a new request for a binding information is made by the forwarding entity.
According to some implementation forms, if the allocation was performed by a mobility controller, also the deletion of the allocation may be performed by the mobility controller. According to a fourth implementation form of the first aspect, the invention relates to a method in which data traffic targeted at the mobile entity is received by a further forwarding entity of the plurality of forwarding entities. The further forwarding entity requests the binding information assigned to the mobile entity. The requested binding information is provided to the further forwarding entity, the binding information comprising the identity of the allocated mobility binding entity. The further forwarding entity forwards the data traffic to the allocated mobility binding entity.
Accordingly, if a mobility binding entity is allocated to a download data path of the mobile entity, the information about the allocation, namely the identity of the allocated mobility binding entity can be provided to other forwarding entities which receive download data traffic for the mobile entity. For example, the binding information with the allocated mobility binding entity is stored in a cache of a mobility controller and/or in a cache of another forwarding entity, that for example is a forwarding entity which made the request resulting in the allocation of the mobility binding entity. According to a fifth implementation form of the first aspect, the invention relates to a method, wherein, after a binding information is provided to a forwarding entity, a mobility connection is registered between the forwarding entity and the allocated mobility binding entity. For example, one or multiple bearers are established between the forwarding entity and the mobility binding entity, including a default bearer.
According to some implementation forms, registering of the mobile connection can comprise the establishment or a definition of at least one of the following: a Policy and Charging Control, PCC, a Quality of Service, QoS, rule, an Internet Protocol, IP, tunnel establishment. For example, registering of the mobile connection is supported by a mobility controller. Further, the mobility controller can perform the update of the binding information in the forwarding entities.
According to a sixth implementation form of the first aspect, the invention relates to a method, wherein the mobile entity is registered with a mobility controller and registering includes transmitting a communication identifier to the mobility controller. The communication identifier includes at least one of the following parameters of the mobile entity: a Media Access Control, MAC, address, an International Mobile Subscriber Identity, IMSI, an Internet Protocol, IP, address, a device identifier, a subscriber identifier, a subscriber identity. With the registering, the mobility controller receives information needed to identify that data traffic is assigned to the mobile entity.
According to a seventh implementation form of the first aspect, the invention relates to a method, wherein the allocated mobility binding entity forwards the data traffic received from the forwarding entity to a gateway entity of a packet data network, the gateway entity being one of the plurality of mobility binding entities or one of one or more forwarding entities. According to a second aspect, the invention relates to a device for a
communication network having one or more forwarding entities for providing data packets for a data path and a plurality of mobility binding entities for forwarding data packets on the data path. The device is configured to register a mobile entity attached to the communication network. The device is further configured to allocate a mobility binding entity of the plurality of mobility binding entities in response to a request for a binding information assigned to the mobile entity, the request being received from one forwarding entity of one or more forwarding entities. The device is further configured to transmit the requested binding information to the one forwarding entity, the binding information including an identity of the allocated mobility binding entity, to which data traffic assigned to the mobile entity is to be forwarded by the one forwarding entity. According to some implementation forms of the second aspect, the device is embodied as a mobility controller as described for the first aspect of the invention . According to further implementation forms of the second aspect, the device can be configured to handle an update request for updating the binding information as described for the first aspect of the invention. The device can further be configured to handle a termination request as described for the first aspect of the invention.
According to some implementation forms of the second aspect, the device configured to perform the method of the first ascpect.
According to a third aspect, the invention relates to a communication system for a communication network, the communication system comprising one or more forwarding entities for providing data packets for a data path, a plurality of mobility binding entities for forwarding data packets on the data path, and a device 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; shows a flowchart of a method according to an implementation form; Fig. 5 shows a flowchart of a method according to an implementation form; Fig. 6 shows a flowchart of a method according to an implementation form; and
Fig. 7 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 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.
In the following, it will be described how the MN 110 connects to the provider network 130 and the data network 140 respectively, and how data traffic is transmitted from and to the MN 1 10. Hence, upon attachment of the MN 1 10 to the network 130, the MN 1 10 is registered with the MC 120. No data path is bound to the MN 1 10 upon this attachment. When one of the FEs 151 , 152 has data traffic assigned to the MN 1 10 to be forwarded, the MC 120 selects one of the MBEs 161 , 162. The MC 120 establishes a data path for the MN 110 between the one FE and the selected MBE. When the MBE changes, for example, upon changes in the provider network 130, the MC 120 is notified. The MC 120 then notifies the FEs which have data traffic assigned to the MN 1 10.
Regarding the attachment to the network, the MN 1 10 requests and receives a network context, such as a reachable IP address or any other network address clearly identifying the attached MN 1 10. The MC 120 creates and stores a mobility binding containing, for example, a mapping between a communication identifier of the MN 1 10, wherein the communication identifier includes at least one of the following parameters of the mobile entity: a MAC address, an IMSI, an IP address, a device identifier, a subscriber identifier, a subscriber identity. The MC 120 may optionally store a locator identity for a data path, for example a fixed entity, to which the MN 1 10 is connected like a base station etc. As a result, the MC 120 in the control plane is the only entity in the system, namely the provider network 130, which is aware of the mobility binding of the MN 1 10. However, no strict data paths are allocated to the MN 1 10.
Regarding forwarding of data traffic, if one of the FEs 151 , 152 has data traffic to be forwarded, the data traffic being assigned to the MN 1 10, the respective FE requests from the MC 120 a binding information corresponding to an identifier of the MN 1 10. For example, the FE asks the MC 120 where to send the data traffic. In response to the request of the FE, the MC 120 allocates one of the MBEs 161 , 162 on the data path to the MN 1 10. For example, the MC 120 allocates an MBE which will receive the data traffic to or from the MN 1 10. The MC 120 may optionally maintain a cache containing the binding information between the identifier of the MN 1 10 and the allocated MBE. Accordingly, an MBE is selected or allocated for the MN 1 10 only when data traffic assigned to the MN 1 10 has to be forwarded. Regarding the establishment of the data path from the respective FE to the allocated MBE, the MC 120 may transmit the identity of the allocated MBE to the FE which has sent the request. For example, the MC 120 tells the FE to which MBE to send the data traffic to. The identity of the allocated MBE may be transmitted in a binding information. The message including the binding
information may be transmitted from the MC 120 to the respective FE either directly or through the allocated MBE. The MC 120 can inform the allocated MBE to establish a context towards the respective FE. For example, one or multiple bearers are established between the respective FE and the allocated MBE, including a default bearer. The MC 120 may initiate the establishment of a subscriber-based Quality of Service, QoS, rule and a Policy and Charging Control, PCC. Both a download data path and an upload data path may be established in a single operation step. However, upload data path and download data path may include different entities of the provider network 130. As a result, an entity on the data path is selected for data packet forwarding.
The respective FE forwards the data traffic to the allocated MBE. For example, data packets are transmitted to the allocated MBE.
Regarding a change of the MBE, the MC 120 may receive an update request or change request for the data path of the MN 1 10 wherein the request may be received from the network 130, from the allocated MBE etc. The request can be received also by administrative means, for example, for maintenance purposes. The request may be triggered internally in the MC 120, for example for load balancing purposes.
In response to the update request, the MC 120 allocates a new MBE on the data path for the MN 1 10. For example, the MC 120 allocates a new MBE which will receive the data traffic to or from the MN 110. It should be noted that is similar to the first allocation of the MBE described above, besides being a re-allocation of an MBE. The MC 120 may optionally update the cache containing the binding information between the identifier of the MN 1 10 and the allocated MBE.
Regarding the notification after the change of the MBE, the MC 120 may send the identity of the newly allocated MBE to one or more FEs. For example, the MC 120 sends the updated binding information to all FEs. However, the MC 120 may send such updated binding information only to those FEs which have requested binding information before. A message including the updated binding information may be sent from the MC 120 to the FE either directly or through the newly or through the former allocated MBEs. The MC 120 can inform the newly allocated MBE to establish a context towards the FE. For example, one or multiple bearers are established between the FE and the newly allocated MBE, including a default bearer. If according to some implementation forms the FEs have a cache for the binding information for the MN 1 10, the binding information can be updated in such cache.
As a result, data packets are forwarded from the FE to the newly allocated MBE on the data path. Fig. 2 shows a communication network according to a further implementation form. A mobile entity or mobile node 1 10 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. Accordingly, a strict binding between the MN 1 10 and a base station is assumed, while towards an IP domain , represented by the PDN 240, a loose data path is assumed. The base station represents the entity to which the MN 1 10 is strictly bound to for communication. For example, the base station can be represented by an eNodeB for EPC. A generic gateway, GG, represents a gateway on the data path to which a mobility binding for the MN 1 10 is maintained. For example, for EPC, the GG can be represented by a PDN gateway or by a PDN and a S-Gateway. The GG may be required for subscriber-based bearer allocation and PCC. A forwarding entity at a border, FE-BR, is a function which may forward data traffic and/or to the MN 110 to and/or from the IP domain. The MC is represented by a separate functionality, for example an MME. The MN 1 10 may be bound to more than one base station at the same time. However, in the following examples it is considered that the MN 1 10 is bound only to one base station. Accordingly, download data traffic has to reach that specific base station in order to be forwarded to the MN 1 10.
Fig. 3 shows a flow chart of an operation according to some implementation forms. Described are communication and operation of a MN 301 , which may be
embodied as a user equipment, UE, a base station 303, which may be embodied as an eNodeB, a first and a second GG 305, 307, which may be embodied as PDN gateways, a mobility controller 309, which may be embodied as an MME with enhanced functionality, and Fes at the border of the operator domains, FE-BRs^ 31 1 , 313.
In this Fig. 3, attachment of the MN 301 to the network is described. In step 320, the MN 301 establishes its connectivity with the base station 303. In step 322 the base station sends to the MC 309 an identifier of the MN 301 and an identity of the base station 303 as allocation information. Optionally in this step 322, the base station 303 may require from the MC 309 an IP address to be allocated for the MN 301 . In step 324, the MC 309 receives the information from the base station 303 and adds cache entries to its cache. For example, the MC 309 stores that all download data traffic for the MN 301 has to be forwarded to base station 303. Furthermore it notes that no MBE was allocated, and that data traffic can be received from any FE-BR. Additionally it stores that upload data traffic is received from the base station 303, and no MBE was allocated for the upload either. Data traffic can be forwarded to any FE-BR. In step 326 the MC 309 sends to the base station 303 an acknowledgment. If the MC 309 allocates the IP address, then the acknowledgement contains the IP address. As a result, the MN 301 has its reachability information stored in the MC 309. No MBE has been selected at this stage.
Fig. 4 describes an operation regarding upload data traffic according to some implementation forms. In the drawing, entities 401 , 403, 405, 407, 409, 411 , 413 are shown which may correspond to the respective entities 301 to 313 of Fig. 3. It is assumed that a procedure of attachment according to Fig. 3 was executed. The MN 401 is connected to the network and the MC 409 has the reachability information. In step 420, the MN 401 announces the base station 403 of its intention to communicate. For example the announcing is performed through getting into connecting state or sending an upload data packet to the base station 403.
In step 422, the base station 403 checks if a PCC and a mobility context are established with any GG assuming that no data traffic was transmitted before. In step 424 the base station 403 requests forwarding information or binding information from the MC 409. In step 426, the MC 409 checks if binding
information including an MBE was allocated before and, if not allocates the GG 1 505 as an MBE for the MN 401 .
In step 428 the forwarding information is transmitted to the GG 405 and optionally to the base station 403. The forwarding information enables the GG 405 to know that a connection with a base station is required for the MN 401 . Furthermore, the forwarding information can enable the GG 1 to know that it can forward the data traffic to any FE-BR.
In step 430 the PCC and mobility context are established between the base station 403 and the GG 405. The establishment may be initiated by the GG 405. The mobility connection or mobility context may include the PCC and QoS rules and IP forwarding tunnel establishment. If the forwarding information was transmitted to the base station 403 in step 428, the PCC and mobility context establishment can be initiated by the base station 403. As a result of this operation, a temporary upload and download connection is established on the path from the mobile node 401 to the GG 405 via the base station 403. In step 432 which is an optional step, the GG 405 can take a forwarding decision, namely to which of the FE-BRs 41 1 , 413 data traffic shall be forwarded. Otherwise, the forwarding to the FE-BR can be executed statically through the existing IP routine mechanisms. It should be noted that only upload data traffic has to follow the allocated data paths.
Fig. 5 shows a flowchart of an operation according to some implementation forms, the operation relating to download data traffic for the MN. Fig. 5 shows the entities 501 , 503, 505, 507, 509, 511 , 513 which may correspond to previously described entities 301 to 313 or 401 to 413, respectively. It is assumed that an attachment operation according to Fig. 3 has been executed, the MN 501 is connected to the network and the MC 509 has a reachability information for the MN 501 .
In step 520, the FE-BR 513 receives a download packet for the MN 501 . The FE- BR 513 checks if it has a cache entry relating to the MN 501 . Assuming that no forwarding info is cached the FE-BR 513, the FE-BR 513 requests, in step 524, a binding information relating to the MN 501 from the MC 509. Similar to step 426, in step 526 the MC 509 checks the binding information and finds, for example, that all download traffic has to be forwarded to the base station 503, but no MBE has been allocated. The MC 509 then allocates the GG 505 as an MBE for the download data path for the MN 501 .
In step 528 the MC 509 transmits the forwarding information or binding information , e.g., to the FE-BR 513. Furthermore, if no MBE was previously allocated, the forwarding information or binding information is also provided to the allocated MBE, namely the GG 505. The FE-BR 513 creates a cache entry which includes the information received from the MC 509.
In step 532, which is an optional step, the forwarding information or binding information can be provided to the base station 503. This information enables the base station 503 to know that a connection with the GG 505 is required for the MN 501 . This may be helpful for example for triggering the MN 501 to get into connected state. In step 534, the PCC and mobility context or mobility connection is established between the base station 503 and the GG 505. The establishment may be initiated by the GG 505 or, if the base station 503 has the forwarding information, also by the base station 503.
As a result, for a period of time or for specific download data traffic, the data traffic is forwarded from the FE-BR 513 to a GG 505. Fig. 6 shows a flowchart of an operation according to some implementation forms. The operation relates to the re-selection of an MBE. Fig. 6 shows entities 601 , 603, 605, 607, 609, 61 1 , 613 which may correspond to the previously shown entities of Figs. 3 to 5. It is assumed that an attachment procedure according to Fig. 3 was executed and the MC 509 maintains reachability information. It is furthermore assumed that the MN 601 is connected to the network through the base station 603 and the GG 605. An upload binding information defines the gateway 605 as the allocated MBE for upload data traffic. Furthermore, for download data traffic it is defined that data traffic arriving at one of the FE-BRs 61 1 , 613 as forwarding entities has to be forwarded to the GG 605.
In step 620, an MBE reallocation decision is made such that the MC 609 has to execute an MBE reallocation procedure. This can, for example, be triggered by the attachment of the MN 601 through another base station, namely an access network handover. The reallocation procedure can further be triggered by administrative means such as maintenance operations, as depicted in Fig. 6. In the reallocation decision, this MC 609 decides to select the second GG 607 as a new MBE for the MN 601 . As upload and download bindings are available, the MC 609 replaces them such that upload data traffic has to be forwarded from the base station 603 to the GG 607, and download data traffic received from one of the FE- BRs 61 1 , 613 has to be forwarded to the GG 607.
In step 622, which is an optional step, the forwarding information or binding information is provided to the newly allocated MBE, the GG 607. The information may be transmitted also to the base station 603. The information enables the base station 603 to know that a connection with the GG 607 is required for the MN 601 . The information may also be transmitted to the previously allocated MBE, namely the GG 605. This information enables the GG 605 to delete the PCC and mobility context and to forward data addressed to MN 601 to the GG 607.
In step 624, the PCC and mobility context is established between the base station 603 and the GG 607, which is initiated by the GG 607. The mobility context includes the PCC and QoS rules and IP forwarding tunnel establishment. In case, in step 622 the information was also sent to the base station 603, the PCC and mobility context establishment can also be initiated by the base station 603. As a result of this operation, a temporary upload and download connection is
established on the path from the mobile node 601 to base station 603 to GG 607. In step 626 the MC 609 checks which of the FE-BRs 611 , 613 require an update. It sends them forwarding info update. In step 628, the FE-BRs 61 1 , 613 update their cache with the information that download data packets related to the MN 601 have to be forwarded the newly allocated GG 607. Fig. 7 shows a flowchart of an operation according to some implementation forms. The operation relates to the termination of a binding. The entities 701 , 703, 705, 707, 709, 71 1 , 713 may correspond to the previously described entities of the Figs. 3 to 6. Similar to some of the implementation forms described before, it is assumed that GG 705 is allocated as an MBE for upload and download connections, and the MN 701 is connected to the network. In step 720, a decision to free the MBE allocation is made. Accordingly, the MC 709 has to execute an MBE free procedure. This can be triggered by, for example, the MN 701 being in an idle mode or not communicating for a predefined period of time. Other triggers could be the attachment of the MN 701 from any network. The MC 709 decides to delete the MBE bindings of the MN 701 such that no MBE is allocated for the MN as well for upload data traffic and download data traffic.
In step 722, the MC 709 checks which of the FE-BRs 711 , 713 require termination information. The MC sends to the FE-BRs 711 , 713 an updated binding
information including the information about the deletion of the allocation of the MBE. In step 724, the FE-BRs 71 1 , 713 delete the respective information in their caches.
In step 726, the MC 709 sends the termination information also to the previously allocated GG 705. Furthermore, the information may also be transmitted to the base station 703. In step 728, the PCC and mobility context between the base station 703 and the allocated GG 705 is terminated, initiated by the GG 705. If the updated binding information was also transmitted to the base station 703 in step 726, the termination of the mobility context can also be initiated by the base station 703.
As a result of this operation, temporary upload and download connection is terminated on the previously allocated path.
It is apparent that the above described procedures can be combined and that steps executed in one of the procedures can be exchanged with steps of other procedures, for example with respect to allocation and transmitting information regarding the allocation.
According to some implementation forms, upload and download data paths can be allocated separately. However, to simplify the allocation procedure, both the upload and the download data path can be allocated simultaneously. For both the upload and download data paths, the FEs may be independent of each other. Therefore, multiple data paths can be used simultaneously and can be seamlessly interchangeable.
According to some implementation forms, if the FEs are eNodeBs or access points and the MBEs are gateways inside the operator domain or a provider network, then the MN can be connected simultaneously over multiple access networks, so- called multi-interface MNs. If the FEs are entities at the border of the operator domain, so-called FE-BRs, and the MBEs are gateways located close to the MN, then the data traffic of the MN can be received from the IP domain over multiple core network links without requiring indirection to any central entity such as a PDN gateway. Multiple MBEs may be used simultaneously for the same MN, e.g., if a policy-based decision is made either on the MC or through the PCC. Therefore, also split or merge of data traffic of a MN is possible, for example, if fine-grained traffic detection is executed by the gateways and/or FEs.
In the above described implementation forms, there is no strict binding between the mobile node and a data path. A decision of a data path optimization can be dynamically taken based on different events such as network load, mobility of the MN etc. Data traffic forwarded to the operator network can be controlled more dynamically, at the following levels of granularity: for one or more data packets, for one or more data flows, for the complete communication of the MN. A data path may be allocated on demand, only when it is required. The data path can be reallocated seamlessly. For example, data path reallocation does not influence the data packets in transit, namely data packets already been forwarded on another data path. Furthermore, data path reallocation may be executed on the FE between two data packets without a requirement of buffering. It is also possible to reselect the capacity of the data path on demand. According to some implementation forms, the data path may be reallocated only when required. No reallocation of a data path may be executed unless an FE requests this. Reallocation information may be transmitted only to the FEs which have or had data packets to be forwarded for the MN. The above described implementation forms allow that multiple data path can be used at the same time. Furthermore, reduced signalling in specific situation can be achieved. No messages may be transmitted to the data path entities unless the MN is communicating. The messages my be transmitted only to the FEs which have or had forwarded data traffic for or from the MN.
The above described implementation forms do not require a modification of the network forwarding mechanisms such as IP routing. The described implementation forms can be used on top of a variety of forwarding mechanisms and does not modify the forwarding mechanism of the underlying network transport.
The described implementation forms can be deployed even in transition stages from EPC to flat architectures. For example, the procedures described above can be deployed with the FE in an eNodeB and an MBE in an S-Gateway/PDN gateway for upload data traffic and with an FE in IP domain of the operator and a MBE on the PDN gateway for download data traffic.

Claims

Method for establishing a data path for a mobile entity (110) in a
communication network having one or more forwarding entities (151 , 152) for providing data packets for a data path and a plurality of mobility binding entities (161 , 162) for forwarding data packets on the data path, the method comprising:
- receiving, by one forwarding entity (151 , 152) of the one or more
forwarding entities (151 , 152), data traffic assigned to the mobile entity (1 10);
- requesting, by a request of the one forwarding entity (151 , 152), a
binding information assigned to the mobile entity (1 10);
- allocating, in response to receiving the request of the one forwarding entity (151 , 152), a mobility binding entity (161 , 162) of the plurality of mobility binding entities (161 , 162);
- providing the requested binding information, the binding information including an identity of the allocated mobility binding entity (161 , 162); and
- forwarding, by the one forwarding entity (151 , 152), in dependence on the binding information, the data traffic to the allocated mobility binding entity (161 , 162).
Method according to claim 1 ,
wherein, in response to an update request for updating the binding information, a further mobility binding entity of the plurality of mobility binding entities (161 , 162) is allocated to the mobile entity (110), and the updated binding information is provided to the one forwarding entity, the updated binding information including an identity of the allocated further mobility binding entity assigned to the mobile entity (1 10).
Method according to claim 1 or 2,
wherein the identity of the allocated further mobility binding entity is provided to the previously allocated mobility binding entity, and wherein the previously allocated mobility binding entity forwards incoming data traffic, that is assigned to the mobile entity (1 10), to the allocated further mobility binding entity.
Method according to one of the preceding claims,
wherein a data path is allocated for the data traffic, the data path including the mobile entity (1 10), the one forwarding entity (151 , 152) and the allocated mobility binding entity (161 , 162).
Method according to one of the preceding claims,
wherein the data traffic is transmitted on a data path from the mobile entity (1 10) to the allocated mobility binding entity via the one forward entity, if the data traffic originates from the mobile entity (110).
Method according to one of the preceding claims,
wherein the data traffic is transmitted on a data path from the one forwarding entity to the mobile entity (110) via the allocated mobility binding entity, if the data traffic is targeted at the mobile entity (110).
Method according to one of the preceding claims,
wherein, in response to a termination request, the allocation of the allocated mobility binding entity (161 , 162) is deleted, and an updated binding information is provided to the mobility binding entity (161 , 162), whose allocation is deleted, the updated binding information including the deleted allocation.
Method according to the preceding claim,
wherein the updated binding information including the deleted allocation is provided to the one or more forwarding entities (151 , 152), to which a binding information was provided before.
Method according to one of the preceding claims, further comprising
- receiving, by a further forwarding entity of the one or more forwarding entities (151 , 152), data traffic targeted at the mobile entity (1 10);
- requesting, by the further forwarding entity (151 , 152), the binding
information assigned to the mobile entity (1 10);
- providing the requested binding information to the further forwarding
entity (151 , 152), the binding information comprising the identity of the allocated mobility binding entity (161 , 162); and
- forwarding, by the further forwarding entity (151 , 152), the data traffic to the allocated mobility binding entity (161 , 162).
Method according to one of the preceding claims,
wherein, after the binding information is provided to a forwarding entity (151 , 152), a mobile connection is registered between the forwarding entity (151 , 152) and the allocated mobility binding entity (161 , 162).
Method according to one of the preceding claims,
wherein the allocating is performed by a mobility controller (120).
Method according to one of the preceding claims,
wherein the mobile entity (1 10) is registered with a mobility controller (120) and registering includes transmitting a communication identifier to the mobility controller (120), the communication identifier including at least one of the following parameters of the mobile entity (1 10):
- a Media Access Control, MAC, address;
- an International Mobile Subscriber Identity, IMSI;
- an Internet Protocol, IP, address;
- a device identifier; - a subscriber identifier;
- a subscriber identity.
13. Method according to one of the preceding claims,
wherein the allocated mobility binding entity (161 , 162) forwards the data traffic received from the forwarding entity (151 , 152) to a gateway entity of a packet data network, the gateway entity being one of the plurality of mobility binding entities (161 , 162) or one of one or more forwarding entities (151 , 152).
14. Device for a communication network having one or more forwarding
entities (151 , 152) for providing data packets for a data path and a plurality of mobility binding entities (161 , 162) for forwarding data packets on the data path, the device being configured to:
- register a mobile entity (1 10) attached to the communication network;
- allocate a mobility binding entity of the plurality of mobility binding
entities (161 , 162) in response to a request for a binding information assigned to the mobile entity (1 10), the request being received from one forwarding entity (151 , 152) of the one or more forwarding entities (151 , 152); and
- transmit the requested binding information to the one forwarding entity, the binding information including an identity of the allocated mobility binding entity, to which data traffic assigned to the mobile entity (1 10) is to be forwarded by the one forwarding entity.
15. Communication system for a communication network, the communication system comprising one or more forwarding entities (151 , 152) for providing data packets for a data path, a plurality of mobility binding entities (161 , 162) for forwarding data packets on the data path, and a device of the preceding claim.
PCT/CN2011/071315 2011-02-25 2011-02-25 Method for establishing a data path, device and communication system WO2012113156A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/CN2011/071315 WO2012113156A1 (en) 2011-02-25 2011-02-25 Method for establishing a data path, device and communication system
CN201180005033.XA CN103069917B (en) 2011-02-25 2011-02-25 For setting up the method for data path, equipment and communication system
EP11815838A EP2507955A4 (en) 2011-02-25 2011-02-25 Method for establishing a data path, device and communication system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2011/071315 WO2012113156A1 (en) 2011-02-25 2011-02-25 Method for establishing a data path, device and communication system

Publications (1)

Publication Number Publication Date
WO2012113156A1 true WO2012113156A1 (en) 2012-08-30

Family

ID=46720101

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/071315 WO2012113156A1 (en) 2011-02-25 2011-02-25 Method for establishing a data path, device and communication system

Country Status (3)

Country Link
EP (1) EP2507955A4 (en)
CN (1) CN103069917B (en)
WO (1) WO2012113156A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107026776A (en) * 2017-04-20 2017-08-08 深圳拓邦股份有限公司 A kind of communication path collocation method, apparatus and system
CN117527680A (en) * 2022-07-29 2024-02-06 华为技术有限公司 Resource reservation path establishment and communication method and device

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008199083A (en) * 2007-02-08 2008-08-28 Nec Access Technica Ltd Method of controlling router route, and router
CN101656765A (en) * 2009-09-14 2010-02-24 中兴通讯股份有限公司 Address mapping system and data transmission method of identifier/locator separation network
CN101662811A (en) * 2009-08-17 2010-03-03 北京航空航天大学 Distributed routing protocol based on reliable path

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2071807A1 (en) * 2007-12-11 2009-06-17 Nokia Siemens Networks Oy Advanced Mobile IP system employing distributed home agents

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008199083A (en) * 2007-02-08 2008-08-28 Nec Access Technica Ltd Method of controlling router route, and router
CN101662811A (en) * 2009-08-17 2010-03-03 北京航空航天大学 Distributed routing protocol based on reliable path
CN101656765A (en) * 2009-09-14 2010-02-24 中兴通讯股份有限公司 Address mapping system and data transmission method of identifier/locator separation network

Also Published As

Publication number Publication date
CN103069917A (en) 2013-04-24
CN103069917B (en) 2015-08-19
EP2507955A4 (en) 2013-01-02
EP2507955A1 (en) 2012-10-10

Similar Documents

Publication Publication Date Title
US8488559B2 (en) Method and an apparatus for providing route optimisation
JP6619815B2 (en) Access control apparatus, system, and method
US9998569B2 (en) Handling multipath transmission control protocol signaling in a communications network
US9480099B2 (en) Mobility anchor relocation
US8447304B2 (en) Mobile communication system and access gateway having plural user plane AGWs
US20160374095A1 (en) Sdn-based lte network structure and operation scheme
US20110019644A1 (en) Method for switching session of user equipment in wireless communication system and system employing the same
JP2011504699A (en) Method and apparatus for use in a communication network
US20150289203A1 (en) Service Node Selection in a Communications Network based on Application Server Information
CN107534608B (en) Method and apparatus for processing data streams in a wireless communication network
US10299181B2 (en) Method and apparatus for configuring disconnected TCP connection in communication system, handover support method and apparatus therefor
CN105874830A (en) Mobility management method, apparatus, and system
US11894937B2 (en) Local user plane function control
JP5655018B2 (en) Handover processing system and gateway router
EP2724563B1 (en) Caching over an interface between a radio access network and a core network
EP2617259A1 (en) A method for providing a local traffic shortcut in a packet-oriented mobile communication network
US10701600B2 (en) 5G core network optimized local handover
KR20230091908A (en) Method and Apparatus for Packet Rerouting
US20160302121A1 (en) Method and apparatus for transmitting ip packet using segment routing
CN114642074A (en) Method for influencing data traffic routing in core network
EP2507955A1 (en) Method for establishing a data path, device and communication system
CN108028799B (en) Service flow forwarding function deployment method, device and system
JP2011509611A (en) Techniques for optimizing routes in communication networks
JP2020191497A (en) Information processing method
KR102036687B1 (en) Method and apparatus for data packet route optimization in distributed network

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180005033.X

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2011815838

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE