WO2014188136A1 - Dispositif et procede de controle d'un coeur de reseau ip - Google Patents

Dispositif et procede de controle d'un coeur de reseau ip Download PDF

Info

Publication number
WO2014188136A1
WO2014188136A1 PCT/FR2014/051210 FR2014051210W WO2014188136A1 WO 2014188136 A1 WO2014188136 A1 WO 2014188136A1 FR 2014051210 W FR2014051210 W FR 2014051210W WO 2014188136 A1 WO2014188136 A1 WO 2014188136A1
Authority
WO
WIPO (PCT)
Prior art keywords
data transfer
gateway
communication
data
control device
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/FR2014/051210
Other languages
English (en)
Inventor
Malla Reddy SAMA
Siwar BEN HADJ SAID
Karine Guillouard
Lucian Suciu
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.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Publication of WO2014188136A1 publication Critical patent/WO2014188136A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • 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
    • 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/38—Flow based routing
    • 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
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0247—Traffic management, e.g. flow control or congestion control based on conditions of the access network or the infrastructure network

Definitions

  • the invention relates to the general field of telecommunications. It relates more particularly to an architecture of core network IP (Internet Protocol).
  • IP Internet Protocol
  • the invention thus applies in a preferred but non-limiting manner to communication networks that comply with the LTE (Long Term Evolution) standard defined by the 3GPP (Third Generation Partnership Project) standardization consortium, and more specifically to the architecture of an LTE / EPC (Evolved Packet Core) backbone.
  • LTE Long Term Evolution
  • 3GPP Third Generation Partnership Project
  • EPC Evolved Packet Core
  • the LTE / EPC architecture has been defined by the 3GPP consortium to provide seamless IP connectivity between a user's terminal, otherwise referred to as user equipment (UE), and wireless networks.
  • data packets or PDNs for Packet Data Networks
  • UE user equipment
  • wireless networks wireless networks.
  • data packets or PDNs for Packet Data Networks
  • voice over IP or VoIP services data downloads, video on demand etc.
  • This architecture is based on:
  • An access network (or E-UTRAN for the Evolved Universal Terrestrial Radio Access Network) to which the user's terminal is connected via a base station designated by "eNodeB” (eNB); and
  • An IP core network (or EPC) managing the uplink and downlink data exchanges between this terminal and the data packet networks connected to the core network.
  • the LTE / EPC architecture defined by the 3GPP consortium is now evolving.
  • the traffic patterns envisaged change in a very dynamic and often unpredictable way, so that new technical constraints are imposed on operators of telecommunications networks.
  • One of these constraints is to transfer, in a manner transparent to the user, active communication tunnels (i.e., in use for data transmissions) established with a first core device. network to a second equipment in case of failure of the first equipment, for example because the first equipment is overloaded, or for reasons of energy optimization or limiting the number of active network equipment.
  • FIG. 1 schematically represents the various network equipment on which the LTE / EPC architecture is based, in its current definition by the 3GPP consortium as described in particular in document 3GPP TS 23.401 entitled “Technical Specification”. Group Services and System aspects; General Packet Radio Service (GPRS) Enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Access ", Release 10, June 2010.
  • GPRS General Packet Radio Service
  • the planned exchanges between these devices for the transfer of data are modeled by solid lines
  • the signaling exchanges provided between these devices to support these data transfers are modeled by discontinuous lines.
  • the EPC core network 1 allows an UE 2 user terminal, associated with (in other words, served by) an eNB 3A base station of an access network such as a telecommunications network. access to services offered by an external PDN 4 data packet network.
  • the core network EPC 1 comprises four types of equipment, namely:
  • gateway P-GW for "PDN GateWay”
  • a terminal mobility management equipment 7 otherwise referred to as MME equipment (for "Mobility Management Entity"), in charge of ensuring the IP connectivity of the terminals when they are in a situation of mobility; and
  • a user database 8 otherwise called subscriber server of the HSS network, (for "Home Subscriber Server”).
  • the base stations 3A and 3B are connected directly to the MME equipment 7 and the data transfer gateway S-GW 5 via Sl-MME and Sl-U interfaces respectively.
  • the MME 7 manages the network connectivity of the terminal 2. It is responsible for its authentication (in order to allow access to the core network 1), and manages the establishment of communication sessions for this terminal and the intra-3GPP mobility.
  • Gateways S-GW 5 and P-GW 6 are responsible for data transfer within the core network 1, IP mobility and quality of service control in the data plane.
  • the MME equipment 7 is connected directly to the data transfer gateway S-
  • the LTE / EPC architecture proposed by the 3GPP consortium is based on the GPRS (GPRS Tunneling Protocol), which has two components:
  • the GTP-U protocol used for the transfer (exchange) of user data between two separate communication tunnels to manage the mobility situations of the user terminal on the interfaces S1 and S5;
  • the signaling exchanges on the interfaces SU and S5 are based on the GTP-C protocol.
  • the MME 7 uses the Sl-AP protocol on the Sl-MME interface to indicate the radio parameters and parameters of the GTP tunnels to the base stations 3A and 3B. These parameters are more generally referred to as "communication parameters" in the remainder of the description.
  • a GTP tunnel is identified at each node of the network by a Tunnel endpoint identifier or TEID (Tunnel Endpoint IDentifier), an IP address and a User Datagram Protocol (UDP) port number. . It is the "receiving" end of the GTP tunnel that locally allocates the value of the TEID, used by the transmitting end of the tunnel to transmit data or signaling in this tunnel to the receiving end.
  • the gateway P-GW 6 uses the value of identifier TEID allocated by the gateway S-GW 5 for the downstream traffic transmitted on the interface S5.
  • TEID ID values are exchanged between the tunnel ends using the GTP-C and Sl-AP protocols.
  • the failure of the data transfer gateway S-GW 5 (step E10) is detected by the MME equipment 7 or by the P-GW gateway 6.
  • the MME equipment 7 Upon detection of this failure (step E20), the MME equipment 7 initiates a procedure for clearing the SI interface for active sessions passing through the S-GW data transfer gateway 5 (step E30).
  • the MME equipment 7 allocates a new data transfer gateway (not shown in FIG. 1, referenced by "S-GW '" in FIG. 2) to the terminals concerned (ie to the terminals that are active or not associated with the gateway 5), and updates the S5 interface by sending the new S-GW data transfer gateway a "Create Session Request" message requesting a session creation. (step E40).
  • This message includes the P-GW gateway address 6 and the P-GW-TEID value allocated by the P-GW gateway 6 for uplink traffic on the S5 interface.
  • the data transfer gateway S-GW then allocates an S-GW'-TEID value for the downlink traffic associated with the terminal 2 on the interface S5. Then it notifies the P-GW gateway 6 of the data transfer gateway change by sending a "Modify Bearer Request" message (step E50).
  • the gateways S-GW 'and P-GW 6 then acknowledge the different messages (steps E60 and E70).
  • the MME equipment 7 then restores the radio channel and the SI channel of each impacted terminal (step E80).
  • the MME 7 expects to receive a terminal 2 service request message or a notification message of the presence of data destined for the terminal 2 from the new gateway of the terminal. S-GW 'data transfer.
  • this restore procedure is not transparent to the user of the terminal 2 since it terminates the current communication sessions and waits to restore these sessions, the terminal 2 initiates a new service request.
  • the user experience of the terminal 2 is degraded.
  • the restoration of a communication session generates significant signaling according to this procedure due to the establishment of new GTP tunnels between the various equipments of the backbone.
  • LTE / EPC networks typically at S-GW data transfer gateways, eNB base stations and P-GW gateways.
  • load balancing techniques between core network equipment, also known as load balancing techniques.
  • the MME selects for a communication session of a user terminal, an S-GW data transfer gateway and a P-GW interconnection gateway by based on weight factors (or WF for "Weight Factors") that are obtained from the Domain Name Server (DNS) of the core network.
  • WF Weight Factors
  • the weight that the DNS server associates with a gateway depends on its capacity relative to concurrent gateways serving the same region.
  • the MME device considers the capacity of a data transfer gateway before assigning it to a communication session of a user terminal, and implements a sort of "proactive" distribution of the load.
  • the MME equipment has no way of knowing the real-time load of this data transfer gateway, and anticipating or managing a possible overhead due for example to a sudden increase in traffic generated by users associated with the data transfer gateway. this data transfer gateway. Therefore, in overload situation, the MME equipment will continue to assign to the user terminals sending a service request to the same data transfer gateway.
  • the standard today does not specify any mechanism for transparently transferring ongoing communication sessions from one data transfer gateway to another.
  • transferring the data plan from one backbone equipment to another requires the restoration of GTP communication tunnels, resulting in session interruptions and significant signaling within the EPC backbone.
  • an SDN network architecture makes it possible to decouple the control and data planes by centralizing the intelligence of the network (that is to say the network control functions) at the level of a software control device .
  • the behavior of the network equipment such as switches or routers is defined by rules received from the control device, such as processing rules or data transfer (i.e. traffic).
  • the SDN concept relies notably on the OpenFlow communication protocol defined by the Open Networking Foundation (ONF), which allows simplified programming, via a standard interface, of peripheral devices of the network.
  • ONF Open Networking Foundation
  • J. Kempf et al. proposes to move the current functions of the MME equipment, as well as the control plane of the S-GW data transfer gateway and the P-GW interconnection gateway, into a control device executed by a virtual machine in an external data center also known as cloud computing or cloud in English.
  • the equipment in the EPC backbone data plan is replaced by OpenFlow switches, and the controller is responsible for establishing the data plan.
  • this proposal is based on the same interfaces between the control entities of the network as those defined by the 3GPP consortium described above, and in particular on the Sl-MME interface between the eNB base station and the MME equipment.
  • the invention offers a solution to this problem in particular by proposing a control device of an IP core network comprising:
  • a communication module able to communicate with a data transfer control entity of the IP core network, and configured to trigger the selection by the data transfer control entity of a data transfer gateway of the core of an IP network, the communication module being further configured to obtain from the data transfer control entity communication parameters for use in a communication session between a terminal connected to a base station of an access network, and an IP core network interconnection gateway connected to a data packet network, that communication session passing through the base station and the data transfer gateway;
  • a first control module of the base station by means of a first processing rule intended to be applied by this base station following the reception of data relating to the communication session, the first rule comprising parameters, among the communication parameters obtained from the data transfer control entity for use in the communication session for data transfer between the base station and the data transfer gateway;
  • the invention also aims at a control method intended to be implemented by a control device of an IP core network, and comprising:
  • a step of communicating with an IP core network data transfer control entity comprising triggering a selection by the data transfer control entity of a data transfer gateway of the IP core network , and obtaining from the communication parameter data transfer control entity for use in a communication session between a terminal, connected to a base station of an access network, and a an IP network core interconnection gateway connected to a data packet network, this communication session passing through the base station and the data transfer gateway;
  • communication session here is meant a session initiated by the terminal or the core network as part of a service offered by an external network of data packets managed by the core network.
  • This communication session is the support for a data exchange between the terminal and the external network via the core network.
  • Each communication session is associated with a quality of service that depends on the type of traffic exchanged during the session (eg File Transfer Protocol (FTP) session, Voice over IP session, etc.).
  • FTP File Transfer Protocol
  • Voice over IP session etc.
  • Data relating to a communication session here means data exchanged during this session uplink (from the terminal to the external network) or downlink (from the external network to the terminal).
  • the invention thus proposes to decouple the data and control planes in the IP core network, by applying the SDN principles of the software-defined network to the architecture of the IP core network.
  • a software control device for example, not only the data transfer gateways of the core network but also the base stations of the access networks at the heart of the network.
  • the stations access network base and the data transfer gateways are thus connected directly to the control device.
  • control performed by the control device is carried out using data processing rules, developed by the software control device and transmitted to the data transfer gateways and to the base stations for application when a communication session of a terminal.
  • processing rules are for example data transfer rules.
  • the communication parameters of the first rule comprise a data transfer gateway address and an endpoint identifier of a communication tunnel established between the data transfer gateway and the base station for the transfer of data. data, allocated by the data transfer control entity; and or
  • the communication parameters of the second rule include an address of the interconnection gateway and an endpoint identifier of a communication tunnel established between the data transfer gateway and the interconnection gateway for the transfer of data. data, allocated by the data transfer control entity.
  • the processing rules transmitted by the software control device can be easily updated directly at the equipment controlled by the control device.
  • the management of the core network, and in particular the procedures for establishing and maintaining communication sessions within the core network, are thus simplified.
  • the invention offers the possibility of easily implementing restoration procedures. in the event of an overload and / or failure of a core network equipment such as a data transfer gateway, without the need for excessive signaling, and transparent to the users of the terminals.
  • the result is flexibility in the management of the backbone and improved reliability of the IP connectivity offered to the terminals by the latter.
  • the user experience is thus privileged.
  • the invention applies in a privileged way to a core network architecture
  • LTE / EPC proposes to modify the communication protocols provided on the communication interfaces Sl-MME (between the base stations and the management entity of the mobility of the core network) and SU (between the entity of mobility management and S-GW data transfer gateways).
  • the invention proposes to modify the interfaces of the LTE / EPC architecture provided by the 3GPP consortium.
  • the new core network architecture defined by the invention thus makes it possible to review the restoration procedure in the event of failure of a network core equipment. currently offered by the 3GPP consortium, and to provide terminals with a more flexible and transparent IP connectivity process.
  • the communication module communicates with the data transfer control entity via a programming interface.
  • the first control module and the second control module are configured to communicate respectively with the base station and with the data transfer gateway via the OpenFlow protocol.
  • OpenFlow protocol facilitates the implementation of the invention.
  • this protocol offers the possibility to the control device to collect real-time load statistics from the data transfer gateways, and thus to consider a selection of the equipment involved in the communication session of a terminal based the current charge of these equipments. It is also possible to easily apply load balancing algorithms during this selection to improve the user experience.
  • control device further comprises a module for obtaining information representative of a current load of at least one data transfer gateway of the IP core network connected to the control device.
  • the communication module being further configured to provide this information to the data transfer control entity via a programming interface.
  • the communication module of the control device is further configured to trigger via a programming interface, on receipt of a request for attachment of the terminal to the heart of IP network, a terminal authentication by a mobility management entity belonging to the IP core network.
  • the authentication of the terminal is managed by an application running above the software control device and interacting with it via a programming interface or API.
  • control device further comprises a module for detecting a failure or an overload of the data transfer gateway, the communication module being further configured to inform the user of the data transfer gateway. the data transfer control entity of this failure or overload and to trigger the selection by the data transfer control entity of a new data transfer gateway for the communication session, and wherein:
  • the first control module is configured to update the first processing rule applied by the base station with communication parameters obtained from the data transfer control entity by the communication module of the control device and for use in the communication session for transferring data between the base station and the new data transfer gateway;
  • the second control module is configured to control the new data transfer gateway by means of a third processing rule intended to be applied by this new data transfer gateway following receipt of data relating to the session communication system, the third rule comprising communication parameters, obtained from the data transfer control entity by the communication module of the control device and intended to be used during the communication session for the transfer of data between the new data transfer gateway and the interconnecting gateway.
  • the first processing rule is updated with an address of the new data transfer gateway.
  • the communication parameters of the second processing rule and the third processing rule may include the same tunnel endpoint identifier allocated by the data transfer control entity and intended to be used between the data transfer gateway and the interconnection gateway, and between the new data transfer gateway and the interconnection gateway.
  • the tunnel endpoint identifier allocated by the data transfer control entity is invariant with respect to the data transfer gateway selected for the communication session.
  • the signaling necessary to manage a change of data transfer gateway is thus advantageously limited: only the address of the new selected data transfer gateway needs to be signaled by the control device to ensure the continuity of the communication session. .
  • the invention relies not only on a control device, but also on an IP network core data transfer control entity able to communicate with the control device.
  • software for example via a programming interface, in other words, executing above the software control device.
  • the invention also aims at a data transfer control entity of an IP core network comprising:
  • a communication module able to communicate with an IP network core control device according to the invention
  • a selection module triggered by the control device via the communication module, and configured to select a data transfer gateway of the IP core network
  • the communication module being configured to provide the control device with communication parameters, among the communication parameters obtained, intended to be used during the communication session for the transfer of data between the base station and the data transfer gateway. data.
  • the invention also provides a selection method intended to be implemented by a data transfer control entity of an IP core network, and comprising:
  • a selection step triggered by a control device of the IP core network, of a data transfer gateway of the IP core network;
  • control device of communication parameters, among the communication parameters obtained, intended to be used during the communication session for the transfer of data between the base station and the data transfer gateway.
  • the data transfer control entity and the selection method according to the invention have the same advantages as those mentioned above for the control device and the control method according to the invention.
  • the communication parameter obtaining module of the data transfer control entity is configured to allocate to the communication session an endpoint identifier of a communication tunnel between the data transfer gateway and the base station and an endpoint identifier of a communication tunnel between the data transfer gateway and the interconnection gateway.
  • the identifiers allocated by the entity to the communication session are invariant during the communication session, so as to simplify the signaling exchanged during the session especially in case of change of data transfer gateway during the session.
  • the data transfer control entity selection module is configured to select the data transfer gateway from among a plurality of data transfer gateways controlled by the control device using information. representative of a current load of these data transfer gateways provided by the control device via a programming interface.
  • the invention thus offers the possibility of implementing load distribution algorithms between the various equipments of the core network and in particular the data transfer gateways, so as to improve the users' experience in terms of IP connectivity. Thanks to this knowledge of the load of the data transfer gateways, it is possible to envisage in the event of overloading a gateway to transfer all or part of the sessions transiting through this data transfer gateway to another transfer gateway. data.
  • the selection module is configured to select a new data transfer gateway for the communication session of the terminal when it is informed by the control device, via a programming interface, of a failure or overload of the data transfer gateway;
  • the supply module and the communication module are configured to respectively provide the interconnection gateway and the control device this address of the new data transfer gateway.
  • the invention also provides an IP core network comprising:
  • a plurality of data transfer gateways are A plurality of data transfer gateways
  • a control device able to control at least one base station of an access network to which a terminal is connected and the plurality of data transfer gateways;
  • a data transfer control entity able to communicate with the control device, and to select a data transfer gateway from among the plurality of data transfer gateways controlled by the control device for a session communication terminal.
  • this IP core network further comprises a mobility management entity configured to authenticate the terminal, this authentication being triggered by the control device via a programming interface.
  • the invention also relates to a base station of an access network, able to serve a terminal during a communication session, and comprising: Means for receiving, from a control device of an IP core network according to the invention, a processing rule intended to be applied by this base station following the reception of data relating to this communication session of the terminal, the processing rule comprising communication parameters for use in this communication session for data transfer between the base station and a data transfer gateway of the IP core network; and
  • Means for applying this processing rule to data relating to the communication session Means for applying this processing rule to data relating to the communication session.
  • the IP core network and the base station according to the invention have the same advantages as those mentioned above for the control device and the data transfer control entity.
  • control method and / or the selection method are determined by computer program instructions.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a control device or more generally in a computer, this program comprising instructions adapted to the implementing the steps of a control method as described above.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a data transfer control entity or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a selection process as described above.
  • Each of these programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any form what other form is desirable.
  • the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question. It is also possible to envisage, in other embodiments, only the control method, the selection method, the control device, the data transfer control entity, the base station and the core network according to the invention. invention in combination all or some of the aforementioned features.
  • FIG. 1, already described, represents the architecture of an LTE / EPC core network as proposed by the 3GPP consortium;
  • FIG. 2 already described, illustrates a restoration procedure supported by the architecture of FIG. 1 and proposed by the 3GPP consortium in the event of a failure of a data transfer gateway;
  • FIGS. 3 and 4 illustrate the principles of a software-defined network (SDN);
  • FIG. 5 represents, in its environment, a core network, a control device, a data transfer control entity and a base station according to the invention in a particular embodiment
  • FIG. 6 schematically represents the hardware architecture of a computing device implementing the control device and the data transfer control entity illustrated in FIG. 6;
  • FIG. 7 represents the main steps of a procedure for attaching a terminal to the core network of FIG. 5, which can be implemented by the core network of FIG. 5, in accordance with the invention
  • FIG. 8 represents the main steps of a procedure for establishing a data plan that can be implemented by the core network of FIG. 5, in accordance with the invention.
  • FIG. 9 shows the main steps of a restoration procedure in case of failure of a data transfer gateway, which can be implemented by the core network of Figure 5, according to the invention.
  • the invention proposes to implement a software defined network SDN architecture within an IP core network, such as for example an LTE / EPC core network, so as to improve flexibility and reliability. in terms of IP connectivity of this core network.
  • IP core network such as for example an LTE / EPC core network
  • This new architecture makes it easy to implement transparent restoration procedures for users in the event of a failure of a core network and / or load balancing equipment in order to favor the user experience.
  • the invention defines a new control plane according to which a plurality of data transfer gateways of the core network and of the access network base stations (via which terminals can access the services offered by the core of the network. network) are controlled by a control device.
  • this control device is a software control device, connected via a programming interface (or API for Application Programming Interface) to an entity responsible for the selection of the equipment of the heart of network involved in communication sessions for data transfer (ie S-GW data transfer gateways and P-GW interconnection gateways)) and the establishment of communication tunnels, in particular in the data plan, between the equipment thus selected.
  • a programming interface or API for Application Programming Interface
  • the SDN concept allows you to specify the behavior of network devices using high-level control programs, which makes it easy to automate certain tasks such as configuring network equipment or managing policies applied to the network. network level.
  • the SDN architecture centralizes the intelligence of the network (i.e. the control functions of the network and its equipment) in a software control device (or controller).
  • the behavior of the network equipment such as switches or routers in the presence of data relating to a communication session is then defined by the control device by means of so-called processing rules that it transmits to the network equipment.
  • These rules are stored by the network devices and are intended to be applied by them on reception of data relating to a communication session. For example, they specify the network equipment to which the data (i.e., traffic) is transferred in uplink and downlink.
  • Figure 3 summarizes this mode of operation by schematically modeling an SDN architecture according to three layers:
  • a lower layer DP modeling the data plane and comprising the switches / routers R of the network controlled (controlled) by the control device (these switches / routers R can be indifferently physical or virtual);
  • An intermediate NW CTRL layer strictly modeling the software control device referenced by "OpenCTR”
  • An upper APPL layer modeling various APP applications or control functions used by the OpenCTR control device to control the switches / routers R of the DP data plane and to elaborate the processing rules.
  • the various layers mentioned above communicate with each other via programming interfaces or APIs called “NorthBound API” and “SouthBound API” (denoted respectively “NB API” and “SB API” in FIG. 3).
  • the OpenCTR control device also communicates with other controllers via programming interfaces called “East / West Bound API” (and denoted “E / WB API” in Figure 3).
  • the SB API programming interfaces between the OpenCTR control device and the data plane implement the OpenFlow communication protocol.
  • the programming interfaces NB API and E / WB API are based on any open communication protocol chosen, for example, from the known SOAP (for "Simple Object Access Protocol"), RPC (for "Remote Procedure Call”) protocols. or REST (for "Representational State Transfer”).
  • the OpenFlow protocol allows the OpenCTR software control device to easily control each switch / router R by means of a set of data processing rules, including in particular transfer rules (or routing) data intended to be applied by the router on receiving data relating to a communication session (in other words, exchanged during a communication session).
  • These processing rules are determined by the OpenCTR control device depending for example on the operator's policy envisaged for managing the network. They specify the processing to be applied by each switch on receiving a packet of a data stream associated with a communication session of a specific terminal, and subsequent packets associated with the same stream.
  • an entry E of such an FTAB flow table is represented in FIG. 4. It is in the form of several fields or parameters intended to be examined by the switch R on reception of a data packet for identify which processing to apply to this packet (eg which equipment in the backbone to transfer the data packet to). These fields include for example an MF field (for "Match Fields”) indicating the fields of the header of the packets concerned by this entry E of the table, as well as an INST field (for "Instructions”) defining the treatment to be applied. on packets whose header includes the fields identified by MF.
  • MF field for "Match Fields”
  • INST field for "Instructions"
  • the switch R uses the FTAB flow tables thus defined as follows. Upon receiving a data packet, it looks in the stored FTAB tables whether the MF field of an entry coincides with the fields of the header of that packet.
  • the instructions associated with this entry specified in the corresponding INST field are executed by the switch R on the data packet (eg forwarding the packet to a particular piece of equipment on the network, or modifying or deleting the packet).
  • the functions and operating modes of the equipment of the IP core network architecture presented are similar or identical to those described in 3GPP TS 23.401 published by 3GPP and are not detailed here.
  • the invention is not limited to LTE telecommunications networks alone and can also be applied to other architectures based on the IP protocol ("garlic IP networks"), such as for example a core architecture of proprietary network.
  • FIG. 5 represents an LTE / EPC network core 10 according to the invention, in a particular embodiment in which the core network 10 allows an UE terminal 11 to access services offered by one or more external network (s) of PDN 12 data packets.
  • the core network 10 allows an UE terminal 11 to access services offered by one or more external network (s) of PDN 12 data packets.
  • the PDN network 12 is connected to the core network 10 via an interconnection gateway 13, which can be a P-GW gateway as defined in the document 3GPP TS 23.401, allowing access to the core network 10 to the PDN 12 network and vice versa.
  • an interconnection gateway 13 can be a P-GW gateway as defined in the document 3GPP TS 23.401, allowing access to the core network 10 to the PDN 12 network and vice versa.
  • the UE terminal 11 is connected to a base station 14 (typically an eNodeB) of an access network, such as for example a UMTS mobile telecommunications network. No limitation, however, is attached to the nature of the access network used by the UE terminal 11 as long as it is compatible with the core network 10.
  • the control functions of a plurality of data transfer gateways 15 of the core network 10 which can typically be S-GW gateways as defined in the document 3GPP TS 23.401), which make it possible to connecting the base stations 14 to the interconnection gateway 13 and thus to the core network 10 are separated from the data transfer functions intended to be applied by these data transfer gateways (in other words, the data plane).
  • This separation of the control plane (signaling) and the data plane is ensured by the introduction of a software control device 16 in the core network 10, taking over the functions of the OpenCTR control device described above.
  • the software control device 16 thus centralizes the network intelligence of the data transfer gateways and determines the processing rules to be applied to the data packets received by them. It ensures the establishment and maintenance of terminal communication sessions of users accessing the core network 10.
  • SGW-C entity gathering the control functions of the data transfer gateways
  • SGW-D entity applying the processing or transfer functions in the data plane of these data transfer gateways
  • Controlled via the software controller 16 are able to encapsulate and de-encapsulate packets exchanged over a communication tunnel established in accordance with the GTP-U protocol as defined by the 3GPP consortium, and belong to the same predetermined region.
  • the software control device 16 centralizes, via the software entity SGW-C 17, the control functions of three data transfer gateways SGW-D 15A, 15B and 15C.
  • this number may vary, in particular as a function of operational constraints and / or sizing of the equipment of the core network.
  • the software entity SGW-C 17 is a data transfer control entity according to the invention, which is more precisely here in the form of an application running above the software control device 16 and communicating with it via a programming interface or PLC API17.
  • the core network 10 comprises a mobility management entity 18 which is in software form, in particular under the form of an application running above the software control device 16 and communicating with it via a programming interface API18 denoted.
  • API17 and API18 programming interfaces fulfill the role of "NorthBound" programming interfaces.
  • the mobility management entity 18 is responsible for authenticating the terminals seeking access to the core network (ie to verify that these terminals are authorized to access the backbone 10 and / or the services offered by the network). PDN network 12), according to authentication and authorization techniques known to those skilled in the art.
  • the mobility management entity 18 is also responsible for managing the mobility of the terminals within the same network. This entity 18 may in particular be MME equipment as described in 3GPP document TS 23.401.
  • the mobility management entity 18 is no longer responsible for selecting, for a communication session associated with a terminal, the SGW data transfer gateway and the P-GW gateway involved in this session in the data exchange between the terminal and the PDN network 12.
  • This function is indeed provided, in accordance with the invention, by the SGW-C 17 data transfer control entity of the core network 10, as described in more detail later.
  • control device
  • SGW-C entities 17 and 18 are software entities, ie applications or computer programs that run on the same computer device or computer 19. Alternatively, these applications can run on a single computer device or computer. distinct computing devices communicating with each other in a manner known to those skilled in the art.
  • FIG. 6 schematically illustrates the hardware architecture of such a computing device 19.
  • This device comprises a processor 20, a read-only memory 21, a random access memory 22, a non-volatile memory 23 and communication means 24, able in particular to communicating with the data transfer gateways SGW-D 15, the interconnection gateway 13 and the base stations 14 according to communication protocols specified later.
  • the read-only memory 21 of the computing device 19 constitutes a recording medium in accordance with the invention, readable by the processor 20 and on which is recorded a computer program according to the invention comprising instructions for the execution of the steps of FIG. a control method according to the invention, and a computer program according to the invention comprising instructions for executing a selection method according to the invention, the steps of which are illustrated later with reference to FIGS. to 9.
  • the aforementioned computer programs define the software control device 16 and the SGW-C software entities 17 and 18 (as well as the functional modules implemented by these entities), so that in the description the references 16, 17 and 18 may designate both the corresponding functional entities and the associated computer device 19 for executing these entities.
  • control device 16 controls the behavior of the base stations 14 (two base stations 14A and 14B being represented in FIG. 5, in a nonlimiting manner) by via a control module 16A (first control module within the meaning of the invention) implementing the OpenFlow communication protocol.
  • the base stations 14A and 14B constitute base stations whose radio functions may be the same as those of the eNodeB base stations specified in 3GPP TS 23.401. However, according to the invention, and unlike the eNodeB base stations specified in 3GPP TS 23.401, they are controlled by the control device 16 via the module 16A with respect to the transfer of data to the data carriers. SGW-D 15 data transfer gateways, by means of processing rules defined by it and stored in FTAB14 flow tables stored by the base stations 14.
  • the FTAB14 tables are similar or identical to the FTAB tables previously described in FIG. reference to Figure 4.
  • These processing rules identify here the SGW-D data transfer gateway 15 to which the data packets received from an uplink terminal by a base station 14 are transferred during a communication session. They include in particular the communication parameters intended to be used during this transfer, that is to say typically the parameters identifying the GTP-U communication tunnel intended to be established or established.
  • the control device 16 furthermore controls the behavior of the SGW-D data transfer gateways (ie active data transfer gateways in the data plane) via a control module 16B also implementing the protocol. OpenFlow communication.
  • This control module 16B constitutes a second control module within the meaning of the invention. It is configured to transmit to the SGW-D data transfer gateways 15 processing rules (second and third processing rules within the meaning of the invention) defined by the control device 16 and intended to be applied by the transfer gateways. of data SGW-D 15 on receipt of data relating to a communication session of a terminal of a user (in particular here of the terminal 11).
  • processing rules are stored at the level of the SGW-D data transfer gateways in FTAB15 flow tables, which are similar or identical to the FTAB tables described above with reference to FIG. 4. They identify for example here:
  • the interconnection gateway 13 (for example via an IP address) to which the data packets received by the uplink data transfer gateways SGW-D 15 are transferred during an associated communication session to this terminal, and the communication parameters intended to be used during this transfer;
  • the base station 14A (for example via its IP address) to which the data packets received by the downlink data transfer gateways SGW-D 15 are transferred during a communication session associated with this terminal, and the communication parameters intended to be used during this transfer
  • the communication parameters stored in the FTAB15 flow tables typically include the parameters identifying the GTP-U communication tunnels intended to be established or established in uplink and downlink between the relevant SGW-D data transfer gateway, and the interconnection gateway and the base station identified in the table.
  • the SGW-D base stations 14 and data transfer gateways 15 implement, for communicating with one another in the data plane, an interface based on the establishment of tunnels.
  • GTP-U compliant uplink and downlink communications that may be similar or identical to the Sl-U interface specified in 3GPP TS 23.401.
  • the SGW-D data transfer gateways 15 and the interconnection gateway 13 implement, for communicating with each other in the data plane, an interface based on the establishment of uplink and downlink communication tunnels.
  • GTP-U compliant which may be similar or identical to the S5-U interface specified in 3GPP TS 23.401.
  • the control device 16 is, as mentioned above, in charge of establishing the communication sessions for the user terminals, and in particular for the UE terminal 11. For this purpose, it interacts with the SGW-C 17 entity and the MME 18 entity via the programming interfaces API17 and API18 respectively.
  • the entity SGW-C 17 has the function of establishing the GTP communication tunnels supporting the downlink and uplink data exchanges transiting through the various equipment of the core network 10 during the communication sessions. terminals, and in particular between the base stations 14 and the SGW-D 15 data transfer gateways, and between the SGW-D 15 data transfer gateways and the interconnection gateway 13.
  • These communication tunnels are, as previously recalled, defined (ie identified) by different communication parameters such as TEID tunnel endpoint identifiers, as well as an IP address and a User Datagram Protocol (UDP) port number. of these points.
  • SGW-D data transfer gateways i.e. for uplinked communication tunnels between the base stations 14 and the data transfer gateways.
  • SGW-D 15 data managed by the control device 16, and for communication tunnels established downlink between the interconnecting gateway 13 and data transfer gateways SGW-D 15), it is the entity SGW -C 17 which is configured to allocate to each GTP tunnel a unique TEID identifier value. By unique, we mean that this value is invariant throughout the communication session of the terminal.
  • the SGW-C 17 allocates a single value of TEID for the uplink traffic exchanged during a communication session between a base station 14 and a SGW-D gateway 15 on the Sl-U interface. , and a single TEID value for the downlink traffic exchanged during a communication session between the P-GW gateway 13 and a SGW-D gateway 15 on the S5-U interface.
  • this TEID identifier value does not change (ie it is invariant) if the communication session is transferred from a SGW-D data transfer gateway to a other, for example due to a failure or overload of the data transfer gateway initially considered for the session.
  • SGW-C 17 which has the function of selecting, for each communication session of a user terminal and on request of the control device 16 via the interface of programming API17, the data transfer gateway among the SGW-D data transfer gateways 15 and the interconnection gateway 13 which are used for the transfer of data between the user terminal and the external PDN networks 12.
  • the SGW-C entity 17 is configured to make this selection taking into account the current state of the load of the SGW-D data transfer gateways 15. For this purpose, it uses information representative of the current load of the S-GW-15 data transfer gateways provided by the control device 16. This information is obtained by the control device 16 from load statistics. periodicals established using the OpenFlow protocol implemented between the control device 16 and the SGW-D 15 data transfer gateways.
  • the control device 16 can then easily exploit the load statistics thus obtained by comparing them with the capabilities of the SGW-D data transfer gateways and with the quality of service required for the communication session (represented for example in the form of quantities or predetermined thresholds), so as to evaluate the current state of the load of these data transfer gateways and implement with the entity SGW-C 17 powerful load balancing algorithms between the different transfer gateways Such load balancing algorithms are known to those skilled in the art and not detailed here.
  • the invention does not require significant signaling to enable the transfer of a communication session between two SGW-D data transfer gateways of the core network 10.
  • a procedure for attaching the terminal 11 to the core network 10 A procedure for establishing an uplink and downlink data plan between a base station used by the terminal to communicate with the core network and an interconnection gateway connected to the external networks PDN 12, and
  • the attachment procedure illustrated in FIG. 7 allows the UE terminal 11 to register with the core network 10, for example following the power-up of the terminal 11.
  • the terminal 11 sends an attachment request "ATTACH REQUEST" to the base station 14A (step F10).
  • the base station 14A translates this request into an OpenFlow message "PACKET-IN” and transfers it to the control device 16 (step F20).
  • the control device 16 transfers the received OpenFlow message to the mobility management entity 18, via the programming interface API18, to trigger an authentication of the terminal 11 (in order to verify that the terminal 11 is authorized to access the services managed by the core network 10 and offered by PDN networks 12).
  • This authentication is performed by the mobility management entity 18 by interrogating the HSS server of the core network 10 in a manner known per se. It relies on the implementation of an exchange with the terminal 11 via the control device 16 (step F30).
  • OpenFlow protocol in its current definition, does not provide messages to manage the authentication of a terminal and must therefore be adapted to cover this authentication. Such an adaptation presents no difficulty for the skilled person and is therefore not described further here.
  • control device 16 triggers the selection by the SGW-C 17 entity:
  • a data transfer gateway SGW-D among the data transfer gateways controlled by the control device 16 (in other words here, among the data transfer gateways 15A, 15B and 15C);
  • An interconnection gateway to the PDN network (here, the interconnection gateway 13);
  • step F40 For the transfer of data exchanged during the communication session of the terminal 11 (step F40).
  • the selection of the SGW-D gateway is performed by the SGW-C 17 entity via a software selection module, from representative information a current load of each of the SGW-D gateways 15 of the core network 10 controlled by the control device 16.
  • This load information is communicated by the control device 16 to the SGW-C 17 entity via the programming interface API17, and derivative of statistical load information collected by the control device 16, via a module for obtaining statistical information, from the data transfer gateways SGW-D 15 via the OpenFlow protocol, as mentioned before.
  • SGW-D data transfer gateway 15A is selected by the SGW-C 17.
  • the SGW-C entity 17 allocates at this point a tunnel endpoint TEID identifier VI value, for a communication session of the terminal 11, for the downlink traffic on the interface between the gateway of the tunnel. interconnection 13 and the data transfer gateway SGW-D 15A.
  • This value VI makes it possible to identify the termination of this tunnel at this data transfer gateway SGW-D 15A.
  • the SGW-C entity 17 also allocates a tunnel endpoint TEID identifier V4 value, for a communication session of the terminal 11, for the uplink traffic on the interface between the base station 14A and the SGW-D 15A data transfer gateway.
  • This value V4 makes it possible to identify the termination of this tunnel at this data transfer gateway SGW-D 15A.
  • the entity SGW-C 17 creates a new entry in a flow table FTAB17 associated with the terminal 11 and stored for example in a non-volatile memory (eg in the memory 23 of the computing device 19).
  • the FTAB17 table is similar or identical to the FTAB tables described above with reference to FIG. 4.
  • This new entry includes the IP address of the data transfer gateway S-GW 15A selected by the entity SGW-C 17, as well as the value VI of TEID (communication parameters within the meaning of the invention intended to be used during the session between the interconnection gateway 13 and the data transfer gateway SGW-D 15A in the data plane).
  • the SGW-C entity 17 then provides these communication parameters to the interconnection gateway 13 by sending a session creation request ("Create Session Request" message) including the IP address of the SGW data transfer gateway. -D 15A and the value VI (step F50).
  • the interconnection gateway 13 On receipt of this request, the interconnection gateway 13 in turn creates a new entry in a flow table maintained in memory for this terminal 11 and this communication session, containing the communication parameters transmitted by the SGW-C entity. 17.
  • the access gateway 13 then allocates a value V2 of identifier TEID, this value V2 allowing the identification of the tunnel termination at the level of the access gateway 13 for the traffic in the upstream direction, in the data plane. on the interface between this access gateway 13 and the data transfer gateway SGW-D 15A (step F55). Then it sends a response message to the entity SGW-C 17 ("Creation Session Response" message), including an IP address allocated to the terminal 11, and this value V2 TEID identifier (step F60).
  • the entity SGW-C 17 updates its flow table associated with the terminal 11 with the communication parameters obtained from the gateway P-GW 13 (IP address of the terminal 11 and value V2) (step F70 ).
  • the entity SGW-C 17 then notifies the control device 16, via the programming interface API17, the IP address and quality of service allocated to the terminal 11.
  • the control device 16 informs the mobility management equipment 18 of the IP address allocated to the terminal 11 via the programming interface API18.
  • This IP address allocated to the terminal constitutes a communication parameter within the meaning of the invention intended to be used during a communication session between the base station 14A, the SGW-D 15A data transfer gateway and the gateway. interconnection 13 for data transfer.
  • the mobility management equipment 18 includes this IP address in an "Attach Response Message" response message and sends it to the terminal 11 via the control device 16 (ie via the API18 programming interface) and the base station. 14 (step F80).
  • the terminal 11 After having successfully concluded this attachment procedure, the terminal 11 is authorized to access the core network LTE / EPC 10 by using for this purpose the IP address allocated by the core network 10.
  • the establishment of such a data plan may result from a communication session initiated either by the terminal 11 or by the network (ie core network 10 following a message received from a PDN network 12).
  • the terminal 11 sends an "initial" data packet to the base station 14A.
  • the base station 14A Upon receipt of this packet, the base station 14A checks the flow tables associated with the terminal 11 stored in its memory (step G10).
  • the base station 14A sends an OpenFlow message "PACKET-IN" to the control device 16.
  • This message includes the header of the initial packet and a TEID identifier V3 value, allocated by the base station 14A for the downstream traffic destined for the terminal 11 in the data plane on the interface between the base station 14A and the SGW-D 15A gateway previously selected for this terminal 11 (step G20).
  • this value v3 identifies the tunnel termination at the base station 14A for the downstream traffic, in the data plane, on the interface between this base station 14A and the SGW-D data transfer gateway 15A.
  • the control device 16 checks the header of the packet to identify the source address at the origin of this packet and the corresponding type of session (eg FTP transfer, voice over IP, etc.) (step G30).
  • the corresponding type of session eg FTP transfer, voice over IP, etc.
  • the control device 16 From the source IP address of the packet (ie here the IP address of the terminal 11 allocated during the attachment procedure previously described), the control device 16 interrogates the SGW-C 17 entity to obtain the address IP of the SGW-D 15A gateway previously selected for the terminal 11, stored in the FTAB17 table. The control device 16 also retrieves from the entity SGW-C 17 the values V1, V2 and V4 previously allocated during the attachment of the terminal 11.
  • the identification of the type of session associated with the packet enables the control device 16 to ensure that the SGW-D 15A gateway selected during the attachment procedure makes it possible to offer the terminal 11 the quality of service required for this session. . If, for example, the packet corresponds to a voice-over-IP session and the control device 16 detects that the selected data transfer gateway 15A is overloaded, it may decide to trigger the selection of a new data transfer gateway. SGW-D by SGW-C 17 as previously described.
  • the control device 16 then creates an OpenFlow message "PACKET-OUT" and sends it to the base station 14A (step G40).
  • This message contains a processing rule of the data packet received by the station 14A (first rule within the meaning of the invention), indicating the processing intended to be applied by this station on this packet (and on the following packets associated with the same stream ).
  • This processing rule is here a transfer rule which tells the base station 14A to which data transfer gateway to transfer this packet, ie which commands the base station 14A so that it transfers the received data packet. to the SGW-D 15A data transfer gateway.
  • the processing rule transmitted by the control device 16 comprises the communication parameters obtained from the SGW-C entity 17 by the control device 16, and intended to be used during the uplink communication session. between the base station 14A and the data transfer gateway SGW-D 15A. These communication parameters comprise the IP address of the data transfer gateway 15A, and the value V4 of the identifier TEID associated with the communication tunnel on the interface intended to be established between the base station 14A and the SGW gateway. D 15A for uplink data exchange. The base station 14A then has values V3 and V4 identifying the ends of the communication tunnel intended to be established on the interface between the SGW-D 15A and the base station 14A. Similarly, the control device 16 creates an OpenFlow message "PACKET-OUT" and sends it to the SGW-D gateway 15A (step G50).
  • This message contains a processing rule of the initial packet (received by the base station 14A and intended to be transferred to the SGW-D gateway 15A according to the first processing rule) indicating the processing to be applied by the gateway of transfer of the 15A data on this packet (and on subsequent packets associated with the same stream).
  • This processing rule (second rule within the meaning of the invention) is here a transfer rule which indicates to the SGW-D 15A to which interconnection gateway to transfer this packet, that is, which controls the data transfer gateway 15A so that it transfers the initial data packet to the interconnection gateway 13.
  • the processing rule transmitted by the control device 16 to the SGW-D 15A gateway comprises the communication parameters obtained from the SGW-C 17 entity by the control device 16, and intended to be used in connection rising during the communication session between the SGW-D gateway 15A and the interconnection gateway 13.
  • These parameters include the IP address of the interconnection gateway 13, and the TEID identifier values VI and V2 allocated to the ends the tunnel intended to be established on the interface between the SGW-D 15A and the interconnection gateway 13.
  • the OpenFlow message "PACKET-OUT" also contains a processing rule intended to be applied by the downstream SGW-D 15A data transfer gateway on the traffic destined for the terminal associated with the terminal. communication session.
  • This processing rule is here a transfer rule which indicates to the data transfer gateway 15A to which base base station to forward the packets relating to the communication session and intended for the terminal 11.
  • this processing rule commands the gateway SGW-D 15A so that it transfers the received data packets to the base station 14A.
  • this processing rule comprises the communication parameters obtained by the control device 16 and intended to be used downlink between the SGW-D 15A and the base station 14A during the communication session, namely the IP address of the base station 14A and the TEID identifier TEID identifier values V3 and V4 allocated to the ends of the tunnel intended to be established on the interface between the SGW-D 15A and the 14A base station .
  • a first communication tunnel is established in uplink and downlink for the interface (for example of the Sl-U type) between the base station 14A and the transfer gateway.
  • data SGW-D 15A the values V3, V4 of TEID identifier being inserted in the GTP packets transmitted in this first tunnel.
  • a second communication tunnel is established in uplink and downlink for the interface (for example of the S5-U type) between the data transfer gateway.
  • SGW-D data 15A and the interconnection gateway 13 step G60), the values V1, V2 TEID identifier being inserted into the GTP packets transmitted in this second tunnel.
  • the interconnection gateway 13 determines that this packet must be sent to the transfer gateway 11.
  • SGW-D 15A data (to the IP address specified in the table).
  • the data transfer gateway SGW-D 15A consults the FTAB15 flow tables stored in its volatile memory to identify whether an entry coincides with the header of the packet received for the terminal 11.
  • the SGW-D data transfer gateway 15A sends an OpenFlow PACKET-IN message to the control device 16.
  • the control device 16 determines the location of the terminal 11 by interrogating the mobility management entity 18 via the programming interface API18, and identifies a base station 14 suitable for transmitting the packet intended for the terminal 11. In this case here, it is assumed that it is the base station 14A that is identified.
  • the control device 16 sends the base station 14A an OpenFlow message
  • PACKET-OUT comprising a processing rule (first treatment rule within the meaning of the invention) intended to be applied by it on reception of data packets from the terminal
  • This processing rule includes the IP address of the data transfer gateway SGW-D 15A as well as the value V4 of the identifier TEID allocated by the entity SGW-C 17 to the gateway SGW-D 15A for the upstream traffic.
  • this terminal 11 in the data plane on the interface between this base station 14A and the data transfer gateway SGW-D 15A.
  • the base station 14A establishes the radio channel with the terminal 11, and responds to the control device 16 by sending it an OpenFlow message containing the value V3 of the identifier TEID allocated by the base station 14A for the downstream traffic intended for the terminal 11 in the data plane, still on the interface between this base station 14A and the data transfer gateway SGW-D 15A.
  • the OpenFlow protocol in its current version does not include a message allowing the base station 14A to send the value V3 to the control device 16 and must be adapted appropriately. This adaptation presents no difficulty for the skilled person.
  • the control device 16 Upon receipt of this message, the control device 16 sends a processing rule (second treatment rule in the sense of the invention) to the data transfer gateway SGW-D 15A containing the IP address of the base station 14A. and the values V3 and V4 of TEID.
  • These parameters are communication parameters intended to be used for transferring downlink traffic between the SGW-D 15A and the base station 14A during the communication session.
  • step G60 we are here at the end of the procedure for establishing a data plan (step G60) described above with reference to FIG. 8.
  • This data plan thus relies on two bidirectional tunnels.
  • GTP-U respectively established between the base station 14A and the data transfer gateway SGW-D 15A, and between the SGW-D 15A data transfer gateway and the interconnection gateway 13 for the current communication session of the terminal 11.
  • the control device 16 has a software module able to detect, using the OpenFlow protocol, a failure of one of the data transfer gateways SGW-D 15 that it controls. Specifically, according to this protocol, the control device 16 and the SGW-D data transfer gateways periodically exchange "Echo Request / Reply" type messages. Detecting the absence of response from the SGW-D data transfer gateway 15A to such a message allows the control device 16 to identify that a problem is affecting that gateway (step H20).
  • control device 16 triggers, via the programming interface API17, the selection by the entity SGW-C 17 of a new data transfer gateway for the communication session of the terminal 11 (and for each communication session more generally impacted by this failure), as previously described for the SGW-D 15A gateway taking into account the current load of data transfer gateways SGW-D 15. It is assumed by example that the gateway SGW-D 15B is so selected.
  • the entity SGW-C 17 sends a message "Modify Bearer Request" to the interconnection gateway 13 to inform it of this new selection (via an interface "E / W Bound” as described with reference to FIG. 3) (step H30).
  • This message includes the IP address of the new SGW-D 15B data transfer gateway.
  • the TEID identifier VI value of the GTP-U tunnel for the downlink remains invariant despite the change of data transfer gateway for each communication session.
  • the interconnection gateway 13 updates the FTAB13 table associated with the terminal 11 and the communication session with the SGW-D 15B IP address and sends a "Modify Bearer Response" message to the SGW-C entity. 17 (step H40).
  • the control device 16 then sends, via its control module 16A, an OpenFlow message "MODIFY-STATE" to the base station 14A to update the address of the associated SGW-D data transfer gateway. at the communication session of the terminal 11 in the FTAB14 table.
  • This message is an update by the module 16A of the control device 16 of the processing rule applied by the base station 14A and contains new communication parameters (in this case, the IP address of the transfer gateway data base SGW-D 15B) obtained from the SGW-C 17 and intended to be used between the base station 14A and the data transfer gateway SGW-D 15B during the communication session.
  • the tunnel identifier value TEID V4 intended to be by the base station 14A for the uplink on the interface with the new SGW-D 15B data transfer gateway remains unchanged. Moreover, the base station 14A does not change, the value V3 remains unchanged.
  • the invention by centralizing at the level of the entity SGW-C 17 the allocation of the TEID identifiers for the communication tunnels of the data plane established with the data transfer gateways SGW-D 15, makes it possible to to free from the allocation of new TEID identifiers when the active data transfer gateway changes and from the communication of these new identifiers to the network equipments brought to establish a tunnel with this data transfer gateway.
  • the signaling required to notify the change of data transfer gateway is thus advantageously limited: only the IP address of the new data transfer gateway needs to be notified by the control device 16.
  • the control device 16 then sends, via its control module 16B, an OpenFlow message "PACKET-OUT" to the new data transfer gateway SGW-D 15B, containing a processing rule (third processing rule within the meaning of the invention) intended to be applied by the data transfer gateway SGW-D 15B uplink on receiving data relating to the communication session of the terminal 11 (step H60).
  • a processing rule third processing rule within the meaning of the invention
  • This processing rule is here a transfer rule which indicates to the data transfer gateway SGW-D 15B to which interconnection gateway to transfer the packets relating to the communication session and received from the terminal 11.
  • this rule of transfer processing controls the data transfer gateway SGW-D 15B so that the latter transfers the received data packets to the interconnection gateway 13.
  • This processing rule includes communication parameters obtained from the SGW-C entity 17 for use in uplink between the SGW-D data transfer gateway 15B and the interconnection gateway 13 during the communication session. These communication parameters include in particular the IP address of the interconnection gateway 13, and the value V2 of TEID allocated by the interconnection gateway 13 to the session of the terminal 11. They are stored in an FTAB15 flow table stored by the data transfer gateway SGW-D 15B in association with the communication session of the terminal 11.
  • the "PACKET-OUT" message further comprises another processing rule intended to be applied by the downstream SGW-D 15B data transfer gateway on the traffic destined for the terminal 11 associated with the communication session.
  • This processing rule is here a transfer rule which indicates to the data transfer gateway SGW-D 15B to which base station to transfer the packets relating to the communication session and intended for the terminal 11.
  • this command processing rule the data transfer gateway SGW-D 15B so that it transfers the received data packets to the base station 14A.
  • this processing rule comprises the communication parameters obtained by the control device 16 and intended to be used in a downlink between the data transfer gateway SGW-D 15B and the base station 14A during the session. communication, namely the IP address of the base station 14A and the value V3 of the TEID identifier.
  • a GTP-U communication tunnel is established in uplink and downlink for the interface (typically of the Sl-U type) between the base station 14A and the new SGW data transfer gateway. 15B, and a GTP-U communication tunnel is established in uplink and downlink for the interface (typically of the S5-U type) between this new SGW-D 15B data transfer gateway and the interconnection gateway 13 (FIG. step H70).
  • this procedure can be easily applied to also handle an overload situation of the SGW-D 15A data transfer gateway.
  • Such a situation can be detected by the control device 16 from the load statistics that it collects in real time using the OpenFlow protocol from the SGW-D data transfer gateways 15 it manages.
  • control device 16 can trigger a change in the SGW-D data transfer gateway according to the procedure described with reference to FIG. 9, in order to balance the load resulting from the data transmission sessions.
  • load distribution or load balancing algorithms known per se can be used by the device.
  • the transfer of a data transfer gateway to another of the communication session is then implemented in a manner similar to that described with reference to FIG. 9, in other words transparently for the IP connectivity of the user.

Landscapes

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

Abstract

Le dispositif de contrôle (16) comprend : ¾ un module de communication avec une entité de contrôle de transfert de données (17) pour déclencher la sélection par cette entité d'une passerelle de transfert de données (15A) et obtenir de celle-ci des paramètres de communication à utiliser lors d'une session de communication entre un terminal (11) connecté à une station de base (14A) et une passerelle d'interconnexion (13) connecté à un réseau PDN (12); ¾ un module de contrôle (16A) de la station de base via une règle de traitement à appliquer à des données relatives à la session et comprenant des paramètres de communication à utiliser lors de la session entre la station de base et la passerelle de transfert; et ¾ un module de contrôle (16B) de la passerelle de transfert via une règle de traitement à à des données relatives à la session et comprenant des paramètres de communication à utiliser lors de la session entre la passerelle de transfert et la passerelle d'interconnexion.

Description

Dispositif et procédé de contrôle d'un cœur de réseau IP
Arrière-plan de rinvention
L'invention se rapporte au domaine général des télécommunications. Elle concerne plus particulièrement une architecture de cœur de réseau IP (Internet Protocol). L'invention s'applique ainsi de façon privilégiée mais non limitative aux réseaux de communication conformes à la norme LTE (Long Term Evolution) définie par le consortium de standardisation 3GPP (Third Génération Partnership Project), et plus spécifiquement à l'architecture d'un cœur de réseau LTE/EPC (Evolved Packet Core).
Une augmentation exponentielle du trafic des télécommunications mobiles est attendue dans les prochaines années, dynamisée par l'apparition de nouvelles applications, de nouveaux terminaux et de débits de communication de plus en plus élevés.
Dans ce contexte, l'architecture LTE/EPC a été définie par le consortium 3GPP pour fournir une connectivité IP transparente entre un terminal d'un utilisateur, autrement désigné par équipement utilisateur (ou UE pour « User Equipment »), et des réseaux de paquets de données (ou PDNs pour « Packet Data Networks ») aptes à offrir à ce terminal divers services de communication, tels que des services de voix sur IP ou VoIP (Voice over IP), de téléchargements de données, de vidéos à la demande, etc.
Cette architecture repose sur :
— un réseau d'accès (ou E-UTRAN pour « Evolved-Universal Terrestrial Radio Access Network ») auquel est connecté le terminal de l'utilisateur via une station de base désignée par « eNodeB » (eNB) ; et
— un cœur de réseau IP (ou EPC) gérant les échanges de données, en liaisons montante et descendante, entre ce terminal et les réseaux de paquets de données reliés au cœur de réseau.
L'architecture LTE/EPC définie par le consortium 3GPP est aujourd'hui en pleine évolution. Les modèles de trafic envisagés changent en effet de manière très dynamique et souvent imprédictible, de sorte que de nouvelles contraintes techniques s'imposent aux opérateurs des réseaux de télécommunications.
L'une de ces contraintes consiste à transférer, de manière transparente pour l'utilisateur, des tunnels de communication actifs (c'est-à-dire, en cours d'utilisation pour des transmissions de données) établis avec un premier équipement du cœur de réseau vers un second équipement en cas de défaillance du premier équipement, par exemple parce que ce premier équipement est en situation de surcharge, ou pour des raisons d'optimisation d'énergie ou encore de limitation du nombre d'équipements actifs du réseau.
Dans l'architecture LTE/EPC actuelle, une défaillance d'un équipement du cœur de réseau est très contraignante pour l'opérateur gérant ce cœur de réseau car elle est susceptible d'entraîner une interruption du service offert par cet opérateur. Pour mieux illustrer ce propos, la figure 1 représente schématiquement les différents équipements de réseau sur lesquels s'appuie l'architecture LTE/EPC, dans sa définition actuelle par le consortium 3GPP telle que décrite notamment dans le document 3GPP TS 23.401 intitulé « Technical Spécification Group Services and System aspects ; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Access », Release 10, juin 2010. A titre indicatif, les échanges prévus entre ces équipements pour le transfert des données (i.e. dans le plan de données ou plan utilisateur) sont modélisés par des traits pleins, tandis que les échanges de signalisation prévus entre ces équipements pour supporter ces transferts de données (i.e. dans le plan de contrôle ou de signalisation) sont modélisés par des traits discontinus.
Plus précisément sur la figure 1, le cœur de réseau EPC 1 permet à un terminal utilisateur UE 2, associé à (autrement dit, servi par) une station de base eNB 3A d'un réseau d'accès tel qu'un réseau de télécommunications mobiles, d'accéder à des services offerts par un réseau de paquets de données externe PDN 4. A cet effet, le cœur de réseau EPC 1 comprend quatre types d'équipements, à savoir :
— une passerelle de transfert de données 5, autrement appelée passerelle S-GW (pour « Serving GateWay »), située entre le réseau d'accès et le cœur de réseau 1 ;
— une passerelle d'interconnexion 6, autrement appelée passerelle P-GW (pour « PDN GateWay »), permettant de connecter le cœur de réseau 1 au réseau externe 4 de paquets de données ;
— un équipement 7 de gestion de mobilité des terminaux, autrement désigné par équipement MME (pour « Mobility Management Entity ») , en charge d'assurer la connectivité IP des terminaux lorsque ceux-ci sont en situation de mobilité ; et
— une base de données utilisateurs 8, autrement appelée serveur d'abonnés du réseau HSS, (pour « Home Subscriber Server »).
Les stations de base 3A et 3B sont connectées directement à l'équipement MME 7 et à la passerelle de transfert de données S-GW 5 par l'intermédiaire d'interfaces Sl-MME et Sl-U respectivement.
L'équipement MME 7 gère la connectivité réseau du terminal 2. Elle est responsable de son authentification (en vue de l'autoriser à accéder au cœur de réseau 1), et gère l'établissement de sessions de communication pour ce terminal ainsi que la mobilité intra-3GPP.
Les passerelles S-GW 5 et P-GW 6 sont responsables du transfert des données au sein du cœur de réseau 1, de la mobilité IP et du contrôle de la qualité de service dans le plan de données.
L'équipement MME 7 est relié directement à la passerelle de transfert de données S-
GW 5 par l'intermédiaire d'une interface SU. La passerelle de transfert de données S-GW 5 est connectée à la passerelle d'interconnexion P-GW 6 par l'intermédiaire d'une interface S5. L'architecture LTE/EPC telle que proposée par le consortium 3GPP s'appuie sur le protocole GTP (GPRS Tunneling Protocol), qui a deux composantes :
— le protocole GTP-U, utilisé pour le transfert (échange) de données utilisateur entre deux tunnels de communication séparés pour gérer les situations de mobilité du terminal utilisateur sur les interfaces SI et S5 ; et
— le protocole GTP-C utilisé pour établir, mettre à jour et maintenir les tunnels de communication GTP. Ainsi, les échanges de signalisation sur les interfaces SU et S5 s'appuient sur le protocole GTP-C.
L'équipement MME 7 utilise le protocole Sl-AP sur l'interface Sl-MME pour indiquer les paramètres radio et les paramètres des tunnels GTP aux stations de base 3A et 3B. Ces paramètres sont désignés plus généralement sous l'appellation de « paramètres de communication » dans la suite de la description.
De façon connue en soi, un tunnel GTP est identifié au niveau de chaque nœud du réseau par un identifiant de point d'extrémité du tunnel ou TEID (Tunnel Endpoint IDentifier), une adresse IP et un numéro de port UDP (User Datagram Protocol). C'est l'extrémité « réceptrice » du tunnel GTP qui attribue localement la valeur de l'identifiant TEID, utilisée par l'extrémité émettrice du tunnel pour transmettre des données ou de la signalisation dans ce tunnel à destination de l'extrémité réceptrice. Ainsi, dans l'exemple illustré à la figure 1, la passerelle P-GW 6 utilise la valeur d'identifiant TEID allouée par la passerelle S-GW 5 pour le trafic descendant émis sur l'interface S5. Les valeurs d'identifiants TEID sont échangées entre les extrémités des tunnels en utilisant les protocoles GTP-C et Sl-AP.
Selon la définition actuelle de l'architecture LTE/EPC, lorsqu'un équipement du cœur de réseau 1, tel que par exemple la passerelle de transfert de données S-GW 5, est subitement défaillant, les sessions de communication en cours gérées par cet équipement sont automatiquement interrompues. Le standard 3GPP prévoit alors le recours à une procédure de restauration décrite dans le document 3GPP TS 23.007 intitulé « Technical Spécification Group Core Network and Terminais ; Restoration procédures », Release 10, et illustrée schématiquement à la figure 2.
Conformément à cette procédure, la défaillance de la passerelle de transfert de données S-GW 5 (étape E10) est détectée par l'équipement MME 7 ou par la passerelle P-GW 6. Sur détection de cette défaillance (étape E20), l'équipement MME 7 initie une procédure de libération de l'interface SI pour les sessions actives passant par la passerelle de transfert de données S-GW 5 (étape E30).
Puis, l'équipement MME 7 alloue une nouvelle passerelle de transfert de données (non représentée sur la figure 1, référencée par « S-GW' » sur la figure 2) aux terminaux concernés (i.e. aux terminaux actifs ou non associés à la passerelle de transfert de données 5 défaillante), comme le terminal 2, et met à jour l'interface S5 en envoyant à la nouvelle passerelle de transfert de données S-GW' un message « Création Session Request » requérant une création de session (étape E40). Ce message inclut l'adresse de la passerelle P-GW 6 et la valeur P-GW-TEID allouée par la passerelle P-GW 6 pour le trafic en liaison montante sur l'interface S5.
La passerelle de transfert de données S-GW alloue alors une valeur S-GW'-TEID pour le trafic en liaison descendante associé au terminal 2 sur l'interface S5. Puis elle notifie la passerelle P-GW 6 du changement de passerelle de transfert de données en lui envoyant un message « Modify Bearer Request » (étape E50).
Les passerelles S-GW' et P-GW 6 accusent alors réception des différents messages (étapes E60 et E70).
L'équipement MME 7 rétablit ensuite le canal radio et le canal SI de chaque terminal impacté (étape E80). Toutefois, à cet effet, conformément à la norme 3GPP, l'équipement MME 7 attend de recevoir un message de requête de service du terminal 2 ou un message de notification de la présence de données destinées au terminal 2 en provenance de la nouvelle passerelle de transfert de données S-GW'. Autrement dit, cette procédure de restauration n'est pas transparente pour l'utilisateur du terminal 2 puisqu'elle met fin aux sessions de communication en cours et attend, pour rétablir ces sessions, que le terminal 2 initie une nouvelle requête de service.
L'expérience de l'utilisateur du terminal 2 est donc dégradée.
Par ailleurs, le rétablissement d'une session de communication engendre une signalisation importante selon cette procédure du fait de l'établissement de nouveaux tunnels GTP entre les différents équipements du cœur de réseau.
On peut envisager d'autres situations dans lesquelles l'architecture LTE/EPC telle que définie actuellement par le consortium 3GPP présente certaines insuffisances.
Ainsi, à titre illustratif, l'engouement des utilisateurs pour des applications gourmandes en bande passante telles que le téléchargement de vidéos, génère un trafic particulièrement imprévisible qui peut créer des goulots d'étranglement et/ou de congestion dans le plan de données du cœur de réseau LTE/EPC, typiquement au niveau des passerelles de transfert de données S-GW, des stations de base eNB et des passerelles P-GW.
Pour résoudre ce problème, il est possible de recourir à des techniques de répartition de la charge entre les équipements du cœur de réseau, aussi connues sous le nom de techniques de « load balancing ».
Dans l'état actuel de la norme, et comme décrit précédemment, l'équipement MME sélectionne pour une session de communication d'un terminal utilisateur, une passerelle de transfert de données S-GW et une passerelle d'interconnexion P-GW en se basant sur des facteurs de poids (ou WF pour « Weight Factors ») qui sont obtenus du serveur DNS (pour « Domain Name Server ») du cœur de réseau. Le poids associé par le serveur DNS à une passerelle dépend de sa capacité par rapport à des passerelles concurrentes servant une même région. Ainsi, l'équipement MME considère la capacité d'une passerelle de transfert de données avant de l'attribuer à une session de communication d'un terminal utilisateur, et met en œuvre une répartition en quelque sorte « proactive » de la charge. Toutefois, l'équipement MME n'a aucun moyen de connaître la charge en temps réel de cette passerelle de transfert de données, et d'anticiper ou gérer une éventuelle surcharge due par exemple à une augmentation soudaine du trafic engendré par les utilisateurs associés à cette passerelle de transfert de données. Par conséquent, en situation de surcharge, l'équipement MME va continuer d'assigner aux terminaux utilisateur lui adressant une requête de service la même passerelle de transfert de données.
En outre, la norme ne spécifie aujourd'hui aucun mécanisme permettant de transférer de manière transparente des sessions de communication en cours d'une passerelle de transfert de données à une autre. Comme illustré précédemment, un transfert du plan de données d'un équipement du cœur de réseau à un autre requiert le rétablissement de tunnels de communication GTP, ce qui entraîne des interruptions de sessions et une signalisation importante au sein du cœur de réseau EPC.
Les deux situations précédemment décrites montrent que le couplage étroit du plan de données et du plan de contrôle au sein d'une même entité du cœur de réseau (typiquement au sein d'une même passerelle de transfert de données S-GW) tel qu'il est envisagé actuellement dans l'architecture LTE/EPC défini par le 3GPP induit de fortes contraintes dès lors que l'on souhaite rendre cette architecture plus flexible ou plus fiable en termes de connectivité IP pour les utilisateurs.
Le document de J. Kempf et al. intitulé « Moving the Mobile Evolved Packet Core to the Cloud », 5th International Workshop on Selected Topics in Mobile and Wireless Computing, 2012, propose une évolution de l'architecture de cœur de réseau LTE/EPC définie par le consortium 3GPP, dans laquelle les plans de données et de contrôle sont séparés, et qui utilise le principe de réseau défini par logiciel, plus communément connu sous l'appellation SDN pour « Software Defined Networking ».
De façon connue, une architecture de réseau SDN permet de découpler les plans de contrôle et de données en centralisant l'intelligence du réseau (c'est-à-dire les fonctions de contrôle du réseau) au niveau d'un dispositif de contrôle logiciel. Le comportement des équipements du réseau tels que les commutateurs (« switches » en anglais) ou les routeurs est défini par des règles reçues du dispositif de contrôle, telles que des règles de traitement ou de transfert des données (i.e. du trafic). Le concept SDN s'appuie à cette fin notamment sur le protocole de communication OpenFlow défini par l'ONF (Open Networking Foundation), qui permet une programmation simplifiée, via une interface standard, des équipements périphériques du réseau.
Le document de J. Kempf et al. propose de déplacer les fonctions actuelles de l'équipement MME, ainsi que le plan de contrôle de la passerelle de transfert de données S-GW et de la passerelle d'interconnexion P-GW, dans un dispositif de contrôle exécuté par une machine virtuelle dans un centre de données externe aussi connu sous l'appellation de nuage informatique ou de « cloud » en anglais. Les équipements du plan de données du cœur de réseau EPC sont remplacés par des commutateurs OpenFlow, et le dispositif de contrôle est responsable de l'établissement du plan de données.
Toutefois, cette proposition s'appuie sur les mêmes interfaces entre les entités de contrôle du réseau que celles définies par le consortium 3GPP décrites précédemment, et notamment sur l'interface Sl-MME entre la station de base eNB et l'équipement MME.
Par ailleurs le document de J. Kempf et al. ne décrit aucune autre procédure de restauration pouvant être mise en œuvre en cas de défaillance ou de surcharge d'une passerelle de transfert de données S-GW que celle définie par le consortium 3GPP et rappelée ci-dessus.
Par conséquent, la solution proposée par J. Kempf et al., même si elle offre la possibilité de simplifier la maintenance et la configuration des équipements du cœur de réseau, ne permet pas d'améliorer l'expérience de l'utilisateur final dans les situations critiques envisagées précédemment (défaillance ou surcharge d'une passerelle de transfert de données).
Objet et résumé de l'invention
L'invention offre une solution notamment à ce problème en proposant un dispositif de contrôle d'un cœur de réseau IP comprenant :
— un module de communication apte à communiquer avec une entité de contrôle de transfert de données du cœur de réseau IP, et configuré pour déclencher la sélection par l'entité de contrôle de transfert de données d'une passerelle de transfert de données du cœur de réseau IP, le module de communication étant en outre configuré pour obtenir de l'entité de contrôle de transfert de données des paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal, connecté à une station de base d'un réseau d'accès, et une passerelle d'interconnexion du cœur de réseau IP connecté à un réseau de paquets de données, cette session de communication transitant par la station de base et la passerelle de transfert de données ;
— un premier module de contrôle de la station de base au moyen d'une première règle de traitement destinée à être appliquée par cette station de base suite à la réception de données relatives à la session de communication, la première règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base et la passerelle de transfert de données ; et
— un deuxième module de contrôle de la passerelle de transfert de données au moyen d'une deuxième règle de traitement destinée à être appliquée par cette passerelle de transfert de données suite à la réception de données relatives à la session de communication, la deuxième règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données et la passerelle d'interconnexion. Corrélativement, l'invention vise également un procédé de contrôle destiné à être mis en œuvre par un dispositif de contrôle d'un cœur de réseau IP, et comprenant :
— une étape de communication avec une entité de contrôle de transfert de données du cœur de réseau IP, comprenant un déclenchement d'une sélection par l'entité de contrôle de transfert de données d'une passerelle de transfert de données du cœur de réseau IP, et une obtention auprès de l'entité de contrôle de transfert de données de paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal, connecté à une station de base d'un réseau d'accès, et une passerelle d'interconnexion du cœur de réseau IP connectée à un réseau de paquets de données, cette session de communication transitant par la station de base et la passerelle de transfert de données ;
— une étape de contrôle de la station de base au moyen d'une première règle de traitement destinée à être appliquée par cette station de base suite à la réception de données relatives à la session de communication, la première règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base et la passerelle de transfert de données; et
— une étape de contrôle de la passerelle de transfert de données au moyen d'une deuxième règle de traitement destinée à être appliquée par cette passerelle de transfert de données suite à la réception de données relatives à la session de communication, la deuxième règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données et la passerelle d'interconnexion.
Par session de communication, on entend ici une session initiée par le terminal ou par le cœur de réseau dans le cadre d'un service offert par un réseau externe de paquets de données géré par le cœur de réseau. Cette session de communication est le support d'un échange de données entre le terminal et le réseau externe via le cœur de réseau. Chaque session de communication est associée à une qualité de service qui dépend du type de trafic échangé lors de la session (ex. session FTP (File Transfer Protocol), session de communication de voix sur IP, etc.).
Par données relatives à une session de communication, on entend ici des données échangées lors de cette session en liaison montante (du terminal vers le réseau externe) ou descendante (du réseau externe vers le terminal).
L'invention propose ainsi de découpler les plans de données et de contrôle dans le cœur de réseau IP, en appliquant les principes SDN du réseau défini par logiciel à l'architecture du cœur de réseau IP.
Plus précisément elle propose de contrôler, par l'intermédiaire d'un dispositif de contrôle par exemple logiciel, non seulement les passerelles de transfert de données du cœur de réseau mais également les stations de base des réseaux d'accès au cœur de réseau. Les stations de base du réseau d'accès et les passerelles de transfert de données sont ainsi connectées directement au dispositif de contrôle.
Conformément à l'invention, le contrôle opéré par le dispositif de contrôle est réalisé à l'aide de règles de traitement des données, élaborées par le dispositif de contrôle logiciel et transmises aux passerelles de transfert de données et aux stations de base pour application lors d'une session de communication d'un terminal.
Ces règles de traitement sont par exemple des règles de transfert des données. Ainsi, dans un mode particulier de réalisation de l'invention :
— les paramètres de communication de la première règle comprennent une adresse de la passerelle de transfert de données et un identifiant de point d'extrémité d'un tunnel de communication établi entre la passerelle de transfert de données et la station de base pour le transfert des données, alloué par l'entité de contrôle de transfert de données ; et/ou
— les paramètres de communication de la deuxième règle comprennent une adresse de la passerelle d'interconnexion et un identifiant de point d'extrémité d'un tunnel de communication établi entre la passerelle de transfert de données et la passerelle d'interconnexion pour le transfert des données, alloué par l'entité de contrôle de transfert de données.
Les règles de traitement transmises par le dispositif de contrôle logiciel peuvent être mises à jour facilement directement au niveau des équipements commandés par le dispositif de contrôle. La gestion du cœur de réseau, et en particulier les procédures d'établissement et de maintien des sessions de communication au sein du cœur de réseau, sont ainsi simplifiées.
Grâce au découplage proposé par l'invention, et plus précisément en centralisant au niveau du dispositif de contrôle la sélection des passerelles de transfert de données impliquées dans la session de communication, l'invention offre la possibilité de mettre aisément en œuvre des procédures de restauration en cas de surcharge et/ou de défaillance d'un équipement du cœur de réseau tel une passerelle de transfert de données, et ce, sans nécessiter de signalisation excessive, et transparentes pour les utilisateurs des terminaux.
Il en résulte une flexibilité de la gestion du cœur de réseau et une amélioration de la fiabilité de la connectivité IP offerte aux terminaux par celui-ci. L'expérience des utilisateurs est ainsi privilégiée.
L'invention s'applique de façon privilégiée à une architecture de cœur de réseau
LTE/EPC. Dans un tel contexte, elle propose de modifier les protocoles de communications prévus sur les interfaces de communication Sl-MME (entre les stations de base et l'entité de gestion de la mobilité du cœur de réseau) et SU (entre l'entité de gestion de la mobilité et les passerelles de transfert de données S-GW).
Ainsi, contrairement à l'état de la technique décrit dans le document de J. Kempf et al., l'invention propose de modifier les interfaces de l'architecture LTE/EPC prévues par le consortium 3GPP. La nouvelle architecture de cœur de réseau définie par l'invention permet ainsi de revoir la procédure de restauration en cas de défaillance d'un équipement du cœur de réseau proposée actuellement par le consortium 3GPP, et d'offrir aux terminaux une procédure plus souple et plus transparente en termes de connectivité IP.
Dans un mode particulier de réalisation de l'invention, le module de communication communique avec l'entité de contrôle de transfert de données par l'intermédiaire d'une interface de programmation.
Dans un autre mode particulier de réalisation, le premier module de contrôle et le deuxième module de contrôle sont configurés pour communiquer respectivement avec la station de base et avec la passerelle de transfert de données par l'intermédiaire du protocole OpenFlow.
L'utilisation du protocole OpenFlow facilite l'implémentation de l'invention. En outre, ce protocole offre la possibilité au dispositif de contrôle de collecter en temps réel des statistiques de charge auprès des passerelles de transfert de données, et d'envisager ainsi une sélection des équipements impliqués dans la session de communication d'un terminal en fonction de la charge courante de ces équipements. Il est également possible d'appliquer aisément des algorithmes de répartition de la charge lors de cette sélection pour améliorer l'expérience des utilisateurs.
Ainsi, dans un mode particulier de réalisation, le dispositif de contrôle comprend en outre un module d'obtention d'informations représentatives d'une charge courante d'au moins une passerelle de transfert de données du cœur de réseau IP connectée au dispositif de contrôle, le module de communication étant en outre configuré pour fournir ces informations à l'entité de contrôle de transfert de données via une interface de programmation.
Dans un autre mode de réalisation de l'invention, le module de communication du dispositif de contrôle est en outre configuré pour déclencher par l'intermédiaire d'une interface de programmation, sur réception d'une requête d'attachement du terminal au cœur de réseau IP, une authentification du terminal par une entité de gestion de la mobilité appartenant au cœur de réseau IP.
Ainsi, dans ce mode de réalisation, l'authentification du terminal est géré par une application s'exécutant au-dessus du dispositif de contrôle logiciel et interagissant avec celui-ci via une interface de programmation ou API.
Dans un autre mode de réalisation de l'invention, le dispositif de contrôle comprend en outre un module de détection d'une défaillance ou d'une surcharge de la passerelle de transfert de données, le module de communication étant en outre configuré pour informer l'entité de contrôle de transfert de données de cette défaillance ou de cette surcharge et pour déclencher la sélection par l'entité de contrôle de transfert de données d'une nouvelle passerelle de transfert de données pour la session de communication, et dans lequel :
— le premier module de contrôle est configuré pour mettre à jour la première règle de traitement appliquée par la station de base avec des paramètres de communication, obtenus de l'entité de contrôle de transfert de données par le module de communication du dispositif de contrôle et destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base et la nouvelle passerelle de transfert de données ; et
— le deuxième module de contrôle est configuré pour contrôler la nouvelle passerelle de transfert de données à l'aide d'une troisième règle de traitement destinée à être appliquée par cette nouvelle passerelle de transfert de données suite à la réception de données relatives à la session de communication, la troisième règle comprenant des paramètres de communication, obtenus de l'entité de contrôle de transfert de données par le module de communication du dispositif de contrôle et destinés à être utilisés lors de la session de communication pour le transfert de données entre la nouvelle passerelle de transfert de données et la passerelle d'interconnexion.
Par exemple, la première règle de traitement est mise à jour avec une adresse de la nouvelle passerelle de transfert de données.
En outre, les paramètres de communication de la deuxième règle de traitement et de la troisième règle de traitement peuvent comprendre un même identifiant de point d'extrémité de tunnel alloué par l'entité de contrôle de transfert de données et destiné à être utilisé entre la passerelle de transfert de données et la passerelle d'interconnexion, et entre la nouvelle passerelle de transfert de données et la passerelle d'interconnexion.
Autrement dit, l'identifiant de point d'extrémité de tunnel alloué par l'entité de contrôle de transfert de données est invariant par rapport à la passerelle de transfert de données sélectionnée pour la session de communication.
La signalisation nécessaire pour gérer un changement de passerelle de transfert de données est ainsi avantageusement limitée : seule l'adresse de la nouvelle passerelle de transfert de données sélectionnée nécessite d'être signalée par le dispositif de contrôle pour assurer la continuité de la session de communication.
Pour permettre le découplage des plans de contrôle et de données, l'invention s'appuie non seulement sur un dispositif de contrôle, mais également sur une entité de contrôle de transfert de données du cœur de réseau IP apte à communiquer avec le dispositif de contrôle logiciel, par exemple via une interface de programmation, autrement dit, s'exécutant au-dessus du dispositif de contrôle logiciel.
Ainsi, l'invention vise également une entité de contrôle de transfert de données d'un cœur de réseau IP comprenant :
— un module de communication apte à communiquer avec un dispositif de contrôle du cœur de réseau IP selon l'invention ;
— un module de sélection, déclenché par le dispositif de contrôle via le module de communication, et configuré pour sélectionner une passerelle de transfert de données du cœur de réseau IP ;
— un module d'obtention de paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal connecté à une station de base d'un réseau d'accès et une passerelle d'interconnexion du cœur de réseau IP connectée à un réseau de paquets de données, cette session de communication transitant par la station de base et la passerelle de transfert de données ;
— un module de fourniture à la passerelle d'interconnexion de paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données et la passerelle d'interconnexion ;
le module de communication étant configuré pour fournir au dispositif de contrôle des paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base et la passerelle de transfert de données.
Corrélativement, l'invention vise aussi un procédé de sélection destiné à être mis en œuvre par une entité de contrôle de transfert de données d'un cœur de réseau IP, et comprenant :
— une étape de sélection, déclenchée par un dispositif de contrôle du cœur de réseau IP, d'une passerelle de transfert de données du cœur de réseau IP ;
— une étape d'obtention de paramètres de communication destinés à être utilisés lors d'une session de communication entre une terminal connecté à une station de base d'un réseau d'accès et une passerelle d'interconnexion du cœur de réseau IP connectée à un réseau de paquets de données, cette session de communication transitant par la station de base et la passerelle de transfert de données ;
— une étape de fourniture
o à ladite passerelle d'interconnexion, de paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données et la passerelle d'interconnexion ; et
o au dispositif de contrôle, de paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base et la passerelle de transfert de données.
L'entité de contrôle de transfert de données et le procédé de sélection selon l'invention bénéficient des mêmes avantages que ceux cités précédemment pour le dispositif de contrôle et le procédé de contrôle selon l'invention.
Dans un mode particulier de réalisation, le module d'obtention de paramètres de communication de l'entité de contrôle de transfert de données est configuré pour allouer à la session de communication un identifiant de point d'extrémité d'un tunnel de communication entre la passerelle de transfert de données et la station de base et un identifiant de point d'extrémité d'un tunnel de communication entre la passerelle de transfert de données et la passerelle d'interconnexion. Par exemple, les identifiants alloués par l'entité à la session de communication sont invariants durant la session de communication, de sorte à simplifier la signalisation échangée lors de session notamment en cas de changement de passerelle de transfert de données en cours de session.
Dans un autre mode de réalisation, le module de sélection de l'entité de contrôle de transfert de données est configuré pour sélectionner la passerelle de transfert de données parmi une pluralité de passerelles de transfert de données contrôlées par le dispositif de contrôle en utilisant des informations représentatives d'une charge courante de ces passerelles de transfert de données fournies par le dispositif de contrôle via une interface de programmation.
L'invention offre ainsi la possibilité de mettre en œuvre des algorithmes de répartition de la charge entre les différents équipements du cœur de réseau et notamment les passerelles de transfert de données, de sorte à améliorer l'expérience des utilisateurs en matière de connectivité IP. Grâce à cette connaissance de la charge des passerelles de transfert de données, il est possible d'envisager en cas de surcharge d'une passerelle de transférer tout ou partie des sessions transitant par cette passerelle de transfert de données vers une autre passerelle de transfert de données.
Ainsi, par exemple, dans un mode particulier de réalisation de l'invention :
— le module de sélection est configuré pour sélectionner une nouvelle passerelle de transfert de données pour la session de communication du terminal lorsqu'il est informé par le dispositif de contrôle, via une interface de programmation, d'une défaillance ou d'une surcharge de la passerelle de transfert de données ;
— le module de fourniture et le module de communication sont configurés pour fournir respectivement à la passerelle d'interconnexion et au dispositif de contrôle cette adresse de la nouvelle passerelle de transfert de données.
Selon un autre aspect, l'invention vise également un cœur de réseau IP comprenant :
— une pluralité de passerelles de transfert de données ;
— un dispositif de contrôle selon l'invention, apte à contrôler au moins une station de base d'un réseau d'accès auquel est connecté un terminal et la pluralité de passerelles de transfert de données ; et
— une entité de contrôle de transfert de données selon l'invention, apte à communiquer avec le dispositif de contrôle, et à sélectionner une passerelle de transfert de données parmi la pluralité de passerelles de transfert de données contrôlées par le dispositif de contrôle pour une session de communication du terminal.
Dans un mode particulier de réalisation de l'invention, ce cœur de réseau IP comprend en outre une entité de gestion de la mobilité configurée pour authentifier le terminal, cette authentification étant déclenchée par le dispositif de contrôle via une interface de programmation.
Selon un autre aspect encore, l'invention vise aussi une station de base d'un réseau d'accès, apte à servir un terminal lors d'une session de communication, et comprenant : — des moyens de réception, en provenance d'un dispositif de contrôle d'un cœur de réseau IP selon l'invention, d'une règle de traitement destinée à être appliquée par cette station de base suite à la réception de données relatives à cette session de communication du terminal, la règle de traitement comprenant des paramètres de communication destinés à être utilisés lors de cette session de communication pour le transfert de données entre la station de base et une passerelle de transfert de données du cœur de réseau IP ; et
— des moyens d'application de cette règle de traitement à des données relatives à la session de communication.
Le cœur de réseau IP et la station de base selon l'invention présentent les mêmes avantages que ceux cités précédemment pour le dispositif de contrôle et l'entité de contrôle de transfert de données.
Dans un mode particulier de réalisation, les différentes étapes du procédé de contrôle et/ou du procédé de sélection sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un dispositif de contrôle ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de contrôle tel que décrit ci-dessus.
L'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans une entité de contrôle de transfert de données ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de sélection tel que décrit ci-dessus.
Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. On peut également envisager, dans d'autres modes de réalisation, que le procédé de contrôle, le procédé de sélection, le dispositif de contrôle, l'entité de contrôle de transfert de données, la station de base et le cœur de réseau selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvu de tout caractère limitatif. Sur les figures :
— la figure 1, déjà décrite, représente l'architecture d'un cœur de réseau LTE/EPC telle que proposée par le consortium 3GPP ;
— la figure 2, déjà décrite, illustre une procédure de restauration supportée par l'architecture de la figure 1 et proposée par le consortium 3GPP en cas de défaillance d'une passerelle de transfert de données ;
— les figures 3 et 4 illustrent les principes d'un réseau défini par logiciel (SDN) ;
— la figure 5 représente, dans son environnement, un cœur de réseau, un dispositif de contrôle, une entité de contrôle de transfert de données et une station de base conformes à l'invention dans un mode particulier de réalisation ;
— la figure 6 représente schématiquement l'architecture matérielle d'un dispositif informatique implémentant le dispositif de contrôle et l'entité de contrôle de transfert de données illustrés à la figure 6 ;
— la figure 7 représente les principales étapes d'une procédure d'attachement d'un terminal au cœur de réseau de la figure 5, pouvant être mise en œuvre par le cœur de réseau de la figure 5, conformément à l'invention ;
— la figure 8 représente les principales étapes d'une procédure d'établissement d'un plan de données pouvant être mise en œuvre par le cœur de réseau de la figure 5, conformément à l'invention ; et
— la figure 9 représente les principales étapes d'une procédure de restauration en cas de défaillance d'une passerelle de transfert de données, pouvant être mise en œuvre par le cœur de réseau de la figure 5, conformément l'invention.
Description détaillée de l'invention
Comme mentionné précédemment, l'invention propose d'implémenter une architecture SDN de réseau défini par logiciel au sein d'un cœur de réseau IP, tel que par exemple un cœur de réseau LTE/EPC, de sorte à améliorer la flexibilité et la fiabilité en termes de connectivité IP de ce cœur de réseau. Cette nouvelle architecture permet en effet de mettre en œuvre aisément des procédures de restauration transparentes pour les utilisateurs en cas de défaillance d'un équipement du cœur de réseau et/ou d'équilibre de la charge afin de privilégier l'expérience des utilisateurs.
Plus précisément, l'invention définit un nouveau plan de contrôle selon lequel une pluralité de passerelles de transfert de données du cœur de réseau et de stations de bases du réseau d'accès (via lesquelles des terminaux peuvent accéder aux services offerts par le cœur de réseau) sont commandées par un dispositif de contrôle. Dans le mode de réalisation décrit ici, ce dispositif de contrôle est un dispositif de contrôle logiciel, relié par l'intermédiaire d'une interface de programmation (ou API pour Application Programming Interface) à une entité responsable de la sélection des équipements du cœur de réseau impliqués dans les sessions de communication pour le transfert des données (i.e. les passerelles de transfert de données S-GW et passerelles d'interconnexion P-GW)) et l'établissement de tunnels de communication, dans le plan de données notamment, entre les équipements ainsi sélectionnés.
Pour faciliter la compréhension de l'invention, nous allons dans un premier temps rappeler brièvement, en référence aux figures 3 et 4, les principes généraux d'une architecture SDN. Dans l'exemple retenu pour illustrer ces principes, on suppose que cette architecture repose sur l'utilisation du protocole OpenFlow, connu de l'homme du métier et décrit notamment dans le document « Openflow switch spécification, version 1.3.1 », Septembre 2012.
Comme mentionné précédemment, le concept SDN permet de spécifier le comportement d'équipements réseau à l'aide de programmes de contrôle haut niveau, ce qui permet d'automatiser aisément certaines tâches comme la configuration des équipements du réseau ou la gestion des politiques appliquées au niveau du réseau.
A cet effet, l'architecture SDN centralise l'intelligence du réseau (i.e. les fonctions de contrôle du réseau et de ses équipements) dans un dispositif de contrôle (ou contrôleur) logiciel.
Le comportement des équipements du réseau tels que les commutateurs ou les routeurs en présence de données relatives à une session de communication est alors défini par le dispositif de contrôle au moyen de règles dites de traitement qu'il transmet aux équipements du réseau. Ces règles sont stockées par les équipements du réseau et sont destinées à être appliquées par ceux-ci sur réception de données relatives à une session de communication. Elles spécifient par exemple les équipements du réseau vers lesquels transférer les données (i.e. le trafic) en liaisons montante et descendante.
La figure 3 résume ce mode de fonctionnement en modélisant schématiquement une architecture SDN selon trois couches :
— une couche inférieure DP, modélisant le plan de données et comprenant les commutateurs/routeurs R du réseau commandés (contrôlés) par le dispositif de contrôle (ces commutateurs/routeurs R peuvent être indifféremment physiques ou virtuels) ;
— une couche intermédiaire NW CTRL, modélisant à proprement parler le dispositif de contrôle logiciel référencé par « OpenCTR » ; et — une couche supérieure APPL, modélisant diverses applications ou fonctions de contrôle APP utilisées par le dispositif de contrôle OpenCTR pour commander les commutateurs/routeurs R du plan de données DP et élaborer les règles de traitement.
Les différentes couches précitées communiquent entre elles via des interfaces de programmation ou API appelées « NorthBound API » et « SouthBound API » (notées respectivement « NB API » et « SB API » sur la figure 3). Le dispositif de contrôle OpenCTR communique par ailleurs avec d'autres contrôleurs via des interfaces de programmation appelées « East/West Bound API » (et notées « E/WB API » sur la figure 3).
Les interfaces de programmation SB API entre le dispositif de contrôle OpenCTR et le plan de données implémentent ici le protocole de communication OpenFlow. Les interfaces de programmation NB API et E/WB API sont basées sur n'importe quel protocole de communication ouvert, choisi par exemple parmi les protocoles connus SOAP (pour « Simple Object Access Protocol »), RPC (pour « Remote Procédure Call ») ou REST (pour « Representational State Transfer »).
Comme rappelé précédemment et illustré à la figure 4, le protocole OpenFlow permet au dispositif de contrôle logiciel OpenCTR de commander aisément chaque commutateur/routeur R au moyen d'un ensemble de règles de traitement de données, incluant notamment des règles de transfert (ou de routage) de données destinées à être appliquées par le routeur sur réception de données relatives à une session de communication (autrement dit, échangées lors d'une session de communication).
Ces règles de traitement sont déterminées par le dispositif de contrôle OpenCTR en fonction par exemple de la politique de l'opérateur envisagée pour la gestion du réseau. Elles spécifient le traitement devant être appliqué par chaque commutateur sur réception d'un paquet d'un flux de données associé à une session de communication d'un terminal déterminé, et des paquets suivants associés au même flux.
Ces règles de traitement sont stockées au niveau de chaque commutateur R sous la forme de tables de flux FTAB (ou « flow tables » en anglais), dont les entrées peuvent être aisément modifiées par le dispositif de contrôle OpenCTR à l'aide du protocole OpenFlow (ex. ajout, mise à jour, suppression d'entrées dans la table).
A titre illustratif, une entrée E d'une telle table de flux FTAB est représentée sur la figure 4. Elle se présente sous la forme de plusieurs champs ou paramètres destinés à être examinés par le commutateur R sur réception d'un paquet de données pour identifier quel traitement appliquer sur ce paquet (ex. vers quel équipement du cœur de réseau transférer le paquet de données). Ces champs incluent par exemple un champ MF (pour « Match Fields ») indiquant les champs de l'entête des paquets concernés par cette entrée E de la table, ainsi qu'un champ INST (pour « Instructions ») définissant le traitement à appliquer sur les paquets dont l'entête comprend les champs identifiés par MF. D'autres champs peuvent bien entendu être également définis pour chaque entrée de la table FTAB en sus de ces deux champs, comme illustré sur la figure 4, tels que par exemple un champ TO (pour « Time Out), PRIO (pour « Priority »), COOK (pour « Cookie ») ou CNT (pour « Counters »).
Le commutateur R utilise les tables de flux FTAB ainsi définies de la façon suivante. Sur réception d'un paquet de données, il cherche dans les tables FTAB stockées si le champ MF d'une entrée coïncide avec les champs de l'entête de ce paquet.
Le cas échéant, les instructions associées à cette entrée spécifiées dans le champ INST correspondant sont exécutées par le commutateur R sur le paquet de données (ex. transférer le paquet vers un équipement déterminé du réseau, ou modifier ou supprimer le paquet).
Si en revanche, aucune entrée ne coïncide avec le paquet reçu, celui-ci est transféré vers le dispositif de contrôle OpenCTR qui crée une nouvelle entrée de table de flux et un traitement associé à cette entrée (autrement dit une nouvelle règle de traitement), et la transmet au commutateur R pour qu'il la stocke dans une table de flux associée au terminal.
On comprend bien dès lors, au vu du mode de fonctionnement qui vient d'être décrit, que selon une architecture de réseau SDN, les plans de contrôle et de données sont découplés.
Nous allons maintenant décrire, en référence aux figures 5 à 9, comment l'invention propose avantageusement d'appliquer ce principe à une architecture de cœur de réseau IP, et plus particulièrement à une architecture de cœur de réseau LTE/EPC.
Par souci de simplification de l'exposé, lorsqu'aucune précision n'est apportée dans la description, les fonctions et les modes de fonctionnement des équipements de l'architecture de cœur de réseau IP présentée (ex. passerelles de transfert de données telles que des passerelles S- GW, passerelles d'interconnexion telles que des passerelles P-GW, stations de bases en particulier de type eNodeB, équipement de gestion de mobilité tel qu'un équipement MME, établissement des tunnels de communication selon le protocole GTP, etc.) sont similaires ou identiques à ceux décrits dans le document 3GPP TS 23.401 édité par le 3GPP et ne sont pas détaillés ici. L'invention ne se limite toutefois pas aux seuls réseaux de télécommunications LTE et peut être également appliquée à d'autres architectures de cœurs de réseau basés sur le protocole IP (« ail IP networks »), tels que par exemple une architecture de cœur de réseau propriétaire.
La figure 5 représente un cœur de réseau LTE/EPC 10 conforme à l'invention, dans un mode particulier de réalisation dans lequel le cœur de réseau 10 permet à un terminal UE 11 d'accéder à des services offerts par un (ou des) réseau(x) externe(s) de paquets de données PDN 12.
Le réseau PDN 12 est relié au cœur de réseau 10 par l'intermédiaire d'une passerelle d'interconnexion 13, pouvant être une passerelle P-GW telle que définie dans le document 3GPP TS 23.401, permettant l'accès du cœur de réseau 10 au réseau PDN 12 et vice versa. On suppose ici, que pour accéder aux services offerts par le réseau PDN 12 via le cœur de réseau LTE/EPC 10, le terminal UE 11 est connecté à une station de base 14 (typiquement une eNodeB) d'un réseau d'accès, tel que par exemple un réseau de télécommunications mobiles UMTS. Aucune limitation n'est toutefois attachée à la nature du réseau d'accès utilisé par le terminal UE 11 dès lors que celui-ci est compatible avec le cœur de réseau 10.
Conformément à l'invention, les fonctions de contrôle d'une pluralité de passerelles de transfert de données 15 du cœur de réseau 10 (lesquelles peuvent typiquement être des passerelles S-GW telles que définies dans le document 3GPP TS 23.401), qui permettent de relier les stations de base 14 à la passerelle d'interconnexion 13 et donc au cœur de réseau 10, sont séparées des fonctions de transfert de données destinées à être appliquées par ces passerelles de transfert de données (autrement dit du plan de données). Cette séparation du plan de contrôle (signalisation) et du plan de données est assurée par l'introduction d'un dispositif de contrôle logiciel 16 dans le cœur de réseau 10, reprenant les fonctions du dispositif de contrôle OpenCTR décrites précédemment.
Le dispositif de contrôle logiciel 16 centralise ainsi l'intelligence réseau des passerelles de transfert de données et détermine les règles de traitement devant être appliquées aux paquets de données reçus par celles-ci. Il assure l'établissement et le maintien des sessions de communication des terminaux des utilisateurs accédant au cœur de réseau 10.
Afin de mieux illustrer la séparation des plans préconisée par l'invention, l'entité rassemblant les fonctions de contrôle des passerelles de transfert de données est référencée par « SGW-C » sur la figure 5 et dans la description. Une telle entité SGW-C est désignée comme étant une entité de contrôle de transfert de données. Pour leur part, les équipements appliquant les fonctions de traitement ou de transfert dans le plan de données de ces passerelles de transfert de données sont référencés par « SGW-D ».
Dans le mode de réalisation décrit ici, les passerelles de transfert de données SGW-D
15 commandées par l'intermédiaire du dispositif de contrôle logiciel 16 sont aptes à encapsuler et à désencapsuler des paquets échangés sur un tunnel de communication établi conformément au protocole GTP-U comme défini par le consortium 3GPP, et appartiennent à une même région prédéterminée. Ainsi, dans l'exemple illustré à la figure 5, le dispositif de contrôle logiciel 16 centralise, via l'entité logicielle SGW-C 17, les fonctions de contrôle de trois passerelles de transfert de données SGW-D 15A, 15B et 15C. Bien entendu, ce nombre peut varier, notamment en fonction de contraintes opérationnelles et/ou de dimensionnement des équipements du cœur de réseau.
L'entité logicielle SGW-C 17 est une entité de contrôle de transfert de données conforme à l'invention, qui se présente plus précisément ici sous la forme d'une application s'exécutant au-dessus du dispositif de contrôle logiciel 16 et communiquant avec celui-ci via une interface de programmation ou API notée API17.
De même, dans le mode de réalisation décrit ici, le cœur de réseau 10 comprend une entité de gestion de la mobilité 18 qui se présente sous forme logicielle, en particulier sous la forme d'une application s'exécutant au-dessus du dispositif de contrôle logiciel 16 et qui communique avec celui-ci via une interface de programmation notée API18.
Ainsi, en référence à la figure 3 commentée précédemment et aux principes généraux du SDN, les interfaces de programmation API17 et API18 remplissent le rôle d'interfaces de programmation « NorthBound ».
L'entité de gestion de la mobilité 18 est chargée d'authentifier les terminaux cherchant à accéder au cœur de réseau 10 (autrement dit de vérifier que ces terminaux sont bien autorisés à accéder au cœur de réseau 10 et/ou aux services offerts par le réseau PDN 12), selon des techniques d'authentification et d'autorisation connues de l'homme du métier. L'entité de gestion de la mobilité 18 est également responsable de la gestion de la mobilité des terminaux au sein d'un même réseau. Cette entité 18 peut notamment être un équipement MME tel que décrit dans le document 3GPP TS 23.401.
Toutefois, contrairement à l'équipement MME décrit dans le document 3GPP TS 23.401 et conformément à l'invention, l'entité 18 de gestion de mobilité n'est plus responsable de la sélection, pour une session de communication associée à un terminal, de la passerelle de transfert de données SGW et de la passerelle P-GW impliquées lors de cette session dans l'échange de données entre le terminal et le réseau PDN 12. Cette fonction est en effet assurée, conformément à l'invention, par l'entité de contrôle de transfert de données SGW-C 17 du cœur de réseau 10, comme décrit plus en détail ultérieurement.
II convient de noter que dans le mode de réalisation décrit ici, le dispositif de contrôle
16, et les entités SGW-C 17 et 18 sont des entités logicielles, autrement dit des applications ou des programmes d'ordinateur qui s'exécutent sur un même dispositif informatique ou ordinateur 19. En variante, ces applications peuvent s'exécuter sur des dispositifs informatiques distincts communiquant entre eux de façon connue de l'homme du métier.
La figure 6 illustre schématiquement l'architecture matérielle d'un tel dispositif informatique 19. Ce dispositif comprend un processeur 20, une mémoire morte 21, une mémoire vive 22, une mémoire non volatile 23 et des moyens de communication 24, aptes en particulier à communiquer avec les passerelles de transfert de données SGW-D 15, la passerelle d'interconnexion 13 et les stations de base 14 selon des protocoles de communication précisés ultérieurement.
La mémoire morte 21 du dispositif informatique 19 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 20 et sur lequel sont enregistrés un programme d'ordinateur conforme à l'invention comportant des instructions pour l'exécution des étapes d'un procédé de contrôle selon l'invention, et un programme d'ordinateur conforme à l'invention comportant des instructions pour l'exécution d'un procédé de sélection selon l'invention, dont les étapes sont illustrées ultérieurement en référence aux figures 7 à 9. En d'autres termes, les programmes d'ordinateur précités définissent le dispositif de contrôle logiciel 16 et les entités logicielles SGW-C 17 et 18 (ainsi que les modules fonctionnels mis en œuvre par ces entités), de sorte que dans la description les références 16, 17 et 18 peuvent désigner aussi bien les entités fonctionnelles correspondantes que le dispositif informatique 19 associé permettant d'exécuter ces entités.
Pour en revenir à la figure 5, dans le mode de réalisation décrit ici, le dispositif de contrôle 16 contrôle le comportement des stations de base 14 (deux stations de base 14A et 14B étant représentées sur la figure 5, de manière non limitative) par l'intermédiaire d'un module de contrôle 16A (premier module de contrôle au sens de l'invention) implémentant le protocole de communication OpenFlow.
Les stations de base 14A et 14B constituent des stations de base dont les fonctions radio peuvent être les mêmes que celles des stations de base eNodeB spécifiées dans le document 3GPP TS 23.401. Elles sont toutefois, conformément à l'invention et à la différence des stations de base eNodeB spécifiées dans le document 3GPP TS 23.401, commandées par le dispositif de contrôle 16 par l'intermédiaire du module 16A pour ce qui concerne le transfert des données vers les passerelles de transfert de données SGW-D 15, au moyen de règles de traitement définies par celui-ci et stockées dans des tables de flux FTAB14 mémorisées par les stations de base 14. Les tables FTAB14 sont similaires ou identiques aux tables FTAB décrites précédemment en référence à la figure 4.
Ces règles de traitement identifient par exemple ici la passerelle de transfert de données SGW-D 15 vers laquelle transférer les paquets de données reçus d'un terminal en liaison montante par une station de base 14 lors d'une session de communication. Elles comprennent notamment les paramètres de communication destinés à être utilisés lors de ce transfert, c'est-à- dire typiquement les paramètres identifiant le tunnel de communication GTP-U destiné à être établi ou établi.
Le dispositif de contrôle 16 contrôle en outre le comportement des passerelles de transfert de données SGW-D 15 (i.e. des passerelles de transfert de données actives dans le plan de données) par l'intermédiaire d'un module de contrôle 16B implémentant également le protocole de communication OpenFlow.
Ce module de contrôle 16B constitue un deuxième module de contrôle au sens de l'invention. Il est configuré pour transmettre aux passerelles de transfert de données SGW-D 15 des règles de traitement (deuxièmes et troisièmes règles de traitement au sens de l'invention) définies par le dispositif de contrôle 16 et destinées à être appliquées par les passerelles de transfert de données SGW-D 15 sur réception de données relatives à une session de communication d'un terminal d'un utilisateur (notamment ici du terminal 11). Ces règles de traitement sont stockées au niveau des passerelles de transfert de données SGW-D 15 dans des tables de flux FTAB15, similaires ou identiques aux tables FTAB décrites précédemment en référence à la figure 4. Elles identifient par exemple ici :
— d'une part, la passerelle d'interconnexion 13 (par exemple via une adresse IP) vers laquelle transférer les paquets de données reçus par les passerelles de transfert de données SGW-D 15 en liaison montante lors d'une session de communication associée à ce terminal, et les paramètres de communication destinés à être utilisés lors de ce transfert ; et
— d'autre part, la station de base 14A (par exemple via son adresse IP) vers laquelle transférer les paquets de données reçus par les passerelles de transfert de données SGW-D 15 en liaison descendante lors d'une session de communication associée à ce terminal, et les paramètres de communication destinés à être utilisés lors de ce transfert
Les paramètres de communication stockés dans les tables de flux FTAB15 incluent typiquement les paramètres identifiant les tunnels de communication GTP-U destinés à être établis ou établis en liaison montante et en liaison descendante entre la passerelle de transfert de données SGW-D concernée, et la passerelle d'interconnexion et la station de base identifiées dans la table.
Il convient de noter que le protocole OpenFlow étant connu de l'homme du métier, il n'est pas détaillé davantage ici.
Dans le mode de réalisation décrit ici, on suppose que les stations de base 14 et les passerelles de transfert de données SGW-D 15 mettent en œuvre, pour communiquer entre elles dans le plan de données, une interface basée sur l'établissement de tunnels de communication en liaisons montante et descendante conformes au protocole GTP-U, qui peut être similaire ou identique à l'interface Sl-U spécifiée dans le document 3GPP TS 23.401.
De même, les passerelles de transfert de données SGW-D 15 et la passerelle d'interconnexion 13 mettent en œuvre, pour communiquer entre elles dans le plan de données, une interface basée sur l'établissement de tunnels de communication en liaisons montante et descendante conformes au protocole GTP-U, qui peut être similaire ou identique à l'interface S5-U spécifiée dans le document 3GPP TS 23.401.
Selon l'architecture proposée par l'invention, le dispositif de contrôle 16 est, comme mentionné précédemment, chargé de l'établissement des sessions de communication pour les terminaux utilisateur, et en particulier pour le terminal UE 11. A cet effet, il interagit avec l'entité SGW-C 17 et l'entité MME 18 via les interfaces de programmation API17 et API18 respectivement.
L'entité SGW-C 17 a, quant à elle, pour fonction d'établir les tunnels de communication GTP supportant les échanges de données en liaison descendante et en liaison montante transitant par les différents équipements du cœur de réseau 10 lors des sessions de communication des terminaux, et notamment entre les stations de base 14 et les passerelles de transfert de données SGW-D 15, et entre les passerelles de transfert de données SGW-D 15 et la passerelle d'interconnexion 13. Ces tunnels de communication sont, comme rappelé précédemment, définis (i.e. identifiés) par différents paramètres de communication tels que les identifiants de points d'extrémités du tunnel TEID, ainsi qu'une adresse IP et un numéro de port UDP (User Datagram Protocol) de ces points.
On rappelle que, dans l'état actuel de la technique défini par le consortium 3GPP, c'est l'extrémité « réceptrice » du tunnel GTP qui attribue localement la valeur de l'identifiant TEID, utilisée par l'extrémité émettrice du tunnel pour transmettre des données ou de la signalisation dans ce tunnel à destination de l'extrémité réceptrice.
Conformément à l'invention, pour les tunnels de communication GTP ayant comme extrémités réceptrices les passerelles de transfert de données SGW-D 15 (autrement dit pour les tunnels de communication établis en liaison montante entre les stations de base 14 et les passerelles de transfert de données SGW-D 15 gérées par le dispositif de contrôle 16, et pour les tunnels de communication établis en liaison descendante entre la passerelle d'interconnexion 13 et les passerelles de transfert de données SGW-D 15), c'est l'entité SGW-C 17 qui est configurée pour allouer à chaque tunnel GTP une unique valeur d'identifiant TEID. Par unique, on entend que cette valeur est invariante tout au long de la session de communication du terminal. Autrement dit, l'entité SGW-C 17 alloue une seule valeur de TEID pour le trafic en liaison montante échangé lors d'une session de communication entre une station de base 14 et une passerelle SGW-D 15 sur l'interface Sl-U, et une seule valeur de TEID pour le trafic en liaison descendante échangé lors d'une session de communication entre la passerelle P-GW 13 et une passerelle SGW-D 15 sur l'interface S5-U.
En d'autres termes, dans le mode de réalisation décrit ici, cette valeur d'identifiant TEID ne change pas (i.e. elle est invariante) si la session de communication est transférée d'une passerelle de transfert de données SGW-D 15 à une autre, par exemple en raison d'une défaillance ou d'une surcharge de la passerelle de transfert de données initialement considérée pour la session.
Par ailleurs, conformément à l'invention, c'est également l'entité SGW-C 17 qui a pour fonction de sélectionner, pour chaque session de communication d'un terminal utilisateur et sur requête du dispositif de contrôle 16 via l'interface de programmation API17, la passerelle de transfert de données parmi les passerelles de transfert de données SGW-D 15 et la passerelle d'interconnexion 13 qui sont utilisées pour le transfert des données entre le terminal utilisateur et les réseaux PDN externes 12.
Dans le mode de réalisation décrit, l'entité SGW-C 17 est configurée pour réaliser cette sélection en prenant en compte l'état courant de la charge des passerelles de transfert de données SGW-D 15. A cet effet, elle utilise des informations représentatives de la charge courante des passerelles de transfert de données S-GW-15 fournies par le dispositif de contrôle 16. Ces informations sont obtenues par le dispositif de contrôle 16 à partir de statistiques de charge périodiques établies à l'aide du protocole OpenFlow mis en œuvre entre le dispositif de contrôle 16 et les passerelles de transfert de données SGW-D 15.
L'obtention en soi de telles statistiques à l'aide du protocole OpenFlow, via le positionnement de compteurs idoines par le dispositif de contrôle 16 au niveau de chaque passerelle de transfert de données SGW-D, ne pose pas de difficultés à l'homme du métier et n'est donc pas décrit plus en détail ici.
Le dispositif de contrôle 16 peut ensuite exploiter aisément les statistiques de charge ainsi obtenues en les comparant aux capacités des passerelles de transfert de données SGW-D et à la qualité de service requise pour la session de communication (représentées par exemple sous forme de quantités ou de seuils prédéterminées), de sorte à évaluer l'état courant de la charge de ces passerelles de transfert de données et mettre en œuvre avec l'entité SGW-C 17 des algorithmes performants d'équilibre de la charge entre les différentes passerelles de transfert de données 15. De tels algorithmes d'équilibre de charge sont connus de l'homme du métier et non détaillés ici.
II convient de noter, que grâce à cette architecture et à cette configuration du dispositif de contrôle 16 et de l'entité logicielle SGW-C 17, les situations de défaillance ou de surcharge d'une passerelle de transfert de données SGW-D active pour une session de communication d'un terminal évoquées précédemment peuvent être gérées de manière transparente pour l'utilisateur de ce terminal.
En effet, lorsque le dispositif de contrôle 16 déclenche la sélection par l'entité SGW-C
17 d'une nouvelle passerelle de transfert de données SGW-D 15 pour servir une session de communication courante, et reçoit de l'entité SGW-C 17 les paramètres de communication destinés à être utilisés par cette passerelle de transfert de données nouvellement sélectionnée et par les stations de base communiquant avec cette passerelle, il n'a qu'à définir des règles de traitement reflétant ces paramètres de communication. Ceci peut être réalisé via la mise à jour de règles de traitement existantes précédemment définies et/ou la création de nouvelles règles de traitement. Ces règles de traitement sont ensuite transmises aux équipements concernés afin d'être stockées dans les tables de flux correspondantes et appliquées pour le traitement des paquets de données reçus par ces équipements. Ainsi l'invention ne nécessite pas de signalisation importante pour permettre le transfert d'une session de communication entre deux passerelles de transfert de données SGW-D du cœur de réseau 10.
Nous allons maintenant illustrer plus en détails la gestion opérée par le cœur de réseau 10 d'une session de communication du terminal utilisateur UE 11 grâce à cette nouvelle architecture. Plus particulièrement, trois procédures sont décrites en référence respectivement aux figures 7 à 9, à savoir :
— une procédure d'attachement du terminal 11 au cœur de réseau 10, — une procédure d'établissement d'un plan de données en liaison montante et en liaison descendante entre une station de base 14 utilisée par le terminal 11 pour communiquer avec le cœur de réseau 10 et une passerelle d'interconnexion 13 connectée aux réseaux externes PDN 12, et
— une procédure de restauration transparente mise en œuvre suite à la détection d'une défaillance de la passerelle de transfert de données S-GW-15 courante utilisée pour la session de communication.
Ces trois procédures reprennent les principales étapes des procédés de contrôle et de sélection selon l'invention dans un mode particulier de réalisation.
La procédure d'attachement illustrée à la figure 7 permet au terminal UE 11 de s'enregistrer auprès du cœur de réseau 10, par exemple suite à la mise sous tension du terminal 11.
A cet effet, le terminal 11 envoie une requête d'attachement « ATTACH REQUEST » à la station de base 14A (étape F10).
La station de base 14A traduit cette requête en un message OpenFlow « PACKET-IN » et le transfère vers le dispositif de contrôle 16 (étape F20).
Le dispositif de contrôle 16 transfère le message OpenFlow reçu vers l'entité de gestion de mobilité 18, via l'interface de programmation API18, pour déclencher une authentification du terminal 11 (en vue de vérifier que le terminal 11 est bien autorisé à accéder aux services gérés par le cœur de réseau 10 et offerts par les réseaux PDN 12). Cette authentification est réalisée par l'entité de gestion de mobilité 18 en interrogeant le serveur HSS du cœur de réseau 10 de façon connue en soi. Elle s'appuie sur la mise en œuvre d'un échange avec le terminal 11 via le dispositif de contrôle 16 (étape F30).
II convient de noter que le protocole OpenFlow, dans sa définition actuelle, ne prévoit pas de messages pour gérer l'authentification d'un terminal et doit donc être adapté de façon idoine pour couvrir cette authentification. Une telle adaptation ne présente pas de difficulté pour l'homme du métier et n'est donc pas décrite davantage ici.
Si le terminal 11 est authentifié avec succès, le dispositif de contrôle 16 déclenche la sélection par l'entité SGW-C 17 :
— d'une passerelle de transfert de données SGW-D parmi les passerelles de transfert de données commandées par le dispositif de contrôle 16 (autrement dit ici, parmi les passerelles de transfert de données 15 A, 15B et 15C) ; et
— d'une passerelle d'interconnexion au réseau PDN (ici, la passerelle d'interconnexion 13) ;
pour le transfert des données échangées lors de la session de communication du terminal 11 (étape F40).
Dans le mode de réalisation décrit ici, la sélection de la passerelle SGW-D est réalisée par l'entité SGW-C 17 via un module de sélection logiciel, à partir d'informations représentatives d'une charge courante de chacune des passerelles SGW-D 15 du cœur de réseau 10 commandées par le dispositif de contrôle 16. Ces informations de charge sont communiquées par le dispositif de contrôle 16 à l'entité SGW-C 17, via l'interface de programmation API17, et dérivées d'informations statistiques de charge collectées par le dispositif de contrôle 16, par l'intermédiaire d'un module d'obtention d'informations statistiques, auprès des passerelles de transfert de données SGW-D 15 via le protocole OpenFlow, comme mentionné précédemment.
On suppose ici que la passerelle de transfert de données SGW-D 15A est sélectionnée par l'entité SGW-C 17.
L'entité SGW-C 17 alloue à ce stade une valeur VI d'identifiant TEID de point d'extrémité de tunnel, pour une session de communication du terminal 11, pour le trafic en liaison descendante sur l'interface entre la passerelle d'interconnexion 13 et la passerelle de transfert de données SGW-D 15A. Cette valeur VI permet l'identification de la terminaison de ce tunnel au niveau de cette passerelle de transfert de données SGW-D 15A.
L'entité SGW-C 17 alloue également une valeur V4 d'identifiant TEID de point d'extrémité de tunnel, pour une session de communication du terminal 11, pour le trafic en liaison montante sur l'interface entre la station de base 14A et la passerelle de transfert de données SGW- D 15A. Cette valeur V4 permet l'identification de la terminaison de ce tunnel au niveau de cette passerelle de transfert de données SGW-D 15A.
Puis, l'entité SGW-C 17 crée une nouvelle entrée dans une table de flux FTAB17 associée au terminal 11 et stockée par exemple dans une mémoire non volatile (ex. dans la mémoire 23 du dispositif informatique 19). La table FTAB17 est similaire ou identique aux tables FTAB décrites précédemment en référence à la figure 4.
Cette nouvelle entrée comprend l'adresse IP de la passerelle de transfert de données S-GW 15A sélectionnée par l'entité SGW-C 17, ainsi que la valeur VI de TEID (paramètres de communication au sens de l'invention destinés à être utilisés lors de la session entre la passerelle d'interconnexion 13 et la passerelle de transfert de données SGW-D 15A dans le plan de données).
L'entité SGW-C 17 fournit ensuite ces paramètres de communication à la passerelle d'interconnexion 13 en lui envoyant une requête de création de session (message « Create Session Request ») comprenant l'adresse IP de la passerelle de transfert de données SGW-D 15A et la valeur VI (étape F50).
Sur réception de cette requête, la passerelle d'interconnexion 13 crée à son tour une nouvelle entrée dans une table de flux maintenue en mémoire pour ce terminal 11 et cette session de communication, contenant les paramètres de communications transmis par l'entité SGW-C 17.
La passerelle d'accès 13 alloue ensuite une valeur V2 d'identifiant TEID, cette valeur V2 permettant l'identification de la terminaison du tunnel au niveau de la passerelle d'accès 13 pour le trafic en sens montant, dans le plan de données, sur l'interface entre cette passerelle d'accès 13 et la passerelle de transfert de données SGW-D 15A (étape F55). Puis elle envoie un message de réponse à l'entité SGW-C 17 (message « Création Session Response »), incluant une adresse IP allouée au terminal 11, ainsi que cette valeur V2 d'identifiant TEID (étape F60).
Sur réception de ce message, l'entité SGW-C 17 met à jour sa table de flux associée au terminal 11 avec les paramètres de communication obtenus de la passerelle P-GW 13 (adresse IP du terminal 11 et valeur V2) (étape F70).
L'entité SGW-C 17 notifie alors au dispositif de contrôle 16, via l'interface de programmation API17, l'adresse IP et la qualité de service allouées au terminal 11.
Le dispositif de contrôle 16 informe l'équipement de gestion de mobilité 18 de l'adresse IP allouée au terminal 11 via l'interface de programmation API18. Cette adresse IP allouée au terminal constitue un paramètre de communication au sens de l'invention destiné à être utilisé lors d'une session de communication entre la station de base 14A, la passerelle de transfert de données SGW-D 15A et la passerelle d'interconnexion 13 pour le transfert de données.
L'équipement de gestion de mobilité 18 inclut cette adresse IP dans un message de réponse « Attach Response Message » et l'envoie au terminal 11 via le dispositif de contrôle 16 (i.e. via l'interface de programmation API18) et la station de base 14 (étape F80).
Après avoir conclu avec succès cette procédure d'attachement, le terminal 11 est autorisé à accéder au cœur de réseau LTE/EPC 10 en utilisant à cet effet l'adresse IP allouée par le cœur de réseau 10.
Nous allons maintenant décrire, en référence à la figure 8, une procédure d'établissement d'un plan de données pour une session de communication du terminal 11, pouvant être mise en œuvre suite à la procédure d'attachement précédemment décrite.
Il convient de noter que l'établissement d'un tel plan de données peut résulter d'une session de communication initiée soit par le terminal 11, soit par le réseau (i.e. cœur de réseau 10 suite à un message reçu en provenance d'un réseau PDN 12).
Session de communication initiée par le terminal 11 :
On suppose ainsi que le terminal 11 envoie un paquet de données « initial » à la station de base 14A.
Sur réception de ce paquet, la station de base 14A vérifie les tables de flux associées au terminal 11 stockées dans sa mémoire (étape G10).
Si aucune entrée des tables de flux ne coïncide avec l'entête du paquet et les champs définis dans ces tables, la station de base 14A envoie un message OpenFlow « PACKET-IN » au dispositif de contrôle 16. Ce message inclut l'entête du paquet initial ainsi qu'une valeur V3 d'identifiant TEID, allouée par la station de base 14A pour le trafic descendant destiné au terminal 11 dans le plan de données sur l'interface entre la station de base 14A et la passerelle SGW-D 15A sélectionnée précédemment pour ce terminal 11 (étape G20). En d'autres termes, cette valeur v3 identifie la terminaison du tunnel au niveau de la station de base 14A pour le trafic en sens descendant, dans le plan de données, sur l'interface entre cette station de base 14A et la passerelle de transfert de données SGW-D 15A.
Le dispositif de contrôle 16 vérifie l'entête du paquet pour identifier l'adresse source à l'origine de ce paquet et le type de session correspondant (ex. transfert FTP, voix sur IP, etc.) (étape G30).
A partir de l'adresse IP source du paquet (i.e. ici l'adresse IP du terminal 11 allouée lors de la procédure d'attachement précédemment décrite), le dispositif de contrôle 16 interroge l'entité SGW-C 17 pour obtenir l'adresse IP de la passerelle SGW-D 15A sélectionnée précédemment pour le terminal 11, stockée dans la table FTAB17. Le dispositif de contrôle 16 récupère également auprès de l'entité SGW-C 17 les valeurs V1,V2 et V4 allouées précédemment lors de l'attachement du terminal 11.
L'identification du type de session associée au paquet permet au dispositif de contrôle 16 de s'assurer que la passerelle SGW-D 15A sélectionnée lors de la procédure d'attachement permet d'offrir au terminal 11 la qualité de service requise pour cette session. Si par exemple, le paquet correspond à une session de type voix sur IP et le dispositif de contrôle 16 détecte que la passerelle de transfert de données 15A sélectionnée est surchargée, il peut décider de déclencher la sélection d'une nouvelle passerelle de transfert de données SGW-D par l'entité SGW-C 17 comme décrit précédemment.
Le dispositif de contrôle 16 crée ensuite un message OpenFlow « PACKET-OUT » et l'envoie à la station de base 14A (étape G40).
Ce message contient une règle de traitement du paquet de données reçu par la station 14A (première règle au sens de l'invention), indiquant le traitement destiné à être appliqué par cette station sur ce paquet (et sur les paquets suivants associés au même flux). Cette règle de traitement est ici une règle de transfert qui indique à la station de base 14A vers quelle passerelle de transfert de données transférer ce paquet, autrement dit qui commande la station de base 14A de sorte que celle-ci transfère le paquet de données reçu vers la passerelle de transfert de données SGW-D 15A.
A cet effet, la règle de traitement transmise par le dispositif de contrôle 16 comprend les paramètres de communication obtenus de l'entité SGW-C 17 par le dispositif de contrôle 16, et destinés à être utilisés lors de la session de communication en liaison montante entre la station de base 14A et la passerelle de transfert de données SGW-D 15A. Ces paramètres de communication comprennent l'adresse IP de la passerelle de transfert de données 15A, et la valeur V4 d'identifiant TEID associée au tunnel de communication sur l'interface destinée à être établie entre la station de base 14A et la passerelle SGW-D 15A pour l'échange de données en liaison montante. La station de base 14A dispose alors des valeurs V3 et V4 identifiant les extrémités du tunnel de communication destiné à être établi sur l'interface entre la passerelle SGW-D 15A et la station de base 14A. De façon similaire, le dispositif de contrôle 16 crée un message OpenFlow « PACKET- OUT » et l'envoie à la passerelle SGW-D 15A (étape G50).
Ce message contient une règle de traitement du paquet initial (reçu par la station de base 14A et destiné à être transféré à la passerelle SGW-D 15A selon la première règle de traitement) indiquant le traitement destiné à être appliqué par la passerelle de transfert de données 15A sur ce paquet (et sur les paquets suivants associés au même flux). Cette règle de traitement (deuxième règle au sens de l'invention) est ici une règle de transfert qui indique à la passerelle SGW-D 15A vers quelle passerelle d'interconnexion transférer ce paquet, autrement dit qui commande la passerelle de transfert de données 15A de sorte que celle-ci transfère le paquet de données initial vers la passerelle d'interconnexion 13.
A cet effet, la règle de traitement transmise par le dispositif de contrôle 16 à la passerelle SGW-D 15A comprend les paramètres de communication obtenus de l'entité SGW-C 17 par le dispositif de contrôle 16, et destinés à être utilisés en liaison montante lors de la session de communication entre la passerelle SGW-D 15A et la passerelle d'interconnexion 13. Ces paramètres incluent l'adresse IP de la passerelle d'interconnexion 13, et les valeurs VI et V2 d'identifiant TEID allouées aux extrémités du tunnel destiné à être établi sur l'interface entre la passerelle SGW-D 15A et la passerelle d'interconnexion 13.
Dans le mode de réalisation décrit ici, le message OpenFlow « PACKET-OUT » contient également une règle de traitement destinée à être appliquée par la passerelle de transfert de données SGW-D 15A en liaison descendante sur le trafic destiné au terminal 11 associé à la session de communication.
Cette règle de traitement est ici une règle de transfert qui indique à la passerelle de transfert de données 15A vers quelle station de base de base transférer les paquets relatifs à la session de communication et destinés au terminal 11. Autrement dit cette règle de traitement commande la passerelle SGW-D 15A de sorte que celle-ci transfère les paquets de données reçus vers la station de base 14A.
A cet effet, cette règle de traitement comprend les paramètres de communication obtenus par le dispositif de contrôle 16 et destinés à être utilisés en liaison descendante entre la passerelle SGW-D 15A et la station de base 14A lors de la session de communication, à savoir l'adresse IP de la station de base 14A et les valeurs V3 et V4 d'identifiant TEID d'identifiant TEID allouées aux extrémités du tunnel destiné à être établi sur l'interface entre la passerelle SGW-D 15A et la station de base 14A.
A l'issue de cette procédure, un premier tunnel de communication, typiquement GTP- U, est établi en liaisons montante et descendante pour l'interface (par exemple de type Sl-U) entre la station de base 14A et la passerelle de transfert de données SGW-D 15A, les valeurs V3,V4 d'identifiant TEID étant insérées dans les paquets GTP transmis dans ce premier tunnel. En outre, un deuxième tunnel de communication, typiquement GTP-U, est établi en liaisons montante et descendante pour l'interface (par exemple de type S5-U) entre la passerelle de transfert de données SGW-D 15A et la passerelle d'interconnexion 13 (étape G60), les valeurs V1,V2 d'identifiant TEID étant insérées dans les paquets GTP transmis dans ce deuxième tunnel.
Session de communication Initiée par le cœur de réseau 10 (non représentée sur la figure 8) :
On suppose ici que l'établissement du plan de données est déclenché par l'arrivée d'un paquet de données « initial » destiné au terminal 11 au niveau de la passerelle d'interconnexion 13 du cœur de réseau 10.
A partir de la table de flux FTAB13 associée au terminal 11 maintenue par la passerelle d'interconnexion 13 suite à la procédure d'attachement du terminal 11, la passerelle d'interconnexion 13 détermine que ce paquet doit être envoyé à la passerelle de transfert de données SGW-D 15A (vers l'adresse IP spécifiée dans la table).
Sur réception de ce paquet, la passerelle de transfert de données SGW-D 15A consulte les tables de flux FTAB15 stockées dans sa mémoire volatile pour identifier si une entrée coïncide avec l'entête du paquet reçu pour le terminal 11.
Si ce n'est pas le cas, la passerelle de transfert de données SGW-D 15A envoie un message OpenFlow PACKET-IN au dispositif de contrôle 16.
Le dispositif de contrôle 16 détermine la localisation du terminal 11 en interrogeant l'entité de gestion de mobilité 18 via l'interface de programmation API18, et identifie une station de base 14 appropriée pour transmettre le paquet destiné au terminal 11. En l'espèce ici, on suppose que c'est la station de base 14A qui est identifiée.
Le dispositif de contrôle 16 envoie à la station de base 14A un message OpenFlow
PACKET-OUT comprenant une règle de traitement (première règle de traitement au sens de l'invention) destinée à être appliquée par celle-ci sur réception de paquets de données du terminal
11 relatifs à la session de communication en cours.
Cette règle de traitement comprend l'adresse IP de la passerelle de transfert de données SGW-D 15A ainsi que la valeur V4 d'identifiant TEID allouée par l'entité SGW-C 17 à la passerelle SGW-D 15A pour le trafic montant de ce terminal 11 dans le plan de données, sur l'interface entre cette station de base 14A et la passerelle de transfert de données SGW-D 15A.
La station de base 14A établit le canal radio avec le terminal 11, et répond au dispositif de contrôle 16 en lui envoyant un message OpenFlow contenant la valeur V3 de l'identifiant TEID alloué par la station de base 14A pour le trafic descendant destiné au terminal 11 dans le plan de données, toujours sur l'interface entre cette station de base 14A et la passerelle de transfert de données SGW-D 15A.
Il convient de noter que le protocole OpenFlow dans sa version actuelle n'inclut pas de message permettant à la station de base 14A d'envoyer la valeur V3 au dispositif de contrôle 16 et doit être adapté de façon idoine. Cette adaptation ne présente aucune difficulté pour l'homme du métier. Sur réception de ce message, le dispositif de contrôle 16 envoie une règle de traitement (deuxième règle de traitement au sens de l'invention) à la passerelle de transfert de données SGW-D 15A contenant l'adresse IP de la station de base 14A et les valeurs V3 et V4 de TEID. Ces paramètres sont des paramètres de communication destinés à être utilisés pour transférer le trafic en liaison descendante entre la passerelle SGW-D 15A et la station de base 14A lors de la session de communication.
Nous allons maintenant décrire en référence à la figure 9 une procédure de restauration pouvant avantageusement être mise en œuvre par le cœur de réseau 10 grâce à l'architecture proposée par l'invention, en cas de défaillance d'une passerelle de transfert de données SGW-D impliquée dans la session de communication du terminal 11. Une procédure similaire peut également être utilisée lorsque le dispositif de contrôle 16 détecte une surcharge d'une passerelle de transfert de données SGW-D impliquée dans la session de communication du terminal 11.
Pour illustrer cette procédure, on se place ici à l'issue de la procédure d'établissement d'un plan de données (étape G60) décrite précédemment en référence à la figure 8. Ce plan de données s'appuie ainsi sur deux tunnels bidirectionnels GTP-U établis respectivement entre la station de base 14A et la passerelle de transfert de données SGW-D 15A, et entre la passerelle de transfert de données SGW-D 15A et la passerelle d'interconnexion 13 pour la session de communication en cours du terminal 11.
On suppose maintenant que la passerelle de transfert de données SGW-D 15A connaît une défaillance (étape H10).
Le dispositif de contrôle 16 dispose d'un module logiciel apte à détecter, en utilisant le protocole OpenFlow, une défaillance d'une des passerelles de transfert de données SGW-D 15 qu'il commande. Plus précisément, conformément à ce protocole, le dispositif de contrôle 16 et les passerelles de transfert de données SGW-D 15 s'échangent périodiquement des messages de type « Echo Request/Reply ». La détection de l'absence de réponse de la passerelle de transfert de données SGW-D 15A à un tel message permet au dispositif de contrôle 16 d'identifier qu'un problème affecte cette passerelle (étape H20).
Sur détection de cette défaillance, le dispositif de contrôle 16 déclenche, par l'intermédiaire de l'interface de programmation API17, la sélection par l'entité SGW-C 17 d'une nouvelle passerelle de transfert de données pour la session de communication du terminal 11 (et pour chaque session de communication de manière plus générale impactées par cette défaillance), comme décrit précédemment pour la passerelle SGW-D 15A en prenant en compte la charge courante des passerelles de transfert de données SGW-D 15. On suppose par exemple que la passerelle SGW-D 15B est ainsi sélectionnée.
L'entité SGW-C 17 envoie un message « Modify Bearer Request » à la passerelle d'interconnexion 13 pour l'informer de cette nouvelle sélection (via une interface « E/W Bound » telle que décrite en référence à la figure 3) (étape H30). Ce message comprend l'adresse IP de la nouvelle passerelle de transfert de données SGW-D 15B. La valeur VI d'identifiant TEID du tunnel GTP-U pour la liaison descendante reste invariante malgré le changement de passerelle de transfert de données pour chaque session de communication.
La passerelle d'interconnexion 13 met à jour la table FTAB13 associée au terminal 11 et à la session de communication avec l'adresse IP de la passerelle SGW-D 15B et envoie un message « Modify Bearer Response » à l'entité SGW-C 17 (étape H40).
Le dispositif de contrôle 16 envoie ensuite, par le biais de son module de contrôle 16A, un message OpenFlow « MODIFY-STATE » à la station de base 14A pour mettre à jour l'adresse de la passerelle de transfert de données SGW-D associée à la session de communication du terminal 11 dans la table FTAB14. Ce message constitue une mise à jour par le module 16A du dispositif de contrôle 16 de la règle de traitement appliquée par la station de base 14A et contient de nouveaux paramètres de communication (en l'occurrence, l'adresse IP de la passerelle de transfert de données SGW-D 15B) obtenus de l'entité SGW-C 17 et destinés à être utilisés entre la station de base 14A et la passerelle de transfert de données SGW-D 15B lors de la session de communication.
En revanche, la valeur V4 d'identifiant TEID de tunnel destinée à être par la station de base 14A pour la liaison montante sur l'interface avec la nouvelle passerelle de transfert de données SGW-D 15B reste inchangée. Par ailleurs, la station de base 14A ne changeant pas, la valeur V3 reste inchangée.
Autrement dit, l'invention, en centralisant au niveau de l'entité SGW-C 17 l'allocation des identifiants TEID pour les tunnels de communication du plan de données établis avec les passerelles de transfert de données SGW-D 15, permet de s'affranchir de l'allocation de nouveaux identifiants TEID lorsque la passerelle de transfert de données active change et de la communication de ces nouveaux identifiants aux équipements du réseau amenés à établir un tunnel avec cette passerelle de transfert de données. La signalisation requise pour notifier le changement de passerelle de transfert de données est ainsi avantageusement limitée : seule l'adresse IP de la nouvelle passerelle de transfert de données nécessite d'être notifiée par le dispositif de contrôle 16.
Le dispositif de contrôle 16 envoie ensuite, par l'intermédiaire de son module de contrôle 16B, un message OpenFlow « PACKET-OUT » à la nouvelle passerelle de transfert de données SGW-D 15B, contenant une règle de traitement (troisième règle de traitement au sens de l'invention) destinée à être appliquée par la passerelle de transfert de données SGW-D 15B en liaison montante sur réception de données relatives à la session de communication du terminal 11 (étape H60).
Cette règle de traitement est ici une règle de transfert qui indique à la passerelle de transfert de données SGW-D 15B vers quelle passerelle d'interconnexion transférer les paquets relatifs à la session de communication et reçus du terminal 11. Autrement dit cette règle de traitement commande la passerelle de transfert de données SGW-D 15B de sorte que celle-ci transfère les paquets de données reçus vers la passerelle d'interconnexion 13.
Cette règle de traitement comprend des paramètres de communication obtenus de l'entité SGW-C 17 destinés à être utilisés en liaison montante entre la passerelle de transfert de données SGW-D 15B et la passerelle d'interconnexion 13 lors de la session de communication. Ces paramètres de communication incluent notamment l'adresse IP de la passerelle d'interconnexion 13, et la valeur V2 de TEID allouée par la passerelle d'interconnexion 13 à la session du terminal 11. Ils sont mémorisés dans une table de flux FTAB15 stockés par la passerelle de transfert de données SGW-D 15B en association avec la session de communication du terminal 11.
Le message « PACKET-OUT » comprend en outre une autre règle de traitement destinée à être appliquée par la passerelle de transfert de données SGW-D 15B en liaison descendante sur le trafic destiné au terminal 11 associé à la session de communication.
Cette règle de traitement est ici une règle de transfert qui indique à la passerelle de transfert de données SGW-D 15B vers quelle station de base transférer les paquets relatifs à la session de communication et destinés au terminal 11. Autrement dit cette règle de traitement commande la passerelle de transfert de données SGW-D 15B de sorte que celle-ci transfère les paquets de données reçus vers la station de base 14A. A cet effet, cette règle de traitement comprend les paramètres de communication obtenus par le dispositif de contrôle 16 et destinés à être utilisés en liaison descendante entre la passerelle de transfert de données SGW-D 15B et la station de base 14A lors de la session de communication, à savoir l'adresse IP de la station de base 14A et la valeur V3 d'identifiant TEID.
A l'issue de cette procédure, un tunnel de communication GTP-U est établi en liaisons montante et descendante pour l'interface (typiquement de type Sl-U) entre la station de base 14A et la nouvelle passerelle de transfert de données SGW-D 15B, et un tunnel de communication GTP- U est établi en liaisons montante et descendante pour l'interface (typiquement de type S5-U) entre cette nouvelle passerelle de transfert de données SGW-D 15B et la passerelle d'interconnexion 13 (étape H70).
Comme mentionné précédemment, cette procédure peut être aisément appliquée pour gérer également une situation de surcharge de la passerelle de transfert de données SGW-D 15A. Une telle situation peut être détectée par le dispositif de contrôle 16 à partir des statistiques de charge qu'il collecte en temps réel à l'aide du protocole OpenFlow auprès des passerelles de transfert de données SGW-D 15 qu'il gère.
Grâce à la connaissance en temps réel de ces statistiques, le dispositif de contrôle 16 peut déclencher un changement de passerelle de transfert de données SGW-D selon la procédure décrite en référence à la figure 9, afin d'équilibrer la charge résultant des sessions de communication actives des terminaux sur les différentes passerelles de transfert de données SGW- D 15. A cette fin, des algorithmes de répartition ou d'équilibre de la charge connus en soi (algorithmes de « load balancing ») peuvent être utilisés par le dispositif de contrôle 16 pour permettre à l'entité SGW-C 7 de sélectionner une nouvelle passerelle de transfert de données pour la session du terminal 11.
Le transfert d'une passerelle de transfert de données à une autre de la session de communication est alors mis en œuvre de manière similaire à celle décrite en référence à la figure 9, autrement dit de façon transparente pour la connectivité IP de l'utilisateur.

Claims

REVENDICATIONS
1. Dispositif de contrôle (16) d'un cœur de réseau IP (10) comprenant :
— un module de communication apte à communiquer avec une entité de contrôle de transfert de données (17) du cœur de réseau IP, et configuré pour déclencher la sélection par l'entité de contrôle de transfert de données d'une passerelle de transfert de données (15A) du cœur de réseau IP, le module de communication étant en outre configuré pour obtenir de l'entité de contrôle de transfert de données des paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal (11), connecté à une station de base (14A) d'un réseau d'accès, et une passerelle d'interconnexion (13) du cœur de réseau IP connecté à un réseau de paquets de données (12), ladite session de communication transitant par la station de base et la passerelle de transfert de données ;
— un premier module de contrôle (16A) de la station de base au moyen d'une première règle de traitement destinée à être appliquée par ladite station de base suite à la réception de données relatives à la session de communication, la première règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base (14A) et la passerelle de transfert de données (15A) ; et
— un deuxième module de contrôle (16B) de la passerelle de transfert de données au moyen d'une deuxième règle de traitement destinée à être appliquée par ladite passerelle de transfert de données suite à la réception de données relatives à la session de communication, la deuxième règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données (15A) et la passerelle d'interconnexion (13).
2. Dispositif de contrôle (16) selon la revendication 1 dans lequel le module de communication communique avec l'entité de contrôle de transfert de données par l'intermédiaire d'une interface de programmation (API17).
3. Dispositif de contrôle (16) selon la revendication 1 ou 2 dans lequel :
— les paramètres de communication de la première règle comprennent une adresse de la passerelle de transfert de données (15A) et un identifiant de point d'extrémité d'un tunnel de communication établi entre la passerelle de transfert de données et la station de base pour le transfert des données, alloué par l'entité de contrôle de transfert de données ; et/ou
— les paramètres de communication de la deuxième règle comprennent une adresse de la passerelle d'interconnexion (13) et un identifiant de point d'extrémité d'un tunnel de communication établi entre la passerelle de transfert de données et la passerelle d'interconnexion pour le transfert des données, alloué par l'entité de contrôle de transfert de données.
4. Dispositif de contrôle (16) selon l'une quelconque des revendications 1 à 3 dans lequel le premier module de contrôle (16A) et le deuxième module de contrôle (16B) sont configurés pour communiquer respectivement avec la station de base et avec la passerelle de transfert de données par l'intermédiaire du protocole OpenFlow.
5. Dispositif de contrôle (16) selon l'une quelconque des revendications 1 à 4 dans lequel le module de communication est en outre configuré pour déclencher, par l'intermédiaire d'une interface de programmation (API18), sur réception d'une requête d'attachement du terminal au cœur de réseau IP, une authentification du terminal par une entité (18) de gestion de la mobilité appartenant au cœur de réseau IP.
6. Dispositif de contrôle selon l'une quelconque des revendications 1 à 5 comprenant en outre un module d'obtention d'informations représentatives d'une charge courante d'au moins une passerelle de transfert de données du cœur de réseau IP connectée au dispositif de contrôle, le module de communication étant en outre configuré pour fournir lesdites informations à l'entité de contrôle de transfert de données, via une interface de programmation (API 17).
7. Dispositif de contrôle selon l'une quelconque des revendications 1 à 6 comprenant en outre un module de détection d'une défaillance ou d'une surcharge de la passerelle de transfert de données, le module de communication étant en outre configuré pour informer l'entité de contrôle de transfert de données de ladite défaillance ou de ladite surcharge et pour déclencher la sélection par l'entité de contrôle de transfert de données d'une nouvelle passerelle de transfert de données (15B) pour la session de communication, et dans lequel :
— le premier module de contrôle est configuré pour mettre à jour la première règle de traitement appliquée par la station de base avec des paramètres de communication, obtenus de l'entité de contrôle de transfert de données par le module de communication du dispositif de contrôle et destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base (14A) et la nouvelle passerelle de transfert de données (15B) ; et
— le deuxième module de contrôle est configuré pour contrôler la nouvelle passerelle de transfert de données (15B) à l'aide d'une troisième règle de traitement destinée à être appliquée par ladite nouvelle passerelle de transfert de données suite à la réception de données relatives à la session de communication, la troisième règle comprenant des paramètres de communication, obtenus de l'entité de contrôle de transfert de données par le module de communication du dispositif de contrôle et destinés à être utilisés lors de la session de communication pour le transfert de données entre la nouvelle passerelle de transfert de données (15B) et la passerelle d'interconnexion (13).
8. Dispositif de contrôle selon la revendication 7, dans lequel la première règle de traitement est mise à jour avec une adresse de la nouvelle passerelle de transfert de données
(15B).
9. Dispositif de contrôle selon la revendication 7, dans lequel les paramètres de communication de la deuxième règle de traitement et de la troisième règle de traitement comprennent un même identifiant de point d'extrémité de tunnel, alloué par l'entité de contrôle de transfert de données et destiné à être utilisé entre la passerelle de transfert de données (15A) et la passerelle d'interconnexion (13), et entre la nouvelle passerelle de transfert de données (15B) et la passerelle d'interconnexion (13).
10. Entité de contrôle de transfert de données (17) d'un cœur de réseau IP (10) comprenant :
— un module de communication apte à communiquer avec un dispositif de contrôle (16) du cœur de réseau IP selon l'une quelconque des revendications 1 à 9 ;
— un module de sélection, déclenché par le dispositif de contrôle (16) via le module de communication, et configuré pour sélectionner une passerelle de transfert de données (15A) du cœur de réseau IP ;
— un module d'obtention de paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal (11), connecté à une station de base (14A) d'un réseau d'accès, et une passerelle d'interconnexion (13) du cœur de réseau IP connectée à un réseau de paquets de données (12), ladite session de communication transitant par la station de base et la passerelle de transfert de données ;
— un module de fourniture à la passerelle d'interconnexion de paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données (15A) et la passerelle d'interconnexion (13) ;
le module de communication étant configuré pour fournir au dispositif de contrôle des paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base (14A) et la passerelle de transfert de données (15A).
11. Entité selon la revendication 10, dans laquelle le module d'obtention de paramètres de communication est configuré pour allouer à la session de communication un identifiant de point d'extrémité d'un tunnel de communication entre la passerelle de transfert de données (15A) et la station de base (14A) et un identifiant de point d'extrémité d'un tunnel de communication entre la passerelle de transfert de données (15A) et la passerelle d'interconnexion (13).
12. Entité selon la revendication 11, dans laquelle les identifiants alloués par l'entité à la session de communication sont invariants durant la session de communication.
13. Entité selon l'une quelconque des revendication 10 à 12 dans laquelle le module de sélection est configuré pour sélectionner la passerelle de transfert de données (15A) parmi une pluralité de passerelles de transfert de données (15A,15B,15C) contrôlées par le dispositif de contrôle en utilisant des informations représentatives d'une charge courante desdites passerelles de transfert de données fournies par le dispositif de contrôle via une interface de programmation.
14. Entité selon l'une quelconque des revendications 10 à 13 dans laquelle :
— le module de sélection est configuré pour sélectionner une nouvelle passerelle de transfert de données (15B) pour la session de communication du terminal lorsqu'il est informé par le dispositif de contrôle, via une interface de programmation, d'une défaillance ou d'une surcharge de la passerelle de transfert de données (15A) ;
— le module de fourniture et le module de communication sont configurés pour fournir respectivement à la passerelle d'interconnexion (13) et au dispositif de contrôle (16) ladite adresse de la nouvelle passerelle de transfert de données (15B).
15. Cœur de réseau IP (10) comprenant :
— une pluralité de passerelles de transfert de données (15A,15B,15C) ;
— un dispositif de contrôle (16) selon l'une quelconque des revendications 1 à 9, apte à contrôler au moins une station de base (14A) d'un réseau d'accès auquel est connecté un terminal et la pluralité de passerelles de transfert de données ; et
— une entité de contrôle de transfert de données (17) selon l'une quelconque des revendications 10 à 14, apte à communiquer avec le dispositif de contrôle, et à sélectionner une passerelle de transfert de données (15A) parmi la pluralité de passerelles de transfert de données contrôlées par le dispositif de contrôle pour une session de communication du terminal.
16. Cœur de réseau IP (10) selon la revendication 15, comprenant en outre une entité (18) de gestion de la mobilité configurée pour authentifier le terminal, ladite authentification étant déclenchée par le dispositif de contrôle via une interface de programmation.
17. Procédé de contrôle destiné à être mis en œuvre par un dispositif de contrôle (16) d'un cœur de réseau IP, et comprenant : — une étape de communication avec une entité de contrôle de transfert de données (17) du cœur de réseau IP, comprenant un déclenchement d'une sélection (F40) par l'entité de contrôle de transfert de données d'une passerelle de transfert de données (15A) du cœur de réseau IP, et une obtention auprès de l'entité de contrôle de transfert de données de paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal connecté à une station de base (14A) d'un réseau d'accès et une passerelle d'interconnexion (13) du cœur de réseau IP connectée à un réseau de paquets de données (12), ladite session de communication transitant par la station de base et la passerelle de transfert de données ;
— une étape de contrôle (G40) de la station de base au moyen d'une première règle de traitement destinée à être appliquée par ladite station de base suite à la réception de données relatives à la session de communication, la première règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base (14A) et la passerelle de transfert de données (15A) ; et
— une étape de contrôle (G50) de la passerelle de transfert de données au moyen d'une deuxième règle de traitement destinée à être appliquée par ladite passerelle de transfert de données suite à la réception de données relatives à la session de communication, la deuxième règle comprenant des paramètres, parmi les paramètres de communication obtenus de l'entité de contrôle de transfert de données, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données (15A) et la passerelle d'interconnexion (13).
18. Procédé de sélection destiné à être mis en œuvre par une entité de contrôle de transfert de données (17) d'un cœur de réseau IP, et comprenant :
— une étape de sélection (F40), déclenchée par un dispositif de contrôle (16) du cœur de réseau IP, d'une passerelle de transfert de données (15A) du cœur de réseau IP ;
— une étape d'obtention de paramètres de communication destinés à être utilisés lors d'une session de communication entre un terminal (11) connecté à une station de base (14A) d'un réseau d'accès et une passerelle d'interconnexion (13) du cœur de réseau IP connectée à un réseau de paquets de données (12), ladite session de communication transitant par la station de base et la passerelle de transfert de données ;
— une étape de fourniture
o à ladite passerelle d'interconnexion (50), de paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la passerelle de transfert de données (15A) et la passerelle d'interconnexion (13) ; et o au dispositif de contrôle (16), de paramètres de communication, parmi les paramètres de communication obtenus, destinés à être utilisés lors de la session de communication pour le transfert de données entre la station de base (14A) et la passerelle de transfert de données (15A).
19. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de contrôle selon la revendication 17 ou du procédé de sélection selon la revendication 18 lorsque ledit programme est exécuté par un ordinateur.
20. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de contrôle selon la revendication 17 ou du procédé de sélection selon la revendication 18.
21. Station de base d'un réseau d'accès (14A), apte à servir un terminal (11) lors d'une session de communication, et comprenant :
— des moyens de réception d'un dispositif de contrôle d'un cœur de réseau IP selon l'une quelconque des revendications 1 à 9 d'une règle de traitement destinée à être appliquée par la station de base suite à la réception de données relatives à ladite session de communication du terminal, la règle de traitement comprenant des paramètres de communication destinés à être utilisés lors de ladite session de communication pour le transfert de données entre la station de base et une passerelle de transfert de données (15A) du cœur de réseau IP ; et
— des moyens d'application de cette règle de traitement à des données relatives à ladite session de communication.
PCT/FR2014/051210 2013-05-24 2014-05-22 Dispositif et procede de controle d'un coeur de reseau ip Ceased WO2014188136A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1354720 2013-05-24
FR1354720A FR3006140A1 (fr) 2013-05-24 2013-05-24 Dispositif et procede de controle d'un cœur de reseau ip

Publications (1)

Publication Number Publication Date
WO2014188136A1 true WO2014188136A1 (fr) 2014-11-27

Family

ID=49003867

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2014/051210 Ceased WO2014188136A1 (fr) 2013-05-24 2014-05-22 Dispositif et procede de controle d'un coeur de reseau ip

Country Status (2)

Country Link
FR (1) FR3006140A1 (fr)
WO (1) WO2014188136A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3031425A1 (fr) * 2015-01-05 2016-07-08 Orange Dispositif et procede de controle d'un coeur de reseau ip

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"Technical Specification Group Core Network and Terminals ; Restoration procedures", 3GPP TS 23.007
J. KEMPF ET AL.: "Moving the Mobile Evolved Packet Core to the Cloud", 5TH INTERNATIONAL WORKSHOP ON SELECTED TOPICS IN MOBILE AND WIRELESS COMPUTING, 2012
KEMPF J ET AL: "Moving the Mobile Evolved Packet Core to the Cloud", 2012 IEEE 8TH INTERNATIONAL CONFERENCE ON WIRELESS AND MOBILE COMPUTING, NETWORKING AND COMMUNICATIONS (WIMOB 2012) : BARCELONA, SPAIN, 8 - 10 OCTOBER 2012, IEEE, PISCATAWAY, NJ, 8 October 2012 (2012-10-08), pages 784 - 791, XP002717394, ISBN: 978-1-4673-1430-5 *
MEVICO: "Architectural EPC extensions for supporting heterogeneous mobility schemes", 31 January 2013 (2013-01-31), XP055101257, Retrieved from the Internet <URL:http://www.mevico.org/D22.pdf> [retrieved on 20140210] *
OPENFLOW SWITCH SPECIFICATION, VERSION 1.3.1, September 2012 (2012-09-01)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3031425A1 (fr) * 2015-01-05 2016-07-08 Orange Dispositif et procede de controle d'un coeur de reseau ip
WO2016110632A1 (fr) * 2015-01-05 2016-07-14 Orange Dispositif et procédé de contrôle d'un cœur de réseau ip
US10506493B2 (en) 2015-01-05 2019-12-10 Orange Device and a method for controlling an IP core network

Also Published As

Publication number Publication date
FR3006140A1 (fr) 2014-11-28

Similar Documents

Publication Publication Date Title
EP3189430B1 (fr) Dispositifs, programme d&#39;ordinateur, support d&#39;enregistrement lisible par un ordinateur et procédé de contrôle d&#39;un coeur de réseau ip
CN106464708B (zh) 针对符合条件的包通过隧道传输和接收数据的方法和系统
EP1267530B1 (fr) Procédé de transmission de paquets IP à travers un système cellulaire de radiocommunication, et equipements du système cellulaire pour la mise en oeuvre de ce procédé
WO2017220893A1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
EP3243347B1 (fr) Dispositif et procédé de contrôle d&#39;un c ur de réseau ip
WO2005029787A1 (fr) Procede de differenciation de la qualite de service dans les reseaux de communication mobile en mode paquets
EP3841729B1 (fr) Réseautage axé sur les informations sur des réseaux 5g ou ultérieurs
EP3017567B1 (fr) Dispositif de contrôle d&#39;un coeur de réseau ip et procédé de commande mis en oeuvre par ce dispositif
EP3105894B1 (fr) Procédé de contrôle par anticipation des flux de données par un réseau sdn en cas de défaillance d&#39;un routeur, disposif, programme d&#39;ordinateur et support d&#39;enregistrement
WO2014188136A1 (fr) Dispositif et procede de controle d&#39;un coeur de reseau ip
EP3539318B1 (fr) Equipement mandataire dans un système de télécommunication cellulaire
EP3366069B1 (fr) Passerelle résidentielle hybride
EP2399406A1 (fr) Procede de commutation de noeud d&#39;acces
WO2020120850A1 (fr) Terminal pouvant être connecté simultanément à plusieurs réseaux d&#39;accès, procédé de différentiation de trafic émis par le terminal, dispositif et procédé de gestion du trafic
FR3079995A1 (fr) Equipement orchestrateur dans un systeme de telecommunication cellulaire
EP2827639B1 (fr) Procédé de gestion d&#39;au moins une connexion virtuelle dynamique entre un terminal mobile et un réseau de communication, et réseau de communication associé
FR3154268A1 (fr) Procédés de vérification, de gestion, de contrôle, d’exécution d’une vérification de l’accessibilité d’un équipement, équipement, serveur de contrôle, contrôleur réseau, entité relais et programme d’ordinateur correspondants.
WO2020120884A1 (fr) Selection d&#39;un réseau en fonction de caractéristiques réseau temps réel

Legal Events

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

Ref document number: 14731712

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: 14731712

Country of ref document: EP

Kind code of ref document: A1