Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
  • H04L51/21—Monitoring or handling of messages
  • H04L51/224—Monitoring or handling of messages providing notification on incoming messages, e.g. pushed notifications of received messages
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W28/00—Network traffic management; Network resource management
  • H04W28/02—Traffic management, e.g. flow control or congestion control
  • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

• the invention belongs to the general field of telecommunications.
• the invention has a preferred but non-limiting application in the context of 5th Generation (or 5G) telecommunications networks defined by the 3GPP (or “ Third Generation Partnership Project”) standard.
• 5G 5th Generation
• 3GPP Third Generation Partnership Project
• 5G networks as defined by the 3GPP standard use network function virtualization (or NFV for "Network Function Virtualization"), software-defined network (or SDN for "Software Defined Networking” in English) and cutting networks into slices, more commonly known as “network slicing” in English.
• network function virtualization or NFV for "Network Function Virtualization”
• SDN software Defined Networking
• 5G networks open up unprecedented prospects for the use of telecommunications networks.
• they enable operators to create end-to-end, tailor-made and independent, scalable and agile virtual logical networks for their customers, all from the same physical network infrastructure (access network(s) , core network, etc.).
• Through these virtual logical networks operators are able to provide their customers with solutions optimized for various scenarios corresponding to various constraints in terms of functionalities, performance and quality of service.
• Network function virtualization or NFV relies on standard servers to run network service software (also called network functions or NFs for “Network Functions”), while software-defined networking or SDN centralizes control of the 5G network by software rather than via physical equipment. Thanks to this virtualization, network functions can be deployed and reconfigured easily, thus providing more elasticity.
• Various network functions of a 5G core network can thus be virtualized, such as for example the access and mobility management network functions or AMF (for "Access Mobility Management Function"), session or SMF (for "Session Management Function” in English), network slice selection or NSSF (for "Network Slice Selection Function” in English), policy control or PCF (for "Policy Control Function” in English), etc
• AMF Access Mobility Management Function
• SMF Session Management Function
• NSSF for "Network Slice Selection Function” in English
• PCF Policy Control Function
• This NRF function is responsible for providing a client or consumer (“consumer”) network function with the information allowing it to interact, directly or indirectly via an intermediate device (or SCP for "Service Communication Proxy” in English), with a server network function (“producer”) offering one or more services in the network.
• the 5G network architecture defined by the 3GPP standard is a service-based architecture (or SBA for “Service Based Architecture”).
• SBA Service Based Architecture
• the functionalities of a 5G network are ensured by a plurality of network functions (or either NF functions in the remainder of the description) virtual nodes providing services to other network functions authorized to access these services, the same network function being able to offer one or more services.
• the NF functions of the 5G core network present the services they offer in the context of the 5G core network (in other words their functionalities) via interfaces in the form of APIs (for "Application Programming Interfaces” in English) that other authorized NF functions can invoke.
• a service model is used in which the NF "consumer” functions interrogate the network function NRF to discover the NF “producer” functions and communicate with them on the APIs they offer. This advantageously offers 5G network operators great flexibility and great adaptability.
• the NRF network function is thus a catalog managing a plurality of NF functions, and storing the profiles of each of these NF functions.
• Each profile includes a plurality of attributes, characterizing the operational state of the NF function (e.g. its availability, its load, since when it started, etc.), its characteristics (e.g. type of NF function, how it can be contacted, etc.), the services it offers, the resources it manages, etc. Attributes can also be defined more specifically at the level of each service (otherwise those defined at the NF function level apply). These profiles allow the NF “consumer” functions to discover providers of particular services and features in the network.
• the NRF network function is updated during the activation and deactivation of each of the NF functions that it manages (i.e. during the registration and deregistration of each instance of each of them ) as well as at each resizing of an NF function (the NRF function can in fact manage several instances of the same NF function).
• the 3GPP standard also defines a subscription procedure via which an NF "consumer" function can request the NRF function to be informed of any event affecting an NF "producer” function, such as the availability of a new instance of an NF function type, update of an attribute of an NF function profile, etc.
• the 5G core network uses, for the exchanges between NF functions, and in particular the notification of events, the HTTP client-server protocol and more particularly its HTTP/2 version.
• the HTTP protocol is a protocol initially developed for the web. Optimizing the encoding of content exchanged via the HTTP protocol (e.g. text, images, fonts, etc.), and more particularly the compression of this content, is a key factor now advocated by web players to reduce latency and bandwidth consumption, and significantly improve the user experience.
• the application of this principle to exchanges between NF functions within the 5G core network is also being considered today.
• the payload of an NF function profile provided in a request when registering an NF function, or in a response provided by the NRF function during the discovery mechanism, or still in a notification sent by the NRF function when a profile of an NF function is updated can easily approach 2 megabytes, which, compared to the number of messages exchanged on the 5G core network, can constitute a total load important.
• the client can indicate in the request that it sends to the server, and more particularly in an "Accept-Encoding" header of the request, the different encoding types or formats that it supports (for example an encoding implementing compression such as gzip or deflate).
• the server then returns a response to the client whose body complies with the encoding indications provided by the client, and indicates in a "Content-Encoding" header of the header of its response, the encoding format (and more particularly compression) that it has applied to the content served to the client.
• the negotiation of the encoding when it is implemented, is therefore at the initiative of the client and concerns only the response sent by the server to the client.
• the client has no way of knowing before receiving the response from the server which encoding format the latter supports.
• an NF "consumer” function can determine the encoding formats supported by an NF “producer” function by sending it an OPTIONS type request, the encoding formats supported by the NF “producer” function being returned to it in the response to the OPTIONS request;
• a “producer” NF function can return an "Accept-Encoding" header as described previously containing the encoding formats it supports in a response, for example a response to a request comprising a body such as an HTTP POST request , PUT or PATCH.
• the NF “consumer” function can then use one of the encoding formats provided by the NF “producer” function to encode the body, if applicable, of its next request addressed to the NF “producer” function.
• An OPTIONS request has however only been implemented by the 3GPP standard in the API of the NRF function for the Nnrf_NFManagement management service (which includes the registration, deregistration and update operations mentioned previously) and in the API of the AMF function.
• a generalization of this solution would require implementing the OPTIONS request for all the resources of the different API interfaces of all the NF functions (currently defined and future) comprising HTTP requests that can implement an encoding of their content, and more particularly the HTTP POST, PUT and PATCH requests. This would result not only in cumbersome maintenance of the 5G core network specifications, but also in an increase in the volume of signaling exchanged in the core network (one dedicated transaction for each resource on each API), and the consideration of additional logic for each "consumer" NF function.
• this constraint is limited to notifications sent by the NRF network function, and to a single encoding format, namely the gzip format.
• a "consumer" NF function supports the gzip encoding format in practice: if this encoding format is not supported, the NRF network function exposes itself to a rejection of its notifications.
• the invention offers such a solution by proposing a method for subscribing a first communicating entity to a second communicating entity, said method being intended to be implemented by the first entity and comprising:
• the invention also relates to a communicating entity, called the first entity, comprising:
• a first module configured to request a subscription from a second network entity to obtain information concerning at least one event monitored by the second entity, this subscription request indicating at least one encoding format supported by the first entity;
• a second module activated following detection by the second entity of a said event corresponding to the subscription request, said second module being configured to receive from the second entity a notification comprising information relating to said detected event encoded in the means of a said encoding format supported by the first entity and indicated in the request for subscription.
• the invention also relates to a method for notifying events to a first communicating entity, intended to be implemented by a second communicating entity, this notification method comprising:
• the invention also relates to a communicating entity, said second entity, comprising:
• a reception module configured to receive a subscription request from a first communicating entity to obtain information concerning at least one event monitored by the second entity, this subscription request indicating at least one encoding format supported by the first entity ;
• a sending module activated following detection of a said event corresponding to the subscription request, and configured to send to the first entity a notification comprising information relating to said detected event encoded by means of a said format encoding supported by the first entity and indicated in the subscription request.
• first and second communicating entities can be physical or software entities, belonging to the same network or to distinct networks.
• Such communicating entities are for example network entities, application functions (or "Application Functions") or even user equipment.
• application entities that is to say entities configured to implement determined processing logics, such as in particular entities offering and/or consuming services in a network such as functions network or instances of network functions (e.g. AMF, SMF, NRF, etc.).
• application entities that is to say entities configured to implement determined processing logics, such as in particular entities offering and/or consuming services in a network such as functions network or instances of network functions (e.g. AMF, SMF, NRF, etc.).
• SCP Service Communication Proxy
• the invention advantageously makes it possible to optimize the transmission of notifications sent asynchronously by the second communicating entity to signal, to the communicating entities which have requested it, various events relating to the elements it manages and/or monitors (eg user equipment, network functions, data sessions, etc.). It advantageously does not impose any specific encoding format, but adapts to the capacities of the entities having subscribed to the notification of events.
• Such a format can of course be a compression format such as gzip, deflate, compress, which makes it possible to optimize the performance of the exchanges between the entities in terms of latency and bandwidth in particular, but other encoding formats can also be envisaged, such as for example a base64 encoding format, an invariant format (or "identity") advocating the absence of transformation of the content, or any reversible transformation carried out for a particular purpose (eg reducing the size of content, obtain content compatible with the majority of systems, secure content, etc.), etc.
• the invention thus offers great flexibility and makes it possible to apply different encoding formats to the notifications sent to different entities, or depending on the context in which the first and second entities are located, or even depending on the characteristics of the information. to be notified (sensitivity, size, etc.).
• the invention can be applied to many communicating entities, and to their respective specificities. It thus offers a homogeneous solution which can be transposed in particular to the various network functions of a core network, which facilitates its implementation in a standardized network such as a 3GPP network.
• these events can include the location or the presence in an area of interest of a user equipment or UE (for "User Equipment” in English), or of a group of UEs, the number of UEs in a given area, a loss of connectivity of a UE or a group of UEs, etc.
• UE User Equipment
• these events may include a change of network or PLMN (for "Public Land Mobile Network"), a release or establishment of a PDU session, a change type of access, etc.
• PLMN Public Land Mobile Network
• the solution offered by the invention easily integrates with existing subscription procedures, and in particular in the context of a 3GPP network, with the subscription procedures defined for the various network entities offering a service of exposure of events such as the NRF, AMF, SMF functions mentioned above. It only requires adding among the indications provided during the subscription, the encoding formats supported by the first entity. For example, this or these formats can be provided in particular in the body of the subscription request (e.g. in a field provided for this purpose) with other data relating to the subscription such as the events for which the first entity wishes to be notified , etc.
• the invention therefore does not require the definition of additional logic, nor the exchange of additional messages (such as for example an OPTIONS request and the associated response, or a request containing an Accept-Encoding field and the associated response ), which preserves network performance.
• additional messages such as for example an OPTIONS request and the associated response, or a request containing an Accept-Encoding field and the associated response .
• the encoding format(s) supported by the first entity can advantageously be stored in the subscription context of the first entity: the invention is therefore particularly easy to implement.
• the second network entity is a control entity managing a plurality of application entities of a network.
• the second entity is for example an NRF function of a 5G core network managing a plurality of NF network functions or instances of NF functions.
• the NRF function is a catalog managing a plurality of NF functions, and storing the profiles of each of these NF functions, each profile comprising 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 (eg type of NF function, how it can be reached, etc.), the services it offers, the resources it manages, etc.
• each application entity profile managed by the second entity, stored by it comprises a plurality of attributes including at least one encoding format supported by this application entity.
• This embodiment is particularly advantageous, because it allows the second entity not only to know the encoding formats supported by an application entity as a "consumer" (when it receives notifications from the second entity) , but also, when the second entity manages this application entity, to know the encoding formats supported by it as “producer”. The second entity is then able to publish this or these encoding formats to entities requesting it, for example during a procedure for discovering application entities managed by the second entity verifying one or more given criteria.
• said detected event is a creation, deletion or modification of an element managed by the second entity.
• Such an element is for example a profile of an application entity managed by the control entity, in the example of an NRF network function. But other applications of this embodiment can be envisaged.
• an AMF function such an element can be a profile or a user context grouping the users registered in a network and managed by the AMF function.
• the element in question can be any resource monitored by the second entity (e.g. a PDU session, a user equipment or a group of user equipment, an IP address, a virtual entity, a physical entity, etc. ). No limitation is attached to the nature of this element.
• the notification sent by the second entity is a request conforming to a version of the HTTP protocol.
• the invention has a preferred application in the context of a 5G network based on the HTTP protocol and in particular on the HTTP/2 version of this protocol, for the compression of the contents of notification requests. conforming to this protocol exchanged between the various entities involved in the invention.
• the invention also applies to other protocols than the HTTP/2 protocol, such as another version of the HTTP protocol (HTTP/1.1), or to the SOAP protocols (for "Simple Object Access Protocol in English), CORBA (for “Common Object Request Broker Architecture” in English), gRPC (for “Remote Procedure Call” in English), QUIC, etc., or any other protocol based on the exchange of re- queries and responses, and supporting an encoding of the body content of requests and/or responses, typically a compression of this content.
• HTTP/2 protocol such as another version of the HTTP protocol (HTTP/1.1)
• SOAP protocols for "Simple Object Access Protocol in English
• CORBA for “Common Object Request Broker Architecture” in English
• gRPC for “Remote Procedure Call” in English
• QUIC Remote Procedure Call
• At least one encoding format supported by the first entity and indicated in the subscription request is a compression format.
• the encoding format used to encode the information relating to the event detected in the notification can be a compression format.
• Such a notification may comprise a large volume of data.
• such a notification may comprise one or more profiles in all or part of network functions, or only, where applicable, the attributes of the profile or profiles affected by the event.
• the application of a compression-type encoding format to the information conveyed by the notifications taking into account the large number of notifications likely to be sent by the various entities of a network and the volume of data transmitted by each of them between them, is therefore particularly advantageous in terms of latency and bandwidth.
• said at least one encoding format supported by the first entity is provided in a data structure comprising at least one communication option supported by the first entity.
• This embodiment offers great flexibility and is scalable: it facilitates the application of the invention to new constraints, in terms of communication options.
• the subscription and notification processes are implemented by a computer.
• 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 first network entity in accordance with the invention and comprises instructions adapted to the implementation of a subscription process as described above.
• the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a second network entity in accordance with the invention and comprises instructions adapted to the implementation of a notification process as described above.
• Each of these programs may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable shape.
• the invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.
• the information or recording medium can be any entity or device capable of storing the programs.
• the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a hard disk, or a flash memory.
• the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio link, by optical link without wire or by other means.
• the program according to the invention can in particular be downloaded from an Internet-type network.
• the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the subscription and notification processes according to invention.
• the invention relates to a system comprising at least a first communicating entity and a second communicating entity according to the invention.
• the first and second communicating entities prefferably have all or part of the aforementioned characteristics in combination.
• Figure 1 shows in its environment, a system according to the invention in a particular embodiment
• FIG. 2 schematically represents the hardware architecture of a computer capable of hosting any of the communicating entities according to the invention belonging to the system of FIG. 1;
• FIG. 3 illustrates, in the form of a flowchart, the main steps of a subscription process implemented by a communicating entity of the system of FIG. 2 in a particular mode of the invention.
• FIG. 4 illustrates, in the form of a flowchart, the main steps of a notification method implemented by a communicating entity of the system of FIG. 2 in a particular embodiment of the invention.
• FIG. 1 represents, in its environment, a system 1 in accordance with the invention, in a particular embodiment in which the system 1 is integrated into a CN core network of a 5G communications network as described in the 3GPP standards.
• the system 1 comprises a first communicating entity 2 and a second communicating entity 3 in accordance with the invention implementing within the core network CN a mechanism for subscription/notification of events.
• entity 3 is a network entity managing various elements of the CN core network, implemented in the CN core network or attached to the CN core network, such as for example network functions (NFs), equipment users (UEs), PDU sessions, etc., and monitors different types of events relating to these elements.
• the events monitored by entity 3 and likely to be published are generally predefined, so that a communicating entity can subscribe to the notification of all or part of these events if it is interested in knowing about them.
• an entity in yet another variant, it is possible for an entity to subscribe unconditionally to all the events liable to be exposed by the entity 3 or to events verifying one or more given criteria.
• the invention is not limited to a particular use of the knowledge of the events in question: the entity, and in particular the entity 2, which has subscribed to a notification of events monitored by the entity 3 can use this knowledge, for example, to manage the elements for which it is responsible, to implement the processing entrusted to it, etc.
• the two entities are application network entities, that is to say network entities configured to implement determined processing logics in the core network CN, such as in particular entities offering and/or consuming services in the core network.
• entities 2 and 3 are virtualized instances of network functions such as AMF, SMF, NRF, etc., which execute various service logics making it possible to ensure the main functions of the core network (ex . management of mobility and access to the core network, definition and application of network policies, invoicing, selection of network slices, etc.).
• Each service offered by such a network function may comprise one or more operations.
• a network function designates a virtual instance of a network function, each network function of the core network CN being able to be instantiated multiple times.
• the communicating entity 2 is an AMF network function and the communicating entity 3 is an NRF network function (control entity within the meaning of the invention) managing a plurality of NF network functions, such as AMF, SMF, NRF, etc. network functions.
• NRF network function control entity within the meaning of the invention
• NF network functions such as AMF, SMF, NRF, etc. network functions.
• application entities within the meaning of the invention are included in a known way.
• such an NRF function is a catalog storing, for each of the NF functions that it manages, a profile comprising a plurality of attributes characterizing the operational state of the associated NF function (e.g. its availability, its load, since when it started, etc.), its characteristics (eg type of NF function, how it can be reached, etc.), the services it offers, the resources these services manage, etc.
• the NRF function itself offers a plurality of services including in particular services for discovering the NF functions it manages (and more particularly certain attributes the profile of these NF functions called “producers” allowing NF “consumers” functions to access the services offered by the NF “producers” functions), management (including the registration/deregistration/update operations mentioned above ), authorization and priming (or “bootstrapping”), which use the logic of the Nnrf_NFDiscovery, Nnrf_NFManagement, Nnrf_AccessToken and Nnrf_Boostrapping services described in particular in the document TS 29.510 entitled “Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3”, V16.6.0, December 2020.
• the invention is however not limited to the hypotheses which have just been formulated. As mentioned above, it applies in fact to other configurations of system 1 (several "first" and “second” communicating entities according to the invention), to other networks (eg other generations of networks defined by the 3GPP standard or by other standards, proprietary networks, micro-services architectures, etc.), as well as to other physical or software communicating entities (e.g. to intermediate SCP equipment located on the path of communication between two network functions, application functions, user equipment, network entities, etc.), when subscription/notification mechanisms are implemented.
• the first and second communicating entities belong to the same CN core network, but the invention also applies when the first and second communicating entities belong to different networks, or when one of the entities is external to the network to which the other entity belongs. It can be for example two NRF network functions belonging to two distinct PLMN networks, or a network function and an external application function, etc.
• the same entity can be configured to be "a first entity” within the meaning of the invention with regard to certain entities (this is ie subscribing to the notification of given events), and “a second entity” within the meaning of the invention with regard to other entities (ie notifying given events).
• the AMF network function can be a first entity with regard to the NRF network function, and a second entity with regard to the SMF network functions, NEF (for "Network Exposure Function” in English) or UDM (for “Unified Data Management” in English).
• entities 2 and 3 are software entities, hosted by physical devices of the core network CN, such as servers for example. These servers here have the hardware architecture of a computer 4, as shown schematically in Figure 2.
• the computer 4 comprises in particular a processor 5, a random access memory 6, a read only memory 7, a non-volatile memory 8, and communication means 9 allowing in particular the entities of the system 1 to communicate with each other and with other entities, if any, of the CN core network or external to the CN network.
• These means of communication 9 are based on the one hand, on a wired or wireless communication interface, known per se and not described in more detail here, but also on one or more software interfaces based on the service or SBI (for “Service Based Interface” in English). These software interfaces are APIs which here use the HTTP/2 protocol.
• the read only memory 7 of the computer 4 constitutes a recording medium in accordance with the invention, readable by the processor 5 and on which is recorded one or more computer programs in accordance with the invention.
• the ROM 7 of the computer 4 comprises, when the computer 4 hosts the entity 2, a recording of a computer program PROG2, comprising instructions defining the main steps of a process subscription according to the invention.
• This program PROG2 defines functional modules of a first entity within the meaning of the invention which are based on or control the hardware elements 5 to 9 of the computer 4 mentioned above. These modules include in particular in the embodiment described here, as illustrated in FIG. 1: a first communication module 2A, configured to request a subscription from the entity 3 to obtain information concerning at least one event monitored by the entity 3, the subscription request indicating at least one encoding format supported by entity 2; and a second communication module 2B, activated following detection by the entity 3 of a said event corresponding to the subscription request, this second module 2B being configured to receive from the entity 3 a notification comprising information relating to the detected event, encoded using an encoding format supported by entity 2 and indicated in the subscription request.
• a first communication module 2A configured to request a subscription from the entity 3 to obtain information concerning at least one event monitored by the entity 3, the subscription request indicating at least one encoding format supported by entity 2
• a second communication module 2B activated following detection by the entity 3 of a said event corresponding to the subscription
• the program PROG2 also defines a processing module 2C, configured to use, where appropriate, the notifications received by the second communication module 2B to manage, in the example considered here, elements of the CN core network or attached to it for which entity 2 is responsible.
• the operating module 2C is configured to use in particular the notifications received to effectively manage the access and the mobility of the user equipment for which it is responsible. charge.
• modules 2A to 2C of the entity 2 are described in more detail later, with reference to the steps of the subscription method according to the invention.
• the ROM 7 of the computer 4 comprises, when the computer 4 hosts the entity 3, a recording of a computer program PROG3, comprising instructions defining the main steps of a subscription process according to the invention.
• This program PROG3 defines functional modules of a second entity within the meaning of the invention which rely on or control the hardware elements 5 to 9 of the computer 4 mentioned above. These modules include in particular in the embodiment described here, as illustrated in FIG. 1: a reception module 3A, configured to receive a subscription request from another entity, for example here from entity 2, to obtain information concerning at least one event monitored by the entity 3, this subscription request indicating at least one encoding format supported by the entity 2.
• a reception module 3A configured to receive a subscription request from another entity, for example here from entity 2, to obtain information concerning at least one event monitored by the entity 3, this subscription request indicating at least one encoding format supported by the entity 2.
• an event is for example the creation, deletion or modification of such an attribute profile, or equivalently, the registration and deregistration of network functions managed by the NRF function (which result respectively in the creation and deletion of a profile at the level of the NRF function ), and modifying an attribute profile of a network function.
• the events monitored by entity 3 depend on the services (functionalities) provided by this entity 3, in the CN core network here, and/or on the elements managed by this entity 3.
• such an event can be the creation, deletion or modification of an element managed and/or monitored by the entity 3. But other events can be considered.
• such events may include, for example, as mentioned previously, the location or the presence in an area of interest of a UE or of a group of UEs, the number of UEs in a given area, a loss of connectivity of a UE or a group of UEs, etc.
• these events may include a network or PLMN change, a PDU session release or establishment, an access type change, etc.
• a monitoring module 3B configured to continuously or quasi-continuously monitor the elements managed by the entity 3 and detect, if necessary, the events mentioned above relating to these elements
• a sending module 3C activated following detection by the monitoring module 3B of an event corresponding to the subscription request from the network entity 2 received by the receiving module 3A, and configured to send to the network entity 2 a notification comprising information relating to this detected event encoded using an encoding format supported by the network entity 2 and indicated in the subscription request.
• modules 3A to 2C of the entity 3 are described in more detail later, with reference to the steps of the notification method according to the invention.
• entity 3 the events monitored by entity 3 and the elements that it manages and/or monitors (in the example considered here, elements of the CN core network or attached to the CN core network) are known, and therefore in particular of entity 2.
• the events monitored by the NRF network function are the registration and deregistration of an NF function managed by the NRF function, as well as the modification of a profile of an NF function managed by the NRF function, that is to say in an equivalent way as already mentioned, the creation, deletion and modification of a profile of a network function managed by the entity 3, likely to be published by it to third parties.
• a profile is an element managed by the entity 3 within the meaning of the invention.
• this information can be obtained by entity 2 dynamically, by interrogating entity 3.
• entity 2 i.e. the AMF function in the illustrative example considered
• entity 2 is interested in being notified of the detection of all or part of the events monitored by entity 3, for at least one of the CN core network elements managed by entity 3.
• this subscription request is made by sending an HTTP POST subscription request. It contains, in its body, the subscription data SubscriptionData, namely here in particular information indicating the type of notifications that entity 2 wishes to receive (and more particularly which event(s) associated with which (s) element(s) managed by entity 3), as well as an identifier or so-called callback URI on which entity 2 wishes to receive notifications.
• SubscriptionData namely here in particular information indicating the type of notifications that entity 2 wishes to receive (and more particularly which event(s) associated with which (s) element(s) managed by entity 3), as well as an identifier or so-called callback URI on which entity 2 wishes to receive notifications.
• the subscription request from entity 2 can relate to one or more elements managed and/or monitored by entity 3, for example on elements verifying a given criterion (for example all the NF functions providing a given service or of a given type).
• entity 2 can indicate that it wishes to receive notifications when any of the creation/deletion or modification events of a profile are detected for the instances network functions AUSF (for "AUthentication Server Function” in English), 5G-EIR (for "Equipment Identity Register” in English), SMF, UDM and PCF managed by the entity 3 (NRF function in this example).
• AUSF for "AUthentication Server Function” in English
• 5G-EIR for "Equipment Identity Register” in English
• SMF User Data Management Function
• UDM User Data Management Function
• SubscriptionData data can be specified in the SubscriptionData data such as, for example, a subscription validity period, or one or more conditional parameters, specific to the type of entity 3, which can be monitored to determine whether whether or not to trigger a notification.
• conditional parameters can be for example the attributes of a profile which must be changed to trigger a notification or those which do not need to be monitored conversely.
• the subscription request advantageously includes among the SubscriptionData data, at least one encoding format supported by the entity 2 and which can be used to encode the content of the notifications sent by the entity 3 to entity 2.
• the encoding format or formats indicated in the subscription request include at least one compression format, such as gzip, deflate or compress.
• other encoding formats may be supported by entity 2 (e.g. base64 encoding formats, invariant (“identity”), etc.), and indicated by it in the request for subscription.
• entity 2 is not required to indicate in the subscription request all the encoding formats that it supports. It can select one or more specific encoding formats among those it supports so that one of them is used during notifications.
• the entity 2 defines possibly distinct encoding formats according to the events monitored by the entity 3 or the elements to which these events relate. For example, we can consider defining a compression format with a higher compression rate for content that we know is large in size (e.g. network function profiles), while a compression format with a compression rate lower or invariant encoding format may be indicated 2 for smaller notification contents. This example is of course only given by way of illustration.
• entity 2 can indeed update its subscription to entity 3, for example by using an HTTP PATCH request including in its body, the subscription data modified if necessary.
• the encoding format or formats supported by the entity 2 and indicated in the subscription data SubscriptionData are provided in a data structure, named for example caplnfo, comprising at at least one communication option supported by the entity 2, each communication option being provided in a distinct field or attribute (for example in a Content-Encoding field or attribute of the caplnfo structure for the encoding formats).
• this data structure can include other communication options that can be used by the entity 3 when sending the notifications, such as for example content formats (eg json, xml or others), supported by the entity 2 (provided for example in a Content-Type field or attribute of the caplnfo structure), or encryption algorithms making it possible to encrypt critical information provided if necessary in the notifications sent by entity 3 (provided for example in an Encrypt-type field or attribute of the caplnfo structure), etc.
• content formats eg json, xml or others
• the entity 2 provided for example in a Content-Type field or attribute of the caplnfo structure
• encryption algorithms making it possible to encrypt critical information provided if necessary in the notifications sent by entity 3 (provided for example in an Encrypt-type field or attribute of the caplnfo structure), etc.
• the encoding format(s) can be provided in a dedicated simple field or attribute, for example in a Content-Encoding field or attribute.
• they can be provided in a proprietary field or attribute provided for by the 3GPP standard (known as a “vendor-specific extension”).
• entity 3 receives, via its reception module 3A, the subscription request from entity 2 (step F10).
• entity 3 checks, via its reception module 3A, whether the subscription request made by entity 2 is authorized (test step F20). It can check in particular that the subscription data indicated in the subscription request is consistent with the information it can publish.
• entity 3 creates a subscription context CNT_SUBS(2) for entity 2 and stores the data in the subscription context subscription form SubscriptionData including the encoding formats supported by entity 2 (step F40).
• An HTTP 201 Created response is then returned to entity 2 by entity 3 to inform it of the success of its subscription request (step E20, FIG. 3).
• the entity 3 monitoring module 3B is configured to continuously or quasi-continuously (and in real time) monitor the elements managed and/or monitored by the entity 3 and more particularly the occurrence of events that entity 3 is likely to expose (in the example of the NRF function, the creation/deletion or modification of profile(s) of network function(s) managed by the NRF function ) (monitoring step F50 and test step F60).
• the entity 3 monitoring module 3B detects one of these events for at least one of the elements that it manages and/or monitors (answer yes to test step F60) , it checks whether the detected event corresponds to one of the subscription requests it has received (test step F70), and more particularly here, whether the detected event corresponds to the subscription request made by the entity 2 For this purpose, it consults the subscription data contained in the CNT_SUBS(2) context and compares them with the characteristics of the detected event (for example, with the nature of the event, the element concerned by this event, etc. .).
• the detected event corresponds to the subscription request formulated by the entity 2, in other words, the event detected by the monitoring module 3B of the entity 3 corresponds to an event for which the entity 2 wishes to be notified (answer yes to test step F70).
• the entity 3 then sends, via its sending module 3C, a notification to the entity 2 to inform it of the detected event (step F80).
• This notification is for example here an HTTP POST request.
• It includes, in its body, NotificationData information relating to the detected event, specific to this event.
• this Notification Data information may include all or part of the profile of the network function affected by the event, or more precisely all the attributes of this profile intended to be published if it is a profile creation type event, or if it is a profile modification type event, all the attributes of this profile intended to be published or only those which have been modified.
• the NotificationData information includes the URI of the NF function instance concerned and the type of event detected (i.e. deletion of the profile or deregistration of the NF function).
• the NotificationData information provided in the notification request is encoded by means of one of the encoding formats supported by the entity 2 and stored in the CNT_SUBS(2) context of its subscription.
• the sending 3C module selects in the CNT_SUBS(2) context a compression format to encode the NotificationData information. It indicates, in accordance with the HTTP protocol, in the Content-Encoding header of the notification request, the encoding format applied.
• the sending module 3C can also apply these communication options to NotificationData information in addition to encoding.
• entity 2 receives, via its second module 2B communication, the notification sent by the entity 3 and informing it of the detected event (step E30).
• Entity 2 extracts the NotificationData information contained in the notification and decodes it according to the encoding format applied by the 3C sending module of entity 3 and signaled in accordance with the HTTP protocol in the headers of the request notification. Then the processing module 2C uses the information thus decoded, for example to manage the elements of the core network CN or attached thereto for which the entity 2 is responsible. As mentioned previously, the way in which the processing module 2C uses this information depends on the services offered by the entity 2, in the core network CN here, and/or on the relevance of this information.
• the invention makes it possible in a simple way to optimize the exchanges between the various entities of the system 1, and more particularly the notifications sent by the entity 3 to the entity 2.
• the encoding formats supported by entity 2 preferably including a compression format, are provided when entity 2 subscribes to the events monitored by entity 3 so that entity 3 can compress the information it sends to entity 2 without having to implement additional exchanges for negotiating the encoding format to be used.
• additional measures can be implemented elsewhere, in the core network here, to encode other content of requests and/or responses.
• the profiles of the network functions managed by the NRF function each comprise an attribute containing at least one encoding format supported by the associated network function and that this attribute is published by the NRF in response to discovery requests it receives as part of the Nnrf_NFDiscovery service.
• these encoding formats can be provided when registering the network functions with the NRF function.
• the entities at the origin of the discovery requests sent to the NRF function can immediately use the encoding formats provided to access the services offered by the network functions (i.e. without having to send OPTIONS requests or to wait a response to a query indicating the encoding formats supported by the network functions).
• the invention has been described in the context of a 5G network defined by the 3GPP standard, with reference to network entities of the network function type, and more particularly to an AMF function and a function NRF belonging to the same core network, the invention can be applied to other entities.
• the 3GPP standard defines in the document TS 29.518 entitled: “Technical Specification Group Core Network and Terminals; 5G System; Access and Mobility Management Services; Stage 3”, V16.7.0, March 2021, that NEF, SMF or UDM network functions can subscribe to event notification from an AMF network function using the Namf_EventExposure service. These network functions can then choose to be notified for events concerning the access and mobility of a UE, of a group of UEs or even of all the UEs managed by this AMF function.
• the invention can also apply to networks other than a 5G network, for example to a 4G, 6G or next-generation network, or to proprietary networks, or to micro-services architectures “ event-driven”, etc., when a subscription/notification mechanism is implemented in this network and the entities involved in this mechanism are likely to support several encoding formats, and in particular at least one format compression.
• the invention is described with reference to virtualized entities, but it also applies to physical entities. These entities can belong to the same network or to different networks.
• entities 2 and 3 can be NRF functions belonging to two different PLMNs, or entity 3 a network function of a core network and entity 2 an application function internal or external to the core network, or user equipment.
• the invention can also be applied to other protocols than the HTTP/2 protocol, such as for example another version of the HTTP protocol (HTTP/1.1), or to the SOAP, CORBA, gRPC, QUIC, or generally to any other protocol based on the exchange of requests and responses, and supporting an encoding of the content of the body of the requests and/or the responses, typically a compression of this content.
• HTTP/2 requests/responses and in particular the data conveyed by these requests/responses for the implementation of the invention, applies, transposed to the requests/responses of these protocols.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer And Data Communications (AREA)
• Alarm Systems (AREA)
• Mobile Radio Communication Systems (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=76730685

Family Applications (1)

Country Status (5)

Family Cites Families (1)

• 2021
  • 2021-04-02 FR FR2103448A patent/FR3121562A1/fr not_active Withdrawn
• 2022
  • 2022-04-01 WO PCT/FR2022/050617 patent/WO2022208034A1/fr active Application Filing
  • 2022-04-01 US US18/553,381 patent/US20240187367A1/en active Pending
  • 2022-04-01 EP EP22719323.2A patent/EP4315962A1/de active Pending
  • 2022-04-01 CN CN202280024777.4A patent/CN117063522A/zh active Pending

Also Published As

Similar Documents

Legal Events