Application entity with a microservices architecture, control entity, and processes implemented by these entities

Abstract

Application entity having a microservices architecture, control entity, and processes implemented by these entities. The invention relates in particular to an application entity (NFk) having a microservices architecture and offering at least one service in a network, said application entity comprising: - a management module configured to notify a control entity (2) managing a plurality of application entities in the network, at least one event affecting a profile of the application entity registered or intended to be registered with said control entity, said profile comprising a plurality of attributes characterizing said application entity; and - a notification module configured to notify each event reported by the management module to the control entity to each microservice of the application entity, said microservice concerned, having subscribed to a notification of said event with the notification module. Figure 1

Description

Title of the invention: Application entity having a micro-services architecture, control entity and methods implemented by these entities Prior art

[0001] The invention belongs to the general field of telecommunications.

[0002] It concerns more particularly micro-service software architectures (also sometimes referred to hereinafter as “micro-service architecture”).

[0003] In a manner known per se, such an architecture is commonly used in the field of software application development. It consists of decomposing an application to isolate the main functions that can be executed independently of one another. These main functions, designated as "services" or "micro-services", can then advantageously be developed and deployed separately, although operating in synergy. The responsibility and number of micro-services depend on the choices of the application designer. The advantage of a micro-services architecture compared to a classic monolithic architecture according to which all the components form an inseparable entity, is that each micro-service can function (or malfunction) without affecting the others, which facilitates the structuring and interventions of the development and maintenance / update teams of the application.

[0004] Microservice architectures, due to the flexibility of each microservice, are ideally (but not exclusively) integrated into cloud environments known for their agility and offering scalable shared resources. The coordination and supervision of microservices are ensured in real time by an orchestrator, which monitors in particular the load of each microservice instance (also commonly referred to as a "pod" in English). When the load of the pods relating to a microservice exceeds a given threshold, the orchestrator instantiates a new pod in order to respond to the increase in load. Conversely, the orchestrator deletes a pod when it estimates that the current load distributed across all pods falls below a certain threshold. This makes it possible to reduce resource consumption (e.g. CPU (for "Central Processing Unit" in English), memory, energy, etc.).This dynamic mechanism of creating and deleting pods is also known as horizontal scalability or elasticity.

[0005] The 5G (or 5th Generation) core network or core network defined by the 3GPP (or “Third Generation Partnership Project” in English) standard is well suited to cloud environments and can be designed according to a micro-services architecture.

[0006] Indeed, the 5G core network uses network function virtualization (NFV), software-defined networking (SDN) and network slicing technologies. These technologies open up new perspectives for the use of telecommunications networks. In particular, they allow operators to create end-to-end, tailor-made, independent, scalable and agile virtual logical networks for their customers, using the same physical network infrastructure (access network(s), core network, etc.). Through these virtual logical networks, operators are able to provide their customers with optimized solutions for various scenarios corresponding to diverse constraints in terms of functionality, performance and quality of service.Network functions virtualization, or NFV, relies on standard servers to run network services software (also known as network functions, or NFs), while software-defined networking, or SDN, centralizes control of the 5G network through software rather than physical devices. With this virtualization, network functions can be deployed and reconfigured easily, providing greater elasticity.

[0007] Various NF functions of a 5G core network can thus be virtualized, such as for example the network functions for access and mobility management or AMF (for "Access Mobility Management Function" in English), session management 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. The control of these virtualized functions in the 5G core network is ensured by another network function called network function catalog or NRF (or "Network function Repository Function" in English).This NRF function is responsible for providing a client or consumer network function with the information enabling it to interact, directly or indirectly via an intermediary device (or SCP for "Service Communication Proxy" in English) with a server network function ("producer" in English).

[0008] Each NF function of the 5G core network has its own role and logic. It typically provides a plurality of services within the 5G network to other functions of the core network authorized to access them, each service itself having its own role and logic, and may include one or more resources (for example REST resources for "REpresentational State Transfer" in English).

[0009] It follows that a micro-services architecture is particularly well suited for the design of NF functions of a 5G network (note that the 3GPP standard does not impose any specific software architecture). Different approaches (not necessarily exclusive) can be considered: - a service as defined by the 3GPP standard specifications can be seen as a micro-service: the orchestrator then instantiates a new pod to respond to an increase in load; - a service as defined by the 3GPP standard specifications is decomposed according to its resources (e.g. REST) ​​or according to subsets of resources based on choices made by the network function designers. According to this approach, a service is defined as a logical entity, and the services are divided into micro-services according to their resources (e.g. REST) ​​or into more detailed micro-services defined by the designers. Thus, according to the first approach, the entire service constitutes a microservice and is replicated when necessary (i.e. instantiation of a new pod). According to the second approach, microservices are potentially replicated but it is not necessary to replicate the service (i.e. the logical entity).

[0010] 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) via interfaces in the form of APIs (for "Application Programming Interfaces" in English) that the other authorized NF functions can invoke. However, instead of predefined interfaces between the different NF functions that can interact with each other, a service model is used in which the "consumer" NF functions query the NRF network function to discover the "producer" NF functions and communicate with them on the APIs they offer. This advantageously offers 5G network operators great flexibility and adaptability.

[0011] 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 (or "NFProfile") 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. its identifier, its fully qualified domain name or FQDN), type of NF function, how it can be reached, 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 level of the NF function apply). These profiles allow the "consumer" NF functions to discover the providers of particular services and characteristics in the network.

[0012] All NF functions must therefore register their profile with the NRF function. The role of the NRF function is then: - to maintain the profiles of available NF functions and their services; - to allow NF functions to subscribe and be notified of any event likely to affect a profile of an NF function with the NRF function (creation of a new profile, deletion and / or update of a profile registered with the NRF function); and - to offer a discovery service allowing an NF function to retrieve a list of NF functions corresponding to certain criteria in order to consume one or more services provided by these NF functions.

[0013] In addition to the information concerning the profiles of the NF functions of which it wishes to consume certain services, an NF function may be required to use the information contained in its own profile for various reasons, such as for example: - to provide, in accordance with the 3GPP specifications concerning it, certain information (for example information that the NF function must value from attribute values ​​of its profile) in requests that it sends to other network functions as a “consumer” or in responses to requests that it has received as a “producer”; - to enable security checks: for example, we can consider that an NF function does not process a request incompatible with its profile (e.g. corresponding to a network slice for which the NF function is not responsible); - to set the value of certain headers, such as the “Location” header.

[0014] In this context of micro-service architecture that can potentially be (massively) replicated, the problem that arises is how to ensure that the NF function has up-to-date information on its own profile. It should be noted that certain information in the NF function profile may be modified due to the intervention of a third-party entity in the network (such as a network management entity) without the NF function being able to determine for itself that these modifications have taken place. In addition, the micro-service architecture means that a modification made to an attribute during processing of this attribute by a micro-service is not necessarily visible to another micro-service performing another processing on this same attribute, the micro-services in question being designed to execute independently.

[0015] A solution, commonly used by network operators, consists of restarting (immediately or at a later date) the NF function following a change affecting its profile.

[0016] However, the disadvantage of this solution is that it results in a momentary interruption of service, while the NF function becomes operational again. Such an interruption can be detrimental to the network and cause error cases during the transitional restart phase, including when the NF function is stopped properly (e.g., shutdown with deregistration). It is all the more detrimental in a fairly dynamic environment in which the attributes of the NF function profile are likely to change frequently (for operational needs, or depending on the network orchestration and management context, etc.).

[0017] There is therefore a need for a solution that does not have this drawback and allows an NF function to have (almost) immediate access to up-to-date information on its profile.

[0018] It should be noted that this need, although illustrated in the context of a 5G core network and a network function, may also exist in other contexts (e.g. ad hoc networks, peer-to-peer (or P2P for "peer-to-peer" in English), etc.) in which application entities capable of providing one or more services are considered, designed on the basis of a micro-services architecture, integrated for example in a cloud-type environment. Statement of the invention

[0019] The invention responds in particular to the need mentioned above by proposing an application entity having a micro-services architecture and proposing at least one service in a network, said application entity comprising: - a management module configured to signal to a control entity managing a plurality of application entities of the network, at least one event affecting a profile of the application entity registered or intended to be registered with said control entity, said profile comprising a plurality of attributes characterizing said application entity; and - a notification module configured to notify each event reported by the management module to the control entity to each micro-service of the application entity, called the micro-service concerned, having subscribed to a notification of said event from the notification module.

[0020] Correlatively, the invention also relates to a notification method intended to be implemented by an application entity having a micro-services architecture and proposing at least one service in a network, said method comprising: - at least one step of reporting to a control entity managing a plurality of application entities of the network, at least one event affecting a profile of the application entity registered or intended to be registered with said control entity, said profile comprising a plurality of attributes characterizing said application entity; and - a step of notification of each event reported by the management module to the control entity to each micro-service of the application entity having subscribed to a notification of said event from the notification module.

[0021] No limitation is attached to the nature of the application entity. By application entity, we mean here any virtual or software 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., and designed according to a micro-services architecture. It is noted that an application entity can be a network entity (i.e. which has a given functionality in a network), but it can also be equipment located at the edge of the network (at the "edge" in English) or user equipment (or UE for "User Equipment" in English).

[0022] Thus the invention proposes a solution based on the one hand on the reporting by the application entity to the control entity to which it is attached, of any event that it detects affecting its profile, and on the other hand, on the notification of these events to the micro-services of the application entity which have declared themselves interested in them (typically the micro-services carrying out processing operations associated with all or part of the attributes contained in the profile of the application entity). Such an event is for example the creation, modification, or deletion of the profile of the application entity, or the creation, modification, or deletion of one or more attributes of this profile. In other words, the invention allows a dynamic update of the profile of the application entity with the control entity and within the microservices which compose it.

[0023] This real-time availability of information relating to events affecting the profile of the application entity at the level of the control entity but also at the level of the micro-services of the application entity is advantageously achieved without interruption of service. This results in better management of these events at the level of the application entity and a possibility of integrating into each micro-service concerned the changes relating to these events, while avoiding an interruption of service which may prove detrimental to the operation of the network.

[0024] The solution offered by the invention is therefore particularly well suited to a scalable and elastic environment such as cloud-type environments and 5G networks. It makes it possible to simply and efficiently integrate a dynamic update of the attributes of a profile of an application entity (e.g. priority, load, IP addresses / ports, etc.) for any reason whatsoever (operational needs, network operation, updating of the attributes by a network management entity, etc.), and regardless of the frequency of modifications made to this profile.

[0025] Various choices of implementation of the invention can be made.

[0026] For example, in a particular embodiment, the management module is further configured to register the profile of the application entity with the control entity.

[0027] It is possible to envisage that the management module is implemented in the form of a micro-service responsible for all the logic of the application entity with the control entity including, in addition to the aforementioned reporting and registration, other operations such as deregistration of the application entity, sending presence messages (or "heart beat" in English), etc. It should be noted that this micro-service is not a priori intended to be replicated at the level of the application entity. However, in a high availability context, it is possible to envisage replicating this micro-service in a "master" instance and a "slave" instance.

[0028] In one embodiment, the notification module of the application entity is implemented in the form of a micro-service for real-time processing of event streams, also known as “event streaming” in English.

[0029] The implementation of such a micro-service makes it easier to implement the invention. This makes it possible, for example, to exploit existing modules such as the Apache Kafka module or the Redis Streams module.

[0030] Different options can be considered for making available (or equivalently publishing) to the notification module the various events affecting the profile of the application entity reported to the control entity, so that the notification module is then able to inform the relevant micro-services of the application entity (i.e. those having subscribed to the notification of these events).

[0031] Thus, according to a first embodiment option of the invention, the management module is configured to subscribe to the control entity for a notification from the application entity of at least one event affecting its profile with the control entity, the notification module of the application entity then being configured to notify each event notified by the control entity to each micro-service of the entity application, called the micro-service concerned, having subscribed to a notification of this event from the notification module.

[0032] In other words, the application entity subscribes to the control entity for notification of events affecting its own profile (typically for notification of these events to its notification module), which allows the microservices that have subscribed to the notification module of the application entity to be informed in turn of these events (also referred to as micro-services concerned). Preferably, the subscription of the application entity to the control entity takes place as soon as the application entity is started so as not to miss any events.The invention makes it possible, according to this option, to signal to the micro-services modifications affecting the profile of the application entity due to the application entity itself or to third-party entities, such as for example to an entity of operations, management and administration of the network known per se, also designated by entity O AM (for "Operations, Administration and Maintenance" in English), to which the application entity and / or the control entity is attached.

[0033] This mode of operation is innovative and particularly clever. In the state of the art, an application entity subscribes only to events relating to other application entities whose services it intends to consume. The invention proposes to exploit the event notification system existing at the level of the control entity to allow the micro-services of the application entity to be informed in real time, in a relatively simple and homogeneous manner, of the modifications made dynamically to the profile of the application entity, independently of the origin of these modifications (other micro-services of the application entity or third-party entities).

[0034] Furthermore, this first implementation option offers the possibility of setting up operations to control the proper functioning of the control entity, and in particular its notification functionality. Indeed, if an update of the profile at the control entity is not followed by the receipt of the associated notification by the application entity, it can then be assumed that there is a malfunction in the chain of notifications from the control entity imparting the chain of broadcasting notifications to the relevant micro-services of the application entity. It can be envisaged that the management module of the application entity raises an alarm at the level of the control entity or of an entity managing the latter such as for example an OAM entity as mentioned above.

[0035] Other operations that can be implemented using the first implementation option are described later.

[0036] In a particular embodiment, the management module is configured to subscribe to said notification with the control entity before registering the profile of the application entity with the control entity.

[0037] For this purpose, the management module of the application entity considered can for example subscribe to the notification of events relating to the application entities managed by the control entity ensuring the same functionality (e.g. same network function) as said application entity.

[0038] In this way, the application entity is notified of the initial version of its profile (or "initial profile") registered with the control entity. Knowledge of this initial profile by the application entity may prove useful for reconstructing the current profile of the application entity when it is notified of an event.

[0039] Indeed, depending on internal rules, the control entity can notify modifications made to a profile by sending the complete profile including said modifications (for example in the case of the registration of a new profile) or, if only a few modifications are made to a profile already registered with the control entity (e.g. addition or deletion of an attribute, etc.), notify these modifications in the form of a series of transformation operations leading to them, in particular to save bandwidth. In this case, the notification module needs to know the profile of the application entity on which these modifications have been applied to reconstitute the current profile of the application entity in order to notify it to the micro-services concerned.

[0040] It should be noted that this initial profile is normally known to the application entity as soon as it registers it itself via the management module with the control entity. However, depending on the implementation choices made for the application entity, the management module and the notification module can be designed as two separate micro-services operating independently and not communicating with each other. This embodiment allows the notification module to obtain the initial profile by benefiting from the notifications from the control entity.

[0041] In a particular embodiment: - at least one event affecting the profile of the application entity notified by the control entity comprises a change of at least one attribute of said profile, called the previous profile, and is notified in the form of at least one transformation operation leading to said change; - said application entity comprises a processing module configured to obtain a current profile of the application entity by applying said at least one transformation operation to said previous profile and providing the current profile to the notification module, the notifications from the notification module to the relevant microservices of the application entity comprising said current profile.

[0042] This embodiment has a preferred application when the event in question is, for example, a modification of a reduced number of attributes of the profile (addition, deletion or change of a value of a reduced number of attributes).

[0043] It should be noted that the notification method adopted by the control entity (complete profile or series of transformation operations) may be left to the control entity's discretion (e.g. based on internal rules) and / or may be subject to change over time and / or depending on the events considered.

[0044] In a particular embodiment, the processing module is configured to store the current profile.

[0045] In the event of a new event notified by the control entity in the form of a series of transformation operations, the processing entity can use the current profile obtained during the previously notified event as the previous profile of the application entity and apply the transformation operations to it to reconstitute the current profile of the application entity which should be transmitted to the micro-services concerned.

[0046] As mentioned previously, in the first implementation option envisaged here, the application entity can be notified of events affecting its profile due to internal changes to the application entity, but also of events linked to an external intervention.

[0047] Thus, in a particular embodiment, at least one event affecting the profile of the application entity notified by the control entity comprises a change of at least one attribute of the profile of the application entity by the control entity or reported to the control entity by a third-party entity of the network.

[0048] Such a third-party entity may be, for example, an entity for operations, management and administration of the network or O AM as indicated previously. This type of intervention by a third-party entity on the profile of the application entity is, in the state of the art, not directly visible to the application entity and requires a restart of the latter to take into account the attributes modified by the third-party entity. The invention advantageously makes it possible to dynamically integrate these modifications in real time into the operation of the micro-services, and therefore of the application entity, without needing to restart it.

[0049] Similarly, this embodiment makes it possible to inform the application entity of changes made to its profile by the control entity. Such a change is, for example, the change of the value of an attribute defining the state of the application entity from “registered” to “suspended”. Notifying the application entity of this change makes it possible to implement specific logic at the application entity level. aimed at restoring the “saved” state of the application entity, for example by sending presence messages (“Heart-Beat”) if the execution context of the application entity allows it.

[0050] In the first embodiment option which has just been described, the application entity subscribes to the control entity for the events reported to the control entity affecting its own profile. According to a second embodiment option of the invention, the publication of the events affecting the application entity is carried out without external intervention, internally to the application entity.

[0051] Thus, according to this second option, the management module is configured to inform the notification module of said at least one event after it has been reported to the control entity.

[0052] This second option offers the possibility of exchanging a larger quantity of information between the management module and the notification module, by exploiting a communication link internal to the application entity. However, it has the disadvantage that the application entity cannot be informed of modifications to its profile due to the intervention of a third-party entity such as for example an O AM entity or to the control entity itself.

[0053] As appears in what has just been described, the first embodiment option of the invention relies not only on the application entity, but also on the control entity. Thus the invention also aims at a control entity managing a plurality of application entities of a network, each application entity being associated with a profile stored by the control entity comprising a plurality of attributes characterizing said application entity, said control entity comprising: - a recording module, configured to record at least one subscription of a said application entity to a notification of at least one event affecting its profile; and - a notification module, configured to send a notification to said application entity when the control entity detects said event.

[0054] Correlatively, the invention also relates to a method of management by a control entity of a plurality of application entities of a network, each application entity being associated with a profile stored by the control entity comprising a plurality of attributes characterizing said application entity, said management method comprising: - a step of recording at least one subscription of a said application entity to a notification of at least one event affecting its profile; and - a step of notifying said application entity when the control entity detects said event.

[0055] As mentioned previously, in one embodiment, at least one said event affecting the profile of the application entity is reported by said application entity or by a third-party entity of the network or is due to the control entity.

[0056] The control entity and the management method according to the invention benefit from the same advantages mentioned above for the application entity and the notification method.

[0057] In a particular embodiment, the management and notification methods are implemented by a computer.

[0058] 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 application entity in accordance with the invention and comprising instructions adapted to the implementation of a notification method as described above.

[0059] 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 a control entity in accordance with the invention and comprising instructions adapted to the implementation of a management method as described above.

[0060] 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 a partially compiled form, or in any other desirable form.

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

[0062] The information or recording medium may be any entity or device capable of storing the programs. For example, the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a hard disk, or a flash memory.

[0063] On the other hand, the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio link, by wireless optical link or by other means.

[0064] The program according to the invention can in particular be downloaded from an Internet-type network.

[0065] Alternatively, 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 the management, recording and communication methods according to the invention.

[0066] According to yet another aspect, the invention relates to a system of a network comprising a plurality of application entities of said network in accordance with the invention and a control entity managing said plurality of application entities.

[0067] In a particular embodiment, this control entity is in accordance with the invention.

[0068] The system benefits from the same advantages cited above as the notification and management methods, the application entity and the control entity according to the invention.

[0069] It is also possible to envisage, in other embodiments, that the notification and management methods, and the application and control entities according to the invention present in combination all or part of the aforementioned characteristics. Brief description of the drawings

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

[0071] [Fig-1] [Fig.l] represents, in its environment, a system in a network in accordance with the invention, in a first embodiment;

[0072] [Fig.2] [Fig.2] 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.l];

[0073] [Fig.3] [Fig.3] represents the functional modules of an application entity in accordance with the first embodiment of the invention of the system of [Fig.l];

[0074] [Fig.4] [Fig.4] represents the functional modules of a control entity in accordance with the first embodiment of the invention of the system of [Fig.l];

[0075] [Fig.5] ;

[0076] [Fig.6] Figures 5 and 6 represent the main stages of a method of notification and a management method according to the invention as implemented in the first mode by the entities of the system of [Fig.l];

[0077] [Fig.7] [Fig.7] represents, in its environment, a system in a network in accordance with the invention, in a second embodiment;

[0078] [Fig.8] [Fig.8] schematically represents the hardware architecture of a computer capable of hosting an application entity belonging to the system of [Fig.7], according to the second embodiment of the invention;

[0079] [Fig.9] [Fig.9] represents the functional modules of an application entity belonging to the system of [Fig.7], according to the second embodiment of the invention;

[0080] [Fig. 10] [Fig. 10] represents the main steps of a notification method according to the second embodiment of the invention as implemented by the application entity of [Fig.9]. Description of the invention

[0081] Preliminaries

[0082] We will now describe the invention in more detail in two embodiments based respectively on the two options introduced above.

[0083] To illustrate these two embodiments, a CN core network of a 5G communications network as defined by the 3GPP standard is considered. This CN core network comprises a plurality of application entities, which are here instances of network functions each proposing one or more services in the CN core network, such as for example AMF, SMF, NSSF, PCF network functions, etc.

[0084] For the sake of simplification, the network function instances considered here are all virtualized instances, in other words software entities, which execute various service logics making it possible to ensure the main functions of the CN core network (e.g. management of mobility and access to the core network, definition and application of network policies, billing, selection of network slices, etc.). It is assumed that these software entities are designed on the basis of a micro-services architecture, as introduced previously.

[0085] Each service executed by an application entity may comprise one or more operations, and itself be designed according to different types of architecture. Thus, by way of illustration but in no way limiting, it is more specifically considered here that an application entity comprises at least two services Xk and Yk such that: - the Xk service is a micro-service which can, as such, be replicated, for example under the control of a CN core network orchestrator as mentioned above; and - the Yk service is a logical entity composed of a plurality of microservices, each of which can be replicated, also under the control of said orchestrator. Replication of the Yk service is however not necessary.

[0086] Each application entity therefore relies on a plurality of micro-services.

[0087] The application entities considered here are managed by a control entity, which is also here a software entity. In the example considered here of a 5G core network, this control entity is a virtualized NRF network function, in other words a catalog storing a profile for each of the application entities. Each stored profile comprises a plurality of attributes, characterizing the operational state of the associated application entity (e.g. its availability, its priority relative to other application entities of the same type (e.g. ensuring the same network function in the example considered here), its load, its capacity, since when it started, etc.), its characteristics (e.g. its identifier, its fully qualified domain name or FQDN), type of NF function, how it can be reached (IP address(es), port(s)), etc.), the services it offers (e.g. Xk and Yk here, and the priorities associated with the services), the resources it manages, etc. Attributes can also be defined per service offered by the application entity considered (in other words, attributes specific to service Xk and / or service Yk in the example considered here). It should be noted, however, that each service (e.g. Xk and Yk here) offered by an application entity is defined only once in its profile.

[0088] Some of the attributes of the profile of an application entity are likely to be modified depending on the evolution of the micro-services architecture on which the application entity in question is based: for example, if the orchestrator instantiates new pods for a micro-service of the application entity (in other words replicates the micro-service in question), the load of the application entity may evolve, and new IP addresses / ports may be allocated to this application entity. According to other examples, the NRF control entity may change the attribute relating to the priority, and an OAM type network management entity may modify the capacity of the application entity (i.e. reduce or increase it).

[0089] Certain attributes of the profile can also be modified according to the evolution of the logical architecture of the CN core network, controlled for example by an OAM entity as presented previously. This logical architecture in fact conditions the functional behavior of the application entity (e.g. addition / deletion of network slices, etc.) and the value of the corresponding attributes associated with it.

[0090] According to yet another example, it is a micro-service of the application entity which may be required to modify an attribute of the profile of the application entity which it processes.

[0091] In any case, as mentioned previously, it is important that each microservice of an application entity required to process one or more attributes of its profile has at its disposal the current value of this or these attributes. Such processing may consist, for example, of providing the value of this or these attributes to other application entities.

[0092] Thus, let us cite as an illustration in the context of a 5G network, the PostSmContext operation of the Nsmf_PDUSession service offered by the SMF network function as “producer” to the AMF network function as “consumer” and of which certain parameters of the service request must be valued by the AMF network function from attributes of its profile. More specifically, this service relies on attributes of type SmContextCreateData (and in particular on the attributes servingNfld and servingName) whose values ​​come from the profile of the AMF network function, and which are then used by the SMF network function when it consumes the NamfCommunication service provided by the AMF network function. The same logic applies to the NsmJ'PDUSession service offered by the SMF network function, which must use the smfServicelnstanceld and recoveryTime attributes in its acceptance response to the service request, based on attributes in its profile, and more specifically, the attributes of its Nsmf_PDUSession service. This example clearly illustrates that there is a link between the NamfCommunication "consumer" service of the AMF network function and the Nsmf_P DU Session "producer" service of the SMF network function, established during the processing by the SMF network function of the PostSmContext operation. This link allows both parties to find their "interlocutor" for other processing operations where this link is important. For example, as shown in [Fig.4].3.2.2.1-1 of the TS 23 document.502 entitled "Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2; (Release 16)", vl6.9.0, September 2021, this PostSmContext operation causes asynchronous processing on the side of the SMF "producer" network function. At the end of this ("potentially long") processing, the SMF "producer" network function specifically informs the AMF "consumer" network function that initiated this processing using the attributes described in the SmContextCreateData type of the status of this processing via a specific operation (N!N2MessageTransfer operation of the NamfCommunication service).

[0093] Another use case for these attributes is, for example, the association mechanism (or "binding" in English) described in particular in document TS 29.500 (in paragraph 6.12), when the AMF and SMF network functions reverse their roles of "consumer" and "producer" for the same context. An association indication (or "binding indication" in English) can then be provided in the service request of the initial "consumer" service, comprising at least one of the following attributes: NF Instance ID, NF Service Instance 1D, NF Set ID or NF Service Set ID which typically can be obtained from the initial "consumer" service's own profile.

[0094] The NRF control entity itself offers a plurality of services including in particular discovery, management (including registration / deregistration / update operations), and booting services, which for example respectively take up the logic of the Nnrf_NFDiscovery, Nnrf_NFManagement and Nnrf_Boostrapping services described in particular in the 3GPP TS 23.502 documents cited above and TS 29.510 entitled “Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3”, vl6.9.0, September 2021.

[0095] In the example considered here, the application entities considered and the NRF control entity are as defined in the 3GPP standard (and the appropriate specifications according to the functionalities offered by the application entities, as well as the specification document TS 29.510 for the NRF control entity), except for the adjustments necessary for the implementation of the invention described below.

[0096] The preceding assumptions are given purely for illustrative purposes and are not limiting in themselves. It is possible to envisage applying the invention in contexts other than a 5G core network (e.g. cloud environment), to application entities other than network functions, executing a different number of services, these being able to be designed according to one or other of the architectures set out above, and to a control entity other than an NRF function depending on the context envisaged. In addition, the invention also applies in other configurations in which only some of the application entities considered (at least one) are virtualized entities having a micro-services architecture, the other application entities being able to rely on a monolithic architecture or be physical application entities.

[0097] First embodiment

[0098] Based on the preliminary context which has just been introduced, [Fig. 1] represents, in its environment, a system 1 of a network, in accordance with the invention, in a first embodiment of the invention.

[0099] System 1 comprises: - application entities NF1,...,NFN as mentioned in the preliminary section, which are in accordance with the first embodiment of the invention; and - an NRF control entity as mentioned in the preliminary, in accordance with the first embodiment of the invention, and referenced by 2.

[0100] As indicated previously, the entities of the system 1 (entities NF1,...,NFN and entity NRF 2) are software entities, designed according to a microservices architecture, and hosted by physical devices of the core network CN, such as for example servers. These servers have the hardware architecture of a computer 3, as shown schematically in [Fig.2].

[0101] The computer 3 comprises in particular a processor 4, a random access memory 5, a read-only memory 6, a non-volatile memory 7, and communication means 8 allowing in particular the entities of the system 1 to communicate with each other and with other elements where appropriate of the core network CN or of another network, for example, with reference to [Fig.l], with an OAM entity 9 for operations, administration and maintenance, already mentioned previously. It is noted that for the sake of simplification in [Fig.l], a single OAM entity is represented, however, depending on the implementation choices made by the operator of the core network CN and the designers of the entities of the system 1, several OAM entities may be considered.

[0102] The communication means 8 rely 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 service-based software interfaces or SBIs. These software interfaces are APIs (for “Application Programming Interfaces” in English) which here use the HTTP / 2 protocol.

[0103] The read-only memory 6 of the computer 3 constitutes a recording medium in accordance with the invention, readable by the processor 4 and on which a computer program in accordance with the invention is recorded.

[0104] More specifically, the read-only memory 6 of the computer 3 comprises, when the latter hosts an application entity NFk, k=l,.. .,N in accordance with the invention, a recording of a computer program PROG-NFk, comprising instructions defining the main steps of a notification method according to the first embodiment of the invention.

[0105] This program PROG-NFk defines functional modules of the application entity NFk, k=l,.. .,N which rely on or control the hardware elements 4 to 8 of the computer 3 mentioned above. These modules include in particular in the first embodiment, as illustrated in [Fig.3]: - an NFk-A management module (or agent) including here: • a NFinst-MNGR sub-module for managing instances of services Xk and Yk, configured to signal to the NRF 2 control entity managing the application entities NF1,.. .,NFN, any event affecting the profile, noted NF_PROFk, of the application entity NFk. Such an event may be the registration (or equivalently, the creation) of the NF_PROFk profile with the NRF 2 control entity, a modification made to this profile (creation, changes or deletion of one or more attributes), or even a deregistration (or equivalently a deletion) of the NF_PROFk profile registered with the NRF 2 control entity; and • a subscription management sub-module SUBS-MNGR, configured to subscribe to the NRF 2 control entity for a notification of events affecting the NF_PROFk profile of the NFk application entity registered with the latter. In the first embodiment described here, this subscription is carried out by the SUBS-MNGR sub-module before the NFinst-MNGR sub-module registers the NF_PROFk profile with the NRF 2 control entity. In addition, the SUBS-MNGR sub-module here subscribes to all events likely to affect its profile with the NRF 2 control entity; however, as a variant, it may be envisaged that it only subscribes to specific events (for example to events concerning a given service provided by the application entity NFk). It is noted that the subscription management sub-module SUBS-MNGR can also be configured to implement other operations relating to the subscription thus created with the NRF 2 control entity. In particular, if the subscription in question has a duration or a validity date, it can be configured to regularly update this duration or this validity date with the NRF 2 control entity so that the subscription does not expire; a reception module NFk-B, configured to receive event notifications issued by the control entity NRF 2 corresponding to the subscription of the sub-module SUBS-MNGR. These notifications may take different forms, at the discretion of the control entity NRF 2. They may in particular comprise the profile of the application entity NFk in its entirety, including the change(s) corresponding to the notified events, or only one or more transformation operations which, applied to the previous version of the profile of the application entity, translate this or these changes. To be able to manage this second scenario, the reception module NFk_B is configured to obtain and store a current (i.e. up-to-date) profile of the application entity NFk by applying the transformation operation(s) to the previous profile of the application entity NFk (the reception module is thus a processing module within the meaning of the invention).When it receives a new event notification, the NFk-B receiving module retrieves the stored profile and uses it as the previous profile to apply the transformation operation(s) included, if applicable, in the new notification. It should be noted that if it does not have a profile in memory (typically at startup of the NFk application entity or the NFk-B receiving module), the NFk-B receiving module can directly retrieve the current profile from the NRF 2 control entity as described in more detail later; and . an NFk-C notification module, configured to notify each event reported by the NRF 2 control entity and received by the NFk-B reception module to each micro-service of the NFk application entity, called the micro-service concerned, having previously subscribed to a notification of this event from the NFk-C notification module. The subscription of the micro-services of the NFk application entity to the NFk-C notification module does not pose any difficulty in itself for those skilled in the art and depends on the implementation chosen for the notification module. In the first embodiment envisaged here, only the micro-services carrying out processing on one or more attributes of the profile of the NFk application entity subscribe to notifications of events affecting this profile. In addition, it can be envisaged that a micro-service only subscribes to the notification of events affecting the attribute(s) of the profile concerning it. Each event is notified here by the NFk-C notification module to the micro-services concerned in the form of the complete current profile NF_PROFk of the NFk application entity integrating the change(s) corresponding to this event. This current profile is received by the NFk-C notification module from the NFk-B reception module. In the embodiment described here, the NFk-C notification module is designed as a micro-service for real-time processing of event streams or event-stream in English. Examples of such a micro-service are for example the Apache Kafka and Redis Streams micro-services.Note that the micro-services of the NFk application entity can be configured to subscribe only to specific events affecting the NF_PROFk profile of the NFk application entity, depending in particular on the functionality they execute (e.g. affecting particular attributes of the profile, and / or the service to which they are attached in the example of the Yk service).

[0106] It is noted that in the first embodiment described here, the communications within the NFk application entity between its various software modules and sub-modules are based on the HTTP / 2 protocol. However, this assumption is not limiting in itself, and other communication protocols may be envisaged, such as for example the QUIC, RPC (for “Remote Procedure Call” in English), CORBA, etc. protocols.

[0107] Furthermore, in the first embodiment described here, three distinct modules (NFk-A, NFk-B, NFk-C) have been considered; however, this is a matter of choice of implementation of the invention (for example three micro-services respectively taking up the functional logic of these three modules), and as a variant, another choice of implementation of the invention can be considered (for example, the notification module embedding the reception module).

[0108] When the computer 3 hosts an NRF 2 control entity in accordance with the invention, its read-only memory 6 comprises a recording of a PROG-2 computer program, comprising instructions defining the main steps of a management method according to the first embodiment of the invention.

[0109] This program PROG-2 defines functional modules of the NRF control entity 2 which rely on or control the hardware elements 4 to 8 of the computer 3 mentioned above. These modules include in particular in the first embodiment, as illustrated in [Fig.4]: a receiving module 2-A, configured to receive from network entities, reports of events affecting the profiles of the application entities that the NRF control entity 2 manages. Such an event, as indicated previously, can be a recording (i.e. a creation) of a profile of an application entity, a modification of an existing profile stored with the NRF control entity 2 (e.g. an addition, a change and / or a deletion of one or more attributes) or even a deletion of an existing profile stored with the NRF control entity 2. It is noted that the events can be caused and reported by the application entities themselves but also caused and reported by third-party entities of the network, such as for example by the OAM entity 9 mentioned previously; a registration module 2-B, configured to register at least one subscription of at least one application entity NFk, k=l,.. .N, managed by the NRF control entity 2 to a notification of at least one event as described above, affecting a profile registered or intended to be registered with the NRF control entity 2. It should be noted that the NRF control entity 2 is thus distinguished from the NRF entities of the state of the art (and in particular those defined in the current specifications of the 3GPP standard) in that the registration module 2-B is required not only to register subscriptions of application entities to events affecting profiles of other application entities (for example, application entities whose services they want to consume or with which they are supposed to communicate), but also to register subscriptions of application entities to events affecting their own profiles; and a notification module 2-C, configured to send notifications to the application entities that have previously subscribed to the registration module 2-B when the NRF control entity 2 detects events corresponding to these subscriptions. These events may have been reported to it via its reception module 2-A or be due to the NRF control entity 2 itself. As mentioned previously, the notification module 2-C can notify these events in different forms: it can notify in its entirety the profile of the application entity concerned by the event including the modification(s) resulting from this event, or notify only the transformation operation(s) that have been applied to the profile of the application entity as a result of the event in question.The choice of one or other of these forms is decided here by the NRF 2 control entity and can vary from one event to another, for example in order to save bandwidth: for example, when a new . profile is created with the NRF 2 control entity, it can notify the entire profile; conversely, when only a few attributes of the profile are modified due to the detected event, it can decide to notify only the transformation operations to be applied to the current profile of the application entity to obtain these modifications. Of course, other forms of notifications can be considered, such as for example the notification of the new value(s) of the attribute(s) having been modified by the event.

[0110] It is noted that, in the event that a micro-services architecture is envisaged to also implement the NRF 2 control entity, the frequency of modifications to the profile of an application entity with the control entity, regardless of the origin of these modifications, is generally sufficiently low so that a single instance of a micro-service implementing the reception module is sufficient to process the traffic of the reports. Furthermore, the traffic induced by the notifications emitted by the notification module for the purposes of the invention should have almost no impact on the network bandwidth, even multiplied by the number of application entities of the network functions type in a 5G core network.

[0111] We will now describe, with reference to [Fig.5], the main steps of a notification method and a management method according to the invention, when they are implemented respectively by the application entity NFk, k an integer between 1 and N, and the control entity NRF 2 of the system 1, in the first embodiment.

[0112] In the first embodiment described here, it is assumed as a preliminary that the application entities NF1,.. .,NFN are attached to the control entity NRF 2 and have been configured with a reachability address (e.g. URI for “Uniform Resource Identifier”) of the latter. It is also assumed that the micro-services of each application entity NFk, k=l,.. .,N, carrying out processing on one or more attributes of the profile of the application entity NFk, have previously subscribed to the notification module NFk-C of the application entity for the notification of events affecting the profile of the application entity NFk (or possibly only the attributes of the profile in question impacting them), as mentioned previously.

[0113] As soon as the application entity NFk is started (step E10), the latter's subscription management sub-module SUBS-MNGR creates a subscription with the control entity NRF 2 via its API in order to subscribe to notifications of any event affecting its own profile with the control entity NRF 2 (in other words likely to lead to a change of the profile in question with the control entity NRF 2, whatever the nature of this change (creation, modification of attributes, deletion)) (step E20). For this purpose, it provides information in the request of subscription that it addresses to the NRF 2 control entity via its API (defined in the 3GPP TS 29.510 document introduced previously): - the nflnstanceldCond attribute (which designates the NF function instance targeted by the subscription) with the nflnstanceld value of the NFk application entity (included in its own NF_PROFk profile); - the nfStatusNotificationUri attribute (which designates the resource to which notifications should be sent) with the value of the reachability address, namely the URI in the example considered here, of the NFK-B reception module which is intended to receive notifications of updates to the NF_PROFk profile; and - optionally, the validityTime attribute (which characterizes the validity period of the subscription) with the end date of validity of the subscription. It should be noted that in the first embodiment described here, the SUBS-MNGR sub-module is configured to extend this expiration date if necessary so that the subscription always remains active during the operation of the NFk application entity. For this purpose, it can use a known UpdateSubscription operation.

[0114] Alternatively, the subscription of the SUBS-MNGR sub-module may more generally target application entities of the same type as the NFk application entity (rather than specifically designating the NFk application entity), for example providing the same functionality or corresponding to the same network function as the NFk application entity, so that any modification affecting the profile of such an application entity (and therefore incidentally of the NFk application entity) is notified to the NFk application entity and more particularly to its NFk-B reception module.

[0115] Upon receipt of the subscription request from the application entity NFk (step F10), the control entity NRF 2 via its recording module 2-B records the information relating to this subscription request (step F20).

[0116] Then, in the first embodiment described here, once the subscription has been created, the management sub-module NFinst-MNGR registers with the control entity NRF 2 the NF_PROFk profile of the application entity NFk, in a manner known per se as described in the document 3GPP TS 29.510 (paragraph 5.2.2.2) (step E30). In particular, it sends here an HTTP PUT registration request in the body of which it provides the NF_PROFk profile of the application entity NFk.

[0117] This NF_PROFk profile, as detailed previously, comprises a plurality of attributes characterizing the NFk application entity, and in particular, in the illustrative example envisaged here, the attributes listed in the document TS 29.510 in table 6.1.6.2.2-1 in section 6.1.6.2.2. These attributes include, in a non-exhaustive manner, the identifier (nflnstanceld) of the NFk application entity (which is an instance of a given network function) to be created (the same identifier as that provided during the subscription if applicable), the type (nfType) of the NFk application entity (i.e. type of the network function here), the state (nfStatus) of the application entity, its name (nflnslanceNamep the PLMN network (for "Public Land Mobile Network" in English) (plmnList) to which it is attached, its IPv4 and IPv6 addresses (ipv4Addresses, ipv6Addresses\ its priority (priority) in relation to other application entities of the same type (i.e. other instances of the same network function), its capacity (capacity), its load (load), its location (locality), etc.

[0118] This request to register the NF_PROFk profile with the NRF 2 control entity constitutes in itself a signaling of an event affecting the profile of the NFk application entity intended to be registered with the NRF 2 control entity within the meaning of the invention.

[0119] Upon receipt of the registration request by the reception module 2-A of the NRF control entity 2 (step F30), the latter registers the application entity NFk: it stores its NF_PROFk profile at the URI indicated in the registration request and associates an “available” status with the application entity NFk (step F40). It can then publish this NF_PROFk profile to other entities in the network querying it about the application entities that it manages.

[0120] Furthermore, this recording triggers the sending, by the notification module 2-C of the control entity NRF 2, of a notification to the network entities having subscribed to a notification of events affecting the profile of the application entity NFk, and in particular, to the application entity NFk itself (and more specifically to its reception module NFk-B) (step F50).

[0121] As mentioned previously, the notification module 2-C is configured here to send in its notifications either the complete profile of the NFk entity, or a series of operations (comprising one or more operations) of transformation to be applied to the previous value of the NF_PROFk profile (“previous profile” within the meaning of the invention) to obtain its current value (“current profile” within the meaning of the invention), in other words the value resulting from the event having triggered the notification and integrating the changes corresponding to this event. The use of one or other of the notification modes is at the discretion of the NRF control entity 2 (for example, according to internal rules of the NRF control entity 2), and can be chosen for example according to the quantity of information translating the modifications made to the profile and to be transmitted to the interested application entities.

[0122] In this case, the event in question corresponds to a creation of the profile of the entity NF_PROFk. The notification module 2-C then chooses for the notification sent during step F50, to send the profile NF_PROFk in its entirety to all the application entities and in particular the NFk entity, having subscribed to notifications of events relating to this profile.

[0123] It is noted that the NFk-B reception module does not necessarily have knowledge, before receiving a notification of events relating to a profile, of the format of the information contained in this notification (i.e. complete profile or series of transformation operations). In the embodiment described here based on a CN 5G core network, as described in document TS 29.510 (table 6.1.6.2.17-1), the notification comprises two attributes associated respectively with a complete profile (nfProfile' attribute) and with a series of transformation operations (profileChanges attribute), only one of which is present, i.e., valued with a non-zero value. In this way, upon receipt of the notification, the NFk-B reception module is able to know whether this notification contains the complete profile of the NFk application entity or only a series of transformation operations. The nfProfile attribute is always present (i.e.set to a non-zero value) when saving an application entity.

[0124] Thus, upon receipt of the notification sent by the notification module 2-C of the control entity NRF 2 by the reception module NFk-B (step E40), two possibilities are possible (test step E50): - if the NF_PROFk profile is contained in its entirety in the received notification (i.e. nfProfile attribute present and set to a non-zero value) (yes response to test step E50, which is the case in the example considered here of the creation of the NF_PROFk profile), the NFk-B reception module stores the complete profile received (which corresponds to the current profile of the NFk-B entity), for example in a non-shared non-volatile memory (step E60); - if the notification does not contain the NF_PROFk profile in its entirety but only a series of transformation operations (comprising one or more transformation operations) translating the changes made to the previous profile of the application entity (i.e. profileChanges attribute present and set to a non-zero value) (response no to test step E50), the NFk-B reception module obtains the previous profile (before modifications linked to the event) and reconstitutes / evaluates the current NF_PROFk profile (in other words obtains an updated version of this profile) by applying to it the series of transformation operations contained in the notification (step E70). Then it stores the current profile thus obtained, in its non-shared non-volatile memory, in order to be able to use it as the previous profile to process a next notification from the NRF 2 control entity if necessary (step E80).It should be noted that during step E70, if it does not have in memory the previous profile of the NFk application entity (which ultimately corresponds to . to the current profile of the application entity before receiving the notification in question), the NFk-B receiving module can then query the NRF 2 control entity to obtain the current profile NF_PROFk registered with the NRF 2 control entity, for example by using the GetNFInstance operation (belonging to the Nnrf_NFManagement service defined by the 3GPP standard in the TS 29.510 document cited above). In this case, exceptionally it does not take into account the content of the notification and stores the current profile obtained by querying the NRF 2 control entity in its non-shared non-volatile memory for later use as described above.

[0125] Regardless of the option that applies, the reception module NFk-B then transmits the current profile NF_PROFk of the application entity NFk (as received from the control entity or reconstituted by the reception module) to the notification module NFk-C (step E90). In the example of a notification module implemented in the form of a micro-service for real-time processing of event streams, this transmission results in the publication by the reception module NFk-B of the current profile NF_PROFk in the theme (or "topic" in English) provided for this purpose of the event-stream micro-service, so that it is broadcast as is to the micro-services of the application entity NFk concerned.

[0126] The notification module NFk-C stores the current profile NF_PROFk (e.g., replacing the previous profile), for example in a non-shared volatile memory (step E100), then notifies the micro-services that have previously registered with it to be informed of the events affecting the profile of the application entity NFk (in other words, having subscribed to the notification module NFk-C for the notification of these events), and more particularly here informed of the creation of the profile of the application entity NFk (step E110). The notification sent by the notification module NFk-C to the micro-services concerned here includes the current profile NF_PROFk in its entirety.

[0127] [Fig.6] represents the management by the application entity NFk and by the control entity NRF2 of other events affecting the profile NF_PROFk of the application entity NFk than the creation of this profile itself.

[0128] Such an event may be due to the NFk application entity itself, to a third-party entity of the network, for example to the OAM entity 9, or to the NRF control entity 2. It typically consists of the modification of one or more attributes of the NF_PROFk profile or a deregistration of the NFk application entity with the NRF control entity 2 resulting in a deletion of its profile.

[0129] This event, when it occurs (test step 120) at the level of the NFk application entity, is signaled by the NFinst-MNGR management sub-module to the control entity NRF 2 (step E130). As with notifications sent by the control entity, the event can be reported in the form of the complete NF_PROFk profile of the NFk application entity or in the form of a series of transformation operations.

[0130] Upon receipt of the signal from the application entity NFk by the reception module 2-A of the control entity NRF 2 (step F60), the latter updates the profile NF_PROFk of the application entity NFk to reflect the modifications signaled by the application entity NFk (step F70).

[0131] This update triggers the sending, by the notification module 2-C of the control entity NRF 2, of a notification to the network entities having subscribed to a notification of events affecting the profile of the application entity NFk of the type reported during step F60, and in particular, to the application entity NFk itself (and more specifically to its reception module NFk-B) (step F80).

[0132] As in step F50 previously described, the notification module 2-C is configured here to send in its notifications either the profile of the complete NFk entity, or a series of operations (comprising one or more operations) of transformation to be applied to the previous profile of the application entity NFk to obtain its current profile NF_PROFk. Since this is an event corresponding to a modification of one or more attributes of the profile or a deletion of the profile, the notification module 2-C chooses to send only the transformation operations leading to this modification. It should be noted that beyond a certain number of transformation operations, it can be envisaged that the notification module 2-C decides to notify the current profile in its entirety to the application entity NFk.

[0133] Then follow at the level of the NFk application entity: - by the NFk-B reception module, steps El40 of receiving the notification, E150 of detecting whether the profile is transmitted in its entirety or only in the form of transformation operations, El60 of recording the current profile transmitted where appropriate in its entirety or El70 of obtaining and E180 of recording the current profile of the application entity when the notification only comprises transformation operations, E190 of transmitting the current profile to the NFk-C notification module of the NFk application entity; then - by the NFk-C notification module, steps E200 for storing the current profile then E210 for notifying the micro-services concerned, identical or similar respectively to steps E40 to El 10 described previously.

[0134] The same steps F60 to F80 at the level of the control entity NRF 2 then E140 to E210 at the level of the application entity NFk are executed when an event affecting the profile NF_PROFk of the application entity NFk is signaled by a third-party entity of the network, such as for example by the OAM entity 9 (step G10). This is valid also for steps F70-F80, E140 to E210 when it is the NRF 2 control entity which is at the origin of this event (step F90).

[0135] As mentioned previously, the first embodiment is particularly innovative and clever. It makes it possible to “hijack” an existing subscription / notification mechanism to allow the various micro-services of an application entity to be informed simultaneously and in real time of changes made dynamically to the profile of the application entity, whether by another micro-service of the application entity, the control entity or another third-party entity.

[0136] This first embodiment also offers the possibility of implementing operations to control the proper functioning of the NRF 2 control entity, and in particular its notification functionality. Indeed, if an update of the NF_PROFk profile at the NRF 2 control entity is not followed by the reception of the associated notification by the NFk application entity, it can then be assumed that there is a malfunction in the chain of notifications from the NRF 2 control entity impacting the chain of broadcasting notifications to the relevant micro-services of the NFk application entity. Once such a malfunction is detected, it is possible to envisage the NFk-A management module of the NFk application entity sending an alarm to the NRF 2 control entity or to an entity managing the latter, such as for example an O AM 9 entity.

[0137] The first embodiment also makes it possible to signal to the application entity NFk a change in its operational state in its stored profile NF_PROFk with the control entity NRF 2 (for example, due to the control entity NRF itself or the OAM entity 9) and to trigger at the level of the application entity NFk actions to restore its initial state. In particular, if its state changes from a value of “registered” to “suspended” or “non-operational”, the application entity NFk becomes unavailable for the other application entities, which may prove problematic. The invention allows the application entity NFk, once informed of this change of state, to implement corrective actions, such as, for example, if its execution context allows it, to immediately send to the control entity NRF 2 a presence message (“heartbeat”) aimed at restoring its “registered” state.

[0138] This first embodiment also allows the micro-services of the notified NFk application entity that process requests sent by other entities of the network, to reject these requests as long as the state of the NFk application entity is “suspended” or “non-operational”. In the current state of the 3GPP standard, the “consumer” application entities are responsible for no longer consuming services from an application entity that is in a “suspended” or “non-operational” state. However, there may be a more or less long delay between the moment when the state of the NFk application entity changes to “suspended” or “non-operational” and the moment when the "Consumer" application entities are informed. Conversely, microservices can return to a nominal operating mode (processing requests) as soon as they are notified of a transition from a "suspended" or "non-operational" state to a "registered" state.

[0139] Second embodiment

[0140] We will now describe, with reference to Figures 7 to 10, a second embodiment of the invention. [Fig.7] represents, in its environment, a system 1' of a network, in accordance with the invention, in the second embodiment.

[0141] The system 1' comprises: - application entities NF1',...,NFN', as introduced in the preliminary and which are in accordance with the second embodiment of the invention; and - an NRF control entity, as introduced in the preliminary and referenced in the second embodiment by 2'. The NRF control entity is, in the second embodiment, as described in the 3GPP TS 29.510 document cited above.

[0142] The application entities NF1',...,NFN' of the system 1' are software entities, designed according to a micro-services architecture, and hosted by physical devices of the core network CN, such as for example servers. These servers have the hardware architecture of a computer 3', as shown schematically in [Fig.8].

[0143] The computer 3' comprises in particular a processor 4', a random access memory 5', a read-only memory 6', a non-volatile memory 7', and communication means 8' allowing in particular the entities of the system 1' to communicate with each other and with other elements where appropriate of the core network CN or another network (for example, with reference to [Fig.7], with an OAM entity 9' of operations (or several depending on the implementation choices adopted), administration and maintenance, already mentioned previously). These communication means 8' rely 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 (for "Application Programming Interfaces" in English) which here use the HTTP / 2 protocol.

[0144] The read-only memory 6' of the computer 3' constitutes a recording medium in accordance with the invention, readable by the processor 4' and on which a computer program in accordance with the invention is recorded.

[0145] More specifically, the read-only memory 6' of the computer 3' comprises a recording of a computer program PROG-NFk', comprising instructions defining the main steps of a notification method according to the second embodiment of the invention.

[0146] This program PROG-NFk' defines functional modules of the application entity NFk', k=1,...,N which rely on or control the hardware elements 4' to 8' of the computer 3' mentioned above. These modules include in particular in the second embodiment, as illustrated in [Fig.9]: - a module (or agent) for managing the NFk'-A' instances of the Xk and Yk services configured to signal to the NRF 2' control entity managing the application entities NF1',.. .,NFN', any event affecting the profile, referenced by NF_PROFk', of the NFk' application entity. Such an event may be the registration (or equivalently, the creation) of the NF_PROFk' profile with the NRF2' control entity, a modification made to this profile (creation, changes or deletion of one or more attributes), or even a deregistration (or equivalently a deletion) of the NF_PROFk' profile registered with the NRF 2' control entity. According to the second embodiment, the NFk'-A instance management module is further configured to notify such an event internally within the NFk' application entity; - a configured NFk'-B notification module: • on the one hand, to receive the event notifications issued internally by the instance management module NFk'-A after having reported these events to the control entity NRF 2' (the notification module is therefore a reception module within the meaning of the invention). In the second embodiment, the notifications issued by the management module NFk'-A preferably comprise the current profile of the application entity NFk' in its entirety, including the change(s) corresponding to the notified events, to limit the processing to be carried out by the reception module NFk'-B; and • on the other hand, to notify each event reported by the management module NFk'-A to each micro-service of the application entity NFk', called the micro-service concerned, having previously subscribed to a notification of this event from the notification module NFk'-B, in a manner similar or identical to that described in the first embodiment. The event is notified here by the notification module NFk'-B to the micro-services concerned in the form of the complete current profile NF_PROFk' of the application entity NFk' integrating the change(s) corresponding to this event. In the second embodiment as in the first embodiment, the notification module NFk'-B is designed as a processing micro-service in real-time event stream. Examples of such a microservice are, for example, Apache Kafka and Redis Streams microservices. Note that the microservices of the NFk' application entity can be configured to subscribe only to specific events affecting the NF_PROFk' profile of the NFk' application entity, depending in particular on the functionality they execute (e.g., affecting particular attributes of the profile, and / or the service to which they are attached in the example of the Yk' service).

[0147] As in the first embodiment, communications within the NFk' application entity between its different software modules are based on the HTTP / 2 protocol. However, this assumption is not limiting in itself, and other communication protocols may be envisaged, such as for example the QUIC, RPC, CORBA protocols, etc.

[0148] We will now describe, with reference to [Fig. 10], the main steps of a notification method according to the second embodiment of the invention, when it is implemented by the application entity NFk', k' being an integer between 1 and N.

[0149] In the second embodiment described here, it is assumed as a preliminary that the application entities NF1',...,NFN' are attached to the control entity NRF 2' and have been configured with a reachability address (e.g. URI for "Uniform Resource Identifier") of the latter.

[0150] As soon as the application entity NFk' starts (step E10'), the management module NFk'-A registers with the control entity NRF 2' the profile NF_PROFk' of the application entity NFk', in a manner known per se as described in the document 3GPP TS 29.510 (paragraph 5.2.2.2) (step E20'). In particular, it sends here an HTTP PUT registration request in the body of which it provides the profile NF_PROFk' of the application entity NFk'.

[0151] This NF_PROFk' profile, as detailed previously, comprises a plurality of attributes characterizing the application entity NFk', and in particular, in the illustrative example envisaged here, the attributes listed in the 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 (nfTyped) of the NFk' application entity (i.e., the type of the network function here), the state (nfStatus) of the application entity, its name (nflnstanceNameY), the PLMN network (for "Public Land Mobile Network" in English) (plmnList) to which it is attached, its IPv4 and IPv6 addresses (ipv4Addresses, ipv6Addresses), its priority (priority) relative to other application entities of the same type (i.e., other instances of the same network function), its capacity (capacity), its load (load), its location (localityY, etc.

[0152] This request to register the NF_PROFk' profile with the NRF 2' control entity constitutes a signaling of an event affecting the profile of the NFk' application entity intended to be registered with the NRF 2' control entity within the meaning of the invention.

[0153] Upon receipt of the registration request by the NRF control entity 2', the latter registers the application entity NFk': it stores its NF_PROFk' profile at the URI indicated in the registration request and associates an "available" status with the application entity NFk'. It acknowledges this registration to the application entity NFk'. The NRF control entity 2' can then publish this NF_PROFk' profile to other entities in the network querying it about the application entities that it manages.

[0154] The reception of the acknowledgment of the registration of the profile of the application entity NFk' by the management module NFk'-A (step E30') triggers the sending, by the latter, of a notification to the notification module NFk'-B of the application entity (step E40'). As mentioned previously, the management module NFk'-A is configured here to send in its notification the complete profile of the entity NFk' including the modifications reported to the control entity NRF 2' (in other words the current profile of the application entity NFk' as it is known to the control entity NRF 2'). In an implementation of the invention based on a notification module of the event-stream micro-service type, the sending of this notification has the effect of publishing the profile NF_PROFk' to the notification module.

[0155] Upon receipt of the notification by the notification module NFk'-B, the latter notifies the microservices that have previously registered with it to be informed of the events affecting the profile of the application entity NFk', and more particularly here informed of the creation of the profile of the application entity NFk' (step E50'). The notification sent by the notification module NFk'-B to the microservices concerned here includes the profile NF_PROFk' in its entirety.

[0156] The same steps E20' of reporting by the management module NFk'-A to the control entity NRF 2', E30' of reception by the management module NFk'-A of the acknowledgment from the control entity NRF 2', E40' of notification of the event acknowledged by the management module NFk'-A to the notification module NFk'-B, and E50' of notification by the notification module NFk'-B to the relevant micro-services of the application entity NFk' are repeated for each event detected by the management module NFk'-A affecting the profile of the application entity NFk', namely the modification of one or more attributes of the profile, the deletion of the profile from the control entity NRF 2'.

Claims

Claims

1. Application entity (NFk, NFk') having a microservices architecture and proposing at least one service in a network, said application entity comprising: - a management module (NFk-A, NFk'-A) configured to signal to a control entity (2,2') managing a plurality of application entities of the network, at least one event affecting a profile of the application entity registered or intended to be registered with said control entity, said profile comprising a plurality of attributes characterizing said application entity; and - a notification module (NFk-C, NFk'-B) configured to notify each event reported by the management module to the control entity to each micro-service of the application entity, said micro-service concerned, having subscribed to a notification of said event with the notification module.

2. Application entity (NFk, NFk') according to claim 1 wherein said management module is configured to register said profile of the application entity with the control entity.

3. Application entity (NFk, NFk') according to claim 1 or 2 wherein said notification module is a micro-service for real-time processing of event streams.

4. Application entity (NFk, NFk') according to any one of claims 1 to 3 wherein said application entity is a network function.

5. Application entity (NFk) according to any one of claims 1 to 4 wherein said management module (NFk-A) is configured to subscribe to the control entity for a notification from the application entity of at least one event affecting its profile with the control entity, said notification module (NFk-C) being configured to notify each event notified by the control entity to each micro-service of the application entity, said microservice concerned, having subscribed to a notification of said event with the notification module.

6. Application entity (NFk) according to claim 5 wherein said management module is configured to subscribe to the entity of control to said notification before registering with the controlling entity said profile of the application entity.

7. Application entity (NFk) according to claim 5 or 6 wherein: - at least one event affecting the profile of the application entity notified by the control entity comprises a change of at least one attribute of said profile, called previous profile, and is notified in the form of at least one transformation operation leading to said change; - said application entity comprises a processing module (NFk-B) configured to obtain a current profile of the application entity by applying said at least one transformation operation to said previous profile and provide the current profile to the notification module, the notifications from the notification module to the relevant micro-services of the application entity comprising said current profile.

8. Application entity (NFk) according to claim 7 wherein said processing module is configured to store said current profile.

9. Application entity (NFk) according to any one of claims 5 to 8 in which at least one event affecting the profile of the application entity notified by the control entity comprises a change of at least one attribute of said profile, called previous profile, and is notified in the form of a current profile integrating the change of said at least one attribute compared to the previous profile.

10. Application entity (NFk) according to any one of claims 5 to 9 in which at least one event affecting the profile of the application entity notified by the control entity comprises a change of at least one attribute of the profile of the application entity reported to the control entity by a third-party entity of the network.

11. Application entity (NFk') according to any one of claims 1 to 4 wherein said management module (NFk'-A) is configured to inform said notification module (NFk'-B) of said at least one event after its reporting to the control entity.

12. Control entity (2) managing a plurality of application entities of a network, each application entity being associated with a profile stored by the control entity comprising a plurality of attributes

13.

14.

15.

16.

17. characterizing said application entity, said control entity comprising: - a recording module, configured to record at least one subscription of a said application entity to a notification of at least one event affecting its profile; and - a notification module, configured to send a notification to said application entity when the control entity detects said event. Control entity (2) according to claim 12 in which at least one said event affecting the profile of the application entity is reported by said application entity or by a third party entity of the network. System of a network (1,1') comprising a plurality of application entities (NFk,NFk') of said network according to any one of claims 1 to 9 and a control entity (2,2') managing said plurality of application entities. System (1) according to claim 14 wherein said control entity (2) is in accordance with claim 12 or 13. Notification method intended to be implemented by an application entity (NFk, NFk') having a micro-services architecture and offering at least one service in a network, said method comprising: - at least one reporting step (E30, E130, E20') to a control entity managing a plurality of application entities of the network, at least one event affecting a profile of the application entity registered or intended to be registered with said control entity, said profile comprising a plurality of attributes characterizing said application entity; and - a notification step (El 10,E210,E50') of each event reported by the management module to the control entity to each micro-service of the application entity having subscribed to a notification of said event from the notification module. Method for managing by a control entity (2) a plurality of application entities of a network, each application entity being associated with a profile stored by the control entity comprising a plurality of attributes characterizing said application entity, said management method comprising: - a step of recording (F20) at least one subscription of a said application entity to a notification of at least one event affecting its profile; and - a notification step (F50, F80) of said application entity when the control entity detects said event.

Images