Method for processing a request to execute a service in a communication network, and corresponding method for validating the request, intermediate entity, validating entity, system and computer program

Abstract

The invention relates to a method for processing a request (REQ) to execute a service in a communication network, from a service consuming entity (ECS) to a service executing entity (EES), characterised in that it is implemented at an intermediate entity configured to receive messages from the service consuming entity intended for the service executing entity (EES) or from the service executing entity intended for the service consuming entity, and comprises: - receiving (20) the request (REQ) to execute the service from the service consuming entity (ECS); - deciding (22) whether or not to transmit (23) the request to execute the service (REQ) to a validating entity (EVS) for validation of the request, which validating entity is separate from the service executing entity (EES), before transmitting (27) the request to the service executing entity (EES).

Description

Description Title of the invention: Method for processing a request for execution of a service in a communication network, method for validating the request, intermediate entity, validation entity, corresponding system and computer program Field of invention

[0001] 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.

[0002] In such a network, the invention relates in particular to the validation of a request for execution of a service before its transmission to the service execution entity. Prior art

[0003] The 5G core network is composed of multiple Network Functions (NFs), each with its own role and logic. A NF is typically responsible for executing multiple services. Each service has its own role and logic within its NF. In order for one service to communicate with another, each service is accessible through an Application Programming Interface (API) interface.

[0004] The 3GPP standards body specifies the API for each of the services implemented by the NF network functions 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 exchanged data structures. 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 an operation of the service that does not conform to the format of the API of this service must be rejected by the requested service and provides for various error messages to be returned to the entity that issued the request.

[0005] Indeed, the processing by a given service of requests to execute operations that do not comply with the API of this service can lead to malfunctions, with undetermined consequences on the operation of the service itself, the NF network function that hosts the service or even the core network. It should be noted in this regard that the issuance of a request to execute an invalid operation (i.e., one that does not comply with the API) may be intentional or not, for example due to a design defect in a computer program (in English, "bug"). Given that the 5G core network in its first version (version 15) already has more than 50 services, it is understandable that the multiplication of these malfunctions can impact not only the quality of service, but also the general security of the core network.

[0006] Today, a check on the validity of requests for executing a service or an operation of a service is carried out by the entity in charge of executing the service. Thus, the NF network functions of the core network and, by extension, 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. However, generally, the executable file of a service inseparably includes the business logic of the service and the operation validity check. As a result, as soon as a change occurs for the execution of the service, the entire software must be updated and retested, even if the operation validation part is not affected by this change.

[0007] However, the NF network functions of the core network are software entities (i.e. software) that can be designed using computer languages ​​from various design environments (in English, "frameworks"). The choices of these software technologies belong to the service designers and the manufacturers of the server equipment that 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 indeed multiple and varied, so that mastering all these ecosystems requires a significant investment for a manufacturer. It will also be understood that the most appropriate software ecosystem for the design of a service is not necessarily the one that provides the best level of control over the validity of an operation executed by this service.

[0008] Furthermore, the API programming interfaces of the 5G core network services are complex and evolve regularly at the rate of several releases per year. Therefore, the development of an operations validation software layer, dependent on the 3GPP version of the service in question and on the software ecosystem of an execution software layer of this service, is a task that must be repeated by programmers frequently and in a non-optimal programming environment, requiring a significant investment for a high risk of bugs and regressions.

[0009] Finally, we know of tools for automatically generating validation layer computer code from OpenAPI description documents of an API of a service of a given NF network function of the 5G core network. An advantage of these tools is that they are capable of producing new validation layer computer code for any new service as well as for a new 3GPP version of an existing service. Compared to a design carried out by a programmer, the quality of the code produced is higher (lower risk of bugs and regressions). However, since the OpenAPI format for describing core network APIs also evolves with successive versions, it follows that the tools for automatic computer code generation must also evolve.

[0010] There is therefore a need for a solution for validating service execution requests that is both more efficient and simpler to implement and maintain. This invention improves the situation. Statement of the invention

[0011] The invention meets this need by proposing a method for processing a request for execution of a service in a communication network, originating from an entity known as a consumer of the service, intended for an entity executing said service, said method being implemented at the level of an intermediate entity configured to receive messages originating from the entity consuming the service and intended for the entity executing the service or originating from the entity executing the service and intended for the entity consuming the service, and comprising: - receipt of said request for execution of the service from the entity consuming the service; - the decision to transmit or not transmit for validation the request for execution of the service to an entity for validation of said request, distinct from the entity for execution of the service, before transmission of said request to the entity for execution of the service.

[0012] The invention thus proposes a completely new and inventive approach to the processing of a request for execution of a service operated by a communications network, which consists on the one hand in separating the prior validation of the request from the execution of the service itself and on the other hand in entrust the processing of these requests and their routing to one and / or other of the service validation and execution entities to an intermediary entity placed in between the service execution requests issued by consumer entities in the communication network and in front of the service validation and execution entities.

[0013] For example, according to the invention, these request validation and service execution functions are performed by separate entities of the communication network. In this way, 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 request validation entities for the execution of several separate 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, an actor 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 intermediary entity that has control over the processing of requests and their possible prior validation.Due to its position at the interface of the flow of requests between client entities (consumers of a service) and server entities (which produce / execute the services), it has visibility over all transactions relating to the services in question and has information to decide whether or not it is necessary for a received request to be subject to prior validation, which allows in particular adaptation to an operating context, such as for example a state of network saturation, a level of quality of the requests received depending on the service requested, etc. It can implement, if necessary, a systematic validation of all the requests it receives or, on the contrary, choose to submit only some of the requests to prior validation by relying on information it has on an operating state of the communication network, such as the state of traffic, a level of quality of the requests previously received, etc.

[0014] The invention thus offers great flexibility, while not deviating from the required quality criteria. It also leaves the possibility of evolving the chosen validation policy over time.

[0015] The invention also makes it possible to increase the modularity of a communication network.

[0016] It also helps optimize and streamline the investment efforts of a manufacturer of software solutions for validating service execution requests in a context of heterogeneous software ecosystems.

[0017] It is particularly suited to a communications network, such as the 5G core network, implementing 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.

[0018] In such an architecture, physical or hardware resources, for example server equipment with significant computing and memory capacities, are used by an orchestrator which supervises in real time the allocation of memory and computing quotas, called virtual machines or containerization instances, to software entities of the NF network function type, services of these NF network functions or even operations of these services, monitors the quantity of memory and the computing time or CPU (Central Processing Unit) actually used by each entity and replicates / delete the virtual machine or containerization instances of a given software entity to meet increased / decreased needs.

[0019] For example, the service required by the service-consuming entity is implemented in a given network function. Such a network function is composed of entities organized among themselves in a network and which are not directly reachable / routable from the outside. It is understood that these entities (and the associated network function) form a kind of subnetwork of which the service-consuming entity generally only knows a public identifier, for example a URI. This network function can provide one or more services.

[0020] The intermediary entity thus acts as a gateway between the service-consuming entity, which requests the execution of this service, and the execution (or production) entity of the requested service. This is, for example, a reverse proxy device which hides from the service-consuming entity the presence of entities belonging to the network function and which contribute to the execution of the requested service.

[0021] The invention is therefore part of the trend of disaggregation or decomposition of the logic of the 5G core network. Advantageously, the invention is implemented at the level of an intermediate entity placed at the cut-off (front) of the network path taken by the execution requests of a service and configured to transmit the requests to be validated to a validation entity separate from the execution entity of the service.

[0022] According to another aspect of the invention, the method comprises: - the transmission of said request for execution of the service to the service validation entity; - receiving at least one response message from among a validation information message and an execution report message; and - transmitting the received response message to the relevant entity among the service consuming entity and the service executing entity, based on the received response message.

[0023] One advantage is that the intermediary entity incorporates the intelligence needed to forward the request and / or response messages it receives to the correct entity. In addition, its role and position give it visibility into the quality of requests, allowing it to decide whether or not to suspend systematic validation of the next requests to be processed.

[0024] The invention thus allows the implementation of at least two embodiments: - according to a first embodiment, 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. According to this embodiment, the intermediate entity receives the validation information message from the service validation entity. If the request is not validated, this validation information message comprises a message body describing the reason for the rejection and a status code. For example, a response message compliant with the 3GPP specifications comprises an HTTP status code of class 4xx. When the request has been validated, the information message comprises a status code which indicates to which entity the request must be transmitted, which is equivalent to validation of the request. In the embodiment described here, this status code is an HTTP code of class 3xx.

[0025] Therefore, the intermediate entity always receives at least the validation information message and, if applicable, the execution report; - according to a second embodiment of the invention, the validation entity and the service execution entity communicate directly with each other. In the event of positive validation, the entity The validation entity directly forwards the service execution request to the executing entity and receives in return the execution report, which it forwards to the intermediate entity. If the request is not validated, the validating 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.

[0026] According to yet another aspect of the invention, 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 consuming entity of the service when the validation result is negative, and the request for execution of the service is transmitted to the execution entity of the service when the validation result is positive.

[0027] According to this first embodiment, the intermediate entity is also the obligatory passage between the validation entity and the execution entity of the service, which do not communicate directly with each other. This configuration is particularly suitable in the case where they do not belong to the same subnet or the same network function.

[0028] The service consumer receives a validation error message and the request is not forwarded to the service execution entity. One advantage is that this informs the service consumer that the service execution request is rejected because it is invalid.

[0029] According to yet another aspect of the invention, 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 request for execution of the service is transmitted to the entity executing the service using said obtained identifier.

[0030] An advantage is that the identifier for accessing the service execution entity is obtained by the intermediate entity only upon successful validation. This ensures 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 subnet of another type, and public otherwise, so as to allow the service execution entity to be reached directly. The identifier of the service execution may be obtained by the intermediate entity from the validation information message received from the validating entity (e.g., it is contained in this message), or alternatively it may be determined by the intermediate entity.

[0031] According to yet another aspect, said at least one received response message comprises a service execution report message issued by the service execution entity and in that said service execution report message is transmitted to the service consuming entity.

[0032] Advantageously, when the request has been validated, the intermediate entity receives in all cases (whether or not the validation entity is connected to the execution entity of the service) an execution report message comprising a result or at least a confirmation of the execution of the service from the execution entity of the service, which it transmits to the consuming entity of the service.

[0033] According to another aspect of the invention, 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 network operating indicator and / or a type of execution request. of the service.

[0034] For example, said at least one network operating indicator belongs to a group of indicators of a network operating state, comprising at least one indicator of traffic, latency, occupation (saturation) of the physical resources of the network over a given time period, an indicator of quality 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 not having been subject to prior validation, etc. It may also be a counter of service execution requests previously submitted for 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 comprises a value threshold of said at least one indicator.

[0035] Alternatively, it may be considered that the criterion for deciding whether or not to forward 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).

[0036] In this way, the invention makes it possible to achieve a compromise between the effort put into validating requests for the execution of a service and the preservation of network resources.

[0037] The invention also relates to an intermediate entity of a communication network, configured to receive messages 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: - receipt of a request for execution of the service from the entity consuming the service; - the decision to transmit or not transmit for validation the request for execution of the service to an entity for validation of said request, distinct from the entity for execution of the service, before transmission of said request to the entity for execution of the service.

[0038] Advantageously, said intermediate entity is configured to implement the steps of the method for processing a request as described previously.

[0039] Correlatively, the invention also relates to a method for validating a request for execution of a service in a communication network, said request having been sent by an entity known as a consumer of the service of said network to an entity executing the service, said method being implemented at the level of a service validation entity distinct from said execution entity and in that it comprises: - receiving said service execution request from an intermediate entity configured to receive messages to or from the service execution entity; - verifying the validity of said service execution request, including obtaining a validation result; and - the execution of at least one action based on the validation result obtained.

[0040] With the invention, the validation of requests is therefore ensured by an entity separate from the service execution entity. This independent entity receives the requests to be validated from the entity intermediary. It can therefore be designed in an environment different from that of the execution entity. It can also be shared for several services.

[0041] According to one aspect of the invention, said at least one action comprises the transmission of a validation information message comprising the validation result to the intermediate entity.

[0042] One advantage is that the responsibility for deciding whether or not a service execution request should be forwarded to the service execution entity is entirely assigned to the intermediary entity. The validating entity is solely responsible for validating the service execution requests it receives from this intermediary entity and returning a validation result to it.

[0043] According to a particular embodiment, a positive validation response may further comprise an identifier of the execution entity of the service.

[0044] This identifier allows the intermediary entity to transmit the service execution request to the service execution entity. An advantage is that it is only obtained by the intermediary entity when the execution request has been considered valid by the service validation entity.

[0045] According to another aspect of the invention, when the validation result is positive, said at least one action comprises the transmission of said request for execution of the service to the execution entity of the service.

[0046] An advantage is that the validating entity directly redirects a service execution request that is considered valid to the relevant service execution entity. In this way, the latency introduced by the validation phase is minimized.

[0047] According to yet another aspect of the invention, said at least one action further comprises receiving a response message from the service execution entity comprising a service execution report and transmitting said response message to the intermediate entity.

[0048] The invention also relates to an entity for validating a request for executing a service in a communication network, said request having been sent by a consumer entity of the service to an execution entity of the service. The validation entity is configured to implement: - the reception of said execution request, said request having been transmitted to the validation entity by an intermediate entity configured to receive messages from an entity, called the consumer of a service, and intended for an execution entity of said service and to receive messages from the execution entity of the service and intended for the consumer entity of the service; - verification of the validity of said request; and - the transmission of a response message to the intermediate entity including at least one validation result.

[0049] Advantageously, said validation entity is configured to implement the steps of the method for validating a request as described previously.

[0050] Advantageously, said intermediate entity and said validation entity are included in a system for managing a service in a communication network, said system comprising a consumer entity of the service and an execution entity of the service, said consumer entity being configured to transmit a request for execution of the service to the execution entity of the service.

[0051] The system has at least the same advantages as those conferred by the aforementioned processing method and validation method.

[0052] The invention also relates to computer program products comprising program code instructions for implementing the processing and validation methods as described above, when executed by a processor.

[0053] A program may use any programming language, and may be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0054] The invention also relates to a computer-readable recording medium on which are recorded the computer programs comprising program code instructions for executing the steps of the methods according to the invention as described above.

[0055] Such a recording medium may be any entity or device capable of storing the program. For example, the medium may comprise a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a mobile medium (memory card) or a hard disk or an SSD.

[0056] On the other hand, 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 contained therein is remotely executable. The program according to the invention may in particular be downloaded over a network, for example the Internet.

[0057] Alternatively, the recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to perform or to be used in performing the above method.

[0058] According to an exemplary embodiment, the present technique is implemented by means of software and / or hardware components. In this regard, the term "module" may correspond in this document to a software component, a hardware component or a set of hardware and software components.

[0059] A software component corresponds to one or more computer programs, one or more sub-programs of a program, or more generally to any element of a program or software capable of implementing a function or a 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 likely to access the hardware resources of this physical entity (memories, recording media, communication buses, electronic input / output cards, user interfaces, etc.). Subsequently, resources are understood to mean all sets of hardware and / or software elements supporting a function or a service, whether individual or combined.

[0060] Similarly, a hardware component is any element of a hardware assembly capable of implementing a function or set of functions, as 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.

[0061] Each component of the system described above of course implements its own software modules.

[0062] The different embodiments mentioned above can be combined with each other for the implementation of the present technique. Brief description of the drawings

[0063] Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate an exemplary embodiment thereof without any limiting character. In the figures:

[0064] [Fig. 1]: schematically illustrates an example of architecture of a system for managing a request for execution of a service in a communication network according to an embodiment of the invention;

[0065] [Fig. 2]: Describes in the form of a flowchart the steps of a method for processing such a request for execution of a service, according to the invention;

[0066] [Fig. 3A]: describes in the form of a flowchart the steps of a method for validating such a request for execution of a service, according to a first exemplary embodiment of the invention;

[0067] [Fig. 3B]: describes in the form of a flowchart the steps of a method for validating such a request for execution of a service, according to a second exemplary embodiment of the invention;

[0068] [Fig. 3C]: describes in the form of a flowchart the steps of a method for validating such a request for execution of a service, according to a third exemplary embodiment of the invention;

[0069] [Fig. 4] [Fig. 5] [Fig. 6] [Fig. 7] [Fig. 8] [Fig. 9]: schematically illustrate the messages exchanged between the different entities of the system for managing a request for execution of a service according to a first exemplary embodiment of the invention;

[0070] [Fig. 10] [Fig. 11] [Fig. 12]: schematically illustrate the messages exchanged between different entities of the system for managing a request for execution of a service according to a second exemplary embodiment of the invention;

[0071] [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 an embodiment of the invention; and

[0072] [Fig. 14]: schematically illustrates an example of hardware structure of an entity for validating a request for execution of a service according to an embodiment of the invention. Description of the invention

[0073] The general principle of the invention consists in separating, in a communication network, the validation of requests for execution of a service coming from a consumer entity of the service, from the actual execution of this service and at the same time centralizing the processing of such requests at the level of an intermediate entity. This intermediate entity is advantageously placed in front of the consumer entity of the service and the requests that it sends, in relation to the validation and execution entities of the service concerned. In other words, this intermediate entity is the first entity that receives the request from a consumer entity, that is to say which is visible to this consumer entity. It is thus placed in cut-off from the flow of requests addressed from the consumer entities to the execution entity. As a result, it hides the validation and execution entities from the consumer entities of the service.

[0074] More specifically, the invention proposes to entrust the tasks of validating a request execution of a service and execution of this request to two distinct entities of the network 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. According to the invention, these two entities have distinct locations (typically are represented by two distinct executable files) and each has its own identifier, for example of the U RI type (in English, "Universal Resource Identifier"), which allows another entity of the network to reach it, and to communicate with it.

[0075] The invention thus makes it possible to make the communication network more modular, and thereby to rationalize the design efforts and therefore the investments necessary to implement an efficient validation of service execution requests in a communication network. Indeed, since the task of validating a service execution request is dissociated from the execution of the service itself, the constraint of adapting to the software environment of the service execution entity is relaxed and a validation solution manufacturer can choose the most suitable design environment.

[0076] The invention also makes it possible to control the processing of these requests and their prior validation by this intermediate entity, which has visibility on 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 decide accordingly 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 the execution requests actually by the service execution entity. In this way, the invention contributes to improving load management and more generally the quality of service within this network.

[0077] The invention relates to any type of network implementing a service-oriented architecture (service requester / service provider) based on application devices. In the remainder of the description, the case of NF network functions configured to perform one or more tasks or services and exchange information with each other through a service interface SBI (Service Based Interface) is considered in particular. However, the invention also applies to other types of application devices such as, for example, web service type application devices.

[0078] In a service-oriented, virtualized and distributed architecture, the allocation of physical resources for the implementation of these network functions is supervised by orchestrator equipment.

[0079] Services are exposed for example by using standard protocols to represent their data in a serialized way (i.e. in the form of a string) (SOAP, Thrift, JSON) allowing the format of the messages exchanged to be imposed.

[0080] Each application device, for example, integrates a software component designed to perform a specific task or tasks such as retrieving information (e.g., the identity of a mobile terminal when it is attached) or executing an operation (e.g., implementing a tunnel). For example, a network function contains the software code and data necessary to perform the list of tasks or services associated with this function.

[0081] Access to such services is via application programming interfaces or APIs (in English, “Applicative Programming Interface”), for example of the REST API type (for “REpresentational 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 control.

[0082]

[0083] An example of a network to which the invention is particularly suited is a 5G core network, as specified by the 3GPP standard.

[0084] In the case of the 5G standard, the data format is JSON and the exchange protocol is HTTP / 2. Each service retrieves, creates, modifies, or deletes a resource. Writing is done using the POST, PUT, or DELETE commands, and reading is done using the GET command.

[0085] Of course, the invention applies to other data formats, to other protocols (for example to the HTTP / 3 protocol), as well as in other contexts (for example a 6G core network).

[0086] Figure 1 schematically illustrates an example of the architecture of a system S for managing a request for execution of a service in an RC communication network, for example a 5G mobile core network as specified by 3GPP.

[0087] 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 upon this service. For simplicity, in Figure 1, a single ECS entity has been represented, but it is understood that the RC network may include several. For example, this is a particular NF network function which requires the execution of a service from an EES entity for producing or executing this service, for example another NF function of this network. It is also understood that a network function may be both a producer of a service for another network function and a consumer in turn of a service provided by this other network function.

[0088] The RC network further comprises an EVS validation entity for a request for execution of the service provided by the EES execution entity. According to the invention, this is an entity separate 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 comprises attributes and parameters included in the body of the request and / or in one or more headers of this request (for example, the unique identifier or URI).

[0089] According to this embodiment of the invention, 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 request for execution of the service sent by the consuming entity ECS. The system S further comprises an intermediate entity of the communication network RC, placed in front of the consuming entity of the ECS service with respect to the execution entity EES of the service. This is for example a proxy device, which is configured to receive messages from and / or intended for the execution entity of the EES service and plays a gateway role between the consuming entity of the service and the execution entity of this service, by transforming a public identifier of this service known to the consuming entity of the service and indicated in its request into another identifier of the execution entity of the service, not known to the consuming entity of the service.

[0090] According to the invention, the intermediate entity is configured to receive said request for execution of the service from the entity consuming the service, decide whether or not to transmit the request for execution of the service to an EVS validation entity 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.

[0091] Said intermediate entity thus implements the method for processing a request for execution of a service according to the invention which will be detailed below in relation to Figure 2.

[0092] For example, the execution entity of the EES service is included in a subnetwork or private network (not shown) of this RC network, for example that of a network function NF in charge of the execution of 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 the other entities of the RC network. Conversely, the entities of this private network communicate with the rest of the RC network only via this intermediate entity. Thus, the consuming entity of the ECS service sends its REQ request to an identifier (for example a URI) associated with the execution entity of the EES service in the RC network or with the network function that 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 execution entity of the service or of another entity in the private network to which it belongs.According to a first embodiment of the invention, 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. In the case of a 5G core network, this proxy device processes requests compliant with the HTTP2 protocol. According to another embodiment of the invention, the intermediate entity is of the SCP type (in English, "Service Communication Proxy"). This is another type of proxy device, defined in particular in version 16 (or "Release 16" in English) of the 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 device is a routable address, therefore public.

[0093] According to the exemplary embodiment of Figure 1, 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 from the intermediate entity RP, SCP, verify a validity of said request for execution of the service, including obtaining a validation result, and execute at least one action for processing the request according to the validation result obtained.

[0094] The EVS validation entity thus implements the method for validating a validation request according to the invention which will be detailed below in relation to Figures 3A to 3C.

[0095] We now present, in relation to Figure 2, in the form of a flowchart, an example of implementation of a method for processing a request for execution of a service in a communication network RC according to an embodiment of the invention. Advantageously, the method is implemented by the intermediate entity RP, SCP.

[0096] At 20, a request to execute a service Si is received from an ECS consumer entity, for example a first network function of the RC network. It is noted that, 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 end of a given period, it may possibly retransmit the request.

[0097] This request indicates the public identifier of the service requested by the service consuming entity, which corresponds for example to that of the NF network function or 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 registered in the network, for example by a network function dedicated to the registration of such profiles.

[0098] In 21 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 a 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 not having been subject to prior validation, etc. These indicators are for example determined from measurement data collected in the network by telemetry.

[0099] At 22, this or these indicators are used to decide whether the received REQ request is subject to prior validation or directly transmitted to the relevant EES execution entity. Advantageously, an identifier (for example URI) of an EVS entity responsible for validating execution requests for this service is obtained, as detailed below. At least one CRT decision criterion is taken into account. This is, for example, a value threshold of said at least one indicator.

[0100] According to a first case, the decision is made to transmit the request REQ to the EVS validation entity in charge of the requested service Si. It is transmitted at 23. To do this, a URI2 identifier of the EVS validation entity has been previously obtained, for example, using configuration rules associating with 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. Alternatively, these configuration rules are grouped in a data table, accessible from the intermediate entity RP, SCP. For example, this information has been obtained during a preliminary discovery phase of the service functions available in the RC network and the services they provide.

[0101] The validation operations carried out by the EVS validation entity on the REQ request are detailed later.

[0102] According to a first embodiment of the invention, a response message REP is received at 24. It comprises a validation information message from the validation entity EVS and therefore comprises a validation result RES which may be positive or negative. Depending on the validation result, it is decided at 25 to transmit the request REQ at T1 to the execution entity of the service EES when this validation result is positive and on the contrary to reject the request REQ otherwise.

[0103] Advantageously, when the RES validation result is positive, the response message comprises at least one location information of the EES execution entity of the requested service, for example a response conforming to the HTTP protocol with a status code of the class “3xx” indicating a redirection, and more precisely of the type “307 Location: URI3”. Such a response comprises for example a private identifier of the network function or of 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 within this network function.

[0104] On the contrary, in case of rejection of the REQ request for lack of conformity (for example non-compliant format of the body of the request, name of a non-compliant attribute, type of a non-compliant attribute, value of a non-compliant attribute, non-compliant multi-attribute constraint, etc.), the REP response comprises a body and a status code. In the embodiment envisaged here, it is a response compliant with the HTTP protocol and the value of the status code is of the class "4xx". The body and the status code comply with 3GPP specifications which are stated in one or more OpenAPI documents describing the operations of the service.

[0105] In case of rejection, 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 not valid.

[0106] In the event of a positive result, a response message REP' including a service execution report is received at 28 from the execution entity EES and transmitted to the consumer entity of the ECS service at 29.

[0107] It is understood that according to this first embodiment, the intermediate entity RP, SCP is the recipient of all the 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 comprising the validation result RES transmitted by the validation entity EVS, and in the event of a positive validation result, the response message REP' comprising the report of execution of the service by the execution entity EES.

[0108] According to a second embodiment of the invention, a single response message is received by the intermediate entity RP, SCP. In the case where 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. On the contrary, when the validation entity EVS has rejected the request, 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 where appropriate by the intermediate entity RP, SCP to the ECS entity at 29, respectively 26.

[0109] In a second case, it is decided not to transmit the request REQ to the validation entity EVS. It is therefore transmitted directly to the execution entity EES at 27. Steps 28 and 29 are identical to those already described.

[0110] It is understood that, according to the invention, a REQ request is not necessarily subject to validation, which makes it possible to limit the latency introduced by the implementation of the invention. In this case, an error message may be issued by the execution entity EES, when the REQ request presents non-conformities making it impossible to execute the requested service or operation. In the embodiment described here, this error message may indicate an HTTP status code in the 5xx class or a 404 Not Found status code.

[0111] We now present, in relation to Figures 3A to 3C, in the form of a flowchart, examples of implementation of a method for validating a request for execution of a service in a communication network according to several embodiments of the invention. Advantageously, the method is implemented by the EVS validation entity.

[0112] In relation to Figure 3A, a request for execution of a service REQ is received at 30 by the validation entity EVS from the intermediate entity RP, SCP. At 31, the information fields composing this request REQ are verified. In particular, in the case of a 5G core network, the verification concerns the body of the request (in English, “request body”) and any associated parameters and headers. Natively, the validation entity EVS has for example been 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 body of the request, as well as any associated parameters and headers. It is noted that this OpenAPI format also describes the structure of the response messages.

[0113] The EVS validation entity then checks that the body of the request and any associated parameters and headers comply with those defined in the service's programming interface description document. Following this check, the EVS validation entity provides a RES result. (positive in case of conformity of all the elements of the REQ request which have been verified by the EVS validation entity, negative in case of non-conformity of at least one of these elements), which is taken into account in 32 to decide on an ACT action to be triggered.

[0114] At this stage, two cases are possible: according to a first embodiment of the invention illustrated by FIG. 3B, the action decided is the sending at 321 of a REP response to the intermediate entity RP, SCP. When the request REQ has been validated, this REP response message is a validation information message comprising a positive RES result. Optionally, it comprises identification / location information of the execution entity of the EES service in the RC network and for example in the private network of the network function to which it belongs. For example, said identification / location information is a universal identifier of type URI (URI3) which is not known to the consuming entity of the ECS service.

[0115] On the contrary, when the REQ request is rejected (i.e. is not validated), the REP response message includes, in the body of the message, an error code; it can also include a description of the errors (i.e. non-conformities) identified. For example, the status code is of type HTTP 400, which means "bad request". Note that the body of the error response message is compliant with the OpenAPI description for any service operation considered.

[0116] According to a second embodiment of the invention, illustrated by FIG. 3C, when the request REQ is validated, the action ACT decided is to directly transmit the service execution request REQ at 322 to the execution entity EES (using the identifier URI3). According to this second embodiment, a response message REP' comprising an execution report sent by the execution entity EES is received at 323 and transmitted at 324 to the intermediate entity RP, SCP. It is understood that according to this second embodiment, the validation entity EVS plays an intermediary role between the intermediate entity RP, SCP and the execution entity of the service ECS. Alternatively, the validation entity EVS is integrated into the intermediate entity RP, SCP.

[0117] We will now detail, in relation to figures 4 to 12, examples of embodiments of the invention in the case of a 5G core network.

[0118] As previously mentioned, a 5G core network as specified by 3GPP is composed of different network functions (NFs), each with a well-defined role. A network function (NF) is generally responsible for executing several distinct services. A service of a network function is described by 3GPP in the form of one or more APIs, themselves specified in a description document compliant with the OpenAPI format. One objective of an API is in particular to define the content of service execution requests sent by a service consumer entity and the content of responses sent by the service execution or production entity.

[0119] For example, it is a REST API type API, that is to say, conforming to a set of architectural constraints defined by REST. It should be noted that 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 control.

[0120]

[0121] As an example, we consider the NRF network function (from the English, “Network function Repository Function”) for registering NF network functions, whose role is to provide an up-to-date directory of the state of the NF network functions of a 5G core network and their data defined in a profile (in English, “NFProfile”). This profile includes in particular an identifier (URI) making it possible to locate each NF network function in the 5G core network. This identifier generally points to a logical address.

[0122] 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 a service for discovering NF functions. To this end, it implements a service called "Nnrf_NFManagement" for managing NF network function profiles and subscriptions. The operations proposed to manage an NF network function profile include registration, update, deletion and consultation.

[0123] For example, the request to perform an NF function profile registration operation is PUT / nf-instances / {nflnstancelD}. It has a request body of type NFProfile. The OpenAPI description of the request for this operation is: put: summary: Register a new NF Instance operationld: RegisterNFInstance tags: - NF Instance ID (Document) parameters: - name: nflnstancelD in: path reguired: true description: Unigue ID of the NF 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] This example does not include a query parameter, but it does include a path parameter in the URI specified by {nflnstancelD}. Note that POST, PUT, and DELETE requests generally do not include query parameters, unlike GET requests.

[0125] In relation to Figures 4 to 9, we consider 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 execution entities EES and validation EVS of N services. According to these exemplary embodiments of the invention, this intermediate entity RP is configured to implement the method for processing a request for execution of a service, as previously described. In Figures 4 to 9, for simplicity, only the EVS and EES entities relating to a given service Si have been represented, with i integer between 1 and N. A second rectangle has been represented behind each EVS and EES rectangle to show that several instances of these EVS and EES entities could have been allocated by an orchestrator of the RC network, depending on the needs, as previously mentioned.

[0126] In relation to Figures 4 to 7, examples of implementation of the first embodiment of the invention are now described, according to which the reverse proxy RP serves as an intermediary for all message exchanges, not only between the consuming entity of the ECS service and the NFx network function, but also between the EVS validation and EES execution entities of the Si service.

[0127] In Figure 4, a REQ request is received by the reverse proxy RP of the NFx network function from an ECS consumer entity 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 ECS consumer entity from the Nnrf_NFmanagement profile management service of the previously mentioned NRF network function.

[0128] The REQ request is then forwarded to the EVS validation entity. To do this, the "public" identifier URI1 was replaced by the reverse proxy RP with a private identifier of type URI, URI2, associated with the EVS validation entity, which is internal to the NFx network function, and therefore is not known outside the NFx network function. Upon receipt of the REQ request, the EVS validation entity checks that it complies with the API specification document of the requested Si service. In the example in Figure 4, the REQ request is validated. The EVS validation entity returns a REP response to the reverse proxy RP indicating, in a dedicated header, for example the location header "location", the private identifier URI3 of the EES execution entity of the Si service. This REP response includes a status code, which here corresponds, in the case of a validated request, to the HTTP redirection code 307.This is a standard HTTP redirect response (with a 3xx HTTP status code). Note that the entity serving such a response specifies the Redirect URL in the Location header.

[0129] The reverse proxy RP forwards the request REQ to the execution entity EES using the identifier URI3. It receives a response REP' including an execution report which it then forwards to the consuming entity of the ECS service.

[0130] In relation to Figure 5, we now describe the case of a request REQ not validated by the EVS validation entity. The response message REP sent by the EVS validation entity to the reverse proxy RP includes an error code, namely in the embodiment described here, an HTTP error code of the “4xx” class. Upon receipt, the reverse proxy RP transmits it to the consuming entity of the ECS service.

[0131] In connection with Figure 6, we now describe an example in which the reverse proxy RP received the REQ request, but decided not to submit it for validation by the EVS entity, based on one or more operating indicators representative for example of a state of the RC network, or of the load of the NFx function or of a rejection rate of requests previously processed for the requested Si service, etc. The REQ request is therefore transmitted directly to the EES service execution entity, whose private identifier URI3 of the NFx network function is obtained by other means, for example based on configuration rules. This request is processed by the EES service execution entity which returns a REP' response including an execution result to the reverse proxy RP. It is received by the reverse proxy RP which transmits it to the ECS service consumer entity.

[0132] Examples of implementations of the second embodiment of the invention are now described in relation to figures 7 to 9. As for figures 4 to 6, the method for processing a request to execute a service is implemented by an intermediate entity, for example of the reverse proxy RP type, which is part of the NFx network function.

[0133] In relation to Figure 7, upon receipt of the REQ request, the reverse proxy RP transmits it to the EVS validation entity as previously described. The EVS validation entity verifies it but does not validate it. It therefore sends a REP response to the reverse proxy RP including an MERR error message. In the embodiment described here, 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.

[0134] In relation to Figure 8, we now consider the case where the REQ request has been validated by the EVS entity. According to this second embodiment, the EVS entity directly transmits the REQ request to the execution entity EES of the requested service Si, using its private identifier URI3. It receives a response REP' from the execution entity EES, which it transmits to the reverse proxy RP. Upon receipt, the intermediate entity RP transmits the response to the service consumer entity ECS.

[0135] In relation to Figure 9, 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 execution entity of the EES service via configuration rules and therefore transmits the REQ request directly to it. The execution entity of the EES service executes the service and returns to it a REP' response including a result of this execution.

[0136] In connection with Figures 10 to 12, embodiments are now described in which the EVS validation entity and the intermediate entity are external to the NFx network function that implements the Si service requested by the ECS service consumer entity and the EVS validation entity. For example, the intermediate entity is an SCP device as previously described. In the case of multi-distributed NF functions and in certain deployment models, this SCP device is configured to constitute a single entry point for a group of network functions that are registered in the NRF function, including the NFx function. In other words, only the SCP knows the NFx producing the requested Si service.

[0137] For example, the EVS validation entity 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 similar way to the examples in Figures 4 to 9.

[0138] In relation to Figure 10, the SCP device receives the REQ request from the ECS service consumer entity. This REQ request is addressed to the public identifier URI1 of the SCP device and includes an identifier of the desired Si service, for example the name of the API of the NFx network function service that implements the Si service (for example, "nsmf-pdusession / vl"). The SCP equipment transmits it to the relevant EVS validation entity using the URI2 identifier of this EVS entity that it has previously obtained from the identifier of the NFx network function and profile information of the NFx function obtained from the NRF network function. This is not a private identifier, but a routable address in the RC network. The EVS entity checks the received REQ request and sends to the SCP equipment (URI1) a validation response REP message including a positive result (for example with a status code 307). According to this embodiment, the REP response does not include a private identifier URI3 allowing access to the execution entity EES of the requested Si service.For example, the SCP device obtains the identifier URI3 in question from the identifier of the service Si produced by the NFx network function and from profile information of the network function that provides the service Si, previously obtained from the NRF network function. It transmits the request REQ to the execution entity EES using the identifier URI3. In this example, the request REQ is not received directly by the execution entity of the service EES, but by an intermediate entity included in the NFx network function, for example a reverse proxy device RP as previously described and which is responsible for transmitting the request REQ to the private identifier of the entity EES inside the NFx network function. It is understood that in this case, URI3 is the identifier of the reverse proxy device RP of the NFx network function and that the private identifier of the entity EES is not known outside the NFx network function.Upon receipt, the EES entity executes the requested service Si and sends a response message REP' to the RP equipment, which forwards it to the intermediate SCP entity. Upon receipt, the SCP equipment forwards it to the consuming entity of the ECS service.

[0139] In relation to Figure 11, a header of the REQ request received by the SCP equipment is modified by the SCP equipment to insert the URI3 identifier of the NFx network function (“3gpp-Sbi-Tar- get-apiRoot” = URI3). It is noted that the SCP is configured to determine this URI3 identifier before the actual validation of the REQ request. However, it should also be noted that, according to the current 3GPP standard, 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.

[0140] Here again, it is assumed that the EVS validation entity validates the REQ request. Its REP response, for example a standard HTTP response of redirection type (with an HTTP status code of the 3xx class), includes the private identifier URI3 of the NFx network function previously received, which allows the SCP equipment to directly transmit the REQ request to this URL identifier. The rest corresponds to what was previously described in relation to Figure 11. It is noted that the use of the location header "3gpp-Sbi-Target-apiRoot" that has just been described is compliant with the specifications of the 3GPP standard. However, according to the current version of this standard, the SCP intermediate entity is the only recipient of the location header "3gpp-Sbi-Target-apiRoot" contained in a request and the only entity / function of the 5G core network configured to be placed in the cut-off of a client-server transaction.The SCP intermediary 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 a request through the SCP intermediary entity.

[0141] The present invention proposes to define a new EVS entity / function for validating requests, to insert it in the client / server exchanges and to configure it so that it transmits validated requests directly to the execution entity of the EES service. To do this, it relies on this location header. As a result, the implementation of the header "3gpp-Sbi-Target-apiRoot" made in fig.ll differs strictly from what is described in the 3GPP standard today.

[0142] In relation to Figure 12, we now consider, as in the example of Figure 12, that 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 requested Si service. The difference is that once the REQ request is validated by the EVS entity, the latter transmits it directly to the NFx network function using the URI3 identifier that it has recovered from the modified header. As previously described, it is received by the reverse proxy equipment RP which transmits it to the identifier of the execution entity EES, internal to the NFx network function. Once the Si service is executed, a REP' response is returned by the EES entity to the reverse proxy RP which forwards it to the SCP which itself forwards it to the consuming entity of the ECS service.It is understood that this embodiment involves the validation entity being configured to process the "3gpp-Sbi-Target-api-Root" header, as described in the 3GPP standard for the SCP intermediate entity.

[0143] According to yet another exemplary embodiment (not shown), the EVS validation entity of the service could be integrated directly into the SCP.

[0144] We then present, in relation to figure 13, 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 an entity, called the consumer entity of 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 entity executing the service, for validation, and a module for transmitting a response to said request to the consumer entity of the service.

[0145] Advantageously, the intermediate entity RP, SCP comprises a module for receiving a validation response message from the validation entity, said message comprising the validation result, and a module for deciding whether or not to transmit the execution request to the service execution entity based on the validation result received. Advantageously, 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.

[0146] The term "module" can correspond to a software component as well 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 sub-programs or more generally to any element of a program capable of implementing a function or a set of functions.

[0147] More generally, such an intermediate entity RP, 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). At initialization, the code instructions of the computer program are for example loaded into the random access memory 103 before being executed by the processor of the processing unit 102. The random access memory 103 may also contain for example information relating to the service validation entity and / or to the service execution entity, such as for example identifiers, allowing access to this or these entities, for example obtained during a prior discovery phase.It may further include one or more decision criteria relating to the triggering of the transmission of the EVS service execution request received to the service validation entity.

[0148] Figure 13 illustrates only one particular way, among several possible ways, of implementing the intermediate entity RP, SCP so that it performs the steps of the method for 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 computing machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated computing machine (for example a set of logic gates such as an FPGA or an ASIC, or any other hardware module).

[0149] In the case where the intermediate entity RP, SCP is produced with a reprogrammable computing machine, the corresponding program (i.e. the sequence of instructions) may 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.

[0150] The different embodiments have been described above in relation to an intermediate entity of the reverse proxy type network equipment or SCP equipment.

[0151] Finally, in relation to Figure 14, an example of hardware structure of an EVS validation entity for a request to execute a service in a communication network is presented, said request having been sent by a consumer entity of the service to an execution entity of the service, comprising a module for receiving said execution request from an intermediate entity RP, SCP configured to process said execution request, said validation entity being configured to receive messages from and / or intended for the execution entity of the service from the execution entity, a module for verifying the validity of said request, comprising obtaining a validation result and a module for triggering an action for processing the request as a function of the validation result obtained.

[0152] The term "module" can correspond to a software component as well 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 sub-programs or more generally to any element of a program capable of implementing a function or a set of functions.

[0153] More generally, such an EVS validation entity 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). At initialization, the code instructions of the computer program are for example loaded into the random access memory 203 before being executed by the processor of the processing unit 202. The random access memory 203 may also contain for example information identifying the execution entity of the requested service and / or the intermediate entity RP, SCP.

[0154] Figure 14 illustrates only one particular way, among several possible ways, of implementing the EVS validation entity so that it performs the steps of the method for validating a request for execution of a service as detailed above, in relation to Figures 4 to 12, in its different embodiments. Indeed, these steps can be carried out indifferently on a reprogrammable computing machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated computing machine (for example a set of logic gates such as an FPGA or an ASIC, or any other hardware module).

[0155] In the case where the EVS validation entity is carried out with a computing machine reprogrammable, the corresponding program (i.e. the sequence of instructions) may 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.

[0156] The embodiments which have just been described can be combined with each other.

Claims

Claims

1. Method for processing a request for execution of a service (REQ.) in a communication network (RC), originating from a so-called service consumer entity (ECS), intended for an execution entity of said service (EES), characterized in that said method is implemented at the level of an intermediate entity (RP, SCP) configured to receive messages originating from the service consumer entity and intended for the service execution entity (EES) or originating from the service execution entity and intended for the service consumer entity, and comprises: - the reception (20) of said request for execution of the service (REQ.) from the entity consuming the service (ECS); - the decision (22) to transmit (23) or not for validation the service execution request (REQ) to a validation entity (EVS) of said request, distinct from the service execution entity (EES), before transmission (27) of said request to the service execution entity (EES).

2. Treatment method according to claim 1, characterized in that it comprises: - the transmission (27) of said service execution request (REQ) to the service validation entity (EVS); - receiving (24,28) at least one response message (REP, REP') from among a validation information message (REP) and an execution report message (REP'); and - transmitting (26, 29) the received response message to the entity concerned among the service consuming entity (ECS) and the service executing entity (EES), depending on the received response message.

3. Processing method according to claim 2, characterized in that the at least one response message received comprises a validation information message (REP) from the validation entity (EVS) comprising a validation result, in that the validation information message is transmitted to the service consuming entity (ECS) when the validation result is negative, and in that the request for execution of the service is transmitted to the service execution entity (EES) when the validation result is positive.

4. Processing method according to claim 3, characterized in that it comprises, in response to a positive validation result, obtaining by the intermediate entity an identifier (URI3) of the service execution entity (EES), and in that the service execution request (REQ) is transmitted (27) to the service execution entity (EES) using said identifier obtained.

5. Processing method according to any one of claims 2 and 4, characterized in that said at least one response message received comprises a service execution report message (REP') sent by the service execution entity (EES) and in that said service execution report message is transmitted (29) to the service consuming entity (ECS).

6. Processing method according to any one of the preceding claims, characterized in that the decision (22) to transmit or not to transmit said request to the service validation entity (EVS) is taken as a function of at least one decision criterion (CRT) given relating to at least one network operating indicator (NOI) and / or one type of service execution request.

7. Method for validating a request for execution of a service (Si) in a communication network (RC), said request (REQ.) having been sent by a so-called service consumer entity (ECS) of said network to a service execution entity (EES), characterized in that it is implemented at the level of a service validation entity (EVS) distinct from said execution entity and in that it comprises: - receiving (40) said service execution request (REQ.) from an intermediate entity (RP, SCP) configured to receive messages to or from the service execution entity (EES); - verifying (41) the validity of said request for execution of the service, comprising obtaining a validation result; and - the execution (42) of at least one action depending on the validation result obtained.

8. Validation method according to the preceding claim, characterized in that said at least one action comprises the transmission (421) of a validation information message (REP) comprising the validation result to the intermediate entity (RP, SCP).

9. Validation method according to any one of claims 7 and 8, characterized in that, when the validation result is positive, said at least one action comprises the transmission (422) of said service execution request (REQ) to the service execution entity (EES).

10. Validation method according to claim 9, characterized in that said at least one action further comprises the reception (423) of a response message from the service execution entity (EES) comprising a service execution report (REP') and the transmission (424) of said response message to the intermediate entity (RP, SCP).

11. Intermediate entity (RP, SCP) of a communication network (RC), configured to receive messages from an entity, called a consumer of a service (ECS), and to an entity executing said service (EES) and to receive messages from the entity executing the service and intended for the entity consuming the service, said intermediate entity being characterized in that it is configured to implement: - receipt of a service execution request (REQ) from the service consuming entity (ECS); - the decision to transmit (23) or not for validation the service execution request (REQ) to a validation entity (EVS) of said request, distinct from the service execution entity (EES), before transmission (27) of said request to the service execution entity (EES).

12. Validation entity (EVS) of a request for execution of a service in a communication network (RC), said request having been sent by a service consuming entity (ECS) to a service execution entity (EES), characterized in that it is configured to implement: - receipt of said execution request, said request having been transmitted to the entity validation (EVS) by an intermediate entity (RP, SCP) configured to receive messages from and / or destined for the service execution entity (EES); - verification of the validity of said request; and - the transmission of a response message to the intermediate entity including at least one validation result.

13. System (S) for managing a service (Si) in a communication network (RC), said system comprising a service consuming entity (ECS) and a service executing entity (EES), said consuming entity being configured to transmit a service execution request (REQ.) to the service executing entity (EES), characterized in that it comprises a validation entity (EVS) of the service execution request, distinct from the service executing entity (EES) and in accordance with claim 12 and an intermediate entity (RP, SCP) in accordance with claim 11.

14. A computer program product comprising program code instructions for implementing a method according to any one of claims 1 to 10, when executed by a processor.

Images