EP4315961A1 - Procédés de gestion, de découverte, d'enregistrement et de communication et entités configurées pour mettre en oeuvre ces procédés - Google Patents

Procédés de gestion, de découverte, d'enregistrement et de communication et entités configurées pour mettre en oeuvre ces procédés

Info

Publication number
EP4315961A1
EP4315961A1 EP22719322.4A EP22719322A EP4315961A1 EP 4315961 A1 EP4315961 A1 EP 4315961A1 EP 22719322 A EP22719322 A EP 22719322A EP 4315961 A1 EP4315961 A1 EP 4315961A1
Authority
EP
European Patent Office
Prior art keywords
entity
application
request
network
control entity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22719322.4A
Other languages
German (de)
English (en)
Inventor
Michel Trefcon
Philippe Bertin
Alexandra ANSIAUX
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4315961A1 publication Critical patent/EP4315961A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • 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

Definitions

  • the invention belongs to the general field of telecommunications.
  • the invention has a preferred but non-limiting application in the context of 5th Generation (or 5G) telecommunications networks defined by the 3GPP (or “ Third Generation Partnership Project”) standard.
  • 5G 5th Generation
  • 3GPP Third Generation Partnership Project
  • 5G networks as defined by the 3GPP standard use network function virtualization (or NFV for "Network Function Virtualization"), software-defined network (or SDN for "Software Defined Networking” in English) and cutting networks into slices, more commonly known as “network slicing” in English.
  • network function virtualization or NFV for "Network Function Virtualization”
  • SDN software Defined Networking
  • 5G networks open up unprecedented prospects for the use of telecommunications networks.
  • they enable operators to create end-to-end, tailor-made and independent, scalable and agile virtual logical networks for their customers, all from the same physical network infrastructure (access network(s) , core network, etc.).
  • Through these virtual logical networks operators are able to provide their customers with solutions optimized for various scenarios corresponding to various constraints in terms of functionalities, performance and quality of service.
  • Network function virtualization or NFV relies on standard servers to run network service software (also called network functions or NFs for “Network Functions”), while software-defined networking or SDN centralizes control of the 5G network by software rather than via physical equipment. Thanks to this virtualization, network functions can be deployed and reconfigured easily, thus providing more elasticity.
  • Various network functions of a 5G core network can thus be virtualized, such as for example the access and mobility management network functions or AMF (for "Access Mobility Management Function"), session or SMF (for "Session Management Function” in English), network slice selection or NSSF (for "Network Slice Selection Function” in English), policy control or PCF (for "Policy Control Function” in English), etc
  • AMF Access Mobility Management Function
  • SMF Session Management Function
  • NSSF for "Network Slice Selection Function” in English
  • PCF Policy Control Function
  • This NRF function is responsible for providing a client or consumer (“consumer”) network function with the information enabling it to interact, directly or indirectly via an intermediate device (or SCP for "Service Communication Proxy") with a server network function (“producer” in English) offering one or more services in the network.
  • the 5G network architecture defined by the 3GPP standard is a service-based architecture (or SBA for “Service Based Architecture”).
  • SBA Service Based Architecture
  • the functionalities of a 5G network are ensured by a plurality of virtual network functions (or indifferently NF functions in the remainder of the description) which provide services to other network functions authorized to access these services. , the same network function being able to offer one or more services.
  • the NF functions of the 5G core network present the services they offer in the context of the 5G core network (in other words their functionalities) by through interfaces in the form of APIs (for "Application Programming Interfaces") that the other authorized NF functions can invoke.
  • a service model is used in which the NF "consumer” functions interrogate the network function NRF to discover the NF “producer” functions and communicate with them on the APIs they offer. This advantageously offers 5G network operators great flexibility and great adaptability.
  • the NRF network function is thus a catalog managing a plurality of NF functions, and storing the profiles of each of these NF functions.
  • Each profile includes a plurality of attributes, characterizing the operational state of the NF function (e.g. its availability, its load, since when it started, etc.), its characteristics (e.g. type of NF function, how it can be contacted, etc.), the services it offers, the resources it manages, etc. Attributes can also be defined more specifically at the level of each service (otherwise those defined at the NF function level apply). These profiles allow the NF “consumer” functions to discover providers of particular services and features in the network.
  • the NRF network function is updated during the activation and deactivation of each of the NF functions that it manages (i.e. during the registration and deregistration of each of them) as well as each resizing of an NF function (the NRF function can indeed manage several instances of the same NF function).
  • NFDiscovery a discovery service
  • Nnrf_NFDiscovery a discovery service
  • Nnrf_NFManagement a management service
  • Nnrf_AccessToken a service authorization service
  • the 3GPP standard also defines a subscription procedure via which an NF "consumer” function can request the NRF function to be informed of any change affecting an NF "producer” function (for example, availability of a new instance , update of an attribute of the profile of an NF function, etc.).
  • Release 16 also describes a "Nnrf_Boosttrapping" bootstrapping procedure allowing the discovery of the services offered by an NRF function by the NF entities of the 5G core network or by other NRF entities belonging to the same network or to a network (PLMN ) different.
  • Figure 1 taken from Joe Wilke's document entitled “5G Network Architecture and FMC”, IMT-2020/5G Workshop and Demo Day seminar, July 2017, schematically illustrates the interface (API) based on the service (or SBI for "Service Based Interface") implementation between two network functions NF A and NF B in a 5G network in accordance with the 3GPP standard.
  • API interface
  • SBI Service Based Interface
  • HTTP HyperText Transfer Protocol
  • these methods may optionally include specific header parameters and bodies, and targeting specific identified resources respectively by uniform resource identifiers or URI (for "Uniform Resource Identifier” in English).
  • URI Uniform Resource Identifier
  • the resources of the 5G core network cannot be extended indefinitely, in particular with regard to the bandwidth and the capacity of the NF functions of the "producers" type (in a fixed number) to process the HTTP requests sent by the NF functions of "consumer” type.
  • the performance of the 5G core network is improved, and more particularly its capacity to absorb traffic as well as its latency.
  • the 5G core network uses the HTTP client-server protocol for exchanges between the NF functions, and more particularly the HTTP/2 protocol.
  • the HTTP/2 protocol is a major evolution of the HTTP/1.1 protocol: it was designed to reduce latency and make exchanges more secure, while remaining compatible with the HTTP/1.1 version. To this end, it offers new functionalities such as the possibility of multiplexing requests and responses, the compression of HTTP headers, or the transmission of data in binary. It is important to note, however, that the HTTP/2 protocol does not modify the application semantics of the HTTP protocol in any way. All the basic concepts of the HTTP protocol, such as methods, status codes, URIs, header fields are preserved.
  • the HTTP/2 protocol changes how data is formatted and transported between a client and a server. Thanks in particular to the compression of the headers of requests and responses, the HTTP/2 protocol makes it possible to reduce and optimize the volume of data transmitted compared to the HTTP/1.1 protocol. It should be noted that the body of the requests and responses remains, where applicable, in conformity with the HTTP/1.1 protocol. This is described in detail in particular in the document IETF RFC 2616 entitled “Hypertext Transfer Protocol - HTTP/1.1”, June 1999.
  • the HTTP protocol is a protocol initially developed for the web. Optimizing the encoding of content exchanged via the HTTP protocol (e.g. text, images, fonts, etc.), and more particularly the compression of this content, is a key factor today advocated by players of the web to reduce latency and bandwidth consumption, and significantly improve the user experience.
  • the 5G core network is based on the HTTP protocol like the web, it is envisaged to apply best practices from the web in this area to the exchanges taking place in particular between the NF functions within the 5G core network.
  • the payload of an NF function profile provided in a request sent when registering an NF function or in a response provided by the NRF function during the discovery mechanism or even in a notification sent by the NRF function when an NF function profile is updated can easily approach 2 megabytes, which, compared to the numbers of these messages exchanged on the 5G core network, can constitute a total load important.
  • the APIs of the services offered by the NF functions of a 5G core network include dozens of operations using POST, PUT or PATCH type HTTP requests comprising a body comprising content, and this number of operations is in constant increase. A reduction in the size of the content exchanged by a few percent or more through the use of an encoding implementing data compression would have a significant impact on the bandwidth and on the latency of the network for all these operations.
  • the client can indicate in the request that it sends to the server, and more particularly in an "Accept-Encoding" header of the request, the different types of encoding that it supports (for example an encoding implementing data compression).
  • the server then returns a response to the client whose body conforms to the encoding indications provided by the client.
  • the server indicates for its part, in a “Content-Encoding” header of its response, the type (or format) of encoding (and more particularly of compression) applied to the content served to the client.
  • the negotiation of the encoding when it is implemented, is therefore at the initiative of the client and concerns only the response sent by the server to the client.
  • the client has no way of knowing before receiving the response from the server which encoding format the latter supports.
  • an NF “consumer” function can determine the encoding formats supported by an NF “producer” function by sending it an OPTIONS type request, the encoding formats supported by the NF “producer” function being returned to it in the response to the OPTIONS request;
  • a “producer” NF function can return an "Accept-Encoding" header as described previously containing the encoding formats it supports in a response, for example a response to a request comprising a body such as an HTTP POST request , PUT or PATCH.
  • the NF “consumer” function can then use one of the encoding formats provided by the NF “producer” function to encode the body, if applicable, of its next request addressed to the NF “producer” function.
  • An OPTIONS request has however only been implemented by the 3GPP standard for the Nnrf_NFManagement service (which includes the registration, deregistration and update operations mentioned previously) supported by the NRF network function.
  • a generalization of this solution would require implementing the OPTIONS request for all the resources of the different API interfaces of all the NF functions (currently defined and future) comprising HTTP requests that can implement an encoding of their content, and more particularly the HTTP POST, PUT and PATCH requests. This would result not only in cumbersome maintenance of the 5G core network specifications, but also in an increase in the volume of signaling exchanged in the core network (one dedicated transaction for each resource on each API), and the consideration of additional logic for each "consumer" NF function.
  • the invention offers a solution that does not have such drawbacks, and that can be easily applied in particular in the context of a 5G network as defined by the 3GPP standard.
  • 5G network As defined by the 3GPP standard, these assumptions are in no way limiting of the invention and the latter can be used in other contexts.
  • it can be used in networks other than a 5G network, relying on service registration and discovery procedures, such as micro-service architectures deployed in a cloud computing system or more commonly "cloud" in English.
  • An example of such an architecture is the Consul service mesh solution offered by Hashicorp.
  • the invention also applies to other protocols than the HTTP/2 protocol such as another version of the HTTP protocol (HTTP/1.1), or to the SOAP protocols (for "Simple Object Access Protocol” in English ), CORBA (for "Common Object Request Broker Architecture” in English), gRPC (for "Remote Procedure Call” in English), QUIC, etc., or any other protocol based on the exchange of requests and responses, and supporting an encoding of the body content of requests and/or responses, typically a compression of this content.
  • the invention generally applies to any application entity (physical or virtual) offering one or more services in a network and capable of implementing different types or formats of encoding (and the associated decodings) to encode (and decode ), and in particular to compress, content within the framework of these services.
  • an application entity within the meaning of the invention can be a virtual instance of a network function of a given type.
  • the invention is not limited to encodings making it possible to compress content, even if it is particularly advantageous in this context for optimizing the performance and latency of a network as mentioned above.
  • encoding formats such as for example an invariant encoding format (corresponding to keeping the content identical), base64 encoding, or any reversible transformation carried out for a particular purpose (e.g. reducing the size of content, obtaining content compatible with the majority of systems, securing content, etc.), etc.
  • the invention proposes a management method, by a network control entity, of a plurality of application entities offering services in the network, said management method comprising: a reception step coming from a first entity of a bootstrap request aimed at discovering services offered by the control entity and/or resources managed by the latter; and a step of sending a response to said bootstrap request from said first entity, said response further comprising at least one encoding format supported by the control entity.
  • the invention also relates to a network control entity managing a plurality of application entities offering services in the network, said control entity comprising a boot module, configured to, in response to a so-called priming request originating from a first entity and aimed at discovering services offered by the control entity and/or resources managed by the latter, providing this first entity with a response to said priming request, said response further comprising at least one encoding format supported by the control entity.
  • application entity any communicating entity (also called communication entity here) configured to implement a determined processing logic, such as for example an entity offering and/or consuming services in a network such as a network function or a network function instance, etc.
  • an application entity can be a network entity (i.e. which has a given functionality in a network), but it can also be a user equipment (or UE for "User Equipment”).
  • the first entity may for example be another control entity, which may belong to a network (or PLMN for "Public Land Mobile Network” in English) different from the control entity, or an application entity that wants to access the services offered by the control entity, and in particular the registration, subscription or discovery services offered by the latter, etc.
  • a network or PLMN for "Public Land Mobile Network” in English
  • PLMN Public Land Mobile Network
  • the response sent by the control entity to the bootstrap request that it receives from the first entity contains the encoding formats supported by the control entity.
  • This allows the first entity to use one of these formats as soon as it sends a request to the control entity to access one of the services offered by the latter.
  • the first entity is an application entity dependent on the control entity, this allows the application entity when it registers with the control entity, to use to provide its profile one of the encoding formats supported by the control entity.
  • the exchanges between the application entity and the control entity are therefore optimized.
  • the invention is easily compatible with Release 16 of the 3GPP standard and in particular with the Nnrf_Boostrapping bootstrapping procedure allowing the discovery of the services offered by an NRF function by the NF entities of the 5G core network or by other entities. NRF belonging to the same network or to a different (PLMN) network.
  • PLMN PLMN
  • the management method further comprises: a step of recording each application entity managed by the control entity comprising storing a profile of said application entity, this profile comprising a plurality of attributes including at least one encoding format supported by said application entity and which can be used when accessing a service offered by it; and in response to a request from a second entity, a step of supplying this second entity, for at least one said application entity managed by the control entity, with at least part of the plurality of attributes of the profile of this application entity, said part comprising said at least one encoding format supported by this application entity.
  • the network control entity further comprises: a recording module, configured to record each application entity managed by the control entity, said recording module being configured to memorize during the recording of an application entity a profile of this application entity comprising a plurality of attributes including at least one encoding format supported by said application entity and which can be used when accessing a service offered by it; and a publication module activated in response to a request from a second entity, and configured to provide this second entity, for at least one said application entity managed by the control entity, at least a part of the plurality attributes of the profile of this application entity, said part comprising said at least one encoding format supported by this application entity.
  • the request triggering the publication of all or part of the profile of an application entity managed by the control entity with another entity may in particular be a request for discovery of at least one application entity managed by the control entity responding for example to at least one given criterion specified implicitly or explicitly in the discovery request (e.g. application entities offering a given service, ensuring a given network function, etc. ).
  • the second entity may be for example another application entity, managed by the control entity or by another control entity, another control entity, intermediate equipment such as an SCP acting for example on behalf of another application entity, or even a network entity located at the periphery of the core network, user equipment, etc.
  • the second entity may or may not belong to the same network as the control entity.
  • the second entity, the control entity and the application entities can belong to different network slices.
  • the invention proposes to integrate, among the attributes listed in the profile of an application entity of the "producer” type and provided by the latter to the control entity which manages it during its registration, the or the different encoding formats it supports.
  • This advantageously allows the control entity to be able to publish to the "consumer” entities of the network or external to the network, interested in the services provided by the "producer” application entity and who request it, this or these encoding formats, and this, prior to any exchange between the “consumer” entities and the “producer” application entity.
  • a "consumer” entity can apply, from the first request that it sends to the "producer” entity in the context of access to a service offered by the latter, one of the encoding supported by the “producer” entity.
  • encoding formats are for example gzip, compress, deflate. The invention thus makes it possible to optimize all of the exchanges between the “consumer” entity and the “producer” entity, in particular in terms of bandwidth and latency.
  • the encoding format(s) thus published can be attributes considered by the "consumer” entity to select a “producer” entity from among several offering the same service, which makes it possible to further optimize network performance.
  • the application entities are for example NF functions, the control entity, an NRF network function, and the second entity, another function.
  • NF another control function (belonging or not to the same network as the control entity) or an intermediate equipment SCP.
  • the solution proposed by the invention advantageously makes it possible to avoid laborious definition of the API interfaces and/or cumbersome maintenance of the specifications of the 5G network. In fact, it only requires the updating of the attributes listed in the profile of an NF function which are stored by the NRF function, and published by the latter during discovery procedures aimed (directly or indirectly) at the NF function.
  • the implementation of the invention is therefore perfectly integrated into the logic of the 5G core network using an NRF function and into the defined procedures for registering the profiles of the NF functions with the NRF function, for discovering the NF "producer” functions by the NF “consumer” functions, and this, in particular, in Releases 15 and 16, or in future Releases taking up these procedures or similar procedures.
  • the invention thus offers a general and lasting solution, which can be applied to any operation of a service offered by an application entity, and in particular by a virtual network function, existing or future, in a 5G core network.
  • the management method further comprises: a step of receiving a subscription request, from a third entity, to receive information concerning at least one event affecting at least one profile stored by the control entity, this subscription indicating at least one encoding format supported by the third entity; and following detection of an event corresponding to said subscription request, a step of notifying said third entity comprising information relating to said detected event encoded by means of a said encoding format supported by the third entity and indicated in the subscription request.
  • the second and third entities can be one and the same communicating entity (physical or software), or be separate entities. They can belong to the same network or to different networks.
  • the third entity can be an application entity managed by the control entity or by another control entity, another control entity, an SCP device, a user device, etc.
  • the first entity may or may not be distinct from the second and/or third entities.
  • This embodiment also makes it possible to optimize the transmission of notifications sent asynchronously by the control entity to signal various events affecting the profiles of the application entities that it manages, to the entities which have indicated their interest in these events via a subscription mechanism known per se.
  • Such events are for example the creation, the modification or even the deletion of a profile of an application entity.
  • the invention according to this embodiment advantageously proposes that during the subscription, the third entity indicates the encoding format(s) that it supports so that the control entity can use these encoding formats when she sends him notifications.
  • a notification may include one or more profiles in whole or in part (e.g. part published by the control entity) or only the case if applicable, the attributes of the profile affected by the event.
  • the application of an encoding format to the information conveyed by the notifications given the large number of notifications likely to be sent by a control entity and the volume of data conveyed by each of them, is therefore particularly advantageous in terms of latency and bandwidth.
  • this embodiment is advantageous whether or not the third entity of the network is managed by the control entity, in particular in the context of the 3GPP standard.
  • the control entity knows for the application entities that it manages, the services offered by these application entities as “producers” (i.e. as service providers) and the attributes associated with these services (and therefore according to the invention, the encoding formats supported by these services).
  • producers i.e. as service providers
  • attributes associated with these services and therefore according to the invention, the encoding formats supported by these services.
  • a communicating entity subscribes to an event notification service relating to the profiles managed by the control entity, this entity acts as a "consumer” (i.e. as a consumer of the notification service). Consequently, even though this entity is an application entity registered with the control entity, the control entity does not know the encoding formats supported by the latter as “consumer”.
  • the embodiment that has just been described allows the control entity to memorize this information, for example in the subscription context associated with the entity in question, for use during future notifications if necessary. Storing this information in the subscription context avoids having to manage and update this information via new processing logic.
  • the encoding formats stored in the profile and in the subscription context indeed advantageously inherit the already existing mechanisms implemented in the network for the management of the other attributes contained in the profile and of the other subscription information.
  • the invention is therefore particularly simple to implement.
  • the third entity indicates the encoding format(s) that it supports during the subscription with the control entity. They can for example be indicated in the body of the subscription request with the other subscription information, in a field provided for this purpose.
  • the invention is based on the recording and publication by the control entity of the encoding formats supported by the application entities that it manages, but also on these application entities which, when they register with the control entity, provide it with the encoding formats that they support, as well as on the entity which is informed of these encoding formats and is able to use them from its first exchanges with the application entities.
  • the invention also relates to a method of discovery by an entity of services offered and/or of resources managed by a control entity of a network managing a plurality of application entities offering services in the network, said discovery method comprising: a step of sending a bootstrap request to said control entity aimed at discovering the services it offers and/or the resources managed by it; a step of receiving a response to said boot request further comprising at least one encoding format supported by the control entity.
  • the invention also relates to a method for registering an application entity offering at least one service in a network, with a network control entity managing a plurality of application entities offering services in the network, said recording method comprising: a step of discovering the services and/or resources managed by the network control entity using a discovery method according to the invention; and a step of registering the application entity with the control entity comprising a provision by said application entity to the control entity of a profile of said application entity, this profile comprising a plurality of attributes including at at least one encoding format supported by said application entity and able to be used when accessing a service offered by it, said control entity being configured to provide at least part of said plurality of attributes of the profile of the application entity, said part comprising said at least one encoding format, in response to a request from another entity.
  • the invention also relates to an application entity of a network offering at least one service in the network, said application entity comprising: a discovery module, configured to send a so-called boot request to a control entity of the network managing a plurality of application entities offering services in the network, said priming request aiming to discover services offered and/or resources managed by said control entity, said discovery module further being configured to receive a response to said boot request comprising said services offered and/or resources managed by said control entity and at least one encoding format supported by said control entity; and a registration module configured to register said application entity with said network control entity, said registration module being configured to provide the control entity during said registration with a profile of said application entity, this profile comprising a plurality of attributes including at least one encoding format supported by said application entity and able to be used when accessing a service offered by it, said control entity being configured to provide at least a part of said plurality of attributes of the profile of the application entity, said part comprising said at least one encoding format, in response to
  • a said encoding format supported by the control entity is used during recording by said application entity to encode the profile provided to the control entity.
  • the invention relates to a method of communication of a so-called "fourth" entity with a network control entity managing a plurality of application entities offering services in the network and storing profiles of these application entities, said communication method comprising: a step for discovering the services and/or resources managed by the network control entity using a discovery method according to the invention; a first step of sending to said control entity a request for discovery of application entities managed by the control entity; and a step of receiving a response to said discovery request indicating at least one so-called candidate application entity managed by the control entity and a plurality of attributes of this candidate application entity extracted from a profile of the application entity stored by the control entity, said plurality of attributes including at least one encoding format supported by this candidate application entity and which can be used when accessing a service offered by it.
  • the invention also relates to a so-called "fourth" entity comprising: a first communication module configured to send to a network control entity managing a plurality of application entities offering services in the network and storing profiles of said application entities, a first request for discovery of application entities managed by the control entity; and a reception module, configured to receive a response to said discovery request indicating at least one so-called candidate application entity managed by the control entity and a plurality of attributes of this candidate application entity extracted from a profile of the application entity stored by the control entity, said plurality of attributes including at least one encoding format supported by this candidate application entity and which can be used when accessing a service offered by it.
  • the communication method comprises a second step of sending, to said candidate application entity indicated in the response received, a request comprising a content encoded by means of a format of encoding supported by this candidate application entity and indicated in the response received.
  • the fourth entity comprises, in this embodiment, a second communication module, configured to send to said candidate application entity indicated in the response received a second request comprising content encoded by means of a format of in coding supported by said candidate application entity and indicated in the response received.
  • the fourth entity can be any one of the first, second and third entities mentioned previously or a distinct entity. It can be, as for the other entities, an application entity, a control entity, or any other entity such as a network entity or user equipment.
  • the request sent during the second sending step is the first request that the fourth entity sends to the candidate application entity when accessing a service offered by the latter.
  • the fourth entity does not actually need to send an additional request (eg OPTIONS request) to the candidate application entity to know an encoding format supported by the latter. It can, from the first request sent to the candidate application entity, exploit an encoding format that it knows how to support by the candidate application entity to encode a content that it intends for it.
  • an additional request eg OPTIONS request
  • the application entity, the fourth entity, the registration method and the communication method according to the invention have the same advantages mentioned above as the management method and the control entity according to the invention.
  • the candidate application entity to which the request is sent by the fourth entity during the second sending step is selected from among said plurality of candidate active entities taking into account the respective encoding formats supported by this plurality of candidate application entities.
  • the encoding formats supported by the application entities discovered by the fourth entity are used as selection criteria by the fourth entity to select an application entity from among these application entities discovered.
  • the fourth entity can thus favor one application entity among several because it supports an encoding format not supported by the others or more advantageous for optimizing its communications.
  • this criterion can be combined with other selection criteria, such as for example the service provided by the application entity in question, its function, its availability, etc.
  • the communication method further comprises a step of sending a subscription request to the control entity to receive information concerning at least one event affecting at least one stored profile. by the control entity, this subscription request indicating at least one encoding format supported by the fourth entity; and following detection of an event corresponding to said subscription request, a step of receiving a notification from the control entity comprising information relating to said event encoded by means of a said encoding format borne by the fourth entity and indicated in the subscription request.
  • An event affecting at least one profile stored by the control entity can in particular be a creation, a deletion or a modification of such a profile.
  • At least one said encoding format supported by a said entity targets an encoding of a content transmitted in a body of a request or a response conforming to a version of the HTTP protocol (HyperText Transfer Protocol).
  • HTTP protocol HyperText Transfer Protocol
  • At least one said encoding format is a data compression format.
  • the invention applies in particular in a privileged way in the context of 5G networks defined by the 3GPP standard to the HTTP/2 protocol, for the compression of the contents of the requests in accordance with this protocol exchanged between the various entities involved in the invention.
  • the invention can be applied in association with other protocols and other encoding formats.
  • At least one said encoding format is provided in an attribute that applies to: to all the services offered by this application entity; or to a given service or to a given version of a service offered by this application entity; or to a given resource managed by a service offered by this application entity; or to a given operation applied to a resource managed by a service offered by this application entity.
  • At least one said encoding format supported by a said entity is included in a data structure comprising at least one communication option supported by this entity.
  • the management, recording and communication methods are implemented by a computer.
  • the invention also relates to a computer program on a recording medium, this program being able to be implemented in a computer or more generally in a control entity in accordance with the invention and comprises instructions adapted to the implementation of a management method as described above.
  • the invention also relates to a computer program on a recording medium, this program being able to be implemented in a computer or more generally in an application entity in accordance with the invention and comprises instructions adapted to the implementation of a recording method as described above.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in an entity of a network in accordance with the invention and comprises instructions adapted to the implementation of a communication method as described above.
  • Each of these programs may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable shape.
  • the invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information or recording medium can be any entity or device capable of storing the programs.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a hard disk, or a flash memory.
  • the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio link, by optical link without wire or by other means.
  • the program according to the invention can in particular be downloaded from an Internet-type network.
  • the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of management, recording and communication according to the invention.
  • the invention relates to a system comprising: at least one application entity according to the invention offering at least one service in a network; a network control entity according to the invention managing said at least one application entity; and at least one (fourth) entity according to the invention.
  • the system benefits from the same advantages mentioned above as the management, recording and communication methods, the control entity, the application entity and the fourth entity according to the invention.
  • FIG. 1 already described, represents the SBI interface proposed by the 3GPP standard between two network functions NF;
  • FIG. 2 represents, in its environment, a system of a network according to the invention in a particular embodiment
  • FIG. 3 schematically represents the hardware architecture of a computer capable of hosting any of the entities according to the invention belonging to the system of FIG. 2;
  • FIG. 4 illustrates priming and registration procedures implemented in the system of FIG. 2 and relying on steps of the management, registration and communication methods according to the invention in a mode particular of realization;
  • FIG. 5 illustrates a discovery procedure implemented in the system of FIG. 2 and based on steps of the management, recording and communication methods according to the invention in a particular embodiment
  • FIG. 6 illustrates a subscription procedure implemented in the system of FIG. 2 and based on steps of the management and communication methods according to the invention in a particular embodiment.
  • FIG. 2 represents, in its environment, a system 1 in accordance with the invention, in a particular embodiment in which the system 1 is integrated into a CN core network of a 5G communications network as described in the 3GPP standard.
  • the system 1 brings together several entities of the core network CN, namely: a plurality of application entities NF1 NF2,...,NFN, in accordance with the invention, N designating a higher integer 1.
  • application entity we means any communicating entity (also called communication entity here) configured to implement a determined processing logic, such as for example an entity offering and/or consuming services in a network such as a network function or a network function instance , etc.
  • an application entity can be a network entity (ie which has a given functionality in a network), but it can also be user equipment (or UE for “User Equipment”).
  • each application entity NF1, NF2,..., NFN offers one or more services in the network (eg ensures one or more determined functionalities of the network).
  • Such application entities are, in the embodiment described here, instances of network functions (NF), known per se as, for example, instances of AMF, SMF, NSSF, PCF functions, etc. . mentioned before.
  • NF network functions
  • These are virtualized instances, in other words software entities, which execute various service logics to ensure the main functions of the core network (e.g. management of mobility and access to the core network, definition and network policy enforcement, billing, network slice selection, etc.).
  • Each service offered by an application entity can include one or more operations; and a control entity 2 managing these application entities NF1, NF2,..., NFN, in accordance with the invention.
  • the control entity 2 is an NRF network function, in other words a catalog storing for each of the application entities NF1,...,NFN, a profile referenced respectively by NF_PROF1, NF_PROF2,... ,NF_PROFN.
  • Each profile includes a plurality of attributes, characterizing the operational state of the associated application entity (e.g. its availability, its load, since when it started, etc.), its characteristics (e.g. type of NF function, how it can be reached , etc.), the services it offers, the resources it manages, etc.
  • the control entity 2 itself offers a plurality of services including, in particular, discovery, management (including registration/deregistration/update) and priming services, which include for example respectively the logic of the Nnrf_NFDiscovery, Nnrf_NFManagement and Nnrf_Boostrapping services described in particular in the documents 3GPP TS 23.502 entitled “Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2; (Release 16)”, V16.7.0, December 2020, and TS 29.510 titled “Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3”, V16.6.0, December 2020, except for the adjustments made by the invention.
  • This list is not exhaustive in itself and has the sole purpose of identifying the services of an NRF entity impacted by the invention.
  • the system 1 also comprises at least one other communicating entity 3, in accordance with the invention.
  • this entity can be either another application entity, managed or not by the control entity 2 (in other words, the entity 3 can be one of the application entities NF1,...,NFN), intermediate equipment of the SCP type, of another control entity of the NRF type belonging or not to the same network as the control entity 2, or of any other network entity or else of a user equipment, etc.
  • this entity 3 of the network CN is an entity of the core network CN, consumer (or "consumer") of one or more services offered by the application entities NF1,...,NFN managed by the controlling entity 2.
  • the entities of system 1 are, in the embodiment described here, software entities, hosted by physical devices of the CN core network, such as servers for example. These servers here have the hardware architecture of a computer 4, as shown schematically in Figure 3.
  • the computer 4 comprises in particular a processor 5, a random access memory 6, a read only memory 7, a non-volatile memory 8, and communication means 9 allowing in particular the entities of the system 1 to communicate with each other and with other elements, if any, of the CN core network or of another network.
  • These means of communication 9 are based on the one hand, on a wired or wireless communication interface, known per se and not described in more detail here, but also on one or more software interfaces based on the service or SBI. These software interfaces are APIs which here use the HTTP/2 protocol.
  • the read only memory 7 of the computer 4 constitutes a recording medium in accordance with the invention, readable by the processor 5 and on which is recorded one or more computer programs in accordance with the invention.
  • These modules include in particular in the embodiment described here, as illustrated in Figure 2: an NFk-A module, configured to offer one or more services (or functionalities) in the CN network via an SBI interface, for example to other application entities such as other network functions or, in the example considered here, to entity 3.
  • the services offered by the NFk-A module obviously depend on the type of application entity NFk considered.
  • an AMF-type NFk application entity offers the following services: user equipment registration management, reachability management, session management, user equipment mobility management, access management (authorization, etc. ), etc.
  • a discovery module NFk-B to discover the services offered by the control entity with which the application entity NFk must register. More particularly in the example considered here of a 3GPP 5G core network, it is assumed that the application entity NFk is configured with a reachability address of the control entity with which it must register (entity 2 control here), but that it does not know a priori the services supported by this control entity (for example the NF function management service with which it must register), nor the resources managed by entity 2 control.
  • the discovery module NFk-B is configured to send a so-called bootstrap request to the control entity 2 whose address it knows, and obtain a response to this bootstrap request including the services supported by the control entity 2, the resources that it manages, as well as at least one encoding format that the control entity 2 supports; and a registration module NFk-C configured to register the application entity NFk with the control entity 2 of the core network CN which manages it.
  • the recording module NFk-C is configured to provide the control entity 2 during this recording with a profile NF_PROFk of the application entity NFk, encoded with one of the encoding formats provided by the entity 2 of control in response to the bootstrap request.
  • the NF_PROFk profile includes a plurality of attributes characterizing the application entity (e.g. type, reachability addresses, PMLN, etc.), an identifier of this application entity (identifier of the instance of the corresponding network function), its state (e.g. registered, not available), etc.
  • attributes include in particular the attributes described in document 3GPP TS 29.510 cited above.
  • the profile NF_PROFk also includes as attribute(s) one or more encoding formats supported by the application entity NFk, and which can be used during access via an SBI interface to a service offered by this one to encode the contents of the bodies of the requests and/or HTTP/2 responses sent to it.
  • this or these encoding formats form part of the attributes which are published by the control entity 2 during the procedures for discovering the application entities, as explained further below.
  • These encoding formats are chosen from known encoding formats such as for example the compression formats gzip, compress, deflate, or even the invariant (“identity”) format indicating the absence of transformation applied to the content.
  • identity the invariant
  • one or more profiles comprise at least one encoding format of the compression format type.
  • modules NFk-A, NFk-B and NFk-C are described in more detail later, with reference to the steps of the recording method according to the invention.
  • the read only memory 7 of the computer 4 comprises, when the computer 4 hosts the control entity 2 according to the invention, a recording of a computer program PROG2, comprising instructions defining the main steps of a management method according to the invention.
  • This program PROG2 defines functional modules of the control entity 2 (NRF function in the example considered) which are based on or control the hardware elements 5 to 9 of the computer 4 mentioned above. These modules include in particular, in the embodiment described here, as illustrated in FIG. 2: a recording module 2A, configured to record each application entity NF1,...,NFN managed by the control entity 2.
  • the recording module 2A is for example configured to execute operations of the logic of the management service Nnrf_NFManagement defined by the standard 3GPP, adapted to take account of the invention.
  • the publication operated by the publication module 2B here targets application entities meeting at least one determined criterion (eg type of application entities), which can be indicated in the discovery request.
  • the publication module 2B is more particularly configured to execute, for example, the operations of the logic of the Nnrf_NFDiscovery discovery service defined by the 3GPP standard, arranged to take account of the invention: more specifically, among the attributes of the profile NF_PROFk which are published, in addition to the attributes indicated in the document TS 29.510 cited above, there is said at least one encoding format supported by the application entity NFk concerned.
  • the PROG2 program also defines the following functional modules: a notification module 2C, configured to manage subscription requests from entities (from the CN core network or external to the CN core network) in order to receive information concerning events affecting the profiles stored by the control entity 2 .
  • a notification module 2C configured to manage subscription requests from entities (from the CN core network or external to the CN core network) in order to receive information concerning events affecting the profiles stored by the control entity 2 .
  • Such an event is for example the creation, modification or deletion of one or more profiles managed by the control entity 2 .
  • the notification module 2C is configured to execute, for example, operations of the logic of the Nnrf_NFManagement management service defined by the 3GPP standard, in addition to those already executed by the module 2A, arranged to take account of the invention.
  • a communicating entity when a communicating entity subscribes to a notification service with the control entity 2 to be informed about specific events, it provides it with at least one encoding format that she supports.
  • the notification module 2C is then configured to record in a CNT context associated with the subscription of the network entity, the event(s) indicated during the subscription as well as the encoding format(s) provided to it, and to apply one of these encoding formats to the notifications that it sends to the communicating entity in question when it detects an event corresponding to the subscription; and a 2D priming (or "bootstrapping") module, configured here for, on a so-called priming request from a communicating entity (for example a priming request sent by the NFk-B module for discovering an application entity NFk described previously), providing this communicating entity (in other words publishing to this entity), the services that the control entity 2 offers as well as the resources that it manages.
  • a priming (or "bootstrapping") module configured here for, on a so-called priming request from a communicating entity
  • the 2D boot module is configured to execute, for example, operations of the logic of the Nnrf_Bootstrapping boot service defined by the 3GPP standard, arranged to take account of the invention. More specifically, in response to a boot request from a communicating entity (eg NF function, NRF function or other network entity or even user equipment, belonging to or attached to the CN core network or to another network), the module 2D priming is configured to supply in response to this request, in addition to the information requested of it, at least one encoding format that the control entity 2 supports.
  • a communicating entity eg NF function, NRF function or other network entity or even user equipment, belonging to or attached to the CN core network or to another network
  • modules 2A to 2D of the control entity 2 are described in more detail later, with reference to the steps of the management method according to the invention.
  • the ROM 7 of the computer 4 comprises, when the computer 4 hosts the communicating entity 3 according to the invention, a recording of a computer program PROG3, comprising instructions defining the main steps of a communication method according to the invention.
  • This program PROG3 defines functional modules of entity 3 which rely on or control the hardware elements 5 to 9 of computer 4 mentioned above. These modules include in particular in the embodiment described here, as illustrated in FIG. 2: a first communication module 3A configured to send to the control entity 2 a request for discovery of application entities managed by the latter.
  • This discovery request which is intended to be processed by the module 2B of the control entity 2 described previously, can contain one or more criteria that the application entities must verify, such as for example a type of application entity, a service provided by it, an encoding format supported by the application entity, etc.
  • a reception module 3B configured to receive a response to the discovery request indicating at least one so-called candidate application entity managed by the control entity 2 meeting the required criterion(s).
  • the response sent by the control entity 2 comprises all or part of the profiles of the candidate application entities, including at least, for each candidate application entity, an encoding format supported by the latter;
  • a selection module 3C configured when the response to the discovery request indicates several application entities, select one of them according to one or more determined selection criteria.
  • such a selection criterion can be a given encoding format, but other criteria can be envisaged such as for example a charge or a service offered; a second 3D communication module, configured to send to the selected candidate application entity, a request comprising a content encoded by means of an encoding format supported by the latter; and a subscription module 3E, configured to send to the control entity 2 a subscription request to receive information concerning at least one event affecting at least one profile stored by the control entity 2, for example the profiles of the entities candidate applications received by the reception module 3B.
  • the 3E module is configured to indicate to the control entity 2 in its subscription request at least one encoding format supported by the entity 3.
  • the 3E module is further configured to receive and process , when an event corresponding to the subscription request is detected by the control entity 2, a notification from the control entity 2 comprising information relating to this event encoded using an encoding format supported by the entity 3 and indicated in the subscription request.
  • modules 3A to 3E of the entity 3 of the network are described in more detail later, with reference to the steps of the communication method according to the invention.
  • the entity 3 is an entity of the core network CN distinct from the application entities NF1,...,NFN managed by the control entity 2.
  • this assumption is not limiting in itself, and the entity 3 can be integrated into one of the application entities NF1,...,NFN. Likewise, it can belong to a network separate from the CN core network or from the NW network.
  • FIG. 4 represents the procedures for priming and registering an application entity NFk with the control entity 2 .
  • each of the application entities NF1,...,NFN are attached to the control entity 2 and have been configured with a reachability address (e.g. URI) of the latter.
  • a reachability address e.g. URI
  • the purpose of this procedure is to allow each application entity NFk to dynamically determine how to access the services offered by the control entity 2 and in particular to identify to which resources (e.g. which URIs) to send their requests when access to these services.
  • the application entity NFk sends, via its discovery module NFk-B, a boot request to the control entity 2, at the address with which it was configured.
  • a boot request for example the URI “URI2-BS”), aimed at discovering the services offered by the control entity 2 and the resources that it manages (step E10).
  • This bootstrapping request is for example an HTTP GET/bootstrapping(URI2-BS) request as defined in the 3GPP standard in document TS 29.510 in particular.
  • the control entity 2 responds to this request via its 2D priming module (step E20). More specifically, the latter provides in the body here of an HTTP 200 OK response, the required information, namely the services that the control entity 2 offers (for example the management services NRF_NFManagement, discovery NRF_NFDiscovery , and authorization NRF_AccessToken) and URIs to access services and resources managed by these services.
  • the 2D boot module completes this information with one or more encoding formats, referenced by ENCOD-2, that the control entity 2 supports. It is assumed here that the set ENCOD-2 comprises one or more encoding formats including at least one compression format, for example gzip. All of the aforementioned information is referenced by BootstrappingData in Figure 4.
  • ENCOD-2 encoding formats can be defined at different levels, namely to apply to all the services offered by the control entity 2 and to all the resources it manages, or differ according to the services offered by the control entity 2, or even according to the resources managed by the control entity 2, or the operations carried out on these resources.
  • the application entity NFk On receipt of this 200 OK response, the application entity NFk stores the Bootstrap pingData information in association with the control entity 2 (E30).
  • the application entity NFk indicates in the bootstrap request sent to the control entity 2, for example in the Accept-Encoding header of the bootstrap request, at least one format encoding it supports.
  • the control entity 2 can use one of these encoding formats to encode the BootstrappingData information that it sends to the application entity NFk in response to the boot request, and indicate in the Content header -Encoding of the response, the encoding format it used.
  • this procedure for priming or discovering the services and resources of the control entity 2 can be executed by entities other than the application entities intended to register with it.
  • it can be executed by another control entity such as another NRF entity belonging or not to the same network (PLMN).
  • the NFk application entity obtains the ENCOD-2 encoding formats supported by the control entity 2 by sending it an OPTIONS request as described above.
  • the control entity 2 responds to this OPTIONS request by providing, in a 200 OK response, the encoding format(s) supported in the Accept-Encoding header of the response.
  • the NFk application entity can register with the control entity 2, using the BootstrappingData information it has on the NRF_NFManagement management service offered by the control entity 2 and the resource (eg URI) to point to access this service.
  • the resource eg URI
  • the application entity NFk sends, via its registration module NFk-C, a registration request (HTTP PUT request in the example considered here) in the body of which it provides its profile NF_PROFk (step E40).
  • the profile NF_PROFk is encoded by the module NFk-C by means of an encoding format selected from among the ENCOD-2 encoding formats supported by the control entity 2, for example the format of gzipped compression.
  • the encoding format selected (eg gzip) is indicated in the Content-Encoding header of the recording request.
  • the registration request is sent to a URI composed of the URI of the registration service and the URI of the resource associated with the application entity NFk to be registered.
  • the profile NF_PROFk comprises a plurality of attributes, and in particular, in the example considered here the attributes listed in document TS 29.510 in table 6.1.6.2.2-1 in section 6.1.6.2.2. These attributes include, but are not limited to, the identifier ( nflnstanceld ) of the NFk application entity (which is an instance of a given network function) to be created, the type ( nfType ) of the NFk application entity (i.e.
  • the profile NF_PROFk comprises an attribute containing one or more encoding formats supported by the application entity NFk. It is assumed here that at least one of these encoding formats is a compression format.
  • the encoding formats indicated in the profile NF_PROFk can be defined at different levels.
  • the attributes of an application entity can be defined in the profile of the application entity at the level of the application entity (they then concern all the services it offers and the resources it manages or that these services manage) or at the level of each service individually.
  • the encoding formats supported by the application entity NFk can be provided in attributes applying: to all the services offered by this application entity; or to a given service or to a given version of a service offered by this application entity; Where to a given resource managed by this application entity or by a service offered by this application entity; or to a given operation on a resource managed by this application entity or by a service offered by this application entity.
  • the control entity 2 Upon receipt of the registration request, the control entity 2 registers the application entity NFk via its registration module 2A: it stores its profile NF_PROFk at the URI indicated in the registration request. recording and associates an “available” state with the application entity NFk (step E50).
  • the control entity 2 confirms the registration of the application entity NFk by sending it an HTTP 201 Created response (step E60).
  • updates can be made to the profile of the application entity NFk (not represented in FIG. 4): for example, the application entity NFk may wish to record modifications to certain attributes of its profile or unregister with the controlling entity 2.
  • the NFk application entity can either resubmit its updated NF_PROFk profile in its entirety, for example here by means of a new HTTP PUT request, or only the modified attributes, for example here by means of a HTTP PATCH request.
  • the application entity NFk provides the profile NF_PROFk or only the modifications in the body of the request, encoded using an encoding format selected from the formats of ENCOD-2 encoding supported by the control entity 2 and indicated in the Content-Encoding header of the request.
  • the control entity 2 updates the profile NF_PROFk which it stores, and confirms the taking into account of the update to the application entity NFk.
  • the application entity NFk may also wish to deregister: in this case, it sends a deregistration request (HTTP DELETE request in the example considered here) to the control entity 2, which upon receipt of this request, associates an “unavailable” state with the application entity NFk.
  • the profile associated with the application entity NFk is moreover deleted (for example at the end of a determined period of time).
  • the three events which have just been described namely the creation of a profile (or equivalently, the recording of an application entity), its modification or its deletion (or equivalently the deregistration of the application entity), may be the subject of notifications sent by the control entity 2 to the entities which have subscribed, where applicable, with it to the notification of these events .
  • FIG. 5 represents a procedure for discovery by the entity 3 of application entities managed by the control entity 2 . No assumption is made on the nature of the entity 3. It may be, for example, another client application entity ("consumer") of the services of the application entities managed by the control entity 2 .
  • consumer another client application entity
  • the entity 3 wishes to discover all the application entities managed by the control entity 2 verifying one or more given search criteria, for example the application entities providing a particular service or corresponding to a determined network function.
  • the invention is not limited to functional search criteria, and it is also possible to consider, in addition or as a variant, basing this search on other criteria such as, for example, on a communication option supported by the application entities, and more specifically on a particular encoding format.
  • This discovery request is for example here an HTTP GET request. It includes "query parameters" specifying the search criteria(s) set by entity 3.
  • the control entity 2 verifies that the entity 3 is authorized to discover the application entities managed by the control entity 2 (step F20). It does this in a manner known to those skilled in the art and not detailed here.
  • control entity 2 via its publication module 2B, searches for the application entity(ies) registered with it which verifies the search criteria(s) indicated by the entity 3 (step F30).
  • publication module 2B searches for the application entities verifying each of these criteria. In a variant embodiment, it can search for the application entities verifying at least one of these criteria.
  • control entity 2 obtains an NF-MATCH set comprising one or more so-called “candidate” application entities verifying the search criteria of entity 3. for the sake of simplification in the following, reference is made to “candidate entities of the NF-MATCH set” including when this set comprises only one candidate entity.
  • the control entity 2 then sends the result of its search to the entity 3 in an HTTP 200 OK response (step F40). It indicates in the body of the response the NF-MATCH candidate application entities corresponding to the search criterion(ies) as well as the attributes of these candidate application entities useful to entity 3 to access the services offered by these application entities. candid dates. In the embodiment described here, it is only a part of the attributes present in the profile NF_PROFk: only the attributes necessary for the choice and the accessibility of the services are provided to the entity 3 (eg identifier of the application entity, type of application entity, state of the application entity, encoding formats, etc.).
  • the attributes transmitted include in particular the encoding format or formats supported by the candidate application entities of the NF-MATCH set.
  • control entity 2 can provide the entity 3 with all the attributes listed in the profiles of the candidate application entities of the NF-MATCH set.
  • the entity 3 indicates in the Accept-Encoding header of the discovery request addressed to the control entity 2 the encoding formats that it supports (for example at least one format compression), and the control entity 2 encodes the NF-MATCH set and the associated attributes using one of these encoding formats (for example the compression format), and indicates in the header Content-Encoding of the response the encoding format used.
  • the encoding formats that it supports for example at least one format compression
  • the control entity 2 encodes the NF-MATCH set and the associated attributes using one of these encoding formats (for example the compression format), and indicates in the header Content-Encoding of the response the encoding format used.
  • control entity 2 determines the encoding formats supported by the entity 3 by sending it an OPTIONS request and uses one of these encoding formats as described above.
  • the reception module 3B of the entity 3 extracts the information contained in the response and stores it for example in a cache memory for a determined duration (step F50).
  • the reception module 3B of the entity 3 extracts the information contained in the response and stores it for example in a cache memory for a determined duration (step F50).
  • entity 3 actually wishes to access a service offered by the candidate application entities of the NF-MATCH set.
  • entity 3 can, by means of its 3D selection module, select one of them according to one or more selection criteria. selection determined (step F60).
  • the selected application entity is designated NFk0.
  • the 3D selection module can take into account, to select the application entity NFkO from the set NF-MATCH, the encoding formats supported by the candidate application entities and select one of them which supports a specific encoding format (for example a compression format such as gzip).
  • other selection criteria may be considered by the 3D selection module, such as for example the loads of the candidate application entities or their respective capacities, or a priority associated with each of them, or their locations, or even a combination of several of these criteria or others criteria.
  • the entity 3 via its second 3D communication module sends a request for access to the service offered by the selected application entity NFk0 (step F70).
  • This request is for example here an HTTP POST, PUT or PATCH request depending on the service in question comprising a request body embedding content.
  • the 3D communication module can advantageously encode this content by means of an encoding format supported by the application entity NFk0 according to the information stored in its cache memory at step F50.
  • the entity 3 can use an encoding format supported by the application entity NFkO such as a compression format from the first request it sends to it when accessing a service offered by the NFkO application entity. It is not obliged to wait for a response to this first request to encode the content that it wishes to transmit to it. Of course, it can (and preferentially continues to) apply this encoding format in subsequent requests as well.
  • entity 3 can be configured to check before applying an encoding format to the content (in whole or in part) of a request or a response that it sends to an application entity, if the content is appropriate (for example if it satisfies a determined size criterion or if its encoding is not prohibited).
  • the profile of an application entity managed by the control entity 2 can be affected by various events (eg creation, deletion, modification), and change over time. This may have the consequence that the information stored in the cache memory of entity 3, and in particular the encoding formats supported by the application entities, may no longer be current when entity 3 seeks to access a service offered by one of the candidate application entities, without the latter being informed.
  • the encoding formats if the event consists of the activation of a new encoding format at the level of a candidate application entity, this does not pose a problem in itself provided that the other formats encoding are always supported by the candidate application entity. A problem arises when an encoding format is no longer supported by the candidate application entity.
  • a first solution known from the 3GPP standard, consists, if the entity 3 uses an encoding format which is no longer supported by the application entity with which it interacts and receives a rejection response with a status 415 , to send the request again without encoding or with an encoding conforming to one of the formats indicated if necessary by the application entity in a header of the response 415, for example in an Accept-Encoding field.
  • a second option also known from the 3GPP standard, consists, following receipt of the rejection response 415, in sending an OPTIONS request to the application entity to obtain an update of the encoding formats it supports. .
  • entity 3 can subscribe to the control entity 2 to receive notifications informing it of events which affect the profiles of the application entities that it manages.
  • entity 3 can specify the scope of the information it wishes to receive, and in particular the type of events (e.g. creation, modification, deletion of a profile) of which it wishes to be informed, and the resources involved.
  • the entity 3 sends, via its subscription module 3E, a subscription request to the control entity 2 indicating the events of which it wishes to be informed. (step G10).
  • These may for example be changes (creation, modification and deletion) affecting profiles of a given type of application entity (eg AMF network function).
  • AMF network function e.g AMF network function
  • this example is given for illustrative purposes only and is not limiting in itself.
  • other elements can be indicated during the subscription such as for example a particular service, an identifier of an application entity, etc.
  • the subscription request is for example here an HTTP POST request. It contains the events to which entity 3 subscribes. It also advantageously contains at least one encoding format supported by the entity 3, for example a compression format.
  • control entity 2 Upon receipt of the subscription request, the control entity 2 memorizes via its notification module 2C, in a context of the subscription of the entity 3, the encoding format(s) supported by the latter (step G20), and confirms the subscription with entity 3 by sending it a 201 Created response (step G30).
  • the control entity 2 via its 2D notification module, sends a notification to the entity 3 to inform it of the detected event (step G50).
  • This notification is for example here an HTTP POST request. It includes, in the body of the request, the NotificationData information relating to the detected event. This information may include, depending on the detected event, all or part of the profile affected by the event (at least the part published by the control entity 2 during the discovery procedure). Thus, for example, if the event is a profile creation, the notification includes all the attributes of the new profile which are usually published during the discovery procedure and which allow entity 3 to access the associated service to this profile.
  • the notification can include only the modified attributes, or summarize all the attributes usually published during the discovery procedure.
  • the information included in the body of the notification is encoded by the 2D notification module in an encoding format supported by the entity 3 and provided during its subscription.
  • entity 3 updates the relevant profiles stored in its cache memory (step G60).
  • This solution advantageously makes it possible to reduce the period of time during which the entity 3 is likely to use information that is not up to date to access the services offered by the application entities NF1,...,NFN.
  • the invention makes it possible in a simple way to optimize the exchanges between the various entities of the system 1, by relying on the knowledge of the encoding formats supported by these different entities.
  • these encoding formats can either be provided in dedicated fields or attributes, in proprietary fields or attributes, or even in data structures such as the caplnfo data structure mentioned previously, comprising at least one communication option (namely at least one encoding format) supported by the entity in question.
  • the invention has been described in the context of a 5G network defined by the 3GPP standard, with reference to application entities and a communicating entity 3 of network function type, and an NRF type control entity, as mentioned previously, the invention can be applied to other entities.
  • entity 3 can alternatively be another NRF-type control entity, whether or not belonging to the same PLMN as control entity 2, or an SCP-type intermediate device acting on behalf of an application entity “ customer", or user equipment attached to the network or an application function (or "Application Function"), located in the network or external to the network.
  • an SCP device after having discovered the candidate application entities and selected one of them, the SCP device can encode the contents received from the “customer” application entity on whose behalf it acts in using an encoding format supported by the candidate application entity.
  • the invention makes it possible to implement encoding on the section connecting the SCP equipment to the control entity 2; on the other hand, it does not ensure the implementation of such encoding between the "consumer” application entity and the SCP equipment acting on behalf of this application entity.
  • the SCP equipment is an application entity which can also register with the control entity 2 and be discovered by other network entities and in particular other SCP equipment, on the assumption that several SCPs are on a path connecting a “consumer” application entity and a “producer” application entity. This also makes it possible to apply an encoding to each segment of the communication path connecting two SCP devices.
  • the invention can also be applied in other generations of communications network or in other contexts than a 5G network, such as for example a 6G or next generation network, a cloud computing system offering microservices, to a proprietary network, etc., using procedures for registering and discovering these microservices. It can also apply to other protocols. Furthermore, the invention can also apply to application entities other than virtualized network function instances, such as for example physical application entities.
  • the invention can also be applied to protocols other than the HTTP/2 protocol, such as for example another version of the HTTP protocol (HTTP/1.1), or to the SOAP, CORBA, gRPC, QUIC, or generally to any other protocol based on the exchange of requests and responses, and supporting an encoding of the content of the body of the requests and/or the responses, typically a compression of this content.
  • HTTP/2 requests/responses and in particular the data conveyed by these requests/responses for the implementation of the invention, applies, transposed to the requests/responses of these protocols.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention propose un procédé de gestion, par une entité (2) de contrôle d'un réseau (CN), d'une pluralité d'entités applicatives (NF1,…,NFN) proposant des services dans le réseau, ce procédé de gestion comprenant : - une étape de réception en provenance d'une première entité (NFk) d'une requête d'amorçage visant à découvrir des services proposés par l'entité de contrôle et/ou des ressources gérées par celle-ci; et - une étape d'envoi d'une réponse à ladite requête d'amorçage de ladite première entité, ladite réponse comprenant en outre au moins un format d'encodage supporté par l'entité de contrôle.

Description

Description
Titre de l’invention : Procédés de gestion, de découverte, d’enregistrement et de communication et entités configurées pour mettre en œuvre ces procédés
Technique antérieure
[0001] L'invention appartient au domaine général des télécommunications.
[0002] Elle concerne plus particulièrement l'accès à des services offerts par des entités applicatives d'un réseau de télécommunications.
[0003] L'invention a une application privilégiée mais non limitative dans le contexte des réseaux de télécommunications de 5ème Génération (ou 5G) définis par le standard 3GPP (ou « Third Génération Part- nership Project » en anglais).
[0004] Les réseaux 5G tels que définis par le standard 3GPP exploitent de façon connue en soi des technologies de virtualisation de fonctions réseau (ou NFV pour « Network Function Virtualization » en anglais), de réseau défini par logiciel (ou SDN pour « Software Defined Networking » en anglais) et de découpage de réseaux en tranches, plus communément appelée « network slicing » en anglais. Ces technologies ouvrent des perspectives d'usage inédites des réseaux de télécommunications. Elles permettent notamment aux opérateurs de créer pour leurs clients des réseaux logiques virtuels de bout-en-bout, sur mesure et indépendants, évolutifs et agiles, et ce à partir d'une même infrastructure de réseau physique (réseau(x) d'accès, réseau cœur, etc.). Par le biais de ces réseaux logiques virtuels, les opérateurs sont capables de fournir à leurs clients des solutions optimisées pour des scénarii variés correspondant à des contraintes diverses en termes de fonctionnalités, de performances et de qualités de service.
[0005] La virtualisation de fonctions réseau ou NFV s'appuie sur des serveurs standards pour exécuter des logiciels de services réseau (aussi appelées fonctions réseau ou NFs pour « Network Functions » en anglais), tandis que le réseau défini par logiciel ou SDN centralise le contrôle du réseau 5G par logiciel plutôt que via des équipements physiques. Grâce à cette virtualisation, les fonctions réseau peuvent être déployées et reconfigurées aisément, apportant ainsi plus d'élasticité.
[0006] Diverses fonctions réseau d'un réseau cœur 5G peuvent être ainsi virtualisées, comme par exemple les fonctions réseau de gestion de l'accès et de la mobilité ou AMF (pour « Access Mobility Management Function » en anglais), de gestion de session ou SMF (pour « Session Management Function » en anglais), de sélection de tranche réseau ou NSSF (pour « Network Slice Sélection Function » en anglais), de contrôle des politiques ou PCF (pour « Policy Control Function » en anglais), etc. Le contrôle de ces fonctions virtualisées dans le réseau cœur 5G est assuré par une autre fonction réseau appelée catalogue de fonctions réseau ou NRF (ou « Network Repository Function » en anglais). Cette fonction NRF est chargée de fournir à une fonction réseau cliente ou consommatrice (« consumer » en anglais) les informations lui permettant d'interagir, directement ou indirectement via un équipement intermédiaire (ou SCP pour « Service Communication Proxy » en anglais) avec une fonction réseau serveur (« producer » en anglais) proposant un ou plusieurs services dans le réseau.
[0007] En effet, l'architecture de réseau 5G définie par le standard 3GPP est une architecture basée sur le service (ou SBA pour « Service Based Architecture » en anglais). Selon une telle architecture, les fonctionnalités d'un réseau 5G sont assurées par une pluralité de fonctions réseau (ou indifféremment fonctions NF dans la suite de la description) virtuelles qui fournissent des services à d'autres fonctions du réseau autorisées à accéder à ces services, une même fonction réseau pouvant offrir un ou plusieurs services. A cet effet, les fonctions NF du réseau cœur 5G présentent les services qu'elles offrent dans le contexte du cœur de réseau 5G (autrement dit leurs fonctionnalités) par l'intermédiaire d'interfaces se présentant sous forme d'APIs (pour « Application Programming Interfaces » en anglais) que les autres fonctions NF autorisées peuvent invoquer. Toutefois, au lieu d'interfaces prédéfinies entre les différentes fonctions NF pouvant interagir entre elles, un modèle de service est utilisé dans lequel les fonctions NF « consumer » interrogent la fonction réseau NRF pour découvrir les fonctions NF « producer » et communiquer avec elles sur les APIs qu'elles offrent. Ceci offre avantageusement aux opérateurs des réseaux 5G une grande flexibilité et une grande adaptabilité.
[0008] La fonction réseau NRF est ainsi un catalogue gérant une pluralité de fonctions NF, et mémorisant les profils de chacune de ces fonctions NF. Chaque profil comprend une pluralité d'attributs, caractérisant l'état opérationnel de la fonction NF (ex. sa disponibilité, sa charge, depuis quand elle a démarré, etc.), ses caractéristiques (ex. type de fonction NF, comment elle peut être jointe, etc.), les services qu'elle offre, les ressources qu'elle gère, etc. Des attributs peuvent être définis également plus spécifiquement au niveau de chaque service (sinon ce sont ceux définis au niveau de la fonction NF qui s'appliquent). Ces profils permettent aux fonctions NF « consumer » de découvrir les fournisseurs de services et de caractéristiques particuliers dans le réseau.
[0009] La fonction réseau NRF est mise à jour lors de l'activation et de la désactivation de chacune des fonctions NF qu'elle gère (i.e. lors de l'enregistrement et du désenregistrement de chacune d'entre elles) ainsi qu'à chaque redimensionnement d'une fonction NF (la fonction NRF peut gérer en effet plusieurs instances d'une même fonction NF). Elle propose aux fonctions NF du réseau cœur 5G différents services décrits notamment dans le document 3GPP TS 29.510 intitulé « Technical Spécification Group Core Network and Terminais; 5G System; Network Function Repository Services; Stage 3 », nΐd.6.0, décembre 2020, à savoir : un service de découverte (service « Nnrf_NFDiscovery ») permettant à une fonction NF « consumer » de découvrir les instances d'une fonction NF « producer » offrant des services répondant à ses besoins ; un service de gestion (service « Nnrf_NFManagement »), assurant des opérations d'enregistrement, de désenregistrement et de mise à jour, et permettant à la fonction NRF d'être informée des instances de fonctions NF « producer » disponibles et des services offerts par ces fonctions NF ; un service d'autorisation de service (service « Nnrf_AccessToken »), permettant de s'assurer qu'une fonction NF « consumer » est autorisée à accéder aux services offerts par une fonction NF « producer ».
[0010] Le standard 3GPP définit également une procédure de souscription via laquelle une fonction NF « consumer » peut demander à la fonction NRF d'être informée de tout changement affectant une fonction NF « producer » (par exemple, disponibilité d'une nouvelle instance, mise à jour d'un attribut du profil d'une fonction NF, etc.). La Release 16 décrit aussi une procédure d'amorçage « Nnrf_Boos- trapping » permettant la découverte des services proposés par une fonction NRF par les entités NF du réseau cœur 5G ou par d'autres entités NRF appartenant au même réseau ou à un réseau (PLMN) différent.
[0011] La figure 1, extraite du document de Joe Wilke intitulé « 5G Network Architecture and FMC », IMT- 2020/5G Workshop and Demo Day seminar, juillet 2017, illustre de façon schématique l'interface (API) basée sur le service (ou SBI pour « Service Based Interface » en anglais) mise en œuvre entre deux fonctions réseau NF A et NF B dans un réseau 5G conformément au standard 3GPP. Ces fonctions réseau sont tour à tour, en fonction du service considéré, « consumer » et « producer », et échangent entre elles en utilisant des méthodes spécifiques conformes au protocole client-serveur HTTP (« HyperText Transfer Protocol ») s'appuyant par exemple sur des requêtes GET, POST, PUT ou encore PATCH et les réponses associées, ces méthodes pouvant comprendre de façon optionnelle des paramètres en entête et des corps spécifiques, et visant des ressources spécifiques identifiées respectivement par des identifiants de ressources uniformes ou URI (pour « Uniform Resource Identifier » en anglais). Ces éléments spécifiques (ressources, méthodes HTTP, paramètres d'entête, structures du corps dans les requêtes ou les réponses) sont définis plus spécifiquement dans les documents 3GPP décrivant plus spécifiquement les fonctions NF.
[0012] Les ressources du réseau cœur 5G ne sont pas extensibles indéfiniment, notamment pour ce qui concerne la bande passante et la capacité des fonctions NF de type « producers » (en nombre fixe) à traiter les requêtes HTTP émises par les fonctions NF de type « consumers ». Ainsi, en optimisant le trafic HTTP échangé entre les fonctions NF à bande passante constante, on améliore les performances du réseau cœur 5G, et plus particulièrement sa capacité à absorber du trafic ainsi que sa latence.
[0013] Comme évoqué ci-dessus, le réseau cœur 5G utilise le protocole client-serveur HTTP pour ce qui est des échanges entre les fonctions NF, et plus particulièrement le protocole HTTP/2. De façon connue en soi, le protocole HTTP/2 est une évolution majeure du protocole HTTP/1.1 : il a été conçu pour réduire la latence et rendre les échanges plus sûrs, tout en restant compatible avec la version HTTP/1.1. A cet effet, il offre de nouvelles fonctionnalités comme notamment la possibilité le multiplexage des requêtes et des réponses, la compression des entêtes HTTP, ou encore la transmission des données en binaire. Il est important toutefois de noter que le protocole HTTP/2 ne modifie pas la sémantique applicative du protocole HTTP de quelle que manière que ce soit. Tous les concepts de base du protocole HTTP, telles que les méthodes, les codes d'état, les URIs, les champs des entêtes sont conservés. En revanche, le protocole HTTP/2 modifie comment les données sont formatées et transportées entre un client et un serveur. Grâce en particulier à la compression des entêtes des requêtes et des réponses, le protocole HTTP/2 permet de réduire et d'optimiser le volume de données transmises par rapport au protocole HTTP/1.1. On note que le corps des requêtes et des réponses reste le cas échéant conforme au protocole HTTP/1.1. Celui-ci est décrit en détail notamment dans le document IETF RFC 2616 intitulé « Hypertext Transfer Protocol - HTTP/1.1 », juin 1999.
[0014] De façon connue en soi, le protocole HTTP est un protocole initialement développé pour le web. L'optimisation de l'encodage des contenus échangés par l'intermédiaire du protocole HTTP (ex. texte, images, polices, etc.), et plus particulièrement la compression de ces contenus, est un facteur clé aujourd'hui prôné par les acteurs du web pour réduire la latence et la consommation de la bande passante, et améliorer sensiblement l'expérience utilisateur. Le réseau cœur 5G s'appuyant sur le protocole HTTP comme le web, il est envisagé d'appliquer les bonnes pratiques issues du web en la matière aux échanges se tenant notamment entre les fonctions NF au sein du réseau cœur 5G. En effet, à titre indicatif, la charge utile d'un profil d'une fonction NF fournie dans une requête adressée lors de l'enregistrement d'une fonction NF ou dans une réponse fournie par la fonction NRF lors du mécanisme de découverte ou encore dans une notification envoyée par la fonction NRF lorsqu'un profil d'une fonction NF est mis à jour, peut facilement avoisiner les 2 mégaoctets, ce qui, rapporté aux nombres de ces messages échangés sur le réseau cœur 5G, peut constituer une charge totale importante. Par ailleurs, les APIs des services offerts par les fonctions NF d'un réseau cœur 5G comportent des dizaines d'opérations utilisant des requêtes HTTP de type POST, PUT ou PATCH comprenant un corps comportant un contenu, et ce nombre d'opérations est en constante augmentation. Un gain de réduction de la taille des contenus échangés de quelques pourcents voire plus via l'utilisation d'un encodage mettant en œuvre une compression des données aurait un impact non négligeable sur la bande passante et sur la latence du réseau pour toutes ces opérations.
[0015] Conformément au protocole HTTP/1.1, lors d'un échange entre un client et un serveur, le client peut indiquer dans la requête qu'il émet à destination du serveur, et plus particulièrement dans un entête « Accept-Encoding » de la requête, les différents types d'encodage (« encoding » en anglais) qu'il supporte (par exemple un encodage mettant en œuvre une compression des données). Le serveur retourne alors une réponse au client dont le corps est conforme aux indications d'encodage fournies par le client. Le serveur indique quant à lui, dans un entête « Content-Encoding » de sa réponse, le type (ou format) d'encodage (et plus particulièrement de compression) appliqué au contenu servi au client. La négociation de l'encodage, lorsqu'elle est mise en œuvre, est donc à l'initiative du client et ne concerne que la réponse envoyée par le serveur au client. Le client n'a aucun moyen de savoir préalablement à la réception de la réponse du serveur quel format d'encodage ce dernier supporte.
[0016] Dans le contexte des réseaux 5G, avant la Release 15.4.0, aucune négociation d'encodage n'est définie au niveau des interfaces APIs des fonctions NF. Dans la Release 15.4.0, le standard 3GPP introduit des règles d'ordre général pour la négociation d'encodage décrites notamment dans le document 3GPPP TS 29.500V15.4.0, juin 2019, intitulé « Technical Spécification Group Core Network and Terminais; 5G System; Technical Realization of Service Based Architecture; Stage 3 (Release 15) ». Selon ces règles : une fonction NF « consumer » peut déterminer les formats d'encodage supportés par une fonction NF « producer » en lui envoyant une requête de type OPTIONS, les formats d'encodage supportés par la fonction NF « producer » lui étant retournés dans la réponse à la requête OPTIONS ; une fonction NF « producer » peut retourner un entête « Accept-Encoding » tel que décrit précédemment contenant les formats d'encodage qu'elle supporte dans une réponse, par exemple une réponse à une requête comportant un corps telle qu'une requête HTTP POST, PUT ou PATCH. La fonction NF « consumer » peut alors utiliser l'un des formats d'encodage fournis par la fonction NF « producer » pour encoder le corps le cas échéant de sa prochaine requête adressée à la fonction NF « producer ».
[0017] Une requête OPTIONS n'a toutefois été mise en œuvre par le standard 3GPP que pour le service Nnrf_NFManagement (qui comprend les opérations d'enregistrement, de désenregistrement et de mise à jour évoquées précédemment) supporté par la fonction réseau NRF. Une généralisation de cette solution imposerait de mettre en œuvre la requête OPTIONS pour toutes les ressources des différentes interfaces APIs de toutes les fonctions NF (actuellement définies et futures) comportant des requêtes HTTP pouvant mettre en œuvre un encodage de leur contenu, et plus particulièrement les requêtes HTTP POST, PUT et PATCH. Ceci aurait pour conséquence non seulement une lourdeur de maintenance des spécifications du réseau cœur 5G, mais également une augmentation du volume de la signalisation échangée dans le réseau cœur (une transaction dédiée pour chaque ressource sur chaque API), et la prise en compte d'une logique additionnelle pour chaque fonction NF « consumer ».
[0018] L'autre solution proposée par le standard 3GPP (ajout d'un entête « Accept-Encoding » dans une réponse) est utilisée dans la Release 16 pour des services offerts par les fonctions réseau NSSF (service Nnssf_NSSAIAvailability) et NRF (services Nnrf_NFManagement, Nnrf_NFDiscovery, Nnrf_AccessToken). Toutefois, comme la solution précédente, la généralisation de cette solution imposerait de modifier toutes les APIs des fonctions NF actuelles et futures du réseau cœur 5G. En outre, elle ne permet malheureusement pas à une fonction « consumer » de tenir compte des formats d'encodage supportés par une fonction « producer » dans la première requête adressée par la fonction « consumer » à la fonction « producer » (l'entête « Accept-Encoding » n'étant fourni qu'en réponse à cette première requête).
[0019] L'application des solutions proposées actuellement par le standard 3GPP à l'ensemble des fonctions NF du réseau cœur 5G, et à l'ensemble des services proposés par ces fonctions NF, paraît donc difficilement envisageable.
Exposé de l'invention
[0020] L'invention offre une solution ne présentant pas de tels inconvénients, et pouvant être aisément appliquée notamment dans le contexte d'un réseau 5G tel que défini par le standard 3GPP. [0021] Il convient toutefois de noter que bien qu'introduite en référence à un réseau 5G, à des fonctions réseau virtuelles et au protocole HTTP/2, ces hypothèses ne sont nullement limitatives de l'invention et celle-ci peut être utilisée dans d'autres contextes. Par exemple, elle peut être utilisée dans d'autres réseaux qu'un réseau 5G, s'appuyant sur des procédures d'enregistrement et de découverte de services, tels que des architectures micro-services déployées dans un système informatique en nuage ou plus communément « cloud » en anglais. Un exemple d'une telle architecture est la solution de service mesh Consul proposée par la société Hashicorp.
[0022] L'invention s'applique également à d'autres protocoles que le protocole HTTP/2 tels qu'une autre version du protocole HTTP (HTTP/1.1), ou aux protocoles SOAP (pour « Simple Object Access Protocol » en anglais), CORBA (pour « Common Object Request Broker Architecture » en anglais), gRPC (pour « Remote Procedure Call » en anglais), QUIC, etc., ou à tout autre protocole basé sur l'échange de requêtes et de réponses, et supportant un encodage du contenu du corps des requêtes et/ou des réponses, typiquement une compression de ce contenu. L'invention s'applique de manière générale à toute entité applicative (physique ou virtuelle) offrant un ou plusieurs services dans un réseau et susceptible de mettre en œuvre différents types ou formats d'encodage (et les décodages associés) pour encoder (et décoder), et notamment compresser, des contenus dans le cadre de ces services. Par exemple, une entité applicative au sens de l'invention peut être une instance virtuelle d'une fonction réseau d'un type donné.
[0023] En outre, l'invention ne se limite pas à des encodages permettant de compresser des contenus, même si elle est particulièrement avantageuse dans ce contexte pour optimiser les performances et la latence d'un réseau comme évoqué ci-dessus. On peut envisager également d'autres formats d'encodage, comme par exemple un format d'encodage invariant (correspondant au maintien à l'identique du contenu), un encodage base64, ou toute transformation réversible réalisée dans un but particulier (ex. réduire la taille d'un contenu, obtenir un contenu compatible avec la majorité des systèmes, sécuriser un contenu, etc.), etc.
[0024] Plus spécifiquement, l'invention propose un procédé de gestion, par une entité de contrôle d'un réseau, d'une pluralité d'entités applicatives proposant des services dans le réseau, ledit procédé de gestion comprenant : une étape de réception en provenance d'une première entité d'une requête d'amorçage visant à découvrir des services proposés par l'entité de contrôle et/ou des ressources gérées par celle- ci ; et une étape d'envoi d'une réponse à ladite requête d'amorçage de ladite première entité, ladite réponse comprenant en outre au moins un format d'encodage supporté par l'entité de contrôle.
[0025] Corrélativement, l'invention vise aussi une entité de contrôle d'un réseau gérant une pluralité d'entités applicatives proposant des services dans le réseau, ladite entité de contrôle comprenant un module d'amorçage, configuré pour, en réponse à une requête dite d'amorçage provenant d'une première entité et visant à découvrir des services proposés par l'entité de contrôle et/ou des ressources gérées par celle-ci, fournir à cette première entité une réponse à ladite requête d'amorçage, ladite réponse comprenant en outre au moins un format d'encodage supporté par l'entité de contrôle.
[0026] Par entité applicative, on entend toute entité communicante (aussi appelée entité de communication ici) configurée pour mettre en œuvre une logique de traitement déterminée, comme par exemple une entité offrant et/ou consommant des services dans un réseau telle qu'une fonction réseau ou une instance de fonction réseau, etc. On note qu'une entité applicative peut être une entité de réseau (i.e. qui a une fonctionnalité donnée dans un réseau), mais il peut s'agir également d'un équipement utilisateur (ou UE pour « User Equipment » en anglais).
[0027] La première entité peut être par exemple une autre entité de contrôle, pouvant appartenir à un réseau (ou PLMN pour « Public Land Mobile Network » en anglais) différent de l'entité de contrôle, ou une entité applicative qui veut accéder aux services proposés par l'entité de contrôle, et notam ment aux services d'enregistrement, de souscription ou de découverte offerts par cette dernière, etc.
[0028] Avantageusement, outre les services proposés par l'entité de contrôle et les ressources gérées par celle-ci (ex. services d'enregistrement, de découverte, de notification, etc.), la réponse adressée par l'entité de contrôle à la requête d'amorçage qu'elle reçoit de la première entité contient les formats d'encodage supportés par l'entité de contrôle. Cela permet à la première entité d'utiliser l'un de ces formats dès qu'elle envoie une requête à l'entité de contrôle pour accéder à l'un des services offerts par cette dernière. A titre d'exemple, si la première entité est une entité applicative dépendant de l'entité de contrôle, cela permet à l'entité applicative lorsqu'elle s'enregistre auprès de l'entité de contrôle, d'utiliser pour fournir son profil l'un des formats d'encodage supportés par l'entité de con trôle. Les échanges entre l'entité applicative et l'entité de contrôle sont donc optimisés.
[0029] L'invention est aisément compatible avec la Release 16 du standard 3GPP et en particulier avec la procédure d'amorçage Nnrf_Boostrapping permettant la découverte des services proposés par une fonction NRF par les entités NF du réseau cœur 5G ou par d'autres entités NRF appartenant au même réseau ou à un réseau (PLMN) différent.
[0030] Dans un mode particulier de réalisation, le procédé de gestion comprend en outre : une étape d'enregistrement de chaque entité applicative gérée par l'entité de contrôle comprenant une mémorisation d'un profil de ladite entité applicative, ce profil comprenant une pluralité d'attributs incluant au moins un format d'encodage supporté par ladite entité applicative et pouvant être utilisé lors d'un accès à un service proposé par elle ; et en réponse à une requête en provenance d'une deuxième entité, une étape de fourniture à cette deuxième entité, pour au moins une dite entité applicative gérée par l'entité de contrôle, d'au moins une partie de la pluralité d'attributs du profil de cette entité applicative, ladite partie comprenant ledit au moins un format d'encodage supporté par cette entité applicative.
[0031] Corrélativement, l'entité de contrôle d'un réseau comprend en outre : un module d'enregistrement, configuré pour enregistrer chaque entité applicative gérée par l'entité de contrôle, ledit module d'enregistrement étant configuré pour mémoriser lors de l'enregistrement d'une entité applicative un profil de cette entité applicative comprenant une pluralité d'attributs incluant au moins un format d'encodage supporté par ladite entité applicative et pouvant être utilisé lors d'un accès à un service proposé par elle ; et un module de publication activé en réponse à une requête en provenance d'une deuxième entité, et configuré pour fournir à cette deuxième entité, pour au moins une dite entité applicative gérée par l'entité de contrôle, au moins une partie de la pluralité d'attributs du profil de cette entité applicative, ladite partie comprenant ledit au moins un format d'encodage supporté par cette entité applicative.
[0032] La requête déclenchant la publication de tout ou partie du profil d'une entité applicative gérée par l'entité de contrôle auprès d'une autre entité (deuxième entité au sens de l'invention) peut être notamment une requête de découverte d'au moins une entité applicative gérée par l'entité de con trôle répondant par exemple à au moins un critère déterminé spécifié implicitement ou explicitement dans la requête de découverte (ex. entités applicatives proposant un service donné, assurant une fonction réseau donnée, etc.).
[0033] Aucune limitation n'est attachée à la nature de la deuxième entité. Il peut s'agir par exemple d'une autre entité applicative, gérée par l'entité de contrôle ou par une autre entité de contrôle, d'une autre entité de contrôle, d'un équipement intermédiaire tel qu'un SCP agissant par exemple pour le compte d'une autre entité applicative, ou encore d'une entité du réseau situé en périphérie du réseau cœur, d'un équipement utilisateur, etc. La deuxième entité peut appartenir ou non au même réseau que l'entité de contrôle. Dans le cas d'un réseau mettant en œuvre un découpage en tranches (ou « slicing »), la deuxième entité, l'entité de contrôle et les entités applicatives peuvent appartenir à des tranches de réseau différentes.
[0034] Ainsi, l'invention propose d'intégrer, parmi les attributs listés dans le profil d'une entité applicative de type « producer » et fournis par cette dernière à l'entité de contrôle qui la gère lors de son enregistrement, le ou les différents formats d'encodage qu'elle supporte. Ceci permet avantageusement à l'entité de contrôle d'être en mesure de publier auprès des entités « consumer » du réseau ou externes au réseau, intéressées par les services fournis par l'entité applicative « producer » et qui la sollicitent, ce ou ces formats d'encodage, et ce, en préliminaire de tout échange entre les entités « consumer » et l'entité applicative « producer ». De cette sorte, une entité « consumer » peut appliquer, dès la première requête qu'elle envoie à l'entité « producer » dans le cadre de l'accès à un service offert par celle-ci, l'un des formats d'encodage supportés par l'entité « producer ». Il convient de noter qu'au vu des bonnes pratiques rappelées précédemment, le support de formats d'encodage mettant en œuvre une compression de données est courant. De tels formats d'encodage sont par exemple gzip, compress, deflate. L'invention permet ainsi d'optimiser l'ensemble des échanges entre l'entité « consumer » et l'entité « producer », notamment en termes de bande passante et de latence.
[0035] En outre, de façon particulièrement avantageuse, le ou les formats d'encodage ainsi publiés peuvent être des attributs considérés par l'entité « consumer » pour sélectionner une entité « producer » parmi plusieurs offrant un même service, ce qui permet d'optimiser encore davantage les performances du réseau.
[0036] Ce peut être également un critère de recherche utilisé par une entité « consumer » lors de la découverte d'entités applicatives « producer », par exemple en complément ou en remplacement de critères plus fonctionnels.
[0037] Dans le contexte plus spécifique d'un réseau 5G tel que défini par le standard 3GPP, les entités applicatives sont par exemple des fonctions NF, l'entité de contrôle, une fonction réseau NRF, et la deuxième entité, une autre fonction NF, une autre fonction de contrôle (appartenant ou non au même réseau que l'entité de contrôle) ou un équipement intermédiaire SCP. La solution proposée par l'invention permet avantageusement d'éviter une définition laborieuse des interfaces APIs et/ou une lourdeur de maintenance des spécifications du réseau 5G. Elle requiert en effet uniquement la mise à jour des attributs listés dans le profil d'une fonction NF qui sont mémorisés par la fonction NRF, et publiés par cette dernière lors de procédures de découverte visant (directement ou indirectement) la fonction NF. Comme cette procédure de découverte est mise en œuvre en préliminaire de tout échange avec la fonction NF conformément au standard 3GPP, elle n'entraîne aucune logique supplémentaire ni aucun échange de messages supplémentaire (contrairement à la solution basée sur l'envoi d'une requête OPTIONS) au niveau du réseau. La mise en œuvre de l'invention s'intégre donc parfaitement dans la logique du réseau cœur 5G utilisant une fonction NRF et dans les procédures définies d'enregistrement des profils des fonctions NF auprès de la fonction NRF, de découverte des fonctions NF « producer » par les fonctions NF « consumer », et ce, notamment, dans les Releases 15 et 16, ou dans de futures Releases reprenant ces procédures ou des procédures similaires. Il en découle une facilité d'implémentation de l'invention pour les équipementiers, mais également de configuration pour les opérateurs des réseaux cœurs. L'invention offre ainsi une solution générale et pérenne, qui peut s'appliquer à toute opération d'un service offert par une entité applicative, et en particulier par une fonction réseau virtuelle, existante ou future, dans un réseau cœur 5G.
[0038] Dans un mode particulier de réalisation, le procédé de gestion comprend en outre : une étape de réception d'une demande de souscription, en provenance d'une troisième entité, pour recevoir des informations concernant au moins un événement affectant au moins un profil mémorisé par l'entité de contrôle, cette souscription indiquant au moins un format d'encodage supporté par la troisième entité ; et suite à une détection d'un évènement correspondant à ladite demande de souscription, une étape de notification de ladite troisième entité comprenant des informations relatives audit événement détecté encodées au moyen d'un dit format d'encodage supporté par la troisième entité et indiqué dans la demande de souscription.
[0039] Il convient de noter que les deuxième et troisième entités peuvent être une seule et même entité communicante (physique ou logicielle), ou être des entités distinctes. Elles peuvent appartenir au même réseau ou à des réseaux distincts. Comme pour la deuxième entité, la troisième entité peut être une entité applicative gérée par l'entité de contrôle ou par une autre entité de contrôle, une autre entité de contrôle, un équipement SCP, un équipement utilisateur, etc. En outre, la première entité peut être distincte ou non des deuxième et/ou troisième entités.
[0040] Ce mode de réalisation permet d'optimiser également la transmission des notifications émises de façon asynchrone par l'entité de contrôle pour signaler divers événements affectant les profils des entités applicatives qu'elle gère, aux entités qui lui ont signalé leur intérêt pour ces événements via un mécanisme de souscription connu en soi. De tels événements sont par exemple la création, la modification ou encore la suppression d'un profil d'une entité applicative.
[0041] L'invention selon ce mode de réalisation propose avantageusement que lors de la souscription, la troisième entité indique le ou les formats d'encodage qu'elle supporte pour que l'entité de contrôle puisse exploiter ces formats d'encodage lorsqu'elle lui envoie des notifications. Suivant l'événement à l'origine de la notification et la configuration de l'entité de contrôle, une telle notification peut comprendre un ou plusieurs profils en tout ou partie (ex. partie publiée par l'entité de contrôle) ou seulement le cas échéant, les attributs du profil affectés par l'événement. L'application d'un format d'encodage aux informations véhiculées par les notifications, compte tenu du nombre important de notifications susceptibles d'être envoyées par une entité de contrôle et du volume de données véhiculé par chacune d'entre elle, est donc particulièrement avantageuse en matière de latence et de bande passante.
[0042] Il convient de noter que ce mode de réalisation est avantageux que la troisième entité du réseau soit gérée ou non par l'entité de contrôle, notamment dans le contexte du standard 3GPP. En effet, l'entité de contrôle connaît pour les entités applicatives qu'elle gère, les services offerts par ces entités applicatives en tant que « producers » (i.e. en tant que fournisseurs de services) et les attributs associés à ces services (et donc conformément à l'invention, les formats d'encodage supportés par ces services). Mais lorsqu'une entité communicante souscrit à un service de notification d'événements relatifs aux profils gérés par l'entité de contrôle, cette entité agit en tant que « consumer » (i.e. en tant que consommateur du service de notification). Par conséquent, quand bien même cette entité est une entité applicative enregistrée auprès de l'entité de contrôle, l'entité de contrôle ne connaît pas les formats d'encodage supportés par cette dernière en tant que « consumer ». Le mode de réalisation qui vient d'être décrit permet à l'entité de contrôle de mémoriser cette information, par exemple dans le contexte de souscription associé à l'entité en question, pour une utilisation lors de futures notifications le cas échéant. Le stockage de cette information dans le contexte de souscription évite d'avoir à gérer et à mettre à jour cette information via une nouvelle logique de traitement. Les formats d'encodage stockés dans le profil et dans le contexte de souscription héritent en effet de façon avantageuse des mécanismes déjà existants mis en œuvre dans le réseau pour la gestion des autres attributs contenus dans le profil et des autres informations de souscription. L'invention est donc particulièrement simple à mettre en œuvre.
[0043] Aucune limitation n'est attachée à la façon dont la troisième entité signale le ou les formats d'encodage qu'elle supporte lors de la souscription auprès de l'entité de contrôle. Ils peuvent par exemple être indiqués dans le corps de la requête de souscription avec les autres informations de souscription, dans un champ prévu à cet effet.
[0044] Comme il apparaît au vu de ce qui précède, l'invention s'appuie sur l'enregistrement et la publication par l'entité de contrôle des formats d'encodage supportés par les entités applicatives qu'elle gère, mais également sur ces entités applicatives qui, lors de leur enregistrement auprès de l'entité de contrôle, lui fournissent les formats d'encodage qu'elles supportent, ainsi que sur l'entité qui est informée de ces formats d'encodage et est en mesure de les exploiter dès ses premiers échanges avec les entités applicatives.
[0045] Ainsi, selon un autre aspect, l'invention vise également un procédé de découverte par une entité de services proposés et/ou de ressources gérées par une entité de contrôle d'un réseau gérant une pluralité d'entités applicatives proposant des services dans le réseau, ledit procédé de découverte comprenant : une étape d'envoi d'une requête d'amorçage à ladite entité de contrôle visant à découvrir des services qu'elle propose et/ou des ressources gérées par celle-ci ; une étape de réception d'une réponse à ladite requête d'amorçage comprenant en outre au moins un format d'encodage supporté par l'entité de contrôle.
[0046] L'invention vise aussi un procédé d'enregistrement d'une entité applicative proposant au moins un service dans un réseau, auprès d'une entité de contrôle du réseau gérant une pluralité d'entités applicatives proposant des services dans le réseau, ledit procédé d'enregistrement comprenant : une étape de découverte des services et/ou ressources gérées par l'entité de contrôle du réseau utilisant un procédé de découverte selon l'invention ; et une étape d'enregistrement de l'entité applicative auprès de l'entité de contrôle comprenant une fourniture par ladite entité applicative à l'entité de contrôle d'un profil de ladite entité applicative, ce profil comprenant une pluralité d'attributs incluant au moins un format d'encodage supporté par ladite entité applicative et pouvant être utilisé lors d'un accès à un service proposé par elle, ladite entité de contrôle étant configurée pour fournir au moins une partie de ladite pluralité d'attributs du profil de l'entité applicative, ladite partie comprenant ledit au moins un format d'encodage, en réponse à une requête en provenance d'une autre entité.
[0047] Corrélativement, l'invention concerne aussi une entité applicative d'un réseau proposant au moins un service dans le réseau, ladite entité applicative comprenant : un module de découverte, configuré pour envoyer une requête dite d'amorçage à une entité de contrôle du réseau gérant une pluralité d'entités applicatives proposant des services dans le réseau, ladite requête d'amorçage visant à découvrir des services offerts et/ou ressources gérées par ladite entité de contrôle, ledit module de découverte étant en outre configuré pour recevoir une réponse à ladite requête d'amorçage comprenant lesdits services offerts et/ou ressources gérées par ladite entité de contrôle et au moins un format d'encodage supporté par ladite entité de contrôle ; et un module d'enregistrement configuré pour enregistrer ladite entité applicative auprès de ladite entité de contrôle du réseau, ledit module d'enregistrement étant configuré pour fournir à l'entité de contrôle lors dudit enregistrement un profil de ladite entité applicative, ce profil comprenant une pluralité d'attributs incluant au moins un format d'encodage supporté par ladite entité applicative et pouvant être utilisé lors d'un accès à un service proposé par elle, ladite entité de contrôle étant configurée pour fournir au moins une partie de ladite pluralité d'attributs du profil de l'entité applicative, ladite partie comprenant ledit au moins un format d'encodage, en réponse à une requête en provenance d'une autre entité.
Dans un mode particulier de réalisation, un dit format d'encodage supporté par l'entité de contrôle est utilisé lors de l'enregistrement par ladite entité applicative pour encoder le profil fourni à l'entité de contrôle.
[0048] Selon un autre aspect encore, l'invention vise un procédé de communication d'une entité dite « quatrième » entité avec une entité de contrôle du réseau gérant une pluralité d'entités applicatives proposant des services dans le réseau et mémorisant des profils de ces entités applicatives, ledit procédé de communication comprenant : une étape de découverte des services et/ou ressources gérées par l'entité de contrôle du réseau utilisant un procédé de découverte selon l'invention ; une première étape d'envoi à ladite entité de contrôle d'une requête de découverte d'entités applicatives gérées par l'entité de contrôle ; et une étape de réception d'une réponse à ladite requête de découverte indiquant au moins une entité applicative dite candidate gérée par l'entité de contrôle et une pluralité d'attributs de cette entité applicative candidate extraits d'un profil de l'entité applicative mémorisé par l'entité de contrôle, ladite pluralité d'attributs incluant au moins un format d'encodage supporté par cette entité applicative candidate et pouvant être utilisé lors d'un accès à un service proposé par elle.
[0049] Corrélativement, l'invention concerne également une entité dite « quatrième » entité comprenant : un premier module de communication configuré pour envoyer à une entité de contrôle du réseau gérant une pluralité d'entités applicatives proposant des services dans le réseau et mémorisant des profils desdites entités applicatives, une première requête de découverte d'entités applica tives gérées par l'entité de contrôle ; et un module de réception, configuré pour recevoir une réponse à ladite requête de découverte indiquant au moins une entité applicative dite candidate gérée par l'entité de contrôle et une pluralité d'attributs de cette entité applicative candidate extraits d'un profil de l'entité applicative mémorisé par l'entité de contrôle, ladite pluralité d'attributs incluant au moins un format d'enco dage supporté par cette entité applicative candidate et pouvant être utilisé lors d'un accès à un service proposé par elle.
[0050] Dans un mode particulier de réalisation, le procédé de communication comprend une deuxième étape d'envoi, à une dite entité applicative candidate indiquée dans la réponse reçue, d'une requête com prenant un contenu encodé au moyen d'un format d'encodage supporté par cette entité applicative candidate et indiqué dans la réponse reçue.
[0051] Corrélativement, la quatrième entité comprend, dans ce mode de réalisation, un deuxième module de communication, configuré pour envoyer à une dite entité applicative candidate indiquée dans la réponse reçue une deuxième requête comprenant un contenu encodé au moyen d'un format d'en codage supporté par ladite entité applicative candidate et indiqué dans la réponse reçue.
[0052] On note que la quatrième entité peut être l'une quelconque des première, deuxième et troisième entités évoquées précédemment ou une entité distincte. Il peut s'agir, comme pour les autres entités, d'une entité applicative, d'une entité de contrôle, ou de toute autre entité comme une entité de réseau ou un équipement utilisateur.
[0053] Ainsi, grâce à l'invention, la requête envoyée lors de la deuxième étape d'envoi est la première requête que la quatrième entité envoie à l'entité applicative candidate lors d'un accès à un service proposé par celle-ci.
[0054] La quatrième entité n'a effectivement pas besoin d'envoyer une requête supplémentaire (ex. requête OPTIONS) à l'entité applicative candidate pour connaître un format d'encodage supporté par celle- ci. Elle peut, dès la première requête envoyée à l'entité applicative candidate, exploiter un format d'encodage qu'elle sait supporter par l'entité applicative candidate pour encoder un contenu qu'elle lui destine.
[0055] L'entité applicative, la quatrième entité, le procédé d'enregistrement et le procédé de communication selon l'invention possèdent les mêmes avantages cités précédemment que le procédé de gestion et l'entité de contrôle selon l'invention.
[0056] Dans un mode particulier de réalisation dans lequel la réponse à la requête de découverte indique une pluralité d'entités applicatives candidates, l'entité applicative candidate à laquelle est envoyée la requête par la quatrième entité lors de la deuxième étape d'envoi est sélectionnée parmi ladite pluralité d'entités actives candidates en tenant compte des formats d'encodage respectifs supportés par cette pluralité d'entités applicatives candidates. [0057] Autrement dit, les formats d'encodage supportés par les entités applicatives découvertes par la qua trième entité (entités applicatives candidates au sens de l'invention) sont utilisés comme critère de sélection par la quatrième entité pour sélectionner une entité applicative parmi ces entités applica tives découvertes. La quatrième entité peut ainsi favoriser une entité applicative parmi plusieurs car elle supporte un format d'encodage non supporté par les autres ou plus avantageux pour optimiser ses communications. Bien entendu, ce critère peut être combiné à d'autres critères de sélection, comme par exemple le service assuré par l'entité applicative en question, sa fonction, sa disponibilité, etc.
[0058] Dans un mode particulier de réalisation, le procédé de communication comprend en outre une étape d'envoi d'une demande de souscription à l'entité de contrôle pour recevoir des infor mations concernant au moins un événement affectant au moins un profil mémorisé par l'entité de contrôle, cette demande de souscription indiquant au moins un format d'encodage supporté par la quatrième entité ; et suite à une détection d'un évènement correspondant à ladite demande de souscription, une étape de réception d'une notification en provenance de l'entité de contrôle comprenant des in formations relatives audit événement encodées au moyen d'un dit format d'encodage supporté par la quatrième entité et indiqué dans la demande de souscription.
[0059] Les avantages de ce mode de réalisation ont déjà été discutés précédemment pour l'entité de con trôle. Un événement affectant au moins un profil mémorisé par l'entité de contrôle peut être notam ment une création, une suppression ou une modification d'un tel profil.
[0060] Dans un mode de réalisation particulier de l'invention, au moins un dit format d'encodage supporté par une dite entité (entité applicative, première, deuxième, troisième ou quatrième entité ou entité de contrôle) vise un encodage d'un contenu transmis dans un corps d'une requête ou d'une réponse conforme à une version du protocole HTTP (HyperText Transfer Protocol).
[0061] Par ailleurs, au moins un dit format d'encodage est un format de compression de données.
[0062] L'invention s'applique notamment de façon privilégiée dans le contexte des réseaux 5G définis par le standard 3GPP au protocole HTTP/2, pour la compression des contenus des requêtes conformes à ce protocole échangées entre les différentes entités impliquées dans l'invention.
[0063] Toutefois comme évoqué précédemment, l'invention peut s'appliquer en association avec d'autres protocoles et d'autres formats d'encodage.
[0064] Dans un mode particulier de réalisation de l'invention, dans au moins un profil d'une entité applicative gérée par l'entité de contrôle, au moins un dit format d'encodage est fourni dans un attribut s'appli quant : à l'ensemble des services proposés par cette entité applicative ; ou à un service donné ou à une version donnée d'un service proposé par cette entité applicative ; ou à une ressource donnée gérée par un service offert par cette entité applicative ; ou à une opération donnée appliquée à une ressource gérée par un service offert par cette entité applicative.
[0065] Ce mode de réalisation s'applique aux différents procédés et entités objets de l'invention.
[0066] Il offre la possibilité de définir différents niveaux de granularité pour les formats d'encodage des contenus lors de la mise en œuvre de l'invention : par type d'entités applicatives gérées par l'entité de contrôle, par type de services ou par version de service offerts par une entité applicative, par type d'opérations au sein d'un service, ou encore par type de ressources gérées par les services offerts par une entité applicative. Le choix de l'une ou l'autre de ces options dépend du comportement de chaque entité applicative, selon si on souhaite un comportement homogène pour l'ensemble des services qu'elle offre et des ressources gérées par ces services, ou au contraire si on souhaite adapter les formats d'encodage en fonction des services (incluant les versions des services) et/ou des ressources. L'invention offre une grande flexibilité à ce niveau, qui peut en outre différer d'une entité applicative à une autre, d'un service à un autre, d'une ressource à une autre, etc.
[0067] Dans un mode de réalisation, au moins un dit format d'encodage supporté par une dite entité est inclus dans une structure de données comprenant au moins une option de communication supportée par cette entité.
[0068] Dans un mode particulier de réalisation de l'invention, les procédés de gestion, d'enregistrement et de communication sont mis en œuvre par un ordinateur.
[0069] L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans une entité de contrôle conforme à l'invention et comporte des instructions adaptées à la mise en œuvre d'un procédé de gestion tel que décrit ci-dessus.
[0070] L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans une entité applicative conforme à l'invention et comporte des instructions adaptées à la mise en œuvre d'un procédé d'enregistrement tel que décrit ci-dessus.
[0071] L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans une entité d'un réseau conforme à l'invention et comporte des instructions adaptées à la mise en œuvre d'un procédé de communication tel que décrit ci-dessus.
[0072] Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
[0073] L'invention vise aussi un support d'information ou un support d'enregistrement lisibles par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
[0074] Le support d'information ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash.
[0075] D'autre part, le support d'information ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.
[0076] Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
[0077] Alternativement, le support d'information ou d'enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés de gestion, d'enregistrement et de communication selon l'invention.
[0078] Selon un autre aspect encore, l'invention vise un système comprenant : au moins une entité applicative selon l'invention proposant au moins un service dans un réseau ; une entité de contrôle du réseau selon l'invention gérant ladite au moins une entité applicative ; et au moins une (quatrième) entité selon l'invention.
[0079] Le système bénéficie des mêmes avantages cités précédemment que les procédés de gestion, d'enregistrement et de communication, l'entité de contrôle, l'entité applicative et la quatrième entité selon l'invention.
[0080] On peut également envisager, dans d'autres modes de réalisation, que les procédés de gestion, d'enregistrement et de communication, l'entité de contrôle, l'entité applicative et la quatrième entité selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. Brève description des dessins
[0081] D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci- dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
[Fig. 1] la figure 1, déjà décrite, représente, l'interface SBI proposée par le standard 3GPP entre deux fonctions réseau N F ;
[Fig. 2] la figure 2 représente dans son environnement, un système d'un réseau selon l'invention dans un mode particulier de réalisation ;
[Fig. 3] la figure 3 représente schématiquement l'architecture matérielle d'un ordinateur pouvant héberger l'une quelconque des entités selon l'invention appartenant au système de la figure 2 ;
[Fig. 4] la figure 4 illustre des procédures d'amorçage et d'enregistrement mises en œuvre dans le système de la figure 2 et s'appuyant sur des étapes des procédés de gestion, d'enregistrement et de communication selon l'invention dans un mode particulier de réalisation ;
[Fig. 5] la figure 5 illustre une procédure de découverte mise en œuvre dans le système de la figure 2 et s'appuyant sur des étapes des procédés de gestion, d'enregistrement et de communication selon l'invention dans un mode particulier de réalisation ;
[Fig. 6] la figure 6 illustre une procédure de souscription mise en œuvre dans le système de la figure 2 et s'appuyant sur des étapes des procédés de gestion et de communication selon l'invention dans un mode particulier de réalisation.
Description de l'invention
[0082] La figure 2 représente, dans son environnement, un système 1 conforme à l'invention, dans un mode particulier de réalisation dans lequel le système 1 est intégré dans un réseau cœur CN d'un réseau de communications 5G tel que décrit dans le standard 3GPP.
[0083] Le système 1 regroupe plusieurs entités du réseau cœur CN, à savoir : une pluralité d'entités applicatives NF1 NF2,...,NFN, conformes à l'invention, N désignant un entier supérieur 1. Par entité applicative, on entend toute entité communicante (aussi appelée entité de communication ici) configurée pour mettre en œuvre une logique de traitement déterminée, comme par exemple une entité offrant et/ou consommant des services dans un réseau telle qu'une fonction réseau ou une instance de fonction réseau, etc. On note qu'une entité applicative peut être une entité de réseau (i.e. qui a une fonctionnalité donnée dans un réseau), mais il peut s'agir également d'un équipement utilisateur (ou UE pour « User Equipment » en anglais). Dans le mode de réalisation décrit ici, chaque entité applicative NF1, NF2,..., NFN propose un ou plusieurs services dans le réseau (ex. assure une ou plusieurs fonctionnalités déterminées du réseau). De telles entités applicatives (dites de type « producer ») sont, dans le mode de réalisation décrit ici, des instances de fonctions réseau (NF), connues en soi comme par exemple des instances de fonctions AMF, SMF, NSSF, PCF, etc. évoquées avant. Il s'agit d'instances virtualisées, autrement dit d'entités logicielles, qui exécutent diverses logiques de service permettant d'assurer les principales fonctions du réseau cœur (ex. gestion de la mobilité et de l'accès au réseau cœur, définition et application de politiques réseau, facturation, sélection de tranches réseau, etc.). Chaque service offert par une entité applicative peut comprendre une ou plusieurs opérations ; et une entité 2 de contrôle gérant ces entités applicatives NF1, NF2,..., NFN, conforme à l'invention. Dans le mode de réalisation décrit ici, l'entité 2 de contrôle est une fonction réseau NRF, autrement dit un catalogue mémorisant pour chacune des entités applicatives NF1,...,NFN, un profil référencé respectivement par NF_PROFl, NF_PROF2,...,NF_PROFN. Chaque profil comprend une pluralité d'attributs, caractérisant l'état opérationnel de l'entité applicative associée (ex. sa disponibilité, sa charge, depuis quand elle a démarré, etc.), ses caractéristiques (ex. type de fonction NF, comment elle peut être jointe, etc.), les services qu'elle offre, les ressources qu'elle gère, etc. L'entité 2 de contrôle propose elle-même une pluralité de services comprenant notamment des services de découverte, de gestion (incluant les opérations d'enregistrement/désenregistre- ment/mise à jour), et d'amorçage, qui reprennent par exemple respectivement la logique des services Nnrf_NFDiscovery, Nnrf_NFManagement et Nnrf_Boostrapping décrits notamment dans les documents 3GPP TS 23.502 intitulé « Technical Spécification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2; (Release 16) », V16.7.0, décembre 2020, et TS 29.510 intitulé « Technical Spécification Group Core Network and Terminais; 5G System; Network Function Repository Services; Stage 3 », V16.6.0, décembre 2020, aux aménagements près apportés par l'invention. Cette liste n'est pas exhaustive en soi et a pour seule visée d'identifier les services d'une entité NRF impactés par l'invention.
[0084] Dans le mode de réalisation décrit ici, le système 1 comprend également au moins une autre entité 3 communicante, conforme à l'invention. Aucune limitation n'est attachée à la nature de cette entité. Il peut s'agir indifféremment d'une autre entité applicative, gérée ou non par l'entité 2 de contrôle (autrement dit, l'entité 3 peut être l'une des entités applicatives NF1,...,NFN), d'un équipement intermédiaire de type SCP, d'une autre entité de contrôle de type NRF appartenant ou non au même réseau que l'entité 2 de contrôle, ou de toute autre entité de réseau ou encore d'un équipement d'utilisateur, etc. Dans le mode de réalisation décrit ici, cette entité 3 du réseau CN est une entité du réseau cœur CN, consommatrice (ou « consumer ») d'un ou de plusieurs services offerts par les entités applicatives NF1,...,NFN gérées par l'entité 2 de contrôle.
[0085] Les entités du système 1 sont, dans le mode de réalisation décrit ici, des entités logicielles, hébergées par des dispositifs physiques du réseau cœur CN, comme par exemple des serveurs. Ces serveurs ont ici l'architecture matérielle d'un ordinateur 4, telle que représentée schématiquement sur la figure 3.
[0086] L'ordinateur 4 comprend notamment un processeur 5, une mémoire vive 6, une mémoire morte 7, une mémoire non volatile 8, et des moyens de communication 9 permettant notamment aux entités du système 1 de communiquer entre elles et avec d'autres éléments le cas échéant du réseau cœur CN ou d'un autre réseau. Ces moyens de communication 9 s'appuient d'une part, sur une interface de communication filaire ou sans fil, connue en soi et non décrite plus en détail ici, mais également sur une ou plusieurs interfaces logicielles basées sur le service ou SBI. Ces interfaces logicielles sont des APIs qui utilisent ici le protocole HTTP/2.
[0087] La mémoire morte 7 de l'ordinateur 4 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 5 et sur lequel est enregistré(s) un ou plusieurs programmes d'ordinateur conformes à l'invention.
[0088] Plus spécifiquement, la mémoire morte 7 de l'ordinateur 4 comprend, lorsque l'ordinateur 4 héberge une entité applicative NFk, k=l,...,N conforme à l'invention, un enregistrement d'un programme d'ordinateur PROG-NFk, comportant des instructions définissant les principales étapes d'un procédé d'enregistrement selon l'invention.
[0089] Ce programme PROG-NFk définit des modules fonctionnels d'une entité applicative NFk, k=l,...,N selon l'invention qui s'appuient ou commandent les éléments matériels 5 à 9 de l'ordinateur 4 cités précédemment. Ces modules comprennent notamment dans le mode de réalisation décrit ici, comme illustré sur la figure 2 : un module NFk-A, configuré pour offrir un ou plusieurs services (ou fonctionnalités) dans le réseau CN par l'intermédiaire d'une interface SBI, par exemple à d'autres entités applicatives telles que d'autres fonctions réseau ou encore, dans l'exemple envisagé ici, à l'entité 3. Les services offerts par le module NFk-A dépendent bien entendu du type de l'entité applicative NFk considérée. Par exemple une entité applicative NFk de type AMF offre les services suivants : gestion de l'enregistrement des équipements utilisateurs, gestion de leur joignabilité, gestion des sessions, gestion de la mobilité des équipements utilisateurs, gestion de l'accès (autorisation, etc.), etc. ; un module NFk-B de découverte pour découvrir les services offerts par l'entité de contrôle auprès de laquelle l'entité applicative NFk doit s'enregistrer. Plus particulièrement dans l'exemple envisagé ici d'un réseau cœur 3GPP 5G, on suppose que l'entité applicative NFk est configurée avec une adresse de joignabilité de l'entité de contrôle auprès de laquelle elle doit s'enregistrer (l'entité 2 de contrôle ici), mais qu'elle ne connaît pas a priori les services supportés par cette entité de contrôle (par exemple le service de gestion des fonctions NF auprès duquel elle doit s'enregistrer), ni les ressources gérées par l'entité 2 de contrôle. Pour obtenir ces informations, le module NFk-B de découverte est configuré pour envoyer une requête dite d'amorçage à l'entité 2 de contrôle dont il connaît l'adresse, et obtenir une réponse à cette requête d'amorçage comprenant les services supportés par l'entité 2 de contrôle, les ressources qu'elle gère, ainsi qu'au moins un format d'encodage que l'entité 2 de contrôle supporte ; et un module d'enregistrement NFk-C configuré pour enregistrer l'entité applicative NFk auprès de l'entité 2 de contrôle du réseau cœur CN qui la gère. Le module d'enregistrement NFk-C est configuré pour fournir à l'entité 2 de contrôle lors de cet enregistrement un profil NF_PROFk de l'entité applicative NFk, encodé avec l'un des formats d'encodage fourni par l'entité 2 de contrôle en réponse à la requête d'amorçage. Le profil NF_PROFk comprend une pluralité d'attributs caractérisant l'entité applicative (ex. type, adresses de joignabilité, PMLN, etc.), un identifiant de cette entité applicative (identifiant de l'instance de la fonction réseau correspondante), son état (ex. enregistrée, non disponible), etc. Pour une entité applicative de type fonction NF comme dans l'exemple envisagé ici, de tels attributs comprennent notamment les attributs décrits dans le document 3GPP TS 29.510 cité précédemment. Conformément à l'invention, le profil NF_PROFk inclut en outre comme attribut(s) un ou plusieurs formats d'encodage supportés par l'entité applicative NFk, et pouvant être utilisés lors d'un accès via une interface SBI à un service proposé par celle-ci pour encoder les contenus des corps des requêtes et/ou des réponses HTTP/2 qui lui sont envoyées. En effet, selon l'invention, ce ou ces formats d'encodage font partie des attributs qui sont publiés par l'entité 2 de contrôle lors des procédures de découverte des entités applicatives, comme expliqué davantage ultérieurement. Ces formats d'encodage sont choisis parmi des formats d'encodage connus comme par exemple les formats de compression gzip, compress, deflate, ou encore le format invariant (« identity ») indiquant l'absence de transformation appliquée au contenu. Dans l'exemple envisagé ici, on suppose qu'un ou plusieurs profils comprennent au moins un format d'encodage de type format de compression.
[0090] Les fonctions assurées par les modules NFk-A, NFk-B et NFk-C sont décrites plus en détail ultérieurement, en référence aux étapes du procédé d'enregistrement selon l'invention.
[0091] De façon similaire, la mémoire morte 7 de l'ordinateur 4 comprend, lorsque l'ordinateur 4 héberge l'entité 2 de contrôle selon l'invention, un enregistrement d'un programme d'ordinateur PROG2, comportant des instructions définissant les principales étapes d'un procédé de gestion selon l'invention.
[0092] Ce programme PROG2 définit des modules fonctionnels de l'entité 2 de contrôle (fonction NRF dans l'exemple envisagé) qui s'appuient ou commandent les éléments matériels 5 à 9 de l'ordinateur 4 cités précédemment. Ces modules comprennent notamment, dans le mode de réalisation décrit ici, comme illustré sur la figure 2 : un module 2A d'enregistrement, configuré pour enregistrer chaque entité applicative NF1,...,NFN gérée par l'entité 2 de contrôle. Dans l'exemple envisagé ici où l'entité 2 de contrôle est une fonction réseau NRF, le module 2A d'enregistrement est par exemple configuré pour exécuter des opérations de la logique du service de gestion Nnrf_NFManagement défini par le standard 3GPP, aménagées pour tenir compte de l'invention. Ainsi, le module 2A d'enregistrement est configuré notamment pour mémoriser, lors de l'enregistrement d'une entité applicative NFk, k=l,...,N, son profil NF_PROFk tel que décrit ci-avant, qui comprend un ou plusieurs formats d'encodage supportés par l'entité applicative NFk ; et un module 2B de publication, activé en réponse à une requête en provenance d'une entité communicante (par exemple une requête de découverte en provenance de l'entité 3), et configuré pour fournir à cette entité (ou de façon équivalente, publier auprès de cette entité), pour au moins une entité applicative NFk gérée par l'entité 2 de contrôle, au moins une partie de la pluralité d'attributs du profil NF_PROFk de cette entité applicative. La publication opérée par le module 2B de publication vise ici des entités applicatives répondant à au moins un critère déterminé (ex. type d'entités applicatives), qui peut être indiqué dans la requête de découverte. Dans l'exemple de la fonction NRF envisagé ici, le module 2B de publication est plus particulièrement configuré pour exécuter par exemple les opérations de la logique du service de découverte Nnrf_NFDiscovery défini par le standard 3GPP, aménagées pour tenir compte de l'invention : plus spécifiquement, parmi les attributs du profil NF_PROFk qui sont publiés, outre les attributs indiqués dans le document TS 29.510 cité précédemment, figure ledit au moins un format d'encodage supporté par l'entité applicative NFk concernée.
[0093] Dans le mode de réalisation décrit ici, le programme PROG2 définit en outre les modules fonctionnels suivants : un module 2C de notification, configuré pour gérer les demandes de souscription d'entités (du réseau cœur CN ou extérieures au réseau cœur CN) en vue de recevoir des informations concernant des événements affectant les profils mémorisés par l'entité 2 de contrôle. Un tel événement est par exemple la création, la modification ou la suppression d'un ou de plusieurs profils gérés par l'entité 2 de contrôle. Dans l'exemple de la fonction NRF envisagé ici, le module 2C de notification est configuré pour exécuter par exemple des opérations de la logique du service de gestion Nnrf_NFManagement défini par le standard 3GPP, en complément de celles déjà exécutées par le module 2A, aménagées pour tenir compte de l'invention. Plus spécifiquement, conformément à l'invention, lorsqu'une entité communicante souscrit à un service de notification auprès de l'entité 2 de contrôle pour être informée à propos d'événements déterminés, elle lui fournit au moins un format d'encodage qu'elle supporte. Le module 2C de notification est alors configuré pour enregistrer dans un contexte CNT associé à la souscription de l'entité du réseau, le ou les événements indiqués lors de la souscription ainsi que le ou les formats d'encodage qui lui sont fournis, et pour appliquer l'un de ces formats d'encodage aux notifications qu'il envoie à l'entité communicante en question lorsqu'il détecte un événement correspondant à la souscription ; et un module 2D d'amorçage (ou « bootstrapping » en anglais), configuré ici pour, sur requête dite d'amorçage d'une entité communicante (par exemple une requête d'amorçage envoyée par le module NFk-B de découverte d'une entité applicative NFk décrit précédemment), fournir à cette entité communicante (autrement dit publier auprès de cette entité), les services que l'entité 2 de contrôle offre ainsi que les ressources qu'elle gère. Dans l'exemple de la fonction NRF envisagé ici, le module 2D d'amorçage est configuré pour exécuter par exemple des opérations de la logique du service d'amorçage Nnrf_Bootstrapping définis par le standard 3GPP, aménagées pour tenir compte de l'invention. Plus spécifiquement, en réponse à une requête d'amorçage d'une entité communicante (ex. fonction NF, fonction NRF ou autre entité de réseau ou encore équipement utilisateur, appartenant ou rattaché au réseau cœur CN ou à un autre réseau), le module 2D d'amorçage est configuré pour fournir en réponse à cette requête outre les informations qui lui sont demandées, au moins un format d'encodage que l'entité 2 de contrôle supporte.
[0094] Les fonctions assurées par les modules 2A à 2D de l'entité 2 de contrôle sont décrites plus en détail ultérieurement, en référence aux étapes du procédé de gestion selon l'invention.
[0095] Enfin, la mémoire morte 7 de l'ordinateur 4 comprend, lorsque l'ordinateur 4 héberge l'entité communicante 3 selon l'invention, un enregistrement d'un programme d'ordinateur PROG3, comportant des instructions définissant les principales étapes d'un procédé de communication selon l'invention.
[0096] Ce programme PROG3 définit des modules fonctionnels de l'entité 3 qui s'appuient ou commandent les éléments matériels 5 à 9 de l'ordinateur 4 cités précédemment. Ces modules comprennent notamment dans le mode de réalisation décrit ici, comme illustré sur la figure 2 : un premier module 3A de communication configuré pour envoyer à l'entité 2 de contrôle une requête de découverte d'entités applicatives gérées par celle-ci. Cette requête de découverte, qui est destinée à être traitée par le module 2B de l'entité 2 de contrôle décrit précédemment, peut contenir un ou plusieurs critères que les entités applicatives doivent vérifier, comme par exemple un type d'entité applicative, un service fourni par celle-ci, un format d'encodage supporté par l'entité applicative, etc. D'autres critères peuvent être envisagés en complément ou en variante ; un module 3B de réception, configuré pour recevoir une réponse à la requête de découverte indiquant au moins une entité applicative dite candidate gérée par l'entité 2 de contrôle répondant au(x) critère(s) requis. La réponse envoyée par l'entité 2 de contrôle comprend tout ou partie des profils des entités applicatives candidates, incluant au moins, pour chaque entité applicative candidate, un format d'encodage supporté par celle-ci ; un module 3C de sélection, configuré lorsque la réponse à la requête de découverte indique plusieurs entités applicatives, sélectionner l'une d'entre elles selon un ou plusieurs critères de sélection déterminés. Par exemple, un tel critère de sélection peut être un format d'encodage donné, mais d'autres critères peuvent être envisagés comme par exemple une charge ou un service proposé ; un deuxième module 3D de communication, configuré pour envoyer à l'entité applicative candidate sélectionnée, une requête comprenant un contenu encodé au moyen d'un format d'encodage supporté par cette dernière ; et un module 3E de souscription, configuré pour envoyer à l'entité 2 de contrôle une demande de souscription pour recevoir des informations concernant au moins un événement affectant au moins un profil mémorisé par l'entité 2 de contrôle, par exemple les profils des entités applicatives candidates reçues par le module 3B de réception. Conformément à l'invention, le module 3E est configuré pour indiquer à l'entité 2 de contrôle dans sa demande de souscription au moins un format d'encodage supporté par l'entité 3. Le module 3E est en outre configuré pour recevoir et traiter, lorsqu'un événement correspondant à la demande de souscription est détecté par l'entité 2 de contrôle, une notification de l'entité 2 de contrôle comprenant des informations relatives à cet événement encodées au moyen d'un format d'encodage supporté par l'entité 3 et indiqué dans la demande de souscription.
[0097] Les fonctions assurées par les modules 3A à 3E de l'entité 3 du réseau sont décrites plus en détail ultérieurement, en référence aux étapes du procédé de communication selon l'invention.
[0098] On note que dans l'exemple envisagé ici, l'entité 3 est une entité du réseau cœur CN distincte des entités applicatives NF1,...,NFN gérées par l'entité 2 de contrôle. Toutefois, cette hypothèse n'est pas limitative en soi, et l'entité 3 peut être intégrée dans l'une des entités applicatives NF1,...,NFN. De même, elle peut appartenir à un réseau distinct du réseau cœur CN ou du réseau NW.
[0099] Nous allons maintenant décrire les principales étapes d'un procédé de gestion, d'un procédé d'enregistrement et d'un procédé de communication selon l'invention telles qu'elles sont mises en œuvre respectivement par l'entité 2 de contrôle, par chacune des entités applicatives NF1,...,NFN gérées par l'entité 2 de contrôle, et par l'entité 3, dans un mode particulier de réalisation. Ces étapes sont mises en œuvre à travers différentes procédures mises en place ici dans le réseau cœur CN, entre les entités applicatives, l'entité 2 de contrôle et l'entité 3 : procédure d'amorçage, procédure d'enre gistrement, procédure de découverte, procédure de souscription/notification, décrites plus en détail ci-après. Les figures 4 à 6 illustrent ces différentes procédures et les étapes des procédés selon l'invention impliquées dans celles-ci.
[0100] La figure 4 représente les procédures d'amorçage et d'enregistrement d'une entité applicative NFk auprès de l'entité 2 de contrôle.
[0101] Dans le mode de réalisation décrit ici, comme mentionné précédemment, on suppose en préliminaire, que chacune des entités applicatives NF1,...,NFN sont rattachées à l'entité 2 de contrôle et ont été configurées avec une adresse de joignabilité (ex. URI) de cette dernière.
[0102] Avant de s'enregistrer auprès de l'entité 2 de contrôle, chaque entité applicative NFk, k= I,. .,N, initie une procédure de découverte des services offerts par l'entité 2 de contrôle et des ressources qu'elle gère. Cette procédure a pour but de permettre à chaque entité applicative NFk de déterminer dyna miquement comment accéder aux services offerts par l'entité 2 de contrôle et en particulier d'iden tifier vers quelles ressources (ex. quelles URIs) envoyer leurs requêtes lors de l'accès à ces services.
[0103] A cet effet, l'entité applicative NFk envoie, par l'intermédiaire de son module NFk-B de découverte, une requête d'amorçage à l'entité 2 de contrôle, à l'adresse avec laquelle elle a été configurée (par exemple l'URI « URI2-BS »), visant à découvrir les services offerts par l'entité 2 de contrôle et les ressources qu'elle gère (étape E10). Cette requête d'amorçage est par exemple une requête HTTP GET/bootstrapping(URI2-BS) telle que définie dans le standard 3GPP dans le document TS 29.510 notamment.
[0104] L'entité 2 de contrôle répond à cette requête via son module 2D d'amorçage (étape E20). Plus spé cifiquement, celui-ci fournit dans le corps ici d'une réponse HTTP 200 OK, les informations requises, à savoir les services que l'entité 2 de contrôle offre (par exemple les services de gestion NRF_NFMa- nagement, de découverte NRF_NFDiscovery, et d'autorisation NRF_AccessToken) et les URIs pour accéder aux services et aux ressources gérées par ces services. Le module 2D d'amorçage complète ces informations par un ou plusieurs formats d'encodage, référencé(s) par ENCOD-2, que l'entité 2 de contrôle supporte. On suppose ici que l'ensemble ENCOD-2 comprend un ou plusieurs formats d'encodage incluant au moins un format de compression, par exemple gzip. L'ensemble des infor mations précitées est référencé par BootstrappingData sur la figure 4.
[0105] On note que les formats d'encodage ENCOD-2 peuvent être définis à différents niveaux, à savoir pour s'appliquer à tous les services proposés par l'entité 2 de contrôle et à toutes les ressources qu'elle gère, ou différer en fonction des services proposés par l'entité 2 de contrôle, ou encore en fonction des ressources gérées par l'entité 2 de contrôle, ou des opérations réalisées sur ces res sources.
[0106] Sur réception de cette réponse 200 OK, l'entité applicative NFk mémorise les informations Bootstrap pingData en association avec l'entité 2 de contrôle (E30).
[0107] Dans une variante de réalisation, l'entité applicative NFk indique dans la requête d'amorçage envoyée à l'entité 2 de contrôle, par exemple dans l'entête Accept-Encoding de la requête d'amorçage, au moins un format d'encodage qu'elle supporte. De cette sorte, l'entité 2 de contrôle peut utiliser un de ces formats d'encodage pour encoder les informations BootstrappingData qu'elle envoie à l'entité applicative NFk en réponse à la requête d'amorçage, et indiquer dans l'entête Content-Encoding de la réponse, le format d'encodage qu'elle a utilisé.
[0108] On note que cette procédure d'amorçage ou de découverte des services et des ressources de l'entité 2 de contrôle peut être exécutée par d'autres entités que les entités applicatives destinées à s'enre gistrer auprès d'elle. Par exemple, elle peut être exécutée par une autre entité de contrôle telle qu'une autre entité NRF appartenant ou non au même réseau (PLMN).
[0109] Dans une variante de réalisation, l'entité applicative NFk obtient les formats d'encodage ENCOD-2 supportés par l'entité 2 de contrôle en lui envoyant une requête OPTIONS telle que décrite précédemment. L'entité 2 de contrôle répond à cette requête OPTIONS en fournissant, dans une réponse 200 OK, le ou les formats d'encodage supportés dans l'entête Accept-Encoding de la réponse.
[0110] Suite à cette procédure de découverte, l'entité applicative NFk peut s'enregistrer auprès de l'entité 2 de contrôle, en utilisant les informations BootstrappingData dont elle dispose sur le service de gestion NRF_NFManagement offert par l'entité 2 de contrôle et la ressource (ex. URI) à pointer pour accéder à ce service.
[0111] Plus particulièrement, l'entité applicative NFk envoie, par l'intermédiaire de son module NFk-C d'enregistrement, une requête d'enregistrement (requête HTTP PUT dans l'exemple envisagé ici) dans le corps de laquelle elle fournit son profil NF_PROFk (étape E40). Conformément à l'invention, le profil NF_PROFk est encodé par le module NFk-C au moyen d'un format d'encodage sélectionné parmi les formats d'encodage ENCOD-2 supportés par l'entité 2 de contrôle, par exemple le format de compression gzip. Le format d'encodage sélectionné (ex. gzip) est indiqué dans l'entête Content-Enco- ding de la requête d'enregistrement.
[0112] La requête d'enregistrement est envoyée à une URI composée de l'URI du service d'enregistrement et de l'URI de la ressource associée à l'entité applicative NFk à enregistrer. Le profil NF_PROFk, comme détaillé précédemment, comprend une pluralité d'attributs, et notamment, dans l'exemple envisagé ici les attributs listés dans le document TS 29.510 dans la table 6.1.6.2.2-1 en section 6.1.6.2.2. Ces attributs comprennent notamment, de façon non exhaustive, l'identifiant ( nflnstanceld ) de l'entité applicative NFk (qui est une instance d'une fonction réseau donnée) à créer, le type ( nfType ) de l'entité applicative NFk (i.e. type de la fonction réseau ici), l'état ( nfStatus ) de l'entité applicative, son nom ( nflnstanœName ), le PLMN (p/mnList) auquel elle est rattachées, ses adresses IPv4 et IPv6 (ipv4Addresses, ipv6Addresses), sa priorité ( prioritÿ) par rapport aux autres entités applicatives de même type (i.e. aux autres instances de la même fonction réseau), sa capacité ( capacitÿ ), sa charge (/oad), sa localisation (/oca/itÿ), etc. En outre, conformément à l'invention, le profil NF_PROFk comprend un attribut contenant un ou plusieurs formats d'encodage supportés par l'entité applicative NFk. On suppose ici qu'au moins l'un de ces formats d'encodage est un format de compression.
[0113] Aucune limitation n'est attachée à la structure de l'attribut contenant le ou les formats d'encodage supportés par l'entité applicative NFk. Il peut s'agir d'un attribut dédié à ces formats d'encodage, nommé par exemple ContentEncoding, d'un attribut propriétaire réservé (« vendor-specific extensions » décrit dans le document TS 29.500 au paragraphe 6.6.3) que les opérateurs de réseau peuvent définir et utiliser comme l'autorise le standard 3GPP, ou encore d'un attribut plus global, nommé par exemple caplnfo, composé d'une structure de données visant plus généralement les options de communication supportées par l'entité applicative NFk dont notamment les formats d'encodage. D'autres options de communication peuvent être spécifiées en plus des formats d'encodage, comme par exemple des algorithmes de chiffrement supportés par l'entité applicative NFk, des formats de contenus (ex. json, xml, multipart, etc.) supportés par celle-ci, etc. On note qu'il est possible en outre d'associer des éléments d'information complémentaires aux formats d'encodage supportés par l'entité applicative NFk, comme par exemple des priorités associées à chaque format d'encodage supporté.
[0114] Par ailleurs, les formats d'encodage indiqués dans le profil NF_PROFk peuvent être définis à différents niveaux. De façon connue en soi, les attributs d'une entité applicative peuvent être définis dans le profil de l'entité applicative au niveau de l'entité applicative (ils concernent alors tous les services qu'elle propose et les ressources qu'elle gère ou que ces services gèrent) ou au niveau de chaque service individuellement. Dans le mode de réalisation décrit ici, les formats d'encodage supportés par l'entité applicative NFk peuvent être fournis dans des attributs s'appliquant : à l'ensemble des services proposés par cette entité applicative ; ou à un service donné ou à une version donnée de service proposé par cette entité applicative ; ou à une ressource donnée gérée par cette entité applicative ou par un service offert par cette entité applicative ; ou à une opération donnée sur une ressource gérée par cette entité applicative ou par un service offert par cette entité applicative.
[0115] Cette liste n'est pas exhaustive et d'autres niveaux de granularité peuvent être envisagés.
[0116] Sur réception de la requête d'enregistrement, l'entité 2 de contrôle enregistre par l'intermédiaire de son module 2A d'enregistrement l'entité applicative NFk : elle mémorise son profil NF_PROFk à l'URI indiquée dans la requête d'enregistrement et associe à l'entité applicative NFk un état « disponible » (étape E50).
[0117] L'entité 2 de contrôle confirme l'enregistrement de l'entité applicative NFk en lui envoyant une réponse HTTP 201 Created (étape E60).
[0118] Suite à cet enregistrement, des mises à jour peuvent être apportées au profil de l'entité applicative NFk (non représentées sur la figure 4) : par exemple, l'entité applicative NFk peut souhaiter enregistrer des modifications de certains attributs de son profil ou se désenregistrer auprès de l'entité 2 de contrôle. Pour enregistrer des modifications, l'entité applicative NFk peut soit resoumettre son profil NF_PROFk mis à jour dans son intégralité, par exemple ici au moyen d'une nouvelle requête HTTP PUT, soit uniquement les attributs modifiés, par exemple ici au moyen d'une requête HTTP PATCH. Dans l'une ou l'autre des options, l'entité applicative NFk fournit le profil NF_PROFk ou seulement les modifications dans le corps de la requête, encodé(es) au moyen d'un format d'encodage sélectionné parmi les formats d'encodage ENCOD-2 supportés par l'entité 2 de contrôle et indiqué dans l'entête Content-Encoding de la requête. Sur réception de ces éléments, l'entité 2 de contrôle met à jour le profil NF_PROFk qu'elle mémorise, et confirme la prise en compte de la mise à jour à l'entité applicative NFk.
[0119] Comme mentionné ci-dessus, l'entité applicative NFk peut également souhaiter se désenregistrer : dans ce cas, elle adresse une requête de désenregistrement (requête HTTP DELETE dans l'exemple envisage ici) à l'entité 2 de contrôle, qui sur réception de cette requête, associe à l'entité applicative NFk un état « indisponible ». Le profil associé à l'entité applicative NFk est par ailleurs supprimé (par exemple à l'issue d'un laps de temps déterminé).
[0120] On note que, comme décrit plus en détail ultérieurement, les trois événements qui viennent d'être décrits, à savoir la création d'un profil (ou de façon équivalente, l'enregistrement d'une entité applicative), sa modification ou sa suppression (ou de façon équivalente le désenregistrement de l'entité applicative), peuvent faire l'objet de notifications envoyées par l'entité 2 de contrôle aux entités qui ont souscrit le cas échéant auprès d'elle à la notification de ces événements.
[0121] La figure 5 représente une procédure de découverte par l'entité 3 d'entités applicatives gérées par l'entité 2 de contrôle. Aucune hypothèse n'est faite sur la nature de l'entité 3. Il peut s'agir par exemple d'une autre entité applicative cliente (« consumer ») des services des entités applicatives gérées par l'entité 2 de contrôle.
[0122] Ainsi, on suppose par exemple que l'entité 3 souhaite découvrir toutes les entités applicatives gérées par l'entité 2 de contrôle vérifiant un ou plusieurs critères de recherche donnés, par exemple les entités applicatives fournissant un service particulier ou correspondant à une fonction réseau déterminée. L'invention ne se limite pas à des critères de recherche fonctionnels, et on peut également envisager en complément ou en variante, de fonder cette recherche d'autres critères telles que par exemple sur une option de communication supportée par les entités applicatives, et plus spécifiquement sur un format d'encodage particulier.
[0123] L'entité 3, par l'intermédiaire de son premier module 3A de communication adresse une requête de découverte à l'entité 2 de contrôle (étape F10). Cette requête de découverte est par exemple ici une requête HTTP GET. Elle comprend des paramètres « query parameters » précisant le ou les critères de recherche fixés par l'entité 3. [0124] Sur réception de cette requête de découverte, l'entité 2 de contrôle vérifie que l'entité 3 est autorisée à découvrir les entités applicatives gérées par l'entité 2 de contrôle (étape F20). Elle procède à cet effet de façon connue de l'homme du métier et non détaillée ici.
[0125] Le cas échéant, l'entité 2 de contrôle, par l'intermédiaire de son module 2B de publication, recherche la ou les entités applicatives enregistrées auprès d'elle qui vérifie le ou les critères de recherche indiqués par l'entité 3 (étape F30). Dans le mode de réalisation décrit ici, si plusieurs critères de recherche sont indiqués dans la requête de découverte, le module 2B de publication recherche les entités applicatives vérifiant chacun de ces critères. Dans une variante de réalisation, il peut recher cher les entités applicatives vérifiant au moins l'un de ces critères.
[0126] On suppose qu'à l'issue de cette recherche, l'entité 2 de contrôle obtient un ensemble NF-MATCH comprenant une ou plusieurs entités applicatives dites « candidates » vérifiant les critères de re cherche de l'entité 3. Par souci de simplification dans la suite, on parle « des entités candidates de l'ensemble NF-MATCH » y compris lorsque cet ensemble ne comprend qu'une entité candidate.
[0127] L'entité 2 de contrôle envoie alors le résultat de sa recherche à l'entité 3 dans une réponse HTTP 200 OK (étape F40). Elle indique dans le corps de la réponse les entités applicatives candidates NF- MATCH correspondant au(x) critère(s) de recherche ainsi que les attributs de ces entités applicatives candidates utiles à l'entité 3 pour accéder aux services proposés par ces entités applicatives candi dates. Dans le mode de réalisation décrit ici, il ne s'agit que d'une partie des attributs présents dans le profil NF_PROFk : seuls les attributs nécessaires au choix et à l'accessibilité des services sont fournis à l'entité 3 (ex. identifiant de l'entité applicative, type d'entité applicative, état de l'entité applicative, formats d'encodage, etc.). Conformément à l'invention, les attributs transmis incluent en particulier le ou les formats d'encodage supportés par les entités applicatives candidates de l'en semble NF-MATCH.
[0128] En variante, l'entité 2 de contrôle peut fournir à l'entité 3 tous les attributs listés dans les profils des entités applicatives candidates de l'ensemble NF-MATCH.
[0129] Dans une variante de réalisation, l'entité 3 indique dans l'entête Accept-Encoding de la requête de découverte adressée à l'entité 2 de contrôle les formats d'encodage qu'elle supporte (par exemple au moins un format de compression), et l'entité 2 de contrôle encode l'ensemble NF-MATCH et les attributs associés au moyen de l'un de ces formats d'encodage (par exemple du format de compres sion), et indique dans l'entête Content-Encoding de la réponse le format d'encodage utilisé.
[0130] Dans une autre variante encore, l'entité 2 de contrôle détermine les formats d'encodage supportés par l'entité 3 en lui envoyant une requête OPTIONS et utilise l'un de ces formats d'encodage comme décrit ci-avant.
[0131] Dans le mode de réalisation décrit ici, suite à la réception de la réponse de l'entité 2 de contrôle, le module 3B de réception de l'entité 3 extrait les informations contenues dans la réponse et les stocke par exemple dans une mémoire cache pour une durée déterminée (étape F50). De cette sorte, lorsqu'il a besoin d'accéder à un service particulier correspondant au(x) critère(s) de recherche au(x)quel(s) répondent les entités applicatives candidates de l'ensemble NF-MATCH, il peut accéder rapidement aux attributs de ces entités applicatives candidates en consultant sa mémoire cache.
[0132] On suppose maintenant que l'entité 3 souhaite effectivement accéder à un service offert par les entités applicatives candidates de l'ensemble NF-MATCH.
[0133] Si l'ensemble NF-MATCH comprend plusieurs entités applicatives candidates, l'entité 3 peut, au moyen de son module 3D de sélection, sélectionner l'une d'entre elles en fonction d'un ou de plu sieurs critères de sélection déterminés (étape F60). On désigne NFkO l'entité applicative sélectionnée. Par exemple, le module 3D de sélection peut tenir compte pour sélectionner l'entité applicative NFkO dans l'ensemble NF-MATCH des formats d'encodage supportés par les entités applicatives candidates et en sélectionner une qui supporte un format d'encodage spécifique (par exemple un format de compression tel que gzip). En variante ou en complément, d'autres critères de sélection peuvent être considérés par le module 3D de sélection, comme par exemple les charges des entités applicatives candidates ou leurs capacités respectives, ou une priorité associée à chacune d'entre elles, ou leurs localisations, ou encore une combinaison de plusieurs de ces critères ou d'autres critères.
[0134] Suite à cette sélection, l'entité 3 via son deuxième module 3D de communication envoie une requête d'accès au service offert par l'entité applicative NFkO sélectionnée (étape F70). Cette requête est par exemple ici une requête HTTP POST, PUT ou PATCH selon le service considéré comprenant un corps de requête embarquant un contenu. Grâce à l'invention, le module 3D de communication peut avantageusement encoder ce contenu au moyen d'un format d'encodage supporté par l'entité applicative NFkO selon les informations stockées dans sa mémoire cache à l'étape F50. En d'autres mots, l'entité 3 peut exploiter un format d'encodage supporté par l'entité applicative NFkO tel qu'un format de compression dès la première requête qu'elle lui envoie lors d'un accès à un service proposé par l'entité applicative NFkO. Elle n'est pas obligée d'attendre une réponse à cette première requête pour encoder les contenus qu'elle souhaite lui transmettre. Bien entendu, elle peut (et continue préférentiellement d') appliquer ce format d'encodage dans les requêtes suivantes également.
[0135] On note que dans certains contextes, il peut s'avérer inapproprié (voire interdit) d'appliquer un format de compression à un contenu envoyé dans le corps d'une requête ou d'une réponse. C'est le cas par exemple lorsque le contenu en question comprend un nombre faible d'octets : la compression d'un tel contenu peut alors avoir un effet opposé à celui recherché à savoir que le nombre d'octets du contenu compressé peut être supérieur à celui du contenu non compressé. De même, certains services offerts par certaines entités applicatives comme par exemple des entités de type AMF ou SMF comportent des opérations s'appuyant sur des requêtes et/ou des réponses qui ont des corps composés de plusieurs parties. Une compression de certaines de ces parties n'apporte pas nécessairement un gain significatif voire est interdit. Pour gérer ces situations, l'entité 3 peut être configurée pour vérifier avant d'appliquer un format d'encodage au contenu (en tout ou partie) d'une requête ou d'une réponse qu'elle envoie à une entité applicative, si le contenu est approprié (par exemple s'il vérifie un critère de taille déterminé ou si son encodage n'est pas interdit).
[0136] Comme mentionné précédemment, le profil d'une entité applicative gérée par l'entité 2 de contrôle peut être affecté par différents événements (ex. création, suppression, modification), et évoluer dans le temps. Cela peut avoir pour conséquence que les informations stockées dans la mémoire cache de l'entité 3, et en particulier les formats d'encodage supportés par les entités applicatives, peuvent ne plus être d'actualité lorsque l'entité 3 cherche à accéder à un service offert par l'une des entités applicatives candidates, sans que celui-ci en soit informé. Dans l'exemple des formats d'encodage, si l'événement consiste en l'activation d'un nouveau format d'encodage au niveau d'une entité applicative candidate, cela ne pose pas de problème en soi dès lors que les autres formats d'encodage sont toujours supportés par l'entité applicative candidate. Un problème se pose lorsqu'un format d'encodage n'est plus supporté par l'entité applicative candidate.
[0137] Plusieurs solutions sont alors possibles pour gérer ce cas de figure dans le contexte de l'invention.
[0138] Une première solution, connue du standard 3GPP, consiste, si l'entité 3 utilise un format d'encodage qui n'est plus supporté par l'entité applicative avec laquelle elle interagit et reçoit une réponse de rejet avec un status 415, à envoyer de nouveau la requête sans encodage ou avec un encodage conforme à l'un des formats indiqués le cas échéant par l'entité applicative dans un entête de la réponse 415, par exemple dans un champ Accept-Encoding.
[0139] Une deuxième option, connue également du standard 3GPP, consiste suite à la réception de la réponse de rejet 415, à envoyer une requête OPTIONS à l'entité applicative pour obtenir une mise à jour des formats d'encodage qu'elle supporte.
[0140] Le choix de l'une ou l'autre de ces options dépend de la configuration de l'entité 3 du réseau (choix d'implémentation de l'équipementier de l'entité 3). Il convient toutefois de noter que ces deux solutions peuvent dégrader un peu les performances de l'entité 3. [0141] Selon une troisième option illustrée à la figure 6, l'entité 3 peut souscrire auprès de l'entité 2 de contrôle pour recevoir des notifications l'informant des événements qui affectent les profils des entités applicatives qu'elle gère. Lors de la souscription, l'entité 3 peut préciser l'étendue des informations qu'elle souhaite recevoir, et notamment le type d'événements (ex. création, modification, suppression d'un profil) dont elle souhaite être informée, et les ressources concernées.
[0142] Plus précisément, dans le mode de réalisation décrit ici, l'entité 3 envoie, par l'intermédiaire de son module 3E de souscription, une requête de souscription à l'entité 2 de contrôle indiquant les événements dont elle souhaite être informée (étape G10). Il peut s'agir par exemple de changements (création, modification et suppression) affectant des profils d'un type d'entités applicatives donné (ex. fonction réseau AMF). Bien entendu cet exemple n'est donné qu'à titre illustratif et n'est pas limitatif en soi. Notamment, d'autres éléments peuvent être indiqués lors de la souscription comme par exemple un service particulier, un identifiant d'une entité applicative, etc.
[0143] La requête de souscription est par exemple ici une requête HTTP POST. Elle contient les événements auxquels l'entité 3 souscrit. Elle contient en outre avantageusement au moins un format d'encodage supporté par l'entité 3, par exemple un format de compression.
[0144] Sur réception de la requête de souscription, l'entité 2 de contrôle mémorise via son module 2C de notification, dans un contexte de la souscription de l'entité 3, le ou les formats d'encodage supportés par cette dernière (étape G20), et confirme la souscription auprès de l'entité 3 en lui envoyant une réponse 201 Created (étape G30).
[0145] Puis, lorsqu'elle détecte un événement correspondant à la souscription de l'entité 3 (étape G40), l'entité 2 de contrôle par l'intermédiaire de son module 2D de notification, envoie une notification à l'entité 3 pour l'informer de l'événement détecté (étape G50). Cette notification est par exemple ici une requête HTTP POST. Elle comprend, dans le corps de la requête, les informations NotificationData relatives à l'événement détecté. Ces informations peuvent comprendre, suivant l'événement détecté, tout ou partie du profil affecté par l'événement (tout du moins de la partie publiée par l'entité 2 de contrôle lors de la procédure de découverte). Ainsi à titre d'exemple, si l'événement est une création de profil, la notification comprend tous les attributs du nouveau profil qui sont habituellement publiés lors de la procédure de découverte et qui permettent à l'entité 3 d'accéder au service associé à ce profil. Si l'événement est une modification d'un profil existant, la notification peut comprendre uniquement les attributs modifiés, ou récapituler l'ensemble des attributs habituellement publiés lors de la procédure de découverte. Avantageusement, les informations incluses dans le corps de la notification sont encodées par le module 2D de notification dans un format d'encodage supporté par l'entité 3 et fourni lors de sa souscription.
[0146] Sur réception de cette notification, l'entité 3 met à jour les profils concernés mémorisés dans sa mémoire cache (étape G60).
[0147] Cette solution permet avantageusement de diminuer le laps de temps pendant lequel l'entité 3 est susceptible d'utiliser des informations qui ne sont pas à jour pour accéder aux services proposées par les entités applicatives NF1,...,NFN.
[0148] On note qu'il est possible au niveau d'une entité du réseau d'implémenter de façon complémentaire plusieurs des trois solutions proposées ci-dessus (par exemple les première et troisième solutions).
[0149] Ainsi, comme il apparaît au vu de ce qui précède, l'invention permet de façon simple d'optimiser les échanges entre les différentes entités du système 1, en s'appuyant sur la connaissance des formats d'encodage supportés par ces différentes entités. Il convient de noter que dans toutes les procédures qui viennent d'être décrites, ces formats d'encodage peuvent indifféremment être fournis dans des champs ou des attributs dédiés, dans des champs ou des attributs propriétaires, ou encore dans des structures de données telles que la structure de données caplnfo évoquée précédemment, comprenant au moins une option de communication (à savoir au moins un format d'encodage) supportée par l'entité considérée. [0150] Bien que l'invention ait été décrite dans le contexte d'un réseau 5G défini par le standard 3GPP, en référence à des entités applicatives et une entité communicante 3 de type fonctions réseau, et une entité de contrôle de type NRF, comme mentionné précédemment, l'invention peut s'appliquer d'autres entités. Par exemple l'entité 3 peut en variante être une autre entité de contrôle de type NRF, appartenant ou non au même PLMN que l'entité 2 de contrôle, ou un équipement intermédiaire de type SCP agissant pour le compte d'une entité applicative « customer », ou encore un équipement utilisateur rattaché au réseau ou une fonction applicative (ou « Application Function » en anglais), se trouvant dans le réseau ou externe au réseau. Dans le cas d'un équipement SCP, après avoir découvert les entités applicatives candidates et sélectionné l'une d'entre elles, l'équipement SCP peut encoder les contenus reçus de l'entité applicative « customer » au nom de laquelle il agit en utilisant un format d'encodage supporté par l'entité applicative candidate. Autrement dit, l'invention permet de mettre en œuvre un encodage sur le tronçon reliant l'équipement SCP à l'entité 2 de contrôle ; en revanche elle n'assure pas la mise en œuvre d'un tel encodage entre l'entité applicative « consu mer » et l'équipement SCP agissant pour le compte de cette entité applicative. On note que l'équi pement SCP est une entité applicative qui peut également s'enregistrer auprès de l'entité 2 de con trôle et être découverte par d'autres entités du réseau et notamment d'autres équipements SCP, dans l'hypothèse où plusieurs SCP se trouvent sur un chemin reliant une entité applicative « consu mer » et une entité applicative « producer ». Cela permet d'appliquer également un encodage sur chaque segment du chemin de communication reliant deux équipements SCP.
[0151] De même, il a été fait référence dans ce qui précède pour mieux illustrer l'invention aux procédures NRF_Bootstrapping, NRF_NFManagement et NRF_NFDiscovery définies par le standard 3GPP, mais l'invention peut s'appliquer à d'autres procédures visant un but similaire, et notamment à des pro cédures d'enregistrement ou de découverte propriétaires.
[0152] L'invention peut aussi s'appliquer dans d'autres générations de réseau de communications ou dans d'autres contextes qu'un réseau 5G, comme par exemple à un réseau 6G ou de génération suivante, à un système informatique en nuage proposant des microservices, à un réseau propriétaire, etc., utilisant des procédures d'enregistrement et de découverte de ces microservices. Elle peut également s'appliquer à d'autres protocoles. En outre l'invention peut également s'appliquer à d'autres entités applicatives que des instances virtualisées de fonction réseau, comme par exemple des entités ap plicatives physiques.
[0153] L'invention peut également s'appliquer à d'autres protocoles que le protocole HTTP/2, comme par exemple à une autre version du protocole HTTP (HTTP/1.1), ou aux protocoles SOAP, CORBA, gRPC, QUIC, ou de façon générale à tout autre protocole basé sur l'échange de requêtes et de réponses, et supportant un encodage du contenu du corps des requêtes et/ou des réponses, typiquement une compression de ce contenu. Ce qui vient d'être décrit dans le cadre de requêtes/ réponses HTTP/2, et en particulier les données véhiculées par ces requêtes/ réponses pour la mise en œuvre de l'in vention, s'applique, transposé aux requêtes/ réponses de ces protocoles.

Claims

Revendications
[Revendication 1] Procédé de gestion, par une entité (2) de contrôle d'un réseau (CN), d'une pluralité d'entités applicatives (NF1,...,NFN) proposant des services dans le réseau, ledit procédé de gestion comprenant : une étape (E10) de réception en provenance d'une première entité (NFk) d'une requête d'amorçage visant à découvrir des services proposés par l'entité de contrôle et/ou des ressources gérées par celle-ci ; et une étape (E20) d'envoi d'une réponse à ladite requête d'amorçage de ladite première entité, ladite réponse comprenant en outre au moins un format d'encodage supporté par l'entité de contrôle.
[Revendication 2] Procédé de gestion selon la revendication 1 comprenant en outre : une étape d'enregistrement (E40) de chaque entité applicative gérée par l'entité de contrôle comprenant une mémorisation d'un profil de ladite entité applicative, ce profil comprenant une pluralité d'attributs incluant au moins un format d'encodage supporté par ladite entité applicative et pouvant être utilisé lors d'un accès à un service proposé par elle ; et en réponse à une requête (F10) en provenance d'une deuxième entité (3), une étape (F40) de fourniture à cette deuxième entité, pour au moins une dite entité applicative gérée par l'entité de contrôle, d'au moins une partie de la pluralité d'attributs du profil de cette entité applicative, ladite partie comprenant ledit au moins un format d'encodage supporté par cette entité applicative.
[Revendication 3] Procédé de gestion selon la revendication 2 dans lequel ladite requête est une requête de découverte d'au moins une dite entité applicative gérée par l'entité de contrôle.
[Revendication 4] Procédé de gestion selon l'une quelconque des revendications 1 à 2 comportant en outre : une étape (G10) de réception d'une demande de souscription, en provenance d'une troisième entité (3), pour recevoir des informations concernant au moins un événement affectant au moins un profil mémorisé par l'entité de contrôle, cette demande de souscription indiquant au moins un format d'encodage supporté par la troisième entité ; suite à une détection (G40) d'un évènement correspondant à ladite demande de souscription, une étape (G50) de notification de ladite troisième entité comprenant des informations relatives audit événement détecté encodées au moyen d'un dit format d'encodage supporté par la troisième entité et indiqué dans ladite demande de souscription.
[Revendication 5] Procédé de gestion selon la revendication 4 dans lequel ledit événement comprend une modification, une suppression ou une création d'un profil d'une entité applicative gérée par l'entité de contrôle, et/ou lesdites informations comprises dans la notification comprennent tout ou partie dudit profil.
[Revendication 6] Procédé de découverte par une entité (NFk) de services proposés et/ou ressources gérées par une entité de contrôle d'un réseau gérant une pluralité d'entités applicatives proposant des services dans le réseau, ledit procédé de découverte comprenant :
- une étape (E10) d'envoi d'une requête d'amorçage à ladite entité de contrôle visant à découvrir des services qu'elle propose et/ou des ressources gérées par celle-ci ; - une étape (E20) de réception d'une réponse à ladite requête d'amorçage comprenant en outre au moins un format d'encodage supporté par l'entité de contrôle.
[Revendication 7] Procédé d'enregistrement d'une entité applicative (NFk) proposant au moins un service dans un réseau, auprès d'une entité de contrôle du réseau gérant une pluralité d'entités applicatives proposant des services dans le réseau, ledit procédé d'enregistrement comprenant :
- une étape de découverte des services et/ou ressources gérées par l'entité de contrôle du réseau utilisant un procédé de découverte selon la revendication 6 ; et
- une étape d'enregistrement de l'entité applicative auprès de l'entité de contrôle comprenant une fourniture (E40) par ladite entité applicative à l'entité de contrôle d'un profil de ladite entité applicative, ce profil comprenant une pluralité d'attributs incluant au moins un format d'encodage supporté par ladite entité applicative et pouvant être utilisé lors d'un accès à un service proposé par elle, ladite entité de contrôle étant configurée pour fournir au moins une partie de ladite pluralité d'attributs du profil de l'entité applicative, ladite partie comprenant ledit au moins un format d'encodage, en réponse à une requête en provenance d'une autre entité.
[Revendication 8] Procédé de communication d'une entité (3), dite « quatrième » entité, avec une entité (2) de contrôle du réseau gérant une pluralité d'entités applicatives proposant des services dans le réseau et mémorisant des profils de ces entités applicatives, ledit procédé de communication comprenant : une étape de découverte des services et/ou ressources gérées par l'entité de contrôle du réseau utilisant un procédé de découverte selon la revendication 6 ; une première étape (F10) d'envoi à ladite entité de contrôle d'une requête de découverte d'entités applicatives gérées par l'entité de contrôle ; et une étape (F20) de réception d'une réponse à ladite requête de découverte indiquant au moins une entité applicative dite candidate gérée par l'entité de contrôle et une pluralité d'attributs de cette entité applicative candidate extraits d'un profil de l'entité applicative mémorisé par l'entité de contrôle, ladite pluralité d'attributs incluant au moins un format d'encodage supporté par cette entité applicative candidate et pouvant être utilisé lors d'un accès à un service proposé par elle.
[Revendication 9] Procédé de communication selon la revendication 8 comprenant en outre une deuxième étape (F70) d'envoi, à une dite entité applicative candidate indiquée dans la réponse reçue, d'une requête comprenant un contenu encodé au moyen d'un format d'encodage supporté par cette entité applicative candidate et indiqué dans la réponse reçue.
[Revendication 10] Procédé de communication selon la revendication 8 ou 9 dans lequel la requête envoyée lors de la deuxième étape d'envoi est la première requête que la quatrième entité envoie à l'entité applicative candidate lors d'un accès à un service proposé par cette entité applicative candidate.
[Revendication 11] Procédé de communication selon l'une quelconque des revendications 8 à 10 dans lequel la réponse à la requête de découverte indique une pluralité d'entités applicatives candidates et l'entité applicative candidate à laquelle est envoyée la requête lors de la deuxième étape d'envoi est sélectionnée (F60) parmi ladite pluralité d'entités actives candidates en tenant compte des formats d'encodage respectifs supportés par cette pluralité d'entités applicatives candidates.
[Revendication 12] Procédé de communication selon l'une quelconque des revendications 8 à 11 comprenant en outre : une étape (G10) d'envoi d'une demande de souscription à l'entité de contrôle pour recevoir des informations concernant au moins un événement affectant au moins un profil mémorisé par l'entité de contrôle, cette demande de souscription indiquant au moins un format d'encodage supporté par la quatrième entité ; et suite à une détection (G40) d'un évènement correspondant à ladite demande de souscription, une étape (G50) de réception d'une notification en provenance de l'entité de contrôle comprenant des informations relatives audit événement encodées au moyen d'un dit format d'encodage supporté par la quatrième entité et indiqué dans la demande de souscription.
[Revendication 13] Procédé selon l'une quelconque des revendications 1 à 12 dans lequel au moins un dit format d'encodage vise un encodage d'un contenu transmis dans un corps d'une requête ou d'une réponse conforme à une version du protocole HTTP (HyperText Transfer Protocol).
[Revendication 14] Procédé selon l'une quelconque des revendications 2, 3 à 5 lorsqu'elles dépendent de la revendication 2 et 7 à 12 dans lequel dans au moins un profil d'une entité applicative gérée par l'entité de contrôle, au moins un dit format d'encodage est fourni dans un attribut s'appliquant : à l'ensemble des services proposés par cette entité applicative ; ou à un service donné ou à une version donnée d'un service proposé par cette entité applicative ; ou à une ressource donnée gérée par un service offert par cette entité applicative ; ou à une opération donnée sur une ressource gérée par un service offert par cette entité applicative.
[Revendication 15] Procédé selon l'une quelconque des revendications 1 à 14 dans lequel au moins un dit format d'encodage est un format de compression de données.
[Revendication 16] Procédé selon l'une quelconque des revendications 1 à 15 dans lequel au moins un dit format d'encodage supporté par une dite entité est inclus dans une structure de données comprenant au moins une option de communications supportée par cette entité.
[Revendication 17] Entité (2) de contrôle d'un réseau gérant une pluralité d'entités applicatives proposant des services dans le réseau, ladite entité de contrôle comprenant un module (2D) d'amorçage, configuré pour, en réponse à une requête dite d'amorçage provenant d'une entité et visant à découvrir des services proposés par l'entité de contrôle et/ou des ressources gérées par celle-ci, fournir à cette entité une réponse à ladite requête d'amorçage, ladite réponse comprenant en outre au moins un format d'encodage supporté par l'entité de contrôle.
[Revendication 18] Entité applicative (NF1,...,NFN) d'un réseau proposant au moins un service dans le réseau, ladite entité applicative comprenant :
- un module (NFk-B) de découverte, configuré pour envoyer une requête dite d'amorçage à une entité de contrôle du réseau gérant une pluralité d'entités applicatives proposant des services dans le réseau, ladite requête d'amorçage visant à découvrir des services offerts et/ou des ressources gérées par ladite entité de contrôle, ledit module (NFk-B) de découverte étant en outre configuré pour recevoir une réponse à ladite requête d'amorçage comprenant lesdits services offerts et/ou ressources gérées par ladite entité de contrôle et au moins un format d'encodage supporté par ladite entité de contrôle ; et
- un module d'enregistrement (NFk-C) configuré pour enregistrer ladite entité applicative auprès de ladite entité de contrôle du réseau, ledit module d'enregistrement étant configuré pour fournir à l'entité de contrôle lors dudit enregistrement un profil de ladite entité applicative, ce profil comprenant une pluralité d'attributs incluant au moins un format d'encodage supporté par ladite entité applicative et pouvant être utilisé lors d'un accès à un service proposé par elle, ladite entité de contrôle étant configurée pour fournir au moins une partie de ladite pluralité d'attributs du profil de l'entité applicative, ladite partie comprenant ledit au moins un format d'encodage, en réponse à une requête en provenance d'une autre entité.
[Revendication 19] Système (1) comprenant : au moins une entité applicative (NF1,...,NFN) selon la revendication 18 proposant au moins un service dans un réseau ; une entité(2) de contrôle du réseau selon la revendication 17 gérant ladite au moins une entité applicative ; et au moins une entité (3, NFk) comprenant :
■ un module (3A) de communication configuré pour envoyer à ladite entité de contrôle une première requête de découverte d'entités applicatives gérées par l'entité de contrôle ; et
■ un module (3B) de réception, configuré pour recevoir une réponse à ladite requête de découverte indiquant au moins une entité applicative dite candidate gérée par l'entité de contrôle et une pluralité d'attributs de cette entité applicative candidate extraits d'un profil de l'entité applicative mémorisé par l'entité de contrôle, ladite pluralité d'attributs incluant au moins un format d'encodage supporté par cette entité applicative candidate et pouvant être utilisé lors d'un accès à un service proposé par elle.
EP22719322.4A 2021-04-02 2022-04-01 Procédés de gestion, de découverte, d'enregistrement et de communication et entités configurées pour mettre en oeuvre ces procédés Pending EP4315961A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2103445A FR3121568A1 (fr) 2021-04-02 2021-04-02 Procédés de gestion, d’enregistrement et de communication et entités configurées pour mettre en œuvre ces procédés
PCT/FR2022/050616 WO2022208033A1 (fr) 2021-04-02 2022-04-01 Procédés de gestion, de découverte, d'enregistrement et de communication et entités configurées pour mettre en oeuvre ces procédés

Publications (1)

Publication Number Publication Date
EP4315961A1 true EP4315961A1 (fr) 2024-02-07

Family

ID=76730684

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22719322.4A Pending EP4315961A1 (fr) 2021-04-02 2022-04-01 Procédés de gestion, de découverte, d'enregistrement et de communication et entités configurées pour mettre en oeuvre ces procédés

Country Status (4)

Country Link
US (1) US20240275860A1 (fr)
EP (1) EP4315961A1 (fr)
FR (1) FR3121568A1 (fr)
WO (1) WO2022208033A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170006078A1 (en) * 2015-06-30 2017-01-05 Qualcomm Incorporated Methods and apparatus for codec negotiation in decentralized multimedia conferences
US20180343468A1 (en) * 2017-05-26 2018-11-29 Comcast Cable Communications, Llc Dynamic Encoding Using Remote Encoding Profiles
EP3716692B1 (fr) * 2019-03-28 2023-03-01 Telefonaktiebolaget LM Ericsson (publ) Procédés et appareils pour la découverte de services

Also Published As

Publication number Publication date
WO2022208033A1 (fr) 2022-10-06
US20240275860A1 (en) 2024-08-15
FR3121568A1 (fr) 2022-10-07

Similar Documents

Publication Publication Date Title
EP3632087B1 (fr) Sélection d'une tranche de réseau relative à une application
WO2015092278A1 (fr) Procédé de mise a jour dynamique d'informations obtenues de la part d'un serveur dns
FR3074626A1 (fr) Procede d'acheminement de donnees d'une session initialisee entre un terminal et un serveur
EP2353278B1 (fr) Procede de gestion d'un utilisateur dans un reseau de telecommunications, et dispositif associe
EP4315961A1 (fr) Procédés de gestion, de découverte, d'enregistrement et de communication et entités configurées pour mettre en oeuvre ces procédés
EP4082232B1 (fr) Procédé de configuration d'un equipement utilisateur, equipement utilisateur, entite de gestion de regles, procédé de gestion de règles et système
WO2022208034A1 (fr) PROCÉDÉS DE SOUSCRIPTION ET DE NOTIFICATION, ET ENTITÉS CONFIGURÉES POUR METTRE EN œUVRE CES PROCÉDÉS.
WO2011124810A1 (fr) Gestion de service personnalisee dans un reseau ip
WO2012001270A1 (fr) Procede et systeme de gestion de sessions de communication
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
FR3129506A1 (fr) Entité applicative ayant une architecture de micro-services, entité de contrôle et procédés mis en œuvre par ces entités
EP1494419B1 (fr) Système de transmission de paramètres caractéristiques d'une session de communication d'un terminal vers un serveur distant
WO2022234218A1 (fr) Parametrage d'un terminal
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
EP4343568A1 (fr) Entité pour mettre en oeuvre un service dans un réseau, dispositif applicatif, et procédé d'éxecution d'une opération d'un service
FR3004612A1 (fr) Procede de restauration de service dans un reseau ims
FR3102595A1 (fr) Procédé de diffusion d’une vidéo par un dispositif client, dispositif client et système associé
WO2015044566A1 (fr) Conversion de protocole enrichie dans un réseau de télécommunications pour la fourniture de services à qualité de service améliorée
WO2015181484A1 (fr) Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client
EP2124410A1 (fr) Système, procédé, serveur d'application et HSS pour l'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'une architecture IMS
FR3007604A1 (fr) Procede d'acquisition d'un module de codage/decodage dans un reseau de telecommunications
FR2988951A1 (fr) Procede d'enregistrement d'un serveur aupres d'une pluralite de coeurs de reseau, et serveur.
WO2012049404A1 (fr) Procede de traitement des flux de presence dans un reseau sip
WO2012175895A1 (fr) Transcodage d'un contenu reference par un serveur de contenus
FR2988967A1 (fr) Procede de transmission d'une requete de reconfiguration de session d'un terminal mobile, et procede de transmission d'une information concernant des zones speciales

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20231016

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)