WO2013144494A1

WO2013144494A1 - Device and method for managing a network service

Info

Publication number: WO2013144494A1
Application number: PCT/FR2013/050638
Authority: WO
Inventors: Selim Ellouze; Emile Stephan; Gaël FROMENTOUX
Original assignee: Orange
Priority date: 2012-03-26
Filing date: 2013-03-25
Publication date: 2013-10-03
Also published as: FR2988545A1

Abstract

A management device (4) for managing at least one application data transmission support network session established by a destination entity (2), the management device comprising: a network information management module for obtaining information relative to an underlying transport network (6), a service information management module for obtaining information relative to an application, the information relative to the application comprising at least one identifier of a source entity (3) associated with the application, a configuration module for determining a transmission configuration of the application data on the basis of the information relative to the network and the information relative to the application, and a control module for controlling a network session control device (5) on the basis of the determined configuration, characterised in that the determined configuration comprises at least one interception rule on the basis of at least one piece of information relative to said at least one session, a processing to be implemented on said at least one session and said at least one identifier of a source entity associated with the application, the control module being configured to transmit the determined configuration to said network session control device (5).

Description

MANAGEMENT DEVICE AND METHOD FOR NETWORK SERVICE

Background of the invention

The invention relates to the general field of telecommunications. In particular, the invention relates to the management of network sessions for the transmission of application data between source entities and destination entities.

Internet applications, for example a video-on-demand service, implemented in a content distribution network or a peer-to-peer network, now operate in a tight manner with respect to underlying transport. An application client is directed to a content source by the application provider, regardless of the impact of this routing on the underlying transport network. This approach leads to conflicting and unoptimized situations where applications do not compromise and do not take into account the limitations of the underlying transport network.

A solution to address this problem has been developed by an IETF working group called ALTO. ALTO provides an architecture and protocol that allows applications to request information or recommendations from networks to overcome this problem. This approach is very limited and static because the network information that the network operator agrees to disclose is not the most relevant. Indeed the network operator seeks to preserve the critical information (topology, evolutions, sizing of the network, etc.) vis-à-vis the applications. Moreover, this approach does not take into account the evolution over time of the constraints of the underlying transport network and the application.

Another ALTO proposal is the use of an entity called ALTO Relay and described in S. Randriamasy, "Provider Confidential ALTO with Relayed, IETF, Draft IETF draft-randriamasy-alto-relay-01, April 2011. This solution allows the underlying transport network to choose, from a source list pre-established by the service provider, the source to be used by the customer, and does not require the transmission of critical information from the transport network to the carrier. There are no mechanisms for managing multiple sessions for the same client with different sources, and the choice of which source to use may become unsuitable when the constraints are applied. transport network or application vary during the course of the session. Transport techniques used by the application may lead to non-optimized use of transmission network resources.

There is therefore a need for an improvement in the management of application data transmission medium network sessions established by at least one destination entity.

Object and summary of the invention

The invention proposes a device for managing at least one network session, an application data transmission medium and established by a destination entity, the management device comprising:

a network information management module for obtaining information relating to an underlying transport network,

a service information management module for obtaining information relating to an application, the information relating to the application comprising at least one identifier of a source entity associated with the application,

a configuration module for determining a transmission configuration of the application data according to the network information and application information, and

a control module for controlling a network session control device according to the determined configuration.

This management device is remarkable in that the determined configuration comprises at least one interception rule as a function of at least one information relating to the said at least one session, a processing to be implemented on the said at least one session and the said at least one identifier of a source entity associated with the application,

the control module being configured to transmit the determined configuration to said network session control device.

Correlatively, the invention proposes a method of managing a network session, an application data transmission medium and established by a destination entity, the management method comprising the following steps implemented by a management device:

a step of obtaining information relating to an underlying transport network,

a step of obtaining information relating to an application, the information relating to the application comprising at least one identifier of a source entity associated with the application, a step of determining a data transmission configuration of application, based on the underlying transport network information and application information, and a step of controlling a network session control device according to the determined configuration.

This management method is remarkable in that the determined configuration comprises at least one interception rule as a function of at least one information relating to the said at least one session, a processing to be implemented on the said at least one session and the said at least one identifier of a source entity associated with the application,

the control step comprising transmitting the determined configuration to said network session control device.

Correspondingly, the invention provides a network session control device, application data transmission media and established by a destination entity, the network session control device comprising:

a transport and session management module for receiving a configuration command issued by a management device according to the invention, the configuration command including at least one interception rule as a function of at least one information relating to at least one of said sessions, a processing to be implemented on said at least one session and at least one identifier of a source entity associated with an application,

an interception module for intercepting sessions according to the interception rule received,

a processing module for implementing a processing on an intercepted session according to the configuration command.

Correlatively, the invention proposes a transmission method for an application service, this method being implemented by a network session control device, the application service comprising at least one application data transmission session between at least one entity source and at least one destination entity, the transmission method comprising:

a step of receiving a configuration command issued by a management device according to the invention, the configuration command including at least one interception rule as a function of at least one information item relating to said at least one session, a processing to be implemented on said at least one session and said at least one identifier of a source entity associated with the application,

a step of interception of sessions according to the received interception rule,

a processing step for implementing a processing on the intercepted session according to the configuration command.

With these features, a destination entity that wishes to obtain the application data will establish a session to a source entity. This session will be intercepted by the network session control device and a processing is implemented according to the configuration determined by the management device. This provides several benefits. Indeed, since the configuration is determined based on information about the underlying transport network and application information, it improves the quality of service in the network and the quality of the experience, compared to a situation in which the destination entity connects directly to a source entity regardless of the state of the underlying transport network. In addition, since the information relating to the underlying transport network is processed by the management device, it is not necessary to transmit it to a third party responsible for the application.

According to one embodiment, the interception rule further comprises at least one identifier of a fictitious source entity associated with said identifier of the corresponding source entity, and the control module is furthermore arranged to transmit said at least one identifier a fictitious source entity to said at least one destination entity.

By using multiple dummy source entities, a destination entity can establish independent sessions to different real source entities corresponding to the dummy source entities.

According to one embodiment of the management device, the network information management module is configured to obtain information relating to the transport network repeatedly during an application data transmission session, the management module service information being configured to obtain application information repeatedly during an application data transmission session,

the configuration module being configured to determine a new configuration in response to a change in the transport network information or application information obtained,

the control module being configured to control the network session control device according to the new configuration.

Correspondingly, according to one embodiment of the network session control device, the transport and session management module is configured to receive a configuration command repeatedly during an application data transmission session. , the processing module being configured to implement a processing on the intercepted session according to the last configuration command received.

In other words, the operation of the management device and the network session control device is dynamic during a transmission session. Thus, the management device may decide to change the configuration during the session if the network and / or service conditions change, to improve the quality of service in the network and the network. quality of service user experience. The network session control device then applies the new configuration.

According to one embodiment, the transmission configuration comprises the choice of a transmission mode of the application data between the network session control device and said at least one source entity. The management device can therefore choose a transmission mode that optimizes the quality of service in the network and the quality of experience.

The transmission configuration may include the selection of a subset of source entities. Thus, it is possible to improve the quality of service in the network and the quality of experience, for example by selecting only source entities reachable by links whose available bandwidth is sufficiently high.

The transmission configuration may include aggregating an application data transmission for a plurality of different destination entities in the same session between the network session controller and at least one source entity. This reduces the amount of data that must pass through the network.

The transmission configuration may also include selecting an application data transport protocol between the network session controller and the at least one source entity. Thus, for illustrative purposes, a transport protocol that improves the quality of service in the network and the quality of experience can be selected.

The transmission configuration may include the implementation of a network resource. Thus, the management device can decide to implement for example a storage server, a virtual machine, ... which can be used to improve the quality of service in the network and the quality of experience.

The transmission configuration may also include the choice of an application data delivery mode between the network session controller and the at least one source entity. As an illustration, it is possible to choose a delivery method to improve the quality of service (unicast, multicast, P2P ....).

The transmission configuration may include the choice of a transparent mode, wherein only said at least one identifier of a dummy source entity is transmitted to said at least one destination entity. In this case, a destination entity must not be adapted specifically for the implementation of the invention.

The transmission configuration may include the choice of a non-transparent mode, in which the control module is configured to transmit information relating to the configuration of the network session to the at least one destination entity. In this case, the additional information may include instructions for the destination entity, for example a transport protocol to be used, also to improve the quality of service in the network and the quality of experience. The invention also relates to a computer program comprising instructions for executing the steps of a management method or a transmission method according to the invention when said program is executed by a computer.

This program 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 other form desirable shape.

The invention also relates to a recording medium or information carrier readable by a computer, and comprising instructions of a computer program as mentioned above.

The recording media mentioned above can 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 recording media may correspond to 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 recording media may correspond to 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. Brief description of the drawings

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

FIG. 1 represents a network allowing the implementation of an embodiment of the invention,

FIG. 2 represents the hardware architecture of a computing device of the network of FIG. 1,

FIG. 3 represents the functional structure of a device for managing a network session according to one embodiment of the invention,

FIG. 4 represents the functional structure of a network session control device according to one embodiment of the invention, FIG. 5 represents a transparent mode of operation of the network of FIG. 1,

FIG. 6 represents a non-transparent mode of operation of the network of FIG. 1,

FIGS. 7 to 9 represent data packets that can be used in the network of FIG. 6,

FIG. 10 represents the main steps of a management method according to one embodiment of the invention,

FIG. 11 represents the main steps of a transmission method according to one embodiment of the invention, and

FIG. 12 represents an example of application of the network of FIG. 1.

Detailed description of an embodiment

FIG. 1 represents a network 1 comprising destination entities 2, source entities 3, an entity called NOM 4 (for "Network Optimization Manager" or network optimization manager), entities called GCS 5 (for "Control Manager"). Session "), an underlying transport network 6 and an SP 7 service provider entity (for" Service Provider ").

The network 1 allows the implementation of an application or application service through data transmission sessions carried by the underlying transport network 6, carrying application data, source entities 3 to the entities destination 2. The application service is managed by the service provider entity SP 7. The application service is for example a video-on-demand service including the transmission of audio-visual data, a CDN-type content distribution service (for "Content Distribution Network") or a peer-to-peer data transfer service.

The entities designated by references 2 to 5 and 7 in FIG. 1 are functional entities, each of which may correspond to the execution of a computer program on a computing device. Thus, FIG. 2 represents such a computing device 10 which notably comprises a microprocessor 11, a non-volatile memory 12, a volatile memory 13 and a communication interface 14. The microprocessor 11 makes it possible to execute computer programs stored in the non-volatile memory 12, using the volatile memory 13 as a working space. The communication interface 14 makes it possible to communicate on the network 1. Hereinafter, references 2 to 5 and 7 may be used to designate one of the functional entities of FIG. 1 or the corresponding computing device 10. The computing device 10 corresponding to the NAME 4 is called network session management device 4, and is in the transport network 6. The NAME 4 is controlled by the operator.

The computing devices 10 corresponding to the GCS 5 are called network session control devices 5, and are in the transport network 6. The GCS 5 are therefore controlled by the operator.

The computing devices 10 corresponding to the destination entities 2 are, for example, user terminals 2 connected to the transport network 6. In this case, according to one embodiment, the computer devices 10 corresponding to the GCSs 5 are, for example, the equipment of FIG. access or collection through which the user terminals 2 are connected to the transport network 6. Specifically, it may be a DSLAM (for "Digital Subscriber Line Access Multiplexer") for residential ADSL access (for "Asymmetric Digital Subscriber Line"), an RNC (for "Radio Network Controller") radio controller for UMTS mobile networks, an "eNodeB" node for LTE mobile networks, ...

The computing devices 10 corresponding to the source entities 3 and to the service provider entity SP 7 may be in the transport network 6 or outside the transport network 6, and are therefore not necessarily under the control of the operator of the service provider. Transport Network 6. In Network 1, the application data transmission sessions between Source Entities 3 and Destination Entities 2 are managed by NOM 4 and GCS 5 in order to improve Quality of Service (QoS). in the transport network 6 and quality of experience (QoE) for users of the application service. The structure and operation of NOM 4 and GCS 5 are described below.

FIG. 3 represents the functional structure of NAME 4. NAME 4 comprises a network information management module 41, a service information management module 42, a configuration module 43 and a control module 44.

The network information management module 41 obtains and stores network information representative of the state of the transport network 6. The network information includes, in particular, information on the topology of the transport network 6, bandwidths available on the network. links of the transport network 6, the availability of resources of the transport network 6 such as servers, multicast addresses, etc. The network information is for example obtained by interrogating a monitoring server of the transport network 6. In a embodiment, the network information management module 41 is also able to make available resources of the transport network 6, by example a storage server, ... to improve the transport of application data in the network. For example, the network information management module 41 is able to either directly control a resource or to request an operator resource management system to do so.

The service information management module 42 obtains and stores information relating to the application service. Service information may include, but is not limited to:

- The nature of the application service,

- The nature of the application data,

A list of source entities 3 of the application service,

- The availability and location of source entities 3,

A list of destination entities 2 of the application service,

- The transport protocols that are able to use source entities 3 and destination entities 2 (TCP, UDP, SCTP, proprietary protocol or other).

In one embodiment, the service information is provided by the service provider entity SP 7.

In another embodiment, the service provider entity SP 7 does not provide service information to the NAME 4. In this case, the NAME 4 determines service information from information provided by the GCS 5. Indeed, the GCS 5 detect the sessions related to the application service in the transport network 6, according to detection criteria provided by the NAME 4.

The configuration module 43 determines a transmission configuration of the application data in the transport network 6, as a function of the network information obtained by the network information management module 41 and the service information obtained by module. The configurations that can be determined by the configuration module 43 are described below. They aim to improve the quality of service in the transport network 6 and the quality of experience of the users of the application service.

Finally, the control module 44 transmits commands to the GCS 5 to apply the configuration determined by the configuration module 43.

The network information management module 41, the service information management module 42, the configuration module 43 and the control module 44 correspond, for example, to software modules of a computer program executed by the communication device. management of a network session 4, that is to say by the NAME 4. Since the network information is processed by the NOM 4 which is controlled by the operator, it is not necessary to transmit the network information to a third party. The confidentiality of the network information is thus preserved. FIG. 4 represents the functional structure of one of the GCS 5. The GCS 5 comprises a transport and session management module 51, an upstream session management module 52, a buffer module 53, a downstream session management module 54, and an interception module 55.

The interception module 55 allows the GCS 5 to intercept the data sessions between the destination entities 2 and the source entities 3, according to an interception rule determined by the NAME 4. The interception rule is described below.

The upstream sessions management module 52 makes it possible to manage the upstream sessions, that is to say a session between a destination entity 2 and the GCS 5. The upstream sessions can be terminated at the GCS 5 or modified from transparent way to the client, as described later.

The downstream sessions management module 52 makes it possible to manage the downstream sessions, that is to say a session between the GCS 5 and a source entity 3. A downstream session can be the extension of an upstream session after modification. transparent or not. If an upstream session has been completed at GCS 5, the corresponding downstream session is created and managed entirely by GCS 5.

The buffer module 53 makes it possible to process and store the data exchanged between a source entity 3 and a destination entity 2.

The transport and session management module 51 is responsible for controlling the operation of the other modules 52, 53, 54 and 55 as a function of commands received from the NOM 4, in order to apply the configuration determined by the NAME 4. The modules 52 , 53, 54 and 55 form a processing module, arranged to implement a processing according to a configuration command.

The transport and session management module 51, the upstream session management module 52, the buffer module 53, the downstream session management module 54, and the interception module 55 correspond, for example, to software modules. a computer program executed by the network session control device 5, that is to say by the GCS 5.

The configuration determined by NAME 4 concerns the interception rule as a function of at least one information relating to the session and a processing to be implemented on this session The interception rule makes it possible to specify the session to be intercepted for application of a treatment by the GCS 5. It includes one or more information relating to the session or sessions to be intercepted. It may be known information with respect to a specific application service (transport protocol, protocol at the application level, etc.) or information obtained from the service provider, for example an identifier of an entity source, a specific port number, a particular protocol, ...

For example, when determining the configuration, a list of fictitious source entities is generated and associated respectively with a list of source entities. The list of fictitious source entities is transmitted to one or more destination entities 2, for example via the SP 7 service provider entity or the GCS 5.

The treatments to be implemented, determined by the NOM 4, concerning the downstream sessions are for example:

- Transport mode modification: By intercepting the sessions between the destination 2 entities and the source entities 3, the GCS 5 can control the transport mode downstream in the transport network 6, according to the configuration determined by the NOM 4 .

For example, if the source entities 3 use a unicast client-server transport mode, as in the case of a CDN type network, the NAME 4 can choose between the following modes of transport:

o A unicast client-server transport mode: In this operating mode, the NAME 4 controls each GCS 5 so that the GCS 5 obtains the application data of one or more source entities 3 individually.

o A transport mode using a multicast broadcast tree: In this operating mode, the NOM 4 controls a determined GCS 5 to receive the unicast application data of one or more source entities 3, and to configure itself as a source a multicast broadcast tree. NAME 4 commands other GCSs concerned with the application data to configure themselves to receive the data as clients of the multicast broadcast tree. The GCSs that receive the application data from the multicast broadcast tree can then forward them to the destination entities 2.

The NAME 4 may for example choose the aforementioned unicast client-server transport mode if the number of destination entities is small and if the available bandwidths in the transport network 6 are sufficient. If NAME 4 finds that the number of destination entities 2 is increasing and exceeds a certain threshold and / or if the available bandwidths in the transport network 6 fall below a determined threshold, the NAME 4 then decides to use the transport mode using a multicast broadcast tree, which makes it possible to reduce the use of the resources 6. If the number of destination entities 2 decreases and / or if the available bandwidths in the transport network 6 increase, the NOM 4 may decide to return to the client-server transport mode.

In another example, if the destination 2 entities and the source entities 3 use a peer-to-peer transport mode, the NAME 4 can choose between the following operating modes:

o Peer-to-peer transport mode: In this mode of operation, NOM 4 commands GCS 5 to configure itself as a peer-to-peer network client to obtain application data from one or several source entities 3 and transmit them to destination entities 2.

o A unicast client-server transport mode: In this operating mode, NAME 4 controls one or more servers of the transport network 6 to receive the application data as a peer-to-peer network client. NOM 4 commands GCSs concerned with the application data to obtain the application data by establishing unicast sessions with the aforementioned servers. The GCSs that receive the application data per unicast session can then forward them to the destination 2 entities on the peer-to-peer network.

Modification of the Source Entities 3 Used: NAME 4 can select the source entities 3 to use and control the GCS 5 to set sessions only to the selected source entities 3.

Modification of the source entities 3 used during the execution of the application service: Depending on the information obtained by the information management module on the network 41 and the service information management module 42, the NAME 4 can select other source entities 3 to use and control the GCS 5 to establish sessions only with the new source entities 3 selected, and this running the application service.

Session Aggregation: NAME 4 can configure a GCS 5 to aggregate sessions of different destination 2 entities that are subscribed to the same application service to retrieve application data of which at least a portion is identical. GCS 5 works by recovering application data once required to route it to the different destination 2 entities that request them. Unlike a cache server, the GCS 5 does not analyze the queries of the destination 2 entities to answer them separately. It applies a determined configuration NAME 4 to route to a destination entity list only once retrieved application data.

- Modification of the transport protocol: If the source entities 3 or the transport network servers used as source entities support different transport protocols, the NOM 4 can decide to pass from a given transport protocol to another protocol, by example from TCP to UDP, SCTP, or another proprietary protocol ... and vice versa. NOM 4 may also decide to use different protocols in parallel, and this in service, depending on the network context and service context.

- Mobilization of network resources: NOM 4 can make network resources available such as multicast resources, storage entities, server entities, virtual machines, etc. to use them in the transport of application data to optimize the routing of traffic to GCS 5. This mobilization is dynamic during service. NAME 4 can decide at any time to release these resources and to return to other modes of routing.

Upstream sessions can use a transparent or non-transparent mode for the destination entity.

FIG. 5 illustrates the transparent mode, that is to say a mode in which the destination entities 2 have the impression of communicating directly with the source entities 3, that is to say without the intervention of intermediate equipment such as NOM 4 and GCS 5.

In FIG. 5, a destination entity 2 receives, from the service provider entity SP 7 or from the NAME 4, the identifiers of the source entities to which it must connect to subscribe to the application service, for example their addresses. Respective IP @ IPX1, @ IPX2 and @ IPX3. These source entities are fictitious, that is, these IP addresses are not real and are used to hide the real IP addresses @IPB, @IPC, @IPD, @IPE and @IPF of the source entities. NAME 4 determines a configuration for the downstream sessions according to the possibilities described above. For example, NAME 4 decides that only source entities 3B, D and E can be used. NAME 4 sends a CMD command to the GCS 5 to indicate the source entities 3 to use.

Thus, when the destination entity 2 initiates sessions to the fictitious source entities corresponding to the addresses @ IPX1, @ IPX2 and @ IPX3, these sessions are transparently intercepted at the GCS 5 which establishes the real sessions with real source entities 3 B, D and E retained by NOM 4.

In a variant of the transparent mode, the GCS 5 terminates the sessions of the destination entity 2 and initiates new sessions with the source entities 3B, D and E. For example, as indicated in the following table, the requests at destination from @ IPX1 to TCP are routed to @IPB in SCTP. Queries at destination @ IPX2 in TCP are routed to @IPD in UDP and requests at destination @ IPX3 in TCP are routed to @IPE in UDP.

In this variant, the NAME 4 can at any time during service modify the configuration and in particular:

to change the selected source entities 3, if, for example, the quality of the paths between the CGS 5 and one of the source entities 3 B or D or deteriorates,

modifying the SCTP and UDP protocols by other protocols, for example to use a source entity 3 that does not support these protocols,

- choose more suitable modes of transport, eg IP Multicast instead of unicast.

In another variant of the transparent mode without session termination, the GCS 5 intercepts the sessions initiated by the destination entity 2 to the source entities 3 that have been communicated to it {@ IPX1, @IP X2, @IP X3}. The GCS 5 makes modifications on the sessions before routing them to the source entities 3 B, D and E chosen by the NAME 4. The sessions are not finished at the level of the GCS 5. They are adapted according to an application routing table defined by NAME 4, as in the following example:

True False Identity

identity

@ IPX1 @IPB

@ IPX2 @IPD

@ IPX3 @IPE According to this example, the TCP (or UDP, SCTP, ...) sessions between XI and B, between X2 and D, and between X3 and E are adapted by the GCS 5 as follows:

- The source address, destination address and checksum (or checksum) fields of the IP header of the packet are modified: In the source address field, the IP address of the destination entity 2 is replaced by the GCS 5 IP address, in the destination address field, the address @ IPX1 (or @ IPX2 or @ IPX3) is replaced by the @IPB address (or @IPD or @IPE), and the checksum field is changed to take into account the modification of the source address and destination address fields.

- The source port, destination port and checksum fields are modified.

- Fields containing peer identity information in the application data are changed if they exist.

FIG. 6 illustrates the non-transparent mode, that is to say a mode in which the destination entities 2 adapt to the configuration determined by the NAME 4.

In the non-transparent mode, the destination entity 2 also receives a CMD command in order to apply the configuration determined by the NAME 4 for the upstream sessions. This CMD command may be transmitted to the destination entities 2 by the NAME 4, the GCS 5 or by the SP 7 service provider entity.

Thus, the destination entity 2 encapsulates the data packets relating to the sessions with the fictitious source entities @ IPX1, @ IPX2 and @ IPX3 in an IP packet sent to the GCS 5. Several types of encapsulations are conceivable:

IP-Transport encapsulation: FIG. 7 represents an IP packet 70 using IP-Transport encapsulation for the communication of the destination entity 2 to the GCS 5. In this variant, the destination entity 2 constructs IP packets 71 and 72 for fictitious source 3 entities @ IPX1, @ IPX3. Then, the destination entity 2 encapsulates the IP packets 71 and 72 in a TCP / IP packet 70 to the GCS 5. When it receives the TCP / IP packet 7, the GCS 5 retrieves the different internal packets 71 and 72. Then, similar to the transparent operating mode described above, the GCS 5 modifies fields relating to the identities of the source entities 3 and the sessions in the headers and data such as the IP addresses, the ports for the transport protocol, etc. . The GCS then sends the modified packets to the source entities 3 concerned. In the opposite direction, GCS 5 differentiates recipients from packets based on the source and destination ports. With this type of encapsulation, the GCS 5 manages only the state of the session between itself and the destination entity 2. This session can be based on a UDP session reducing to the logon the consequent processing to run in GCS 5. In addition, session states are managed end-to-end. The transport is optimized by multiplexing multiple sessions to the source entities 3 on the same session between the destination entity 2 and the GCS 5. The processing can be fast in the GCS 5 because the packets 71 and 72 are already ready and require only the modification of certain fields.

ID-Transport encapsulation: FIG. 8 represents an IP packet 80 using ID-Transport encapsulation for the communication of the destination entity 2 to the GCS 5. In this variant, a list of ID identifiers is assigned to the different source entities. 3. These ID identifiers may be IP addresses, numbers, designations or any information that makes it possible to distinguish a source entity 3 without revealing its identity. To construct the IP packet 80, the destination entity 2 adds upstream data intended for each source entity 3 a field containing its ID and the length L of the data. This information is encapsulated in the IP packet 80 and sent to the GCS 5. When it receives the IP packet 80, the GCS 5 retrieves the data intended for each source entity 3. It constructs the IP packet to be sent to each source entity and inserts the application data received from the destination entity. The GCS 5 then sends the data to the source entities 3 through the sessions it has established with them. In the reverse path, the GCS 5 multiplexes the data destined for the destination entity 2 by adding the identification ID of each sender in front of its data.

With respect to the IP packet 70 of FIG. 7, the IP packet 80 makes it possible to reduce the amount of additional data to be transmitted since the IP packet 80 does not have to include the IP headers of encapsulated packets. In addition, GCS 5 can intervene on the data, its origin and the mode of transport. As in the case of Figure 7, the transport is optimized by multiplexing multiple sessions to the source entities 3 on the same session between the destination entity 2 and the GCS 5. GCS can handle different types of sessions.

IP-IP Encapsulation: FIG. 9 represents an IP packet 90 using IP-IP encapsulation for the communication of the destination entity 2 to the GCS 5. In this variant, the destination entity 2 constructs IP packets 91 and 92 to fictitious source 3 entities @ IPX1, @ IPX3. Then, destination entity 2 encapsulates IP packets 91 and 92 directly into an IP packet 90 to the GCS 5 (and not in a TCP / IP packet as in the case of Figure 7). When it receives the IP packet 90, the GCS 5 retrieves the various internal packets 91 and 92. Then, similarly to the transparent operating mode described above, the GCS 5 modifies fields relating to the identities of the source entities 3 and the sessions in headers and data like IP addresses, ports for transport protocol, etc. The GCS 5 then sends the modified packets to the source entities 3 concerned. In the opposite direction, GCS 5 differentiates recipients from packets based on the source and destination ports.

IP-IP encapsulation reduces the additional data needed for a transport session. In addition, the GCS 5 must not manage a transport session with destination entity 2.

The use of addresses @ IPX1, @ IPX2 and @ IPX3 (case of transparent mode and, in the non-transparent mode, of figures 7 and 9) or identifiers of fictitious source entity IDs allows destination entities 2 to communicate with several source entities 3 by independently managing the sessions with each source entity 3, while ignoring the real identity of the source entities 3. Similarly the source entities 3 ignore the identity of the destination entity 2 because the same processing is applied by GCD 5 on the downstream connections. The address of the destination entity 2 @IPA is replaced by an address of the GCD @IPGCD to conceal the identity of the destination entity 2.

Since the destination entity 2 is not aware of the real addresses of the source entities 3, it is not possible for it to bypass the configuration set up by the NOM 4. Moreover, it is not possible to infer on the the configuration implemented by NOM 4 of the critical information relating to the state of the transport network used to optimize the transport of data.

FIG. 10 represents the main steps of a management method of a network session, implemented by the management device of a network session 4, that is to say by the NAME 4.

In step E1, NAME 4 obtains NTW network information. As explained above, the NTW network information includes in particular information on the topology of the transport network 6, bandwidths available on the links of the transport network 6, the availability of resources of the transport network 6 such as servers, .. .

In step E2, the NAME 4 obtains service information SP relating to the application service. Then, in step E3, NAME 4 determines a CONF configuration based on NTW network information and SP service information: CONF = F (NTW., SP). As previously explained, the configuration includes an interception rule and may concern the choice of a transport mode, the selection of source entities, a transport protocol, etc.

Finally, the NOM 4 transmits, at the step E4, CMD commands to the GCS 5 so that the GCS 5 apply the CONF configuration.

In Fig. 10, an arrow connects step E4 to step E1, which means that steps E1 through E4 are performed repeatedly during the application data transmission sessions between the source entities 3 and the destination entities 2. In other words, the operation of the system shown in FIG. 1 is dynamic. The NAME 4 can change the configuration during the session if the conditions of the network and / or the service evolve, to improve the quality of service in the transport network 6 and the quality of experience of the users of the service.

For example, with reference to FIG. 5, if during a session between the destination entity A and the source entity B passing through the GCS 5, the NAME 4 finds, as a function of the NTW network information, that the quality of the link between the GCS 5 and the source entity B is degraded, the NOM 4 determines a new configuration in which the source entity C is used in place of the source entity B and controls the GCS 5 to direct the destination entity A to the source entity C. The destination entity A always has the impression of continuing the same session with the imaginary source entity @ IPX1.

FIG. 11 represents the main steps of a transmission method, implemented by a network session control device 5, that is to say by a GCS 5.

In step F1, the GCS 5 receives a CMD command from the NAME 4, asking it to apply a determined configuration.

Then, in step F2, the GCS transmits the data packets it receives by applying the configuration.

Fig. 11 shows an arrow from step F2 to step F1. That is, steps F1 and F2 are performed repeatedly during the application data transmission sessions between source entities 3 and destination entities. 2. In other words, as explained above, the operation of the system shown in FIG. 1 is dynamic. When NAME 4 decides to change the configuration during the session, the GCS 5 applies the new configuration.

Steps F21 to F25 represent the flow of step F2 in more detail.

In step F21, the GCS 5 receives a packet of data P. Then, in step F22, the GCS 5 determines whether the data packet P is linked to the application service managed by the NAME 4. This determination can be made on the basis of the interception rule transmitted by the NAME 4 in the CMD command. For example, if a packet P received from a destination entity 2 has for destination address a @ IPX1 dummy address specified by the NAME 4, the GCS 5 determines that the packet P is linked to the application service. According to another example, if a packet P received from a source entity 3 has for source address an @IPB address indicated by the NOM 4, the GCS 5 determines that the packet P is linked to the application service.

If it has been determined in step F22 that the packet P is related to the application service, then the packet P is processed at processing steps F23 and F24 according to the configuration determined by the NAME 4. The processing steps F23 and F24 allow to implement a processing on the intercepted session according to the configuration command. For example, in the case of the transparent operating mode without termination of the sessions described above, the GCS 5 implements a processing on a packet P 'belonging to an intercepted session by changing the source address, destination address and checksum fields of the packet P (step F23), and transmits the packet P '(step F24).

If it has been determined in step F22 that the packet P is not related to the application service, then the packet P is simply retransmitted without being processed by the GCS 5 (step F25).

Source entities 3 and destination entities 2 have been described as corresponding to different devices. However, the same computer device 10 can simultaneously correspond to a source entity 3 and a destination entity 2, especially in the case of a peer-to-peer network.

Figure 12 shows a first concrete example of application of the invention. This example relates to a video-on-demand service. The source entities are here called 3 or 3 servers and the destination entities are called clients 2.

An SP 7 service provider provides a streaming video streaming application. The SP 7 service provider has 3 servers with limited capabilities and P2P distribution modules for Peer-to-Peer. It has a partnership with the operator of the transport network 6 to improve the quality of its customers' experience while optimizing the traffic for the transport network 6. In practice, for each customer 2, this partnership aims to determine which is the server 3 and the possible peers 3 P2P which offer the best quality of service taking into account the state of the network and in particular the load of the links between the customers 2 themselves and the customers 2 and the servers 3 .

The SP 7 service provider distributes adaptable content structured in several layers allowing to have representations of the content with resolutions, qualities or different fluidities of images, for example content encoded with the H.264 SVC standard for "Scalable Video Coding". The base layer (in normal quality) is retrieved by the clients 2 from the servers 3 directly into unicast client-server TCP. The enhancement layers that improve the quality of the stream are in turn distributed in P2P in TCP because of the limited resources of the servers 3. One of the servers 3 becomes source P2P and the others can be used as super-pairs. Clients 2 retrieve content in client-server and P2P modes.

In order not to disclose information about its infrastructure and link status and session preferences, NOM 4 configures GCS 5 to control client 2 sessions internally instead of sending this information to the provider. SP 7 service and let him manage the sessions.

During the initial configuration, NAME 4 decides to use the transparent mode with session termination. For each client 2, the NAME 4 determines the corresponding GCS 5, the best server or servers 3 and P2P 2 clients which make it possible to improve both the quality of experience perceived by the users and to optimize the network traffic generated by the service. The SP 7 service provider transmits a list of server source entities 3 and P2P clients 2 to the NAME. It receives a list of fictitious source entities to communicate to clients 2 (fictitious IP addresses). The GCS 5 receives the configuration indicating the list of fictitious and real source entities with the configuration of the session to use: protocol, mode of transport, etc.

Thus, during the execution of the service, the clients 2 initialize sessions to the fictitious IP addresses delivered by the NAME 4 to the service provider SP 7. Each GCS 5 intercepts the sessions and redirects the requests to the servers 3 and 3 through the sessions he himself created with them. By using several fictitious addresses, the client 2 can thus distinguish between the different entities: servers 3, peers 3 while ignoring their identities. Each packet sent by the client 2 and intended for a specific source entity is identified by the GCS 5 by means of the fictitious IP address.

During the session, NAME 4 can decide on an adaptation of the source entities. For example, if paths used by other application services begin to achieve high utilization rates degrading the quality of service in the network, NOM 4 intervenes on a selection of client 2 to replace the servers 3 they are in use by other servers 3 whose paths are less exploited. NOM 4 establishes new configurations for the GCS 5 concerned for immediate application. The transparent mode prevents clients 2 any session interruption and new session establishment maneuvers.

During the session, NAME 4 can also decide on an adaptation of the mode of transport. For example, if the number of clients 2 increases significantly, NAME 4 decides use an IP Multicast broadcast tree to transport the content. NAME 4 configures the GCS 5 to subscribe to the multicast tree and finish the unicast sessions with the servers 3. An entity (which can be a GCS 5 or a server of the transport network) is chosen by the NAME 4 for position itself as the source of the multicast tree. GCS 5 creates multicast UDP sockets for receiving multicast base layer. On the other hand TCP unicast sessions with clients 2 in peer-to-peer mode are kept. The stream is received in multicast UDP by the GCS 5 and forwarded in TCP unicast to the clients 2.

The GCS 5 are for example embedded in the DSLAM for residential ADSL access, in the RNC radio controllers (for "Radio Network Controller") for UMTS networks, in an eNodeB node for LTE networks, ... This distribution of the GCS 5 offers the advantages of closer contact with end customers and improved extensibility. Reconciliation with clients 2 optimizes traffic. For example, if the GCS 5 retrieves the content in multicast (one session), the unicast sessions between the GCS 5 and the clients 2 will be confined to the local loop where inevitably each client has a dedicated channel. Regarding the improvement of extensibility, each equipment (RNC, eNodeB, DSLAM) will be responsible for a limited number of customers 2 which does not require more material resources to contribute. The scale factor is therefore not a problem.

A second concrete example of application of the invention concerns the distribution of content on a peer-to-peer (P2P) network, in which some clients 2 connect to the network by a radio link.

P2P is a means of distributing content that is very penalizing in radio networks. It generates symmetrical traffic on the upstream and downstream channels that share the radio resources (in TDMA or FDMA) because the peers download chunks but they also transmit them to other peers.

The scenario of a P2P application that distributes content live and managed by a service provider consisting of a set of "trackers" is considered. When a mobile client 2 connects to the P2P network, the tracker transmits the information on the client 2 (IP address) and the list of potential sources to the NAME 4. The NAME 4 chooses the most interesting entities according to the network information. It communicates to the tracker a list of fake IP addresses. The tracker communicates these addresses to the P2P mobile client 2. Thus neither the tracker nor the P2P client knows the actual peer list retained by the NOM 4 and therefore can not infer the choices made by the network in an attempt to collect information. At the same time, a GCS 5 at the RNC radio controller of the client 2 receives the configuration established by the NOM 4 defining the parameters of interception and control of the sessions.

When running the application, the P2P 2 client creates TCP sessions intercepted by GCS 5. The latter then creates TCP sessions with the entities chosen by NOM 4. The client sends requests to the list. peer, rerouted by the GCS 5. It receives pieces of data ("data chunks") relayed by the GCS 5 in a transparent mode of operation with termination of sessions.

When the client 2 receives requests for transmission of pieces of data sent by peers in its list, they are intercepted by the GCS 5 which does not forward them to the client 2. It is responsible for responding according to the pieces of data 53. In this way, the P2P mobile client 2 never receives retransmission requests and the previously committed radio resources for data link transmissions on the upstream link are saved.

Claims

A management device (4; 10) of at least one network session, an application data transmission medium and established by a destination entity (2), the management device comprising:

a network information management module (41) for obtaining information (NTW.) relating to an underlying transport network (6),

a service information management module (42) for obtaining information relating to an application, the information relating to the application comprising at least one identifier of a source entity (3) associated with the application,

a configuration module (43) for determining an application data transmission pattern based on the network information (NTW.) and application information, and

a control module (44) for controlling a network session control device (5; 10) according to the determined configuration,

characterized in that the determined configuration comprises at least one interception rule as a function of at least one information relating to the said at least one session, a processing to be implemented on the said at least one session and the said at least one identifier a source entity associated with the application,

the control module (44) being configured to transmit the determined configuration to said network session control device (5; 10).

The management apparatus of claim 1, wherein the interception rule further comprises at least one identifier of a dummy source entity (@ IPX1, @ IPX2, @ IPX3;

ID X2, ID X3) associated with said identifier of the corresponding source entity (3), and the control module (44) is furthermore arranged to transmit said at least one identifier of a fictitious source entity to said at least one entity destination (2).

3. Management device (4) according to claim 1, wherein

the network information management module (41) is configured to obtain information relating to the transport network (6) repeatedly during an application data transmission session,

the service information management module (42) being configured to obtain information relating to the application repeatedly during an application data transmission session, the configuration module (43) being configured to determine a new configuration in response to a change in the transport network information or application information obtained,

the control module (44) being configured to control the network session control device (5) according to the new configuration.

The management device (4) according to claim 1, wherein the transmission configuration comprises the choice of a transmission mode of the application data between the network session control device (5) and said at least one entity. source (3).

The management device (4) of claim 1, wherein the transmission configuration comprises the selection of a subset of source entities (3).

The management device (4) according to claim 1, wherein the transmission configuration comprises aggregating an application data transmission for a plurality of different destination entities (2) in a same session between the control device. network sessions (5) and at least one source entity (3).

The management device (4) according to claim 1, wherein the transmission configuration comprises the choice of a delivery mode and / or an application data transport protocol between the network session control device. (5) and said at least one source entity (3).

8. Management device (4) according to claim 1, wherein the transmission configuration comprises the implementation of a network resource.

9. Management device (4) according to claim 2, wherein the transmission configuration comprises the choice of a transparent mode, wherein only said at least one identifier of a fictitious source entity is transmitted to said at least one entity. destination (2).

The management device (4) of claim 1, wherein the transmission configuration comprises choosing a non-transparent mode, wherein the control module (44) is configured to transmit information relating to the configuration of the the network session to the at least one destination entity (2).

A method of managing a network session, an application data transmission medium and established by a destination entity (2), the management method comprising the following steps implemented by a management device (4; 10). :

a step (El) for obtaining information relating to an underlying transport network (6), a step (E2) for obtaining information relating to an application, the information relating to the application comprising at least an identifier of a source entity associated with the application, a step (E3) of determining a configuration (CONF) of transmission of the application data, as a function of the information relating to the underlying transport network (6) and information about the application, and

a step (E4) of controlling a network session control device (5; 10) according to the determined configuration,

the control step comprising transmitting the determined configuration to said network session control device (5; 10).

12. Network session control device (5; 10), application data transmission media established by a destination entity (2), the network session control device comprising:

a transport and session management module (51) for receiving a configuration command issued by a management device (4; 10) according to claim 1, the configuration command including at least one interception rule as a function of at least one information relating to at least one of said sessions, a processing to be implemented on said at least one session and at least one identifier of a source entity associated with an application,

an interception module (55) for intercepting sessions according to the intercepting rule received,

a processing module (52, 53, 54) for implementing a processing on an intercepted session according to the configuration command.

The network session control device (5) according to claim 12, wherein the transport and session management module (51) is configured to receive a configuration command repeatedly during a transmission session of application data, wherein the processing module (52, 53, 54) is configured to implement a processing according to the last received configuration command.

14. Transmission method for an application service, said method being implemented by a network session control device (5, 10), the application service comprising at least one application data transmission session between at least one entity source (3) and at least one destination entity (2), the transmission method comprising: a step (F1) for receiving a configuration command issued by a management device (4) according to claim 1, the command of configuration including at least one interception rule according to at least one information relating to said at least one session, a processing to be implemented on said at least one session and at least one identifier of a source entity associated with a application,

a step (F21, F22) of interception of sessions according to the intercepting rule received,

a processing step (F23, F24) for implementing a processing on the intercepted session according to the configuration command.

A computer program comprising instructions for executing the steps of a management method according to claim 11 or a transmission method according to claim 14 when said program is executed by a computer.

Computer-readable recording medium, comprising instructions of a computer program according to claim 15.