EP4315962A1 - Procédés de souscription et de notification, et entités configurées pour mettre en oeuvre ces procédés - Google Patents

Procédés de souscription et de notification, et entités configurées pour mettre en oeuvre ces procédés

Info

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

Links

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)
  • Mobile Radio Communication Systems (AREA)
  • Alarm Systems (AREA)

Abstract

L'invention vise un procédé de souscription d'une première entité communicante (2) auprès d'une deuxième entité communicante (3), ledit procédé étant destiné à être mis en œuvre par la première entité et comprenant : - une étape de demande de souscription auprès de la deuxième entité pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d'encodage supporté par la première entité; et - suite à une détection par la deuxième entité d'un dit événement correspondant à la demande de souscription, une étape de réception en provenance de la deuxième entité d'une notification comprenant des informations relatives audit événement détecté encodées au moyen d'un dit format d'encodage supporté par la première entité et indiqué dans la demande de souscription.

Description

Description
Titre de l’invention : Procédés de souscription et de notification, et entités configurées pour mettre en œuvre ces procédés.
Technique antérieure
[0001] L'invention appartient au domaine général des télécommunications.
[0002] Elle concerne plus particulièrement la notification d'événements dans un réseau de télécommunications.
[0003] L'invention a une application privilégiée mais non limitative dans le contexte des réseaux de télécommunications de 5ème Génération (ou 5G) définis par le standard 3GPP (ou « Third Génération Partnership Project » en anglais).
[0004] Les réseaux 5G tels que définis par le standard 3GPP exploitent de façon connue en soi des technologies de virtualisation de fonctions réseau (ou NFV pour « Network Function Virtualization » en anglais), de réseau défini par logiciel (ou SDN pour « Software Defined Networking » en anglais) et de découpage de réseaux en tranches, plus communément appelée « network slicing » en anglais. Ces technologies ouvrent des perspectives d'usage inédites des réseaux de télécommunications. Elles permettent notamment aux opérateurs de créer pour leurs clients des réseaux logiques virtuels de bout-en-bout, sur mesure et indépendants, évolutifs et agiles, et ce à partir d'une même infrastructure de réseau physique (réseau(x) d'accès, réseau cœur, etc.). Par le biais de ces réseaux logiques virtuels, les opérateurs sont capables de fournir à leurs clients des solutions optimisées pour des scénarii variés correspondant à des contraintes diverses en termes de fonctionnalités, de performances et de qualités de service.
[0005] La virtualisation de fonctions réseau ou NFV s'appuie sur des serveurs standards pour exécuter des logiciels de services réseau (aussi appelées fonctions réseau ou NFs pour « Network Functions » en anglais), tandis que le réseau défini par logiciel ou SDN centralise le contrôle du réseau 5G par logiciel plutôt que via des équipements physiques. Grâce à cette virtualisation, les fonctions réseau peuvent être déployées et reconfigurées aisément, apportant ainsi plus d'élasticité.
[0006] Diverses fonctions réseau d'un réseau cœur 5G peuvent être ainsi virtualisées, comme par exemple les fonctions réseau de gestion de l'accès et de la mobilité ou AMF (pour « Access Mobility Management Function » en anglais), de gestion de session ou SMF (pour « Session Management Function » en anglais), de sélection de tranche réseau ou NSSF (pour « Network Slice Sélection Function » en anglais), de contrôle des politiques ou PCF (pour « Policy Control Function » en anglais), etc. Le contrôle de ces fonctions virtualisées dans le réseau cœur 5G est assuré par une autre fonction réseau appelée catalogue de fonctions réseau ou N RF (ou « Network Repository Function » en anglais). Cette fonction NRF est chargée de fournir à une fonction réseau cliente ou consommatrice (« consumer » en anglais) les informations lui permettant d'interagir, directement ou indirectement via un équipement intermédiaire (ou SCP pour « Service Communication Proxy » en anglais), avec une fonction réseau serveur (« producer » en anglais) proposant un ou plusieurs services dans le réseau.
[0007] En effet, l'architecture de réseau 5G définie par le standard 3GPP est une architecture basée sur le service (ou SBA pour « Service Based Architecture » en anglais). Selon une telle architecture, les fonctionnalités d'un réseau 5G sont assurées par une pluralité de fonctions réseau (ou indifféremment fonctions NF dans la suite de la description) virtuelles fournissant des services à d'autres fonctions du réseau autorisées à accéder à ces services, une même fonction réseau pouvant offrir un ou plusieurs services. A cet effet, les fonctions NF du réseau cœur 5G présentent les services qu'elles offrent dans le contexte du cœur de réseau 5G (autrement dit leurs fonctionnalités) par l'intermédiaire d'interfaces se présentant sous forme d'APIs (pour « Application Pro- gramming Interfaces » en anglais) que les autres fonctions NF autorisées peuvent invoquer. Toutefois, au lieu d'interfaces prédéfinies entre les différentes fonctions NF pouvant interagir entre elles, un modèle de service est utilisé dans lequel les fonctions NF « consumer » interrogent la fonction réseau NRF pour découvrir les fonctions NF « producer » et communiquer avec elles sur les APIs qu'elles offrent. Ceci offre avantageusement aux opérateurs des réseaux 5G une grande flexibilité et une grande adaptabilité.
[0008] La fonction réseau NRF est ainsi un catalogue gérant une pluralité de fonctions NF, et mémorisant les profils de chacune de ces fonctions NF. Chaque profil comprend une pluralité d'attributs, caractérisant l'état opérationnel de la fonction NF (ex. sa disponibilité, sa charge, depuis quand elle a démarré, etc.), ses caractéristiques (ex. type de fonction NF, comment elle peut être jointe, etc.), les services qu'elle offre, les ressources qu'elle gère, etc. Des attributs peuvent être définis également plus spécifiquement au niveau de chaque service (sinon ce sont ceux définis au niveau de la fonction NF qui s'appliquent). Ces profils permettent aux fonctions NF « consumer » de découvrir les fournisseurs de services et de caractéristiques particuliers dans le réseau.
[0009] La fonction réseau NRF est mise à jour lors de l'activation et de la désactivation de chacune des fonctions NF qu'elle gère (i.e. lors de l'enregistrement et du désenregis- trement de chaque instance de chacune d'entre elles) ainsi qu'à chaque redimensionnement d'une fonction NF (la fonction NRF peut gérer en effet plusieurs instances d'une même fonction NF). Outre le service de découverte évoqué précédemment, le standard 3GPP définit également une procédure de souscription via laquelle une fonction NF « consumer » peut demander à la fonction NRF d'être informée de tout événement affectant une fonction NF « producer », comme par exemple la disponibilité d'une nouvelle instance d'un type de fonction NF, la mise à jour d'un attribut du profil d'une fonction NF, etc.
[0010] De nombreuses autres fonctions NF du réseau cœur 5G proposent aujourd'hui des services d'exposition d'événements comme celui proposé par la fonction NRF. Citons par exemple le service « Nsmf_EventExposure » qui permet à des fonctions NF « con- sumers » d'être informées par la fonction SMF d'événements relatifs à une session PDU (pour « Protocol Data Unit » en anglais), ou encore le service « Namf_EventExposure » qui permet à des fonctions NF « consumers » d'être informées par la fonction AMF d'événements relatifs à l'accès et à la mobilité d'un équipement utilisateur, d'un groupe d'équipements utilisateurs ou de l'ensemble des équipements utilisateurs gérés par la fonction AMF.
[0011] Le réseau cœur 5G utilise, pour les échanges entre fonctions NF, et notamment la notification d'événements, le protocole client-serveur HTTP et plus particulièrement sa version HTTP/2. De façon connue en soi, le protocole HTTP est un protocole initialement développé pour le web. L'optimisation de l'encodage des contenus échangés par l'intermédiaire du protocole HTTP (ex. texte, images, polices, etc.), et plus particulièrement la compression de ces contenus, est un facteur clé aujourd'hui prôné par les acteurs du web pour réduire la latence et la consommation de la bande passante, et améliorer sensiblement l'expérience utilisateur. L'application de ce principe aux échanges entre les fonctions NF au sein du réseau cœur 5G est également envisagée aujourd'hui. En effet, à titre indicatif, la charge utile d'un profil d'une fonction NF fourni dans une requête lors de l'enregistrement d'une fonction NF, ou dans une réponse fournie par la fonction NRF lors du mécanisme de découverte, ou encore dans une notification envoyée par la fonction NRF lorsqu'un profil d'une fonction NF est mis à jour, peut facilement avoisiner les 2 mégaoctets, ce qui, rapporté aux nombres de messages échangés sur le réseau cœur 5G, peut constituer une charge totale importante.
[0012] Selon le protocole HTTP/1.1, lors d'un échange entre un client et un serveur, le client peut indiquer dans la requête qu'il émet à destination du serveur, et plus particulièrement dans un entête « Accept-Encoding » de la requête, les différents types ou formats d'encodage (pour « encoding » en anglais) qu'il supporte (par exemple un encodage mettant en œuvre une compression tels que gzip ou deflate). Le serveur retourne alors une réponse au client dont le corps est conforme aux indications d'encodage fournies par le client, et indique dans un entête « Content-Encoding » de l'entête de sa réponse, le format d'encodage (et plus particulièrement de compression) qu'il a appliqué au contenu servi au client. La négociation de l'encodage, lorsqu'elle est mise en œuvre, est donc à l'initiative du client et ne concerne que la réponse envoyée par le serveur au client. Le client n'a aucun moyen de savoir préalablement à la réception de la réponse du serveur quel format d'encodage ce dernier supporte.
[0013] Dans le contexte des réseaux 5G, avant la Release 15.4.0, aucune négociation d'encodage n'est définie au niveau des interfaces APIs des fonctions NF. Dans la Release 15.4.0, le standard 3GPP introduit des règles d'ordre général pour la négociation d'encodage décrites notamment dans le document 3GPPP TS 29.500 V15.4.0, juin 2019, intitulé « Technical Spécification Group Core Network and Terminais; 5G System; Technical Realization of Service Based Architecture; Stage 3 (Release 15) ». Selon ces règles : une fonction NF « consumer » peut déterminer les formats d'encodage supportés par une fonction NF « producer » en lui envoyant une requête de type OPTIONS, les formats d'encodage supportés par la fonction NF « producer » lui étant retournés dans la réponse à la requête OPTIONS ; une fonction NF « producer » peut retourner un entête « Accept-Encoding » tel que décrit précédemment contenant les formats d'encodage qu'elle supporte dans une réponse, par exemple une réponse à une requête comportant un corps telle qu'une requête HTTP POST, PUT ou PATCH.
La fonction NF « consumer » peut alors utiliser l'un des formats d'encodage fournis par la fonction NF « producer » pour encoder le corps le cas échéant de sa prochaine requête adressée à la fonction NF « producer ».
[0014] Une requête OPTIONS n'a toutefois été mise en œuvre par le standard 3GPP que dans l'API de la fonction NRF pour le service de gestion Nnrf_NFManagement (qui comprend les opérations d'enregistrement, de désenregistrement et de mise à jour évoquées précédemment) et dans l'API de la fonction AMF. Une généralisation de cette solution imposerait de mettre en œuvre la requête OPTIONS pour toutes les ressources des différentes interfaces APIs de toutes les fonctions NF (actuellement définies et futures) comportant des requêtes HTTP pouvant mettre en œuvre un encodage de leur contenu, et plus particulièrement les requêtes HTTP POST, PUT et PATCH. Ceci aurait pour conséquence non seulement une lourdeur de maintenance des spécifications du réseau cœur 5G, mais également une augmentation du volume de la signalisation échangée dans le réseau cœur (une transaction dédiée pour chaque ressource sur chaque API), et la prise en compte d'une logique additionnelle pour chaque fonction NF « consumer ».
[0015] L'autre solution proposée par le standard 3GPP (ajout d'un entête « Accept- Encoding » dans une réponse ou dans une requête) est utilisée dans la Release 16 pour des services offerts par les fonctions réseau NSSF (service Nnssf_NSSAIAvailability) et NRF (services Nnrf_NFManagement, Nnrf_NFDiscovery et Nnrf_AccessToken), mais il n'est pas fait référence explicitement à son utilisation pour les notifications. Selon le document TS 29.510 intitulé « Technical Spécification Group Core Network and Terminais; 5G System; Network Function Repository Services; Stage 3 », V16.6.0, décembre 2020, les fonctions NF « consumers » devraient supporter l'utilisation du format d'encodage gzip dans les notifications envoyées par la fonction NRF. Toutefois, cette contrainte se limite aux notifications émises par la fonction réseau NRF, et à un seul format d'encodage à savoir le format gzip. En outre, il n'est pas sûr qu'une fonction NF « consumer » supporte en pratique le format d'encodage gzip : si ce format d'encodage n'est pas supporté, la fonction réseau NRF s'expose à un rejet de ses notifications.
[0016] Il existe donc un besoin d'une solution ne présentant pas les inconvénients précités et pouvant s'appliquer de façon homogène à toutes les fonctions réseau d'un réseau cœur 5G.
Exposé de l'invention
[0017] L'invention offre une telle solution en proposant un procédé de souscription d'une première entité communicante auprès d'une deuxième entité communicante, ledit procédé étant destiné à être mis en œuvre par la première entité et comprenant :
- une étape de demande de souscription auprès de la deuxième entité pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité relatif, cette demande de souscription indiquant au moins un format d'encodage supporté par la première entité ; et
- suite à une détection par la deuxième entité d'un dit événement correspondant à la demande de souscription, une étape de réception en provenance de la deuxième entité d'une notification comprenant des informations relatives audit événement détecté encodées au moyen d'un dit format d'encodage supporté par la première entité et indiqué dans la demande de souscription.
[0018] Corrélativement, l'invention vise aussi une entité communicante, dite première entité, comprenant :
- un premier module configuré pour demander une souscription auprès d'une deuxième entité de réseau pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d'encodage supporté par la première entité ; et
- un deuxième module, activé suite à une détection par la deuxième entité d'un dit événement correspondant à la demande de souscription, ledit deuxième module étant configuré pour recevoir en provenance de la deuxième entité une notification comprenant des informations relatives audit événement détecté encodées au moyen d'un dit format d'encodage supporté par la première entité et indiqué dans la demande de souscription.
[0019] L'invention vise aussi un procédé de notification d'événements à une première entité communicante, destiné à être mis en œuvre par une deuxième entité communicante, ce procédé de notification comprenant :
- une étape de réception d'une demande de souscription en provenance de la première entité pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d'encodage supporté par la première entité ; et
- suite à une détection par la deuxième entité d'un dit événement correspondant à la demande de souscription, une étape d'envoi à la première entité d'une notification comprenant des informations relatives audit événement détecté encodées au moyen d'un dit format d'encodage supporté par la première entité et indiqué dans la demande de souscription.
[0020] Corrélativement, l'invention vise aussi une entité communicante, dit deuxième entité, comprenant :
- un module de réception, configuré pour recevoir une demande de souscription d'une première entité communicante pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d'encodage supporté par la première entité ; et
- un module d'envoi, activé suite à une détection d'un dit événement correspondant à la demande de souscription, et configuré pour envoyer à la première entité une notification comprenant des informations relatives audit événement détecté encodées au moyen d'un dit format d'encodage supporté par la première entité et indiqué dans la demande de souscription.
[0021] Aucune limitation n'est attachée à la nature des première et deuxième entités communicantes. Il peut s'agir d'entités physiques ou logicielles, appartenant à un même réseau ou à des réseaux distincts. De telles entités communicantes sont par exemple des entités de réseau, des fonctions d'applications (ou « Application Functions » en anglais) ou encore des équipements utilisateurs. Il peut s'agir notamment d'entités applicatives, c'est-à-dire d'entités configurées pour mettre en œuvre des logiques de traitement déterminées, comme notamment des entités offrant et/ou consommant des services dans un réseau telles que des fonctions réseau ou des instances de fonctions réseau (ex. fonctions AMF, SMF, NRF, etc.). Mais il peut également s'agir d'autres entités telles que des équipements intermédiaires situés sur le chemin de communication entre deux fonctions réseau comme par exemple des équipements SCP (pour « Service Communication Proxy » en anglais), ou encore des équipements utilisateurs.
[0022] On note en outre que bien qu'introduite en référence à un réseau cœur 5G, l'invention ne se limite pas à ce contexte. Elle peut s'appliquer à d'autres générations de réseaux (ex. 4G, 6G, et suivantes), à des réseaux propriétaires, ou encore à d'autres types de réseaux, mettant en œuvre des services d'exposition d'événements, comme par exemple à des architectures micro-services « event-driven » dont un exemple illustratif est décrit à l'URL https://www.theodo.fr/digital-et-strategie/architectures-event- driven-construisez-des-applications-performantes-et-d%C3%A9coupl%C3%A9es- avec-rabbitmq.
[0023] L'invention permet avantageusement d'optimiser la transmission des notifications émises de façon asynchrone par la deuxième entité communicante pour signaler, aux entités communicantes qui en ont fait la demande, divers événements relatifs aux éléments qu'elle gère et/ou surveille (ex. équipements d'utilisateurs, fonctions réseau, sessions de données, etc.). Elle n'impose avantageusement aucun format d'encodage spécifique, mais s'adapte aux capacités des entités ayant souscrit à la notification des événements. Un tel format peut être bien entendu un format de compression tel que gzip, deflate, compress, ce qui permet d'optimiser les performances des échanges entre les entités en termes de latence et de bande passante notamment, mais d'autres formats d'encodage peuvent être envisagés également, comme par exemple un format d'encodage base64, un format invariant (ou « identity ») prônant l'absence de transformation du contenu, ou toute transformation réversible réalisée dans un but particulier (ex. réduire la taille d'un contenu, obtenir un contenu compatible avec la majorité des systèmes, sécuriser un contenu, etc.), etc. L'invention offre ainsi une grande flexibilité et permet d'appliquer des formats d'encodage différents aux notifications envoyées à des entités différentes, ou en fonction du contexte dans lesquels se trouvent les première et deuxième entités, ou encore en fonction des caractéristiques des informations à notifier (sensibilité, taille, etc.).
[0024] Grâce à cette flexibilité, l'invention peut s'appliquer à de nombreuses entités communicantes, et à leurs spécificités respectives. Elle offre ainsi une solution homogène qui peut être transposée notamment aux différentes fonctions réseau d'un réseau cœur, ce qui facilite sa mise en œuvre dans un réseau standardisé tel qu'un réseau 3GPP.
[0025] Aucune limitation n'est attachée à la nature des événements notifiés. Ils dépendent bien entendu de la fonction de la deuxième entité communicante et des éléments qu'elle gère et/ou qu'elle surveille. Par exemple, pour une fonction réseau de type catalogue de fonctions réseau (i.e. une fonction NRF) qui gèrent des fonctions réseau, ces événements peuvent être la création, la modification ou encore la suppression d'un profil d'une fonction réseau. Pour une fonction réseau gérant l'accès et la mobilité (i.e. une fonction AMF) dans un réseau, ces événements peuvent comprendre la localisation ou la présence dans une zone d'intérêt d'un équipement utilisateur ou UE (pour « User Equipment » en anglais), ou d'un groupe d'UEs, le nombre d'UEs dans une zone donnée, une perte de connectivité d'un UE ou d'un groupe d'UEs, etc. Pour une fonction réseau gérant des sessions PDU (i.e. une fonction SMF), ces événements peuvent comprendre un changement de réseau ou PLMN (pour « Public Land Mobile Network » en anglais), une libération ou un établissement d'une session PDU, un changement de type d'accès, etc.
[0026] La solution offerte par l'invention s'intégre aisément aux procédures de souscription existantes, et en particulier dans le contexte d'un réseau 3GPP, aux procédures de souscription définies pour les différentes entités de réseau offrant un service d'exposition d'événements tels que les fonctions NRF, AMF, SMF mentionnées ci-avant. Elle nécessite seulement d'ajouter parmi les indications fournies lors de la souscription, les formats d'encodage supportés par la première entité. Par exemple, ce ou ces formats peuvent être notamment fournis dans le corps de la requête de souscription (ex. dans un champ prévu à cet effet) avec d'autres données relatives à la souscription comme les événements pour lesquels la première entité souhaite être notifiée, etc.
[0027] L'invention ne requiert donc pas de définition d'une logique complémentaire, ni l'échange de messages supplémentaires (comme par exemple une requête OPTIONS et la réponse associée, ou une requête contenant un champ Accept-Encoding et la réponse associée), ce qui permet de préserver les performances du réseau. Au niveau de la deuxième entité, le(s) format(s) d'encodage supporté(s) par la première entité peut(vent) avantageusement être mémorisé(s) dans le contexte de souscription de la première entité : l'invention est donc particulièrement facile à mettre en œuvre.
[0028] Dans un mode particulier de réalisation, la deuxième entité de réseau est une entité de contrôle gérant une pluralité d'entités applicatives d'un réseau.
[0029] Ce mode de réalisation a une application privilégiée lorsque la deuxième entité est par exemple une fonction NRF d'un réseau cœur 5G gérant une pluralité de fonctions réseau NF ou d'instances de fonctions NF. Comme mentionné précédemment, la fonction NRF est un catalogue gérant une pluralité de fonctions NF, et mémorisant les profils de chacune de ces fonctions NF, chaque profil comprenant une pluralité d'attributs caractérisant l'état opérationnel de la fonction NF (ex. sa disponibilité, sa charge, depuis quand elle a démarré, etc.), ses caractéristiques (ex. type de fonction NF, comment elle peut être jointe, etc.), les services qu'elle offre, les ressources qu'elle gère, etc.
[0030] Dans un mode particulier de réalisation, chaque profil d'entité applicative gérée par la deuxième entité, mémorisé par elle, comprend une pluralité d'attributs incluant au moins un format d'encodage supporté par cette entité applicative.
[0031] Ce mode de réalisation est particulièrement avantageux, car il permet à la deuxième entité non seulement de connaître les formats d'encodage supportés par une entité applicative en tant que « consumer » (lorsqu'elle reçoit les notifications de la deuxième entité), mais également, lorsque la deuxième entité gère cette entité applicative, de connaître les formats d'encodage supportés par elle en tant que « producer ». La deuxième entité est alors en mesure de publier ce ou ces formats d'encodage auprès d'entités le requérant, par exemple au cours d'une procédure de découverte d'entités applicatives gérées par la deuxième entité vérifiant un ou plusieurs critères donnés.
[0032] Dans un mode particulier de réalisation, ledit événement détecté est une création, une suppression ou une modification d'un élément géré par la deuxième entité.
[0033] Un tel élément est par exemple un profil d'une entité applicative gérée par l'entité de contrôle, dans l'exemple d'une fonction réseau NRF. Mais d'autres applications de ce mode de réalisation peuvent être envisagées. Par exemple pour une fonction AMF, un tel élément peut être un profil ou un contexte utilisateur regroupant les utilisateurs enregistrés dans un réseau et gérés par la fonction AMF.
[0034] L'élément en question peut être une ressource quelconque surveillée par la deuxième entité (ex. une session PDU, un équipement utilisateur ou un groupe d'équipements utilisateurs, une adresse IP, une entité virtuelle, une entité physique, etc.). Aucune limitation n'est attachée à la nature de cet élément.
[0035] Dans un mode particulier de réalisation, la notification envoyée par la deuxième entité est une requête conforme à une version du protocole HTTP.
[0036] Comme mentionné précédemment, l'invention a une application privilégiée dans le cadre d'un réseau 5G s'appuyant sur le protocole HTTP et notamment sur la version HTTP/2 de ce protocole, pour la compression des contenus des requêtes de notification conformes à ce protocole échangées entre les différentes entités impliquées dans l'invention.
[0037] Toutefois, l'invention s'applique également à d'autres protocoles que le protocole HTTP/2 tels qu'à une autre version du protocole HTTP (HTTP/1.1), ou aux protocoles SOAP (pour « Simple Object Access Protocol » en anglais), CORBA (pour « Common Object Request Broker Architecture » en anglais), gRPC (pour « Remote Procedure Call » en anglais), QUIC, etc., ou à tout autre protocole basé sur l'échange de re- quêtes et de réponses, et supportant un encodage du contenu du corps des requêtes et/ou des réponses, typiquement une compression de ce contenu.
[0038] Dans un mode particulier de réalisation, au moins un format d'encodage supporté par la première entité et indiqué dans la demande de souscription est un format de compression. Ainsi, le format d'encodage utilisé pour encoder les informations relatives à l'événement détecté dans la notification peut être un format de compression.
[0039] Ce mode de réalisation permet d'optimiser les performances et la latence du réseau. En effet, selon l'événement à l'origine de la notification et la configuration de la deuxième entité, une telle notification peut comprendre un volume de données important. Par exemple, pour une fonction réseau NRF, une telle notification peut comprendre un ou plusieurs profils en tout ou partie de fonctions réseau, ou seulement le cas échéant, les attributs du profil ou des profils affectés par l'événement. L'application d'un format d'encodage de type compression aux informations véhiculées par les notifications, compte tenu du nombre important de notifications susceptibles d'être envoyées par les différentes entités d'un réseau et du volume de données transmis par chacune d'entre elles, est donc particulièrement avantageuse en matière de latence et de bande passante.
[0040] Dans un mode particulier de réalisation, dans la demande de souscription, ledit au moins un format d'encodage supporté par la première entité est fourni dans une structure de données comprenant au moins une option de communication supportée par la première entité.
[0041] L'usage d'une telle structure de données permet de signaler de façon synthétique à la deuxième entité, lors de la souscription, plusieurs options de communication supportées par la première entité et qui peuvent être exploitées lors de l'envoi des notifications. Par exemple, outre les formats d'encodage, on peut envisager de signaler dans cette structure de données des formats de contenus (ex. json, xml, atom, etc.) supportés par la première entité permettant à la deuxième entité d'ajuster le format des informations qu'elle transmet dans les notifications à la première entité.
[0042] Ce mode de réalisation offre une grande flexibilité et est évolutif : il facilite l'application de l'invention à de nouvelles contraintes, en matière d'options de communication.
[0043] Dans un mode particulier de réalisation de l'invention, les procédés de souscription et de notification sont mis en œuvre par un ordinateur.
[0044] L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans une première entité de réseau conforme à l'invention et comporte des instructions adaptées à la mise en œuvre d'un procédé de souscription tel que décrit ci-dessus.
[0045] L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans une deuxième entité de réseau conforme à l'invention et comporte des instructions adaptées à la mise en œuvre d'un procédé de notification tel que décrit ci-dessus.
[0046] Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. [0047] L'invention vise aussi un support d'information ou un support d'enregistrement lisibles par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
[0048] Le support d'information ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash.
[0049] D'autre part, le support d'information ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.
[0050] Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
[0051] Alternativement, le support d'information ou d'enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés de souscription et de notification selon l'invention.
[0052] Selon un autre aspect, l'invention vise un système comprenant au moins une première entité communicante et une deuxième entité communicante selon l'invention.
[0053] Le système bénéficie des mêmes avantages cités précédemment que les procédés de souscription et de notification, et que les première et deuxième entités communicantes selon l'invention.
[0054] On peut également envisager, dans d'autres modes de réalisation, que les procédés de souscription, de notification, les première et deuxième entités communicantes présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
[0055] D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
[Fig. 1] la figure 1 représente dans son environnement, un système selon l'invention dans un mode particulier de réalisation ;
[Fig. 2] la figure 2 représente schématiquement l'architecture matérielle d'un ordinateur pouvant héberger l'une quelconque des entités communicantes selon l'invention appartenant au système de la figure 1 ;
[Fig. 3] la figure 3 illustre, sous forme d'ordinogramme, les principales étapes d'un procédé de souscription mises en œuvre par une entité communicante du système de la figure 2 dans un mode particulier de l'invention ; et
[Fig. 4] la figure 4 illustre, sous forme d'ordinogramme, les principales étapes d'un procédé de notification mises en œuvre par une entité communicante du système de la figure 2 dans un mode particulier de l'invention.
Description de l'invention
[0056] La figure 1 représente, dans son environnement, un système 1 conforme à l'invention, dans un mode particulier de réalisation dans lequel le système 1 est intégré dans un réseau cœur CN d'un réseau de communications 5G tel que décrit dans le standard 3GPP.
[0057] Dans l'exemple envisagé à la figure 1, le système 1 comprend une première entité communicante 2 et une deuxième entité communicante 3 conformes à l'invention mettant en œuvre au sein du réseau cœur CN un mécanisme de souscription/notification d'événements. On suppose plus particulièrement ici que l'entité 3 est une entité de réseau gérant différents éléments du réseau cœur CN, mis en œuvre dans le réseau cœur CN ou rattachés au réseau cœur CN, comme par exemple des fonctions réseau (NFs), des équipements utilisateurs (UEs), des sessions PDU, etc., et surveille différents types d'événements relatifs à ces éléments. Les événements surveillés par l'entité 3 et susceptibles d'être publiés (autrement dit d'être partagés avec d'autres entités comme par exemple avec l'entité 2) sont généralement prédéfinis, de sorte qu'une entité communicante peut souscrire à la notification de tout ou partie de ces événements si elle est intéressée par leur connaissance.
[0058] En variante, on peut envisager une découverte dynamique des événements susceptibles d'être publiés par l'entité 3, par exemple en l'interrogeant.
[0059] Dans une autre variante encore, on peut envisager qu'une entité souscrive inconditionnellement à tous les événements susceptibles d'être exposés par l'entité 3 ou à des événements vérifiant un ou plusieurs critères donnés.
[0060] L'invention ne se limite pas à une utilisation particulière de la connaissance des événements en question : l'entité, et en particulier l'entité 2, qui a souscrit à une notification d'événements surveillés par l'entité 3 peut utiliser cette connaissance par exemple pour gérer des éléments dont elle a la charge, pour mettre en œuvre des traitements qui lui sont confiés, etc.
[0061] Dans le mode de réalisation décrit ici, les deux entités sont des entités de réseau applicatives, c'est-à-dire des entités de réseau configurées pour mettre en œuvre des logiques de traitement déterminées dans le réseau cœur CN, comme notamment des entités offrant et/ou consommant des services dans le réseau cœur. Plus particulièrement, on suppose ici que les entités 2 et 3 sont des instances virtualisées de fonctions réseau telles que des fonctions AMF, SMF, NRF, etc., qui exécutent diverses logiques de service permettant d'assurer les principales fonctions du réseau cœur (ex. gestion de la mobilité et de l'accès au réseau cœur, définition et application de politiques réseau, facturation, sélection de tranches réseau, etc.). Chaque service offert par une telle fonction réseau peut comprendre une ou plusieurs opérations. Dans la suite de la description, une fonction réseau désigne une instance virtuelle d'une fonction réseau, chaque fonction réseau du réseau cœur CN pouvant être instanciée de façon multiple.
[0062] A titre illustratif et pour mieux comprendre l'invention, on considère dans la suite de la description que l'entité communicante 2 est une fonction réseau AMF et l'entité communicante 3 est une fonction réseau NRF (entité de contrôle au sens de l'invention) gérant une pluralité de fonctions réseau NF, telles que des fonctions réseau AMF, SMF, NRF, etc. (entités applicatives au sens de l'invention). De façon connue, une telle fonction NRF est un catalogue mémorisant pour chacune des fonctions NF qu'elle gère, un profil comprenant une pluralité d'attributs caractérisant l'état opérationnel de la fonction NF associée (ex. sa disponibilité, sa charge, depuis quand elle a démarré, etc.), ses caractéristiques (ex. type de fonction NF, comment elle peut être jointe, etc.), les services qu'elle offre, les ressources que ces services gèrent, etc. La fonction NRF propose elle-même une pluralité de services comprenant notamment des services de découverte des fonctions NF qu'elle gère (et plus particulièrement de certains attributs du profil de ces fonctions NF dites « producers » permettant à des fonctions NF « consumers » d'accéder aux services offerts par les fonctions NF « producers »), de gestion (incluant les opérations d'enregistrement/désenregistrement/mise à jour évoquées précédemment), d'autorisation et d'amorçage (ou « bootstrapping » en anglais), qui reprennent la logique des services Nnrf_NFDiscovery, Nnrf_NFManagement, Nnrf_AccessToken et Nnrf_Boostrapping décrits notamment dans le document TS 29.510 intitulé « Technical Spécification Group Core Network and Terminais; 5G System; Network Function Repository Services; Stage 3 », V16.6.0, décembre 2020.
[0063] L'invention ne se limite toutefois pas aux hypothèses qui viennent d'être formulées. Comme évoqué précédemment, elle s'applique en effet à d'autres configurations du système 1 (plusieurs « premières » et « deuxièmes » entités communicantes selon l'invention), à d'autres réseaux (ex. d'autres générations de réseaux définis par le standard 3GPP ou par d'autres standards, des réseaux propriétaires, des architectures micro-services, etc.), ainsi qu'à d'autres entités communicantes physiques ou logicielles (ex. à des équipements intermédiaires SCP situés sur le chemin de communication entre deux fonctions réseau, à des fonctions d'applications, à des équipements d'utilisateurs, à des entités de réseau, etc.), dès lors que des mécanismes de souscription/notification sont mis en œuvre.
[0064] En outre, dans l'exemple envisagé ici, les première et deuxième entités communicantes appartiennent au même réseau cœur CN, mais l'invention s'applique également lorsque les première et deuxième entités communicantes appartiennent à des réseaux différents, ou lorsqu'une des entités est externe au réseau auquel appartient l'autre entité. Il peut s'agir par exemple de deux fonctions réseau NRF appartenant à deux réseaux PLMN distincts, ou d'une fonction réseau et d'une fonction d'application externe, etc.
[0065] Il convient également de noter qu'une même entité, qu'elle soit physique ou logicielle (virtuelle), peut être configurée pour être « une première entité » au sens de l'invention au regard de certaines entités (c'est-à-dire souscrivant à la notification d'événements donnés), et « une deuxième entité » au sens de l'invention au regard d'autres entités (c'est-à-dire notifiant des événements donnés). Par exemple, dans un réseau cœur 5G tel que défini par le standard 3GPP, la fonction réseau AMF peut être une première entité au regard de la fonction réseau NRF, et une deuxième entité au regard des fonctions réseau SMF, NEF (pour « Network Exposure Function » en anglais) ou UDM (pour « Unified Data Management » en anglais).
[0066] Dans le mode de réalisation décrit ici, les entités 2 et 3 sont des entités logicielles, hébergées par des dispositifs physiques du réseau cœur CN, comme par exemple des serveurs. Ces serveurs ont ici l'architecture matérielle d'un ordinateur 4, telle que représentée schématiquement sur la figure 2.
[0067] L'ordinateur 4 comprend notamment un processeur 5, une mémoire vive 6, une mémoire morte 7, une mémoire non volatile 8, et des moyens de communication 9 permettant notamment aux entités du système 1 de communiquer entre elles et avec d'autres entités le cas échéant du réseau cœur CN ou externes au réseau CN. Ces moyens de communication 9 s'appuient d'une part, sur une interface de communication filaire ou sans fil, connue en soi et non décrite plus en détail ici, mais également sur une ou plusieurs interfaces logicielles basées sur le service ou SBI (pour « Service Based Interface » en anglais). Ces interfaces logicielles sont des APIs qui utilisent ici le protocole HTTP/2. [0068] La mémoire morte 7 de l'ordinateur 4 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 5 et sur lequel est enregistré(s) un ou plusieurs programmes d'ordinateur conformes à l'invention.
[0069] Plus spécifiquement, la mémoire morte 7 de l'ordinateur 4 comprend, lorsque l'ordinateur 4 héberge l'entité 2, un enregistrement d'un programme d'ordinateur PROG2, comportant des instructions définissant les principales étapes d'un procédé de souscription selon l'invention.
[0070] Ce programme PROG2 définit des modules fonctionnels d'une première entité au sens de l'invention qui s'appuient ou commandent les éléments matériels 5 à 9 de l'ordinateur 4 cités précédemment. Ces modules comprennent notamment dans le mode de réalisation décrit ici, comme illustré sur la figure 1 : un premier module 2A de communication, configuré pour demander une souscription auprès de l'entité 3 pour obtenir des informations concernant au moins un événement surveillé par l'entité 3, la demande de souscription indiquant au moins un format d'encodage supporté par l'entité 2 ; et un deuxième module 2B de communication, activé suite à une détection par l'entité 3 d'un dit événement correspondant à la demande de souscription, ce deuxième module 2B étant configuré pour recevoir en provenance l'entité 3 une notification comprenant des informations relatives à l'événement détecté, encodées au moyen d'un format d'encodage supporté par l'entité 2 et indiqué dans la demande de souscription.
[0071] Dans le mode de réalisation décrit ici, le programme PROG2 définit également un module 2C de traitement, configuré pour utiliser le cas échéant les notifications reçues par le deuxième module 2B de communication pour gérer, dans l'exemple envisagé ici, des éléments du réseau cœur CN ou rattachés à celui-ci dont l'entité 2 a la charge. Ainsi, dans l'exemple illustratif introduit précédemment où l'entité 2 est une fonction réseau AMF, le module 2C d'exploitation est configuré pour utiliser notamment les notifications reçues pour gérer efficacement l'accès et la mobilité des équipements utilisateurs dont il a la charge.
[0072] Les fonctions assurées par les modules 2A à 2C de l'entité 2 sont décrites plus en détail ultérieurement, en référence aux étapes du procédé de souscription selon l'invention.
[0073] De façon similaire, la mémoire morte 7 de l'ordinateur 4 comprend, lorsque l'ordinateur 4 héberge l'entité 3, un enregistrement d'un programme d'ordinateur PROG3, comportant des instructions définissant les principales étapes d'un procédé de souscription selon l'invention.
[0074] Ce programme PROG3 définit des modules fonctionnels d'une deuxième entité au sens de l'invention qui s'appuient ou commandent les éléments matériels 5 à 9 de l'ordinateur 4 cités précédemment. Ces modules comprennent notamment dans le mode de réalisation décrit ici, comme illustré sur la figure 1 : un module 3A de réception, configuré pour recevoir une demande de souscription d'une autre entité, par exemple ici de l'entité 2, pour obtenir des informations concernant au moins un événement surveillé par l'entité 3, cette demande de souscription indiquant au moins un format d'encodage supporté par l'entité 2. Dans l'exemple illustratif envisagé ici d'une fonction réseau NRF gérant plusieurs fonctions réseau NF et mémorisant pour chacune de ces fonctions réseau un profil d'attributs, un tel événement est par exemple la création, la suppression ou la modification d'un tel profil d'attributs, ou de façon équivalente, l'enregistrement et le désenregistrement de fonctions réseau gérées par la fonction NRF (qui se traduisent respectivement par la création et la suppression d'un profil au niveau de la fonction NRF), et la modification d'un profil d'attributs d'une fonction réseau. Bien entendu, les événements surveillés par l'entité 3 dépendent des services (fonctionnalités) assurés par cette entité 3, dans le réseau cœur CN ici, et/ou des éléments gérés par cette entité 3. Par exemple, un tel événement peut être la création, la suppression ou la modification d'un élément géré et/ou surveillé par l'entité 3. Mais d'autres événements peuvent être envisagés. Ainsi, pour une fonction réseau AMF, de tels événements peuvent comprendre par exemple, comme évoqué précédemment, la localisation ou la présence dans une zone d'intérêt d'un UE ou d'un groupe d'UEs, le nombre d'UEs dans une zone donnée, une perte de connectivité d'un UE ou d'un groupe d'UEs, etc. Pour une fonction réseau SMF, ces événements peuvent comprendre un changement de réseau ou PLMN, une libération ou un établissement d'une session PDU, un changement de type d'accès, etc. ; un module 3B de surveillance, configuré pour surveiller de façon continue ou quasi-continue les éléments gérés par l'entité 3 et détecter le cas échéant les événements évoqués ci-avant relatifs à ces éléments ; et un module 3C d'envoi, activé suite à une détection par le module 3B de surveillance d'un événement correspondant à la demande de souscription de l'entité de réseau 2 reçue par le module 3A de réception, et configuré pour envoyer à l'entité de réseau 2 une notification comprenant des informations relatives à cet événement détecté encodées au moyen d'un format d'encodage supporté par l'entité de réseau 2 et indiqué dans la demande de souscription.
[0075] Les fonctions assurées par les modules 3A à 2C de l'entité 3 sont décrites plus en détail ultérieurement, en référence aux étapes du procédé de notification selon l'invention.
[0076] Nous allons maintenant décrire en référence aux figures 3 et 4 respectivement les principales étapes d'un procédé de souscription et d'un procédé de notification selon l'invention telles qu'elles sont mises en œuvre respectivement par l'entité 2 et par l'entité 3, dans un mode particulier de réalisation.
[0077] On suppose ici que les événements surveillés par l'entité 3 et les éléments qu'elle gère et/ou surveille (dans l'exemple envisagé ici, des éléments du réseau cœur CN ou rattachés au réseau cœur CN) sont connus, et donc en particulier de l'entité 2.
[0078] Aucune limitation n'est attachée à la façon dont ces informations sont obtenues par l'entité 2. Elle peut être configurée par l'équipementier fournissant l'entité 2, à partir notamment de spécifications décrivant l'entité 3. C'est le cas notamment des fonctions réseau dans un réseau cœur 5G, ou plus généralement dans un réseau cœur défini par le standard 3GPP, ces événements et ces éléments étant décrits dans les spécifications relatives à ces fonctions réseau. Ainsi, dans l'exemple illustratif envisagé ici d'une entité 3 comprenant une fonction réseau NRF, ces informations sont décrites dans le document TS 29.510 introduit précédemment, au paragraphe 5.2.2.5 notamment. Conformément à ce document, les événements surveillés par la fonction réseau NRF sont l'enregistrement et le désenregistrement d'une fonction NF gérée par la fonction NRF, ainsi que la modification d'un profil d'une fonction NF gérée par la fonction NRF, c'est-à-dire de façon équivalente comme déjà évoqué, la création, la suppression et la modification d'un profil d'une fonction réseau gérée par l'entité 3, susceptible d'être publié par celle-ci auprès d'entités tierces. Un tel profil est un élément géré par l'entité 3 au sens de l'invention.
[0079] En variante, ces informations peuvent être obtenues par l'entité 2 de façon dynamique, en interrogeant l'entité 3.
[0080] En référence à la figure 3, on suppose que l'entité 2 (i.e. la fonction AMF dans l'exemple illustratif envisagé) est intéressée par être notifiée de la détection de tout ou partie des événements surveillés par l'entité 3, pour au moins l'un des éléments du réseau cœur CN gérés par l'entité 3.
[0081] L'entité 2, par l'intermédiaire de son premier module 2A de communication, envoie donc une demande de souscription à l'entité 3, pour obtenir des informations concernant ces événements (étape E10). Dans l'exemple envisagé ici d'un réseau cœur 5G défini par le standard 3GPP, cette demande de souscription est réalisée via l'envoi d'une requête de souscription HTTP POST. Elle contient, dans son corps, les données de la souscription SubscriptionData, à savoir notamment ici des informations indiquant le type de notifications que l'entité 2 souhaite recevoir (et plus particulièrement quel(s) événement(s) associé(s) à quel(s) élément(s) géré(s) par l'entité 3), ainsi qu'un identifiant ou URI dit de rappel (« callback » en anglais) sur laquelle l'entité 2 souhaite recevoir les notifications. On note que la demande de souscription de l'entité 2 peut porter sur un ou plusieurs éléments gérés et/ou surveillés par l'entité 3, par exemple sur des éléments vérifiant un critère donné (par exemple toutes les fonctions NF assurant un service donné ou d'un type donné). Dans l'exemple illustratif d'une entité 2 de type fonction AMF, l'entité 2 peut indiquer qu'elle souhaite recevoir des notifications lorsque l'un quelconque des événements de création/suppression ou modification d'un profil est détecté pour les instances des fonctions réseau AUSF (pour « AUthentication Server Function » en anglais), 5G-EIR (pour « Equipment Identity Register » en anglais), SMF, UDM et PCF gérées par l'entité 3 (fonction NRF dans cet exemple).
[0082] D'autres informations peuvent être spécifiées dans les données SubscriptionData comme par exemple une durée de validité de la souscription, ou un ou plusieurs paramètres conditionnels, propres au type de l'entité 3, qui peuvent être surveillés pour déterminer s'il convient ou non de déclencher une notification. Dans l'exemple d'une fonction NRF, de tels paramètres conditionnels peuvent être par exemple les attributs d'un profil qui doivent être changés pour déclencher une notification ou ceux qui n'ont pas besoin d'être surveillés à l'inverse. Ces paramètres conditionnels permettent d'apporter une granularité supplémentaire et de limiter l'envoi de notifications aux événements réellement pertinents pour l'entité 2.
[0083] En outre, conformément à l'invention, la demande de souscription comprend avantageusement parmi les données SubscriptionData, au moins un format d'encodage supporté par l'entité 2 et pouvant être utilisé pour encoder le contenu des notifications envoyées par l'entité 3 à l'entité 2. Dans le mode de réalisation décrit ici, le ou les formats d'encodage indiqués dans la demande de souscription comprennent au moins un format de compression, tel que gzip, deflate ou compress. Toutefois en complément ou en variante, d'autres formats d'encodage peuvent être supportés par l'entité 2 (ex. formats d'encodage base64, invariant (« identity »), etc.), et indiqués par elle dans la demande de souscription.
[0084] Il convient de noter que l'entité 2 n'est pas contrainte d'indiquer dans la demande de souscription tous les formats d'encodage qu'elle supporte. Elle peut sélectionner un ou plusieurs formats d'encodage spécifiques parmi ceux qu'elle supporte pour que l'un d'eux soit utilisé lors des notifications.
[0085] Par ailleurs, dans un mode particulier de réalisation, on peut envisager que l'entité 2 définisse des formats d'encodage éventuellement distincts en fonction des événements surveillés par l'entité 3 ou des éléments auxquels se rapportent ces événements. Par exemple, on peut envisager de définir un format de compression avec un plus fort taux de compression pour des contenus qu'on sait de taille importante (ex. profils de fonctions réseau), tandis qu'un format de compression avec un taux de compression plus faible ou un format d'encodage invariant peut être indiqué 2 pour des contenus de notification de taille moindre. Cet exemple n'est bien entendu donné qu'à titre illustratif.
[0086] En outre, les formats d'encodage indiqués par l'entité 2 peuvent évoluer dans le temps : l'entité 2 peut en effet mettre à jour sa souscription auprès de l'entité 3, en utilisant par exemple une requête HTTP PATCH comprenant dans son corps, les données de souscription modifiées le cas échéant.
[0087] Par ailleurs, dans le mode de réalisation décrit ici, le ou les formats d'encodage supportés par l'entité 2 et indiqués dans les données de souscription SubscriptionData sont fournis dans une structure de données, nommée par exemple caplnfo, comprenant au moins une option de communication supportée par l'entité 2, chaque option de communication étant fournie dans un champ ou dans un attribut distinct (par exemple dans un champ ou attribut Content-Encoding de la structure caplnfo pour les formats d'encodage). Avantageusement, cette structure de données peut comprendre d'autres options de communication pouvant être utilisées par l'entité 3 lors de l'envoi des notifications, comme par exemple des formats de contenus (ex. json, xml ou autres), supportés par l'entité 2 (fournis par exemple dans un champ ou attribut Content-Type de la structure caplnfo), ou des algorithmes de chiffrement permettant de chiffrer des informations critiques fournies le cas échéant dans les notifications émises par l'entité 3 (fournis par exemple dans un champ ou attribut Encrypt-type de la structure caplnfo), etc.
[0088] En variante, le ou les formats d'encodage peuvent être fournis dans un champ ou attribut simple dédié, par exemple dans un champ ou attribut Content-Encoding. Dans une autre variante encore, ils peuvent être fournis dans un champ ou attribut propriétaire prévu par le standard 3GPP (connu sous l'appellation de « vendor-specific extension »).
[0089] En référence à la figure 4, l'entité 3 reçoit, via son module 3A de réception, la demande de souscription de l'entité 2 (étape F10).
[0090] Dans le mode de réalisation décrit ici, l'entité 3 vérifie, par l'intermédiaire de son module 3A de réception, si la demande de souscription formulée par l'entité 2 est autorisée (étape test F20). Elle peut vérifier notamment que les données de souscription indiquées dans la requête de souscription sont cohérentes avec les informations qu'elle peut publier.
[0091] Si la demande de souscription n'est pas autorisée (réponse non à l'étape test F20), elle est rejetée par l'entité 3 et l'entité 2 en est informée (étape F30).
[0092] Sinon (la demande de souscription est autorisée) (réponse oui à l'étape test F20), l'entité 3 crée un contexte de souscription CNT_SUBS(2) pour l'entité 2 et stocke dans le contexte de souscription les données de souscription SubscriptionData incluant les formats d'encodage supportés par l'entité 2 (étape F40). Une réponse HTTP 201 Created est alors retournée à l'entité 2 par l'entité 3 pour l'informer du succès de sa demande de souscription (étape E20, figure 3).
[0093] Comme évoqué précédemment, le module 3B de surveillance de l'entité 3 est configuré pour surveiller de manière continue ou quasi-continue (et en temps réel), les éléments gérés et/ou surveillés par l'entité 3 et plus particulièrement l'occurrence des événements que l'entité 3 est susceptible d'exposer (dans l'exemple de la fonction NRF, la création/suppression ou modification de profil(s) de fonction(s) réseau gérée(s) par la fonction NRF) (étape de surveillance F50 et étape test F60).
[0094] Dès lors, si le module 3B de surveillance de l'entité 3 détecte l'un de ces événements pour au moins l'un des éléments qu'il gère et/ou surveille (réponse oui à l'étape test F60), il vérifie si l'événement détecté correspond à l'une des demandes de souscription qu'il a reçues (étape test F70), et plus particulièrement ici, si l'événement détecté correspond à la demande de souscription faite par l'entité 2. Il consulte à cet effet les données de souscription contenues dans le contexte CNT_SUBS(2) et les compare avec les caractéristiques de l'événement détecté (par exemple, avec la nature de l'événement, l'élément concerné par cet événement, etc.).
[0095] Si aucune demande de souscription concerne l'événement détecté (réponse non à l'étape test F70), aucune notification n'est envoyée, et l'entité 3 continue sa surveillance (étape F50 et suivantes).
[0096] On suppose ici que l'événement détecté correspond à la demande de souscription formulée par l'entité 2, autrement dit, l'événement détecté par le module 3B de surveillance de l'entité 3 correspond à un événement pour lequel l'entité 2 souhaite être notifiée (réponse oui à l'étape test F70).
[0097] L'entité 3 envoie alors, via son module 3C d'envoi, une notification à l'entité 2 pour l'informer de l'événement détecté (étape F80). Cette notification est par exemple ici une requête HTTP POST. Elle comprend, dans son corps, des informations Notifica- tionData relatives à l'événement détecté, propres à cet événement. Par exemple, pour une fonction NRF, ces informations Notification Data peuvent comprendre tout ou partie du profil de la fonction réseau affecté par l'événement, ou plus précisément tous les attributs de ce profil destinés à être publiés s'il s'agit d'un événement de type création d'un profil, ou s'il s'agit d'un événement de type modification d'un profil, tous les attributs de ce profil destinés à être publiés ou seulement ceux qui ont été modifiés. Si l'événement concerne une suppression d'un profil (ou de façon équivalente le désen- registrement de la fonction NF associée à ce profil), les informations NotificationData comprennent l'URI de l'instance de fonction NF concernée et le type d'événement détecté (i.e. la suppression du profil ou le désenregistrement de la fonction NF). Conformément à l'invention, les informations NotificationData fournies dans la requête de notification sont encodées au moyen d'un des formats d'encodage supportés par l'entité 2 et mémorisés dans le contexte CNT_SUBS(2) de sa souscription. Par exemple ici, le module 3C d'envoi sélectionne dans le contexte CNT_SUBS(2) un format de compression pour encoder les informations NotificationData. Il indique, conformément au protocole HTTP, dans l'entête Content-Encoding de la requête de notification, le format d'encodage appliqué.
[0098] Dans le mode de réalisation décrit ici, si la structure de données caplnfo comprend d'autres options de communication qu'un ou des formats d'encodage supportés par l'entité 2, le module 3C d'envoi peut également appliquer ces options de communication aux informations NotificationData en plus de l'encodage.
[0099] En référence à la figure 3 de nouveau, l'entité 2 reçoit, via son deuxième module 2B de communication, la notification émise par l'entité 3 et l'informant de l'événement détecté (étape E30).
[0100] L'entité 2 extrait les informations NotificationData contenues dans la notification et les décode en fonction du format d'encodage appliqué par le module 3C d'envoi de l'entité 3 et signalé conformément au protocole HTTP dans les entêtes de la requête de notification. Puis le module 2C de traitement exploite, les informations ainsi décodées, par exemple pour gérer les éléments du réseau cœur CN ou rattachés à celui-ci dont l'entité 2 a la charge. Comme mentionné précédemment, la façon dont le module 2C de traitement utilise ces informations dépend des services offerts par l'entité 2, dans le réseau cœur CN ici, et/ou de la pertinence de ces informations.
[0101] Ainsi, comme il apparaît au vu de ce qui précède, l'invention permet de façon simple d'optimiser les échanges entre les différentes entités du système 1, et plus particulièrement les notifications envoyées par l'entité 3 à l'entité 2. Avantageusement, les formats d'encodage supportés par l'entité 2, incluant préférentiellement un format de compression, sont fournis lors de la souscription de l'entité 2 aux événements surveillés par l'entité 3 de sorte que l'entité 3 peut compresser les informations qu'elle envoie à l'entité 2 sans avoir à mettre en œuvre des échanges complémentaires pour la négociation du format d'encodage à utiliser. Bien entendu, des mesures additionnelles peuvent être mises en œuvre par ailleurs, dans le réseau cœur ici, pour encoder d'autres contenus de requêtes et/ou de réponses. Ainsi, dans l'exemple illustratif envisagé ici d'une entité 3 comprenant une fonction NRF, on peut envisager par exemple que les profils des fonctions réseau gérées par la fonction NRF comprennent chacun un attribut contenant au moins un format d'encodage supporté par la fonction réseau associée et que cet attribut soit publié par la fonction NRF en réponse aux requêtes de découverte qu'elle reçoit dans le cadre du service Nnrf_NFDiscovery. Avantageusement, ces formats d'encodage peuvent être fournis lors de l'enregistrement des fonctions réseau auprès de la fonction NRF. De cette sorte, les entités à l'origine des requêtes de découverte adressées à la fonction NRF peuvent utiliser sans délai les formats d'encodage fournis pour accéder aux services proposés par les fonctions réseau (i.e. sans avoir à émettre de requêtes OPTIONS ou à attendre une réponse à une requête indiquant les formats d'encodage supportés par les fonctions réseau).
[0102] Par ailleurs, bien que l'invention ait été décrite dans le contexte d'un réseau 5G défini par le standard 3GPP, en référence à des entités de réseau de type fonctions réseau, et plus particulièrement à une fonction AMF et une fonction NRF appartenant à un même réseau cœur, l'invention peut s'appliquer à d'autres entités.
[0103] Typiquement elle peut s'appliquer à d'autres fonctions réseau d'un réseau 3GPP, consommatrice d'événements et exposant de tels événements. A titre d'autre exemple, le standard 3GPP définit dans le document TS 29.518 intitulé : « Technical Spécification Group Core Network and Terminais; 5G System; Access and Mobility Management Services; Stage 3 », V16.7.0, mars 2021, que des fonctions réseau NEF, SMF ou UDM peuvent souscrire à la notification d'événements auprès d'une fonction réseau AMF en utilisant le service Namf_EventExposure. Ces fonctions réseau peuvent choisir alors d'être notifiées pour des événements concernant l'accès et la mobilité d'un UE, d'un groupe d'UEs voire de tous les UEs gérés par cette fonction AMF. Les différents événements exposés par la fonction AMF sont décrits dans le document TS 29.518 par exemple au paragraphe 6.2.6.3.3 dans la table 6.2.6.3.3-1. D'autres documents 3GPP définissent des mécanismes de souscription/notification entre d'autres fonctions ré- seau d'un réseau 5G, et les événements exposés par ces fonctions réseau.
[0104] L'invention peut s'appliquer également à d'autres réseaux qu'un réseau 5G, par exemple à un réseau 4G, 6G ou de génération suivante, ou à des réseaux propriétaires, ou à des architectures de micro-services « event-driven », etc., dès lors qu'un mécanisme de souscription/notification est mis en œuvre dans ce réseau et que les entités impliquées dans ce mécanisme sont susceptibles de supporter plusieurs formats d'encodage, et en particulier au moins un format de compression. En outre, l'invention est décrite en référence à des entités virtualisées, mais elle s'applique également à des entités physiques. Ces entités peuvent appartenir à un même réseau ou à des réseaux différents. Ainsi par exemple, les entités 2 et 3 peuvent être des fonctions NRF appartenant à deux PLMN différents, ou l'entité 3 une fonction réseau d'un réseau cœur et l'entité 2 une fonction d'application interne ou externe au réseau cœur, ou encore un équipement d'utilisateur.
[0105] L'invention peut également s'appliquer à d'autres protocoles que le protocole HTTP/2, comme par exemple à une autre version du protocole HTTP (HTTP/1.1), ou aux protocoles SOAP, CORBA, gRPC, QUIC, ou de façon générale à tout autre protocole basé sur l'échange de requêtes et de réponses, et supportant un encodage du contenu du corps des requêtes et/ou des réponses, typiquement une compression de ce contenu. Ce qui vient d'être décrit dans le cadre de requêtes/ réponses HTTP/2, et en particulier les données véhiculées par ces requêtes/ réponses pour la mise en œuvre de l'invention, s'applique, transposé aux requêtes/ réponses de ces protocoles.

Claims

Revendications
[Revendication 1] Procédé de souscription d'une première entité communicante (2) auprès d'une deuxième entité communicante (3), ledit procédé étant destiné à être mis en œuvre par la première entité et comprenant :
- une étape (E10) de demande de souscription auprès de la deuxième entité pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d'encodage supporté par la première entité ; et
- suite à une détection (F70) par la deuxième entité d'un dit événement correspondant à la demande de souscription, une étape (E30) de réception en provenance de la deuxième entité d'une notification comprenant des informations relatives audit événement détecté encodées au moyen d'un dit format d'encodage supporté par la première entité et indiqué dans la demande de souscription.
[Revendication 2] Procédé de notification d'événements à une première entité communicante
(2), destiné à être mis en œuvre par une deuxième entité communicante
(3), ledit procédé comprenant :
- une étape (F10) de réception d'une demande de souscription en provenance de la première entité pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d'encodage supporté par la première entité ; et
- suite à une détection (F70) par la deuxième entité d'un dit événement correspondant à la demande de souscription, une étape (F80) d'envoi à la première entité d'une notification comprenant des informations relatives audit événement détecté encodées au moyen d'un dit format d'encodage supporté par la première entité et indiqué dans la demande de souscription.
[Revendication 3] Procédé selon la revendication 1 ou 2 dans laquelle au moins une entité parmi la première entité et la deuxième entité (2,3) est une entité de réseau, une fonction d'application ou un équipement utilisateur.
[Revendication 4] Procédé selon l'une quelconque des revendications 1 à 3 dans lequel au moins une entité parmi la première entité et la deuxième entité est une fonction réseau ou une instance d'une fonction réseau.
[Revendication 5] Procédé selon l'une quelconque des revendications 1 à 4 dans laquelle la deuxième entité est une entité de contrôle gérant une pluralité d'entités applicatives d'un réseau.
[Revendication 6] Procédé selon l'une quelconque des revendications 1 à 5 dans lequel ledit événement détecté est une création, une suppression ou une modification d'un élément géré par la deuxième entité.
[Revendication 7] Procédé selon l'une quelconque des revendications 1 à 6 dans lequel la notification est une requête conforme à une version du protocole HTTP.
[Revendication 8] Procédé selon l'une quelconque des revendications 1 à 7 dans lequel ledit format d'encodage utilisé pour encoder les informations relatives audit événement détecté dans la notification est un format de compression.
[Revendication 9] Procédé selon l'une quelconque des revendications 1 à 8 dans lequel dans la demande de souscription, ledit au moins un format d'encodage supporté par la première entité est fourni dans une structure de données comprenant au moins une option de communication supportée par la première entité.
[Revendication 10] Programme d'ordinateur (PROG2,PROG3) comportant des instructions pour l'exécution d'un procédé selon l'une quelconque des revendications 1 à 9, lorsque ledit programme est exécuté par un ordinateur.
[Revendication 11] Support d'enregistrement (7) lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur selon la revendication 10.
[Revendication 12] Entité communicante (2), dite première entité, comprenant :
- un premier module (2A) configuré pour demander une souscription auprès d'une deuxième entité communicante pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, la demande de souscription indiquant au moins un format d'encodage supporté par la première entité ; et
- un deuxième module (2B) activé suite à une détection par la deuxième entité d'un dit événement correspondant à la demande de souscription, ledit deuxième module de réception étant configuré pour recevoir en provenance de la deuxième entité une notification comprenant des informations relatives audit événement détecté encodées au moyen d'un dit format d'encodage supporté par la première entité et indiqué dans la demande de souscription.
[Revendication 13] Entité communicante (3), dit deuxième entité, comprenant :
- un module (3A) de réception, configuré pour recevoir une demande de souscription d'une première entité communicante pour obtenir des informations concernant au moins un événement surveillé par la deuxième entité, cette demande de souscription indiquant au moins un format d'encodage supporté par la première entité ;
- un module (3C) d'envoi, activé suite à une détection d'un dit événement correspondant à la demande de souscription, et configuré pour envoyer à la première entité une notification comprenant des informations relatives audit événement détecté encodées au moyen d'un dit format d'encodage supporté par la première entité et indiqué dans la demande de souscription.
[Revendication 14] Système (1) comprenant : au moins une première entité communicante (2) selon la revendication 12 ; et au moins une deuxième entité communicante (3) selon la revendication 13.
EP22719323.2A 2021-04-02 2022-04-01 Procédés de souscription et de notification, et entités configurées pour mettre en oeuvre ces procédés Pending EP4315962A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2103448A FR3121562A1 (fr) 2021-04-02 2021-04-02 Procédés de souscription et de notifications, et entités configurées pour mettre en œuvre ces procédés.
PCT/FR2022/050617 WO2022208034A1 (fr) 2021-04-02 2022-04-01 PROCÉDÉS DE SOUSCRIPTION ET DE NOTIFICATION, ET ENTITÉS CONFIGURÉES POUR METTRE EN œUVRE CES PROCÉDÉS.

Publications (1)

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

Family

ID=76730685

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22719323.2A Pending EP4315962A1 (fr) 2021-04-02 2022-04-01 Procédés de souscription et de notification, et entités configurées pour mettre en oeuvre ces procédés

Country Status (5)

Country Link
US (1) US20240187367A1 (fr)
EP (1) EP4315962A1 (fr)
CN (1) CN117063522A (fr)
FR (1) FR3121562A1 (fr)
WO (1) WO2022208034A1 (fr)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106209942B (zh) * 2015-05-07 2020-06-09 阿里巴巴集团控股有限公司 一种数据压缩传输方法和系统、及其终端和服务器

Also Published As

Publication number Publication date
US20240187367A1 (en) 2024-06-06
WO2022208034A1 (fr) 2022-10-06
FR3121562A1 (fr) 2022-10-07
CN117063522A (zh) 2023-11-14

Similar Documents

Publication Publication Date Title
EP2936782B1 (fr) Procédé de traitement de requêtes d'accès et navigateur web
US11916734B2 (en) Third party network and network slice management
EP3603024B1 (fr) Procédé de recommandation d'une pile de communication
FR3015832A1 (fr) Technique de controle du routage d'une requete relative a un service
FR3015838A1 (fr) Procede de mise a jour dynamique d'informations obtenues de la part d'un serveur dns
WO2005076606A1 (fr) Procede d’enregistrement de contenus audio-visuels dans un reseau de communication
EP3216189A1 (fr) Délégation d'intermédiation sur un échange de données chiffrées
FR3074626A1 (fr) Procede d'acheminement de donnees d'une session initialisee entre un terminal et un serveur
WO2022208034A1 (fr) PROCÉDÉS DE SOUSCRIPTION ET DE NOTIFICATION, ET ENTITÉS CONFIGURÉES POUR METTRE EN œUVRE CES PROCÉDÉS.
EP4315961A1 (fr) Procédés de gestion, de découverte, d'enregistrement et de communication et entités configurées pour mettre en oeuvre ces procédés
FR3081582A1 (fr) Procede d'installation d'une fonction reseau virtualisee
EP3149918B1 (fr) Téléchargement de contenu et mise a disposition de réseaux
WO2011124810A1 (fr) Gestion de service personnalisee dans un reseau ip
FR3129506A1 (fr) Entité applicative ayant une architecture de micro-services, entité de contrôle et procédés mis en œuvre par ces entités
EP1494419B1 (fr) Système de transmission de paramètres caractéristiques d'une session de communication d'un terminal vers un serveur distant
EP4335144A1 (fr) Parametrage d'un terminal
Falchuk et al. An open service platform for deploying and managing services at network edges
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
EP3866432B1 (fr) Transmission de flux de données adaptable
EP4258137A1 (fr) Procédé de distribution de fichier entre systèmes 3gpp mcdata interconnectés
EP4335145A1 (fr) Procédé d'enregistrement d'un terminal utilisateur auprès d'un réseau de communications organise en tranches de réseau
FR3105677A1 (fr) Procédé d’acheminement de messages, équipement réseau associé
FR3132000A1 (fr) Procédé de mise à jour d’une politique d’accès à un premier réseau de télécommunication, système, équipements et programmes d’ordinateurs correspondants
FR3102595A1 (fr) Procédé de diffusion d’une vidéo par un dispositif client, dispositif client et système associé
FR2999374A1 (fr) Selection multicriteres de systemes de diffusion de contenu

Legal Events

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

Free format text: STATUS: UNKNOWN

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

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

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20231016

AK Designated contracting states

Kind code of ref document: A1

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