[go: up one dir, main page]

WO2025061515A1 - Procédés, dispositifs et système de contrôle d'une communication dans un réseau - Google Patents

Procédés, dispositifs et système de contrôle d'une communication dans un réseau Download PDF

Info

Publication number
WO2025061515A1
WO2025061515A1 PCT/EP2024/075172 EP2024075172W WO2025061515A1 WO 2025061515 A1 WO2025061515 A1 WO 2025061515A1 EP 2024075172 W EP2024075172 W EP 2024075172W WO 2025061515 A1 WO2025061515 A1 WO 2025061515A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
network
communication
server
control interface
Prior art date
Application number
PCT/EP2024/075172
Other languages
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2025061515A1 publication Critical patent/WO2025061515A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements

Definitions

  • the invention belongs to the field of telecommunications, and more particularly to the field of value-added IP services. More specifically, the invention relates to methods and devices for applying differentiated processing to data packets exchanged between a terminal and a server via a communications network.
  • Modern communications networks expose application programming interfaces (or APIs) that allow all or part of the services they support to be invoked.
  • 5G networks support the Network Exposure Function (NEF), which is designed to expose the functional capabilities of 5G core networks to third parties, including to “non-3GPP” environments such as fixed IP/MPLS networks.
  • NEF Network Exposure Function
  • Such APIs allow, for example, service developers (or providers) to dynamically adapt the quality of service policy implemented in a network according to the services they offer or the needs of the customers accessing these services.
  • a server e.g., an application server or a remote terminal
  • an API or control interface
  • a server can discover and invoke an API (or control interface) of the network to which a particular client connects in order to offer this client differentiated treatment such as a quality of service adapted to the service exposed by said application server.
  • differentiated treatments can be envisaged, such as isolation of traffic characteristic of the service accessed by a client, special protection of said traffic, routing of said traffic via secure tunnels, or which exploits redundant paths, etc.
  • the terminal obtains the characteristics of one or more interfaces exposed by one or more networks to which said terminal is connected and indicates them to an application server that it wishes to access by transmitting this information in a message.
  • the server does not have to know in advance the characteristics of the APIs exposed by all the networks likely to be used by its clients to contact it.
  • the application server can invoke an API exposed by a network used by a particular client and request particular resources offered by this network in order to adapt the quality of service policy provided by said application server for this particular client, for example.
  • the terminal obtains the characteristic information of at least one control interface exposed by the network in a DHCP message, a PCO (Protocol Configuration Option) information element or a “Neighbor Discovery” message.
  • a PCO Protocol Configuration Option
  • Such an arrangement advantageously allows a terminal to obtain information characteristic of at least one network control interface upon its attachment to the network or upon its configuration by the network.
  • the information characteristic of the API exposed by the network may advantageously be transmitted in a network attachment message, a terminal configuration message or a discovery message.
  • the information is transmitted in an optional header, so that the information may be ignored when it is not supported by a terminal.
  • the identifier, address and/or type of network API received allows the terminal to know how to access the API.
  • the rules governing the conditions for applying a configuration correspond, for example, to filters dependent on the destination address, the protocol used (e.g. UDP, TCP, QUIC, HTTP, or SIP), etc.
  • the protocol used e.g. UDP, TCP, QUIC, HTTP, or SIP
  • the opaque parameter is, for example, a token generated by the network that allows the terminal to be identified in the network without disclosing to third parties information specific to the terminal or its user, and therefore potentially confidential. In doing so, the network operator does not disclose information that is likely to be used by third parties for tracking or profiling purposes.
  • the terminal transmits the information characteristic of at least one control interface exposed by the network to the server in a TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) option field, a QUIC frame, a DCCP (Datagram Congestion Control Protocol) option, an HTTP (Hypertext Transfer Protocol) or SIP (Session Initiation Protocol) header.
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • QUIC User Datagram Protocol
  • DCCP Datagram Congestion Control Protocol
  • HTTP Hypertext Transfer Protocol
  • SIP Session Initiation Protocol
  • the terminal By transmitting information about the control interface exposed by the network in a field or header of a communication setup message according to a transport layer protocol, for example in a TCP option, a UDP extension, a DCCP extension, a QUIC frame, or an application layer protocol such as an HTTP or SIP header, the terminal ensures that the application server discovers the network control interfaces as early as possible in order to configure access to the service.
  • a transport layer protocol for example in a TCP option, a UDP extension, a DCCP extension, a QUIC frame, or an application layer protocol such as an HTTP or SIP header
  • the terminal By transmitting information about the control interface exposed by the network in a field or header of a communication setup message according to a transport layer protocol, for example in a TCP option, a UDP extension, a DCCP extension, a QUIC frame, or an application layer protocol such as an HTTP or SIP header, the terminal ensures that the application server discovers the network control interfaces as early as possible in order to configure access
  • the method further comprises a step of receiving a message transmitted by the server, the message comprising at least one packet identification instruction obtained by the server via at least one network control interface whose characteristics have been transmitted to the server by the terminal, the communication step comprising the generation of at least one data packet in accordance with said identification instructions.
  • the server When the server invokes a control interface of a network whose characteristics have been transmitted by the terminal, the server obtains instructions for generating data packets comprising an identifier from which the network can apply differentiated processing to said packets, and transmits these instructions to the terminal.
  • an identification instruction may consist of a marking identifier, a token, a particular tag or any other information suitable for the network to be able to identify the packet and apply particular processing to it according to the configuration requested by the server. In this way, the network can apply differentiated processing to the data packets transmitted by the terminal to the server.
  • an application server receives indications allowing it to invoke an API exposed by a particular communication network used by the terminal to contact the server and thus control the configuration of this network to apply differentiated treatment to the data packets exchanged between the terminal and the server.
  • These indications are obtained by the terminal from a dedicated function of the network, for example when it attaches to the network, and transmitted to the server so that the network can carry out a network configuration adapted to the service that the server provides to this terminal.
  • the method advantageously allows an application server to invoke a particular network configuration without knowing a priori the characteristics of the networks likely to be used by the terminals to connect to the service. Data packets can thus be exchanged between the terminal and the server while benefiting from differentiated treatment.
  • control method further comprises a step of obtaining, from the invoked control interface, at least one identification instruction for the packets exchanged with the terminal, the packets sent during the sending step being generated in accordance with said identification instructions obtained.
  • the server thus obtains instructions enabling it to generate data packets comprising an identifier from which the network can apply differentiated processing.
  • an identification instruction may consist of a marking identifier, a token, a particular tag or any other suitable information that the server can insert into the data packets sent to the terminal so that they are transmitted via the network by requesting particular resources invoked via the control interface of said network.
  • control method is such that it further comprises a step of obtaining, from the invoked control interface, at least one identification instruction for the packets exchanged with the terminal, and a step of receiving at least one data packet transmitted by the terminal by requesting resources of said network invoked via said control interface, the packets received being generated by the terminal in accordance with said transmitted identification instructions.
  • the operator of the AS service can use the API exposed by the network 102 to request that a particular quality of service policy can be implemented for the benefit of the user of the terminal 100 when the latter accesses its services.
  • the operator of the AS service can use the API exposed by the network 104 to request that a particular quality of service policy can be implemented for the benefit of the user of the terminal 101 when the latter accesses its services.
  • the terminal 100 of the implements a particular embodiment of the communication establishment method and the AS server represented on the implements the control method according to a particular embodiment.
  • This information is transmitted to the terminal in a message sent by a network function, for example a CTRL controller, a DHCP server or an access router.
  • a network function for example a CTRL controller, a DHCP server or an access router.
  • Such a message is for example sent following a request from the terminal, that is to say in response to a message sent by the terminal.
  • a message can also be sent without prior request, that is to say the network announces this information to the terminals without waiting for an explicit request from these terminals.
  • the information is obtained by the terminal when it attaches to the network.
  • the terminal sends, for example, a DHCP request including a particular option to a device on the network.
  • the reception of such a DHCP request by the network device causes the sending of a DHCP response including, in addition to the data traditionally included in such a message, information characteristic of the configuration interfaces exposed to third parties by the network.
  • This information is, for example, transmitted in one or more DHCP options as defined in the RFC8415 document.
  • the received information may include one or more instructions allowing the terminal to generate an opaque identifier itself.
  • the presence of a "Self_Terminal_ID” parameter set to "1" is an explicit indication that the terminal must generate a non-persistent identifier. If the network returns this parameter, then it must not include “Terminal_ID” in the same message.
  • This variant is advantageous because it avoids exposing information that is probably invariant over time and could be used for malicious purposes (e.g., terminal tracking).
  • the terminal sends a message 400, such as a DHCP request including a particular option.
  • the option is particular in that it allows the terminal to indicate that it wishes to receive indications relating to one or more control interfaces exposed by this network.
  • the destination network function receives this request, and when said particular option is present in the request, said network function inserts information characteristic of at least one control interface in a response 401, for example a DHCP response including a particular option.
  • this information can be encoded in the same information element or be returned separately without it being necessary to modify the invention.
  • DHCPv6 option header including information characteristic of a control interface exposed by the network.
  • the type of the option “OPTION_V6_TANIT” and its length “Length” are each encoded on 16 bits.
  • the option also includes a 16-bit "API_ID” field conveying an identifier of an API exposed by the network preceded by its length "API_ID_LENGTH", an address of a server exposing said API "API_LOCATORS” also preceded by the length of the "API_LOCATORS_Length” field, a field including a set of rules for using the API "CRE” preceded by its length “CRE_LENGTH", an API type "API_TYPE” and an opaque identifier assigned to the terminal "Terminal_ID”.
  • the structure of the is given as a non-limiting example, and other formats may be considered for conveying this information.
  • the structure may include a number and types of parameters that differ from those shown in the example of the , and these parameters can be passed in different options and/or different messages.
  • the terminal 100 stores the information received in association with a network identifier, for example a NID (Network Identifier) obtained in an “Access Network Domain Name” option of a DHCP response or with an identifier of the network interface through which the information was received.
  • a network identifier for example a NID (Network Identifier) obtained in an “Access Network Domain Name” option of a DHCP response or with an identifier of the network interface through which the information was received.
  • NID Network Identifier
  • the communication establishment method comprises a step 202 during which the terminal 100 transmits the information obtained in step 200 to the application server AS.
  • the terminal 100 when the terminal 100 wishes to establish communication with the AS server via a network to which it is connected, it searches in its memory for an entry corresponding to the identifier of this network with which are associated information characteristic of one or more control interfaces exposed by the network. If information relating to a control interface is available for the identifier sought, the terminal transmits this information to the AS server in a message.
  • this information is encoded and transmitted to the application server AS in the form of a TCP option, a UDP option, a DCCP option, a QUIC frame, or an HTTP or SIP header.
  • step 202 is preceded by an optional step 201 during which the terminal 100 transmits to the AS server a message 402 comprising an indication that it has the capacity to transmit information characteristic of one or more control interfaces exposed by a network to which it is connected and receives in return a message 403 from the AS server comprising an indication relating to the fact that the AS server is willing to receive such information.
  • the terminal knows whether the AS server to which it connects implements the control method which is the subject of the present invention and whether the AS server is willing to receive the information obtained by the terminal during step 200.
  • the message 402 is a TCP SYN segment exchanged with the AS server during the TCP connection establishment phase (“handshake” in English), and the message 403 is a SYN/ACK segment exchanged during this same TCP connection establishment phase.
  • the AS server is suitable for receiving information concerning the interfaces exposed by the network and as transmitted by the terminal.
  • An error message received from the server is an indication that it is not suitable for receiving such information.
  • the terminal 100 When the terminal 100 receives from the AS server the message 403, confirming that the AS server is suitable for receiving information relating to control interfaces exposed by the network 102, it implements a step 202 during which it transmits to the AS server at least one message 404 comprising an announcement of the network API associated with the network via which the communication is established.
  • the message 404 is for example a TCP option, a UDP option, a QUIC frame, a DCCP option, etc.
  • the terminal 100 sends the information relating to at least one control interface to the AS server in a message 404 comprising a descriptor which announces the network API associated with the network via which the communication is established.
  • the terminal 100 can announce the characteristic information of the APIs of the other networks via which certain flows of said communication can transit, and the terminal can also include the APIs of these other networks.
  • the message 404 can comprise descriptors relating to the control interfaces of the networks 102 and 104.
  • the characteristic information of an API must in particular specify the identifier of the network. This identifier can be an address identifier (AddressID), an IP address, an autonomous system number (ASN), etc.
  • the terminal 100 may further insert a “TERMINAL_SUPPLIED_ID” token to assist the network in correlating the identifier presented by the server with an identifier of the terminal as known by the network.
  • “TERMINAL_SUPPLIED_ID” is a copy of the “TERMINAL_ID”.
  • the terminal 100 can receive an optional message 410 during a step 203, comprising a marking identifier generated by the network 102.
  • the marking identifier is intended to be inserted into the messages transmitted by the terminal 100 to the AS server so that the messages transmitted by the terminal 100 to the AS server can benefit from differentiated processing by the network 102 configured following a request from the AS server based on the information transmitted to the AS server in the message 404.
  • the network applies special processing to these messages.
  • This identifier can be, for example, a QUIC connection identifier (Source or Destination Connection Identifier), a DSCP value (“Diffserv Code Point”), a value of the Flow Label field of an IPv6 packet header, etc.
  • the identifier can be encoded in one or more fields of a message.
  • Identification is typically performed by an edge node such as an access router or an interconnect router. Such a node may maintain, remove, or rewrite the identifying information before forwarding the packet and invoking the resources necessary to apply differentiated processing.
  • edge node such as an access router or an interconnect router.
  • the terminal 100 exchanges data packets with the AS server by requesting resources of said network invoked by the server via the control interface indicated by the terminal.
  • the network may apply particular traffic classification rules, or transmit the data packets to a particular network slice.
  • the method comprises a first step 300 during which the AS server receives a first message 402 from the terminal 100, the message 402 comprising an indication that the terminal 100 has the capacity to transmit information characteristic of one or more control interfaces exposed by the network 102 to which it is connected.
  • a message is for example a control message or a data message.
  • it may be a TCP SYN segment exchanged during a TCP connection establishment phase comprising a TCP option in which the capacities of the terminal 100 to transmit the information relating to interfaces exposed by the network 102 are encoded.
  • Other examples include the encoding of the information in a UDP option, a DCCP option or a QUIC transport parameter.
  • the AS server Upon receipt of the message 402, the AS server detects the presence in this message of an indication that the terminal 100 has the capacity to transmit information characteristic of one or more configuration interfaces exposed by the network 102. The AS server then responds to the terminal 100 with a message 403 in which it inserts a particular indication confirming that it is suitable for receiving such information. This response is for example transmitted in a TCP SYN/ACK segment of the TCP connection establishment phase, or in a UDP option, or in a DCCP option or according to a QUIC transport parameter.
  • This preliminary exchange of messages allows the terminal 100 and the AS server to exchange their capabilities to implement the methods according to the invention.
  • the terminal and the server can be configured beforehand in accordance with a standard requiring support for methods in accordance with the present invention, making the preliminary step of exchanging capabilities unnecessary.
  • the network API can record in the response 406 to the request 405 traffic classification information which can be communicated in advance by the server to terminals in order to facilitate the establishment of future communications under the same service.
  • the aim of this mode is to optimize the time required to set up differentiated treatment for these terminals when they connect to the service.
  • FIG. 800 There represents an architecture of a device 800 adapted to implement the method of controlling a communication, according to a particular embodiment.
  • the code instructions of the computer program 803 are for example loaded into the memory 801 before being executed by the processor of the processing unit 802.
  • the microprocessor of the processing unit 802 implements, according to the instructions of the computer program 803, the steps of the method for controlling a communication as described previously with reference to FIGS. 3 and 4.
  • the device 800 comprises communication means 804, for example a 3G, 4G, 5G cellular network interface, Wi-Fi® or Wimax® wireless network, an optical interface or an Ethernet interface.
  • the communication means enable the device 800 to connect to a communication network and exchange data with other devices.
  • the device 800 also comprises a module 805 for receiving a message transmitted by a terminal comprising at least one piece of information characteristic of a control interface exposed by a network to which the terminal is connected.
  • the module 805 cooperates with the communication means 804 to implement a data transmission protocol, for example a TCP, UDP, QUIC or other protocol, and receive a data structure, for example a TLV field of a data packet comprising at least the address of a control interface (or API) exposed by the network to which the terminal is connected and an identifier of the terminal.
  • a data transmission protocol for example a TCP, UDP, QUIC or other protocol
  • receive a data structure for example a TLV field of a data packet comprising at least the address of a control interface (or API) exposed by the network to which the terminal is connected and an identifier of the terminal.
  • the device 800 finally comprises a data transmission module 807 adapted to mark data packets intended for the terminal having transmitted the characteristic information of a network control interface received by the module 805.
  • the module 807 is implemented by computer program instructions and cooperates with the communication means 804 to send data packets to the terminal by requesting network resources invoked via said control interface, the packets sent being marked using the marking information obtained by the configuration module 806.
  • the device 800 is integrated into an application server.

Landscapes

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

Abstract

L'invention concerne un procédé d'établissement d'une communication entre un terminal et un serveur par l'intermédiaire d'un réseau de communication exposant au moins une interface de contrôle, le procédé comprenant une étape d'obtention (200) d'une information caractéristique d'au moins une interface de contrôle exposée par le réseau, une étape (202) de configuration au cours de laquelle le terminal transmet au serveur d'application au moins une partie de ladite information obtenue, et une étape (204) de communication au cours de laquelle le terminal échange des paquets de données avec le serveur en sollicitant des ressources dudit réseau invoquées par le serveur par l'intermédiaire de l'interface de contrôle indiquée par le terminal. Corrélativement, l'invention concerne un procédé de contrôle, par un serveur d'application, d'une communication établie selon le procédé d'établissement, ainsi que des dispositifs pour mettre en œuvre ces procédés.

Description

Procédés, dispositifs et système de contrôle d’une communication dans un réseau
L'invention appartient au domaine des télécommunications, et plus particulièrement au domaine des services IP à valeur ajoutée. Plus précisément, l’invention concerne des procédés et des dispositifs pour appliquer un traitement différencié à des paquets de données échangés entre un terminal et un serveur par l’intermédiaire d’un réseau de communication.
 Art antérieur
Les réseaux de communication modernes exposent des interfaces de programmation applicatives (ou API, pour « Application Program Interface » en anglais) qui permettent d’invoquer tout ou partie des services qu’ils supportent. Par exemple, les réseaux 5G supportent la fonction NEF (pour « Network Exposure Function » en anglais), qui a pour vocation d’exposer les capacités fonctionnelles des réseaux cœur 5G à des tiers, y compris à des environnements « non 3GPP » comme des réseaux fixes IP/MPLS. De telles API permettent par exemple à des développeurs (ou des fournisseurs) de services d’adapter dynamiquement la politique de qualité de service mise en place dans un réseau selon les services qu’ils proposent ou les besoins des clients qui accèdent à ces services.
Les méthodes existantes pour invoquer ces API supposent généralement la mise en place préalable d’accords contractuels entre l’opérateur du réseau et les tiers souhaitant y accéder. La nécessité d’établir de tels accords a priori présente des limitations, notamment parce qu’il apparaît difficile pour un fournisseur de service de connaître a priori l’ensemble des réseaux susceptibles d’être utilisés par ses clients pour se connecter à un service. Par exemple, un opérateur d’une plateforme de vidéo à la demande peut difficilement convenir d’un accord préalable avec tous les opérateurs des réseaux susceptibles d’être utilisés par ses clients pour accéder au service.
En outre, de tels accords ne permettent pas facilement de maintenir à jour une liste d’adresses permettant d’invoquer une API réseau particulière (par exemple, en cas de modification de l’alias ou de l’adresse IP pour joindre une API ou lorsque des API différentes sont utilisées selon le périmètre fonctionnel de cette API).
Ainsi, il existe un besoin pour une méthode permettant à un fournisseur de service d’offrir une qualité de service personnalisée à ses clients au moyen d’API exposées par les différents réseaux qu’ils utilisent, et qui ne souffre pas les limitations évoquées ci-dessus.
A cet effet, il est proposé un procédé d’établissement d’une communication entre un terminal et un serveur par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le procédé comprenant les étapes suivantes, mises en œuvre par le terminal :
  • Une étape d’obtention d’une information caractéristique de l’au moins une interface de contrôle exposée par le réseau,
  • Une étape de configuration au cours de laquelle le terminal transmet au serveur d’application au moins une partie de ladite information obtenue,
  • Une étape de communication au cours de laquelle le terminal échange des paquets de données avec le serveur en sollicitant des ressources dudit réseau invoquées par le serveur par l’intermédiaire de l’interface de contrôle indiquée par le terminal.
De cette façon, un serveur (par ex. un serveur d’application ou un terminal distant) peut découvrir et invoquer une API (ou interface de contrôle) du réseau auquel se connecte un client particulier afin d’offrir à ce client un traitement différencié tel qu’une qualité de service adaptée au service exposé par ledit serveur d’application. Bien entendu, d’autres traitements différenciés peuvent être envisagés, comme une isolation du trafic caractéristique du service auquel accède un client, une protection particulière dudit trafic, un acheminement dudit trafic via des tunnels sécurisés, ou qui exploite des chemins redondants, etc.
Le terminal obtient les caractéristiques d’une ou plusieurs interfaces exposées par un ou plusieurs réseaux auxquels ledit terminal est connecté et les indique à un serveur d’application auquel il souhaite accéder en transmettant ces informations dans une message. Ainsi, le serveur n’a pas à connaître au préalable les caractéristiques des API exposées par tous les réseaux susceptibles d’être utilisés pas ses clients pour le contacter.
A partir des caractéristiques reçues, le serveur d’application peut invoquer une API exposée par un réseau utilisé par un client particulier et solliciter des ressources particulières offertes par ce réseau afin d’adapter la politique de qualité du service fourni par ledit serveur d’application pour ce client particulier, par exemple.
Les paquets envoyés et/ou reçus par le terminal lorsqu’il communique avec le serveur bénéficient alors d’un traitement différencié par le réseau, permettant par exemple d’optimiser certaines caractéristiques de transmission (latence, débit, priorité, etc.) ou encore d’emprunter une tranche réseau particulière.
Dans un mode de réalisation particulier, le terminal obtient l’information caractéristique d’au moins une interface de contrôle exposée par le réseau dans un message DHCP, un élément d’information PCO (Protocol Configuration Option) ou un message « Neighbor Discovery ».
Une telle disposition permet avantageusement à un terminal d’obtenir une information caractéristique d’au moins une interface de contrôle du réseau dès son attachement au réseau ou lors de sa configuration par le réseau. L’information caractéristique de l’API exposée par le réseau peut avantageusement être transmise dans un message d'attachement au réseau, un message de configuration du terminal ou un message de découverte. De préférence, l’information est transmise dans un entête optionnel, de sorte que l’information peut être ignorée lorsqu’elle n'est pas supportée par un terminal.
La transmission de l’information dans un élément d’information PCO (« Protocol Configuration Option » en anglais) d’un message NAS (« Non-Access Stratum » en anglais) tel que défini par le 3GPP (« 3rd Partnership Project ») ou la transmission de l’information dans un message de découverte IPv6 « Neighbor Discovery » tel que défini dans le standard RFC4861 permet de communiquer l’information dès l’établissement d’une session.
Selon une réalisation particulière, le procédé est tel que l’information caractéristique d’au moins une interface de contrôle exposée par le réseau comprend au moins un élément sélectionné parmi les éléments suivants :
  • Un identifiant d’API réseau,
  • Au moins une adresse d’accès à une API réseau,
  • Un type d’API réseau,
  • Une ou plusieurs règles régissant les conditions d’applications d’une configuration,
  • Une donnée d’identification opaque du terminal.
L’identifiant, l’adresse et/ou le type d’API réseau reçue permettent au terminal de connaître les modalités d’accès à l’API.
Les règles régissant les conditions d’application d’une configuration correspondent par exemple à des filtres dépendants de l’adresse destination, du protocole utilisé (par ex. UDP, TCP, QUIC, HTTP, ou SIP), etc.
Le paramètre opaque est par exemple un jeton généré par le réseau permettant d’identifier le terminal dans le réseau sans pour autant divulguer à des tiers des informations propres au terminal ou à son utilisateur et donc potentiellement confidentielles. Ce faisant, l’opérateur réseau ne divulgue pas des informations qui sont susceptibles d’être utilisées par des tiers pour des besoins de traçabilité (« tracking » ou « profiling » en anglais).
Les informations caractéristiques reçues peuvent être mémorisées par le terminal en association avec un identifiant du réseau et transmise à un serveur d’application en vue de configurer le réseau pour le service auquel le terminal souhaite accéder.
Selon un mode de réalisation particulier, le terminal transmet l’information caractéristique d’au moins une interface de contrôle exposée par le réseau au serveur dans un champ d’option TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol), une trame QUIC, une option DCCP (Datagram Congestion Control Protocol), un entête HTTP (Hypertext Transfer Protocol) ou SIP (Session Initiation Protocol).
En transmettant les informations concernant l’interface de contrôle exposée par le réseau dans un champ ou un entête d’un message d'établissement de communication selon un protocole de la couche transport, par exemple dans une option TCP, une extension UDP, une extension DCCP, une trame QUIC, ou encore un protocole de la couche application tel qu’un entête HTTP ou SIP, le terminal s’assure que le serveur d’application découvre au plus tôt les interfaces de contrôle du réseau afin de configurer l’accès au service. En outre, l’utilisation d’entêtes optionnels de messages permet de mettre en œuvre le procédé de l’invention avec des moyens techniques existants, facilitant ainsi le déploiement de la solution baptisée TANIT (pour « Terminal-Assisted dissimeNation of application programming Interfaces locaTors for network exposure » en anglais).
Selon un mode particulier de réalisation, le procédé comprend en outre une étape de réception d’un message transmis par le serveur, le message comprenant au moins une consigne d’identification des paquets obtenue par le serveur via au moins une interface de contrôle du réseau dont les caractéristiques ont été transmises au serveur par le terminal, l’étape de communication comprenant la génération d’au moins un paquet de données conformément auxdites consignes d’identification.
Lors de l’invocation par le serveur d’une interface de contrôle d’un réseau dont les caractéristiques ont été transmises par le terminal, le serveur obtient des consignes permettant de générer des paquets de données comprenant un identifiant à partir duquel le réseau peut appliquer auxdits paquets un traitement différencié, et transmet ces consignes au terminal. Par exemple, une consigne d’identification peut consister en un identifiant de marquage, un jeton, un tag particulier ou tout autre information adaptée pour que le réseau puisse identifier le paquet et lui appliquer un traitement particulier selon la configuration demandée par le serveur. De cette façon, le réseau peut appliquer un traitement différencié aux paquets de données transmis par le terminal à destination du serveur.
De façon correspondante au procédé d’établissement d’une communication, il est également proposé un procédé de contrôle d’une communication entre un terminal et un serveur par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le procédé comprenant les étapes suivantes, mises en œuvre par le serveur :
  • Réception d’un message transmis par le terminal, ledit message comprenant au moins une information caractéristique d’une interface de contrôle exposée par un réseau auquel est connecté le terminal,
  • Invocation d’au moins une interface de contrôle identifiée à partir de ladite information caractéristique,
  • Envoi d’au moins un paquet de données vers le terminal et/ou réception d’au moins un paquet de données en provenance du terminal, les paquets étant acheminés en sollicitant des ressources dudit réseau invoquées via ladite interface de contrôle.
De cette façon, un serveur d’application reçoit des indications lui permettant d’invoquer une API exposée par un réseau de communication particulier utilisé par le terminal pour contacter le serveur et contrôler ainsi la configuration de ce réseau pour appliquer un traitement différencié aux paquets de données échangées entre le terminal et le serveur. Ces indications sont obtenues par le terminal auprès d’une fonction dédiée du réseau, par exemple lors de son attachement au réseau, et transmises au serveur afin que le réseau puisse procéder à une configuration réseau adaptée au service que le serveur fournit à ce terminal. Le procédé permet avantageusement à un serveur d’application d’invoquer une configuration réseau particulière sans connaître à priori les caractéristiques des réseaux susceptibles d’être utilisés par les terminaux pour se connecter au service. Des paquets de données peuvent ainsi être échangés entre le terminal et le serveur en bénéficiant d’un traitement différencié.
Selon un mode particulier de réalisation, le procédé de contrôle comprend en outre une étape d’obtention, à partir de l’interface de contrôle invoquée, d’au moins une consigne d’identification des paquets échangés avec le terminal, les paquets envoyés au cours de l’étape d’envoi étant générés conformément auxdites consignes d’identification obtenues.
Le serveur obtient ainsi des consignes lui permettant de générer des paquets de données comprenant un identifiant à partir duquel le réseau peut appliquer un traitement différencié. Par exemple, une consigne d’identification peut consister en un identifiant de marquage, un jeton, un tag particulier ou tout autre information adaptée que le serveur peut insérer dans les paquets de données envoyés à destination du terminal pour qu’ils soient transmis via le réseau en sollicitant des ressources particulières invoquées via l’interface de contrôle dudit réseau.
Selon un mode de réalisation particulier, le procédé de contrôle est tel qu’il comporte en outre une étape d’obtention, à partir de l’interface de contrôle invoquée, d’au moins une consigne d’identification des paquets échangés avec le terminal, et une étape de réception d’au moins un paquet de données transmis par le terminal en sollicitant des ressources dudit réseau invoquées via ladite interface de contrôle, les paquets reçus étant générés par le terminal conformément auxdites consignes d’identification transmises.
De cette façon, le terminal dispose de la consigne d’identification lui permettant de générer des paquets comprenant une information d’identification permettant au réseau d’appliquer un traitement différencié selon l’information d’identification. Ainsi, le serveur reçoit des paquets de données auxquels le réseau a appliqué un traitement différencié sur la base de l’information d’identification insérée dans les paquets par le terminal.
Selon une réalisation particulière, le procédé de contrôle est tel que l’information caractéristique d’au moins une interface de contrôle exposée par le réseau comprend au moins un élément sélectionné parmi les éléments suivants :
  • Un identifiant d’API réseau,
  • Au moins une adresse d’accès à une API réseau,
  • Un type d’API réseau,
  • Une ou plusieurs règles régissant les conditions d’applications d’une configuration,
  • Une donnée d’identification opaque du terminal.
Dans un mode particulier de réalisation, le procédé de contrôle est tel que l’information caractéristique d’au moins une interface de contrôle exposée par le réseau est reçue dans un champ d’option TCP ou UDP, une trame QUIC, une option DCCP, un entête HTTP ou SIP.
L’information caractéristique peut ainsi être transmise dans un message d’un protocole de la couche de transport (TCP, UDP, QUIC ou DCCP par exemple) ou bien dans un message d’un protocole de la couche applicative (comme SIP ou HTTP par exemple). D’autres modes de réalisation peuvent être considérés tels que l’utilisation d’une option IPv4 ou un entête d’extension IPv6 (« Extension Header » en anglais). A noter que l’utilisation de la couche IP pour véhiculer l’information caractéristique d’au moins une interface de contrôle exposée par le réseau est plus robuste en cas de communications limitées à un seul domaine (par ex. « Limited Domains », « controlled environment », ou « managed networks »).
Selon un autre aspect, l’invention concerne un dispositif d’établissement d’une communication avec un serveur par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le dispositif comprenant un processeur couplé à une mémoire dans laquelle sont enregistrées des instructions adaptées pour mettre en œuvre les étapes suivantes :
  • Une étape d’obtention d’une information caractéristique de l’au moins une interface de contrôle exposée par le réseau,
  • Une étape de configuration au cours de laquelle le terminal transmet au serveur d’application au moins une partie de ladite information obtenue,
  • Une étape de communication au cours de laquelle le terminal échange des paquets de données avec le serveur en sollicitant des ressources dudit réseau invoquées par le serveur par l’intermédiaire d’une interface de contrôle indiquée par le terminal.
L’invention vise aussi un terminal de communication comprenant un dispositif d’établissement d’une communication tel que décrit précédemment.
Selon encore un autre aspect, l’invention concerne un dispositif de contrôle d’une communication établie avec un terminal par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le dispositif comprenant un processeur couplé à une mémoire dans laquelle sont enregistrées des instructions adaptées pour mettre en œuvre les étapes suivantes :
  • Réception d’un message transmis par le terminal, ledit message comprenant au moins une information caractéristique d’une interface de contrôle exposée par le réseau de communication,
  • Invocation d’au moins une interface de contrôle identifiée à partir de ladite information caractéristique,
  • Envoi d’au moins un paquet de données vers le terminal et/ou réception d’au moins un paquet de données en provenance du terminal, les paquets étant acheminés en sollicitant des ressources dudit réseau invoquées via ladite interface de contrôle.
L’invention concerne aussi un serveur comprenant un dispositif de contrôle d’une communication tel que décrit ci-dessus.
Il est également proposé un système de communication comprenant au moins un terminal de communication et un serveur comprenant respectivement un dispositif d’établissement de communication et un dispositif de contrôle tels que décrits ci-dessus.
Dans un mode particulier de réalisation, les différentes étapes du procédé d’établissement d’une communication et du procédé de contrôle sont déterminées par des instructions de programmes d’ordinateurs.
En conséquence, l’invention vise aussi un programme d’ordinateur comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de communication et/ou d’un procédé de contrôle tels que décrits ci-dessus, lorsque le programme est exécuté par un processeur.
Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise aussi un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé d’établissement d’une communication et/ou d’un procédé de contrôle.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, une mémoire flash, ou encore un moyen d'enregistrement magnétique, comme un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés en question.
Les différents modes ou caractéristiques de réalisation précités peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux étapes des procédés d’établissement de communication et/ou de contrôle.
Les dispositifs, systèmes et programmes présentent des avantages analogues à ceux des procédés auxquels ils correspondent.
 Brève description des figures
D'autres caractéristiques et avantages apparaîtront à la lecture d’un mode de réalisation préféré décrit en référence aux dessins annexés parmi lesquels :
  • la représente un environnement adaptée pour mettre en œuvre les procédés d’établissement d’une communication et de contrôle d’une communication selon un mode particulier de réalisation,
  • la est un ordinogramme représentant les principales étapes d’un procédé d’établissement d’une communication selon un mode de réalisation particulier,
  • la est un ordinogramme représentant les principales étapes d’un procédé de contrôle d’une communication selon une réalisation particulière,
  • la est un diagramme combiné montrant les principales étapes des procédés d’établissement et de contrôle d’une communication et des échanges de messages adaptés pour mettre en œuvre ces procédés dans un mode particulier de réalisation,
  • la est un exemple de structure de données adaptée pour véhiculer des informations caractéristiques d’une interface de contrôle exposée par le réseau selon une réalisation particulière,
  • la montre un exemple de structure de données adaptée pour transmettre à un serveur une description d’une interface de contrôle exposée par le réseau selon une réalisation particulière,
  • la est un diagramme en bloc montrant une architecture d’un dispositif adapté pour mettre en œuvre le procédé d’établissement d’une communication selon une réalisation particulière, et
  • la est un diagramme en bloc montrant une architecture d’un dispositif adapté pour mettre en œuvre le procédé de contrôle d’une communication selon une réalisation particulière.
 Description détaillée
La représente une architecture réseau permettant à des terminaux d’accéder à des services.
L’environnement de la comprend un terminal 100 et un terminal 101 qui sont par exemple des terminaux de communication tels que des smartphones, des ordinateurs, des télévisions connectées, ou tout autres équipements adaptés pour accéder à un service. Un terminal au sens de cette description peut ainsi être un UE (« User Equipment » en anglais), une instance de fonction service, un CPE (pour «Customer Premises Equipment » en anglais), etc. Le terminal peut être mobile ou fixe.
L’environnement comprend un ou plusieurs serveurs d’application AS hébergés dans un réseau de communication 103. Un serveur AS héberge par exemple un ou plusieurs services, tels que des services de diffusion audiovisuels et/ou de stockage en ligne auxquels les utilisateurs des terminaux 100 et 101 ont souscrit et peuvent accéder. Bien entendu, un AS peut héberger tout type de service sans qu’il soit nécessaire de modifier l’invention. En outre, le service peut être offert par le serveur AS qui est en contact avec le terminal ou par d'autres serveurs non visibles au client (« back-end »). Aucune hypothèse n'est faite quant à la structure du service. Dans l’exemple de la , les serveurs AS sont opérés par un opérateur distinct des opérateurs des réseaux de communication 102 et 104 par l’intermédiaire desquels les terminaux 100 et 101 sont respectivement connectés.
Le réseau 102 est par exemple un réseau d’accès cellulaire, tel qu’un réseau 3G, 4G, 5G ou B5G («Beyond 5G » en anglais), ou un réseau Wi-Fi® ou encore WiMax® auquel le terminal 100 peut accéder.
Le réseau 104 est par exemple un réseau fixe, comme un réseau IP/MPLS (« Internet Protocol/ Multiprotocol Label Switching » en anglais). Dans l’exemple de la , le terminal 100 le terminal 101 peuvent accéder au réseau 104.
L’interconnexion des réseaux 102, 104 et 103 permet au terminal 100 d’accéder à un serveur d’application AS du réseau 103 par l’intermédiaire du réseau 102 et/ou du réseau 104, et permet au terminal 101 d’accéder à un serveur d’application AS du réseau 103 par l’intermédiaire du réseau d’accès 104.
Les réseaux 102 et 104 offrent la possibilité à des tiers de personnaliser le service rendu par le réseau au moyen d’interfaces de contrôle (ou API, pour Application Programming Interface) par lesquelles les réseaux 102 et 104 exposent certaines de leurs capacités fonctionnelles. L’interface de contrôle permet par exemple de configurer un marquage des paquets de certaines communications au sein du réseau de façon à offrir une qualité de service différenciée, et/ou d’acheminer certains paquets via des liens sécurisés ou redondants, par exemple. Dans la suite, aucune hypothèse n’est faite quant à la nature du traitement différencié contrôlé via une API exposée par un réseau. Les réseaux 102 et 104 comprennent en outre au moins un contrôleur CTRL, par exemple un contrôleur SDN (pour « Software-Defined Network » en anglais), chargé de coordonner les actions nécessaires à la mise en œuvre d’une configuration particulière. Dans certaines réalisations, la fonction de contrôle CTRL et la fonction NEF sont une même entité. Un ou plusieurs contrôleurs peuvent être déployés dans un réseau. Lesdites fonctions CTRL/NEF ne sont pas forcément sur le chemin emprunté par les paquets de données échangés entre un terminal et un serveur.
On notera que dans cette description, les termes « interface de contrôle réseau », « interface de configuration » et « API » sont indistinctement utilisés pour désigner un ensemble de fonctions mises à disposition des tiers par le réseau et accessibles à distance afin de permettre à des services, des applications ou des logiciels tiers de commander un paramétrage particulier et/ou un traitement différencié des flux par le réseau. Par exemple, lorsqu’un réseau met en œuvre des « network slices » (soit « tranches réseau » en français), l’utilisation d’une API permet par exemple d’affecter une tranche particulière à un service donné ou à l’acheminement d’une partie des paquets de données échangés pour ce service. Une tranche réseau peut être définie comme un réseau privé virtuel (RPV, ou VPN pour « Virtual Private Network » en anglais) déployé sur une infrastructure fixe ou mobile. Les caractéristiques d’une tranche réseau sont essentiellement exprimées en termes de capacité (bande passante) et de qualité de service (par ex., latence, temps de transit unidirectionnel, etc.), voire de sécurité (par ex., préservation de la confidentialité des informations transmises au sein du RPV moyennant l’utilisation de techniques de chiffrement).
Ainsi, et à titre d’exemple, l’opérateur du service AS peut utiliser l’API exposée par le réseau 102 pour demander qu’une politique de qualité de service particulière puisse être mise en œuvre au bénéfice de l’utilisateur du terminal 100 lorsque celui-ci accède à ses services. De même, l’opérateur du service AS peut utiliser l’API exposée par le réseau 104 pour demander qu’une politique de qualité de service particulière puisse être mise en œuvre au bénéfice de l’utilisateur du terminal 101 lorsque celui-ci accède à ses services.
Cependant, comme on l’a déjà indiqué, en l’état actuel de la technique, l’opérateur du service AS doit au préalable convenir d’accords avec les opérateurs des réseaux 102 et 104 pour découvrir et utiliser les API offertes par ces réseaux. Or, l’opérateur du service AS ne connaît pas à priori les réseaux qui seront utilisés par ses clients pour accéder à ses services.
Les procédés et dispositifs objets de la présente invention permettent de lever de telles limitations.
Un mode de réalisation particulier du procédé d’établissement d’une communication va maintenant être décrit en référence aux figures 2 et 4. Dans la description qui suit, le terminal 100 de la met en œuvre une réalisation particulière du procédé d’établissement de communication et le serveur AS représenté sur la met en œuvre le procédé de contrôle selon un mode particulier de réalisation.
La est un ordinogramme représentant les principales étapes d’un procédé d’établissement de communication selon un mode particulier de réalisation.
La est un diagramme de flux combiné montrant des échanges de messages entre un terminal, un serveur d’application et différentes entités d’un réseau auquel le terminal est connecté. Ce diagramme décrit les étapes des procédés d’établissement d’une communication et de contrôle, selon une réalisation particulière. Des références identiques sont utilisées dans les figures 2, 3 et 4 pour désigner les étapes des procédés d’établissement d’une communication et de contrôle.
Lors d’une première étape 200, le terminal 100 reçoit des informations caractéristiques d’une ou plusieurs interfaces de configuration du réseau auquel le terminal est connecté. Les informations reçues comprennent par exemple un ou plusieurs éléments parmi les éléments suivants :
  • un identifiant d’API réseau,
  • au moins une adresse d’accès à une API réseau (ou un alias, un nom de domaine),
  • un type d’API réseau (REST, RPC, SOAP, …),
  • une ou plusieurs règles régissant les conditions d’application d’une configuration (CRE, pour « Classification Rule Entry » en anglais, par exemple une règle de filtrage en fonction de l’adresse destination ou du protocole utilisé),
  • une donnée d’identification opaque du terminal, telle qu’un jeton, permettant d’identifier le terminal dans le réseau sans divulguer des informations propres au terminal ou à son utilisateur.
Ces informations sont transmises au terminal dans un message envoyé par une fonction réseau, par exemple un contrôleur CTRL, un serveur DHCP ou un routeur d’accès. Un tel message est par exemple envoyé suite à une sollicitation du terminal, c’est-à-dire en réponse à un message envoyé par le terminal. De plus, dans une réalisation particulière, un tel message peut également être envoyé sans sollicitation préalable, c’est-à-dire que le réseau annonce ces informations aux terminaux sans attendre une requête explicite de la part de ces terminaux.
Dans une réalisation particulière, les informations sont obtenues par le terminal lors de son attachement au réseau. Pour cela, le terminal envoie par exemple une requête DHCP comprenant une option particulière vers un équipement du réseau. La réception d’une telle requête DHCP par l’équipement réseau provoque l’envoi d’une réponse DHCP comprenant, outre les données traditionnellement comprises dans un tel message, des informations caractéristiques des interfaces de configuration exposées à des tiers par le réseau. Ces informations sont par exemple transmises dans une ou plusieurs options DHCP telles que définies dans le document RFC8415.
Dans une variante, les informations reçues peuvent comprendre une ou plusieurs consignes permettant au terminal de générer lui-même un identifiant opaque. Par exemple, la présence d’un paramètre « Self_Terminal_ID » valorisé à « 1 » est une indication explicite que le terminal doit générer un identifiant non persistant. Si le réseau retourne ce paramètre, alors il ne doit pas inclure « Terminal_ID » dans le même message. Cette variante est avantageuse car elle permet d’éviter d’exposer une information probablement invariable dans le temps qui pourrait être utilisée à des fins malveillantes (par exemple traçage du terminal).
La montre un tel échange de messages : le terminal envoie un message 400, tel qu’une requête DHCP comprenant une option particulière. L’option est particulière en ce qu’elle permet au terminal d’indiquer qu’il souhaite recevoir des indications relatives à une ou plusieurs interfaces de contrôle exposées par ce réseau. Lorsque la fonction réseau destinataire reçoit cette requête, et lorsque ladite option particulière est présente dans la requête, ladite fonction réseau insère des informations caractéristiques d’au moins une interface de contrôle dans une réponse 401, par exemple une réponse DHCP comprenant une option particulière. Bien entendu, ces informations peuvent être encodées dans un même élément d’information ou être retournées séparément sans qu’il soit nécessaire de modifier l’invention.
La montre un exemple d’un entête d’option DHCPv6 comprenant des informations caractéristiques d’une interface de contrôle exposée par le réseau. Dans cet exemple, le type de l’option « OPTION_V6_TANIT » et sa longueur « Length » sont encodés chacun sur 16 bits. L’option comprend en outre un champ « API_ID » de 16 bits véhiculant un identifiant d’une API exposée par le réseau précédé de sa longueur « API_ID_LENGTH », une adresse d’un serveur exposant ladite API « API_LOCATORS » également précédé de la longueur du champ « API_LOCATORS_Length », un champ comprenant un ensemble de règles d’utilisation de l’API « CRE » précédé de sa longueur « CRE_LENGTH », un type d’API « API_TYPE » et un identifiant opaque affecté au terminal « Terminal_ID ».
Bien entendu, la structure de la est donné à titre d’exemple non limitatif, et d’autres formats peuvent être envisagés pour transmettre ces informations. En particulier, la structure peut comprendre un nombre et des types de paramètres qui diffèrent de ceux présentés dans l’exemple de la , et ces paramètres peuvent être transmis dans différentes options et/ou différents messages.
Dans une réalisation particulière, le terminal 100 mémorise les informations reçues en association avec un identifiant du réseau, par exemple un NID (« Network Identifier » en anglais) obtenu dans une option « Access Network Domain Name » d’une réponse DHCP ou avec un identifiant de l’interface réseau au travers de laquelle les informations ont été reçues. Cette association est maintenue localement par le terminal 100 tant que l’attachement avec le réseau identifié par le NID est actif. Ainsi, ces informations restent disponibles tant que le terminal est attaché à ce réseau, mais sont supprimées lorsque l’interface via laquelle les informations ont été reçues est désactivée. De cette façon, les informations relatives aux interfaces exposées par le réseau peuvent être transmises par le terminal 100 à différents services auxquels il accède.
Lorsque des informations relatives à au moins une interface de contrôle sont obtenues, le terminal 100 accède à un service offert par un serveur d’application AS.
Le procédé d’établissement de communication comprend une étape 202 au cours de laquelle le terminal 100 transmet les informations obtenues à l’étape 200 au serveur d’application AS.
Plus précisément, lorsque le terminal 100 souhaite établir une communication avec le serveur AS via un réseau auquel il est connecté, il recherche dans sa mémoire une entrée correspondant à l’identifiant de ce réseau à laquelle sont associées des informations caractéristiques d’une ou plusieurs interfaces de contrôle exposées par le réseau. Si des informations relatives à une interface de contrôle sont disponibles pour l’identifiant recherché, le terminal transmet ces informations au serveur AS dans un message.
Selon une réalisation particulière, cette information est encodée et transmise au serveur d’application AS sous la forme d’une option TCP, une option UDP, une option DCCP, une trame QUIC, ou un entête HTTP ou SIP.
Selon un mode particulier de réalisation, l’étape 202 est précédée d’une étape optionnelle 201 au cours de laquelle le terminal 100 transmet au serveur AS un message 402 comprenant une indication selon laquelle il dispose d’une capacité à transmettre des informations caractéristiques d’une ou plusieurs interfaces de contrôle exposées par un réseau auquel il est connecté et reçoit en retour un message 403 du serveur AS comprenant une indication relative au fait que le serveur AS est disposé à recevoir une telle information. De cette manière, le terminal sait si le serveur AS auquel il se connecte met en œuvre le procédé de contrôle objet de la présente invention et si le serveur AS est disposé à recevoir les informations obtenues par le terminal lors de l’étape 200.
Dans une réalisation particulière, le message 402 est un segment TCP SYN échangé avec le serveur AS lors de la phase d’établissement de connexion TCP (« handshake » en anglais), et le message 403 est un segment SYN/ACK échangé lors de cette même phase d’établissement de connexion TCP. De cette façon, il est possible de déterminer dès l’établissement de la connexion avec le serveur, sans latence, et avec un faible surcoût de signalisation, si le serveur AS est adapté à recevoir des informations concernant les interfaces exposées par le réseau et telles que transmises par le terminal. Un message d’erreur reçu du serveur (ou d’une manière extrême la clôture de la connexion) est une indication que celui-ci n’est pas adapté pour recevoir de telles informations.
Lorsque le terminal 100 reçoit du serveur AS le message 403, confirmant que le serveur AS est adapté pour recevoir des informations relatives à des interfaces de contrôle exposées par le réseau 102, il met en œuvre une étape 202 au cours de laquelle il transmet au serveur AS au moins un message 404 comprenant une annonce de l’API réseau associée au réseau via lequel la communication est établie. Le message 404 est par exemple une option TCP, une option UDP, une trame QUIC, une option DCCP, etc. La montre un exemple d’une structure d’option TCP adaptée pour transmettre au serveur AS une description d’une interface de contrôle exposée par le réseau 102 selon une réalisation particulière.
Ainsi, le terminal 100 envoie les informations relatives à au moins une interface de contrôle au serveur AS dans un message 404 comprenant un descripteur qui annonce l’API réseau associée au réseau via lequel la communication est établie. Dans une variante, le terminal 100 peut annoncer les informations caractéristiques des API des autres réseaux via lesquels certains flux de ladite communication peuvent transiter, et le terminal peut également inclure les API de ces autres réseaux. Par exemple, le message 404 peut comprendre des descripteurs relatifs aux interfaces de contrôle des réseaux 102 et 104. Dans ce cas, les informations caractéristiques d’une API doivent notamment préciser l’identifiant du réseau. Cet identifiant peut être un identifiant d’adresse (AddressID), une adresse IP, un numéro de système autonome (« Autonomous System Number » en anglais, ou ASN), etc.
Le terminal 100 peut en outre insérer un jeton « TERMINAL_SUPPLIED_ID » pour aider le réseau à corréler l’identifiant présenté par le serveur avec un identifiant du terminal tel que connu par le réseau. Dans une variante « TERMINAL_SUPPLIED_ID » est une copie du « TERMINAL_ID ».
En réponse au message 404 envoyé au serveur AS, le terminal 100 peut recevoir un message optionnel 410 lors d’une étape 203, comprenant un identifiant de marquage généré par le réseau 102. L’identifiant de marquage est destiné à être inséré dans les messages transmis par le terminal 100 à destination du serveur AS afin que les messages transmis par le terminal 100 au serveur AS puissent bénéficier d’un traitement différencié par le réseau 102 configuré suite à une demande du serveur AS à partir des informations transmises au serveur AS dans le message 404. Ainsi, selon l’identifiant indiqué par le terminal 100 dans les messages envoyés à destination du serveur AS, le réseau applique un traitement particulier à ces messages. Cet identifiant peut être par exemple, un identifiant de connexion QUIC (Source ou Destination Connection Identifier), une valeur DSCP (« Diffserv Code Point »), une valeur du champ Flow Label d’un entête de paquet IPv6, etc. L'identifiant peut être encodé dans un seul ou plusieurs champs d'un message.
L’identification est typiquement effectuée par un nœud de bordure tel qu’un routeur d’accès ou un routeur d’interconnexion. Un tel nœud peut maintenir, retirer ou réécrire l’information d’identification avant d’acheminer le paquet et d’invoquer les ressources nécessaires pour appliquer un traitement différencié.
A l’étape 204, le terminal 100 échange des paquets de données avec le serveur AS en sollicitant des ressources dudit réseau invoquées par le serveur par l’intermédiaire de l’interface de contrôle indiquée par le terminal. Par exemple, le réseau peut appliquer des règles de classification de trafic particulières, ou encore transmettre les paquets de données vers une tranche réseau particulière.
Une réalisation particulière du procédé de contrôle d’une communication mis en œuvre par le serveur AS de la va maintenant être décrite en référence aux figures 3 et 4.
La est un ordinogramme représentant les principales étapes d’un procédé de contrôle selon une réalisation particulière.
Dans un mode de réalisation particulier, le procédé comprend une première étape 300 au cours de laquelle le serveur AS reçoit un premier message 402 en provenance du terminal 100, le message 402 comprenant une indication selon laquelle le terminal 100 dispose d’une capacité à transmettre des informations caractéristiques d’une ou plusieurs interfaces de contrôle exposées par le réseau 102 auquel il est connecté. Un tel message est par exemple un message de contrôle ou un message de données. Par exemple, il peut s’agir d’un segment TCP SYN échangé lors d’une phase d’établissement de connexion TCP comprenant une option TCP dans laquelle sont encodées les capacités du terminal 100 à transmettre l’information relative à des interfaces exposées par le réseau 102. D’autres exemples comprennent l’encodage de l’information dans une option UDP, une option DCCP ou un paramètre de transport QUIC.
A la réception du message 402, le serveur AS détecte la présence dans ce message d’une indication selon laquelle le terminal 100 dispose d’une capacité à transmettre des informations caractéristiques d’une ou plusieurs interfaces de configuration exposées par le réseau 102. Le serveur AS répond alors au terminal 100 par un message 403 dans lequel il insère une indication particulière confirmant qu’il est adapté pour recevoir une telle information. Cette réponse est par exemple transmise dans un segment TCP SYN/ACK de la phase d’établissement de connexion TCP, ou dans une option UDP, ou dans une option DCCP ou selon un paramètre de transport QUIC.
Cet échange de messages préliminaire permet au terminal 100 et au serveur AS d’échanger leurs capacités à mettre en œuvre les procédés selon l’invention. Dans certaines réalisations, il est toutefois possible de s’affranchir de cette phase sans pour autant modifier l’invention. Par exemple, le terminal et le serveur peuvent être configurés au préalable conformément à un standard imposant le support de procédés conformes à la présente invention, rendant inutile l’étape préliminaire d’échange de capacités.
A l’étape 301, le serveur AS reçoit un message 404 transmis par le terminal 100, ledit message comprenant au moins une information caractéristique d’une interface de contrôle exposée par un réseau 102 auquel est connecté le terminal. Le message 404 comprend par exemple une option TCP, une option UDP, une trame QUIC, une option DCCP, etc. Il peut en outre s’agir d’un message de signalisation ou de données. La réception du message 404 permet ainsi au serveur de connaître les caractéristiques d’une ou plusieurs interfaces de contrôle exposée(s) par le réseau auquel est connecté le terminal 100. Selon une réalisation particulière, le message 404 comprend non seulement une information caractéristique d’une ou plusieurs interfaces de contrôle du réseau 102 auquel le terminal 100 est connecté, mais aussi un ou plusieurs descripteurs d’interface d’un autre réseau par lequel des flux sont susceptibles de transiter. Par exemple, le message 404 peut comprendre un descripteur correspondant à une première interface exposée par un réseau d’accès cellulaire auquel le terminal est connecté, et un descripteur correspondant à une deuxième interface de contrôle exposée par un réseau d’accès terrestre, par exemple un réseau d’accès optique, accessible par le terminal. De cette manière, le serveur AS peut anticiper un éventuel basculement du trafic sur l’un ou l’autre des réseaux utilisables par le terminal selon les instructions de configuration exécutées par les deux réseaux.
L’étape 302 du procédé de contrôle comprend le contrôle de la configuration du réseau 102 par le serveur AS à partir des informations reçues à l’étape 301. Plus précisément, le serveur AS invoque une ou plusieurs fonctions offertes par l’interface exposée par le réseau 102 pour configurer et appliquer une politique de qualité de service particulière pour les messages échangés avec le terminal 100 au travers du réseau 102. Par exemple, le serveur AS peut configurer le réseau pour que les paquets de données échangés avec le terminal 100 utilisent une tranche réseau particulière optimisée pour le service.
Le serveur AS demande une configuration spécifique du réseau en invoquant une API dont les caractéristiques sont transmises par le terminal 100 dans le message 404. Pour cela, le serveur envoie par exemple une requête HTTP POST vers un serveur NEF dont l’adresse et les paramètres d’accès ont été communiqués par le terminal 100 dans le message 404. La requête POST comprend les arguments nécessaires pour invoquer cette API. Ces arguments sont par exemple configurés pour commander au réseau la classification de certains flux au titre d’une tranche, la priorisation de tout ou partie des flux de cette communication, l’invocation d’une fonction service locale (par ex. fonction de transcodage), ou la demande de servir ce terminal depuis un cache plus proche, etc. Les arguments peuvent également inclure les informations de classification pour identifier les paquets éligibles au traitement demandé. La requête POST peut être décomposée en plusieurs requêtes.
Selon une réalisation particulière, l’étape 302 de configuration comprend une sous-étape préalable d’obtention des capacités de l’API. Pour cela, le serveur AS interroge par exemple le serveur NEF dont l’adresse est consignée dans le message 404 et obtient en réponse les capacités de contrôle offertes par l’interface de contrôle (API). Plus précisément, le serveur AS envoie par exemple une requête 405, telle qu’une requête HTTP GET, pour récupérer la liste des fonctions (« capabilities » en anglais) supportées par cette API en utilisant l’adresse renseignée dans le message 404, et reçoit en retour un message de réponse 406 comprenant une liste de capacités. Dans une variante, l’API réseau peut consigner dans la réponse 406 à la requête 405 des informations de classification de trafic qui peuvent être communiquées au préalable par le serveur à des terminaux afin de faciliter l’établissement de communications futures au titre du même service. Ce mode a pour objectif d’optimiser le délai nécessaire pour la mise en place d’un traitement différencié pour ces terminaux lorsque ces derniers se connectent au service.
Par exemple, sur réception du message 407 par une fonction NEF du réseau 102, cette dernière extrait les informations communiquées par le serveur AS et procède à des vérifications (par exemple, la fonction NEF vérifie la disponibilité des ressources permettant d’offrir le service différencié demandé, l’absence de consignes pour bloquer ce serveur, validité de l’identifiant du terminal).
Si la fonction NEF accepte de répondre positivement à la requête 407 du serveur AS pour une communication avec le terminal 100, la fonction NEF définit les actions nécessaires à mettre en œuvre dans le réseau pour fournir un traitement différencié du trafic caractéristique de cette communication. Ces actions sont par exemple coordonnées par un contrôleur réseau CTRL (typiquement, un contrôleur SDN). Dans une variante, ledit contrôleur CTRL est l’entité NEF qui expose l’API réseau. Pour cela, la fonction NEF peut transmettre un message 409 au contrôleur réseau, comprenant le paramétrage souhaité.
Lors d’une étape optionnelle 303, le serveur AS reçoit un message de confirmation 408 en réponse à la requête 407. Dans une réalisation particulière, le message de confirmation 408 comprend des informations pour faciliter l’identification des paquets éligibles au traitement différencié, par exemple des informations de marquage pour les paquets envoyés depuis le serveur AS vers le terminal 100 et/ou des informations de marquage pour les paquets envoyés depuis le terminal 100 vers le serveur AS.
Selon un mode particulier de réalisation, le serveur AS transmet un message 410 au terminal 100 dans lequel sont incluses les informations de marquage reçues dans le message 408. De cette façon, le terminal 100 peut insérer une information de marquage adaptée dans les paquets envoyés à destination du serveur AS afin que le réseau 102 puisse appliquer à ces paquets le traitement différencié demandé par le serveur AS à l’étape 302.
L’identification est typiquement effectuée par un nœud de bordure tel qu’un routeur d’accès ou un routeur d’interconnexion. Un tel nœud peut maintenir, retirer ou réécrire l’information d’identification avant d’acheminer le paquet et d’invoquer les ressources nécessaires pour appliquer un traitement différencié.
De façon optionnelle, le serveur AS peut, lors d’une étape 305, demander au réseau 102 de mettre fin au traitement personnalisé des paquets de données échangés avec le terminal 100. Pour cela, le serveur AS transmet par exemple un message 412 à la fonction NEF, le message comprenant une commande réseau adaptée pour mettre fin au traitement différencié.
La représente une architecture d’un dispositif 700 adapté pour mettre en œuvre le procédé d’établissement d’une communication, selon un mode particulier de réalisation.
Le dispositif 700 comprend un module de traitement de données composé d’un espace de stockage 701, par exemple une mémoire (MEM), une unité de traitement 702, équipée par exemple d'un microprocesseur (PROC), et pilotée par un programme d'ordinateur (PGR) 703 dont les instructions sont configurées pour mettre en œuvre le procédé d’établissement d’une communication tel que décrit précédemment en référence aux figures 2 et 4.
A l'initialisation, les instructions de code du programme d'ordinateur 703 sont par exemple chargées dans la mémoire 701 avant d'être exécutées par le processeur de l'unité de traitement 702. Le microprocesseur de l'unité de traitement 702 met en œuvre, selon les instructions du programme d'ordinateur 703, les étapes du procédé d’établissement d’une communication tel que décrit précédemment en référence aux figures 2 et 4.
Pour cela, le dispositif 700 comprend des moyens de communication 704, par exemple une interface réseau cellulaire 3G, 4G, 5G, réseau sans fil Wi-Fi® ou Wimax®, une interface optique ou encore une interface Ethernet. Les moyens de communication permettent au dispositif 700 de se connecter à un réseau de communication et échanger des données avec d’autres dispositifs.
Le dispositif 700 comprend aussi un module 705 d’obtention d’informations caractéristiques d’au moins une interface de contrôle exposée par le réseau. Pour cela, le module 705 coopère avec les moyens de communication 704 pour générer et transmettre un message à une entité de contrôle d’un réseau, le message comprenant une indication adaptée pour commander à l’entité de contrôle l’insertion d’informations caractéristiques d’au moins une API exposée par ledit réseau dans une réponse au message. Le module 705 est en outre configuré pour permettre la réception d’un message en provenance de l’entité de contrôle comprenant au moins un descripteur d’une interface de contrôle exposée par le réseau comprenant au moins une adresse permettant d’invoquer ladite interface de contrôle. Le module 705 est par exemple mis en œuvre par des instructions de programme d’ordinateur configurées pour mettre en œuvre l’étape 200 du procédé d’établissement d’une communication selon une réalisation particulière.
Le dispositif 700 comprend également un module de configuration 706 adapté pour transmettre une information caractéristique d’une interface de contrôle du réseau reçue par le module 705. Selon un mode de réalisation particulier, le module est mis en œuvre par des instructions de programme d’ordinateur configurées pour générer un message comprenant une structure de données particulière, par exemple un champ d’option au format TLV (Type Longueur Valeur), comprenant au moins une adresse d’une interface de contrôle obtenue par le module 705 et un identifiant du dispositif, et pour coopérer avec les moyens de communication 704 pour transmettre le message à un serveur d’application hébergeant un service auquel le dispositif souhaite accéder.
Le dispositif 700 comprend en outre un module 707 de transfert de données adapté pour coopérer avec les moyens de communication afin d’échanger des données avec un serveur en sollicitant des ressources réseau invoquées par ledit serveur par l’intermédiaire de d’une interface de contrôle dont les caractéristiques ont été transmises par le module 706. Le module 707 est par exemple mis en œuvre par des instructions de programme d’ordinateur configurées pour mettre en œuvre l’étape 204 du procédé d’établissement d’une communication décrite ci-avant. Dans une réalisation particulière, le module 707 est adapté pour marquer des paquets transmis au serveur d’application par les moyens de communication 704.
Selon un mode de réalisation particulier, le dispositif est intégré dans un terminal de communication, par exemple dans un équipement utilisateur (UE), un téléphone mobile, un ordinateur, un décodeur vidéo, une passerelle, un objet connecté ou tout autre dispositif susceptible d’accéder à des services hébergés par un serveur d’application.
La représente une architecture d’un dispositif 800 adapté pour mettre en œuvre le procédé de contrôle d’une communication, selon un mode particulier de réalisation.
Le dispositif 800 comprend un module de traitement de données composé d’un espace de stockage 801, par exemple une mémoire (MEM), une unité de traitement 802, équipée par exemple d'un microprocesseur (PROC), et pilotée par un programme d'ordinateur (PGR) 803 dont les instructions sont configurées pour mettre en œuvre le procédé de contrôle d’une communication tel que décrit précédemment en référence aux figures 3 et 4.
A l'initialisation, les instructions de code du programme d'ordinateur 803 sont par exemple chargées dans la mémoire 801 avant d'être exécutées par le processeur de l'unité de traitement 802. Le microprocesseur de l'unité de traitement 802 met en œuvre, selon les instructions du programme d'ordinateur 803, les étapes du procédé de contrôle d’une communication tel que décrit précédemment en référence aux figures 3 et 4.
Pour cela, le dispositif 800 comprend des moyens de communication 804, par exemple une interface réseau cellulaire 3G, 4G, 5G, réseau sans fil Wi-Fi® ou Wimax®, une interface optique ou encore une interface Ethernet. Les moyens de communication permettent au dispositif 800 de se connecter à un réseau de communication et échanger des données avec d’autres dispositifs.
Le dispositif 800 comprend aussi un module 805 de réception d’un message transmis par un terminal comprenant au moins une information caractéristique d’une interface de contrôle exposée par un réseau auquel est connecté le terminal. Dans un mode de réalisation particulier, le module 805 coopère avec les moyens de communication 804 pour mettre en œuvre un protocole de transmission de données, par exemple un protocole TCP, UDP, QUIC ou autre, et recevoir une structure de données, par exemple un champ TLV d’un paquet de données comprenant au moins l’adresse d’une interface de contrôle (ou API) exposée par le réseau auquel est connecté le terminal et un identifiant du terminal.
Le dispositif 800 comprend également un module de configuration 806 adapté pour configurer des ressources particulières dans un réseau de communication par l’intermédiaire d’une interface exposée par ledit réseau et indiquée dans un message reçu par le module 805. Plus précisément, le module 806 peut être mis en œuvre par des instructions de programme d’ordinateur configurées pour coopérer avec les moyens de communication 804 afin d’invoquer une ou plusieurs fonctions offertes par une interface exposée par un réseau à partir de l’adresse reçue par le module 805 de sorte à mettre en place une configuration réseau particulière, et recevoir en retour au moins une information destinée à marquer les paquets de données auxquels la configuration réseau particulière doit s’appliquer.
Le dispositif 800 comprend enfin un module de transmission de données 807 adapté pour marquer des paquets de données destinés au terminal ayant transmis les informations caractéristiques d’une interface de contrôle réseau reçues par le module 805. Dans un mode particulier de réalisation, le module 807 est mis en œuvre par des instructions de programme d’ordinateur et coopère avec les moyens de communication 804 pour envoyer des paquets de données vers le terminal en sollicitant des ressources du réseau invoquées via ladite interface de contrôle, les paquets envoyés étant marquée à l’aide de l’information de marquage obtenue par le module de configuration 806.
Selon un mode particulier de réalisation, le dispositif 800 est intégré dans un serveur d’application.

Claims (14)

  1. Procédé d’établissement d’une communication entre un terminal et un serveur par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le procédé comprenant les étapes suivantes, mises en œuvre par le terminal :
    • Une étape (200) d’obtention d’une information caractéristique d’au moins une interface de contrôle exposée par le réseau,
    • Une étape (202) de configuration au cours de laquelle le terminal transmet au serveur d’application au moins une partie de ladite information obtenue,
    • Une étape (204) de communication au cours de laquelle le terminal échange des paquets de données avec le serveur en sollicitant des ressources dudit réseau invoquées par le serveur par l’intermédiaire de l’interface de contrôle indiquée par le terminal.
  2. Procédé selon la revendication 1 dans lequel le terminal obtient l’information caractéristique d’au moins une interface de contrôle exposée par le réseau dans un message DHCP, un élément d’information PCO, ou un message « Neighbor Discovery ».
  3. Procédé selon l’une quelconque des revendications précédentes dans lequel l’information caractéristique d’au moins une interface de contrôle exposée par le réseau comprend au moins un élément sélectionné parmi les éléments suivants :
    • Un identifiant d’API réseau,
    • Au moins une adresse d’accès à une API réseau,
    • Un type d’API réseau,
    • Une ou plusieurs règles régissant les conditions d’applications d’une configuration,
    • Une donnée d’identification opaque du terminal.
  4. Procédé selon l’une quelconque des revendications précédentes dans lequel le terminal transmet l’information caractéristique d’au moins une interface de contrôle exposée par le réseau au serveur dans un champ d’option d’un entête TCP ou UDP, une trame QUIC, ou une option DCCP, un entête HTTP ou SIP.
  5. Procédé selon l’une quelconque des revendications précédentes tel qu’il comprend en outre une étape de réception d’un message transmis par le serveur, le message comprenant au moins une consigne d’identification des paquets obtenue par le serveur auprès d’au moins une interface de contrôle du réseau dont les caractéristiques ont été transmise au serveur par le terminal, l’étape de communication comprenant la génération d’au moins un paquet de données conformément auxdites consignes d’identification.
  6. Procédé de contrôle d’une communication entre un terminal et un serveur par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le procédé comprenant les étapes suivantes, mises en œuvre par le serveur :
    • Réception (301) d’un message transmis par le terminal, ledit message comprenant au moins une information caractéristique d’une interface de contrôle exposée par un réseau auquel est connecté le terminal,
    • Invocation (302) d’au moins une interface de contrôle identifiée à partir de ladite information caractéristique,
    • Envoi d’au moins un paquet de données (306) vers le terminal et/ou réception d’au moins un paquet de données en provenance du terminal, les paquets étant acheminés en sollicitant des ressources dudit réseau invoquées via ladite interface de contrôle.
  7. Procédé selon la revendication 6 tel qu’il comprend en outre une étape d’obtention, à partir de l’interface de contrôle invoquée, d’au moins une consigne d’identification des paquets échangés avec le terminal, les paquets envoyés et/ou reçus étant générés conformément auxdites consignes d’identification obtenues.
  8. Dispositif d’établissement d’une communication avec un serveur par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le dispositif comprenant un processeur (702) couplé à une mémoire (701) dans laquelle sont enregistrées des instructions (703) adaptées pour mettre en œuvre les étapes suivantes :
    • Une étape d’obtention d’une information caractéristique d’au moins une interface de contrôle exposée par le réseau,
    • Une étape de configuration au cours de laquelle le terminal transmet au serveur d’application au moins une partie de ladite information obtenue,
    • Une étape de communication au cours de laquelle le terminal échange des paquets de données avec le serveur en sollicitant des ressources dudit réseau invoquées par le serveur par l’intermédiaire de l’interface de contrôle indiquée par le terminal.
  9. Terminal de communication comprenant un dispositif d’établissement d’une communication selon la revendication 8.
  10. Dispositif de contrôle d’une communication établie avec un terminal par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le dispositif comprenant un processeur (803) couplé à une mémoire (801) dans laquelle sont enregistrées des instructions (803) adaptées pour mettre en œuvre les étapes suivantes :
    • Réception d’un message transmis par le terminal, ledit message comprenant au moins une information caractéristique d’une interface de contrôle exposée par un réseau auquel est connecté le terminal,
    • Invocation d’au moins une interface de contrôle identifiée à partir de ladite information caractéristique,
    • Envoi d’au moins un paquet de données vers le terminal et/ou réception d’au moins un paquet de données en provenance du terminal, les paquets étant acheminés en sollicitant des ressources dudit réseau invoquées via ladite interface de contrôle.
  11. Serveur d’application comprenant un dispositif de contrôle d’une communication selon la revendication 10.
  12. Système de communication comprenant au moins un terminal selon la revendication 9 et au moins un serveur selon la revendication 11.
  13. Produit programme d’ordinateur comprenant des instructions configurées pour mettre en œuvre un procédé d’établissement d’une communication selon l’une quelconque des revendications 1 à 5 et/ou des instructions pour mettre en œuvre un procédé de contrôle d’une communication selon l’une quelconque des revendications 6 à 7, lorsque les instructions sont exécutées par un processeur.
  14. Support d’information lisible par un ordinateur sur lequel sont enregistrées des instructions de code pour mettre en œuvre un procédé d’établissement d’une communication selon l’une quelconque des revendications 1 à 5 et/ou des instructions pour mettre en œuvre un procédé de contrôle d’une communication selon l’une quelconque des revendications 6 à 7.
PCT/EP2024/075172 2023-09-18 2024-09-10 Procédés, dispositifs et système de contrôle d'une communication dans un réseau WO2025061515A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2309820 2023-09-18
FR2309820A FR3153206A1 (fr) 2023-09-18 2023-09-18 Procédés, dispositifs et système de contrôle d’une communication dans un réseau

Publications (1)

Publication Number Publication Date
WO2025061515A1 true WO2025061515A1 (fr) 2025-03-27

Family

ID=89308737

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2024/075172 WO2025061515A1 (fr) 2023-09-18 2024-09-10 Procédés, dispositifs et système de contrôle d'une communication dans un réseau

Country Status (2)

Country Link
FR (1) FR3153206A1 (fr)
WO (1) WO2025061515A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108388475A (zh) * 2018-02-27 2018-08-10 广州联智信息科技有限公司 一种基于终端类型配置api资源的方法及系统
WO2019194242A1 (fr) * 2018-04-06 2019-10-10 Nec Corporation Procédures de sécurité pour cadre d'api commune dans des réseaux de prochaine génération
EP4161128A1 (fr) * 2020-05-24 2023-04-05 ZTE Corporation Procédé d'optimisation de réseau, serveur, dispositif côté réseau, système, et support de stockage

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108388475A (zh) * 2018-02-27 2018-08-10 广州联智信息科技有限公司 一种基于终端类型配置api资源的方法及系统
WO2019194242A1 (fr) * 2018-04-06 2019-10-10 Nec Corporation Procédures de sécurité pour cadre d'api commune dans des réseaux de prochaine génération
EP4161128A1 (fr) * 2020-05-24 2023-04-05 ZTE Corporation Procédé d'optimisation de réseau, serveur, dispositif côté réseau, système, et support de stockage

Also Published As

Publication number Publication date
FR3153206A1 (fr) 2025-03-21

Similar Documents

Publication Publication Date Title
EP4087305B1 (fr) Sélection d'une tranche de réseau relative à une application
EP3739843B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
JP7125788B2 (ja) プロキシを用いてセキュアデバイスとアンセキュアデバイスとの間を通信するシステム及び方法
EP3476095B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
WO2019002754A1 (fr) Procédé de communication quic via des chemins multiples
WO2017194861A1 (fr) Procédé d'accès à un contenu hébergé sur un serveur selectionné en fonction de la localisation du terminal utilisateur
EP3284224B1 (fr) Procédé d'émulation dune connexion à chemins multiples
EP3603024B1 (fr) Procédé de recommandation d'une pile de communication
EP3643044B1 (fr) Procédé d'activation de traitements appliqués à une session de données
EP3732829B1 (fr) Procédé d'acheminement de données d'une session initialisée entre un terminal et un serveur
WO2009125158A2 (fr) Procede de routage d'un paquet de donnees dans un reseau et dispositif associe
EP3430777B1 (fr) Procédé et système de gestion dynamique de chemins de communication entre routeurs en fonction de besoins applicatifs
WO2025061515A1 (fr) Procédés, dispositifs et système de contrôle d'une communication dans un réseau
WO2019211548A1 (fr) Procédé d'envoi d'une information et de réception d'une information pour la gestion de réputation d'une ressource ip
EP3526956B1 (fr) Procédé de négociation d'une qualité de service offerte par une passerelle à des terminaux
FR3094590A1 (fr) Passerelle et procédé de différentiation de trafic émis par la passerelle, dispositif et procédé de gestion du trafic.
WO2025078594A1 (fr) Procédés de sélection de tranches réseau adaptées à un service, de gestion d'au moins une tranche réseau et de communication, et entités configurées pour mettre en œuvre ces procédés
FR3115644A1 (fr) Procédé et dispositif d’aiguillage d’une donnée applicative
FR3115645A1 (fr) Procédé et dispositif de médiation d’un ensemble d’applications