Data change event handling

Abstract

There is provided a method for handling data change events in a network. The method is performed by a user data management (UDM) node of the network. The method comprises initiating (202) transmission of a network function (NF) profile of the UDM node towards a network repository function (NRF) node of the network. The NF profile comprises first information indicative of a first subscription to a user data repository (UDR) node of the network. The first subscription is a subscription to be notified of a data change event occurring at any wireless device of a plurality of wireless devices of the network.

Description

[0001] DATA CHANGE EVENT HANDLING

[0002] Technical Field

[0003] The present disclosure relates to methods for handling data change events in a network, and nodes configured to operate in accordance with those methods.

[0004] The third-generation partnership project (3GPP) technical specification (TS) 28.310 version 18.0.0 describes principles and mechanisms for energy saving in the fifth generation (5G) radio access network (RAN) (5G-RAN). In 3GPP release (Rel-) 17, work began on developing such energy saving mechanisms and principles for the 5G Core Network as described in, for example, service and system aspects five (SA5) study.

[0005] Compute nodes, and their related dimensioning, are tightly related to a number of Transactions Per Second (TPS) which occur in a network. Hence, it is desirable (e.g. for 3GPP efforts) to optimise interactions and signaling among network functions in a network to achieve the desired outcomes.

[0006] In certain networks (e.g. those comprising exposure technology), some types of information and / or configurations are applicable to all UEs (any UE) in the network, and not on an individual UE basis. In a public land mobile network (PLMN), these types of information can be referred to as PLMN-wide information. Such PLMN-wide information is stored in a user data repository (UDR) and read by user data management (UDM) entities, policy control function (PCF) entities, etc. In particular, some events in a 5GC network, for example an international mobile station equipment identity (I MEI) change or software version change (e.g. an international mobile station equipment identity and software version (IMEISV) change), are usually requested for any UE belonging to a mobile network operator (MNO). In general, when an event is detected for a given UE in the network, and there is a subscription to notifications of the event, the event is to be notified. When certain events are detected (e.g. in the case of IMEISV change) it is the role of the UDM to notify the relevant entity of the event. However, there exist certain challenges associated with existing techniques for handling such events.

[0007] In particular, when the UDM needs to notify a relevant entity of a change at a UE of the network, the UDM sends a request to a UDR for associated information. However, it is often the case that there are multiple UEs in the network. In such cases, each UE change results in the UDM sending the same request for associated information to the UDR, which the UDR must respond to. As such, there is a high rate of information repetition in the communication between UDM and UDR, which clearly leads to a waste of network resources. In a particular example, in which there is a massive change to the UEs in a network (e.g. an Android version update), and millions of users update a software version on their UEs (e.g. smartphones) in a short period of time, the UDR may be saturated with the same request from the UDM over and over again, millions of times. Therefore, such a change can cause the UDR to experience overload and lose requests from the UDM, resulting in a failure in the network to provide the appropriate response to the change. Furthermore, the signalling repetition that results from the change leads to a large consumption of network resources and thus a significant amount of energy is used to provide the appropriate response to the change.

[0008] Summary

[0009] As mentioned above, there are certain challenges associated with existing techniques for handling data change events in a network. Specifically, existing techniques do not make efficient use of network resources when reacting to a data change event which should be notified to one or more entities in the network. In particular, existing techniques often involve sending multiple communications between a UDM and UDR in order for the UDM to retrieve information which has already been retrieved. This is disadvantageous, especially when such an existing technique experiences a high rate of a particular data change event in the network. Indeed, such a scenario can lead to overload in the network, degradation in network performance, and an undesirably large consumption of both network resources and energy.

[0010] It is an object of the disclosure to obviate or eliminate some of the challenges associated with existing techniques.

[0011] Therefore, according to an aspect of the disclosure, there is provided a first method for handling data change events in a network. The first method is performed by a user data management (UDM) node of the network. The first method comprises initiating transmission of a network function (NF) profile of the UDM node towards a network repository function (NRF) node of the network. The NF profile comprises first information indicative of a first subscription to a user data repository (UDR) node of the network. The first subscription is a subscription to be notified of a data change event occurring at any wireless device of a plurality of wireless devices of the network.

[0012] According to another aspect of the disclosure, there is provided a second method for handling data change events in a network. The second method is performed by a NRF node of the network. The second method comprises receiving a NF profile of a UDM node of the network. The NF profile comprises first information indicative of a first subscription to a UDR node of the network. The first subscription is a subscription to be notified of a data change event occurring at any wireless device of a plurality of wireless devices of the network.

[0013] According to another aspect of the disclosure, there is provided a third method for handling data change events in a network. The third method is performed by a UDR node of the network. The third method comprises, in response to obtaining, from one or more network function (NF) nodes of the network, one or more respective first subscriptions determining, based on first information comprised in a NF profile of at least one UDM node of the network, that the at least one UDM node is to be notified of the one or more respective first subscriptions. The first information is indicative of a first subscription to the UDR node. A first subscription is a subscription to be notified of the data change event occurring at any wireless device of the plurality of wireless devices of the network.

[0014] According to another aspect of the disclosure, there is also provided a UDM node comprising processing circuitry configured to operate in accordance with the first method. In some embodiments, the UDM node may comprise at least one memory for storing instructions which, when executed by the processing circuitry, cause the UDM node to operate in accordance with the first method.

[0015] According to another aspect of the disclosure, there is also provided a NRF node comprising processing circuitry configured to operate in accordance with the second method. In some embodiments, the NRF node may comprise at least one memory for storing instructions which, when executed by the processing circuitry, cause the NRF node to operate in accordance with the second method.

[0016] According to another aspect of the disclosure, there is also provided a UDR node comprising processing circuitry configured to operate in accordance with the third method. In some embodiments, the UDR node may comprise at least one memory for storing instructions which, when executed by the processing circuitry, cause the UDR node to operate in accordance with the third method.

[0017] According to another aspect of the disclosure, there is provided a method performed by a system. The method comprises any two or more of the first, second and third methods described earlier.

[0018] According to another aspect of the disclosure, there is provided a system comprising any two or more of a UDM node as described earlier, a NRF node as described earlier, and a UDR node as described earlier.

[0019] According to another aspect of the disclosure, there is provided a computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform any one or more of the first, second and third methods described earlier.

[0020] According to another aspect of the disclosure, there is provided a computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform any one or more of the first, second and third methods described earlier.

[0021] Thus, in the manner described above, improved techniques for handling data change events in a network are provided. Advantageously, the improved techniques reduce the number of communications between a UDM node and a UDR node in the network. The improved techniques reduce the number of communications by enabling the UDM node to subscribe to being informed of information stored at the UDR node in a more efficient manner. Advantageously, by reducing the number of communications in the network, network resource consumption is also reduced and energy savings are made. Furthermore, the improved techniques provide for a methodology which is less prone to signaling storms and overload. That is, if a data change event is massively detected for many wireless devise (e.g. UEs) in the network (e.g. PLMN), no extra traffic is sent to the UDR node, since the UDM node already has the necessary info to notify all relevant NFs of the network. As such, compute resources can be safely dimensioned without taking into account massive event detection in many cases, since the UDR node is not receiving as much (e.g. any) traffic associated with subscriptions applicable to any wireless device.

[0022] Brief description of the drawings

[0023] For a better understanding of the techniques, and to show how they may be put into effect, reference will now be made, by way of example, to the accompanying drawings, in which:

[0024] Figure 1 is a signalling diagram illustrating an example exchange of signals in a network according to an existing technique for handling a data change event at a user equipment (UE);

[0025] Figure 2 is a block diagram illustrating a user data management (UDM) node according to an embodiment;

[0026] Figure 3 is a block diagram illustrating a method performed by the UDM node according to an embodiment;

[0027] Figure 4 is a block diagram illustrating a network repository function (NRF) node according to an embodiment;

[0028] Figure 5 is a block diagram illustrating a method performed by the NRF node according to an embodiment;

[0029] Figure 6 is a block diagram illustrating a user data repository (UDR) node according to an embodiment;

[0030] Figure 7 is a block diagram illustrating a method performed by the UDR node according to an embodiment;

[0031] Figure 8 is a signalling diagram illustrating an exchange of signals in a system according to an embodiment;

[0032] Figure 9 is a block diagram illustrating an example NF profile according to an embodiment; and Figures 10 and 11 are signalling diagrams illustrating an exchange of signals in a system according to some embodiments.

[0033] Figure 12 is an example embodiment of a virtualization environment.

[0034] Detailed Description

[0035] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0036] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject-matter disclosed herein, the disclosed subject-matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject-matter to those skilled in the art.

[0037] In some instances, detailed descriptions of well-known methods, entities, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more entities using hardware circuitry (e.g., analogue and / or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and / or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Entities that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0038] As described earlier, there are described herein improved techniques performed by nodes of a network. The network referred to herein can be any type of network. For example, the network referred to herein may be a communications or telecommunications network. In some embodiments, the network referred to herein can be a mobile network, such as a fifth generation (5G) mobile network or any other generation mobile network (e.g. 6G). For example, the network referred to herein can be a 5G core (5GC) network. In some embodiments, the network referred to herein can be a radio access network (RAN). In some examples, the network referred to herein may be a public land mobile network (PLMN). In some embodiments, the network referred to herein can be a virtual network or an at least partially virtual network. Although some examples have been provided for the type of network referred to herein, it will be understood that the network referred to herein can be any other type of network.

[0039] As described earlier, the techniques described herein involve a plurality of wireless devices. As used herein, a wireless device may refer to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other wireless devices. Examples of a wireless device include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless camera, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptopmounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any wireless device identified by the 3GPP, including a narrow band internet of things (NB-loT) wireless device, a machine type communication (MTC) wireless device, and / or an enhanced MTC (eMTC) wireless device. Herein, a wireless device may be a user equipment (UE).

[0040] A wireless device may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In order to aid the understanding of techniques described herein, and the associated technical advantages, an example of some existing techniques will first be described.

[0041] Figure 1 is a signalling diagram illustrating an existing technique for handling a change at a user equipment (UE) in a network. The network illustrated in Figure 1 comprises a network exposure function (NEF) 102, a first user data management (UDM) node 104 (“UDM-1 ”), a second UDM node 106 (“UDM-2”), a first user data repository (UDR) node 108 (“UDR (UEs)”), a second UDR node 110 (“UDR central”), an access and mobility management function (AMF) 112, a first UE 114 (“UE-1”), a second UE 116 (“UE-2”), and a third UE 118 (“UE-3”). The network shown can be a 5GC network.

[0042] As illustrated by block 120 of Figure 1 , an application subscribes to the NEF 102 as the application wants to be notified about IMEI(SV) changes in the whole network (e.g. a PLMN). An IMEI(SV) change can occur when a subscriber identity module (SIM) is put in a new UE (e.g. a device / smartphone), or a UE with a SIM updates its software (SW) (e.g. iPhone operating system (iOS) version update in an iPhone).

[0043] As illustrated by arrow 122 of Figure 1 , the NEF 102 send a message (“HTTP POST (any UE) Event=IMEISV change”) to the first UDM node 104. The first UDM node 104 is thus aware that the application wishes to subscribed to any IMEI(SV) changes in the network. As illustrated by arrow 124 of Figure 1 , the first UDM node 104 sends the message to the second UDR node 110. As such, the first UDM node 104 stores the subscription to IMEISV change in the second UDR node 110. As illustrated by arrow 124 of Figure 1 , the subscription information can be stored in the first UDR node 108 and the second UDR node 110. Since the first UDM node 104 is stateless (e.g. or data-less), and the subscription from the application requires persistency in the network, the first UDM node 104 must store the subscription at the second UDR node 110. Hence, the subscription to notifications information is now available at the second UDR node 110 and is available to all UDMs in the network (e.g. first UDM node 104 and second UDM node 106) when needed.

[0044] As illustrated by block 128 of Figure 1 , a user buys a new smartphone (i.e. the first UE 114) and puts his SIM card in the new smartphone. As illustrated by arrow 130 of Figure 1 , since the user’s SIM / subscription permanent identifier (SUPI) now has a different permanent equipment identifier (PEI) / international mobile station equipment identity (IMEI), the AMF 112 informs the first UDM node 104 about the change via a transmitted message (“HTTP PUT (UE-1 context update) New IMEISV”) to the first UDM node 104.

[0045] As illustrated by block 132 of Figure 1 , the first UDM node 104 reads a current UE context, from the first UDR node 108 and / or the second UDR node 110, that is allocated to an international mobile subscriber identity (IMSI)ZSUPI. The first UDM node 104 then stores the new PEI / IMEI in the first UDR node 108 and / or the second UDR node 110.

[0046] As illustrated in Figure 1 , there are two types of UDR. The first type corresponds to the first UDR node 108 and is configured to store individual UE subscription data and context data. The second type corresponds to the second UDR node 110 and is configured to store data which is common to all UEs in the network. The second UDR node 110 can be referred to as a “central UDR”, since the second UDR node 110 stores data that is not specific to any individual UE, but to all UEs (e.g. any UE) in the network. In practice, the first UDR node 108 and the second UDR node 110 can be deployed as a single UDR node. Alternatively, (e.g. for scalability purposes) the first UDR node 109 and the second UDR node 110 can be deployed as separate UDR nodes (as illustrated in Figure 1).

[0047] As illustrated by arrow 134 of Figure 1 , since the first UDM node 104 has detected an IMEISV change for the first UE 114, the first UDM node 104 checks whether there are subscriptions to notifications about such an event which are applicable to all UEs (e.g. any UE). As also illustrated by arrow 134 of Figure 1 , the first UDM node 104 performs this check by transmitting a message (“HTTP GET (any UE) Event=IMEISV change”) to the second UDR node 110. As illustrated by block 136 of Figure 1 , the second UDR node 110 returns the stored subscriptions applicable to any UE. As illustrated by arrow 138 of Figure 1 , the second UDR node 110 provides the subscriptions information to the first UDM node 104 via a transmitted message (“HTTP 200 OK (Any UE subscriptions information)”).

[0048] As illustrated by block 140 of Figure 1 , since there is an active subscription to the event detected, the first UDM node 104 notifies the relevant endpoint (i.e. the NEF 102). The identity of the relevant endpoint (i.e. the NEF 102) is part of the subscription information retrieved from the second UDR node 110. As illustrated by arrow 142 of Figure 1 , the first UDM node 104 can notify the NEF 102 by transmitting a message (“HTTP POST (UE-1 , new IMEISV)”). Thus, the subscribed application can be notified of the change in IMEISV. As illustrated by block 144 of Figure 1 , a user updates the software on his smartphone (i.e. the second UE 116) (e.g. by installing a newly released Android software version). Since this is a change in the software version (SV) part of the IMEISV, the AMF 112 informs the second UDM node 106 about the change. As illustrated by arrow 146 of Figure 1 , the AMF 112 informs the second UDM node 106 of the change by transmitting a message (“HTTP PUT (UE-2 context update) New IMEISV”) to the second UDM node 106.

[0049] As illustrated by block 148 of Figure 1 , the second UDM node 106 reads the current UE context, from the first UDR node 108 and / or the second UDR node 110, that is allocated to the IMSI / SUPI. The second UDM node 106 then stores the new PEI / IMEI in the first UDR node 108 and / or the second UDR node 110. Since the second UDM node 106 has detected an IMEISV change for the second UE 116, the second UDM node 106 checks whether there are subscriptions to notifications about such an event which are applicable to all UEs (e.g. any UE). As such, as illustrated by block 150 of Figure 1 , the method steps as described with reference to arrow 134, block 136 and arrow 138 of Figure 1 are performed again, with the exception that the second UDM node 106 performs the steps instead of the first UDM node 104, as mentioned above. That is, the second UDM node 106 queries the second UDR node 110 to retrieve the same exact information.

[0050] As illustrated by block 152 of Figure 1 , since there is an active subscription to the event detected, the second UDM node 106 notifies the relevant endpoint (i.e. the NEF 102). The identity of the relevant endpoint (i.e. the NEF 102) is part of the subscription information retrieved from the second UDR node 110. As illustrated by arrow 154 of Figure 1 , the second UDM node 106 can notify the NEF 102 by transmitting a message (“HTTP POST (UE-2, new IMEISV)”). Thus, the subscribed application can be notified of the change in IMEISV.

[0051] As illustrated by block 156 of Figure 1 , another user updates their software (e.g. an iOS version update) on their iPhone (i.e. third UE 118). Since this is a change in the software version (SV) part of the IMEISV, the AMF 112 informs the first UDM node 104 about the change. As illustrated by arrow 158 of Figure 1 , the AMF 112 informs the first UDM node 104 of the change by transmitting a message (“HTTP PUT (UE-2 context update) New IMEISV”) to the first UDM node 104. As illustrated by block 160 of Figure 1 , the first UDM node 104 reads the current UE context, from the first UDR node 108 and / or the second UDR node 110, that is allocated to the IMSI / SUPI. The first UDM node 104 then stores the new PEI / IMEI in the first UDR node 108 and / or the second UDR node 110. Since the first UDM node 104 has detected an IMEISV change for the third UE 118, the first UDM node 104 checks whether there are subscriptions to notifications about such an event which are applicable to all UEs (e.g. any UE). As such, as illustrated by block 162 of Figure 1 , the method steps as described with reference to arrow 134, block 136 and arrow 138 of Figure 1 are performed again (i.e. for a third time). That is, the first UDM node 104 queries the first UDR node 108 to retrieve the same exact information.

[0052] Therefore, both the first UDM node 104 and the second UDM node 106 are repeatedly and constantly retrieving the same exact information from a UDR (e.g. the first UDR node 108 and / or the second UDR node 110). In particular, the first UDM node 104 and the second UDM node 106 are repeatedly retrieving information related to subscriptions to notifications which are to be applied to any UE in the network.

[0053] Therefore, the existing technique as described with reference to Figure 1 is inefficient. In particular, the same information is retrieved from a UDR again and again, no matter the UE that is experiencing a change. Since the UDM nodes are dataless (e.g. stateless), the UDM nodes are not configured to “remember” anything, even if the UDM nodes have already been provided with the same information multiple times simultaneously, since the requests to the UDR relate to different traffic requests and are thus each handled in an independent manner. As such, the existing technique as described with reference to Figure 1 leads to a waste of computing resources in both UDM nodes and UDR nodes.

[0054] Moreover, if there is a massive change (e.g. a widespread Android software version update) and millions of users update their devices to a new SW version (e.g. on their smartphones in a very short period), a UDR will receive the same exact request again and again (e.g. millions of times). This can cause significant overload at the UDR and lead to some requests being lost, resulting in notifications to subscribed applications not being made.

[0055] In addition, the UDR hosting data applicable to any UE in the network is usually a centralised UDR (e.g. the second UDR node 110 of Figure 1). In these scenarios, a UDM needs to access two different UDRs (e.g. a first UDR node 108 and a second UDR node 110) since one UDR (e.g. “central UDR”) holds UE subscription / context data (e.g. which includes IMEISV information), and the other UDR (e.g. “UDR (UEs)”) holds information associated with subscriptions to events applicable to any UE. This topology introduces latency when it comes to notification of events, since the central UDR is not deployed in all clusters, sites, and / or data centres, but it is rather nation-wide. As such, the geographical location of the central UDR can be very distant from the requesting UDM’s geographical location.

[0056] Furthermore, if there are multiple events subscribed for any UE, the responses from a UDR can grow exponentially. Moreover, if other scenarios result in an event which might be subscribed for all UEs, a UDM may need to retrieve the information again and again. In short: the existing techniques for handling such events are not scalable and will require increased computing resources in order to handle more applications being subscribed to be notified about events for UEs in a network.

[0057] The improved techniques described herein address the challenges associated with existing techniques, such as that illustrated in Figure 1. In particular, the improved techniques discussed herein enable UDM nodes to become stateful such that they are aware of subscriptions to notifications of UE changes in the network.

[0058] Figure 2 illustrates a user data management (UDM) node 10 of a network in accordance with an embodiment. The UDM node 10 is for for handling data change events in a network. In some embodiments, the UDM node 10 referred to herein can refer to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with the network repository function (NRF) node referred to herein, the user data repository (UDR) node referred to herein, and / or with other nodes or equipment to enable and / or to perform the functionality described herein. In some embodiments, the UDM node 10 referred to herein can, for example, be a physical node (e.g. a physical machine or server) or a virtual node (e.g. a virtual machine, VM).

[0059] As illustrated in Figure 2, the UDM node 10 comprises processing circuitry (or logic) 12. The processing circuitry 12 controls the operation of the UDM node 10 and can implement the method described herein in respect of the UDM node 10. The processing circuitry 12 can be configured or programmed to control the UDM node 10 in the manner described herein. The processing circuitry 12 can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and / or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of the UDM node 10. In some embodiments, the processing circuitry 12 can be configured to run software to perform the method described herein in respect of the UDM node 10. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry 12 may be configured to run a container to perform the method described herein in respect of the UDM node 10.

[0060] Briefly, the processing circuitry 12 of the UDM node 10 is configured to initiate transmission of a NF profile of the UDM node 10 towards a NRF node of the network. The NF profile comprises first information indicative of a first subscription to a UDR node of the network. The first subscription is a subscription to be notified of a data change event occurring at any wireless device of a plurality of wireless devices of the network.

[0061] As illustrated in Figure 2, in some embodiments, the UDM node 10 may optionally comprise a memory 14. The memory 14 of the UDM node 10 can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory 14 of the UDM node 10 may comprise a non-transitory media. Examples of the memory 14 of the UDM node 10 include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital versatile disk (DVD), and / or any other memory.

[0062] The processing circuitry 12 of the UDM node 10 can be communicatively coupled (e.g. connected) to the memory 14 of the UDM node 10. In some embodiments, the memory 14 of the UDM node 10 may be for storing program code or instructions which, when executed by the processing circuitry 12 of the UDM node 10, cause the UDM node 10 to operate in the manner described herein in respect of the UDM node 10. For example, in some embodiments, the memory 14 of the UDM node 10 may be configured to store program code or instructions that can be executed by the processing circuitry 12 of the UDM node 10 to cause the UDM node 10 to operate in accordance with the method described herein in respect of the UDM node 10. Alternatively or in addition, the memory 14 of the UDM node 10 can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry 12 of the UDM node 10 may be configured to control the memory 14 of the UDM node 10 to store any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0063] In some embodiments, as illustrated in Figure 2, the UDM node 10 may optionally comprise a communications interface 16. The communications interface 16 of the UDM node 10 can be communicatively coupled (e.g. connected) to the processing circuitry 12 of the UDM node 10 and / or the memory 14 of the UDM node 10. The communications interface 16 of the UDM node 10 may be operable to allow the processing circuitry 12 of the UDM node 10 to communicate with the memory 14 of the UDM node 10 and / or vice versa. Similarly, the communications interface 16 of the UDM node 10 may be operable to allow the processing circuitry 12 of the UDM node 10 to communicate with any one or more nodes (e.g. the NRF node referred to herein, and / or the UDM node referred to herein) referred to herein and / or any other node. The communications interface 16 of the UDM node 10 can be configured to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry 12 of the UDM node 10 may be configured to control the communications interface 16 of the UDM node 10 to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0064] Although the UDM node 10 is illustrated in Figure 2 as comprising a single memory 14, it will be appreciated that the UDM node 10 may comprise at least one memory (i.e. a single memory or a plurality of memories) 14 that operate in the manner described herein. Similarly, although the UDM node 10 is illustrated in Figure 2 as comprising a single communications interface 16, it will be appreciated that the UDM node 10 may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interfaces) 16 that operate in the manner described herein. It will also be appreciated that Figure 2 only shows the components required to illustrate an embodiment of the UDM node 10 and, in practical implementations, the UDM node 10 may comprise additional or alternative components to those shown.

[0065] Figure 3 illustrates a method performed by the UDM node 10 of a network in accordance with an embodiment. The method is for handling data change events in a network. The UDM node 10 described earlier with reference to Figure 2 can be configured to operate in accordance with the method of Figure 3. The method can be performed by or under the control of the processing circuitry 12 of the UDM node 10 according to some embodiments.

[0066] With reference to Figure 3, as illustrated by block 202, transmission of an NF profile of the UDM node 10 is initiated towards a NRF node of the network. Herein, the term “initiate” can mean, for example, cause or establish. Thus, the UDM node 10 (e.g. the processing circuitry 12 of the UDM node 10) can be configured to itself transmit the first request (e.g. via the communications interface 16 of the UDM node 10) or can be configured to cause another entity to transmit the first request. The NF profile comprises first information indicative of a first subscription to a UDR node of the network. The first subscription is a subscription to be notified of a data change event occurring at any wireless device of a plurality of wireless devices of the network.

[0067] Therefore, the UDM node 10 is able to send its NF profile to the NRF node. As described herein, the first information comprised in the NF profile can comprise a (e.g. new) notification uniform resource indicator (URI) which can serve as an implicit subscription towards the UDR node to be notified of the data change event occurring at any wireless device of a plurality of wireless devices of the network. Thus, the UDM node 10 can be (e.g. automatically) notified of data change events as a result of subscribing to the UDR node via the NF profile transmitted to the NRF node.

[0068] In some examples, the plurality of wireless devices of the network may comprise a group of wireless devices of the network. For example, the plurality of wireless devices of the network may comprise all wireless devices (e.g. UEs) of the network associated with a telecoms operator of the network. In some examples, the plurality of wireless devices may comprise all wireless devices (e.g. of a particular type) in the network. For example, the plurality of wireless devices may comprise all UEs of the network.

[0069] The data change event described herein may be any data change event (e.g. one or more data change events) which may occur at any of the plurality of wireless devices. As such, the first subscription can be a subscription to be notified of any data change which can (e.g. potentially) occur at any wireless device of the plurality of wireless devices. In some examples, the method may comprise obtaining 203, from the UDR node, second information indicative of one or more first subscriptions to the UDR node. The second information can be indicative of one or more NF nodes of the network associated with the respective one or more first subscriptions. Therefore, the UDM node may obtain information indicative of any NF of the network (e.g. another UDM node, and / or a network exposure function (NEF) of the network) that has subscribed to be notified of the data change event (e.g. via a first subscription as defined herein). In some examples, the second information can be received in response to initiating transmission of the NF profile. As such, initiating transmission of the NF profile of the UDM node 10, as described herein, can trigger the receipt of the second information from the UDR node. In some examples, the method may comprise storing 204 the second information in a memory of the UDM node 10 (e.g. the memory 14 of the UDM node 10).

[0070] In some examples, the method may comprise obtaining third information indicative that the data change event has occurred at a first wireless device of the plurality of wireless devices. The method may further comprise identifying, based on the second information, the one or more NF nodes to which to initiate transmission of the third information. The UDM node 10 may then use the second information (received from the UDR node) to identify (e.g. and notify) any subscribed NF nodes (e.g. an NEF node as mentioned herein) of the data change event. In some examples, the third information may comprise information indicative of the (e.g. details of the) data change event that has occurred at the first wireless device. Therefore, in some examples, the third information can comprise information indicative that the data change event has occurred, and the details of the data change event. The information indicative of the data change event can comprise a configuration of the first wireless device after (e.g. resulting from) the data change event. In some examples, obtaining the third information may comprise receiving the third information from a second NF node of the network. The (e.g. type of the) second NF node may depend on the type of data change event. The second NF node may be an access and mobility management function (AMF) node of the network (e.g. in examples in which the data change event is an IMEISV change).

[0071] In some examples, the method may comprise receiving 205 a first request for the first subscription from a first NF node of the network, and initiating transmission of the NF profile in response to receiving the first request. Therefore, in some examples, the UDM node 10 may receive a request for a first NF node to be subscribed to the data change event as described herein. In some examples, the first request can trigger the transmission initiation of the NF profile of the UDM node 10 as described herein.

[0072] In some examples, initiating transmission of the NF profile may comprise initiating transmission of a registration message comprising the NF profile. Therefore, transmission initiation of the NF profile as described herein may be performed as part of a registration of the UDM node 10 at the NRF node. Alternatively, in some examples, initiating transmission of the NF profile may comprise initiating transmission of an update message comprising the NF profile. Therefore, transmission initiation of the NF profile as described herein may be performed as an update (e.g. of a previously stored NF profile of the UDM node 10) at the NRF node.

[0073] In some examples, initiating transmission of the NF profile may comprise initiating transmission of a hypertext transfer protocol (HTTP) PUT message comprising the NF profile. In some examples, the first information may comprise a uniform resource identifier (URI).

[0074] Figure 4 illustrates a NRF node 20 of a network in accordance with an embodiment. The NRF node 20 is for handling data change events in a network. In some embodiments, the NRF node 20 referred to herein can referto equipment capable, configured, arranged and / or operable to communicate directly or indirectly with the UDM node 10 referred to herein, the UDR node referred to herein, and / or with other nodes or equipment to enable and / or to perform the functionality described herein. In some embodiments, the NRF node 20 referred to herein can, for example, be a physical node (e.g. a physical machine or server) or a virtual node (e.g. a virtual machine, VM).

[0075] As illustrated in Figure 4, the NRF node 20 comprises processing circuitry (or logic) 22. The processing circuitry 22 controls the operation of the NRF node 20 and can implement the method described herein in respect of the NRF node 20. The processing circuitry 22 can be configured or programmed to control the NRF node 20 in the manner described herein. The processing circuitry 22 can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and / or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of the NRF node 20. In some embodiments, the processing circuitry 22 can be configured to run software to perform the method described herein in respect of the NRF node 20. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry 22 may be configured to run a container to perform the method described herein in respect of the NRF node 20.

[0076] Briefly, the processing circuitry 22 of the NRF node 20 is configured to receive, from a UDM node 10 of the network, a NF profile of the UDM node 10. The NF profile comprises first information indicative of a first subscription to a UDR node of the network. The first subscription is a subscription to be notified of a data change event occurring at any wireless device of a plurality of wireless devices of the network.

[0077] As illustrated in Figure 4, in some embodiments, the NRF node 20 may optionally comprise a memory 24. The memory 24 of the NRF node 20 can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory 24 of the NRF node 20 may comprise a non-transitory media. Examples of the memory 24 of the NRF node 20 include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital versatile disk (DVD), and / or any other memory.

[0078] The processing circuitry 22 of the NRF node 20 can be communicatively coupled (e.g. connected) to the memory 24 of the NRF node 20. In some embodiments, the memory 24 of the NRF node 20 may be for storing program code or instructions which, when executed by the processing circuitry 22 of the NRF node 20, cause the NRF node 20 to operate in the manner described herein in respect of the NRF node 20. For example, in some embodiments, the memory 24 of the NRF node 20 may be configured to store program code or instructions that can be executed by the processing circuitry 22 of the NRF node 20 to cause the NRF node 20 to operate in accordance with the method described herein in respect of the NRF node 20. Alternatively or in addition, the memory 24 of the NRF node 20 can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry 22 of the NRF node 20 may be configured to control the memory 24 of the NRF node 20 to store any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, as illustrated in Figure 4, the NRF node 20 may optionally comprise a communications interface 26. The communications interface 26 of the NRF node 20 can be communicatively coupled (e.g. connected) to the processing circuitry 22 of the NRF node 20 and / or the memory 24 of the NRF node 20. The communications interface 26 of the NRF node 20 may be operable to allow the processing circuitry 22 of the NRF node 20 to communicate with the memory 24 of the NRF node 20 and / or vice versa. Similarly, the communications interface 26 of the NRF node 20 may be operable to allow the processing circuitry 22 of the NRF node 20 to communicate with any one or more nodes (e.g. UDM node 10 referred to herein, and / or the UDR node referred to herein) referred to herein and / or any other node. The communications interface 26 of the NRF node 20 can be configured to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry 22 of the NRF node 20 may be configured to control the communications interface 26 of the NRF node 20 to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0079] Although the NRF node 20 is illustrated in Figure 4 as comprising a single memory 24, it will be appreciated that the NRF node 20 may comprise at least one memory (i.e. a single memory or a plurality of memories) 24 that operate in the manner described herein. Similarly, although the NRF node 20 is illustrated in Figure 4 as comprising a single communications interface 26, it will be appreciated that the NRF node 20 may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interfaces) 26 that operate in the manner described herein. It will also be appreciated that Figure 4 only shows the components required to illustrate an embodiment of the NRF node 20 and, in practical implementations, the NRF node 20 may comprise additional or alternative components to those shown.

[0080] Figure 5 illustrates a method performed by the NRF node 20 of a network in accordance with an embodiment. The method is for handling data change events in a network. The NRF node 20 described earlier with reference to Figure 4 can be configured to operate in accordance with the method of Figure 5. The method can be performed by or under the control of the processing circuitry 22 of the NRF node 20 according to some embodiments. With reference to Figure 5, at block 302, a NF profile of a UDM node 10 of the network is received from the UDM node 10. The NF profile comprises first information indicative of a first subscription to a UDR node of the network. The first subscription is a subscription to be notified of a data change event, as described herein, occurring at any wireless device of a plurality of wireless devices of the network, as described herein.

[0081] Although not illustrated in Figure 5, in some examples, the method may comprise storing the NF profile at the NRF node 20 (e.g. in the memory 24 of the NRF node 20). In some examples, storing the NF profile may comprise updating an NF profile of the UDM node 10 previously stored at the NRF node 20. In these examples, the NRF node 20 may have previously received (e.g. and stored) an NF profile from the UDM node 10.

[0082] In some examples, the method may comprise making the first information available to the UDR node. Making the first information available to the UDR node may comprise initiating transmission of the first information towards the UDR node. In some examples, the NRF node 20 may receive a request for NF profile information from the UDR node. The NRF node 20 may initiate transmission of the first information towards the UDR node in response to receiving this request. Therefore, the UDR node can (e.g. directly) retrieve the first information (e.g. and / or the NF profile of the UDM node 10) from the NRF node 20. In some examples, initiating transmission of the first information towards the UDR node may comprise initiating transmission of a HTTP PUT message comprising the first information.

[0083] In some examples, the method may comprise receiving a second request from the UDR node. The second request can be a request to be notified of UDM node NF profile changes. Therefore, in some examples, the UDR node can subscribe, at the NRF node 20, to NF profile changes of any UDM nodes (e.g. the UDM node 10). In some examples, the NRF node 20 may (e.g. automatically) make the first information available to the UDR node if the second request has (e.g. previously) been received by the NRF node 20. As described herein, in some examples, the first information may comprise a uniform resource identifier (URI).

[0084] Figure 6 illustrates a UDR node 30 of a network in accordance with an embodiment. The UDR node 30 is for handling data change events in a network. In some embodiments, the UDR node 30 referred to herein can refer to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with the UDM node 10 referred to herein, the NRF node 20 referred to herein, and / or with other nodes or equipment to enable and / or to perform the functionality described herein. In some embodiments, the UDR node 30 referred to herein can, for example, be a physical node (e.g. a physical machine or server) or a virtual node (e.g. a virtual machine, VM). The UDR node 30 may be a (e.g. single) central UDR node of the network. Alternatively, the functionality of the UDR node 30 described herein may be configured to be performed by more than one (e.g. two) UDR nodes. For example, the functionality of the UDR node 30 may be performed by a first UDR node and a second UDR node (e.g. such as those described with reference to Figure 1 above).

[0085] As illustrated in Figure 6, the UDR node 30 comprises processing circuitry (or logic) 32. The processing circuitry 32 controls the operation of the UDR node 30 and can implement the method described herein in respect of the UDR node 30. The processing circuitry 32 can be configured or programmed to control the UDR node 30 in the manner described herein. The processing circuitry 32 can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and / or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of the UDR node 30. In some embodiments, the processing circuitry 32 can be configured to run software to perform the method described herein in respect of the UDR node 30. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry 32 may be configured to run a container to perform the method described herein in respect of the UDR node 30.

[0086] Briefly, the processing circuitry 32 of the UDR node 30 is configured to, in response to obtaining, from one or more NF nodes of the network, one or more respective first subscriptions, determine, based on first information comprised in a NF profile of at least one UDM node of the network, that the at least one UDM node is to be notified of the one or more respective first subscriptions. The first information is indicative of a first subscription to the UDR node 30. The first subscription is a subscription to be notified of a data change event occurring at any wireless device of a plurality of wireless devices of the network.

[0087] As illustrated in Figure 6, in some embodiments, the UDR node 30 may optionally comprise a memory 34. The memory 34 of the UDR node 30 can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory 34 of the UDR node 30 may comprise a non-transitory media. Examples of the memory 34 of the UDR node 30 include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital versatile disk (DVD), and / or any other memory.

[0088] The processing circuitry 32 of the UDR node 30 can be communicatively coupled (e.g. connected) to the memory 34 of the UDR node 30. In some embodiments, the memory 34 of the UDR node 30 may be for storing program code or instructions which, when executed by the processing circuitry 32 of the UDR node 30, cause the UDR node 30 to operate in the manner described herein in respect of the UDR node 30. For example, in some embodiments, the memory 34 of the UDR node 30 may be configured to store program code or instructions that can be executed by the processing circuitry 32 of the UDR node 30 to cause the UDR node 30 to operate in accordance with the method described herein in respect of the UDR node 30. Alternatively or in addition, the memory 34 of the UDR node 30 can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry 32 of the UDR node 30 may be configured to control the memory 34 of the UDR node 30 to store any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0089] In some embodiments, as illustrated in Figure 6, the UDR node 30 may optionally comprise a communications interface 36. The communications interface 36 of the UDR node 30 can be communicatively coupled (e.g. connected) to the processing circuitry 32 of the UDR node 30 and / or the memory 34 of the UDR node 30. The communications interface 36 of the UDR node 30 may be operable to allow the processing circuitry 32 of the UDR node 30 to communicate with the memory 34 of the UDR node 30 and / or vice versa. Similarly, the communications interface 36 of the UDR node 30 may be operable to allow the processing circuitry 32 of the UDR node 30 to communicate with any one or more nodes (e.g. the UDM node 10 referred to herein, and / or the NRF node 20 referred to herein) referred to herein and / or any other node. The communications interface 36 of the UDR node 30 can be configured to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry 32 of the UDR node 30 may be configured to control the communications interface 36 of the UDR node 30 to transmit and / or receive any of the information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0090] Although the UDR node 30 is illustrated in Figure 6 as comprising a single memory 34, it will be appreciated that the UDR node 30 may comprise at least one memory (i.e. a single memory or a plurality of memories) 34 that operate in the manner described herein. Similarly, although the UDR node 30 is illustrated in Figure 6 as comprising a single communications interface 36, it will be appreciated that the UDR node 30 may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interfaces) 36 that operate in the manner described herein. It will also be appreciated that Figure 6 only shows the components required to illustrate an embodiment of the UDR node 30 and, in practical implementations, the UDR node 30 may comprise additional or alternative components to those shown.

[0091] Figure 7 illustrates a method performed by the UDR node 30 of a network in accordance with an embodiment. The method is for handling data change events in a network. The UDR node 30 described earlier with reference to Figure 6 can be configured to operate in accordance with the method of Figure 7. The method can be performed by or under the control of the processing circuitry 32 of the UDR node 30 according to some embodiments.

[0092] With reference to Figure 7, as illustrated at block 402, in response to obtaining, from one or more NF nodes of the network, one or more respective first subscriptions, it is determined that at least one UDM node of the network is to be notified of the one or more respective first subscriptions. A first subscription is a subscription to be notified of a data change event occurring at any wireless device of a plurality of wireless devices of the network. The determination is based on first information comprised in a NF profile of the at least one UDM node. The first information is indicative of a first subscription to the UDR node 30. The data change event and the plurality of wireless devices can be as described herein. In some examples, the at least one UDM node may comprise the UDM node 10 as defined herein.

[0093] Although not illustrated in Figure 7, in some examples, the method may comprise initiating transmission of second information towards the at least one UDM node. The second information can be indicative of the one or more NF nodes of the network associated with the respective one or more first subscriptions. In some examples, initiating transmission of the second information may comprise initiating transmission of a HTTP POST message comprising the second information.

[0094] In some examples, determining that the at least one UDM node is to be notified of the one or more respective first subscriptions may comprise identifying the at least one UDM node from one or more UDM nodes based on one or more respective NF profiles of the one or more UDM nodes. Thus, in some examples, the UDR node 30 may obtain NF profile information (e.g. from the NRF node 20 referred to herein) of the one or more UDM nodes.

[0095] Although not illustrated in Figure 7, in some examples, the method may comprise obtaining the first information from the NRF node 20. In some examples, obtaining the first information from the NRF node 20 may comprise receiving the first information from the NRF node 20, as described herein. In some examples, although also not illustrated in Figure 7, the method may comprise initiating transmission of a second request towards the NRF node 20. The second request can be a request to be notified of UDM node NF profile changes. Thus, in some examples, the UDR node 30 can subscribe to be notified of NF profile changes (e.g. of any UDM node) at the NRF node 20.

[0096] In some examples, the method may comprise determining that the data change event has occurred at a first wireless device. For example, determining that the data change event has occurred at the first wireless device may comprise obtaining information indicative that the data change event has occurred at the first wireless device. Obtaining the information indicative that the data change event has occurred in the network may comprise receiving, from a first UDM node (e.g. the UDM node 10 referred to herein, and / or another UDM node of the network), the information indicative that the data change event has occurred in the network.

[0097] In some examples, the data change event referred to herein may be any data change event which may be monitored for any (e.g. all) of the plurality of wireless devices mentioned herein. For example, the data change event may comprise one or more of a software version change, an IMEI change, an IMEISV change, and a roaming status change. Thus, in a particular example, the data change event may comprise an IMEISV change occurring at any wireless device of the plurality of wireless devices referred to herein. As mentioned herein, the network referred to herein may be a telecommunications network. In some examples, the network referred to herein may be a PLMN.

[0098] Therefore, in the manner described above, there is provided improved techniques for handling data change events in a network. Indeed, the improved techniques define a new procedure to allow a UDM node 10 of a network to become stateful (e.g. non data- less), such that the UDM node 10 can be aware of subscriptions to notifications for any wireless device (e.g. UE). In general, the improved techniques can be applied to (e.g. PLMN-wide) data which does not necessarily need to be retrieved from a UDR every time a change event occurs at a wireless device.

[0099] The procedure allows a UDM node 10 to register in an NRF node 20, as part of the NF profile of the UDM node 10, a subscription to be notified every time there is a new (e.g. PLMN-wide) data stored in a UDR node 30. The subscription instructs the UDR node 30 (e.g. when storing data associated with a data change event) to notify all UDM nodes which have subscribed to be notified of such (e.g. PLMN-wide) data. Hence, UDM nodes are able to hold a replica (e.g. in a cache) of such data. In this way, a UDM node 10 can locally check the data previously received from a UDR node 30, instead of retrieving it from the UDR node 30 every time a change event occurs.

[0100] Figure 8 is a signalling diagram illustrating an exchange of signals in a system (e.g. a network) according to an embodiment. As illustrated in Figure 8, the system can comprise a first UDM node 10a (”UDM-1”) and a second UDM node 10b (“UDM-2”). The first UDM node 10a and / or the second UDM node 10b can be configured to operate as the UDM node 10 described herein (e.g. with reference to Figure 2 and / or Figure 3). As also illustrated in Figure 8, the system can comprise an NRF node 20 and a UDR node 30 (“UDR central”). The NRF node 20 can be configured to operate as described herein (e.g. with reference to Figure 4 and / or Figure 5). The UDR node 30 can be configured to operate as described herein (e.g. with reference to Figure 6 and / or Figure 7).

[0101] As illustrated by block 510 of Figure 8, the first UDM node 10a can initiate a registration procedure in order to register an NF profile of the first UDM node 10a at the NRF node 20.

[0102] As illustrated by arrow 512 of Figure 8, the first UDM node 10a may initiate transmission of the NF profile of the first UDM node 10a towards the NRF node 20. The transmission initiation of the NF profile of the first UDM node 10a can be as described with reference to Figure 3. Thus, the NRF node 20 receives the NF profile of the first UDM node 10a from the first UDM node 10a. The NF profile of the first UDM node 10a can comprise first information indicative of a first subscription to the UDR node 30. The first subscription is a subscription to be notified of a data change event occurring at any wireless device of a plurality of wireless devices of the network.

[0103] As illustrated by block 514 of Figure 8, the NRF node 20 may store the NF profile of the first UDM node 10a (e.g. in the memory 24 of the NRF node 20). Therefore, the first UDM node 10a is able to register its NF profile in the NRF node 20. As described herein, the first information comprised in the NF profile of the first UDM node 10a may comprise a (e.g. new default notification) URI (e.g. “notification type=ANY_UE_DATA_UPDATE”). The first information comprised in the NF profile of the first UDM node 10a can serve as a (e.g. implicit) subscription towards the UDR node 30 for any (e.g. UE) data change events. As such, the first information can serve as an instruction for the UDR node 30 to notify each UDM node with the first information comprised in its NF profile of any first subscriptions made to the UDR node 30.

[0104] As illustrated by block 516 of Figure 8, the NRF node 20 may notify any NF nodes (e.g. subscribed to UDM NF profile changes) of the (e.g. changes to the) NF profile of the first UDM node 10a. As illustrated by arrow 518 of Figure 8, the NRF node 20 may make the first information available to the UDR node 30. As also illustrated by arrow 518 of Figure 8, making the first information available to the UDR node 30 may comprise initiating transmission of the first information towards the UDR node. In some examples, initiating transmission of the first information towards the UDR node may comprise initiating transmission of a HTTP PUT message (“HTTP POST (UDM-1 Profile update)”) comprising the first information. Although not illustrated in Figure 8, the UDR node 30 may have subscribed, to the NRF node 20, to NF profile changes (e.g. of UDM nodes).

[0105] Thus, the NRF node 20 can notify the UDR node 30 about the NF profile (e.g. update) of the first UDM node 10a. The UDR node 30 can thus be made aware that, if there is any wireless device data (e.g. PLMN-wide data for any UE), it must notify the first UDM node 10a which registered first information at the NRF node 20. The UDR node 30 may notify the first UDM node 10a of any wireless device data which has changed as a result of a data change event. Therefore in some examples, the first subscription may comprise a subscription to be notified of the wireless device data which has changed as a result of a data change event.

[0106] The steps illustrated by arrow 520, block 522, block 524, and arrow 526 of Figure 8 can be as described with reference to the steps illustrated by arrow 512, block 514, block 516, and arrow 518 of Figure 8, with the exception that the second UDM node 10b is performing the UDM node specific parts of the method instead of the first UDM node 10a. Therefore, as illustrated by block 528 of Figure 8, the UDR node 30 can be made aware that both the first UDM node 10a and the second UDM node 10b are to be notified of a data change event as defined herein.

[0107] Figure 9 is a block diagram illustrating an example NF profile of a UDM node 10 according to an embodiment. The first information, as described herein, can be represented by the notification highlighted by the arrow of Figure 9. More specifically, in some examples, the first information can have the form “ANY_UE_DATA_UPDATE”. The NF profile of the UDM node 10 can be configured as follows:

[0108] Notification Type: description: >

[0109] Types of notifications used in Default Notification URIs in the NF Profile of an NF Instance anyOf:

[0110] - type: string enum:

[0111] - N1_MESSAGES

[0112] - N2JNFORMATION

[0113] - LOCATION_NOTIFICATION

[0114] - DATA_REMOVAL_NOTIFICATION

[0115] - DA TA_ CHANG E_NO TIFICA TION

[0116] - LOCATION_UPDATE_NOTIFICATION

[0117] - NSSAA_REAUTH_NOTIFICATION

[0118] - NSSAA_REVOC_NOTIFICATION

[0119] - MATCH_INFO_NOTIFICATION

[0120] - DATA_RESTORATION_NOTIFICATION

[0121] - TSCTS_NOTIFICATION

[0122] - LCS_KEY_DELIVERY_NOTIFICATION - ANY_ UE_DA TA_ UPDA TE

[0123] The first information may be referred to herein as a new notification type (e.g. “ANY_UE_DATA_UPDATE”, and / or “PLMN_WIDE_DATA_UPDATE”) and / or a new notification URI. The first information referred to herein can be defined so that a UDM node 10 (e.g. or any fifth generation core (5GC) network function (NF) type), when registering at a NRF, can indicate that it requires a notification when a data change event occurs (e.g. when a subscription to notifications for IMEISV change is stored for any (e.g. all) wireless devices (e.g. UEs)). The first information can be referred to herein as new business logic. The first information in the NF profile of one or more UDM nodes can serve as a (e.g. implicit) request for the UDR node 30 to send a notification to each of the one or more UDM nodes (e.g. that are interested in receiving data associated with a data change event).

[0124] Figure 10 is a signalling diagram illustrating an exchange of signals in a system (e.g. a network) according to an embodiment. As illustrated in Figure 10, the system can comprise a first UDM node 10a (”UDM-1”) and a second UDM node 10b (“UDM-2”). The first UDM node 10a and the second UDM node 10b can be configured to operate as the UDM node 10 described herein (e.g. with reference to Figure 2 and / or Figure 3). As also illustrated in Figure 10, the system can comprise an NRF node 20 and a UDR node 30 (“UDR central”). The NRF node 20 can be configured to operate as described herein (e.g. with reference to Figure 4 and / or Figure 5). The UDR node 30 can be configured to operate as described herein (e.g. with reference to Figure 6 and / or Figure 7). As illustrated in Figure 10, the system can also comprise a network exposure function (NEF) node 602, an AMF node 610, and a plurality of wireless devices 612, 614, 616 (“UE-1”, “UE-2”, and “UE-3”, respectively). The NEF node 602 and / or the AMF node 610 may be referred to herein as a NF node. In the example illustrated by Figure 10, the plurality of wireless devices 612, 614, 616 comprises three wireless devices. However, it will be understood that this is merely an example, and that the plurality of wireless devices 612, 614, 616 may contain any number of two or more wireless devices according to other examples. The method steps illustrated by Figure 10 may supplement the method steps as described with reference to Figure 8 to achieve the above discussed and additional functionality.

[0125] As illustrated by block 618 of Figure 10, the first UDM node 10a may receive a first request for a first subscription, as described herein, from the NEF node 602. In some examples, although not illustrated in Figure 10, the NEF node 602 may receive the first request for the first subscription from an application function (AF) of the network. As illustrated by arrow 620 of Figure 10, receiving the first request from the NEF node 602 may comprise receiving a message (e.g. “HTTP POST (any UE) Even=IMEISV change”) from the NEF node 602 comprising the first request for the first subscription. As such, the NEF node 602 can subscribe to the data change event towards the first UDM node 10a. In the example illustrated by Figure 10, the data change event comprises a IMEISV change. However, it will be appreciated that this is merely an example, and that the data change event may comprise any data change event.

[0126] As illustrated by arrow 622 of Figure 10, the first UDM node 10a may initiate transmission of the first request towards the UDR node 30. Thus, the UDR node 30 can receive the first request from the first UDM node 10a. As also illustrated by arrow 622 of Figure 10, initiating transmission of the first request towards the UDR node 30 may comprise initiating transmission of an HTTP message (e.g. “HTTP POST (any UE) Event=IMEISV change”) comprising the first request. As illustrated by block 624 of Figure 10, the UDR node 30 may store the first request for the first subscription (e.g. in the memory 34 of the UDR node 30). Therefore, the first UDM node 10a is able to store the first subscription in the UDR node 30.

[0127] As illustrated by block 626 of Figure 10, in response to obtaining, from one or more NF nodes (e.g. the NEF node 602 of Figure 10) one or more respective first subscriptions (e.g. the first subscription comprised in the first request received from the first UDM node 10a) the UDR node 30 determines at least one UDM node is to be notified of the one or more respective first subscriptions. The determination is based on first information comprised in a NF profile of the at least one UDM node. The first information is indicative of a first subscription, as defined herein, to the UDR node 30.

[0128] Therefore, in some examples, the UDR node 30 can determine whether it has obtained first information from a NF profile of any UDM nodes of the network. As described herein, the first information is indicative of a first subscription to the UDR node 30, and the first subscription is a subscription to be notified of the data change event (e.g. IMEISV change) occurring at any wireless device of the plurality of wireless devices of the network. In some examples, the UDR node 30 may check all UDM node NF profiles obtained (e.g. and cached) from the NRF node 20 to see if there are any NF profiles which comprise the first information as defined herein. For example, for each NF profile that is available to the UDR node 30, the UDR node 30 may determine (e.g. check) whether the corresponding UDM node needs to be notified based on whether the first information (e.g. “ANY_UE_DATA_UPDATE” notification) is comprised in the NF profile.

[0129] As illustrated by block 628 of Figure 10, the UDR node 30 may determine that the at least one UDM node is to be notified of the one or more respective first subscriptions (e.g. the first subscription comprised in the first request received from the first UDM node 10a). As mentioned herein, the method steps illustrated by Figure 10 may supplement the method as described with reference to Figure 8. As such, in some examples, the UDM node 10 may determine that the at least one UDM node to be notified of the one or more respective first subscriptions comprises the first UDM node 10a and the second UDM node 10b.

[0130] As illustrated by arrow 630 of Figure 10, the UDR node 30 may initiate transmission of second information towards the first UDM node 10a. Thus, the first UDM node 10a can receive the second information from the UDR node 30. The first UDM node 10a can store the second information (e.g. in a cache). The second information can be indicative of the one or more NF nodes of the network associated with the respective one or more first subscriptions. In the example illustrated in Figure 10, the second information is indicative of the NEF node 602 since the NEF node 602 has made a first subscription to the UDR node 30 (as described with reference to block 618 and arrows 620 and 622 of Figure 10). Herein, the second information may be indicative of an identifier (ID) of the one or more NF nodes of the network (e.g. the NEF node 602).

[0131] As illustrated by arrow 632 of Figure 10, the UDR node 30 may initiate transmission of the second information, as defined herein, towards the second UDM node 10b. Thus, the second UDM node 10b can receive the second information from the UDR node 30. The second UDM node 10b can store the second information (e.g. in a cache).

[0132] Therefore, the UDR node 30 can notify all UDM nodes of any first subscription made to the UDR node 30. In some examples, the second information may also comprise information of one or more wireless devices of the plurality of wireless devices. For example, the second information may comprise updated wireless device (e.g. UE) information (e.g. data). As illustrated by block 634 of Figure 10, as a result of the receipt of the second information as described herein, the first UDM node 10a and the second UDM node 10 can be made aware that, if there is a data change even detected, they need to notify the one or more NF nodes (e.g. the NEF node 602) of the network about the data change event.

[0133] Figure 11 is a signalling diagram illustrating an exchange of signals in a system (e.g. a network) according to an embodiment. The system illustrated in Figure 11 can be as described with reference to the system of Figure 10. The method steps illustrated by Figure 11 may supplement the methods steps as described with reference to Figure 8 and / or Figure 10 to achieve the above discussed and additional functionality.

[0134] As illustrated by block 704 of Figure 11 , a change event can occur at a first wireless device 612 of the plurality of wireless devices 612, 614, 616. As illustrated in Figure 11 , in some examples, the data change event may comprise a subscriber identity module (SIM) being configured for (e.g. inserted into) the first wireless device 612 (e.g. a smartphone). Therefore, in some examples, and as illustrated in Figure 11 , the data change event may comprise an IMEISV change.

[0135] As illustrated by arrow 706 of Figure 11 , the first UDM node 10a may obtain third information indicative that the data change event has occurred at the first wireless device 612 of the plurality of wireless devices 612, 614, 616. As illustrated in Figure 11 , in some examples, obtaining the third information may comprise obtaining an HTTP PUT message comprising the third information. As also illustrated by arrow 706 of Figure 11 , the first UDM node 10a may receive the third information from the AM F node 610. Thus, in some examples, the AMF node 610 can inform the first UDM node 10a of the data change event (e.g. IMEISV change associated with an IMSI / SUPI).

[0136] As illustrated by block 708 of Figure 11 , the first UDM node 10a can determine that the data change event has occurred at the first wireless device 612 based on the third information. As mentioned herein, the method steps illustrated by Figure 11 may supplement the method as described with reference to Figures 8 and / or 10. As such, in some examples, the first UDM node 10a may identify, based on the second information (e.g. received by the first UDM node 10a as described with reference to arrow 630 of Figure 10), one or more NF nodes to which to initiate transmission of the third information. Therefore, instead of retrieving any subscription information from the UDR node 30, the first UDM node 10a can identify the one or more NF nodes based on previously obtained (e.g. and stored) second information (e.g. stored in a local cache of the first UDM node 10a).

[0137] In the example as illustrated by Figures 10 and 11 , the one or more NF nodes comprise the NEF node 602. Thus, in some examples, as illustrated by block 710 of Figure 11 , the first UDM node 10a identifying as the one or more NF nodes based on the second information may comprise identifying the NEF node 602. As illustrated by arrow 712 of Figure 11 , the first UDM node 10a may initiate transmission of the third information towards the one or more NF nodes (e.g. the NEF node 602 in the example illustrated in Figure 11). The one or more NF nodes can thus receive the third information from the first UDM node 10a. Therefore, as the first UDM node 10a has been made aware of a first subscription for the NEF node 602, the first UDM node 10a can notify the NEF node 602 accordingly.

[0138] As illustrated by block 714 of Figure 11 , a change event can occur at a second wireless device 614 of the plurality of wireless devices 612, 614, 616, as referred to herein. The second wireless device 614 may be a first wireless device, as referred to herein. As illustrated in Figure 11 , in some examples, the data change event may comprise a software version (e.g. iOS update) change.

[0139] As illustrated by arrow 716 of Figure 11 , the second UDM node 10b may obtain third information indicative that the data change event has occurred at the second wireless device 614 of the plurality of wireless devices 612, 614, 616. As illustrated in Figure 11 , in some examples, obtaining the third information may comprise obtaining an HTTP PUT message comprising the third information. As also illustrated by arrow 716 of Figure 11 , the second UDM node 10b may receive the third information from the AMF node 610. Thus, in some examples, the AMF node 610 can inform the second UDM node 10b of the data change event (e.g. software version change).

[0140] As illustrated by block 718 of Figure 11 , the second UDM node 10b can determine that the data change event has occurred at the second wireless device 614 based on the third information. As mentioned herein, the method steps illustrated by Figure 11 may supplement the method as described with reference to Figures 8 and / or 10. As such, in some examples, the second UDM node 10b may identify, based on the second information (e.g. received by the second UDM node 10b as described with reference to arrow 632 of Figure 10), one or more NF nodes to which to initiate transmission of the third information. Therefore, instead of retrieving any subscription information from the UDR node 30, the second UDM node 10b can identify the one or more NF nodes based on previously obtained (e.g. and stored) second information (e.g. stored in a local cache of the second UDM node 10b).

[0141] In the example as illustrated by Figures 10 and 11 , the one or more NF nodes comprise the NEF node 602. Thus, in some examples, as illustrated by block 720 of Figure 11 , the second UDM node 10b may identify the NEF node 602 based on the second information. As illustrated by arrow 722 of Figure 11 , the second UDM node 10b may initiate transmission of the third information towards the one or more NF nodes (e.g. the NEF node 602 in the example illustrated in Figure 11). The one or more NF nodes can thus receive the third information from the second UDM node 10b. Therefore, as the second UDM node 10b has been made aware of a first subscription for the NEF node 602, the second UDM node 10b can notify the NEF node 602 accordingly.

[0142] In the method illustrated by Figure 11 , no traffic is required to be sent to the UDR node 30 in order to inform the one or more NF nodes of the data event change regardless of the number of wireless devices at which the data change event occurs.

[0143] There is also provided a computer program comprising instructions which, when executed by processing circuitry (such as the processing circuitry 12 of the UDM node 10 described herein, the processing circuitry 22 of the NRF node 20 described herein, and / or the processing circuitry 32 of the UDR node 30 described herein), cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry (such as the processing circuitry 12 of the UDM node 10 described herein, the processing circuitry 22 of the NRF node 20 described herein, and / or the processing circuitry 32 of the UDR node 30 described herein) to cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product comprising a carrier containing instructions for causing processing circuitry (such as the processing circuitry 12 of the UDM node 10 described herein, the processing circuitry 22 of the NRF node 20 described herein, and / or the processing circuitry 32 of the UDR node 30 described herein) to perform at least part of the method described herein. In some embodiments, the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable storage medium.

[0144] In some embodiments, the UDM node functionality described herein, the NRF node functionality described herein, and / or the UDR node functionality described herein can be performed by hardware. Thus, in some embodiments, the UDM node 10, the NRF node 20, and / or the UDR node 30 described herein can be a hardware entity. However, it will also be understood that optionally at least part or all of the UDM node functionality described herein, the NRF node functionality described herein, and / or the UDR node functionality described herein can be virtualised. For example, the functions performed by the UDM node 10, the NRF node 20, and / or the UDR node 30 described herein can be implemented in software running on generic hardware that is configured to orchestrate the UDM node functionality described herein, the NRF node functionality described herein, and / or the UDR node functionality described herein. Thus, in some embodiments, the UDM node 10, the NRF node 20, and / or the UDR node 30 described herein can be a virtual node. In some embodiments, at least part or all of the UDM node functionality described herein, the NRF node functionality described herein, and / or the UDR node functionality described herein may be performed in a network enabled cloud. Thus, the method described herein can be realised as a cloud implementation according to some embodiments. The UDM node functionality described herein, the NRF node functionality described herein, and / or the UDR node functionality described herein may all be at the same location or at least some of the UDM node functionality described herein, the NRF node functionality described herein, and / or the UDR node functionality may be distributed, e.g. the UDM node functionality described herein, the NRF node functionality described herein, and / or the UDR node functionality may be performed by one or more different nodes.

[0145] Therefore, as described herein, there are provided improved techniques for handling data change events in a network. The techniques enable a reduction in the number of transactions per second (TPS) between the UDM node 10 and the UDR node 30 (e.g. to zero), since the UDM node 10 can obtain and store (e.g. hold a replica of) first subscription information stored at the UDR node 30. In this way, the improved techniques enable both network resource and energy consumption to be reduced.

[0146] The improved techniques are also advantageous as the techniques and dimensioning are 100% scalable, since no additional compute resources are required in the UDM node 10 or the UDR node 30 when the number of data change events grow. For example, application functions which trigger the first subscription requests do not have any effect on computing for the UDM node 10 or the UDR node 30.

[0147] Moreover, the improved techniques are less prone to signaling storms and overload than existing techniques (e.g. as described with reference to Figure 1). That is, if a data change event is massively detected for many wireless devise (e.g. UEs) in the network (e.g. PLMN), no extra traffic is sent to the UDR node 30, since the UDM node 10 already has the necessary info to notify all relevant NFs of the network. As such, compute resources can be safely dimensioned without taking into account massive event detection in many cases, since the UDR node 30 is not receiving as much (e.g. any) traffic associated with subscriptions applicable to any wireless device.

[0148] Furthermore, latency is improved by way of the improved techniques described herein, no matter whether the UDR node hosting wireless device (e.g. UE) data is co-located with the UDR node hosting wireless device (e.g. UE) contexts. In particular, if a central UDR node is deployed, the latency improvements are even higher.

[0149] The techniques described herein are also future proof since they can be applied to any data change event which can be applied to any wireless device of a plurality of wireless devices. As such, data change events which may be detected very frequently in (e.g. 5GC) networks, for example with millions of devices, do not result in traffic towards the UDR node 30 to (e.g. constantly) read subscription to notifications information. Furthermore, the techniques described herein can be extended to different types of (e.g. 5GC PLMN-wide) data, such as shared user data. Such data is currently stored in a UDR and common to many wireless devices (e.g. UES). The techniques described herein provide for defining new notification types for new (e.g. PLMN-wide) data which can be persistently stored in the UDR node 30 and stored (e.g. cached) in the UDM node 10. Moreover, the techniques described herein can be reused for other (e.g. 5GC) data such as policy data in the UDR node 30 (e.g. user equipment routing selection policy (URSP) rules applicable to any UE).

[0150] Figure 12 is a block diagram illustrating a virtualization environment 1200 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1200 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 1200 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface.

[0151] Applications 1202 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0152] Hardware 1204 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1206 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1208a and 1208b (one or more of which may be generally referred to as VMs 1208), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1206 may present a virtual operating platform that appears like networking hardware to the VMs 1208.

[0153] The VMs 1208 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1206. Different embodiments of the instance of a virtual appliance 1202 may be implemented on one or more of VMs 1208, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment. In the context of NFV, a VM 1208 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1208, and that part of hardware 1204 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1208 on top of the hardware 1204 and corresponds to the application 1202.

[0154] Hardware 1204 may be implemented in a standalone network node with generic or specific components. Hardware 1204 may implement some functions via virtualization. Alternatively, hardware 1204 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1210, which, among others, oversees lifecycle management of applications 1202. In some embodiments, hardware 1204 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1212 which may alternatively be used for communication between hardware nodes and radio units.

[0155] It should be noted that the above-mentioned embodiments illustrate rather than limit the idea, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended embodiments. The word “comprising” does not exclude the presence of elements or steps other than those listed in an embodiment, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the embodiments. Any reference signs in the embodiments shall not be construed so as to limit their scope.

Claims

CLAIMS1 . A method for handling data change events in a network, wherein the method is performed by a user data management, UDM, node (10, 10a, 10b) of the network, the method comprising: initiating (202, 512, 520) transmission of a network function, NF, profile of the UDM node (10, 10a, 10b) towards a network repository function, NRF, node of the network, wherein the NF profile comprises first information indicative of a first subscription to a user data repository, UDR, node (30) of the network, and wherein the first subscription is a subscription to be notified of a data change event occurring at any wireless device of a plurality of wireless devices (612, 614, 616) of the network.

2. The method of claim 1 , the method comprising: obtaining (630, 632), from the UDR node (30), second information indicative of one or more first subscriptions to the UDR node (30), wherein the second information is indicative of one or more network function, NF, nodes (602) of the network associated with the respective one or more first subscriptions.

3. The method of claim 1 or 2, wherein the second information is received in response to initiating (202, 512, 520) transmission of the NF profile.

4. The method of any of the preceding claims, the method comprising: storing the second information in a memory of the UDM node (10, 10a, 10b).

5. The method of any of claims 2 to 4, the method comprising: obtaining (706, 716) third information indicative that the data change event has occurred at a first wireless device of the plurality of wireless devices (612, 614, 616); and identifying, based on the second information, the one or more NF nodes (602) to which to initiate transmission of the third information.

6. The method of claim 5, the method comprising: initiating (712, 722) transmission of the third information towards the one or more NF nodes (602).

7. The method of claim 5 or 6, wherein obtaining (706, 716) the third information comprises: receiving the third information from a second NF node (610) of the network.

8. The method of claim 7, wherein the second NF node (610) is an access and mobility management function, AMF, node of the network.

9. The method of any of the preceding claims, the method comprising: receiving a first request for the first subscription from a first NF node of the network; and initiating (202, 512, 520) transmission of the NF profile in response to receiving the first request.

10. The method of any of the preceding claims, wherein the first information comprises a uniform resource identifier.

11. The method of any of the preceding claims, wherein initiating (202, 512, 520) transmission of the NF profile comprises initiating transmission of: a registration message comprising the NF profile; or an update message comprising the NF profile.

12. The method of any of the preceding claims, wherein initiating transmission (202, 512, 520) of the NF profile comprises: initiating transmission of a hypertext transfer protocol, HTTP, PUT message comprising the NF profile.

13. The method of any of the preceding claims, wherein the data change event comprises one or more of: a software version change; an international mobile equipment identity, IMEI, change; an international mobile equipment identity software version, IMEISV, change; and a roaming status change.

14. The method of any of the preceding claims, wherein the network is a telecommunications network.

15. The method of any of the preceding claims, wherein the network is a public land mobile network, PLMN.

16. A method for handling data change events in a network, wherein the method is performed by a network repository function, NRF, node (20) of the network, the method comprising: receiving (302, 512, 520), from a user data management node (10, 10a, 10b) of the network, a network function, NF, profile of the UDM node (10, 10a, 10b), wherein the NF profile comprises first information indicative of a first subscription to a user data repository, UDR, node (30) of the network, and wherein the first subscription is a subscription to be notified of a data change event occurring at any wireless device of a plurality of wireless devices (612, 614, 616) of the network.

17. The method of claim 16, the method comprising: storing the NF profile at the NRF node (20).

18. The method of claim 17, wherein storing the NF profile at the NRF node (20) comprises: updating an NF profile of the UDM node (10, 10a, 10b) previously stored at the NRF node (20).

19. The method of any of claims 16 to 18, the method comprising: making the first information available to the UDR node (30).

20. The method of claim 19, wherein making the first information available to the UDR node (30) comprises: initiating (518, 526) transmission of the first information towards the UDR node (30).21 . The method of claim 20, wherein initiating (518, 526) transmission of the first information towards the UDR node (30) comprises: initiating transmission of a hypertext transfer protocol, HTTP, PUT message comprising the first information.

22. The method of any of claims 16 to 21 , the method comprising:receiving a second request from the UDR node (30), wherein the second request is a request to be notified of UDM node NF profile changes.

23. The method of any of claims 16 to 22, wherein the first information comprises a uniform resource identifier.

24. The method of any of claims 16 to 23, wherein the data change event comprises one or more of: a software version change; an international mobile equipment identity, IMEI, change; an international mobile equipment identity software version, IMEISV, change; and a roaming status change.

25. The method of any of claims 16 to 24, wherein the network is a telecommunications network.

26. The method of any of claims 16 to 25, wherein the network is a public land mobile network, PLMN.

27. A method for handling data change events in a network, wherein the method is performed by a user data repository, UDR, node (30) of the network, the method comprising: in response to obtaining, from one or more network function, NF, nodes of the network, one or more respective first subscriptions, wherein a first subscription is a subscription to be notified of a data change event occurring at any wireless device of a plurality of wireless devices (612, 614, 616) of the network: determining (402), based on first information comprised in a NF profile of at least one user data management, UDM, node of the network, that the at least one UDM node is to be notified of the one or more respective first subscriptions, wherein the first information is indicative of a first subscription to the UDR node (30).

28. The method of claim 27, the method comprising: initiating (630, 632) transmission of second information towards the at least one UDM node, wherein the second information is indicative of the one or more NF nodes of the network associated with the respective one or more first subscriptions.

29. The method of claim 28, wherein initiating (630, 632) transmission of the second information comprises: initiating transmission of a hypertext transfer protocol, HTTP, POST message comprising the second information.

30. The method of any of claims 27 to 29, wherein determining that the at least one UDM node is to be notified of the one or more respective first subscriptions comprises: identifying the at least one UDM node from one or more UDM nodes based on one or more respective NF profiles of the one or more UDM nodes.31 . The method of any of claims 27 to 30, the method comprising: obtaining (526) the first information from the NRF node (20).

32. The method of claim 31 , wherein obtaining (526) the first information from the NRF node (20) comprises: receiving the first information from the NRF node (20).

33. The method of any of claims 27 to 32, the method comprising: initiating transmission of a second request towards the NRF node (20), wherein the second request is a request to be notified of UDM node NF profile changes.

34. The method of any of claims 27 to 33, the method comprising: determining that the data change event has occurred at a first wireless device.

35. The method of claim 34, wherein determining that the data change event has occurred at the first wireless device comprises: obtaining information indicative that the data change event has occurred at the first wireless device.

36. The method of claim 35, wherein obtaining the information indicative that the data change event has occurred in the network comprises: receiving, from a first UDM node, the information indicative that the data change event has occurred in the network.

37. The method of any of claims 27 to 36, wherein the first information comprises a uniform resource identifier.

38. The method of any of claims 27 to 37, wherein the data change event comprises one or more of: a software version change; an international mobile equipment identity, IMEI, change; an international mobile equipment identity software version, IMEISV, change; and a roaming status change.

39. The method of any of claims 27 to 38, wherein the network is a telecommunications network.

40. The method of any of claims 27 to 39, wherein the network is a public land mobile network, PLMN.41 . A method performed by a system, the method comprising: the method of any of claims 1 to 15; the method of any of claims 16 to 26; and / or the method of any of claims 27 to 40.

42. A user data management, UDM, node (10, 10a, 10b) comprising: processing circuitry (12) configured to operate in accordance with any of claims 1 to 15.

43. A UDM node (10, 10a, 10b) of claim 42, wherein: the UDM node (10, 10a, 10b) comprises: at least one memory (14) for storing instructions which, when executed by the processing circuitry (12), cause the UDM node (10, 10a, 10b) to operate in accordance with any of claims 1 to 15.

44. A network repository function, NRF, node (20) comprising: processing circuitry (22) configured to operate in accordance with any of claims 16 to 26.

45. A NRF node (20) of claim 44, wherein: the NRF node (20) comprises:at least one memory (24) for storing instructions which, when executed by the processing circuitry (22), cause the NRF node (20) to operate in accordance with any of claims 16 to 26.

46. A user data repository, UDR, node (30) comprising: processing circuitry (32) configured to operate in accordance with any of claims 27 to 40.

47. A UDR node (30) of claim 46, wherein: the UDR node (30) comprises: at least one memory (34) for storing instructions which, when executed by the processing circuitry (32), cause the UDR node (30) to operate in accordance with any of claims 27 to 40.

48. A system comprising any two or more of: at least one UDM node (10, 10a, 10b) of claim 1 to 15; at least one NRF node (20) of claim 16 to 26; and at least one UDR node (30) of claim 27 to 40.

49. A computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method according to any of claims 1 to 15, any of claims 16 to 26, and / or any of claims 27 to 40.

50. A computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform the method according to any of claims 1 to 15, any of claims 16 to 26, and / or any of claims 27 to 40.

Images