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.
• 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 invention is therefore part of the trend of disaggregation or decomposition of the logic of the 5G core network.
• 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 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 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.
• a positive validation response may also include an identifier of 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.
• 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;
• 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.
• 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.
• 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
• 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 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 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.
• 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.
• 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.
• 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.
• 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:

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)

Applications Claiming Priority (2)

Publications (1)

Family

ID=85792686

Family Applications (1)

Country Status (3)

Families Citing this family (1)

Family Cites Families (3)

• 2022
  • 2022-10-21 FR FR2210911A patent/FR3141301A1/fr not_active Withdrawn
• 2023
  • 2023-10-19 EP EP23790357.0A patent/EP4606084A1/de active Pending
  • 2023-10-19 WO PCT/EP2023/079144 patent/WO2024083978A1/fr not_active Ceased

Also Published As

Similar Documents

Legal Events