WO2014188136A1

WO2014188136A1 - Device and method for controlling an ip core network

Info

Publication number: WO2014188136A1
Application number: PCT/FR2014/051210
Authority: WO
Inventors: Malla Reddy SAMA; Siwar BEN HADJ SAID; Karine Guillouard; Lucian Suciu
Original assignee: Orange
Priority date: 2013-05-24
Filing date: 2014-05-22
Publication date: 2014-11-27
Also published as: FR3006140A1

Abstract

The control device (16) comprises: - a communication module communicating with a control entity for controlling data transfer (17) in order to trigger the selection by this entity of a data transfer gateway (15A) and obtain, from same, communication parameters to use during a communication session between a terminal (11) connected to a base station (14A) and an interconnect gateway (13) connected to a PDN network (12); - a control module (16A) for controlling the base station via a processing rule to apply to data related to the session and comprising communication parameters to use during the session between the base station and the transfer gateway; and - a control module (16B) for controlling the transfer gateway via a processing rule to apply to data related to the session and comprising communication parameters to be used during the session between the transfer gateway and the interconnect gateway.

Description

Device and method for controlling an IP core network

Background rinenvention

The invention relates to the general field of telecommunications. It relates more particularly to an architecture of core network 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.

An exponential increase in mobile telecommunications traffic is expected in the coming years, boosted by the emergence of new applications, new terminals and communication rates of higher and higher.

In this context, 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) capable of offering this terminal various communication services, such as 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.

In the current LTE / EPC architecture, a failure of a core network equipment is very constraining for the operator managing this core network because it is likely to cause an interruption of the service offered by this operator. To better illustrate this point, 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. As an indication, the planned exchanges between these devices for the transfer of data (ie in the plan of data or user plane) are modeled by solid lines, while the signaling exchanges provided between these devices to support these data transfers (ie in the control or signaling plan) are modeled by discontinuous lines.

More specifically in FIG. 1, 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. For this purpose, the core network EPC 1 comprises four types of equipment, namely:

A data transfer gateway 5, otherwise called S-GW gateway (for "Serving GateWay"), located between the access network and the core network 1;

An interconnection gateway 6, otherwise called gateway P-GW (for "PDN GateWay"), for connecting the core network 1 to the external network 4 of data packets;

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-

GW 5 via a SU interface. The data transfer gateway S-GW 5 is connected to the interconnection gateway P-GW 6 via an interface S5. 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; and

- the GTP-C protocol used to establish, update and maintain the GTP communication tunnels. Thus, 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.

In a manner known per se, 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. Thus, in the example illustrated in FIG. 1, 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.

According to the current definition of the LTE / EPC architecture, when an equipment of the core network 1, such as for example the data transfer gateway S-GW 5, is suddenly defective, the current communication sessions managed by this equipment are automatically interrupted. The 3GPP standard then provides for the use of a restoration procedure described in 3GPP TS 23.007 entitled "Technical Specification Group Core Network and Terminals; Restoration procedures ", Release 10, and schematically illustrated in Figure 2.

According to this procedure, 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. 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).

Then, 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). However, for this purpose, according to the 3GPP standard, 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. In other words, 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.

Furthermore, 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.

Other situations in which the LTE / EPC architecture as currently defined by the 3GPP consortium has certain shortcomings can be envisaged.

Thus, by way of illustration, the popularity of users for bandwidth-intensive applications such as downloading videos generates particularly unpredictable traffic that can create bottlenecks and / or congestion in the data plan of the heart. LTE / EPC networks, typically at S-GW data transfer gateways, eNB base stations and P-GW gateways.

To solve this problem, it is possible to use load balancing techniques between core network equipment, also known as load balancing techniques.

In the current state of the standard, and as previously described, 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. The weight that the DNS server associates with a gateway depends on its capacity relative to concurrent gateways serving the same region. Thus, 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. However, 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.

In addition, the standard today does not specify any mechanism for transparently transferring ongoing communication sessions from one data transfer gateway to another. As previously illustrated, 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.

The two situations described above show that the close coupling of the data plane and the control plane within one and the same core network entity (typically within the same S-GW data transfer gateway) as in FIG. it is currently envisaged in the LTE / EPC architecture defined by the 3GPP induces strong constraints when it is desired to make this architecture more flexible or more reliable in terms of IP connectivity for users.

The document by 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, proposes an evolution of the LTE / EPC backbone architecture defined by the 3GPP consortium, in which Data and control plans are separated, and that uses the software-defined network principle, more commonly known as SDN for "Software Defined Networking".

In a known manner, 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). For this purpose, 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.

The document by 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.

However, 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.

Moreover, the document by J. Kempf et al. does not describe any other restoration procedure that can be implemented in the event of a failure or overloading of an S-GW data transfer gateway as defined by the 3GPP consortium and recalled above.

Therefore, the solution proposed by J. Kempf et al., While offering the possibility of simplifying the maintenance and configuration of backbone equipment, does not improve the end-user experience in critical situations previously considered (failure or overload of a data transfer gateway).

Object and summary of the invention

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; and

A second control module of the data transfer gateway by means of a second processing rule intended to be applied by this data transfer gateway following the reception of data relating to the communication session, the second rule comprising parameters, among the communication parameters obtained from the data transfer control entity, for use in the communication session for the transfer of data between the data transfer gateway and the interconnection gateway. Correlatively, 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;

A step of controlling 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; and

A step of controlling the data transfer gateway by means of a second processing rule intended to be applied by this data transfer gateway following the reception of data relating to the communication session, the second rule comprising parameters, among the communication parameters obtained from the data transfer control entity, for use in the communication session for the transfer of data between the data transfer gateway and the interconnection gateway.

By 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.).

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.

More precisely, it proposes to control, by means of 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.

According to the invention, the 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.

These processing rules are for example data transfer rules. Thus, in a particular embodiment of the invention:

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.

Thanks to the decoupling proposed by the invention, and more precisely by centralizing at the level of the control device the selection of the data transfer gateways involved in the communication session, 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. In such a context, it 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).

Thus, contrary to the state of the art described in the document by J. Kempf et al., 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.

In a particular embodiment of the invention, the communication module communicates with the data transfer control entity via a programming interface.

In another particular embodiment, 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.

The use of the OpenFlow protocol facilitates the implementation of the invention. In addition, 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.

Thus, in a particular embodiment, the 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.

In another embodiment of the invention, 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.

Thus, in this embodiment, 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.

In another embodiment of the invention, the 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; and

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.

For example, the first processing rule is updated with an address of the new data transfer gateway.

In addition, 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.

In other words, 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. .

In order to enable the decoupling of the control and data planes, 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.

Thus, 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;

A module for obtaining communication parameters intended to be used during a communication session between a terminal connected to a base station of a network an access gateway and an IP core network interconnection gateway connected to a data packet network, said communication session passing through the base station and the data transfer gateway;

A module for supplying the communication parameter interconnection gateway, among the obtained communication parameters, intended to be used during the communication session for the transfer of data between the data transfer gateway and the gateway; interconnection;

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.

Correlatively, 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;

A step of obtaining communication parameters intended to be used during a communication session between a terminal connected to a base station of an access network and an interconnection bridge of the IP core network connected to a network of data packets, this communication session passing through the base station and the data transfer gateway;

- a supply stage

o to said interconnection gateway, communication parameters, among the communication parameters obtained, intended to be used during the communication session for the transfer of data between the data transfer gateway and the interconnection gateway; and

o the 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.

In a particular embodiment, 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. For example, 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.

In another embodiment, 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.

Thus, for example, in a particular embodiment of the invention:

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.

In another aspect, the invention also provides an IP core network comprising:

A plurality of data transfer gateways;

A control device according to the invention, 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; and

A data transfer control entity according to the invention, 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.

In a particular embodiment of the invention, 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.

According to another aspect, 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.

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.

In a particular embodiment, the various steps of the control method and / or the selection method are determined by computer program instructions.

Accordingly, 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. For example, 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.

On the other hand, 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.

Alternatively, 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.

Brief description of the drawings

Other features and advantages of the present invention will become apparent from the description given below, with reference to the accompanying drawings which illustrate embodiments having no limiting character. In the figures:

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; and

- Figure 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.

Detailed description of the invention

As mentioned above, 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. 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.

More specifically, 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. In the embodiment described here, 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.

To facilitate understanding of the invention, we will first briefly recall, with reference to Figures 3 and 4, the general principles of an SDN architecture. In the example chosen to illustrate these principles, it is assumed that this architecture is based on the use of the OpenFlow protocol, known to those skilled in the art and described in particular in the document "Openflow switch specification, version 1.3.1", September 2012 .

As previously mentioned, 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.

For this purpose, 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"; and 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").

As mentioned above and illustrated in FIG. 4, 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.

These processing rules are stored at each switch R in the form of FTAB flow tables (or "flow tables" in English), the inputs of which can easily be modified by the OpenCTR control device using the OpenFlow protocol. (eg adding, updating, deleting entries in the table).

By way of illustration, 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. Other fields can of course be also defined for each entry of the FTAB table in addition to these two fields, as illustrated in Figure 4, such as for example a TO field (for "Time Out"), PRIO (for "Priority"), COOK (for "Cookie"") Or CNT (for" Counters ").

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.

Where appropriate, 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).

If, on the other hand, no entry coincides with the received packet, it is transferred to the OpenCTR control device which creates a new flow table entry and a processing associated with that entry (ie a new processing rule), and transmits it to the switch R for storing it in a flow table associated with the terminal.

It is therefore clear that, in view of the operating mode just described, according to an SDN network architecture, the control and data planes are decoupled.

We will now describe, with reference to FIGS. 5 to 9, how the invention advantageously proposes to apply this principle to an IP core network architecture, and more particularly to an LTE / EPC core network architecture.

For the sake of simplification of the presentation, when no precision is provided in the description, the functions and operating modes of the equipment of the IP core network architecture presented (eg data transfer gateways such as S-GW gateways, interconnection gateways such as P-GW gateways, base stations in particular of eNodeB type, mobility management equipment such as MME equipment, establishment of GTP communication tunnels, etc. .) are similar or identical to those described in 3GPP TS 23.401 published by 3GPP and are not detailed here. However, 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 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. It is assumed here that in order to access the services offered by the PDN network 12 via the LTE / EPC network core 10, 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.

According to the invention, 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.

In order to better illustrate the separation of the planes recommended by the invention, the entity gathering the control functions of the data transfer gateways is referenced by "SGW-C" in FIG. 5 and in the description. Such an entity SGW-C is designated as a data transfer control entity. For their part, the equipment applying the processing or transfer functions in the data plane of these data transfer gateways are referenced by "SGW-D".

In the embodiment described here, the SGW-D 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. Thus, in the example illustrated in FIG. 5, 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. Of course, 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.

Similarly, in the embodiment described here, 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.

Thus, with reference to FIG. 3 previously commented and to the general principles of the SDN, the 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.

However, unlike the MME equipment described in 3GPP TS 23.401 and in accordance with the invention, 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.

It should be noted that in the embodiment described here, the control device

16, and the 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. In other words, 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.

Returning to FIG. 5, in the embodiment described here, the 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, for example, 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). These 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:

On the one hand, 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; and

On the other hand, 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.

It should be noted that the OpenFlow protocol being known to those skilled in the art, it is not detailed further here.

In the embodiment described here, it is assumed that 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.

Similarly, 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.

According to the architecture proposed by the invention, 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.

It is recalled that, in the current state of the art defined by the 3GPP consortium, it is the "receiving" end of the GTP tunnel that locally allocates the value of the TEID identifier used by the transmitting end of the tunnel to transmit data or signaling in this tunnel to the receiving end.

In accordance with the invention, for GTP communication tunnels having as receiving ends the 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. In other words, 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.

In other words, in the embodiment described here, 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.

Furthermore, according to the invention, it is also the entity 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.

In the described embodiment, 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.

Obtaining such statistics by itself using the OpenFlow protocol, via the positioning of appropriate counters by the control device 16 at each data transfer gateway SGW-D, does not pose any difficulties for the human being. of the trade and is therefore not described in more detail here.

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.

It should be noted that, thanks to this architecture and configuration of the control device 16 and the software entity SGW-C 17, the failure or overload situations of an active SGW-D data transfer gateway for a communication session of a terminal mentioned above can be managed in a transparent manner for the user of this terminal.

Indeed, when the control device 16 triggers the selection by the entity SGW-C

17 of a new SGW-D data transfer gateway 15 for serving a current communication session, and receives from the SGW-C 17 the communication parameters for use by this newly selected data transfer gateway and by the base stations communicating with this gateway, it has only to define processing rules reflecting these communication parameters. This can be achieved by updating previously defined existing processing rules and / or creating new processing rules. These processing rules are then transmitted to the equipment concerned in order to be stored in the corresponding flow tables and applied for the processing of the data packets received by these equipment. Thus, 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.

We will now illustrate in more detail the management performed by the heart of network 10 of a communication session of the user terminal UE 11 thanks to this new architecture. More particularly, three procedures are described with reference to FIGS. 7 to 9 respectively, namely:

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

A transparent restoration procedure implemented following the detection of a failure of the current S-GW-15 data transfer gateway used for the communication session.

These three procedures show the main steps of the control and selection methods according to the invention in a particular embodiment.

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.

For this purpose, 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).

It should be noted that the 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.

If the terminal 11 is successfully authenticated, the 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); and

An interconnection gateway to the PDN network (here, the interconnection gateway 13);

for the transfer of data exchanged during the communication session of the terminal 11 (step F40).

In the embodiment described here, 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.

It is assumed here that the 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.

Then, 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).

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).

On receipt of this message, 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).

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.

We will now describe, with reference to FIG. 8, a procedure for establishing a data plan for a communication session of the terminal 11, which can be implemented following the attachment procedure previously described.

It should be noted that 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).

Communication session initiated by the terminal 11:

It is thus assumed that the terminal 11 sends an "initial" data packet to 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).

If no input of the flow tables coincides with the header of the packet and the fields defined in these tables, 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). In other words, 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).

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.

For this purpose, 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.

For this purpose, 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.

In the embodiment described here, 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. In other words, this processing rule commands the gateway SGW-D 15A so that it transfers the received data packets to the base station 14A.

For this purpose, 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 .

At the end of this procedure, a first communication tunnel, typically GTP-U, 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. of data SGW-D 15A, the values V3, V4 of TEID identifier being inserted in the GTP packets transmitted in this first tunnel. In addition, a second communication tunnel, typically GTP-U, 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.

Communication session initiated by the core network 10 (not shown in FIG. 8):

It is assumed here that the establishment of the data plan is triggered by the arrival of an "initial" data packet intended for the terminal 11 at the level of the interconnection gateway 13 of the core network 10.

From the FTAB13 flow table associated with the terminal 11 maintained by the interconnection gateway 13 following the attachment procedure of the terminal 11, 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).

On receipt of this packet, 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.

If this is not the case, 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

11 relating to the current communication session.

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.

It should be noted that 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. 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.

We will now describe, with reference to FIG. 9, a restoration procedure that can advantageously be implemented by the core network 10 thanks to the architecture proposed by the invention, in the event of failure of an SGW data transfer gateway. -D involved in the communication session of the terminal 11. A similar procedure can also be used when the control device 16 detects an overload of an SGW-D data transfer gateway involved in the communication session of the terminal 11.

To illustrate this procedure, 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.

It is now assumed that the SGW-D data transfer gateway 15A is failing (step H10).

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).

On detection of this failure, the 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.

On the other hand, 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.

In other words, 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).

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. In other words, 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. In other words, this command processing rule the data transfer gateway SGW-D 15B so that it transfers the received data packets to the base station 14A. For this purpose, 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.

At the end of this procedure, 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).

As mentioned previously, 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.

Thanks to the real-time knowledge of these statistics, the 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. terminals for the different data transfer gateways SGW-D 15. For this purpose, load distribution or load balancing algorithms known per se (load balancing algorithms) can be used by the device. check 16 for enable the SGW-C 7 to select a new data transfer gateway for the session of the terminal 11.

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.

Claims

A control device (16) for an IP core network (10) comprising:

A communication module able to communicate with a data transfer control entity (17) of the IP core network, and configured to trigger the selection by the data transfer control entity of a data transfer gateway (15A) of the IP core 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 (11) connected to a base station (14A) of an access network, and an interconnection gateway (13) of the IP core network connected to a data packet network (12), said communication session transiting through the base station and the data transfer gateway;

A first control module (16A) of the base station by means of a first processing rule intended to be applied by said 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 the transfer of data between the base station (14A) and the data transfer gateway ( 15A); and

A second control module (16B) of the data transfer gateway by means of a second processing rule intended to be applied by said data transfer gateway following the reception of data relating to the communication session; second rule comprising parameters, among the communication parameters obtained from the data transfer control entity, for use in the communication session for the transfer of data between the data transfer gateway (15A) and the interconnection gateway (13).

2. Control device (16) according to claim 1 wherein the communication module communicates with the data transfer control entity via a programming interface (API17).

3. Control device (16) according to claim 1 or 2 wherein:

The communication parameters of the first rule comprise an address of the data transfer gateway (15A) and an endpoint identifier of a communication tunnel established between the data transfer gateway and the base station for the transfer of data, allocated by the data transfer control entity; and or

The communication parameters of the second rule comprise an address of the interconnection gateway (13) and an endpoint identifier of a communication tunnel established between the data transfer gateway and the gateway interconnection for the transfer of data, allocated by the data transfer control entity.

4. Control device (16) according to any one of claims 1 to 3 wherein the first control module (16A) and the second control module (16B) are configured to communicate respectively with the base station and with the data transfer gateway through the OpenFlow protocol.

5. Control device (16) according to any one of claims 1 to 4 wherein the communication module is further configured to trigger, via a programming interface (API18), on receipt of a request for attachment of the terminal to the IP core network, authentication of the terminal by a mobility management entity (18) belonging to the IP core network.

6. Control device according to any one of claims 1 to 5 further comprising a module for obtaining information representative of a current load of at least one data transfer gateway IP core network connected to the device control, the communication module being further configured to provide said information to the data transfer control entity via a programming interface (API 17).

7. Control device according to any one of claims 1 to 6 further comprising a module for detecting a failure or overload of the data transfer gateway, the communication module being further configured to inform the data transfer control entity of said failure or overload and to trigger the selection by the data transfer control entity of a new data transfer gateway (15B) for the communication session, and which :

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 data transfer between the base station (14A) and the new data transfer gateway (15B); and

The second control module is configured to control the new data transfer gateway (15B) by means of a third processing rule intended to be applied by said new data transfer gateway following the reception of relative data. at the communication session, 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 transferring data between the new data transfer gateway (15B) and the interconnection gateway (13).

8. Control device according to claim 7, wherein the first processing rule is updated with an address of the new data transfer gateway.

(15B).

The control device of claim 7, wherein the communication parameters of the second processing rule and the third processing rule comprise the same tunnel endpoint identifier allocated by the transfer control entity. and for use between the data transfer gateway (15A) and the interconnection gateway (13), and between the new data transfer gateway (15B) and the interconnection gateway (13).

A data transfer control entity (17) of an IP core network (10) comprising:

A communication module able to communicate with a control device (16) of the IP core network according to any one of claims 1 to 9;

A selection module, triggered by the control device (16) via the communication module, and configured to select a data transfer gateway (15A) of the IP core network;

A module for obtaining communication parameters intended to be used during a communication session between a terminal (11), connected to a base station (14A) of an access network, and a gateway of interconnection (13) of the IP core network connected to a data packet network (12), said communication session passing through the base station and the data transfer gateway;

A module for supplying the communication parameter interconnection gateway, among the obtained communication parameters, intended to be used during the communication session for the transfer of data between the data transfer gateway (15A) and the interconnection gateway (13);

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 (14A) and the gateway data transfer (15A).

An entity according to claim 10, wherein the communication parameter obtaining module is configured to allocate to the communication session an endpoint identifier of a communication tunnel between the communication transfer gateway and the communication terminal. data (15A) and the base station (14A) and an endpoint identifier of a communication tunnel between the data transfer gateway (15A) and the interconnection gateway (13).

The entity of claim 11, wherein the identifiers allocated by the entity to the communication session are invariant during the communication session.

An entity according to any one of claims 10 to 12 wherein the selection module is configured to select the data transfer gateway (15A) from among a plurality of data transfer gateways (15A, 15B, 15C) controlled by the control device using information representative of a current load of said data transfer gateways provided by the control device via a programming interface.

An entity according to any of claims 10 to 13 wherein:

The selection module is configured to select a new data transfer gateway (15B) for the communication session of the terminal when it is informed by the control device, via a programming interface, of a failure or of overloading the data transfer gateway (15A);

- The supply module and the communication module are configured to respectively provide the interconnection gateway (13) and the control device (16) said address of the new data transfer gateway (15B).

15. Core Network IP (10) comprising:

A plurality of data transfer gateways (15A, 15B, 15C);

A control device (16) according to any one of claims 1 to 9, able to control at least one base station (14A) of an access network to which a terminal is connected and the plurality of transfer gateways of data ; and

A data transfer control entity (17) according to any one of claims 10 to 14, able to communicate with the control device, and to select a data transfer gateway (15A) from the plurality of gateways of data transfer controlled by the control device for a communication session of the terminal.

The IP network core (10) of claim 15, further comprising a mobility management entity (18) configured to authenticate the terminal, said authentication being initiated by the control device via a programming interface.

17. Control method intended to be implemented by a control device (16) of an IP core network, and comprising: A step of communicating with a data transfer control entity (17) of the IP core network, comprising triggering a selection (F40) by the data transfer control entity of a data transfer gateway; data (15A) of the IP core network, and obtaining from the communication data control entity communication parameters for use in a communication session between a terminal connected to a base station (14A ) an access network and an interconnection gateway (13) of the IP core network connected to a data packet network (12), said communication session passing through the base station and the data transfer gateway data;

A control step (G40) of the base station by means of a first processing rule intended to be applied by said 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 the transfer of data between the base station (14A) and the data transfer gateway (15A) ); and

A control step (G50) of the data transfer gateway by means of a second processing rule intended to be applied by said data transfer gateway following the reception of data relating to the communication session, the second a rule comprising parameters, among the communication parameters obtained from the data transfer control entity, for use in the communication session for the transfer of data between the data transfer gateway (15A) and the gateway interconnection (13).

A selection method for implementation by a data transfer control entity (17) of an IP core network, and comprising:

A selection step (F40), triggered by a control device (16) of the IP core network, of a data transfer gateway (15A) of the IP core network;

A step of obtaining communication parameters intended to be used during a communication session between a terminal (11) connected to a base station (14A) of an access network and an interconnection gateway ( 13) of the IP core network connected to a data packet network (12), said communication session passing through the base station and the data transfer gateway;

- a supply stage

o to said interconnection gateway (50), communication parameters, among the communication parameters obtained, intended to be used during the communication session for the transfer of data between the data transfer gateway (15A) and the interconnection gateway (13); and to the control device (16), communication parameters, among the communication parameters obtained, intended to be used during the communication session for the transfer of data between the base station (14A) and the data transfer gateway; data (15A).

A computer program comprising instructions for performing the steps of the checking method according to claim 17 or the selection method of claim 18 when said program is executed by a computer.

20. A computer-readable recording medium on which is recorded a computer program comprising instructions for carrying out the steps of the checking method according to claim 17 or the selection method according to claim 18.

21. Base station of an access network (14A), able to serve a terminal (11) during a communication session, and comprising:

Means for receiving an IP network core control device according to any one of claims 1 to 9 of a processing rule intended to be applied by the base station following the reception of data relating to at said communication session of the terminal, the processing rule comprising communication parameters for use in said communication session for data transfer between the base station and a data transfer gateway (15A) of the heart of IP network; and

Means for applying this processing rule to data relating to said communication session.