WO2012113154A1 - Procédé et dispositif pour l'adaptation d'un chemin de données pour une entité mobile dans un réseau de communications - Google Patents

Procédé et dispositif pour l'adaptation d'un chemin de données pour une entité mobile dans un réseau de communications Download PDF

Info

Publication number
WO2012113154A1
WO2012113154A1 PCT/CN2011/071307 CN2011071307W WO2012113154A1 WO 2012113154 A1 WO2012113154 A1 WO 2012113154A1 CN 2011071307 W CN2011071307 W CN 2011071307W WO 2012113154 A1 WO2012113154 A1 WO 2012113154A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
forwarding
binding
data path
mobile
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/CN2011/071307
Other languages
English (en)
Inventor
Qing Zhou
Konstantinos Pentikousis
Cornel Pampu
Marius CORICI
Dragos VINGARZAN
Thomas MAGEDANZ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Fraunhofer Gesellschaft zur Foerderung der Angewandten Forschung eV
Original Assignee
Huawei Technologies Co Ltd
Fraunhofer Gesellschaft zur Foerderung der Angewandten Forschung eV
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 Foerderung der Angewandten Forschung eV filed Critical Huawei Technologies Co Ltd
Priority to PCT/CN2011/071307 priority Critical patent/WO2012113154A1/fr
Priority to CN201180002695.1A priority patent/CN102860084B/zh
Publication of WO2012113154A1 publication Critical patent/WO2012113154A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering

Definitions

  • the present invention relates to communications in a communication network, in particular to radio communication systems such as a 2nd generation system, e.g. a Global System for Mobile Communications (GSM) or a 3rd Generation
  • a 2nd generation system e.g. a Global System for Mobile Communications (GSM) or a 3rd Generation
  • 3GPP 3rd Generation Partnership Project
  • UMTS Universal Mobile Telecommunications System
  • LTE Long Term Evolution
  • UMTS Universal Mobile Telecommunications System
  • a mobile communication provider usually provides several entities like gateways that establish a connection to the packet data network for the mobile terminal.
  • GSN GPRS support nodes
  • 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 standardization organisations like 3GPP and IETF considered for any mobile node, given a data path, that a strict length of the data path is used for mobility managed forwarding of data traffic.
  • a single mobility binding entity MBE
  • PDN packet data network gateway
  • a set of tunnels may be established between the mobile node and mobility binding entity.
  • the mobility domain Due to the strict conventional binding between the mobile node and the mobility binding entity, the mobility domain is fixed in size, independent on any mobility- related characteristics or mobility patterns of the mobile node. For example, wireless connected devices that do not move and, therefore, have a fixed location, have the same mobility domain as fully mobile devices.
  • 3GPP EPC Evolved Packet Core
  • a PDN gateway GW
  • a set of tunnels is established between the UE and the PDN GW.
  • more than one PDN data path may be established.
  • the data traffic may be not seamlessly and dynamically balanced over these multiple PDN data paths.
  • 3GPP EPC provides a fixed mobility domain, i.e. optimal data path and transparent mobility using the same PDN GW, regardless of the mobility patterns of the user equipments. That means that the mobility domain size is the same, e.g. house appliances and smart phones have the same mobility domain.
  • the same number of entities has to maintain mobility management associations, e.g. eNodeB, Serving- GW (S-GW), and PDN GW. Further, tunnels have to be established between the same numbers of entities.
  • mobility management associations e.g. eNodeB, Serving- GW (S-GW), and PDN GW. Further, tunnels have to be established between the same numbers of entities.
  • 3GPP may flexibly select a PDN GW based on access point name (APN). Said offloading may be not adjusted dynamically.
  • APN access point name
  • a fixed mobility domain is conventionally defined for each UE and for each PDN connection.
  • a pre-configuration is needed dependent on offline network planning and dimensioning.
  • nearly-fixed devices including those with restricted mobility, are handled the same way with respect to mobility management functionality with mobile devices.
  • the mobility domain is fixed, needs to be preconfigured for deployment independent on the mobility pattern of the users.
  • new PDN connections have to be established for parts or complete data traffic in case the mobility domain has to be modified, e.g. for offloading data traffic.
  • a goal to be achieved by the present invention is to provide an improved data path binding in a communication network.
  • a method for adapting a data path for a mobile entity in a communication network has at least one forwarding entity for providing data packets for the data path and a plurality of mobility binding entities for forwarding data packets on the data path, wherein a first mobility binding entity is allocated to the data path for the mobile entity according to binding information for the mobile entity.
  • the method has a step of receiving a re-allocation request for re-allocating a second mobility binding entity to the data path for the mobile entity, a step of updating the binding information for the mobile entity on the basis of the received re-allocation request, a step of forwarding data packets received from the forwarding entity by the first mobility binding entity to the second mobility binding entity until the updated binding information is received at the forwarding entity, and/or a step of forwarding data packets from the forwarding entity to the second mobility binding entity after the updated binding information is received at the forwarding entity.
  • the re-allocation request may be a request for substituting the source MBE by the target MBE in the data path for the mobile entity.
  • the re-allocation request may include an identity indication indicating the target MBE.
  • the re-allocation request may be received by the source MBE.
  • the source MBE may then have the identity indication of the target MBE. Because the source MBE knows the identity indication and therefore the identity of the target MBE, the source MBE may forward data packets to the target MBE. In the time interval between the reception of the re-allocation request and the reception of the updated binding information by the forwarding entity, the forwarding entity may remain unaware of the MBE re-allocation. Thus, the forwarding entity may continue to send packets to the source MBE. Because the source MBE may create a binding with the target MBE to forward the data packets to the target MBE, the packets are not omitted.
  • the data path may be re-allocated without packet loss, because data packets follow the data path binding through the forwarding entity, the source mobile entity and the target mobile entity until the forwarding entity receives the updated binding information.
  • the forwarding entity received the update binding information, the data path is shifted to the sequence of the forwarding entity and target MBE.
  • the method may also receive the re-allocation request at the forwarding entity from the first mobility binding entity, update the binding information for the mobile entity on the forward entity and/or forward data packets toward the mobile entity from the forwarding entity to the second mobility binding entity.
  • this procedure may not influence the packets in transit. Thus, no buffering of data packets may be required.
  • the mobility binding entity MBE is only reallocated after receiving a re-allocation request. Thus, the data path is only updated when required. Further, according to some implementations, no data path may be established through the target MBE unless data traffic has to be forwarded even though a target MBE is selected for the mobile entity.
  • the updated binding information may be transmitted as a reaction to the forwarding entity forwarding a packet to or from the mobile entity. Moreover, according to some implementations, no binding information or mobile binding information may be updated in a forwarding entity, unless this forwarding entity forwarded at least one data packet to or from the mobile entity.
  • the re-allocation request may be a re- selection request.
  • Re-allocation may include that one mobility binding entity is already allocated to the data path for the mobile entity and the already allocated mobility binding entity is substituted by another mobility binding entity.
  • a decision of data path self-adaptation or re- allocation may be dynamically taken based on different parameters, such as network load, mobile entity, mobility or the like.
  • data traffic forwarded through an operator network may be more dynamically controlled, in particular at different levels of granularity.
  • the source MBE may use Traffic Flow Template (TFT) to differentiate data traffic that has to be sent to the target MBE.
  • TFT Traffic Flow Template
  • the forwarding entity may forward traffic through traffic filtering to multiple MBEs at the same time.
  • the present procedure may provide reduced signalling in case that there is no data traffic from or to the mobile entity.
  • no modification of the network forwarding mechanism such as IP routing is necessary.
  • the present procedure may be used on top of a variety of forwarding mechanisms and may not modify forwarding mechanism of the underlying network transport.
  • a mobility binding entity may be any entity which is configured to forward data packets on the data path.
  • the forwarding entity may be any entity which is configured to provide data packets for the data path.
  • the mobile entity may be a mobile node, for example a user equipment, a mobile phone or a smart phone.
  • the method has a step of receiving the re-allocation request at the first mobility binding entity, a step of updating the binding information for the mobile entity on the basis of the received re-allocation request by the first mobility binding entity, and a step of transmitting the updated binding information from the first mobility binding entity to the forwarding entity.
  • the first or source MBE may be the entity which receives the re-allocation request.
  • the re-allocation request may be the event triggering the data path binding update.
  • the source MBE may receive data packets from the forwarding entity, because this may be the only known path between the forwarding entity and the MBE for their specific mobile entity.
  • the data packets may be sent from the mobile entity or to the mobile entity. This means uplink and downlink is possible.
  • the source MBE proceeds with the update of the data path binding. That means that the source MBE is the entity for updating the binding information in this first implementation form. Further, the source MBE forwards the data packets received from the forwarding entity to the target MBE using the data path binding
  • the source MBE may send the forwarding entity the new binding information in the form of the updated binding information for the specific mobile entity.
  • data packets are passing through the data path [forwarding entity - source MBE - target MBE], for both uplink and downlink. Further, when the forwarding entity receives the transmitted updated binding information from the source MBE, the forwarding entity replaces the data path binding information with the newly received updated binding information.
  • the forwarding entity may forward data packets to the target MBE.
  • data packets may pass through the data path [forwarding entity - target MBE].
  • the method has a step of receiving the re-allocation request at the first mobility binding entity, said re-allocation request including an identity indication indicating an identity of the second mobility binding entity, a step of extracting the identity indication from the received re-allocation request, and a step of forwarding data packets received from the forwarding entity by the first mobility binding entity to the second mobility binding entity on the basis of the extracted identity indication until the updated binding information is received at the forwarding entity.
  • the method has a step of receiving the re-allocation request at the second mobility binding entity, a step of updating the binding information for the mobile entity on the basis of the received re-allocation request by the second mobility binding entity, and a step of transmitting the updated binding information from the second mobility binding entity to the first mobility binding entity and to the forwarding entity.
  • the method has a step of creating a binding between the first mobility binding entity and the second mobility binding entity for a time interval between a first instance of time when receiving the re-allocation request and a second instance of time when the updated binding information is received at the forwarding entity.
  • the binding may be a mobile binding, in particular including a mobile context.
  • the mobile context may include at least one of the following: a Policy and
  • the data path is allocated for the data traffic such that the data path has the mobile entity, the one forwarding entity and the first mobility binding entity and/or the second mobility binding entity.
  • the data path is allocated for the data traffic in dependence on the binding information for the mobile entity such that the data path has different entities in different times.
  • the data path Before the first instance of time when the re-allocation request is received, the data path has the mobile entity, the one forwarding entity and the first mobility binding entity. Between the first instance of time and the second instance of time when the updated binding information is received at the forwarding entity, the data path has the mobile entity, the one forwarding entity, the first mobility binding entity and the second mobility binding entity. After the second instance of time, the data path has the mobile entity, the one forwarding entity and the second mobility binding entity.
  • the data traffic is transmitted on the data path from the mobile entity to the allocated mobility binding entity via the one forwarding entity, if the data traffic originates from the mobile entity.
  • the data traffic is transmitted over an uplink data path.
  • the data traffic is transmitted on the data path from the one forwarding entity to the mobile entity via the allocated mobility binding entity, if the data traffic is targeted at the mobile entity. Therefore, the data traffic is transmitted over a downlink data path.
  • a first data path is allocated for uplink data traffic and a second data path is allocated for downlink data traffic, wherein the binding information for the first data path and the second data path are updated simultaneously.
  • the one forwarding entity when the one forwarding entity receives a data packet from a certain mobility binding entity, the one forwarding entity establishes a reverse data path through the certain mobility binding entity.
  • a plurality of independent forwarding entities is provided for allocating a plurality of data paths to the mobile entity.
  • the forwarding entities may be independent of each other.
  • multiple data paths may be used simultaneously and may be seamlessly interchanged.
  • the forwarding entities are embodied as eNodeBs or access points and the MBEs are gateways inside an operator domain
  • the mobile entity may be connected simultaneously over multiple access networks, e.g. multi-interface mobile nodes.
  • the forwarding entities are entities at the border of the operator domain and the MBEs are gateways located close to the mobile entity, then the data traffic of the mobile entity may be received from the IP domain over multiple core network links without requiring indirection to any central entity such as a Proxy Gateway (P-GW).
  • P-GW Proxy Gateway
  • multiple MBEs may be used simultaneously for the same mobile entity if a policy-based decision is made, e.g. multi-path support permission.
  • the mobility binding entity is embodied by an access network gateway, an access router, an eNodeB, an access point/base station or a forwarding entity at a border of an operator domain.
  • the forwarding entity is embodied by an eNodeB, an access point/base station, an access router or an backhaul entity for forwarding data packets towards at least one gateway.
  • eNodeB an access point/base station
  • access router an access router
  • backhaul entity for forwarding data packets towards at least one gateway.
  • implementation form of the first aspect to obtain another implementation form of the first aspect.
  • the invention relates to a computer program comprising a program code for executing the method for adapting a data path for a mobile entity in a communication network when run on at least one computer.
  • a device for adapting a data path for a mobile entity in a communication network having at least one forwarding entity for providing data packets for the data path and a plurality of mobility binding entities for forwarding data packets on the data path, a first mobility binding entity being allocated to the data path for the mobile entity according to binding information for the mobile entity, the device comprising:
  • a receiving entity for receiving a re-allocation request for re-allocating a second mobility binding entity to the data path for the mobile entity
  • an updating entity for updating the binding information for the mobile entity on the basis of the received re-allocation request
  • a first forwarding entity for forwarding data packets received from the forwarding entity by the first mobility binding entity to the second mobility binding entity until the updated binding information is received at the forwarding entity
  • a second forwarding entity for forwarding data packets from the forwarding entity to the second mobility binding entity after the updated binding information is received at the forwarding entity.
  • the receiving entity may be any receiver or any receiving means.
  • the updating entity may be any updating means.
  • the respective forwarding entity may be any forwarding means.
  • the respective means in particular the receiving entity, the updating entity and the respective forwarding entity, may be implemented in hardware or in software. If said means are implemented in hardware, it may be embodied as a device, e.g. as a computer or as a processor or as a part of a system, e.g. a computer system. If said means are implemented in software it may be embodied as a computer program product, as a function, as a routine, as a program code or as an executable object.
  • a system in particular a communication system is suggested, said system comprising at least one device for adapting a data path for mobile entity in a communication network.
  • FIG. 1 shows an implementation form of a method for adapting a data path for a mobile entity in a communication network
  • Fig. 2 shows an implementation form of an arrangement for carrying out the steps of Fig.1
  • Fig. 3 shows an implementation form of a data path according to the third step of Fig. 1 ,
  • Fig. 4 shows an implementation form of a data path according to the fourth step of Fig. 1 .
  • Fig. 5 shows a preparation procedure according to an implementation form
  • Fig. 6 shows an operation procedure for downlink data according to an
  • Fig. 7 shows an operation procedure for uplink data according to an
  • Fig. 8 shows an implementation form of a device for adapting a data path for a mobile entity in a communication network.
  • FIG. 1 an embodiment of a method for adapting a data path for a mobile entity in a communication network is depicted.
  • the implementation form of the method of Fig. 1 has the method steps 101 , 103, 105 and 107 and is described with reference to the arrangement 200 of Fig. 2, said arrangement 200 of Fig. 2 being configured to carry out the steps 101 -107 of Fig. 1 .
  • the arrangement 200 of Fig. 2 shows a mobile node (MN) 201 , a forwarding entity (FE) 203 coupled to the MN 201 and a further forwarding entity (FE) 205. Between the two forwarding entities (FE) 203 and 205, there are two mobility binding entities (MBE) 207 and 209 coupled. With attaching the MN 201 to the arrangement 200, exemplarily embodied by a communication network, the MBE 207 is allocated to the MN 201 . Thus, the MBE 207 is also called source MBE 207.
  • the source MBE 207 is allocated to the data path for the MN 201 according to binding information for the mobile entity 201 .
  • a re-allocation request for re-allocating a second or target MBE 209 to the data path for the MN 201 is received.
  • Re-allocation may mean that the allocation of the source MBE 207 to the data path for the MN 201 is deleted and the target MBE 209 is allocated to said data path instead.
  • said reallocation request may be received by the source MBE 207.
  • the binding information for the MN 201 is updated on the basis of the received re-allocation request. Said updating may be performed by the source MBE 207.
  • step 105 data packets received from the forwarding entity 203 or 205 are forwarded by the source MBE 207 to the target MBE 209 until the updated binding information is received at the forwarding entity 203 or 205.
  • the forwarding entity 203 For uplink, it is the forwarding entity 203.
  • the forwarding entity 205 In contrast, for downlink, it is the forwarding entity 205.
  • Fig. 3 shows an implementation form of a data path 300 according to the third step of Fig. 1 .
  • a binding between the source MBE 207 and the target MBE 209 may be created at least for a time interval between a first instance of time when the re-allocation request is received and a second instance of time when the updated binding information is received at the forwarding entity 203 (for uplink) or 205 (for downlink; not shown).
  • data packets from the forwarding entity 203 or 205 are forwarded to the target MBE 209 after the updated binding information is received at the forwarding entity 203 or 205.
  • this is the forwarding entity 203.
  • for downlink it is the forwarding entity 205.
  • Fig. 4 shows an implementation of a data path according to the step 107.
  • Data packets - illustrated by the arrows - are received by a forwarding entity 203 (uplink) or 205 (downlink, not shown) and directly forwarded to the target MBE 209 which may forward it to further entities in the communication network.
  • a bridge over the source MBE 207 may be not necessary in step 107, because the forwarding entity 203 has already received the updated binding information and knows the identity of the target MBE 209.
  • the data path is allocated for the data traffic in dependence on the binding information for the MN 201 such that the data path may have different entities in different times.
  • the data path Before the first instance of time when the re-allocation request is received, the data path has the mobile entity 201 , the forwarding entity 203 or 205 and the source MBE 207. Between the first instance of time and the second instance of time, when the updated binding information is received at the forwarding entity 203 or 205, the data path has the mobile entity 201 , the forwarding entity 203 and the forwarding entity 205, the source MBE 207 and the target MBE 209. After the second instance of time, the data path has the mobile entity 201 , the one forwarding entity 203 or 205 and the target MBE 209.
  • the source MBE 207 and the target MBE 209 may be embodied by an access network gateway, an access router, eNodeB, an access point/base station or a forwarding entity at a border of an operator domain, respectively.
  • the forwarding entities 203 and 205 may be embodied by an eNodeB, an access point/base station, an access router or a backhaul entity for forwarding data packets towards at least one gateway, respectively.
  • Fig. 5 a preparation procedure according to an implementation form is illustrated.
  • Fig. 5 shows a preparation procedure according to an implementation form which may be performed by a communication system 500.
  • the communication system 500 of Fig. 5 has a mobile node (MN) 501 , a base station (BS) 503, a source MBE 505, a target MBE 507 and forwarding entities border (FE-BR) 509, 51 1 , 513.
  • MN mobile node
  • BS base station
  • FE-BR forwarding entities border
  • FE-BR forwarding entities border
  • FE-BR forwarding entities border
  • the drawn-through double arrows show that strict forwarding information is available.
  • the dashed double arrow shows that loose information is available.
  • the single arrow shows an active procedure step.
  • Fig. 5 shows a strict binding between the MN 501 and the BS 503 and a loose path towards the IP domain.
  • the strict binding is shown by a UL & DL connection.
  • the loose paths towards the IP domain are shown by a respective loose DL connection (dashed double arrow).
  • the BS 503 represents the entity to which the MN 501 is strictly bound to for communication.
  • the BS 503 may be represented by an eNodeB.
  • the respective MBE 505 and 507 represents a data path gateway to which the MN 501 has to maintain a mobility binding.
  • the MBE 505 and 507 may be represented by a PDN (Packet Data Network) GW (Gateway) or a PDN & Serving GW. Further, the MBE 505 and 507 may be required for subscriber-based bearer allocation and Policy and Charging Control (PCC).
  • PDN Packet Data Network
  • PCC Policy and Charging Control
  • the forwarding entity border (FE-BR1 , FE-BR2, FE-BR3) 509, 51 1 , 513 is a function which forwards data traffic from/to the MN 501 to/from the IP domain. As indicated above, in the example of Fig. 5, three FE-BRs 509, 511 , 513 are considered.
  • the FE-BRs 509, 51 1 , 513 are able to forward data traffic to the MN 501 through the source MBE 505 having a data path binding for the MN 501. This is referred to as a loose DL connection.
  • the MN 501 may be bound to more than one BS 503 at the same time.
  • Fig. 6 shows an example for uplink (UL)
  • Fig. 7 shows an example for downlink (DL).
  • a UL and a DL path may be established between the BS 503 and the source MBE 505.
  • it may include PCC procedures on the BS 503 and on the source MBE 505.
  • the source MBE 505 receives data packets addressed to the MN 501 from any FE-BR 509, 511 , 513.
  • the source MBE 507 may forward data packets to any FE-BR 509, 51 1 , 513 according to an underlying routing
  • the source MBE 505 maintains for the MN 501 the binding:
  • DL data traffic for the MN 501 is to be forwarded to the BS 503 illustrated by BS in the above binding, and UL data traffic may be sent to any FE-BR 509, 51 1 , 513 illustrated by * .
  • a re-selection decision is made by the source MBE 505 for the MN 501 to use the target MBE 507.
  • the re-selection or re-allocation decision may be received from exterior triggers such as from the target MBE 507 as an attachment of the MN 501 through another BS (not shown), i.e. access network handover. Further, administrative means such as maintenance operations may be used.
  • the source MBE 505 transmits the forwarding information for the MN 501 to the target MBE 507: [MN identity, IP address, IMSI, BS, * ],
  • the target MBE 507 stores the transmitted forwarding information and knows where to send the data traffic from/to the MN 501 .
  • step 3 the source MBE 505 stores the identity of the target MBE 507 in the following forwarding entry:
  • the first mentioned target MBE means that the data traffic for the MN 501 has to be forwarded to the target MBE 507
  • the second mentioned target MBE means that UL data traffic may be sent to the target MBE 507.
  • the target MBE 507 may request PCC rules from the PCRF (Policy Control and Charging Rules Function). As the data traffic may all be forwarded through the target MBE 507, a single PCEF (Policy Control and Charging Enforcement Function) may be used for charging - the one on the target MBE 507 after step 2.
  • PCRF Policy Control and Charging Rules Function
  • Fig. 6 shows an operation procedure for downlink data according to an implementation form which may be performed by the communication system 500.
  • the communication system 500 of Fig. 6 corresponds to that of Fig. 5.
  • BS [MN Identity, IP Address, IMSI, MN, source MBE]
  • Source MBE [MN Identity, IP Address, IMSI, target MBE, Target MBE]
  • Target MBE [MN Identity, IP Address, IMSI, BS, * ]
  • FE-BRs [MN Identity, IP Address, IMSI, source MBE, * ]
  • step 1 an UL data packet is sent by the MN 501 to the BS 503.
  • step 2 the BS 503 sends the data packet to the source MBE 505 according to its UL mobility binding information.
  • step 3 the source MBE 505 checks the data path information and sends the data packet to target MBE 507 according to its UL mobility binding information.
  • step 4 the data packet is received by the target MBE 507, a forwarding decision is made and it is forwarded to the appropriate FE-BR, e.g. FE-BR1 509, which subsequently sends it to the IP domain.
  • FE-BR e.g. FE-BR1 509
  • step 5 the source MBE 505 sends a forwarding information message to the BS including: [MN identity, IP address, IMSI, MN, target MBE]
  • step 6 the BS 503 stores the new forwarding information to forward UL packets to target MBE 507. As a result, the BS 503 is forwarding UL data packets directly to the target MBE 507.
  • the FE-BR1 509 may optionally determine that the new MBE of the MN 501 is the target MBE 507 and to change internally its data path binding information to [MN Identity, IP Address, IMSI, target MBE, * ].
  • Fig. 7 shows an operation procedure for uplink data according to an implementation form which may be performed by a communication system 500 corresponding to that of Figs. 5 and 6.
  • the prerequisite for the example of Fig. 7 are that the preparation procedure of Fig. 5 was executed and the following information is available:
  • BS [MN Identity, IP Address, IMSI, MN, source MBE]
  • Source MBE [MN Identity, IP Address, IMSI, target MBE, target MBE]
  • Target MBE [MN Identity, IP Address, IMSI, BS, * ]
  • FE-BRs [MN Identity, IP Address, IMSI, source MBE, * ]
  • step 1 the DL packet is received by FE-BR2 51 1 from the IP domain addressed to the MN 501 .
  • step 2 the FE-BR2 51 1 sends the data packet to the source MBE 505
  • step 3 the source MBE 505 checks the data path binding information and sends the data packet to the target MBE 507 according to its DL mobility binding information.
  • step 4 the data packet is received by the target MBE 507, a forwarding decision is made and is forwarded to the BS 503 which sends it to the MN 501 .
  • step 5 the source MBE 505 sends a forwarding information message to the FE- BR2 51 1 including: [MN Identity, IP Address, IMSI, target MBE, * ].
  • the FE-BR2 51 1 stores the new forwarding information to forward DL data packets to target MBE 507.
  • the FE-BR2 511 is forwarding data packets directly to the target MBE 507.
  • the loose DL routes for these entities remain on the source MBE 505.
  • the BS 503 may optionally determine that a new MBE is the target MBE 507 and to change internally its data path binding information to: [MN Identity, IP Address, IMSI, MN, target MBE]. This information is already available in case of an uplink data transfer previous to the downlink data transfer.
  • the present self-adaptation of the binding may be easily deployed even in transition stages from EPC (Evolved Packet Core) to flat architectures. This may be employed, for example, with:
  • Fig. 8 shows an implementation form of a device 801 for adapting a data path for a mobile entity in a communication network.
  • the communication network has at least one forwarding entity for providing data packets for the data path and a plurality of mobility binding entities for forwarding data packets on the data path.
  • a first mobility binding entity is allocated to the data path for the mobile entity according to binding information for the mobile entity.
  • the device 801 has a receiving entity 803, an updating entity 805, a first forwarding entity 807, and a second forwarding entity 809.
  • the receiving entity 803 is configured to receive a re-allocation request for reallocating a second mobility binding entity to the data path for the mobile entity.
  • the updating entity 805 is configured to update the binding information for the mobile entity on the basis of the received re-allocation request.
  • the first forwarding entity 807 is configured to forward data packets received from the forwarding entity by the first mobility binding entity to the second mobility binding entity until the updated binding information is received at the forwarding entity.
  • the second forwarding entity 809 is configured to forward data packets from the forwarding entity to the second mobility binding entity after the updated binding information is received at the forwarding entity.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne un procédé et dispositif pour l'adaptation d'un chemin de données pour une entité mobile (201) dans un réseau de communications. Le réseau de communications comporte au moins une entité de retransmission (203, 205) pour fournir des paquets de données pour le chemin de données et une pluralité d'entités de liaison de mobilité (207, 209) pour la retransmission des paquets de données sur le chemin de données, la première entité de liaison de mobilité (207) étant allouée au chemin de données pour l'entité mobile (201) selon une information de liaison pour l'entité mobile (201). Le procédé comprend une étape de réception (101) d'une demande de réallocation d'une seconde entité de liaison de mobilité (209) au chemin de données pour l'entité mobile (201), une étape de mise à jour (103) de l'information de liaison pour l'entité mobile (201) sur la base de la demande de réallocation reçue, une étape de retransmission (105) des paquets de données reçus depuis l'entité de retransmission (203, 205) par la première entité de liaison de mobilité (207) à la seconde entité de mobilité (209) jusqu'à la réception de l'information de liaison mise à jour au niveau de l'entité de retransmission (203, 205), et une étape de retransmission (107) des paquets de données depuis l'entité de retransmission (203, 205) vers la seconde entité de liaison de mobilité (209) après la réception de l'information de liaison mise à jour au niveau de l'entité de retransmission (203, 205).
PCT/CN2011/071307 2011-02-25 2011-02-25 Procédé et dispositif pour l'adaptation d'un chemin de données pour une entité mobile dans un réseau de communications Ceased WO2012113154A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2011/071307 WO2012113154A1 (fr) 2011-02-25 2011-02-25 Procédé et dispositif pour l'adaptation d'un chemin de données pour une entité mobile dans un réseau de communications
CN201180002695.1A CN102860084B (zh) 2011-02-25 2011-02-25 通信网络中移动实体选配数据路径的方法和设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2011/071307 WO2012113154A1 (fr) 2011-02-25 2011-02-25 Procédé et dispositif pour l'adaptation d'un chemin de données pour une entité mobile dans un réseau de communications

Publications (1)

Publication Number Publication Date
WO2012113154A1 true WO2012113154A1 (fr) 2012-08-30

Family

ID=46720099

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/071307 Ceased WO2012113154A1 (fr) 2011-02-25 2011-02-25 Procédé et dispositif pour l'adaptation d'un chemin de données pour une entité mobile dans un réseau de communications

Country Status (2)

Country Link
CN (1) CN102860084B (fr)
WO (1) WO2012113154A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070248062A1 (en) * 2006-04-25 2007-10-25 Cisco Technology, Inc. Mobile network operator multihoming and enterprise VPN solution
CN101895458A (zh) * 2009-05-18 2010-11-24 大唐移动通信设备有限公司 一种分组数据网络连接的释放方法、系统和数据网关
US7876728B1 (en) * 2007-04-05 2011-01-25 Sprint Communications Company L.P. Maintaining path optimization during foreign agent handoff

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070248062A1 (en) * 2006-04-25 2007-10-25 Cisco Technology, Inc. Mobile network operator multihoming and enterprise VPN solution
US7876728B1 (en) * 2007-04-05 2011-01-25 Sprint Communications Company L.P. Maintaining path optimization during foreign agent handoff
CN101895458A (zh) * 2009-05-18 2010-11-24 大唐移动通信设备有限公司 一种分组数据网络连接的释放方法、系统和数据网关

Also Published As

Publication number Publication date
CN102860084A (zh) 2013-01-02
CN102860084B (zh) 2016-06-22

Similar Documents

Publication Publication Date Title
US10638376B2 (en) RAN based gateway functions
US11026276B2 (en) Inter-PGW handover architecture
JP5570611B2 (ja) 改善されたサービス品質処理のための通信方法、通信プロトコル及び通信装置
EP2471306B1 (fr) Relocalisation d'ancre de mobilité
US10103896B2 (en) Method and device of a policy control and charging (PCC) system in a communication network
CN105939527B (zh) 针对漫游用户的拥塞缓解
EP3041311B1 (fr) Appareil et procédé de communication dans un système de communication, et appareil et procédé de commande de voie de communication
EP3107248A1 (fr) Dispositif de traitement d'informations, procédé de communication, dispositif et procédé de commande de réseau, système de communication et programme
WO2015134985A1 (fr) Passerelle x2 fédérée
KR20230091908A (ko) 패킷 리라우팅을 위한 방법 및 장치
KR101481337B1 (ko) 소프트웨어 정의 네트워크 기반 이동통신 시스템 및 이의 단말 접속 처리 방법
EP3749018A2 (fr) Point d'accès mobile
EP3107249A1 (fr) Dispositif de traitement d'informations, procédé de communication, dispositif de commande de réseau, procédé de commande de réseau et programme
US20160212678A1 (en) Communication apparatus and method, communication path control apparatus and method in a communication system
US10609157B2 (en) Communication apparatus, communication method, and program
US9232438B2 (en) Device and a system for IP traffic offloading
EP3107250A1 (fr) Dispositif de traitement d'informations, procédé de communication, dispositif de commande de réseau, procédé de commande de réseau, système de communication, et programme
WO2015130937A1 (fr) Procédés et appareil de conversion d'une connexion à technologie d'accès radio unique en une connexion à technologies d'accès radio multiples
US20170156088A1 (en) Relay apparatus, communication apparatus, communication method, and program
WO2012113154A1 (fr) Procédé et dispositif pour l'adaptation d'un chemin de données pour une entité mobile dans un réseau de communications
WO2016019985A1 (fr) Procédé, produit-programme d'ordinateur et appareil permettant une différentiation de flux de trafic
WO2012113156A1 (fr) Procédé pour l'établissement d'un chemin de données, dispositif et système de communications
US20150236956A1 (en) Traffic flow mobility with single host connection
JP5855171B2 (ja) 改善されたサービス品質処理のための通信方法、通信プロトコル及び通信装置
Speicher 3.2 5G Core Network

Legal Events

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

Ref document number: 201180002695.1

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11859622

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11859622

Country of ref document: EP

Kind code of ref document: A1