Method and apparatus for synchronizing data in networks and functions

Abstract

[0005] Embodiments described herein relate to a method and apparatus for synchronizing data at a second network function, the method at a first network function including receiving an indication of a potential registration data inconsistency associated with one or more wireless devices from the second network function, receiving a registration request for the first wireless device from a third network function, the registration request including a first indication indicating that a reason for the registration request is a potential data inconsistency, and updating registration data at the second network function in response to receiving the registration request.

Description

[Technical field]

[0001] The embodiments described herein relate to methods and apparatus for synchronizing data in a second network function, eg, a unified data repository. [Background technology]

[0002] Generally, all terms used herein should be interpreted according to the ordinary meaning of those terms in the relevant technical field, unless a different meaning is expressly given and / or implied from the context in which the term is used. All references to a / an / the element, apparatus, component, means, step, etc. should be openly interpreted as referring to at least one instance of that element, apparatus, component, means, step, etc., unless expressly stated otherwise. The steps of any method disclosed herein need not be performed in the exact order disclosed, unless a step is expressly described as following or preceding another step, and / or 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. Similarly, any advantage of any of the embodiments may be applied to any other embodiment, and vice versa. Other objectives, features, and advantages of the enclosed embodiments will become apparent from the following description.

[0003] In a core network (e.g., a 5G core network implemented as a service-based architecture), there may be several scenarios in which data in the Unified Data Repository (UDR) is partially or completely lost or must be retrieved from a previous backup. In these scenarios, the data in the UDR may not be fully consistent with the data stored and / or used by network function consumers of this data (e.g., the Network Publishing Function (NEF), Session Management Function (SMF), Policy Charging and Control Function (PCF), and Access and Mobility Management Function (AMF), etc.).

[0004] Different solutions are currently proposed to restore consistency across consumer NFs and UDRs, allowing NF consumers to regenerate and / or restore their data again, if possible. Summary of the Invention

[0005] According to some embodiments, a method is provided in a first network function for synchronizing data at a second network function, the method including receiving from the second network function an indication of a potential registration data inconsistency associated with one or more wireless devices, receiving from a third network function a registration request for the first wireless device, the registration request including a first indication indicating that a reason for the registration request is a potential data inconsistency, and updating registration data at the second network function in response to receiving the registration request.

[0006] According to some embodiments, a method is provided in a third network function for synchronizing data at a second network function, the method including receiving, from a first network function, a notification of a potential registration data inconsistency for one or more wireless devices, and in response to receiving a registration update from a first wireless device of the one or more wireless devices, sending to the first network function a registration request for the first wireless device, the registration request including a first indication indicating that a reason for the registration request is a potential registration data inconsistency.

[0007] According to some embodiments, a method is provided in a fourth network function for synchronizing data in a second network function, the method including receiving a notification of a potential registration data inconsistency for one or more wireless devices.

[0008] According to some embodiments, there is provided a method in a second network function for synchronizing data at the second network function, the method including obtaining, from a fifth network function, an indication of one or more first network functions associated with a potential inconsistent registration data notification type at the fifth network function.

[0009] According to some embodiments, a first network function is provided for synchronizing data at a second network function, the first network function comprising processing circuitry configured to cause the first network function to receive, from the second network function, an indication of a potential registration data inconsistency associated with one or more wireless devices.

[0010] According to some embodiments, a third network function is provided for synchronizing data at the second network function, the third network function comprising processing circuitry configured to cause the third network function to receive notification of a potential registration data inconsistency for one or more wireless devices from the first network function.

[0011] According to some embodiments, a fourth network function is provided for synchronizing data at the second network function, the fourth network function comprising processing circuitry configured to cause the fourth network function to receive notification of a potential registration data inconsistency for one or more wireless devices.

[0012] According to some embodiments, a second network function for synchronizing data at the second network function is provided, the second network function comprising processing circuitry configured to cause the second network function to obtain, from a fifth network function, an indication of one or more first network functions associated with a potential inconsistent registration data notification type at the fifth network function.

[0013] For a better understanding of embodiments of the present disclosure and to show how the same may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Brief description of the drawings]

[0014] [Figure 1] A diagram showing a method in a first network function for synchronizing data in a second network function. [Diagram 2] A diagram showing a method in a third network function for synchronizing data in a second network function. [Diagram 3]A diagram showing a method in a fourth network function for synchronizing data in a second network function. [Figure 4] A diagram showing a method in a second network function for synchronizing data in the second network function. [Figure 5(a)-5(c)] FIG. 5 illustrates an exemplary implementation of the method of FIGS. 1-4. [Figure 6] FIG. 2 illustrates a first network function comprising processing circuitry (or logic). [Figure 7] FIG. 2 illustrates a third network function comprising processing circuitry (or logic). [Figure 8] FIG. 4 illustrates a fourth network function comprising processing circuitry (or logic). [Figure 9] FIG. 2 illustrates a second network function comprising processing circuitry (or logic). [Figure 10] FIG. 1 illustrates a networked system in accordance with certain embodiments of the solutions described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Exemplary embodiments described herein occur in the context of a telecommunications network, also referred to as a communications network in this disclosure, including, but not limited to, a telecommunications network conforming to and / or possibly incorporating aspects of a fifth generation (5G) architecture. FIG. 10 is an exemplary networked system 100, according to an exemplary embodiment of the present disclosure. In particular, FIG. 10 illustrates a user equipment (UE) 101, which may be in communication with a (radio) access network (RAN) 102, as well as an access and mobility management function (AMF) 106, and a user plane function (UPF) 103. The AMF 106 may be in communication with core network services, including a session management function (SMF) 107 and a policy control function (PCF) 111. The core network services may also be in communication with an application server / application function (AS / AF) 113. Other networked services also include a network slice selection function (NSSF) 108, an authentication server function (AUSF) 105, a user data management (UDM) 112, a network publishing function (NEF) 109, a network repository function (NRF) 110, a user data repository (UDR) 114, a network data analysis function (NWDAF) 115, and a data network (DN) 104. In some exemplary implementations of the present disclosure, the AMF 106, the SMF 107, the UPF 103, the PCF 111, the AUSF 105, the NRF 110, the UDM 112, the NEF 109, the AF 113, the UDR 114, the NWDAF 115, and the NSSF 108 are each considered to be an NF. One or more additional instances of a network function (NF) may be incorporated into the networked system.

[0016] The following describes specific details, such as specific embodiments or examples, for purposes of explanation and not limitation. It will be appreciated by those skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not to obscure the description with unnecessary details. It will be appreciated by those skilled in the art that the described functions may be implemented in one or more nodes using hardware circuits (e.g., analog and / or discrete logic gates interconnected to perform specialized functions, ASICs, PLAs, etc.) and / or using software programs and data with one or more digital microprocessors or general-purpose computers. Also, nodes that communicate using an air interface have suitable wireless communication circuitry. Moreover, where appropriate, the present technology may be considered to be fully embodied in any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk, that additionally contains a suitable set of computer instructions that will cause a processor to perform the techniques described herein.

[0017] A hardware implementation may include or encompass hardware (e.g., digital or analog) circuitry, including, but not limited to, digital signal processor (DSP) hardware, reduced instruction set processors, and application specific integrated circuit (ASIC)(s) and / or field programmable gate array (FPGA)(s), and (where appropriate) state machines capable of performing such functionality.

[0018] Currently, there is no solution to the above-mentioned problem.

[0019] For example, if registration data for a particular wireless device stored in the UDR is lost, it may be useful for the AMF to perform a new registration related to the wireless device in the UDM, so that the registration data for the wireless device is restored and / or updated in the UDR and aligned with the actual registration context of the wireless device.

[0020] Some embodiments described herein focus on issues related to the NEF(s) (it will be appreciated that this is also applicable to the Service Capability Exposure Function (SCEF) in 4G). Currently, the NEF is not provided with any information or indication when certain data may be corrupted or inconsistent in the UDR and therefore that the UDR data may need to be regenerated (if possible).

[0021] For example, if the NEF were to receive, by some means, an indication that there is a "potential UDR data inconsistency," the NEF may initiate regeneration of any relevant data. For example, the NEF may subscribe to be notified of certain changes and / or updates in the state or events of the wireless device. Then, if the UDR data is inconsistent (i.e., the NEF internal data is not the same as the data stored in the UDR), the NEF may again send those subscriptions to the UDM (for use in updating the UDR).

[0022] However, in instances where potential data inconsistencies affect a large number of wireless devices (e.g., in large-scale IoT deployments), this would mean that the NEF would need to send a huge number of subscriptions to the UDM with no criteria other than time windows and burst sizes, which could overload the UDM and, consequently, the UDR as well, causing many rejections of restoration / regeneration attempts.

[0023] To avoid this excessive signaling and request bursts, there are mechanisms that can be implemented in the NEF to pace the subscriptions sent to the UDM. For example, the NEF could react to error codes by the UDM, or load and overload control mechanisms may need to be implemented to throttle requests and dynamically adapt the request throughput.

[0024] While this is possible, it requires significant implementation and processing costs, even more so when adaptations may vary depending on the UDM / UDR vendor. For example, whether a NEF may implement a load / overload mechanism may not be consistent across UDMs. Even the use of error codes may not be perfectly consistent across UDMs.

[0025] Furthermore, these throttling mechanisms may not be able to guarantee that there will be no vetoes to restoring data. Moreover, these throttling mechanisms do not provide an indication to the operator as to what percentage or number of wireless devices have been restored at a given point in time.

[0026] Therefore, some embodiments described herein also provide methods and apparatus that enable the NEF / SCEF to effectively receive an indication (e.g., via the UDM) of UE activity, which the NEF can then utilize to recover needed data in the UDR.

[0027] Some embodiments described herein also enable the UDM to track the progress of resynchronization of data in the UDR after receiving a "potential UDR data inconsistency" warning, for example by tracking the number of wireless devices whose data has been restored. Operators may therefore easily check (e.g., via O&M nodes) the number of wireless devices whose data is already consistent across the network and may therefore be able to estimate the percentage of wireless devices that remain unsynchronized, so they can decide to accelerate or keep the same progress via other O&M-initiated means.

[0028] Some embodiments described herein avoid the need to implement message throughput adaptation mechanisms in the NEF / SCEF towards different UDM / UDR vendors (e.g., as described above). Instead, by providing the NEF / SCEF with an effective indication of UE activity, regeneration and / or restoration of wireless device data in the UDR can be performed in a smooth and gradual manner related to (or effectively controlled by) the naturally occurring traffic from the wireless device.

[0029] The embodiments described herein are described with respect to network functions in a 5G core network. However, it will be appreciated that functions described as being performed by a 5G core network function may be equivalently performed by a network node or function in another type of network, for example, a 4G core network. For example, functions described as being performed by a NEF may be equivalently performed by a SCEF in a 4G network.

[0030] FIG. 1 shows a method in a first network function for synchronizing data in a second network function. The method includes, in step 1001, receiving an indication of a potential registration data inconsistency related to one or more wireless devices from the second network function. In step 1002, the method may include receiving a registration request for the first wireless device from a third network function, the registration request including a first indication indicating that the reason for the registration request is a potential data inconsistency. In step 1003, the method may include updating registration data in the second network function in response to receiving the registration request. The first network function may comprise a unified data management (UDM) function. The second network function may comprise a unified data repository (UDR) function.

[0031] The method of FIG. 1 may be performed by a first network function, which may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud, or fog deployment.

[0032] 2 shows a method in a third network function for synchronizing data in a second network function. The method includes, in step 201, receiving a notification of a potential registration data inconsistency for one or more wireless devices from a first network function. In step 202, the method may include, in response to receiving a registration update from a first wireless device of the one or more wireless devices, sending a registration request for the first wireless device to the first network function, the registration request including a first indication indicating that the reason for the registration request is a potential registration data inconsistency. The third network function may comprise an access and mobility management function (AMF). The first network function may comprise a first network function configured to perform the method of FIG. 1.

[0033] The method of FIG. 2 may be performed by a third network function, which may comprise a physical or virtual node and may be implemented in a computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud, or fog deployment.

[0034] 3 shows a method in a fourth network function for synchronizing data in a second network function, the method including receiving notification of a potential registration data inconsistency for one or more wireless devices in step 301. The fourth network function may comprise a NEF.

[0035] The method of FIG. 3 may be performed by a fourth network function, which may comprise a physical or virtual node and may be implemented in a computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud, or fog deployment.

[0036] 4 shows a method in a second network function for synchronizing data in the second network function. The method includes, in step 401, obtaining an indication of one or more first network functions from a fifth network function, the one or more first network functions associated with a potential inconsistent registration data notification type in the fifth network function. The second network function may comprise a UDR. The one or more first network functions may comprise a UDM network function. The fifth network function may comprise a network repository function (NRF).

[0037] The method of FIG. 4 may be performed by a fourth network function, which may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud, or fog deployment.

[0038] Figures 5(a), 5(b) and 5(c) show an example implementation of the method of Figures 1-4. The methods of Figures 5(a), 5(b) and 5(c) are shown as being performed by the AMF, NEF, UDM, NRF and UDR. It will be appreciated that the functions described as being performed by these network functions may be equivalently performed by general network functions in different network types.

[0039] In step 0, the UDM and the NEF both register in the NRF that the UDM and the NEF are configured to receive potential inconsistency registration data notifications. In other words, the UDM and the NEF both register in their profiles in the NRF that the UDM and the NEF are the "Potential UDR Data Inconsistency" (Potential UDR_DI) default notification endpoints. The NEF and the UDM also register, in this example, that the NEF and the UDM support data restoration during wireless device activity.

[0040] In step 1, the UDR detected that data may be corrupted, lost, or inconsistent. For example, the UDR may fail and be restarted, or a migration of data from the old UDR to a new UDR may occur.

[0041] In step 2, the UDR performs a step of obtaining an indication of one or more UDMs (e.g., step 401 of FIG. 4), which may be performed in response to detecting a potential registration data inconsistency associated with one or more wireless devices (e.g., in response to step 1).

[0042] The UDR may, in some examples, perform the steps of obtaining an indication of one or more UDMs by sending a first discovery request to the NRF, where the first discovery request indicates that a network function of type UDM is the purpose of the discovery request, receiving from the NRF one or more network function profiles for the UDM, and selecting the one or more UDMs as one or more UDMs having a potential inconsistency registration data notification type in the one or more network function profiles for the UDM. In other words, the UDR may discover all profiles for a (network function type) NFtype (e.g., UDM) and then search for those that include the Potential UDR Data Inconsistency notification type in the profiles returned by the NRF.

[0043] Alternatively, as shown in Figures 5(a), 5(b), and 5(c), the UDR may perform the steps of obtaining an indication of one or more UDMs by sending a first discovery request to the NRF (e.g., step 2), where the first discovery request indicates a network function type UDM and a potential inconsistency registration data notification type (e.g., PotentialUDR_DI), and receiving one or more network function profiles for the UDM from the NRF (step 3). In other words, the UDR may use the notification type (set to PotentialUDRDataInconsistency) as a discovery query parameter, and thus the NRF returns only NF profiles that include the PotentialUDRDataInconsistency default notification type.

[0044] In step 4, the UDR sends an indication of a potential registration data inconsistency for one or more wireless devices to one or more UDMs (e.g., the UDM obtained by steps 2 and 3 performed, only one UDM is shown in Fig. 5(a), Fig. 5(b) and Fig. 5(c)). The indication may indicate which one or more wireless devices may be affected by the potential registration data inconsistency. The indication may also include a time period during which the potential registration data inconsistency may be valid.

[0045] In some examples, the UDR will repeat steps 2-4 for NFtype NEFs to also notify associated NEFs of the potential data inconsistency. However, in the examples shown in Figures 5(a), 5(b), and 5(c), the notification of the NEFs is performed by the UDM (as described with reference to steps 8-10).

[0046] In step 5 , the UDM acknowledges the message sent in step 4 .

[0047] In step 6, the UDM identifies which consumer NFs to which it should forward the notification received in step 4. For example, based on the affected users and their respective affected data, and the time period during which the data inconsistency may have an impact, the UDM may determine that the published data is also potentially inconsistent in the UDR. The UDM may then determine which NEF instances need to be informed. The UDM may also determine which AMFs or AMFs should be informed of the potential data inconsistency.

[0048] In some examples, in step 7, the UDM may track which wireless devices (and optionally data) are affected by the UDR data inconsistency (e.g., by storing this information in the UDR). In some examples, the UDM may record a count of one or more wireless devices. For example, the UDM may count a wireless device in one or more wireless devices as "Registration Data Inconsistent" in a KPI / counter that is accessible at any time by the operator via O&M.

[0049] In step 8, the UDM discovers one or more NEFs. In particular, the UDM discovers one or more NEFs that include the PotentialUDRDataInconsistency notification type in their profile. Steps 8 and 9 may be performed similarly to those described for steps 2 and 3.

[0050] In step 10, the UDM sends a Potential UDR Data Inconsistency notification to one or more NEFs (only one is shown) discovered in steps 8 and 9. In other words, the UDM notifies one or more NEFs of a potential registration data inconsistency for one or more wireless devices. The content of this message (step 10) may be the same as the content of the message received at the UDM in step 4.

[0051] It will be appreciated that steps 8, 9, and 10 may alternatively be performed by a UDR, as previously described.

[0052] In step 11, the NEF acknowledges the message received in step 10.

[0053] When a UDR group identification (UDRGroupId) is received from a UDR, the UDM may need to map it onto the corresponding UDM group identification (UDMGroupIds), if applicable; how this is done is implementation specific. The group id in the UDR identifies the set of users being served by the UDR, for example, the group id could be "UDR-group-1". When the UDM is receiving this information as part of a notification, the UDM needs to know which UDM group id (which identifies the set of users) is relevant. This may be done, for example, by mapping "UDR-group-1" to "UDM-group-1".

[0054] In step 12, the NEF may record one or more wireless devices that may be affected by a potential registration data inconsistency. For example, the NEF may mark one or more wireless devices as "pending restore of published data." The NEF may also record the time interval if one was mentioned by the UDR.

[0055] In step 13, the NEF may initiate the synchronization procedure without further initiation for the UDM that does not support gradual data restoration during wireless device activity. In other words, in response to the UDM not having previously indicated support for data restoration during wireless device activity (however, in the example shown in Figures 5(a), 5(b), and 5(c), in step 0, the UDM indicated support for data restoration), the NEF may initiate the synchronization procedure towards the UDR. It will be appreciated that mechanisms may be used to appropriately adjust requests to the UDR (as previously described). An NEF that does not itself support gradual data restoration during wireless device activity may also initiate the synchronization procedure at this stage.

[0056] However, in this example, the UDM indicated support for restoration of data during wireless device activity in step 0. Thus, in this example, the NEF (which in this example supports gradual restoration of data during wireless device activity as mentioned in step 0) instead waits to receive an indication of wireless device activity before proceeding with synchronization.

[0057] In step 14, the UDM notifies the AMF of a potential registration data inconsistency for one or more wireless devices. This step may be implemented as a broadcast to all AMFs. Alternatively, the UDM may send the notification only to the AMFs that currently serve the wireless device or currently serve one of the one or more wireless devices. The UDM may have a stored / cached list that includes all AMFs that have at least served the wireless device, and therefore may not need to discover these AMFs. However, in some examples, the AMFs may be discovered from the NRF.

[0058] This notification in step 14 may include the information received from the UDR in step 4 .

[0059] The AMF may record the wireless devices it serves that fall within one or more wireless devices in a notification from the UDM. For example, the AMF may mark such wireless devices as "pending restoration of registration data."

[0060] In step 15, the AMF performs the required restoration action for those wireless devices marked as "pending restoration of registration data" based on the activity of the wireless devices. The AMF periodically receives the wireless device activity (e.g., the wireless device it serves sends a "registration update" periodically to the AMF to inform the network that it is reachable for incoming calls and / or downlink data and / or paging). The AMF is the only NF that periodically receives this keep-alive from the wireless device. For example, the NEF does not receive this information in a periodic manner. If the restoration of the wireless device's data should be done incrementally instead of being initiated by the NEF (causing extensive signaling), the method described herein ensures that upon periodic wireless device contact with the AMF, the NEF is informed of the traffic activity from the wireless device and can then initiate restoration for that wireless device. This is an incremental procedure that is performed when the wireless device contacts the network, not before.

[0061] For example, in step 16, in response to receiving a registration update from a first wireless device of the one or more wireless devices, the AMF sends to the UDM a registration request for the first wireless device, the registration request including an indication that the reason for the registration request is a potential registration data inconsistency. The AMF may then record that the registration data of the first wireless device is no longer pending to be restored. This may prevent further restoration actions following further communication from the wireless device.

[0062] In step 17 , the UDM updates / restores the registration data in the UDR based on the registration update received in step 16 .

[0063] In step 18, in response to the registration request including an indication (e.g., flag PotentialUDR_DI) indicating that the reason for the registration request is a potential data inconsistency, the UDM notifies at least one of the one or more NEFs of the registration request for the first wireless device, at least one of which previously indicated support for data restoration upon wireless device activity. Thus, in this example (in step 19), the UDM indicates the "PotentialUDR_DI" flag to the NEF while notifying that the registration request was received from the AMF. This indication allows for resolving the data inconsistency between the NEF and the UDR.

[0064] For example, the UDM may discover from the NRF a NEF that supports restoration of data during wireless device activity.

[0065] In step 20 , the NEF acknowledges the message received in step 19 .

[0066] In step 21, the NEF performs the required restoration action for one or more wireless devices. For example, the NEF may send a subscription request for a first wireless device to the UDM, and in response to the subscription request including a second indication indicating that the subscription request is intended to restore data in the UDR, the UDM may record that the first wireless device public data has been restored. The UDM may also convey the subscription request to the UDR to update the public data in the UDR. Once the restoration action is performed for the wireless device, the NEF may mark the wireless device as "Restored Public Data".

[0067] In other words, the notification received at the NEF in step 19 may be interpreted as a user activity that may have potential inconsistencies. The NEF may then perform the required restoration action (e.g., sending a corresponding subscription request to the UDM). The NEF may also include an indication that the subscription to be restored is intended to serve as a regeneration / restoration of UDR data, e.g., it is not initiated by the AF (Application Function), but only by the NEF. Based on this indication, the UDM may count the user as having its "restored published data" in KPIs / counters that should be accessible at any time by the operator via O&M.

[0068] The published data may include subscriptions to notifications about some network events. For example, the NEF may subscribe to International Mobile Equipment Identity (IMEI) changes for a given wireless device (e.g., to be notified when the wireless device changes smartphones, e.g., introduces a SIM card in a new smartphone). This subscription to notifications about IMEI changes is sent to the UDM, which stores it in the UDR. If the UDR loses this data, the NEF will no longer be notified about the IMEI change. By implementing the method described above, if the NEF receives a notification from the UDM about a UDR inconsistency (which will cause the NEF to mark the affected users) and then receives a notification from the UDM about detected wireless device traffic activity (sent by the AMF to the UDM because the AMF also caused the wireless device to be marked as "pending to be restored"), the NEF will check whether the wireless device has been marked as "pending to be restored" (as is done by the AMF). If the wireless device is marked as "pending to be restored", the NEF may resend the subscription request for the IMEI change event so that it is restored in the UDR, and the UDM may then notify the NEF of the IMEI change as usual.

[0069] In this way, the AMF in contact with the UDM also acted as a trigger for the NEF to restore the user to the published data (which may include, for example, subscriptions to notifications about event publications).

[0070] 6 illustrates a first network function 600 comprising a processing circuit (or logic) 601. The processing circuit 601 controls the operation of the first network function 600 and may implement the methods described herein with respect to the first network function 600. The processing circuit 601 may comprise one or more processors, processing units, multi-core processors or modules configured or programmed to control the first network function 600 in the manner described herein. In certain implementations, the processing circuit 601 may comprise multiple software and / or hardware modules each configured to or for performing individual or multiple steps of the methods described herein with respect to the first network function 600.

[0071] Briefly, a processing circuit 601 of a first network function 600 is configured to receive an indication of a potential registration data inconsistency associated with one or more wireless devices from a second network function. The processing circuit may be further configured to receive a registration request for the first wireless device from a third network function, the registration request including a first indication indicating that a reason for the registration request is a potential data inconsistency, and to update the registration data at the second network function in response to receiving the registration request.

[0072] In some embodiments, first network function 600 may optionally comprise a communications interface 602. Communications interface 602 of first network function 600 may be for use in communicating with other nodes, such as other virtual nodes. For example, communications interface 602 of first network function 600 may be configured to transmit requests, resources, information, data, signals, or the like to and / or receive requests, resources, information, data, signals, or the like from other nodes. Processing circuitry 601 of first network function 600 may be configured to control communications interface 602 of first network function 600 to transmit requests, resources, information, data, signals, or the like to and / or receive requests, resources, information, data, signals, or the like from other nodes.

[0073] Optionally, the first network function 600 may comprise a memory 603. In some embodiments, the memory 603 of the first network function 600 may be configured to store program code that may be executed by the processing circuitry 601 of the first network function 600 to perform the methods described herein with respect to the first network function 600. Alternatively or additionally, the memory 603 of the first network function 600 may be configured to store any requests, resources, information, data, signals, or the like described herein. The processing circuitry 601 of the first network function 600 may be configured to control the memory 603 of the first network function 600 to store any requests, resources, information, data, signals, or the like described herein.

[0074] 7 illustrates a third network function 700 comprising a processing circuit (or logic) 701. The processing circuit 701 controls the operation of the third network function 700 and may implement the methods described herein with respect to the third network function 700. The processing circuit 701 may comprise one or more processors, processing units, multi-core processors or modules configured or programmed to control the third network function 700 in the manner described herein. In certain implementations, the processing circuit 701 may comprise multiple software and / or hardware modules each configured to or for performing individual or multiple steps of the methods described herein with respect to the third network function 700.

[0075] Briefly, the processing circuit 701 of the third network function 700 is configured to receive a notification of a potential registration data inconsistency for one or more wireless devices from a first network function. The processing circuit 701 may be further configured to, in response to receiving a registration update from a first wireless device of the one or more wireless devices, send to the first network function a registration request for the first wireless device, the registration request including a first indication indicating that a reason for the registration request is a potential registration data inconsistency.

[0076] In some embodiments, the third network function 700 may optionally comprise a communications interface 702. The communications interface 702 of the third network function 700 may be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 702 of the third network function 700 may be configured to transmit requests, resources, information, data, signals, or the like to and / or receive requests, resources, information, data, signals, or the like from the other nodes. The processing circuitry 701 of the third network function 700 may be configured to control the communications interface 702 of the third network function 700 to transmit requests, resources, information, data, signals, or the like to and / or receive requests, resources, information, data, signals, or the like from the other nodes.

[0077] Optionally, the third network function 700 may comprise a memory 703. In some embodiments, the memory 703 of the third network function 700 may be configured to store program code that may be executed by the processing circuitry 701 of the third network function 700 to perform the methods described herein with respect to the third network function 700. Alternatively or additionally, the memory 703 of the third network function 700 may be configured to store any requests, resources, information, data, signals, or the like described herein. The processing circuitry 701 of the third network function 700 may be configured to control the memory 703 of the third network function 700 to store any requests, resources, information, data, signals, or the like described herein.

[0078] 8 illustrates a fourth network function 800 comprising a processing circuit (or logic) 801. The processing circuit 801 controls the operation of the fourth network function 800 and may implement the methods described herein with respect to the fourth network function 800. The processing circuit 801 may comprise one or more processors, processing units, multi-core processors or modules configured or programmed to control the fourth network function 800 in the manner described herein. In certain implementations, the processing circuit 801 may comprise multiple software and / or hardware modules each configured to or for performing individual or multiple steps of the methods described herein with respect to the fourth network function 800.

[0079] Briefly, the processing circuit 801 of the fourth network function 800 is configured to receive a notification of a potential registration data inconsistency for one or more wireless devices.

[0080] In some embodiments, the fourth network function 800 may optionally comprise a communications interface 802. The communications interface 802 of the fourth network function 800 may be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 802 of the fourth network function 800 may be configured to transmit requests, resources, information, data, signals, or the like to and / or receive requests, resources, information, data, signals, or the like from other nodes. The processing circuitry 801 of the fourth network function 800 may be configured to control the communications interface 802 of the fourth network function 800 to transmit requests, resources, information, data, signals, or the like to and / or receive requests, resources, information, data, signals, or the like from other nodes.

[0081] Optionally, the fourth network function 800 may comprise a memory 803. In some embodiments, the memory 803 of the fourth network function 800 may be configured to store program code that may be executed by the processing circuitry 801 of the fourth network function 800 to perform the methods described herein with respect to the fourth network function 800. Alternatively or additionally, the memory 803 of the fourth network function 800 may be configured to store any requests, resources, information, data, signals, or the like described herein. The processing circuitry 801 of the fourth network function 800 may be configured to control the memory 803 of the fourth network function 800 to store any requests, resources, information, data, signals, or the like described herein.

[0082] 9 illustrates a second network function 900 comprising a processing circuit (or logic) 901. The processing circuit 901 controls the operation of the second network function 900 and can implement the methods described herein with respect to the second network function 900. The processing circuit 901 can comprise one or more processors, processing units, multi-core processors or modules configured or programmed to control the second network function 900 in the manner described herein. In certain implementations, the processing circuit 901 can comprise multiple software and / or hardware modules each configured to or for performing individual or multiple steps of the methods described herein with respect to the second network function 900.

[0083] In brief, the processing circuit 901 of the second network function 900 is configured to obtain, from a fifth network function, an indication of one or more first network functions associated with a potential inconsistent registration data notification type at the fifth network function.

[0084] In some embodiments, the second network function 900 may optionally comprise a communications interface 902. The communications interface 902 of the second network function 900 may be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 902 of the second network function 900 may be configured to transmit requests, resources, information, data, signals, or the like to and / or receive requests, resources, information, data, signals, or the like from the other nodes. The processing circuitry 901 of the second network function 900 may be configured to control the communications interface 902 of the second network function 900 to transmit requests, resources, information, data, signals, or the like to and / or receive requests, resources, information, data, signals, or the like from the other nodes.

[0085] Optionally, the second network function 900 may comprise a memory 903. In some embodiments, the memory 903 of the second network function 900 may be configured to store program code that may be executed by the processing circuitry 901 of the second network function 900 to perform the methods described herein with respect to the second network function 900. Alternatively or additionally, the memory 903 of the second network function 900 may be configured to store any requests, resources, information, data, signals, or the like described herein. The processing circuitry 901 of the second network function 900 may be configured to control the memory 903 of the second network function 900 to store any requests, resources, information, data, signals, or the like described herein.

[0086] Also provided is a computer program comprising instructions that, when executed by a processing circuit (such as processing circuit 601, 701, 801, or 901 described previously), cause the processing circuit to perform at least a portion of the methods described herein. A computer program product embodied on a non-transitory machine-readable medium is provided comprising instructions executable by the processing circuit to cause the processing circuit to perform at least a portion of the methods described herein. A computer program product is provided comprising a carrier including instructions for causing the processing circuit to perform at least a portion of the methods described herein. In some embodiments, the carrier may 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.

[0087] Implementing the embodiments described herein may result in one or more of the following effects on services, entities, and interfaces. UDM: - Specify and register a new PotentialUDRDataInconsistency notification endpoint in the NF profile. - Receives a PotentialUDRDataInconsistency notification, which triggers the required actions for data synchronization. - Discover the PotentialUDRDataInconsistency notification endpoint and send a PotentialUDRDataInconsistency notification request (and identify to which of its consumers it should send the notification). - Check whether the Potential UDR Data Inconsistency flag is included in the registration, and if so, send a new notification (registration for potential UDR data inconsistency) to the NEF. UDR: - Identifying the affected subscribers, affected data sets and data subsets, and affected time periods of potential data inconsistencies. - Discover the PotentialUDRDataInconsistency notification endpoint and send a PotentialUDRDataInconsistency notification request (previously identifying to which of its consumers it should send the notification). PCF: - Specify and register a new PotentialUDRDataInconsistency notification endpoint in the NF profile. - Receives a PotentialUDRDataInconsistency notification, which triggers the required actions for data synchronization. - Perform (implementation specific) recovery actions. AMF / SMF / SMSF / NEF: - Specify and register a new PotentialUDRDataInconsistency notification endpoint in the NF profile. - Receives a PotentialUDRDataInconsistency notification, which triggers the required actions for data synchronization. - Marking identified subscribers (and data) that were affected during an identified time period. AMF: - Include the PotentialUDRDataInconsistency flag in the registration when it is needed for that reason. NEF: - When a notification from the UDM is received for a marked user, perform the (implementation specific) restore action.

[0088] It should be noted that the above-described embodiments are illustrative rather than limiting of the present invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, and "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfill the functions of several units recited in a claim. Any reference signs in the claims should not be construed as limiting their scope.

Claims

1. A method in a first network function for synchronizing data in a second network function, the method comprising: receiving, from the second network function, an indication of potential registration data inconsistency related to one or more wireless devices; receiving, from a third network function, a registration request for a first wireless device, the registration request including a first indication indicating that the reason for the registration request is potential data inconsistency; in response to receiving the registration request, updating registration data in the second network function; and a method comprising.

2. further comprising notifying one or more fourth network functions of the potential registration data inconsistency for the one or more wireless devices; The method according to claim 1, further comprising.

3. The method according to claim 2, wherein each of the one or more fourth network functions includes a network exposure function.

4. further comprising discovering the one or more fourth network functions from a fifth network function, wherein the one or more fourth network functions are registered as potential registration data inconsistency endpoints in the fifth network function; The method according to claim 2.

5. The method according to claim 4, wherein the fifth network function includes a network repository function (NRF).

6. further comprising notifying one or more third network functions of the potential registration data inconsistency for the one or more wireless devices; The method according to claim 1, further comprising.

7. The method according to claim 6, wherein each of the one or more third network functions includes an access and mobility management function (AMF).

8. further comprising discovering the one or more third network functions from a fifth network function; The method according to claim 6.

9. The method according to claim 1, further comprising registering in the fifth network function to configure the first network function to receive a potential inconsistency registration data notification.

10. The method according to claim 9, wherein the fifth network function includes a network repository function (NRF), the first network function includes unified data management (UDM), and the second network function includes a unified data repository (UDR).

11. A method in a third network function for synchronizing data in a second network function, the method comprising: Receiving, from a first network function, a notification of potential registration data inconsistency for one or more wireless devices; In response to receiving a registration update from a first wireless device among the one or more wireless devices, sending, to the first network function, a registration request for the first wireless device, the registration request including a first indication indicating that the reason for the registration request is potential registration data inconsistency; A method comprising the above.

12. The method according to claim 11, wherein the third network function includes an access and mobility management function (AMF), and the first network function includes a unified data management (UDM) function.

13. Further comprising, in response to receiving the notification from the first network function, recording that the one or more wireless devices have inconsistent registration data. The method according to claim 11.

14. A method in a fourth network function for synchronizing data in a second network function, the method comprising: Registering, in a fifth network function, that the fourth network function is set to receive a potential inconsistent registration data notification; Receiving, from a first network function, a notification of a registration request for a first wireless device among one or more wireless devices; In response to receiving the notification of the registration request, sending, to the first network function, a subscription request for the first wireless device, the subscription request including a second indication indicating that the subscription request is intended to restore data in the second network function; Receiving a notification of potential registration data inconsistency for one or more wireless devices; A method comprising the above.

15. The method according to claim 14, wherein the notification of potential registration data inconsistency for one or more wireless devices is received from a first network function or a second network function.

16. The method according to claim 15, wherein the first network function comprises an integrated data management (UDM) function, the second network function comprises an integrated data repository (UDR) function, the fifth network function comprises a network repository function (NRF), and the fourth network function comprises a network exposure function (NEF).

17. A method in a second network function for synchronizing data in the second network function, the method comprising: obtaining an instruction of one or more first network functions from a fifth network function, wherein the one or more first network functions are related to a potential inconsistent registration data notification type in the fifth network function; Method.

18. The step of obtaining the instruction of one or more first network functions comprises: sending a first discovery request to the fifth network function, wherein the first discovery request indicates the type of the first network function; receiving one or more first network function profiles from the fifth network function; selecting the one or more first network functions as the one or more first network functions having the potential inconsistent registration data notification type in the one or more first network function profiles. The method according to claim 17.

19. further comprising sending an indication of potential registration data inconsistency for one or more wireless devices to the one or more first network functions. The method according to claim 17.

20. The method according to claim 17, wherein the second network function comprises an integrated data repository (UDR) function.

21. A first network function for synchronizing data in a second network function, wherein the first network function comprises a processing circuit, and the processing circuit is configured to cause the first network function to execute the method according to any one of claims 1 to 20.

Images