WO2024083978A1 - Procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d'ordinateur correspondants - Google Patents

Procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d'ordinateur correspondants Download PDF

Info

Publication number
WO2024083978A1
WO2024083978A1 PCT/EP2023/079144 EP2023079144W WO2024083978A1 WO 2024083978 A1 WO2024083978 A1 WO 2024083978A1 EP 2023079144 W EP2023079144 W EP 2023079144W WO 2024083978 A1 WO2024083978 A1 WO 2024083978A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
service
execution
request
validation
Prior art date
Application number
PCT/EP2023/079144
Other languages
English (en)
Inventor
Michel Trefcon
Alexandra ANSIAUX
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 WO2024083978A1 publication Critical patent/WO2024083978A1/fr

Links

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/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • 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/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • 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/563—Data redirection of data network streams

Definitions

  • Title of the invention Method for processing a request for execution of a service in a communications network, method for validating the request, intermediate entity, validation entity, corresponding system and computer program
  • the field of the invention is that of a communication network, in particular a communication network implementing a service-oriented architecture based on network functions.
  • the invention relates in particular to the validation of a request for execution of a service before its transmission to the entity executing the service.
  • the 5G core network is composed of multiple NF network functions (in English, “Network Function”), each having its own role and logic.
  • An NF is generally in charge of running multiple services.
  • Each service has its own role and logic within its NF.
  • each service is accessible in the form of a programming interface or API type interface (in English, “Application Programming Interface”).
  • the 3GPP standardization body specifies the API for each of the services implemented by the NF network functions that it has defined for the 5G core network, in a document written in a dedicated description language (OpenAPI version 3 ).
  • This document describes, among other things, the operations supported by the service and the format of the data structures exchanged.
  • These data structures are a set of attributes, each attribute being characterized by a simple type (string, number, Boolean, etc.) or the type of a structure, a name and authorized values. It can, where appropriate, specify constraints applicable to attributes or groups of attributes.
  • 3GPP further specifies that any request to execute a service operation that does not conform to the format of the API of this service must be rejected by the requested service and provides various error messages to be returned to the service. entity that issued the request.
  • the NF network functions of the core network and, thereby, the entity in charge of executing a service of this network function are typically software entities, comprising a request validation layer and a service execution layer.
  • the executable file of a service inseparably includes the business logic of the service and the validity check of operations.
  • the NF network functions of the core network are software entities (that is to say software) which can be designed using computer languages from design environments (in English, “framework”). varied.
  • the choices of these software technologies belong to the designers of services and the manufacturers of the server equipment which hosts these services. They are made according to the adequacy of the specificities of the service to be designed and the software technologies mastered by their research and development teams.
  • Current software ecosystems are in fact multiple and varied, so that mastering all of these ecosystems requires a significant investment for a manufacturer.
  • the most appropriate software ecosystem for the design of a service is not necessarily the one which provides the best level of control of the validity of an operation executed by this service.
  • the invention responds to this need by proposing a method for processing a request for execution of a service in a communication network, coming from an entity called a consumer of the service, to an entity execution of said service, said method being implemented at the level of an intermediate entity configured to receive messages coming from the entity consuming the service and intended for the entity executing the service or coming from the entity executing the service and intended for the entity consuming the service, and comprising:
  • the invention thus proposes a completely new and inventive approach to the processing of a request for execution of a service operated by a communication network, which consists on the one hand of separating the prior validation of the request for the execution of the service itself and on the other hand to entrust the processing of these requests and their routing towards one or other of the validation and execution entities of the service, to an intermediate entity placed in isolation from the service execution requests issued by consuming entities in the communication network and at the front of the validation and execution entities of the service.
  • these request validation and service execution functions are fulfilled by separate entities of the communication network.
  • each of them can be designed in the design environment considered most suitable by the designer/builder.
  • the invention also makes it possible to use a single design environment to design the execution request validation entities of several distinct services, regardless of the API associated with them and the design environment used to develop the execution entity of the corresponding service. Thanks to the invention, a player in the field can therefore specialize in the design of entities/components for validating API operations of network function services of a communication network. With the invention, it is the intermediate entity which has control of the processing of requests and their possible prior validation.
  • the invention thus offers great flexibility, while not deviating from the required quality criteria. It also leaves the possibility of changing the chosen validation policy over time.
  • the invention also makes it possible to increase the modularity of a communication network.
  • a communication network such as the 5G core network
  • a virtualized and distributed cloud computing architecture of network functions which promotes the sharing, via networks, of resources that provide access to infrastructure, services, platforms and applications on demand.
  • the physical or material resources for example server equipment having significant computing and memory capacities, are exploited by an orchestrator which supervises in real time the allocation of memory quotas and of calculation, called virtual machines or containerization instances, to software entities of the NF network function type, the services of these NF network functions or even the operations of these services, monitors the quantity of memory and the calculation or CPU time (“ Central Processing Unit", in English) effectively used by each entity and replicates/removes the virtual machine or containerization instances of a given software entity to meet increased/decreased needs.
  • Central Processing Unit in English
  • the service required by the service consuming entity is implemented in a given network function.
  • a network function is composed of entities organized together in a network and which are not reachable/routable directly from the outside.
  • these entities and the associated network function
  • This network function can provide one or more services.
  • the intermediate entity thus plays the role of gateway between the entity consuming the service, which requests the execution of this service, and the entity executing (or producing) the requested service.
  • This is for example reverse proxy equipment which hides from the entity consuming the service the presence of entities belonging to the network function and which contribute to the execution of the requested service.
  • the invention is therefore part of the trend of disaggregation or decomposition of the logic of the 5G core network.
  • the invention is implemented at the level of an intermediate entity placed in cutoff (on the front) of the network path taken by the requests for execution of a service and configured to transmit the requests to be validated to a validation entity distinct from the service execution entity.
  • the method comprises:
  • An advantage is that the intermediate entity integrates the intelligence necessary to transmit the request and/or response messages that it receives to the correct entity. In addition, his role and his position give him visibility on the quality of requests, which allows him to decide whether or not to suspend the systematic validation of the next requests to be processed.
  • the validation entity and the service execution entity do not communicate directly with each other.
  • the intermediate entity is the obligatory passage of messages between the validation entity and the service execution entity.
  • the intermediate entity receives the validation information message from the service validation entity. If the request is not validated, this validation information message includes a message body describing the cause of the rejection and a status code.
  • a response message conforming to the 3GPP specifications includes an HTTP status code of class 4xx.
  • the information message includes a status code which indicates to which entity the request must be transmitted, which constitutes validation of the request. In the embodiment described here, this status code is a class 3xx HTTP code.
  • the intermediate entity always receives at least the validation information message and, where applicable, the execution report;
  • the validation entity and the service execution entity communicate directly with each other.
  • the entity validation directly transmits the service execution request to the execution entity and in return receives the execution report which it transmits to the intermediate entity. If the request is not validated, the validation entity sends a validation information message to the intermediate entity. Therefore, the intermediate entity always receives at least either a negative validation message or an execution report.
  • the at least one response message received comprises a validation information message from the validation entity comprising a validation result
  • the validation information message is transmitted to the entity consuming the service when the validation result is negative
  • the service execution request is transmitted to the service execution entity when the validation result is positive.
  • the intermediate entity is also the obligatory passage between the validation entity and the service execution entity, which do not communicate directly with each other.
  • This configuration is particularly suitable in case they do not belong to the same subnet or the same network function.
  • the entity consuming the service receives a validation error message and the request is not transmitted to the entity executing the service.
  • the method comprises, in response to a positive validation result, obtaining by the intermediate entity an identifier of the entity executing the service), and the service execution request is transmitted to the service execution entity using said obtained identifier.
  • An advantage is that the identifier allowing access to the service execution entity is only obtained by the intermediate entity in the event of successful validation. This guarantees that the service execution entity only processes valid requests.
  • This identifier may be private, when the service execution entity is included in a network function or subnetwork of another type, and public otherwise, so as to allow the service entity to be directly reached. execution of the service.
  • the service execution identifier may be obtained by the intermediate entity from the validation information message received from the validation entity (for example, it is contained in this message), or alternatively be determined by the intermediary entity.
  • said at least one response message received comprises a service execution report message sent by the service execution entity and in that said service execution report message is transmitted to the entity consuming the service.
  • the intermediate entity receives in all cases (whether the validation entity is connected or not to the service execution entity) an execution report message comprising a result or at least a confirmation of the execution of the service coming from the entity executing the service, which it transmits to the entity consuming the service.
  • the decision whether or not to transmit said request to the service validation entity is taken based on at least one given decision criterion relating to at least one operating indicator of the service. network and/or a type of execution request of the service.
  • said at least one network operation indicator belongs to a group of indicators of a network operating state, comprising at least one indicator of traffic, latency, occupancy (saturation) of resources network over a given time period, a quality indicator of service execution requests such as for example a rate of requests not validated by the validation entity during the given time period, a rate of error messages generated by the service execution entity for requests that have not been subject to prior validation, etc. It may also be a counter of service execution requests previously submitted to validation during an elapsed time period. For example, a request is transmitted directly every ten requests submitted for validation. As for the decision criterion, it includes a value threshold of said at least one indicator.
  • the criterion for deciding whether or not to transmit the request to the validation entity is linked to a type of service execution request (for example, depending on whether these requests concern the creation , modification, deletion or consultation of a resource).
  • the invention makes it possible to achieve a compromise between the effort put into validating requests for execution of a service and the preservation of network resources.
  • the invention also relates to an intermediate entity of a communication network, configured to receive messages coming from an entity, called a consumer of a service, and intended for an entity executing said service and to receive messages from the entity executing the service and intended for the entity consuming the service, and configured to implement:
  • said intermediate entity is configured to implement the steps of the method for processing a request as described above.
  • the invention also relates to a method of validating a request for execution of a service in a communication network, said request having been issued by an entity said to be a consumer of the service of said network intended for a service execution entity, said method being implemented at the level of a service validation entity distinct from said execution entity and in that it comprises:
  • the validation of requests is therefore ensured by an entity distinct from the entity executing the service.
  • This independent entity receives requests to be validated from the entity intermediate. It can therefore be designed in an environment different from that of the execution entity. It can also be shared for several services.
  • said at least one action comprises the transmission of a validation information message comprising the validation result to the intermediate entity.
  • An advantage is that the responsibility for deciding whether or not a request for execution of a service must be transmitted to the entity executing the service is entirely entrusted to the intermediate entity.
  • the sole responsibility of the validation entity is to validate the service execution requests that it receives from this intermediate entity and to return a validation result to it.
  • a positive validation response may also include an identifier of the service execution entity.
  • This identifier allows the intermediate entity to transmit the service execution request to the service execution entity.
  • An advantage is that it is only obtained by the intermediate entity when the execution request has been considered valid by the validation entity of the service.
  • said at least one action comprises the transmission of said service execution request to the service execution entity.
  • An advantage is that the validation entity directly redirects a service execution request considered valid to the service execution entity concerned. In this way, the latency introduced by the validation phase is reduced to a minimum.
  • said at least one action further comprises the reception of a response message from the service execution entity comprising a service execution report and the transmission of said response message to the intermediate entity.
  • the invention also relates to an entity for validating a request for execution of a service in a communication network, said request having been sent by an entity consuming the service to an entity executing the service. service.
  • the validation entity is configured to implement:
  • said request having been transmitted to the validation entity by an intermediate entity configured to receive messages coming from an entity, called a consumer of a service, and intended for 'an entity executing said service and to receive messages from the entity executing the service and intended for the entity consuming the service;
  • said validation entity is configured to implement the steps of the method for validating a request as described previously.
  • said intermediate entity and said validation entity are included in a system for managing a service in a communications network, said system comprising an entity consuming the service and an entity executing the service, said consuming entity being configured to transmit a service execution request to the service execution entity.
  • the system has at least the same advantages as those conferred by the aforementioned treatment method and validation method.
  • the invention also relates to computer program products comprising program code instructions for implementing the processing and validation methods as described above, when they are executed by a processor.
  • a program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in no no matter what other desirable shape.
  • the invention also relates to a recording medium readable by a computer on which computer programs are recorded comprising program code instructions for executing the steps of the methods according to the invention as described below. above.
  • Such a recording medium can be any entity or device capable of storing the program.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a mobile medium (memory card) or a hard drive or SSD.
  • such a recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means, so that the computer program it contains can be executed remotely.
  • the program according to the invention can in particular be downloaded onto a network, for example the Internet network.
  • the recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned method.
  • the present technique is implemented by means of software and/or hardware components.
  • module can correspond in this document to a software component as well as to a hardware component or to a set of hardware and software components.
  • a software component corresponds to one or more computer programs, one or more subprograms of a program, or more generally to any element of a program or software capable of implementing a function or set of functions, as described below for the module concerned.
  • Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is capable of accessing the hardware resources of this physical entity (memories, recording media, communication buses, electronic input/output cards, user interfaces, etc.). Subsequently, by resources we mean all sets of hardware and/or software elements supporting a function or service, whether unitary or combined.
  • a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions, according to what is described below for the module concerned. It may be a programmable hardware component or one with an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing a firmware, etc.
  • FIG. 1 schematically illustrates an example of architecture of a system for managing a request for execution of a service in a communications network according to one embodiment of the invention
  • FIG. 2 Idescribes in the form of a flowchart the steps of a process for processing such a request for execution of a service, according to the invention
  • FIG. 3A describes in the form of a flowchart the steps of a method of validating such a request for execution of a service, according to a first exemplary embodiment of the invention
  • FIG. 3B describes in the form of a flowchart the steps of a method of validating such a request for execution of a service, according to a second exemplary embodiment of the invention
  • FIG. 3C describes in the form of a flowchart the steps of a method of validating such a request for execution of a service, according to a third embodiment of the invention
  • FIG. 4 [Fig. 5] [Fig. 6] [Fig. 7] [Fig. 8] [Fig. 9]: schematically illustrate the messages exchanged between the different entities of the management system of a request for execution of a service according to a first exemplary embodiment of the invention
  • FIG. 10 [Fig. 11] [Fig. 12]: schematically illustrate the messages exchanged between different entities of the management system of a request for execution of a service according to a second exemplary embodiment of the invention
  • FIG. 13 schematically illustrates an example of hardware structure of an intermediate entity configured to process a request for execution of a service according to one embodiment of the invention
  • FIG. 14 schematically illustrates an example of hardware structure of an entity for validating a request for execution of a service according to one embodiment of the invention.
  • the general principle of the invention consists of separating, in a communication network, the validation of requests for execution of a service coming from an entity consuming the service, from the actual execution of this service. and at the same time centralize the processing of such requests at the level of an intermediate entity.
  • This intermediate entity is advantageously placed at the front of the entity consuming the service and the requests it sends, in relation to the validation and execution entities of the service concerned.
  • this intermediate entity is the first entity which receives the request from a consuming entity, that is to say which is visible to this consuming entity. It is thus placed in cutoff from the flow of requests addressed from the consuming entities to the execution entity. As a result, it hides the validation and execution entities from the entities consuming the service.
  • the invention proposes to entrust the tasks of validating a request execution of a service and execution of this request to two distinct network entities placed under the responsibility of the same intermediate entity which controls them.
  • These two entities are for example two software entities which may, therefore, have been designed in distinct design environments and using different programming languages.
  • these two entities have distinct locations (typically are represented by two distinct executable files) and each has its own identifier, for example of type U RI (in English, "Universal Resource Identifier"), which allows another entity in the network to reach it, and communicate with it.
  • the invention thus makes it possible to make the communication network more modular, and therefore, to rationalize the design efforts and therefore the investments necessary to implement effective validation of requests for execution of services in a network.
  • Communication since the task of validating a request to execute a service is dissociated from the execution of the service itself, the constraint of adapting to the software environment of the entity executing the service is released and a validation solution builder can choose the most suitable design environment.
  • the invention also makes it possible to control the processing of these requests and their prior validation by this intermediate entity, which has visibility over the request flows, receives information representative of an operating state of the network and a quality level of the service execution requests received and can therefore decide whether or not to trigger the validation of a new request based on this information.
  • An advantage is to limit latency and resource consumption induced by the validation of operations while guaranteeing an acceptable compliance rate of execution requests actually by the entity executing the service. In this way, the invention contributes to improving load management and more generally the quality of service within this network.
  • the invention relates to any type of network implementing a service-oriented architecture (service requester/service provider) based on application devices.
  • service-oriented architecture service requester/service provider
  • NF network functions configured to carry out one or more tasks or services and exchange information with each other through an SBI (Service Based Interface) service interface.
  • SBI Service Based Interface
  • the invention also applies to other types of application devices such as, for example, web service type application devices.
  • application devices such as, for example, web service type application devices.
  • the allocation of physical resources for the implementation of these network functions is supervised by orchestrator equipment.
  • Each application device integrates, for example, a software component designed to carry out a specific task or tasks such as retrieving information (example: the identity of a mobile terminal when it is attached) or executing an operation (example: implementing works a tunnel).
  • a network function contains the software code and data necessary to produce the list of tasks or services associated with this function.
  • Access to such services is via application programming interfaces or APIs (in English, “Applicative Programming Interface”), for example of the REST API type (for “RE-presentational State Transfer” , in English), configured to execute a service or an operation of a service in response to requests from consuming entities whose validity the designer wishes to check.
  • APIs in English, “Applicative Programming Interface”
  • REST API type for “RE-presentational State Transfer” , in English
  • An example of a network to which the invention is particularly suited is a 5G core network, as specified by the 3GPP standard.
  • the data format is the JSON format and the exchange protocol is the HTTP/2 protocol.
  • Each service retrieves, creates, modifies or deletes a resource. Writing is done using the POST or PUT or DELETE commands, and reading is done using the GET command.
  • Figure 1 schematically illustrates an example of architecture of a system S for managing a request for execution of a service in a communication network RC, for example a 5G mobile core network as specified by 3GPP.
  • the RC network includes an ECS entity for consuming a service provided by the RC network.
  • This is a hardware and/or software element of the RC network, configured to execute one or more tasks in the RC network and which, to do so, calls on this service.
  • a single ECS entity is shown, but we understand that the RC network can include several. This is for example a particular NF network function which requires the execution of a service from an EES entity for production or execution of this service, for example another NF function of this network.
  • a network function can be both a producer of a service for another network function and in turn a consumer of a service provided by this other network function.
  • the RC network further comprises a validation entity EVS of a request for execution of the service provided by the execution entity EES.
  • EES execution entity
  • it is an entity distinct from the EES execution entity. It is configured to validate in particular a format (for example a name and/or a value) of the data specified in the execution request.
  • This data includes attributes and parameters included in the request body and/or in one or more headers of that request (for example, the unique identifier or URI).
  • the system S therefore comprises the consuming entity of an ECS service, the execution entity of the EES service and the validation entity EVS of the execution request of the service issued by the consuming entity ECS.
  • the system S further comprises an intermediate entity of the communication network RC, placed at the front of the consuming entity of the ECS service in relation to the execution entity EES of the service.
  • the intermediate entity is configured to receive said service execution request from the service consuming entity, decide whether or not to transmit the service execution request to a validation entity.
  • EVS of said request distinct from the execution entity of the EES service, for validation, before transmission (27) of said request to the execution entity of the EES service.
  • Said intermediate entity thus implements the method of processing a request for execution of a service according to the invention which will be detailed below in relation to Figure 2.
  • the entity executing the EES service is included in a subnetwork or private network (not shown) of this RC network, for example that of an NF network function responsible for executing this service.
  • the intermediate entity may or may not be part of the private network and therefore serves to hide the different entities that belong to the private network from other entities in the RC network. Conversely, the entities of this private network only communicate with the rest of the RC network via this intermediate entity.
  • the entity consuming the ECS service sends its REQ request to an identifier (for example a URI) associated with the entity executing the EES service in the RC network or with the network function which implements this service and that it may or may not have previously discovered, and the intermediate entity, which receives this REQ request, then transmits it to a private identifier of this service execution entity or of another entity in the private network to which it belongs.
  • the intermediate entity is a so-called reverse proxy device (in English, “Reverse Proxy”) because it replaces a “public” identifier with a private identifier, unlike conventional intermediate devices .
  • this proxy equipment processes requests conforming to the HTTP2 protocol.
  • the intermediate entity is of the SCP type (in English, “Service Communication Proxy”).
  • SCP Service Communication Proxy
  • This is another type of proxy equipment, defined in particular in version 16 (or “Release 16” in English) of 3GPP, constituting a single entry point for a group of NF network functions. It is therefore external to these network functions. It also processes requests compliant with the HTTP2 protocol. Note that in this case, the identifier used by this SCP proxy equipment is a routable address, therefore public.
  • the system S for managing a request for execution of a service further comprises the validation entity EVS configured to receive said request for execution of the service in coming from the intermediate entity RP, SCP, verifying the validity of said service execution request, comprising obtaining a validation result, and executing at least one request processing action based on the validation result got.
  • the validation entity EVS configured to receive said request for execution of the service in coming from the intermediate entity RP, SCP, verifying the validity of said service execution request, comprising obtaining a validation result, and executing at least one request processing action based on the validation result got.
  • the validation entity EVS thus implements the method of validating a validation request according to the invention which will be detailed below in relation to Figures 3A to 3C.
  • a request for execution of a service Si is received from a consumer entity ECS, for example a first network function of the RC network.
  • ECS electronic commerce
  • the ECS consumer entity following the transmission of this request, the ECS consumer entity generally starts a counter (in English, "timer") and that in the absence of a response received at the expiration of a given period, it can optionally retransmit the request.
  • This request indicates the public identifier of the service requested by the entity consuming the service, which corresponds for example to that of the NF network function or of the application device which provides the requested service.
  • This unique identifier or URI is defined in a profile of the network function or the application device, which is recorded in the network, for example by a network function dedicated to recording such profiles.
  • At least one operating indicator IND is obtained, for example from a memory Ml of the intermediate entity RP, SCP.
  • This is for example an indicator of load or traffic, latency, occupation (saturation) of the physical resources of the network over a given time period of the RC network and/or an indicator of quality of requests previously processed during an elapsed time period, a rate of requests not validated by the validation entity during the given time period, a rate of error messages generated by the service execution entity for requests n not having been subject to prior validation, etc.
  • These indicators are for example determined from measurement data collected in the network by telemetry.
  • this or these indicators are used to decide whether the received REQ request is subject to prior validation or directly transmitted to the EES execution entity concerned.
  • an identifier for example URI
  • At least one CRT decision criterion is taken into account. This is for example a value threshold of said at least one indicator.
  • the decision is made to transmit the REQ request to the EVS validation entity in charge for the If requested service. It is transmitted at 23.
  • a URI2 identifier of the validation entity EVS has been previously obtained, for example, using configuration rules associating each service provided by the RC network, or a network function NF or a group of network functions of the RC network, the identifier of the corresponding EVS validation entity.
  • these configuration rules are grouped in a data table, accessible from the intermediate entity RP, SCP. For example, this information was obtained during a preliminary discovery phase of the service functions available in the RC network and the services they provide.
  • a REP response message is received at 24. It includes a validation information message from the validation entity EVS and therefore includes a validation RES result which can be positive or negative. Depending on the validation result, it is decided at 25 to transmit the REQ request in Tl to the execution entity of the EES service when this validation result is positive and on the contrary to reject the REQ request otherwise.
  • the response message includes at least one location information of the EES execution entity of the requested service, for example a response conforming to the HTTP status code protocol. the class “3xx” indicating a redirection, and more precisely of the type “307 Location: URI3”.
  • a response includes for example a private identifier of the network function or the application device which implements the service and possibly supplemented by an identifier of the EVS validation entity concerned, when the intermediate entity is located inside this network function.
  • the REP response includes a body and a status code.
  • it is a response conforming to the HTTP protocol and the value of the status code is of the “4xx” class.
  • the body and status code conform to 3GPP specifications that are set forth in one or more OpenAPI documents describing the operations of the service.
  • the REP response message is transmitted to the entity consuming the service ECS, which is therefore informed that its request is rejected because it is invalid.
  • a response message REP' including a service execution report is received at 28 from the execution entity EES and transmitted to the consuming entity of the ECS service at 29.
  • the intermediate entity RP, SCP is the recipient of all messages sent by the validation entity EVS and the execution entity EES which do not communicate directly. It therefore potentially receives two response messages, namely the response message REP including the validation result RES transmitted by the validation entity EVS, and in the event of a positive validation result, the response message REP' including the report d execution of the service by the EES execution entity.
  • a single response message is received by the intermediate entity RP, SCP.
  • the validation entity EVS has validated the request
  • only the response message REP' is received at 28, because the validation entity EVS directly transmits the request REQ to the execution entity of the EES service in this second embodiment.
  • a validation information message REP comprising a negative result is received by the intermediate entity RP, SCP at 24.
  • the validation information message REP comprising the negative result, respectively the response message REP', is transmitted if necessary by the intermediate entity RP, SCP to the entity ECS in 29, respectively 26.
  • a REQ request is not necessarily subject to validation, which makes it possible to limit the latency time introduced by the implementation of the invention.
  • an error message can be issued by the EES execution entity, when the REQ request presents non-conformities making it impossible to execute the requested service or operation.
  • this error message may indicate an HTTP status code in class 5xx or a 404 Not Found status code.
  • a request for execution of a REQ service is received at 30 by the validation entity EVS coming from the intermediate entity RP, SCP.
  • the information fields making up this REQ request are checked.
  • the verification concerns the request body and any associated parameters and headers.
  • the EVS validation entity was for example designed from a document describing the API programming interface of the service of the execution entity of the service considered, for example in OpenAPI format, which describes all the information fields of the request body, as well as any associated parameters and headers. Note that this OpenAPI format also describes the structure of response messages.
  • the EVS validation entity thus verifies that the body of the request and any associated parameters and headers comply with those defined in the service programming interface description document. At the end of this verification, the validation entity EVS provides a RES result (positive in the event of conformity of all the elements of the REQ request which have been verified by the EVS validation entity, negative in the event of non-conformity of at least one of these elements), which is taken into account counts in 32 to decide on an ACT action to trigger.
  • the decided action is the sending in 321 of a response REP to the intermediate entity RP, SCP.
  • this REP response message is a validation information message including a positive RES result.
  • it includes identification/location information of the entity executing the EES service in the RC network and for example in the private network of the network function to which it belongs.
  • said identification/location information is a universal URI type identifier (URI3) which is not known to the entity consuming the ECS service.
  • URI3 universal URI type identifier
  • the REP response message includes, in the body of the message, an error code; it may also include a description of the errors (in other words non-conformities) identified.
  • the status code is HTTP 400, which means “Bad Request”. Note that the body of the error response message conforms to the OpenAPI description for any service operation considered.
  • the ACT action decided is to directly transmit the REQ service execution request in 322 to the entity EES execution (using the URI3 identifier).
  • a response message REP' comprising an execution report issued by the execution entity EES is received at 323 and transmitted at 324 to the intermediate entity RP, SCP.
  • the validation entity EVS plays an intermediary role between the intermediate entity RP, SCP and the execution entity of the ECS service.
  • the validation entity EVS is integrated into the intermediate entity RP, SCP.
  • a 5G core network as specified by the 3GPP is composed of different NF network functions, each having a well-defined role.
  • An NF network function is typically responsible for running several distinct services.
  • a network function service is described by 3GPP in the form of one or more API application programming interfaces, themselves specified in a description document conforming to the OpenAPI format.
  • One objective of an API is in particular to define the content of requests for execution of a service sent by an entity consuming the service and the content of the responses sent by the entity executing or producing the service.
  • REST API type APIs are very common today in cloud computing, which consists of using remote servers to process, store and manage data, and apply to any business domain.
  • the invention relates more generally to any application programming interface, for example of the REST API type, designed to execute a service in response to requests from consuming entities whose validity the designer wishes to check.
  • the network function NRF (from English, “Network function Repository Function”) for recording NF network functions, the role of which is to provide an up-to-date directory of the state NF network functions of a 5G core network and their data defined in a profile (in English, “NFProfile”).
  • This profile notably includes an identifier (URI) allowing each NF network function to be located in the 5G core network. This identifier generally points to a logical address.
  • This directory is updated at the time of instantiation of each NF function (registration) and when an NF function sees its characteristics modified, for example when it is resized.
  • the NRF network function thus offers an NF function discovery service. To do this, it implements a service called “Nnrf_NFManagement” for managing profiles and subscriptions of NF network functions.
  • the operations offered to manage an NF network function profile include saving, updating, deleting and viewing.
  • the request for executing an operation to record an NF function profile is PUT/nf-instances/ ⁇ nflnstancelD ⁇ . It has a request body of type NFProfile.
  • the OpenAPI request description for this operation is: put: summary: Register a new NF Instance operationld: RegisterNFInstance tags:
  • a network function NFx of the RC network configured to provide N services, with N integer greater than or equal to 1, and comprising an intermediate entity RP of reverse proxy type and entities EES execution and EVS validation of N services.
  • this intermediate entity RP is configured to implement the method of processing a request for execution of a service, as previously described.
  • EVS and EES relating to a given service Si, with i integer between 1 and N.
  • a REQ request is received by the reverse proxy RP of the network function NFx coming from a consuming entity ECS of the network, for example another network function of the RC network.
  • This request identifies the service Si by specifying a unique identifier of this service Si in the RC network, for example the URI U RI 1.
  • This identifier URI1 was for example obtained by the consuming entity ECS from the Nnrf_NFmanagement service for managing the profiles of the NRF network function previously mentioned.
  • the REQ request is then transmitted to the validation entity EVS.
  • the “public” identifier URI1 was replaced by the reverse proxy RP by a private identifier of type URI, URI2, associated with the validation entity EVS, which is internal to the NFx network function, and therefore n is not known outside of the NFx network function.
  • the EVS validation entity verifies that it complies with the service API specification document If requested. In the example in Figure 4, the REQ request is validated.
  • the validation entity EVS returns a REP response to the reverse proxy RP indicating, in a dedicated header, for example the “location” location header, the private identifier URI3 of the execution entity EES of the Si service.
  • This REP response includes a status code, which corresponds here, in the case of a validated request, to the HTTP redirection code 307.
  • This is a standard HTTP response of redirection type (with a code HTTP status of class 3xx). Note that the entity serving a response of this type indicates the Redirection URL in the location header.
  • the reverse proxy RP transmits the REQ request to the execution entity EES using the identifier URI3. It receives a REP' response including an execution report which it then transmits to the entity consuming the ECS service.
  • the REP response message sent by the validation entity EVS to the reverse proxy RP includes an error code, namely in the embodiment described here, an HTTP error code of class “4xx”.
  • the reverse proxy RP Upon receipt, the reverse proxy RP transmits it to the consuming entity of the ECS service.
  • the reverse proxy RP upon receipt of the REQ request, transmits it to the validation entity EVS as previously described.
  • the EVS validation entity checks it but does not validate it. It therefore sends a REP response to the reverse proxy RP including an MERR error message.
  • this error message uses the HTTP status code of the “4xx” class.
  • the intermediate entity receives it and transmits it to the ECS consumer entity as previously described.
  • the EVS entity directly transmits the REQ request to the EES execution entity of the If requested service, using its private identifier URI3. It receives a REP' response from the execution entity EES, which it transmits to the reverse proxy RP. On receipt, the intermediate entity RP transmits the response to the ECS service consuming entity.
  • the REQ request is received by the intermediate entity RP which decides on the basis of at least one decision criterion based on at least one operating indicator, not to submit it to the validation of the EVS validation entity. It obtains the URI4 identifier of the EES service execution entity via configuration rules and therefore transmits the REQ request directly to it.
  • the execution entity of the EES service executes the service and returns a REP' response to it including a result of this execution.
  • the validation entity EVS and the intermediate entity are external to the network function NFx which implements the service Si requested by the The consuming entity of the ECS service and the EVS validation entity.
  • the intermediate entity is SCP equipment as previously described.
  • this SCP is configured to provide a single entry point for a group of network functions that are registered in the NRF, including the NFx. In other words, only the SCP knows the NFx producing the If requested service.
  • the validation entity EVS is included in another network function (not shown in Figures 10 to 12), which can group together several validation entities of distinct services. Note that in the following, certain steps will not be described in detail because they are carried out in a manner similar to the examples in Figures 4 to 9.
  • the SCP equipment receives the REQ request from the ECS service consuming entity.
  • This REQ request is addressed to the public identifier URI1 of the SCP equipment and includes an identifier of the desired Si service, for example the name of the service API of the NFx network function that implements the Si service (for example, “nsmf-pdusession/vl”).
  • the SCP equipment transmits it to the EVS validation entity concerned using the URI2 identifier of this EVS entity which it has previously obtained from the identifier of the NFx network function and profile information of the function NFx obtained from the NRF network function. This is not a private identifier, but a routable address in the RC network.
  • the EVS entity verifies the REQ request received and sends to the SCP equipment (URI1) a validation REP response message including a positive result (for example with a status code 307).
  • the REP response does not include a private identifier URI3 allowing access to the EES execution entity of the If requested service.
  • the SCP equipment obtains the URI3 identifier in question from the identifier of the service Si produced by the network function NFx and profile information from the network function which provides the service Si, previously obtained from the function NRF network. It transmits the REQ request to the EES execution entity using the URI3 identifier.
  • the REQ request is not received directly by the execution entity of the EES service, but by an intermediate entity included in the NFx network function, for example reverse proxy equipment RP as previously described and which is responsible for transmitting the REQ request to the private identifier of the EES entity inside the NFx network function.
  • URI3 is the identifier of the reverse proxy equipment RP of the NFx network function and that the private identifier of the EES entity is not known from outside the NFx network function.
  • the EES entity executes the If requested service and sends a REP' response message to the RP equipment, which transmits it to the SCP intermediate entity.
  • the SCP equipment Upon receipt, the SCP equipment transmits it to the consuming entity of the ECS service.
  • the SCP is configured to determine this URI3 identifier before the actual validation of the REQ request.
  • the SCP intermediate entity is only configured to then insert it into a response message and not into the request itself as proposed by the present invention.
  • the validation entity EVS validates the REQ request.
  • Its REP response for example a standard HTTP response of redirection type (with an HTTP status code of class 3xx), includes the private identifier URI3 of the NFx network function previously received, which allows the SCP equipment to transmit the REQ request directly to this URL identifier.
  • the following corresponds to what was previously described in relation to Figure 11. Note that the use of the “3gpp-Sbi-Target-apiRoot” location header which comes from be described complies with the specifications of the 3GPP standard.
  • the SCP intermediate entity is the only recipient of the “3gpp-Sbi-Target-apiRoot” location header contained in a request and the only entity/function of the 5G core network configured to be placed in break of a client-server transaction.
  • the SCP intermediate entity is configured to process this header and then forward the request to the URI that this header carries. This header is used to force the passage of a request through the SCP intermediate entity.
  • the present invention proposes to define a new EVS entity/function for validating requests, to insert it in disconnection from client/server exchanges and to configure it so that it transmits validated requests directly to the entity of execution of the EES service. To do this, it relies on this location header. This results in the implementation of the "3gpp-Sbi-Target-apiRoot" header made in fig.ll differs strictly from what is described in the 3GPP standard today.
  • a header of the REQ request is modified, for example the 3gpp-Sbi-Target-apiRoot header, by the SCP equipment to insert the public identifier URI3 of the NFx network function which implements the If requested service.
  • the REQ request has been validated by the EVS entity, the latter transmits it directly to the NFx network function using the URI3 identifier that it has retrieved from the modified header.
  • the reverse proxy equipment RP which transmits it to the identifier of the execution entity EES, internal to the NFx network function.
  • a REP' response is returned by the EES entity to the reverse proxy RP which transmits it to the SCP which itself transmits it to the entity consuming the ECS service.
  • the validation entity is configured to process the “3gpp-Sbi-Target-api-Root” header, as described in the 3GPP standard for the SCP intermediate entity.
  • the validation entity EVS of the service could be integrated directly into the SCP.
  • an example of hardware structure of an intermediate entity RP, SCP configured to process a request for execution of a service in a communication network, coming from a entity, said entity consuming the service, to an entity executing said service in said network, said intermediate entity being configured to receive messages coming from and/or intended for the entity executing the service, and comprising a module for transmitting the execution request to an entity for validating said request, distinct from the execution entity of the service, for validation, and a module for transmitting a response to said request to the entity consuming the service .
  • the intermediate entity RP, SCP comprises a module for receiving a validation response message coming from the validation entity, said message comprising the validation result, and a decision-making module for transmit or not the execution request to the execution entity of the service depending on the validation result received.
  • it further comprises a module for transmitting the service execution request to the service execution entity, said module being configured to be implemented in response to a positive validation result.
  • module can correspond as well to a software component as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms or more generally to any element of a program capable of implementing a function or a set of functions.
  • SCP comprises a random access memory 103 (for example a RAM memory), a processing unit 102 equipped for example with a processor, and controlled by a computer program Pgl, representative of the aforementioned modules, stored in a read only memory 101 (for example a ROM memory or a hard disk).
  • a computer program Pgl representative of the aforementioned modules, stored in a read only memory 101 (for example a ROM memory or a hard disk).
  • the code instructions of the computer program are for example loaded into the RAM 103 before being executed by the processor of the processing unit 102.
  • the RAM 103 can also contain, for example, information relating to the validation entity of the service and/or to the execution entity of the service, such as for example identifiers, allowing access to this or these entities, for example obtained during a preliminary discovery phase.
  • Figure 13 illustrates only one particular way, among several possible, of creating the intermediate entity RP, SCP so that it carries out the steps of the method of processing a request for execution of a service as detailed above, in relation to Figures 2 and 3, in its different embodiments. Indeed, these steps can be carried out indifferently on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated calculation machine (for example a set of logic gates like an FPGA or an ASIC, or any other hardware module).
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a program comprising a sequence of instructions
  • a dedicated calculation machine for example a set of logic gates like an FPGA or an ASIC, or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) can be stored in a removable storage medium (such as for example an SD card, a USB key, a CD-ROM or a DVD-ROM) or not, this storage medium being partially or totally readable by a computer or a processor.
  • a removable storage medium such as for example an SD card, a USB key, a CD-ROM or a DVD-ROM
  • an EVS validation entity of a request for execution of a service in a communication network said request having been issued by a entity consuming the service intended for an execution entity of the service, comprising a module for receiving said execution request coming from an intermediate entity RP, SCP configured to process said execution request, said validation entity being configured to receive messages coming from and/or intended for the execution entity of the service of the execution entity, a module for verifying the validity of said request, comprising obtaining a result validation and a module for triggering a request processing action based on the validation result obtained.
  • module can correspond as well to a software component as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms or more generally to any element of a program capable of implementing a function or a set of functions.
  • such a validation entity EVS comprises a random access memory 203 (for example a RAM memory), a processing unit 202 equipped for example with a processor, and controlled by a computer program Pg2, representative of the aforementioned modules, stored in a read only memory 201 (for example a ROM memory or a hard disk).
  • a computer program Pg2 representative of the aforementioned modules, stored in a read only memory 201 (for example a ROM memory or a hard disk).
  • the code instructions of the computer program are for example loaded into the RAM 203 before being executed by the processor of the processing unit 202.
  • the RAM 203 can also contain, for example, information identification of the entity executing the requested service and/or the intermediate entity RP, SCP.
  • Figure 14 illustrates only one particular way, among several possible, of realizing the validation entity EVS so that it carries out the steps of the method of validating a request for execution of a service as detailed below. above, in relation to Figures 4 to 12, in its different embodiments. Indeed, these steps can be carried out indifferently on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated calculation machine (for example a set of logic gates like an FPGA or an ASIC, or any other hardware module).
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a program comprising a sequence of instructions
  • a dedicated calculation machine for example a set of logic gates like an FPGA or an ASIC, or any other hardware module.
  • the corresponding program i.e. the sequence of instructions
  • a removable storage medium such as for example an SD card, a USB key, a CD-ROM or a DVD-ROM ) or not, this storage medium being partially or totally readable by a computer or a processor.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Procédé de traitement d'une requête d'exécution d'un service (REQ) dans un réseau de communication, en provenance d'une entité consommatrice du service (ECS), à destination d'une entité d'exécution dudit service (EES), caractérisé en ce qu'il est mis en œuvre au niveau d'une entité intermédiaire configurée pour recevoir des messages en provenance de l'entité consommatrice du service et destinés à l'entité d'exécution du service (EES) ou en provenance de l'entité d'exécution du service et destinés à l'entité consommatrice du service, et comprend : - la réception (20) de ladite requête d'exécution du service (REQ) en provenance de l'entité consommatrice du service (ECS); - la prise de décision (22) de transmettre (23) ou non pour validation la requête d'exécution du service (REQ) vers une entité de validation (EVS) de ladite requête, distincte de l'entité d'exécution du service (EES), avant transmission (27) de ladite requête à l'entité d'exécution du service (EES).

Description

Description
Titre de l'invention : Procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d'ordinateur correspondants
Domaine de l'invention
[0001] Le domaine de l'invention est celui d'un réseau de communication, en particulier d'un réseau de communication mettant en œuvre une architecture orientée services et basée sur des fonctions réseau.
[0002] Dans un tel réseau, l'invention concerne en particulier la validation d'une requête d'exécution d'un service avant sa transmission à l'entité d'exécution du service.
Art antérieur
[0003] Le réseau cœur 5G est composé de multiples fonctions réseau NF (en anglais, « Network Function »), chacune ayant un rôle et une logique propre. Une NF est généralement en charge de l'exécution de plusieurs services. Chaque service a un rôle et une logique propres au sein de sa NF. Afin qu'un service communique avec un autre, chaque service est accessible sous la forme d'une interface de type interface de programmation ou API (en anglais, « Application Programming Interface »).
[0004] L'organisme de normalisation 3GPP spécifie l'API de chacun des services mis en œuvre par les fonctions réseau NF qu'il a définies pour le réseau cœur 5G, dans un document écrit dans un langage de description dédié (OpenAPI version 3). Ce document décrit entre autres les opérations supportées par le service et le format des structures des données échangées. Ces structures de données sont un ensemble d'attributs, chaque attribut étant caractérisé par un type simple (chaîne de caractères, nombre, booléen, etc.) ou le type d'une structure, d'un nom et des valeurs autorisées. Il peut, le cas échéant, préciser des contraintes applicables à des attributs ou à des groupes d'attributs. Le 3GPP spécifie en outre que toute requête d'exécution d'une opération du service qui n'est pas conforme au format de l'API de ce service doit être rejetée par le service sollicité et prévoit différents messages d'erreur à retourner à l'entité qui a émis la requête.
[0005] En effet, le traitement par un service donné de requêtes d'exécution d'opérations non conformes à l'API de ce service peut entraîner des dysfonctionnements, avec des conséquences indéterminées sur le fonctionnement du service lui-même, de la fonction réseau NF qui héberge le service voire du réseau cœur. On note à cet égard que l'émission d'une requête d'exécution d'une opération non valide (c'est-à-dire non conforme à l'API) peut être intentionnelle ou non, par exemple due à un défaut de conception d'un programme informatique (en anglais, « bug »). Compte tenu du fait que le réseau cœur 5G dans sa première version (version 15) compte déjà plus de 50 services, on comprend que la multiplication de ces dysfonctionnements peut impacter non seulement la qualité de service, mais aussi la sécurité générale du réseau cœur.
[0006] Aujourd'hui, un contrôle de la validité des requêtes d'exécution d'un service ou d'une opération d'un service est effectué par l'entité en charge d'exécuter le service. Ainsi, les fonctions réseau NF du réseau cœur et, par là même l'entité en charge d'exécuter un service de cette fonction réseau, sont typiquement des entités logicielles, comprenant une couche de validation des requêtes et une couche d'exécution du service. Toutefois, généralement, le fichier exécutable d'un service comporte de façon indissociable la logique métier du service et le contrôle de validité d'opérations. Il en résulte que dès qu'un changement survient pour l'exécution du service, l'ensemble du logiciel doit être mis à jour et retesté, même si la partie validation d'opérations n'est pas affectée par ce changement. [0007] Or, les fonctions réseau NF du réseau cœur sont des entités logicielles (c'est-à-dire des logiciels) qui peuvent être conçues à partir de langages informatiques issus d'environnements de conception (en anglais, « framework ») variés. Les choix de ces technologies logicielles appartiennent aux concepteurs de services et aux constructeurs des équipements serveurs qui hébergent ces services. Ils sont faits en fonction de l'adéquation des spécificités du service à concevoir et des technologies logicielles maîtrisées par leurs équipes de recherche et développement. Les écosystèmes logiciels actuels sont en effet multiples et variés, de sorte que la maîtrise de tous ces écosystèmes demande un investissement conséquent pour un constructeur. On comprendra aussi que l'écosystème logiciel le plus approprié pour la conception d'un service n'est pas forcément celui qui fournit le meilleur niveau de contrôle de la validité d'une opération exécutée par ce service.
[0008] En outre, les interfaces de programmation API des services du réseau cœur 5G sont complexes et évoluent régulièrement au rythme de plusieurs publications par an. Par conséquent, le développement d'une couche logicielle de validation d'opérations, dépendant d'une part de la version 3GPP du service en question et d'autre part, de l'éco système logiciel d'une couche logicielle d'exécution de ce service, est une tâche qui doit être répétée par les programmeurs fréquemment et dans un environnement de programmation non optimal, nécessitant un investissement conséquent pour un risque élevé de bugs et de régressions.
[0009] On connaît enfin des outils de génération automatique de code informatique de la couche de validation à partir des documents de description OpenAPI d'une API d'un service d'une fonction réseau NF donnée du réseau cœur 5G. Un avantage de ces outils est qu'ils sont capables de produire un nouveau code informatique de la couche de validation pour tout nouveau service ainsi que pour une nouvelle version 3GPP d'un service existant. Par rapport à une conception réalisée par un programmeur, la qualité du code produit est supérieure (risque de bugs et de régressions plus faible). Néanmoins, le format OpenAPI de description des API du réseau cœur évoluant lui aussi au gré de versions successives, il en découle que les outils de génération automatique de code informatique doivent eux aussi évoluer. [0010] Il existe donc un besoin d'une solution de validation des requêtes d'exécution d'un service qui soit à la fois plus efficace et plus simple à mettre en œuvre et à maintenir. L'invention vient améliorer la situation.
Exposé de l'invention
[0011] L'invention répond à ce besoin en proposant un procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication, en provenance d'une entité dite consommatrice du service, à destination d'une entité d'exécution dudit service, ledit procédé étant mis en œuvre au niveau d'une entité intermédiaire configurée pour recevoir des messages en provenance de l'entité consommatrice du service et destinés à l'entité d'exécution du service ou en provenance de l'entité d'exécution du service et destinés à l'entité consommatrice du service, et comprenant :
- la réception de ladite requête d'exécution du service en provenance de l'entité consommatrice du service;
- la prise de décision de transmettre ou non pour validation la requête d'exécution du service vers une entité de validation de ladite requête, distincte de l'entité d'exécution du service, avant transmission de ladite requête à l'entité d'exécution du service .
[0012] L'invention propose ainsi une approche tout-à-fait nouvelle et inventive du traitement d'une requête d'exécution d'un service opéré par un réseau de communication, qui consiste d'une part à séparer la validation préalable de la requête de l'exécution du service proprement dite et d'autre part à confier le traitement de ces requêtes et leur aiguillage vers l'une et/ou l'autre des entités de validation et d'exécution du service, à une entité intermédiaire placée en coupure des requêtes d'exécution de service émises par des entités consommatrices dans le réseau de communication et en frontal des entités de validation et d'exécution du service.
[0013] Par exemple, selon l'invention, ces fonctions de validation des requêtes et d'exécution du service, sont remplies par des entités distinctes du réseau de communication. De la sorte, chacune d'entre elles peut être conçue dans l'environnement de conception considéré comme le plus adapté par le concepteur/constructeur. L'invention permet aussi d'utiliser un unique environnement de conception pour concevoir les entités de validation de requêtes d'exécution de plusieurs services distincts, quelle que soit l'API qui leur est associée et l'environnement de conception utilisé pour développer l'entité d'exécution du service correspondant. Grâce à l'invention, un acteur du domaine peut donc se spécialiser dans la conception d'entités/composants de validation d'opérations d'API de services de fonctions réseau d'un réseau de communication. Avec l'invention, c'est l'entité intermédiaire qui a le contrôle du traitement des requêtes et de leur éventuelle validation préalable. Du fait de sa position en coupure du flux des requêtes entre des entités clientes (consommatrices d'un service) et des entités serveuses (qui produisent/exécutent les services), elle a la visibilité sur toutes les transactions relatives aux services en question et dispose d'informations pour décider s'il est nécessaire qu'une requête reçue fasse ou non l'objet d'une validation préalable, ce qui permet notamment une adaptation à un contexte de fonctionnement, comme par exemple un état de saturation du réseau, un niveau de qualité des requêtes reçues en fonction du service demandé etc. Elle peut mettre en œuvre, si besoin, une validation systématique de toutes les requêtes qu'elle reçoit ou au contraire choisir de ne soumettre à une validation préalable qu'une partie des requêtes en s'appuyant sur des informations dont elle dispose sur un état de fonctionnement du réseau de communication, comme l'état du trafic, un niveau de qualité des requêtes précédemment reçues etc.
[0014] L'invention offre ainsi une grande flexibilité, tout en ne dérogeant pas aux critères de qualité requis. Elle laisse également la possibilité de faire évoluer la politique de validation choisie dans le temps.
[0015] L'invention permet aussi d'augmenter la modularité d'un réseau de communication.
[0016] Elle permet également d'optimiser et de rationaliser les efforts d'investissement d'un constructeur de solutions logicielles de validation de requêtes d'exécution de service dans un contexte d'écosystèmes logiciels hétéroclites.
[0017] Elle est particulièrement adaptée à un réseau de communication, tel que le réseau cœur 5G, mettant en œuvre une architecture d'informatique en nuage, (en anglais, « cloud computing »), virtualisée et distribuée de fonctions réseau, qui favorise le partage, via des réseaux, de ressources qui donnent accès à une infrastructure, des services, des plateformes et des applications à la demande. [0018] Dans une telle architecture, les ressources physiques ou matérielles, par exemple d'équipements serveurs disposant de capacités de calcul et de mémoire importantes, sont exploitées par un or- chestrateur qui supervise en temps réel l'allocation de quotas de mémoire et de calcul, appelés machines virtuelles ou instances de conteneurisation, à des entités logicielles de type fonction réseaux NF, des services de ces fonctions réseau NF ou encore des opérations de ces services, surveille la quantité de mémoire et le temps de calcul ou CPU (« Central Processing Unit », en anglais) effectivement utilisés par chaque entité et réplique/supprime la machine virtuelle ou les instances de conteneurisation d'une entité logicielle donnée pour répondre à des besoins accrus/décrus. [0019] Par exemple, le service requis par l'entité consommatrice de services est mis en œuvre dans une fonction réseau donnée. Une telle fonction réseau est composée d'entités organisées entre elles en réseau et qui ne sont pas atteignables/routables directement depuis l'extérieur. On comprend que ces entités (et la fonction réseau associée) forment une sorte de sous-réseau dont l'entité consommatrice du service ne connaît généralement qu'un identifiant public, par exemple une URI. Cette fonction réseau peut rendre un ou plusieurs services.
[0020] L'entité intermédiaire joue ainsi le rôle de passerelle entre l'entité consommatrice du service, qui demande l'exécution de ce service, et l'entité d'exécution (ou de production) du service demandé. Il s'agit par exemple d'un équipement proxy inversé (en anglais, « reverse proxy ») qui masque à l'entité consommatrice du service la présence des entités appartenant à la fonction réseau et qui contribuent à l'exécution du service demandé.
[0021] L'invention s'inscrit donc dans la tendance de désagrégation ou décomposition de la logique du réseau cœur 5G.
Avantageusement, l'invention est mise en œuvre au niveau d'une entité intermédiaire placée en coupure (en frontal) du chemin réseau emprunté par les requêtes d'exécution d'un service et configurée pour transmettre les requêtes à valider à une entité de validation distincte de l'entité d'exécution du service.
[0022] Selon un autre aspect de l'invention, le procédé comprend :
- la transmission de ladite requête d'exécution du service à l'entité de validation du service ;
- la réception d'au moins un message de réponse parmi un message d'information de validation et un message de rapport d'exécution ; et
- la transmission du message de réponse reçu à l'entité concernée parmi l'entité consommatrice du service et l'entité d'exécution du service, en fonction du message de réponse reçu.
[0023] Un avantage est que l'entité intermédiaire intègre l'intelligence nécessaire pour transmettre les messages de requête et/ou de réponse qu'il reçoit à la bonne entité. En outre, son rôle et sa position lui donnent une visibilité sur la qualité de requêtes, ce qui lui permet de décider de suspendre ou non la validation systématique des prochaines requêtes à traiter.
[0024] L'invention permet ainsi la mise en œuvre d'au moins deux modes de réalisation :
- selon un premier mode de réalisation, l'entité de validation et l'entité d'exécution du service ne communiquent pas directement entre elles. L'entité intermédiaire est le passage obligé de messages entre l'entité de validation et l'entité d'exécution de service. Selon ce mode de réalisation, l'entité intermédiaire reçoit le message d'information de validation en provenance de l'entité de validation du service. Si la requête n'est pas validée, ce message d'information de validation comprend un corps de message décrivant la cause du rejet et un code de statut. Par exemple, un message de réponse conforme aux spécifications du 3GPP comprend un code de statut HTTP de la classe 4xx. Lorsque la requête a été validée, le message d'information comprend un code de statut qui indique à quelle entité la requête doit être transmise, qui vaut validation de la requête. Dans le mode de réalisation décrit ici, ce code de statut est un code HTTP de classe 3xx.
[0025] Par conséquent, l'entité intermédiaire reçoit toujours au moins le message d'information de validation et, le cas échéant, le rapport d'exécution ;
- selon un deuxième mode de réalisation de l'invention, l'entité de validation et l'entité d'exécution du service communiquent directement entre elles. En cas de validation positive, l'entité de validation transmet directement la requête d'exécution du service à l'entité d'exécution et reçoit en retour le rapport d'exécution qu'elle transmet à l'entité intermédiaire. Si la requête n'est pas validée, l'entité de validation envoie un message d'information de validation à l'entité intermédiaire. Par conséquent, l'entité intermédiaire reçoit toujours au moins soit un message de validation négatif, soit un rapport d'exécution.
[0026] Selon encore un autre aspect de l'invention, le au moins un message de réponse reçu comprend un message d'information de validation de l'entité de validation comprenant un résultat de validation, le message d'information de validation est transmis vers l'entité consommatrice du service lorsque le résultat de validation est négatif, et la requête d'exécution du service est transmise vers l'entité d'exécution du service lorsque le résultat de validation est positif.
[0027] Selon ce premier mode de réalisation, l'entité intermédiaire est aussi le passage obligé entre l'entité de validation et l'entité d'exécution du service, qui ne communiquent pas directement l'une avec l'autre. Cette configuration est particulièrement adaptée au cas où elles n'appartiennent pas au même sous-réseau ou à la même fonction réseau.
[0028] L'entité consommatrice du service reçoit un message d'erreur de validation et la requête n'est pas transmise à l'entité d'exécution du service. Un avantage est que l'entité consommatrice du service est ainsi informée que la requête d'exécution du service est rejetée parce qu'elle n'est pas valide.
[0029] Selon encore un autre aspect de l'invention, le procédé comprend, en réponse à un résultat de validation positif, l'obtention par l'entité intermédiaire d'un identifiant de l'entité d'exécution du service), et la requête d'exécution du service est transmise à l'entité d'exécution du service en utilisant ledit identifiant obtenu.
[0030] Un avantage est que l'identifiant permettant d'accéder à l'entité d'exécution du service n'est obtenu par l'entité intermédiaire qu'en cas de validation réussie. On garantit ainsi que l'entité d'exécution du service ne traite que des requêtes valides. Cet identifiant peut être privé, lorsque l'entité d'exécution de service est comprise dans une fonction de réseau ou un sous-réseau d'un autre type, et public sinon, de sorte à permettre d'atteindre directement l'entité d'exécution du service. L'identifiant de l'exécution du service peut être obtenu par l'entité intermédiaire à partir du message d'information de validation reçu en provenance de l'entité de validation (par exemple, il est contenu dans ce message), ou en variante être déterminé par l'entité intermédiaire.
[0031] Selon encore un autre aspect, ledit au moins un message de réponse reçu comprend un message de rapport d'exécution du service émis par l'entité d'exécution du service et en ce que ledit message de rapport d'exécution du service est transmis vers l'entité consommatrice du service.
[0032] Avantageusement, lorsque la requête a été validée, l'entité intermédiaire reçoit dans tous les cas (que l'entité de validation soit connectée ou non à l'entité d'exécution du service) un message de rapport d'exécution comprenant un résultat ou au moins une confirmation de l'exécution du service en provenance de l'entité d'exécution du service, qu'il transmet à l'entité consommatrice du service.
[0033] Selon un autre aspect de l'invention, la décision de transmettre ou non ladite requête à l'entité de validation du service est prise en fonction d'au moins un critère de décision donné relatif à au moins un indicateur de fonctionnement du réseau et/ou un type de la requête d'exécution du service.
[0034] Par exemple, ledit au moins un indicateur de fonctionnement du réseau appartient à un groupe d'indicateurs d'un état de fonctionnement du réseau, comprenant au moins un indicateur de trafic, de latence, d'occupation (saturation) des ressources physiques du réseau sur une période temporelle donnée, un indicateur de qualité des requêtes d'exécution de service tel que par exemple un taux de requêtes non validées par l'entité de validation pendant la période temporelle donnée, un taux de messages d'erreurs générés par l'entité d'exécution du service pour des requêtes n'ayant pas fait l'objet d'une validation préalable, etc. Il peut s'agir aussi d'un compteur de requêtes d'exécution de service précédemment soumises à validation pendant une période temporelle écoulée. Par exemple, une requête est transmise directement toutes les dix requêtes soumises à validation. Quant au critère de décision, il comprend un seuil de valeur du dit au moins un indicateur.
[0035] En variante, on peut envisager que le critère pour décider de transmettre ou non la requête à l'entité de validation soit en lien avec un type de requêtes d'exécution de service (par exemple, selon si ces requêtes concernent la création, la modification, la suppression ou encore la consultation d'une ressource).
[0036] De la sorte, l'invention permet de réaliser un compromis entre l'effort mis sur la validation des requêtes d'exécution d'un service et la préservation des ressources du réseau.
[0037] L'invention concerne également une entité intermédiaire d'un réseau de communication, configurée pour recevoir des messages en provenance en provenance d'une entité, dite consommatrice d'un service, et à destination d'une entité d'exécution dudit service et pour recevoir des messages en provenance de l'entité d'exécution du service et destinés à l'entité consommatrice du service, et configurée pour mettre en œuvre :
- la réception d'une requête d'exécution du service en provenance de l'entité consommatrice du service ;
- la prise de décision de transmettre ou non pour validation la requête d'exécution du service vers une entité de validation de ladite requête, distincte de l'entité d'exécution du service, avant transmission de ladite requête à l'entité d'exécution du service.
[0038] Avantageusement, ladite entité intermédiaire est configurée pour mettre en œuvre les étapes du procédé de traitement d'une requête tel que décrit précédemment.
[0039] Corrélativement, l'invention concerne aussi un procédé de validation d'une requête d'exécution d'un service dans un réseau de communication, ladite requête ayant été émise par une entité dite consommatrice du service dudit réseau à destination d'une entité d'exécution du service , ledit procédé étant mis en œuvre au niveau d'une entité de validation du service distincte de ladite entité d'exécution et en ce qu'il comprend :
- la réception de ladite requête d'exécution du service en provenance d'une entité intermédiaire configurée pour recevoir des messages à destination de ou en provenance de l'entité d'exécution du service;
- la vérification d'une validité de ladite requête d'exécution du service, comprenant l'obtention d'un résultat de validation ; et
- l'exécution d'au moins une action en fonction du résultat de validation obtenu.
[0040] Avec l'invention, la validation des requêtes est donc assurée par une entité distincte de l'entité d'exécution du service. Cette entité indépendante reçoit les requêtes à valider de l'entité intermédiaire. Elle peut donc être conçue dans un environnement différent de celui de l'entité d'exécution. Elle peut aussi être mutualisée pour plusieurs services.
[0041] Selon un aspect de l'invention, ladite au moins une action comprend la transmission d'un message d'information de validation comprenant le résultat de validation à l'entité intermédiaire.
[0042] Un avantage est que la responsabilité de décider si une requête d'exécution d'un service doit être transmise ou non à l'entité d'exécution du service est entièrement confiée à l'entité intermédiaire. L'entité de validation a pour unique charge de valider les requêtes d'exécution de service qu'elle reçoit de cette entité intermédiaire et de lui renvoyer un résultat de validation.
[0043] Selon un mode de réalisation particulier, une réponse de validation positive peut comprendre en outre un identifiant de l'entité d'exécution du service.
[0044] Cet identifiant permet à l'entité intermédiaire de transmettre à l'entité d'exécution du service la requête d'exécution du service. Un avantage est qu'il n'est obtenu par l'entité intermédiaire que lorsque la requête d'exécution a été considérée comme valide par l'entité de validation du service.
[0045] Selon un autre aspect de l'invention, lorsque le résultat de validation est positif, ladite au moins une action comprend la transmission de ladite requête d'exécution du service à l'entité d'exécution du service.
[0046] Un avantage est que l'entité de validation redirige directement une requête d'exécution de service considérée comme valide à l'entité d'exécution du service concernée. De la sorte, la latence introduite par la phase de validation est réduite au minimum.
[0047] Selon encore un autre aspect de l'invention, ladite au moins une action comprend en outre la réception d'un message de réponse en provenance de l'entité d'exécution du service comprenant un rapport d'exécution du service et la transmission dudit message de réponse à destination de l'entité intermédiaire.
[0048] L'invention concerne également une entité de validation d'une requête d'exécution d'un service dans un réseau de communication, ladite requête ayant été émise par une entité consommatrice du service à destination d'une entité d'exécution du service. L'entité de validation est configurée pour mettre en œuvre :
- la réception de ladite requête d'exécution, ladite requête ayant été transmise à l'entité de validation par une entité intermédiaire configurée pour recevoir des messages en provenance en provenance d'une entité, dite consommatrice d'un service, et à destination d'une entité d'exécution dudit service et pour recevoir des messages en provenance de l'entité d'exécution du service et destinés à l'entité consommatrice du service;
- la vérification d'une validité de ladite requête ; et
- la transmission d'un message de réponse à destination de l'entité intermédiaire comprenant au moins un résultat de validation.
[0049] Avantageusement, ladite entité de validation est configurée pour mettre en œuvre les étapes du procédé de validation d'une requête tel que décrit précédemment.
[0050] Avantageusement, ladite entité intermédiaire et ladite entité de validation sont comprises dans un système de gestion d'un service dans un réseau de communication, ledit système comprenant une entité consommatrice du service et une entité d'exécution du service, ladite entité consommatrice étant configurée pour transmettre une requête d'exécution du service à l'entité d'exécution du service. [0051] Le système présente au moins les mêmes avantages que ceux conférés par le procédé de traitement et le procédé de validation précités.
[0052] L'invention concerne également des produits programmes d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre des procédés de traitement et de validation tels que décrits précédemment, lorsqu'ils sont exécutés par un processeur.
[0053] Un 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.
[0054] L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel sont enregistrés les programmes d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes des procédés selon l'invention tel que décrits ci-dessus.
[0055] Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile (carte mémoire) ou un disque dur ou un SSD.
[0056] D'autre part, un tel support d'enregistrement 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, de sorte que le programme d'ordinateur qu'il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.
[0057] Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé précité.
[0058] Selon un exemple de réalisation, la présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
[0059] Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set- top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). Par la suite, on entend par ressources tous ensembles d'éléments matériels et/ou logiciels support d'une fonction ou d'un service, qu'ils soient unitaires ou combinés.
[0060] De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (« firmware » en anglais), etc.
[0061] Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.
[0062] Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de la présente technique.
Brève description des dessins
[0063] D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
[0064] [Fig. 1] : illustre de façon schématique un exemple d'architecture d'un système de gestion d'une requête d'exécution d'un service dans un réseau de communication selon un mode de réalisation de l'invention ;
[0065] [Fig. 2] : Idécrit sous forme d'un logigramme les étapes d'un procédé de traitement d'une telle requête d'exécution d'un service, selon l'invention ;
[0066] [Fig. 3A] : décrit sous forme d'un logigramme les étapes d'un procédé de validation d'une telle requête d'exécution d'un service, selon un premier exemple de réalisation de l'invention ;
[0067] [Fig. 3B] : décrit sous forme d'un logigramme les étapes d'un procédé de validation d'une telle requête d'exécution d'un service, selon un deuxième exemple de réalisation de l'invention ;
[0068] [Fig. 3C] : décrit sous forme d'un logigramme les étapes d'un procédé de validation d'une telle requête d'exécution d'un service, selon un troisième exemple de réalisation de l'invention ;
[0069] [Fig. 4] [Fig. 5] [Fig. 6] [Fig. 7] [Fig. 8] [Fig. 9] : illustrent de façon schématique les messages échangés entre les différentes entités du système de gestion d'une requête d'exécution d'un service selon un premier exemple de réalisation de l'invention ;
[0070] [Fig. 10] [Fig. 11] [Fig. 12] : illustrent de façon schématique les messages échangés entre différentes entités du système de gestion d'une requête d'exécution d'un service selon un deuxième exemple de réalisation de l'invention ;
[0071] [Fig. 13] : illustre de façon schématique un exemple de structure matérielle d'une entité intermédiaire configurée pour traiter une requête d'exécution d'un service selon un mode de réalisation de l'invention ; et
[0072] [Fig. 14] : illustre de façon schématique un exemple de structure matérielle d'une entité de validation d'une requête d'exécution d'un service selon un mode de réalisation de l'invention.
Description de l'invention
[0073] Le principe général de l'invention consiste à séparer, dans un réseau de communication, la validation des requêtes d'exécution d'un service en provenance d'une entité consommatrice du service, de l'exécution proprement dite de ce service et en même temps de centraliser le traitement de telles requêtes au niveau d'une entité intermédiaire. Cette entité intermédiaire est avantageusement placée en frontal de l'entité consommatrice du service et des requêtes qu'elle envoie, par rapport aux entités de validation et d'exécution du service concerné. Autrement dit, cette entité intermédiaire est la première entité qui reçoit la requête d'une entité consommatrice, c'est-à-dire qui est visible de cette entité consommatrice. Elle est ainsi placée en coupure des flux de requêtes adressées des entités consommatrices à l'entité d'exécution. De ce fait, elle masque les entités de validation et d'exécution aux entités consommatrices du service.
[0074] Plus précisément, l'invention propose de confier les tâches de validation d'une requête d'exécution d'un service et d'exécution de cette requête à deux entités distinctes du réseau placées sous la responsabilité d'une même entité intermédiaire qui les pilote. Ces deux entités sont par exemple deux entités logicielles qui peuvent, de ce fait, avoir été conçues dans des environnements de conception distincts et en utilisant des langages de programmation différents. Selon l'invention, ces deux entités ont des localisations distinctes (typiquement sont représentées par deux fichiers exécutables distincts) et chacune dispose de son propre identifiant, par exemple de type U RI (en anglais, « Universal Resource Identifier »), qui permet à une autre entité du réseau de l'atteindre, et de communiquer avec elle.
[0075] L'invention permet ainsi de rendre le réseau de communication plus modulaire, et de ce fait, de rationaliser les efforts de conception et donc les investissements nécessaires pour mettre en œuvre une validation efficace des requêtes d'exécution de services dans un réseau de communication. En effet, puisque la tâche de validation d'une requête d'exécution d'un service est dissociée de l'exécution du service proprement dit, la contrainte de s'adapter à l'environnement logiciel de l'entité d'exécution du service est relâchée et un constructeur de solutions de validation peut choisir l'environnement de conception le plus adapté.
[0076] L'invention permet aussi de contrôler le traitement de ces requêtes et leur validation préalable par cette entité intermédiaire, qui a de la visibilité sur les flux de requêtes, reçoit des informations représentatives d'un état de fonctionnement du réseau et d'un niveau de qualité des requêtes d'exécution de service reçues et peut décider en conséquence de déclencher ou non la validation d'une nouvelle requête en fonction de ces informations. Un avantage est de limiter une latence et une consommation de ressources induites par la validation d'opérations tout en garantissant un taux de conformité acceptable des requêtes d'exécution effectivement par l'entité d'exécution du service. De la sorte, l'invention contribue à améliorer la gestion de la charge et plus généralement la qualité de service au sein de ce réseau.
[0077] L'invention concerne tout type de réseau mettant en œuvre une architecture orientée service (demandeur de services/fournisseur de services) basée sur des dispositifs applicatifs. Dans la suite de la description, on considère en particulier le cas de fonctions réseaux NF configurées pour réaliser une ou plusieurs tâches ou services et échanger des informations les uns vers les autres à travers une interface de service SBI (Service Based Interface). Toutefois, l'invention s'applique également à d'autres types de dispositifs applicatifs tels que par exemple des dispositifs applicatifs de type services web. [0078] Dans une architecture orientée services, virtualisée et distribuée, l'allocation de ressources physiques pour l'implémentation de ces fonctions réseau est supervisée par un équipement orchestrate ur.
[0079] Les services sont exposés par exemple en utilisant des protocoles standards pour représenter de façon sérialisée (i.e. sous forme d'une chaîne) leurs données (SOAP, Thrift, JSON) permettant d'imposer le format des messages échangés.
[0080] Chaque dispositif applicatif intègre par exemple une composante logicielle conçue pour réaliser une tâche ou des tâches précises comme récupérer des informations (exemple : l'identité d'un terminal mobile lors de son attachement) ou exécuter une opération (exemple : mettre en œuvre un tunnel). A titre d'exemple, une fonction réseau contient le code logiciel et les données nécessaires pour réaliser la liste des tâches ou services associées à cette fonction.
[0081] L'accès à de tels services se fait par l'intermédiaire d'interfaces de programmation applicative ou API (en anglais, « Applicative Programming Interface »), par exemple de type API REST (pour « RE- presentational State Transfer », en anglais), configurées pour exécuter un service ou une opération d'un service en réponse à des requêtes en provenance d'entités consommatrices dont le concepteur souhaite contrôler la validité.
[0082]
[0083] Un exemple de réseau auquel l'invention est particulièrement adaptée est un réseau cœur 5G, tel que spécifié par la norme 3GPP.
[0084] Dans le cas de la norme 5G, le format des données est le format JSON et le protocole d'échange est le protocole HTTP/2. Chaque service récupère, crée, modifie ou supprime une ressource. L'écriture se fait en utilisant les commandes POST ou PUT ou encore DELETE, et la lecture en utilisant la commande GET.
[0085] Bien entendu, l'invention s'applique à d'autres formats de données, à d'autres protocoles (par exemple au protocole HTTP/3), ainsi que dans d'autres contextes (par exemple un réseau cœur 6G). [0086] La figure 1 illustre de façon schématique un exemple d'architecture d'un système S de gestion d'une requête d'exécution d'un service dans un réseau de communication RC, par exemple un réseau cœur mobile 5G tel que spécifié par le 3GPP.
[0087] Le réseau RC comprend une entité ECS de consommation d'un service fourni par le réseau RC. Il s'agit d'un élément matériel et/ou logiciel du réseau RC, configuré pour exécuter une ou plusieurs tâches dans le réseau RC et qui, pour ce faire, fait appel à ce service. Par simplicité, sur la figure 1, on a représenté une seule entité ECS, mais on comprend que le réseau RC peut en comprendre plusieurs. Il s'agit par exemple d'une fonction réseau NF particulière qui requiert l'exécution d'un service d'une entité EES de production ou d'exécution de ce service, par exemple une autre fonction NF de ce réseau. On comprend aussi qu'une fonction réseau peut être à la fois productrice d'un service pour une autre fonction réseau et consommatrice à son tour d'un service rendu par cette autre fonction réseau.
[0088] Le réseau RC comprend en outre une entité de validation EVS d'une requête d'exécution du service rendu par l'entité d'exécution EES. Selon l'invention, il s'agit d'une entité distincte de l'entité d'exécution EES. Elle est configurée pour valider notamment un format (par exemple un nom et/ou une valeur) des données spécifiées dans la requête d'exécution. Ces données comprennent des attributs et des paramètres inclus dans le corps de la requête et/ou dans un ou plusieurs en-têtes de cette requête (par exemple, l'identifiant unique ou URI).
[0089] Selon ce mode de réalisation de l'invention, le système S comprend donc l'entité consommatrice d'un service ECS, l'entité d'exécution du service EES et l'entité de validation EVS de la requête d'exécution du service émise par l'entité consommatrice ECS. Le système S comprend en outre une entité intermédiaire du réseau de communication RC, placée en frontal de l'entité consommatrice du service ECS par rapport à l'entité d'exécution EES du service. Il s'agit par exemple d'un équipement proxy, qui est configuré pour recevoir des messages en provenance et/ou destinés à l'entité d'exécution du service EES et joue un rôle de passerelle entre l'entité consommatrice du service et l'entité d'exécution de ce service, en transformant un identifiant public de ce service connu de l'entité consommatrice du service et indiqué dans sa requête en un autre identifiant de l'entité d'exécution du service, non connu de l'entité consommatrice du service.
[0090] Selon l'invention, l'entité intermédiaire est configurée pour recevoir ladite requête d'exécution du service en provenance de l'entité consommatrice du service, décider de transmettre ou non la requête d'exécution du service vers une entité de validation EVS de ladite requête, distincte de l'entité d'exécution du service EES, pour validation, avant transmission (27) de ladite requête à l'entité d'exécution du service EES. [0091] Ladite entité intermédiaire met ainsi en œuvre le procédé de traitement d'une requête d'exécution d'un service selon l'invention qui sera détaillé ci-après en relation avec la figure 2.
[0092] Par exemple, l'entité d'exécution du service EES est comprise dans un sous-réseau ou réseau privé (non représenté) de ce réseau RC, par exemple celui d'une fonction réseau NF en charge de l'exécution de ce service. L'entité intermédiaire peut faire partie ou non du réseau privé et sert donc à masquer les différentes entités qui appartiennent au réseau privé aux autres entités du réseau RC. A l'inverse, les entités de ce réseau privé ne communiquent avec le reste du réseau RC que via cette entité intermédiaire. Ainsi, l'entité consommatrice du service ECS envoie sa requête REQ à un identifiant (par exemple une URI) associé à l'entité d'exécution du service EES dans le réseau RC ou à la fonction réseau qui met en œuvre ce service et qu'elle peut ou non avoir préalablement découverte, et l'entité intermédiaire, qui reçoit cette requête REQ, la transmet alors vers un identifiant privé de cette entité d'exécution du service ou d'une autre entité dans le réseau privé auquel elle appartient. Selon un premier mode de réalisation de l'invention, l'entité intermédiaire est un équipement proxy dit inversé (en anglais, « Reverse Proxy ») du fait qu'il remplace un identifiant « public » en identifiant privé, contrairement aux équipements intermédiaires classiques. Dans le cas d'un réseau cœur 5G, cet équipement proxy traite des requêtes conformes au protocole HTTP2. Selon un autre mode de réalisation de l'invention, l'entité intermédiaire est de type SCP (en anglais, « Service Communication Proxy »). Il s'agit d'un autre type d'équipement proxy, défini notamment dans la version 16 (ou « Release 16 » en anglais) du 3GPP, constituant un point d'entrée unique pour un groupe de fonctions réseaux NF. Il est donc externe à ces fonctions réseau. Il traite lui aussi des requêtes conformes au protocole HTTP2. On note que dans ce cas, l'identifiant utilisé par cet équipement proxy SCP est une adresse routable, donc publique.
[0093] Selon l'exemple de réalisation de la figure 1, le système S de gestion d'une requête d'exécution d'un service comprend en outre l'entité de validation EVS configurée pour recevoir ladite requête d'exécution du service en provenance de l'entité intermédiaire RP, SCP, vérifier une validité de ladite requête d'exécution du service, comprenant l'obtention d'un résultat de validation, et exécuter au moins une action de traitement de la requête en fonction du résultat de validation obtenu.
[0094] L'entité de validation EVS met ainsi en œuvre le procédé de validation d'une requête de validation selon l'invention qui sera détaillé ci-après en relation avec les figures 3A à 3C.
[0095] On présente désormais, en relation avec la figure 2, sous une forme de logigramme, un exemple de mise en œuvre d'un procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication RC selon un mode de réalisation de l'invention. Avantageusement, le procédé est mis en œuvre par l'entité intermédiaire RP, SCP.
[0096] En 20, une requête d'exécution d'un service Si est reçue en provenance d'une entité consommatrice ECS, par exemple une première fonction réseau du réseau RC. On note que, suite à l'émission de cette requête, l'entité consommatrice ECS enclenche généralement un compteur (en anglais, « timer ») et qu'en l'absence de réponse reçue à l'expiration d'une période donnée, elle peut éventuellement retransmettre la requête.
[0097] Cette requête indique l'identifiant public du service demandé par l'entité consommatrice du service, qui correspond par exemple à celui de la fonction réseau NF ou du dispositif applicatif qui fournit le service demandé. Cet identifiant unique ou URI est défini dans un profil de la fonction réseau ou du dispositif applicatif, lequel est enregistré dans le réseau, par exemple par une fonction réseau dédiée à l'enregistrement de tels profils.
[0098] En 21 au moins un indicateur de fonctionnement IND est obtenu, par exemple d'une mémoire Ml de l'entité intermédiaire RP, SCP. Il s'agit par exemple d'un indicateur de charge ou de trafic, de latence, d'occupation (saturation) des ressources physiques du réseau sur une période temporelle donnée du réseau RC et/ ou d'un indicateur de qualité des requêtes précédemment traitées pendant une période temporelle écoulée, d'un taux de requêtes non validées par l'entité de validation pendant la période temporelle donnée, d'un taux de messages d'erreurs générés par l'entité d'exécution du service pour des requêtes n'ayant pas fait l'objet d'une validation préalable, etc. Ces indicateurs sont par exemple déterminés à partir de données de mesure collectées dans le réseau par télémétrie.
[0099] En 22, ce ou ces indicateurs sont exploités pour décider si la requête REQ reçue est soumise à validation préalable ou directement transmise à l'entité d'exécution EES concernée. Avantageusement un identifiant (par exemple URI) d'une entité EVS en charge de la validation des requêtes d'exécution de ce service est obtenu, comme détaillé ci-après. Au moins un critère de décision CRT est pris en compte. Il s'agit par exemple d'un seuil de valeur du dit au moins un indicateur.
[0100] Selon un premier cas, la décision est prise de transmettre la requête REQ à l'entité de validation EVS en charge pour le service Si demandé. Elle est transmise en 23. Pour ce faire, un identifiant URI2 de l'entité de validation EVS a été préalablement obtenu, par exemple, à l'aide de règles de configuration associant à chaque service rendu par le réseau RC, ou une fonction réseau NF ou encore un groupe de fonctions réseaux du réseau RC, l'identifiant de l'entité de validation EVS correspondante. En variante, ces règles de configuration sont regroupées dans une table de données, accessible depuis l'entité intermédiaire RP, SCP. Par exemple, ces informations ont été obtenues lors d'une phase de découverte préalable des fonctions de service disponibles dans le réseau RC et des services qu'elles fournissent.
[0101] Les opérations de validation conduites par l'entité de validation EVS sur la requête REQ sont détaillées ultérieurement.
[0102] Selon un premier mode de réalisation de l'invention, un message de réponse REP est reçu en 24. Il comprend un message d'information de validation de l'entité de validation EVS et comprend donc un résultat RES de validation qui peut être positif ou négatif. En fonction du résultat de validation, il est décidé en 25 de transmettre la requête REQ en Tl à l'entité d'exécution du service EES lorsque ce résultat de validation est positif et au contraire de rejeter la requête REQ sinon.
[0103] Avantageusement, lorsque le résultat de validation RES est positif, le message de réponse comprend au moins une information de localisation de l'entité d'exécution EES du service demandé, par exemple une réponse conforme au protocole HTTP de code de statut de la classe « 3xx » indiquant une redirection, et plus précisément du type « 307 Location : URI3 ». Une telle réponse comprend par exemple un identifiant privé de la fonction réseau ou du dispositif applicatif qui met en œuvre le service et éventuellement complétée par un identifiant de l'entité de validation EVS concernée, lorsque l'entité intermédiaire se trouve à l'intérieur de cette fonction réseau.
[0104] Au contraire, en cas de rejet de la requête REQ pour défaut de conformité (par exemple format du corps de la requête non conforme, nom d'un attribut non conforme, type d'un attribut non conforme, valeur d'un attribut non conforme, contrainte multi-attributs non conforme, etc.), la réponse REP comprend un corps et un code de statut. Dans le mode de réalisation envisagé ici, il s'agit d'une réponse conforme au protocole HTTP et la valeur du code de statut est de la classe « 4xx ». Le corps et le code de statut sont conformes à des spécifications du 3GPP qui sont énoncées dans un ou plusieurs documents OpenAPI décrivant les opérations du service.
[0105] En cas de rejet, le message de réponse REP est transmis à l'entité consommatrice du service ECS, qui est donc informée que sa requête est rejetée car elle n'est pas valide.
[0106] En cas de résultat positif, un message de réponse REP' comprenant un rapport d'exécution du service est reçu en 28 de l'entité d'exécution EES et transmis à l'entité consommatrice du service ECS en 29.
[0107] On comprend que selon ce premier mode de réalisation, l'entité intermédiaire RP, SCP est destinataire de tous les messages émis par l'entité de validation EVS et l'entité d'exécution EES qui ne communiquent pas directement. Il reçoit donc potentiellement deux messages de réponse, à savoir le message de réponse REP comprenant le résultat de validation RES transmis par l'entité de validation EVS, et en cas de résultat de validation positif, le message de réponse REP' comprenant le rapport d'exécution du service par l'entité d'exécution EES.
[0108] Selon un deuxième mode de réalisation de l'invention, un seul message de réponse est reçu par l'entité intermédiaire RP, SCP. Dans le cas où l'entité de validation EVS a validé la requête, seul le message de réponse REP' est reçu en 28, car l'entité de validation EVS transmettant directement la requête REQ à l'entité d'exécution du service EES dans ce deuxième mode de réalisation. Au contraire, lorsque l'entité de validation EVS a rejeté la requête, un message d'information de validation REP comprenant un résultat négatif est reçu par l'entité intermédiaire RP, SCP en 24. Le message d'information de validation REP comprenant le résultat négatif, respectivement le message de réponse REP', est transmis le cas échéant par l'entité intermédiaire RP, SCP à l'entité ECS en 29, respectivement 26.
[0109] Selon un deuxième cas, il est décidé de ne pas transmettre la requête REQ à l'entité de validation EVS. Elle est donc transmise directement à l'entité d'exécution EES en 27. Les étapes 28 et 29 sont identiques à celles déjà décrites.
[0110] On comprend que, selon l'invention, une requête REQ n'est pas forcément soumise à validation ce qui permet de limiter le temps de latence introduit par la mise en œuvre de l'invention. Dans ce cas, un message d'erreur peut être émis par l'entité d'exécution EES, lorsque la requête REQ présente des non-conformités rendant impossible l'exécution du service ou de l'opération demandée. Dans le mode de réalisation décrit ici, ce message d'erreur peut indiquer un code de statut HTTP dans la classe 5xx ou un code de statut 404 Not Found.
[0111] On présente désormais, en relation avec les figures 3A à 3C, sous forme de logigramme, des exemples de mise en œuvre d'un procédé de validation d'une requête d'exécution d'un service dans un réseau de communication selon plusieurs modes de réalisation de l'invention. Avantageusement, le procédé est mis en œuvre par l'entité de validation EVS.
[0112] En relation avec la figure 3A, une requête d'exécution d'un service REQ est reçue en 30 par l'entité de validation EVS en provenance de l'entité intermédiaire RP, SCP. En 31, les champs d'information composant cette requête REQ sont vérifiés. En particulier, dans le cas d'un réseau cœur 5G, la vérification concerne le corps de la requête (en anglais, « request body ») et d'éventuels paramètres et entêtes associés. Nativement, l'entité de validation EVS a par exemple été conçue à partir d'un document de description de l'interface de programmation API du service de l'entité d'exécution du service considérée, par exemple au format OpenAPI, qui décrit tous les champs d'information du corps de la requête, ainsi que d'éventuels paramètres et en-têtes associés. On note que ce format OpenAPI décrit aussi la structure des messages de réponse.
[0113] L'entité de validation EVS vérifie ainsi que le corps de la requête et les éventuels paramètres et entêtes associés sont conformes à ceux définis dans le document de description de l'interface de programmation du service. A l'issue de cette vérification, l'entité de validation EVS fournit un résultat RES (positif en cas de conformité de l'ensemble des éléments de la requête REQ qui ont été vérifiés par l'entité de validation EVS, négatif en cas de non-conformité de l'un au moins de ces éléments), qui est pris en compte en 32 pour décider d'une action ACT à déclencher.
[0114] A ce stade, deux cas sont possibles : selon un premier mode de réalisation de l'invention illustré par la figure 3B, l'action décidée est l'envoi en 321 d'une réponse REP à l'entité intermédiaire RP, SCP. Lorsque la requête REQ a été validée, ce message de réponse REP est un message d'information de validation comprenant un résultat RES positif. Optionnellement, il comprend une information d'identifi- cation/localisation de l'entité d'exécution du service EES dans le réseau RC et par exemple dans le réseau privé de la fonction réseau à laquelle elle appartient. Par exemple, ladite information d'identification/lo- calisation est un identifiant universel de type URI (URI3) qui n'est pas connu de l'entité consommatrice du service ECS.
[0115] Au contraire, lorsque la requête REQ est rejetée (i.e. n'est pas validée), le message de réponse REP comprend, dans le corps du message, un code d'erreur ; il peut en outre comprendre une description des erreurs (autrement dit des non-conformités) identifiées. Par exemple, le code de statut est de type HTTP 400, qui signifie « mauvaise requête » (en anglais, « Bad Request »). On note que le corps du message de réponse d'erreur est conforme à la description OpenAPI pour toute opération de service considérée.
[0116] Selon un deuxième mode de réalisation de l'invention, illustré par la figure 3C, lorsque la requête REQ est validée, l'action ACT décidée est de transmettre directement la requête d'exécution de service REQ en 322 vers l'entité d'exécution EES (en utilisant l'identifiant URI3). Selon ce deuxième mode de réalisation, un message de réponse REP' comprenant un rapport d'exécution émis par l'entité d'exécution EES est reçu en 323 et transmis en 324 à l'entité intermédiaire RP, SCP. On comprend que selon ce deuxième mode de réalisation, l'entité de validation EVS joue un rôle d'intermédiaire entre l'entité intermédiaire RP, SCP et l'entité d'exécution du service ECS. En variante, l'entité de validation EVS est intégrée dans l'entité intermédiaire RP, SCP.
[0117] On détaille maintenant, en relation avec les figures 4 à 12 des exemples de réalisation de l'invention dans le cas d'un réseau cœur 5G.
[0118] Comme précédemment évoqué, un réseau cœur 5G tel que spécifié par le 3GPP est composé de différentes fonctions réseau NF, chacune ayant un rôle bien défini. Une fonction réseau NF est généralement en charge d'exécuter plusieurs services distincts. Un service d'une fonction réseau est décrit par le 3GPP sous la forme d'une ou plusieurs interfaces de programmation applicative API, elles- mêmes spécifiées dans un document de description conforme au format OpenAPI. Un objectif d'une API est notamment de définir le contenu des requêtes d'exécution d'un service envoyées par une entité consommatrice du service et le contenu des réponses envoyées par l'entité d'exécution ou de production du service.
[0119] Par exemple, il s'agit d'une API de type API REST, c'est-à-dire conforme à un ensemble de contraintes architecturales définies par REST. On note que les API de type API REST sont très communes aujourd'hui dans l'informatique en nuage (en anglais, « cloud computing ») qui consiste à recourir à des serveurs distants pour traiter, stocker et gérer des données, et s'appliquent à tout domaine métier. L'invention concerne plus généralement toute interface de programmation applicative, par exemple de type API REST, conçue pour exécuter un service en réponse à des requêtes en provenance d'entités consommatrices dont le concepteur souhaite contrôler la validité.
[0120] [0121] On considère à titre d'exemple, la fonction réseau NRF (de l'anglais, « Network function Repository Function » ) d'enregistrement de fonctions réseau NF, dont le rôle est de fournir un annuaire à jour de l'état des fonctions réseau NF d'un réseau cœur 5G et de leurs données définies dans un profil (en anglais, « NFProfile »). Ce profil comprend notamment un identifiant (URI) permettant de localiser chaque fonction réseau NF dans le réseau cœur 5G. Cet identifiant pointe généralement sur une adresse logique.
[0122] Cet annuaire est mis à jour au moment de l'instanciation de chaque fonction NF (enregistrement) et lorsqu'une fonction NF voit ses caractéristiques modifiées, par exemple lorsqu'elle est redimensionnée. La fonction réseau NRF propose ainsi un service de découverte de fonctions NF. Elle met pour cela en œuvre un service appelé « Nnrf_NFManagement » de gestion des profils et des souscriptions de fonctions réseau NF. Les opérations proposées pour gérer un profil de fonction réseau NF comprennent l'enregistrement, la mise à jour, la suppression et la consultation.
[0123] Par exemple, la requête pour l'exécution d'une opération d'enregistrement d'un profil de fonction NF est PUT/nf-instances/{nflnstancelD}. Elle comporte un corps de requête de type NFProfile. La description OpenAPI de la requête de cette opération est la suivante: put: summary: Register a new NF Instance operationld: RegisterNFInstance tags:
- N F Instance ID (Document) parameters:
- name: nflnstancelD in: path reguired: true description: Unigue ID of the N F Instance to register schema:
$ref: 'TS29571_CommonData.yaml#/components/schemas/Nflnstanceld'
- name: Content-Encoding in: header description: Content-Encoding, described in IETF RFC 7231 schema: type: string
- name: Accept-Encoding in: header description: Accept-Encoding, described in IETF RFC 7231 schema: type: string reguestBody: content: application/json: schema:
$ref: 'ff/components/schemas/NFProfile' reguired: true [0124] Cet exemple ne comporte pas de paramètre de requête (en anglais, « query parameter »), mais il comprend un paramètre dans l'URI (en anglais, « path parameter ») spécifié par {nflnstancelD}. On note qu'en règle générale, les requêtes de types POST, PUT, DELETE ne comportent pas de paramètres de requête, contrairement aux requêtes GET.
[0125] En relation avec les figures 4 à 9, on considère une fonction réseau NFx du réseau RC, configurée pour rendre N services, avec N entier supérieur ou égal à 1, et comprenant une entité intermédiaire RP de type proxy inversé et des entités d'exécution EES et de validation EVS de N services. Selon ces exemples de réalisation de l'invention, cette entité intermédiaire RP est configurée pour mettre en œuvre le procédé de traitement d'une requête d'exécution d'un service, tel que précédemment décrit. Sur les figures 4 à 9, on n'a, par simplicité, représenté que les entités EVS et EES relatives à un service Si donné, avec i entier compris entre 1 et N. On a représenté un deuxième rectangle derrière chaque rectangle EVS et EES pour figurer que plusieurs instances de ces entités EVS et EES ont pu être allouées par un orchestrateur du réseau RC, en fonction des besoins, comme précédemment évoqué.
[0126] En relation avec les figures 4 à 7, on décrit maintenant des exemples de mise en œuvre du premier mode de réalisation de l'invention, selon lequel le proxy inversé RP sert d'intermédiaire à tous les échanges de messages, non seulement entre l'entité consommatrice du service ECS et la fonction réseau NFx, mais aussi entre les entités de validation EVS et d'exécution EES du service Si.
[0127] Sur la figure 4, une requête REQ est reçue par le proxy inversé RP de la fonction réseau NFx en provenance d'une entité consommatrice ECS du réseau, par exemple une autre fonction réseau du réseau RC. Cette requête identifie le service Si en spécifiant un identifiant unique de ce service Si dans le réseau RC, par exemple l'URI U RI 1. Cet identifiant URI1 a par exemple été obtenu par l'entité consommatrice ECS auprès du service Nnrf_NFmanagement de gestion des profils de la fonction réseau NRF précédemment évoquée.
[0128] La requête REQ est ensuite transmise à l'entité de validation EVS. Pour ce faire, l'identifiant « public» URI1 a été remplacé par le proxy inversé RP par un identifiant privé de type URI, URI2, associé à l'entité de validation EVS, qui est interne à la fonction réseau NFx, et donc n'est pas connu en dehors de la fonction réseau NFx. A réception de la requête REQ, l'entité de validation EVS vérifie qu'elle est conforme au document de spécification de l'API du service Si demandé. Dans l'exemple de la figure 4, la requête REQ est validée. L'entité de validation EVS retourne une réponse REP au proxy inversé RP lui indiquant, dans un en-tête dédié, par exemple l'en-tête de localisation « location », l'identifiant privé URI3 de l'entité d'exécution EES du service Si. Cette réponse REP comprend un code de statut, qui correspond ici, dans le cas d'une requête validée, au code HTTP de redirection 307. Il s'agit d'une réponse HTTP standard de type redirection (avec un code de statut HTTP de la classe 3xx). On note que l'entité qui sert une réponse de ce type indique l'URL de Redirection dans l'en-tête de localisation.
[0129] Le proxy inversé RP transmet la requête REQ à l'entité d'exécution EES en utilisant l'identifiant URI3. Il reçoit une réponse REP' comprenant un rapport d'exécution qu'il transmet alors à l'entité consommatrice du service ECS.
[0130] En relation avec la figure 5, on décrit maintenant, le cas d'une requête REQ non validée par l'entité de validation EVS. Le message de réponse REP adressé par l'entité de validation EVS au proxy inversé RP comprend un code d'erreur, à savoir dans le mode de réalisation décrit ici, un code d'erreur HTTP de la classe « 4xx ». A réception, le proxy inversé RP le transmet à l'entité consommatrice du service ECS.
[0131] En relation avec la figure 6, on décrit maintenant un exemple selon lequel le proxy inversé RP a reçu la requête REQ, mais a décidé de ne pas la soumettre à la validation de l'entité EVS, sur la base d'un ou plusieurs indicateurs de fonctionnement représentatifs par exemple d'un état du réseau RC, ou de la charge de la fonction NFx ou encore d'un taux de rejet des requêtes précédemment traitées pour le service Si demandé, etc. La requête REQ est donc transmise directement à l'entité d'exécution de service EES, dont l'identifiant privé URI3 de la fonction réseau NFx est obtenu par d'autres moyens, par exemple basés sur des règles de configuration. Cette requête est traitée par l'entité d'exécution de service EES qui renvoie une réponse REP' comprenant un résultat d'exécution au proxy inversé RP. Elle est reçue par le proxy inversé RP qui la transmet à l'entité consommatrice de service ECS.
[0132] On décrit maintenant des exemples de mises en œuvre du deuxième mode de réalisation de l'invention en relation avec les figures 7 à 9. Comme pour les figures 4 à 6, le procédé de traitement d'une requête d'exécution d'un service est mis en œuvre par une entité intermédiaire, par exemple de type proxy inversé RP, qui fait partie de la fonction réseau NFx.
[0133] En relation avec la figure 7, à réception de la requête REQ, le proxy inversé RP la transmet à l'entité de validation EVS comme précédemment décrit. L'entité de validation EVS la vérifie mais ne la valide pas. Elle émet donc une réponse REP à destination du proxy inversé RP comprenant un message d'erreur MERR. Dans le mode de réalisation décrit ici, ce message d'erreur utilise le code de statut HTTP de la classe « 4xx ». L'entité intermédiaire le reçoit et le transmet à l'entité consommatrice ECS comme précédemment décrit.
[0134] En relation avec la figure 8, on considère maintenant le cas où la requête REQ a été validée par l'entité EVS. Selon ce deuxième mode de réalisation, l'entité EVS transmet directement la requête REQ à l'entité d'exécution EES du service Si demandé, en utilisant son identifiant privé URI3. Elle reçoit une réponse REP' de l'entité d'exécution EES, qu'elle transmet au proxy inversé RP. A réception, l'entité intermédiaire RP transmet la réponse à l'entité consommatrice de service ECS.
[0135] En relation avec la figure 9, la requête REQ est reçue par l'entité intermédiaire RP qui décide sur la base d'au moins un critère de décision basé sur au moins un indicateur de fonctionnement, de ne pas la soumettre à la validation de l'entité de validation EVS. Il obtient l'identifiant URI4 de l'entité d'exécution du service EES via des règles de configuration et lui transmet donc directement la requête REQ. L'entité d'exécution du service EES exécute le service et lui renvoie une réponse REP' comprenant un résultat de cette exécution.
[0136] En relation avec les figures 10 à 12, on décrit maintenant des exemples de réalisation selon lesquels l'entité de validation EVS et l'entité intermédiaire sont externes à la fonction de réseau NFx qui met en œuvre le service Si demandé par l'entité consommatrice du service ECS et l'entité de validation EVS. Par exemple, l'entité intermédiaire est un équipement SCP tel que précédemment décrit. Dans le cas de fonctions NF multi-distribuées et dans certains modèles de déploiement, cet équipement SCP est configuré pour constituer un point d'entrée unique pour un groupe de fonctions réseau qui sont enregistrées dans la fonction NRF, dont la fonction NFx. Autrement dit, seul le SCP connaît la NFx productrice du service Si demandé.
[0137] Par exemple l'entité de validation EVS est comprise dans une autre fonction réseau (non représentée sur les figures 10 à 12), qui peut regrouper plusieurs entités de validation de services distincts. On note que dans ce qui suit, certaines étapes ne seront pas décrites en détail car elles sont réalisées de façon similaire aux exemples des figures 4 à 9.
[0138] En relation avec la figure 10, l'équipement SCP reçoit la requête REQ de l'entité consommatrice de service ECS. Cette requête REQ est adressée à l'identifiant public URI1 de l'équipement SCP et comprend un identifiant du service Si souhaité, par exemple le nom de l'API du service de la fonction réseau NFx qui met en œuvre le service Si (par exemple, « nsmf-pdusession/vl »). L'équipement SCP la transmet vers l'entité de validation EVS concernée en utilisant l'identifiant URI2 de cette entité EVS qu'elle a préalablement obtenu à partir de l'identifiant de la fonction réseau NFx et d'informations de profil de la fonction NFx obtenues auprès de la fonction réseau NRF. Il ne s'agit pas ici d'un identifiant privé, mais d'une adresse routable dans le réseau RC. L'entité EVS vérifie la requête REQ reçue et envoie à l'équipement SCP (URI1) un message de réponse REP de validation comprenant un résultat positif (par exemple avec un code de statut 307). Selon ce mode de réalisation, la réponse REP ne comprend pas d'identifiant privé URI3 permettant d'accéder à l'entité d'exécution EES du service Si demandé. Par exemple, l'équipement SCP obtient l'identifiant URI3 en question à partir de l'identifiant du service Si produit par la fonction réseau NFx et d'informations de profil de la fonction réseau qui rend le service Si, obtenues précédemment de la fonction réseau NRF. Il transmet la requête REQ à l'entité d'exécution EES à l'aide de l'identifiant URI3. Dans cet exemple, la requête REQ n'est pas reçue directement par l'entité d'exécution du service EES, mais par une entité intermédiaire comprise dans la fonction réseau NFx, par exemple un équipement proxy inversé RP tel que précédemment décrit et qui se charge de transmettre la requête REQ vers l'identifiant privé de l'entité EES à l'intérieur de la fonction réseau NFx. On comprend que dans ce cas, URI3 est l'identifiant de l'équipement proxy inversé RP de la fonction réseau NFx et que l'identifiant privé de l'entité EES n'est pas connu de l'extérieur de la fonction réseau NFx. A réception, l'entité EES exécute le service Si demandé et envoie un message de réponse REP' à l'équipement RP, qui le transmet vers l'entité intermédiaire SCP. A réception, l'équipement SCP le transmet à l'entité consommatrice du service ECS.
[0139] En relation avec la figure 11, un en-tête de la requête REQ reçue par l'équipement SCP est modifié par l'équipement SCP pour y insérer l'identifiant URI3 de la fonction réseau NFx (« 3gpp-Sbi-Tar- get-apiRoot » = URI3). On note que le SCP est configuré pour déterminer cet identifiant URI3 avant la validation effective de la requête REQ. Néanmoins, il convient de noter également que, selon la norme 3GPP actuelle, l'entité intermédiaire SCP n'est configurée que pour l'insérer ensuite dans un message de réponse et pas dans la requête elle-même comme proposé par la présente invention.
[0140] On suppose ici encore que l'entité de validation EVS valide la requête REQ. Sa réponse REP, par exemple une réponse HTTP standard de type redirection (avec un code de statut HTTP de la classe 3xx), comprend l'identifiant privé URI3 de la fonction réseau NFx précédemment reçu, ce qui permet à l'équipement SCP de transmettre directement la requête REQ vers cet identifiant URL La suite correspond à ce qui a été précédemment décrit en relation avec la figure 11. On note que l'utilisation de l'entête « 3gpp-Sbi-Target-apiRoot » de localisation qui vient d'être décrite est conforme aux spécifications de la norme 3GPP. Néanmoins, selon la version actuelle de cette norme, l'entité intermédiaire SCP est le seul récipiendaire de l'en-tête de localisation « 3gpp-Sbi-Target-apiRoot » contenu dans une requête et la seule entité/fonction du réseau cœur 5G configurée pour être placée en coupure d'une transaction client-serveur. L'entité intermédiaire SCP est configurée pour traiter cet en-tête et transmettre ensuite la requête à l'identifiant URI que cet en-tête porte. Cet en-tête permet de forcer le passage d'une requête par l'entité intermédiaire SCP.
[0141] La présente invention propose de définir une nouvelle entité/fonction EVS de validation des requêtes, de l'insérer en coupure des échanges clients/serveur et de la configurer pour qu'elle transmet les requêtes validées directement vers l'entité d'exécution du service EES. Pour ce faire, elle s'appuie sur cet en-tête de localisation. Il en résulte que la mise en œuvre de l'en-tête « 3gpp-Sbi-Target-apiRoot » faite à la fig.ll diffère strictement de ce qui est décrit dans le standard 3GPP aujourd'hui.
[0142] En relation avec la figure 12, on considère maintenant, comme dans l'exemple de la figure 12 qu'un entête de la requête REQ est modifié, par exemple l'entête 3gpp-Sbi-Target-apiRoot, par l'équipement SCP pour y insérer l'identifiant public URI3 de la fonction réseau NFx qui met en œuvre le service Si demandé. La différence est qu'une fois la requête REQ validée par l'entité EVS, cette dernière la transmet directement vers la fonction réseau NFx en utilisant l'identifiant URI3 qu'elle a récupéré de l'en-tête modifié. Comme précédemment décrit, elle est reçue par l'équipement proxy inversé RP qui la transmet vers l'identifiant de l'entité d'exécution EES, interne à la fonction réseau NFx. Une fois le service Si exécuté, une réponse REP' est retournée par l'entité EES au proxy inversé RP qui la transmet vers le SCP qu'il la transmet lui-même à l'entité consommatrice du service ECS. On comprend que ce mode de réalisation implique que l'entité de validation soit configurée pour traiter l'entête « 3gpp-Sbi-Target-api- Root », comme décrit dans la norme 3GPP pour l'entité intermédiaire SCP.
[0143] Selon encore un autre exemple de réalisation (non représenté), l'entité de validation EVS du service pourrait être intégrée directement dans le SCP.
[0144] On présente ensuite, en relation avec la figure 13, un exemple de structure matérielle d'une entité intermédiaire RP, SCP configurée pour traiter une requête d'exécution d'un service dans un réseau de communication, en provenance d'une entité, dite entité consommatrice du service, à destination une entité d'exécution dudit service dans ledit réseau, ladite entité intermédiaire étant configurée pour recevoir des messages en provenance et/ou destinés à l'entité d'exécution du service, et comprenant un module de transmission de la requête d'exécution vers une entité de validation de ladite requête, distincte de l'entité d'exécution du service, pour validation, et un module de transmission d'une réponse à ladite requête à l'entité consommatrice du service.
[0145] Avantageusement, l'entité intermédiaire RP, SCP comprend un module de réception d'un message de réponse de validation en provenance de l'entité de validation, ledit message comprenant le résultat de validation, et un module de prise de décision de transmettre ou non la requête d'exécution à l'entité d'exécution du service en fonction du résultat de validation reçu. Avantageusement, il comprend en outre un module de transmission de la requête d'exécution du service à l'entité d'exécution du service, ledit module étant configuré pour être mis en œuvre en réponse à un résultat de validation positif. [0146] Le terme « module » peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions. [0147] Plus généralement, une telle entité intermédiaire RP, SCP comprend une mémoire vive 103 (par exemple une mémoire RAM), une unité de traitement 102 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pgl, représentatif des modules précités, stocké dans une mémoire morte 101 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 103 avant d'être exécutées par le processeur de l'unité de traitement 102. La mémoire vive 103 peut aussi contenir par exemple des informations relatives à l'entité de validation du service et/ou à l'entité d'exécution du service, comme par exemple des identifiants, permettant d'accéder à cette ou ces entités, par exemple obtenus lors d'une phase préalable de découverte. Elle peut comprendre en outre un ou plusieurs critères de décision relatifs au déclenchement de la transmission de la requête d'exécution du service EVS reçue à l'entité de validation de service. [0148] La figure 13 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser l'entité intermédiaire RP, SCP afin qu'elle effectue les étapes du procédé de traitement d'une requête d'exécution d'un service tel que détaillé ci-dessus, en relation avec les figures 2 et 3, dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
[0149] Dans le cas où l'entité intermédiaire RP, SCP est réalisée avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
[0150] Les différents modes de réalisation ont été décrits ci-avant en relation avec une entité intermédiaire de type équipement réseau de type proxy inversé ou équipement SCP.
[0151] On présente enfin, en relation avec la figure 14, un exemple de structure matérielle d'une entité de validation EVS d'une requête d'exécution d'un service dans un réseau de communication, ladite requête ayant été émise par une entité consommatrice du service à destination d'une entité d'exécution du service, comprenant un module de réception de ladite requête d'exécution en provenance d'une entité intermédiaire RP, SCP configurée pour traiter ladite requête d'exécution, ladite entité de validation étant configurée pour recevoir des messages en provenance de et/ou destinés à l'entité d'exécution du service de l'entité d'exécution, un module de vérification d'une validité de ladite requête, comprenant l'obtention d'un résultat de validation et un module de déclenchement d'une action de traitement de la requête en fonction du résultat de validation obtenu.
[0152] Le terme « module » peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.
[0153] Plus généralement, une telle entité de validation EVS comprend une mémoire vive 203 (par exemple une mémoire RAM), une unité de traitement 202 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg2, représentatif des modules précités, stocké dans une mémoire morte 201 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 203 avant d'être exécutées par le processeur de l'unité de traitement 202. La mémoire vive 203 peut aussi contenir par exemple des informations d'identification de l'entité d'exécution du service demandé et/ou de l'entité intermédiaire RP, SCP.
[0154] La figure 14 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser l'entité de validation EVS afin qu'elle effectue les étapes du procédé de validation d'une requête d'exécution d'un service tel que détaillé ci-dessus, en relation avec les figures 4 à 12, dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
[0155] Dans le cas où l'entité de validation EVS est réalisée avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD- ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
[0156] Les modes de réalisation qui viennent d'être décrits peuvent être combinés entre eux.

Claims

Revendications
[Revendication 1] Procédé de traitement d'une requête d'exécution d'un service (REQ.) dans un réseau de communication (RC), en provenance d'une entité dite consommatrice du service (ECS), à destination d'une entité d'exécution dudit service (EES), caractérisé en ce que ledit procédé est mis en œuvre au niveau d'une entité intermédiaire (RP, SCP) configurée pour recevoir des messages en provenance de l'entité consommatrice du service et destinés à l'entité d'exécution du service (EES) ou en provenance de l'entité d'exécution du service et destinés à l'entité consommatrice du service, et comprend :
- la réception (20) de ladite requête d'exécution du service (REQ.) en provenance de l'entité consommatrice du service (ECS) ;
- la prise de décision (22) de transmettre (23) ou non pour validation la requête d'exécution du service (REQ) vers une entité de validation (EVS) de ladite requête, distincte de l'entité d'exécution du service (EES), avant transmission (27) de ladite requête à l'entité d'exécution du service (EES).
[Revendication 2] Procédé de traitement selon la revendication 1, caractérisé en ce qu'il comprend :
- la transmission (27) de ladite requête d'exécution du service (REQ) à l'entité de validation du service (EVS) ;
- la réception (24,28) d'au moins un message de réponse (REP, REP') parmi un message (REP) d'information de validation et un message (REP') de rapport d'exécution ; et
- la transmission (26, 29) du message de réponse reçu à l'entité concernée parmi l'entité consommatrice du service (ECS) et l'entité d'exécution du service (EES), en fonction du message de réponse reçu.
[Revendication 3] Procédé de traitement selon la revendication 2, caractérisé en ce que le au moins un message de réponse reçu comprend un message d'information de validation (REP) de l'entité de validation (EVS) comprenant un résultat de validation, en ce que le message d'information de validation est transmis vers l'entité consommatrice du service (ECS) lorsque le résultat de validation est négatif, et en ce que la requête d'exécution du service est transmise vers l'entité d'exécution du service(EES) lorsque le résultat de validation est positif.
[Revendication 4] Procédé de traitement selon la revendication 3, caractérisé en ce qu'il comprend, en réponse à un résultat de validation positif, l'obtention par l'entité intermédiaire d'un identifiant (URI3) de l'entité d'exécution du service (EES), et en ce que la requête d'exécution du service (REQ) est transmise (27) à l'entité d'exécution du service (EES) en utilisant ledit identifiant obtenu.
[Revendication 5] Procédé de traitement selon l'une quelconque des revendications 2 et 4, caractérisé en ce que ledit au moins un message de réponse reçu comprend un message de rapport d'exécution du service (REP') émis par l'entité d'exécution du service (EES) et en ce que ledit message de rapport d'exécution du service est transmis (29) vers l'entité consommatrice du service (ECS).
[Revendication 6] Procédé de traitement selon l'une quelconque des revendications précédentes, caractérisé en ce que la décision (22) de transmettre ou non ladite requête à l'entité de validation du service (EVS) est prise en fonction d'au moins un critère de décision (CRT) donné relatif à au moins un indicateur de fonctionnement du réseau (IND) et/ou un type de la requête d'exécution du service.
[Revendication 7] Procédé de validation d'une requête d'exécution d'un service (Si) dans un réseau de communication (RC), ladite requête (REQ.) ayant été émise par une entité dite consommatrice du service (ECS) dudit réseau à destination d'une entité d'exécution du service (EES), caractérisé en ce qu'il est mis en œuvre au niveau d'une entité de validation du service (EVS) distincte de ladite entité d'exécution et en ce qu'il comprend :
- la réception (40) de ladite requête d'exécution du service (REQ.) en provenance d'une entité intermédiaire (RP, SCP) configurée pour recevoir des messages à destination de ou en provenance de l'entité d'exécution du service (EES);
- la vérification (41) d'une validité de ladite requête d'exécution du service, comprenant l'obtention d'un résultat de validation ; et
- l'exécution (42) d'au moins une action en fonction du résultat de validation obtenu.
[Revendication 8] Procédé de validation selon la revendication précédente, caractérisé en ce que ladite au moins une action comprend la transmission (421) d'un message d'information de validation (REP) comprenant le résultat de validation à l'entité intermédiaire (RP, SCP).
[Revendication 9] Procédé de validation selon l'une quelconque des revendications 7 et 8, caractérisé en ce que, lorsque le résultat de validation est positif, ladite au moins une action comprend la transmission (422) de ladite requête d'exécution du service (REQ) à l'entité d'exécution du service (EES).
[Revendication 10] Procédé de validation selon la revendication 9, caractérisé en ce que, ladite au moins une action comprend en outre la réception (423) d'un message de réponse en provenance de l'entité d'exécution du service (EES)comprenant un rapport d'exécution du service (REP') et la transmission (424) dudit message de réponse à destination de l'entité intermédiaire (RP, SCP).
[Revendication 11] Entité intermédiaire (RP, SCP) d'un réseau de communication (RC), configurée pour recevoir des messages en provenance en provenance d'une entité, dite consommatrice d'un service (ECS), et à destination d'une entité d'exécution dudit service (EES) et pour recevoir des messages en provenance de l'entité d'exécution du service et destinés à l'entité consommatrice du service, ladite entité intermédiaire étant caractérisée en ce qu'elle est configurée pour mettre en œuvre :
- la réception d'une requête d'exécution du service (REQ) en provenance de l'entité consommatrice du service (ECS) ;
- la prise de décision de transmettre (23) ou non pour validation la requête d'exécution du service (REQ) vers une entité de validation (EVS) de ladite requête, distincte de l'entité d'exécution du service (EES), avant transmission (27) de ladite requête à l'entité d'exécution du service (EES).
[Revendication 12] Entité de validation (EVS) d'une requête d'exécution d'un service dans un réseau de communication (RC), ladite requête ayant été émise par une entité consommatrice du service (ECS) à destination d'une entité d'exécution du service (EES), caractérisé en ce qu'elle est configurée pour mettre en œuvre :
- la réception de ladite requête d'exécution, ladite requête ayant été transmise à l'entité de validation (EVS) par une entité intermédiaire (RP, SCP) configurée pour recevoir des messages en provenance et/ou destinés à l'entité d'exécution du service (EES) ;
- la vérification d'une validité de ladite requête ; et
- la transmission d'un message de réponse à destination de l'entité intermédiaire comprenant au moins un résultat de validation.
[Revendication 13] Système (S) de gestion d'un service (Si) dans un réseau de communication (RC), ledit système comprenant une entité consommatrice du service (ECS) et une entité d'exécution du service (EES), ladite entité consommatrice étant configurée pour transmettre une requête d'exécution du service (REQ.) à l'entité d'exécution du service (EES), caractérisé en ce qu'il comprend une entité de validation (EVS) de la requête d'exécution du service, distincte de l'entité d'exécution du service (EES) et conforme à la revendication 12 et une entité intermédiaire (RP, SCP) conforme à la revendication 11.
[Revendication 14] Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d'un procédé selon l'une quelconque des revendications 1 à 10, lorsqu'il est exécuté par un processeur.
PCT/EP2023/079144 2022-10-21 2023-10-19 Procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d'ordinateur correspondants WO2024083978A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2210911A FR3141301A1 (fr) 2022-10-21 2022-10-21 Procédé de traitement d’une requête d’exécution d’un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d’ordinateur correspondants
FRFR2210911 2022-10-21

Publications (1)

Publication Number Publication Date
WO2024083978A1 true WO2024083978A1 (fr) 2024-04-25

Family

ID=85792686

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/079144 WO2024083978A1 (fr) 2022-10-21 2023-10-19 Procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d'ordinateur correspondants

Country Status (2)

Country Link
FR (1) FR3141301A1 (fr)
WO (1) WO2024083978A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130227634A1 (en) * 2012-02-28 2013-08-29 Partha Pal System and method for protecting service-level entities
WO2022095730A1 (fr) * 2020-11-05 2022-05-12 腾讯科技（深圳）有限公司 Procédé, système et appareil de communication de service, et dispositif électronique
CN114491454A (zh) * 2022-02-16 2022-05-13 平安科技（深圳）有限公司 请求校验方法、装置及计算机可读存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130227634A1 (en) * 2012-02-28 2013-08-29 Partha Pal System and method for protecting service-level entities
WO2022095730A1 (fr) * 2020-11-05 2022-05-12 腾讯科技（深圳）有限公司 Procédé, système et appareil de communication de service, et dispositif électronique
CN114491454A (zh) * 2022-02-16 2022-05-13 平安科技（深圳）有限公司 请求校验方法、装置及计算机可读存储介质

Also Published As

Publication number Publication date
FR3141301A1 (fr) 2024-04-26

Similar Documents

Publication Publication Date Title
EP3243176B1 (fr) Procédé de traitement d'une transaction à partir d'un terminal de communication
FR2801697A1 (fr) Procede d'acces selon divers protocoles a des objets d'un arbre representatif d'au moins une ressource de systeme
EP1726124B1 (fr) Systeme et procede de controle d'equipements a distance a l'aide de commandes at, dispositif, module de radiocommunication et programme correspondants
EP0599706A2 (fr) Dispositif de traitement de l'information permettant la gestion d'une ressource informatique par un système d'administration
Boyd et al. Building Real-time Mobile Solutions with MQTT and IBM MessageSight
WO2020016499A1 (fr) Procédé de coordination d'une pluralité de serveurs de gestion d'équipements
EP2353256A1 (fr) Determination et gestion de reseaux virtuels
US9563781B2 (en) Directional optimization for policy evaluation
US20170331923A1 (en) Using an integration service to facilitate interactions between software systems
FR2847406A1 (fr) Procede et dispositif modulaire de tracage d'un message multimedia a travers un reseau de telecommunications
EP0969625B1 (fr) Agent de communication entre un administrateur et au moins une ressource d'un système informatique
EP3657859B1 (fr) Optimisation par type de message de l'échange de données entre objets connectés
WO2024083978A1 (fr) Procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d'ordinateur correspondants
EP3714588B1 (fr) Procede de gestion a distance d'un dispositif connecte a une passerelle residentielle
EP2674860A1 (fr) Procédé de traitement de données par un module de navigation
EP3475847B1 (fr) Serveur de statistiques pour optimisation de requêtes client-serveur
US8930523B2 (en) Stateful business application processing in an otherwise stateless service-oriented architecture
EP2497235A1 (fr) Outil de diagnostic pour réseaux à haut débit
Patel et al. Introduction to Cloud Computing and Amazon Web Services (AWS)
WO2018172669A1 (fr) Procédé et dispositif de gestion du stockage de documents numériques
EP1047222A1 (fr) Procédé de gestion des états de fonctionnement dans un système informatique
FR2801704A1 (fr) Procede de communication sous plusieurs protocoles entre une application et une ressource de systeme
WO2023217639A1 (fr) Procédé, dispositif et système d'élaboration dynamique d'une infrastructure de données
FR2816419A1 (fr) Procede de repartition de charge entre serveurs d'un systeme informatique distribue
WO2023217638A1 (fr) Procédé, dispositif et système de certification d'une ressource

Legal Events

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

Ref document number: 23790357

Country of ref document: EP

Kind code of ref document: A1