A method of restoring data in a telecommunication network
Patent Information
- Application Number
- PCT/EP2026/058887
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-03-28
- Filing Date
- 2026-03-27
- Publication Date
- 2026-10-01
Smart Images

Figure EP2026058887_01102026_PF_FP_ABST
Abstract
Description
[0001] P113042WG01
[0002] 1
[0003] A method of restoring data in a telecommunication network
[0004] Technical Field
[0005] The present disclosure generally relates to data restoration in a telecommunication network.
[0006] Background
[0007] Data restoration plays a role that may be of importance in maintaining system integrity when the User Data Repository, UDR, experiences data loss. When the UDR loses data, it may need to notify both UDR consumers and Unified Data Management, UDM, consumers about the need to re-create the lost data. Upon receiving this notification from the UDR, the UDM informs its own consumers, such as the Access and Mobility Management Function, AMF, Session Management Function, SMF, by sending out a notification.
[0008] Restoration of data is described in TS 23.527.
[0009] When a system responsible for storing temporary user data, UDR, experiences issues such as data corruption, loss, or inconsistencies, it needs a way to notify other systems that rely on this data, i.e. the UDR consumers and UDM consumers. These consumers include network functions such as UDM, PCF, NEF, AMF, SMF, SMSF, and AUSF.
[0010] If the UDR detects a problem with its temporary data, it sends a notification to its consumers, informing them about the issue. If the affected consumer is UDM, it will also notify its own consumers to ensure they are aware of the potential data inconsistency. These consumers can then take the necessary steps to re-synchronize their data with the UDR.
[0011] The notification from the UDR identifies the entities related to the affected data. This is done using one or more identifiers, such as:
[0012] Reset-ID (with PLMN ID) - This identifier is assigned by the UDR and may relate to specific hardware resources or contain a reset-counter.
[0013] SUPI or GPSI ranges - These identify the affected subscriber or service profile. DNNs / S-NSSAIs (with PLMN ID) - These define specific network services or access settings.
[0014] UDR or UDM Group ID (with PLMN ID) - This groups affected data by system category.P113042W001
[0015] 2
[0016] PLMN ID of the UDR - This identifies the affected network.
[0017] While these identifiers are optional, it is recommended to include at least one to help narrow down the affected data. If the notification is sent to a UDM consumer in a different network, at least one identifier must be included.
[0018] The notification may include two timestamps:
[0019] Last Replication Time - The last time the UDR successfully saved a copy of the temporary data before the issue occurred.
[0020] Recovery Time - The time when the UDR resumed normal operations after the issue.
[0021] To handle notifications effectively, UDR consumers and UDM consumers define a callback URI in their system profile. This is an endpoint where they can receive notifications if a data inconsistency is detected.
[0022] When the UDR detects an issue, it may send a notification to UDR consumers using their callback URI. If UDM is affected, it may forward the notification to its consumers within the same network using their registered callback URIs. In cases involving users in different networks (e.g., roaming users), UDM consumers can register their data restoration callback URI to ensure they receive notifications even when connected to another network.
[0023] This process ensures that affected systems are informed and can take appropriate actions to maintain service continuity and are able to restore data at the UDR.
[0024] Summary
[0025] It would be advantageous to achieve a more efficient method of restoring data at the UDR.
[0026] In a first aspect of the disclosure, there is provided a method of restoring data at a Unified Data Repository, UDR, in a telecommunication network, wherein said UDR stores one or more data sets, wherein each of said plurality of data sets comprises a plurality of data records, wherein said method comprises the steps of:
[0027] determining, by said UDR, a need to restore a specific data record within said one or more data sets in said UDR;
[0028] requesting, by said UDR, restoration of data, wherein said requesting comprises an identification of said specific data record within said one of said plurality of data sets in said UDR;
[0029] receiving, by said UDR, said specific data record.P113042W001
[0030] 3
[0031] The present disclosure focuses on a method for restoring data within a Unified Data Repository, UDR, in a telecommunication network. An aspect of this method is the identification of the specific data record(s) that need to be restored.
[0032] When the UDR determines or identifies the need to restore a particular data record, it initiates a request for data restoration. This request may be of importance as it includes the identification of the specific data record within the relevant data set. By incorporating this identification step, the method ensures that the identified data record required is restored, thereby maintaining data integrity and minimizing the risk of data loss.
[0033] One of the advantages of this method is its efficiency in data restoration. Instead of restoring an entire data set, which can be time-consuming and resource-intensive, the method focuses on restoring only the specific data records that are identified as needing restoration. This targeted approach ensures that only the necessary data is restored, reducing the load on the system and minimizing downtime.
[0034] By including the identification of specific data records in the restoration request, the method avoids unnecessary data processing and storage overhead. This not only speeds up the restoration process but also conserves system resources, making the UDR more efficient and responsive. Additionally, this selective restoration enhances data integrity by ensuring that only the accurate and required data records are restored, thereby maintaining the consistency and reliability of the data stored within the UDR.
[0035] Implementing the identification of a specific data record for restoration in a Unified Data Repository, UDR, can be approached in several ways.
[0036] A first option is that each data record within the UDR is assigned a unique identifier, UID. When a restoration request is made, the UID of the specific data record needing restoration may be included in the request. This ensures that only the data record identified by the UID is restored.
[0037] Another option is that data records can be tagged with metadata that includes information such as timestamps, record types, or other relevant attributes. The restoration request can then specify the metadata criteria to identify the specific data records that need to be restored.
[0038] Yet a further option is implementing an indexing system within the UDR which can help locate and identify specific data records. The restoration request can reference the index to pinpoint the exact records that need to be restored.
[0039] In an example, the one or more data sets can comprise subscription data, policy data, structured data for exposure, and application data. This flexibility allows the method to be applied to various types of data, making it versatile and adaptable to differentP113042W001
[0040] 4
[0041] telecommunication needs. By accommodating different data types, the method can be tailored to specific requirements, ensuring comprehensive data management across the network.
[0042] In a further example, profiles are incorporated, wherein profiles comprise a collection of data records associated with corresponding User Equipment, UE, in the telecommunication network. The requesting step may then include an identifier for identifying a set of profiles for which the specific data record is to be restored.
[0043] This approach ensures that data restoration is targeted and relevant to specific, i.e. a limited set of, user equipment, improving accuracy and relevance. By focusing on a limited number of profiles, the method can efficiently manage user-specific data.
[0044] In a further example, the identifier for identifying the set of profiles for which the specific data record is to be restored can include reset-identification, subscription permanent identifier or generic public subscription identifier ranges, data network names or single network slice selection assistance information, UDR or UDM group identification, and public land mobile network identifier identification, PLMN ID, of the UDR.
[0045] This variety of identifiers allows for flexible and accurate identification of the corresponding entities.
[0046] In yet another example, the one or more data sets comprise a plurality of data records organized in a hierarchy. Organizing data records in a hierarchy allows for structured restoration, enhancing data management. Hierarchical organization ensures that data can be efficiently accessed and restored, maintaining the integrity and consistency of the data stored within the UDR.
[0047] The above further entails that specific data records in the lower entry of the hierarchy can be restored without unnecessarily restoring all higher branches of data records of that hierarchy.
[0048] In yet another example, the identification of the specific data record within one of one or more of data sets in the UDR can include context-data, ee-subscriptions, amf-subscriptions, smf-subscriptions, hss-subscriptions, amf-3gpp-access, smf-registrations, and smsf-3gpp-access.
[0049] These are typical examples of data records that may be restored within the hierarchical data sets comprised by the UDR.
[0050] In yet another example, the identification of the specific data record can include an identification of any of an Access Management Function, AMF, Session Management Function, SMF, Short Message Service Function, SMSF, or Network Exposure Function, NEF.P113042W001
[0051] 5
[0052] In a second aspect of the present disclosure, there is provided a method of supporting restoration of data at a Unified Data Repository, UDR, by a Unified Data Management, UDM, in a telecommunication network, wherein said UDR stores one or more data sets, wherein each of said one or more data sets comprises a plurality of data records, wherein said method comprises the steps of:
[0053] determining, by said UDM, a need to restore a specific data record within said one or more data sets in said UDR;
[0054] transmitting, by said UDM, a request for restoring data, wherein said request comprises an identification of said specific data record within said one or more data sets in said UDR.
[0055] It is noted that the same advantages as explained with reference to the first aspect of the present disclosure are applicable for the second aspect of the present disclosure.
[0056] A method of supporting restoration of data at a UDR by a Unified Data Management, UDM, in a telecommunication network is described. The UDR stores one or more data sets, each comprising a plurality of data records.
[0057] The method involves determining, by the UDM, a need to restore a specific data record within one or more data sets in the UDR, and transmitting, by the UDM, a request for restoring data, wherein this request includes the identification of the specific data record within one or more data sets in the UDR. This method leverages UDM to support UDR, ensuring coordinated and efficient data restoration.
[0058] In an example, the step of determining comprises receiving, by the UDM, from the UDR, a request for restoring data, wherein this request includes the identification of the specific data record within one or more data sets in the UDR.
[0059] This step ensures that UDM is able to determine restoration needs based on UDR's requests, improving responsiveness. By receiving requests from UDR, UDM can efficiently initiate the restoration processes, ensuring timely and efficient data recovery.
[0060] In a further example, the step of transmitting comprises transmitting, by the UDM, the request for restoring data to a Network Exposure Function, NEF, in the telecommunication network. Involving NEF in the restoration process ensures that data restoration is integrated with network exposure functions, enhancing overall network performance. By transmitting requests to NEF, the method ensures that restoration processes are seamlessly integrated with existing network operations.
[0061] In yet another example, profiles are introduced, wherein profiles comprise a collection of data records associated with corresponding User Equipment, UE, in the telecommunication network. The request includes an identifier for identifying a set of profiles for which the specific data record is to be restored.P113042W001
[0062] 6
[0063] In another example, the identifier for identifying a set of profiles for which the specific data record is to be restored can include reset-identification, subscription permanent identifier or generic public subscription identifier ranges, data network names or single network slice selection assistance information, UDR or UDM group identification, and public land mobile network identifier identification, PLMN ID, of the UDR.
[0064] In yet another example, each of the one or more data sets comprises a plurality of data records organized in a hierarchy.
[0065] Organizing data records in a hierarchy allows for structured and systematic restoration, enhancing data management. Hierarchical organization ensures that data can be efficiently accessed and restored, maintaining the integrity and consistency of the data stored within the UDR.
[0066] In an even further example, the identification of the specific data record within one of the plurality of data sets in the UDR can include context-data, ee-subscriptions, amf-subscriptions, smf-subscriptions, hss-subscriptions, amf-3gpp-access, smf-registrations, and smsf-3gpp-access. Specifying different types of data records ensures that the method can accurately restore various data categories, improving overall data integrity.
[0067] In a third aspect of the present disclosure, there is provided a method of supporting restoration of data at a Unified Data Repository, UDR, in a telecommunication network, wherein said UDR stores a one or more data sets, wherein each of said one or more data sets comprises a plurality of data records, wherein said method comprises the steps of
[0068] receiving, by a Network Exposure Function, NEF, a request for restoring data, wherein said request comprises an identification of said specific data record within said one or more data sets in said UDR;
[0069] controlling, by said NEF, that said requested specific data record is restored at said UDR.
[0070] It is noted that the same advantages as explained with reference to the first aspect of the present disclosure are applicable for the third aspect of the present disclosure.
[0071] In an example, the step of controlling comprises any of:
[0072] transmitting, by said NEF, to said UDR, said requested specific data record;
[0073] transmitting, by said NEF, to an Application Function, AF, in said telecommunication network, a request for restoring data, wherein said request comprises an identification of said specific data record;P113042WG01
[0074] 7
[0075] marking, by said NEF, said specific data record as to be restored.
[0076] In another example, profiles comprise a collection of data records that are associated to corresponding User Equipment, UE, in said telecommunication network, wherein said request comprises an identifier for identifying a set of profiles for which said specific data record is to be restored.
[0077] In a further example, the said identifier for identifying a set of profiles for which said specific data record is to be restored is any of:
[0078] Reset-Identification;
[0079] Subscription Permanent Identifier or Generic Public Subscription Identifier ranges;
[0080] Data Network Names or Single Network Slice Selection Assistance Information;
[0081] UDR or UDM Group Identification;
[0082] Public Land Mobile Network Identifier Identification, PLMN ID, of the UDR. In yet another example, each of said one or more data sets comprises a plurality of data records organized in a hierarchy.
[0083] The identification of said specific data record within said one of said plurality of data sets in said UDR may comprise any of:
[0084] / context-data;
[0085] / ee-subscriptions;
[0086] / amf- subscriptions;
[0087] / smf-subscriptions;
[0088] / hss- subscriptions;
[0089] / amf-3gpp-access;
[0090] / smf-registrations;
[0091] / smsf-3gpp-access.
[0092] In a fourth aspect of the present disclosure, there is provided a method of supporting restoration of data at a Unified Data Repository, UDR, in a telecommunication network, wherein said UDR stores one or more data sets, wherein each of said one or more data sets comprises a plurality of data records, said method comprising the steps of:
[0093] receiving, by any of a Network Function, NF, in said telecommunication network, an identification of said specific data record within said one or more data sets in said UDR to be restored;
[0094] transmitting, by said NF, said identification of said specific data record within said one or more of said data sets in said UDR to be restored.P113042WG01
[0095] 8
[0096] It is noted that the same advantages as explained with reference to the first aspect of the present disclosure are applicable for the fourth aspect of the present disclosure.
[0097] In an example, the NF is any of an Application Function, AF, a Session Management Function, SMF, or an Application Management Function.
[0098] In a specific example, profiles comprise a collection of data records that are associated to corresponding User Equipment, UE, in said telecommunication network, wherein said request comprises an identifier for identifying a set of profiles for which said specific data record is to be restored.
[0099] In an example, the identifier for identifying a set of profiles for which said specific data record is to be restored is any of:
[0100] Reset-Identification;
[0101] Subscription Permanent Identifier or Generic Public Subscription Identifier ranges;
[0102] Data Network Names or Single Network Slice Selection Assistance Information;
[0103] UDR or UDM Group Identification;
[0104] Public Land Mobile Network Identifier Identification, PLMN ID, of the UDR. In a further example, each of said plurality of data sets comprises a plurality of data records organized in a hierarchy. The identification of said specific data record within said one of said plurality of data sets in said UDR may comprise any of:
[0105] / context-data;
[0106] / ee-subscriptions;
[0107] / amf- subscriptions;
[0108] / smf-subscriptions;
[0109] / hss- subscriptions;
[0110] / amf-3gpp-access;
[0111] / smf-registrations;
[0112] / smsf-3gpp-access.
[0113] In a fifth aspect of the present disclosure, there is provided a Unified Data Repository, UDR, arranged for operating in a telecommunication network, said UDR comprising a processing circuitry and a memory, wherein said processing circuitry is arranged to perform a method in accordance with any of the examples provided above.
[0114] In a sixth aspect of the present disclosure, there is provided a Unified Data Management, UDM, arranged for operating in a telecommunication network, said UDR comprising a processing circuitry and a memory, wherein said processing circuitry is arranged to perform a method in accordance with any of the examples provided above.P113042W001
[0115] 9
[0116] In a seventh aspect of the present disclosure, there is provided a Network Exposure Function, NEF, arranged for operating in a telecommunication network, said UDR comprising a processing circuitry and a memory, wherein said processing circuitry is arranged to perform a method in accordance with any of the examples provided above.
[0117] In an eight aspect of the present disclosure, there is provided a Network Function, NF, arranged for operating in a telecommunication network, said UDR comprising a processing circuitry and a memory, wherein said processing circuitry is arranged to perform a method in accordance with any of the examples provided above.
[0118] The above and other aspects of the disclosure will be apparent from and elucidated with reference to the examples described hereinafter.
[0119] Brief description of the figures
[0120] Fig. 1 depicts an example of a restoration protocol in accordance with the prior art;
[0121] Fig. 2 depicts another example of a restoration protocol in accordance with the prior art;
[0122] Fig. 3 depicts a subscription profile;
[0123] Fig. 4 depicts an example of a data restoration schematic in accordance with the disclosure;
[0124] Fig. 5 depicts an example of a data restoration schematic 400 in accordance with the disclosure;
[0125] Fig. 6 depicts another example of a data restoration schematic 400 in accordance with the disclosure;
[0126] Fig. 7 depicts yet another example of a data restoration schematic 400 in accordance with the disclosure;
[0127] Fig. 8 depicts yet another example of a data restoration schematic 400 in accordance with the disclosure;
[0128] Fig. 9 depicts yet another example of a data restoration schematic 400 in accordance with the disclosure;
[0129] Fig. 10 depicts yet another example of a data restoration schematic 400 in accordance with the disclosure;
[0130] Fig. 11 depicts yet another example of a data restoration schematic 400 in accordance with the disclosure;
[0131] Fig. 12 depicts yet another example of a data restoration schematic 400 in accordance with the disclosure.P113042W001
[0132] 10
[0133] Detailed description
[0134] It is noted that in the description of the figures, same reference numerals refer to the same of similar components performing a same of essentially similar function.
[0135] A more detailed description is made with reference to particular examples, some of which are illustrated in the appended drawings, such that the features of the present disclosure may be understood in more detail. It is noted that the drawings only illustrate typical examples and are therefore not to be considered to limit the scope of the subject matter of the claims. The drawings are incorporated for facilitating an understanding of the disclosure and are thus not necessarily drawn to scale. Advantages of the subject matter as claimed will become apparent to those skilled in the art upon reading the description in conjunction with the accompanying drawings.
[0136] The ensuing description above provides preferred exemplary embodiment(s) only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the preferred exemplary embodiment(s) will provide those skilled in the art with an enabling description for implementing a preferred exemplary embodiment of the disclosure, it being understood that various changes may be made in the function and arrangement of elements, including combinations of features from different embodiments, without departing from the scope of the disclosure.
[0137] Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise," "comprising," and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to." As used herein, the terms "connected," "coupled," or any variant thereof means any connection or coupling, either direct or indirect, between two or more elements; the coupling or connection between the elements can be physical, logical, electromagnetic, or a combination thereof. Additionally, the words "herein," "above," "below," and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. Where the context permits, words in the Detailed Description using the singular or plural number may also include the plural or singular number respectively. The word "or" in reference to a list of two or more items, covers all the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.P113042W001
[0138] 11
[0139] These and other changes can be made to the technology considering the following detailed description. While the description describes certain examples of the technology, and describes the best mode contemplated, no matter how detailed the description appears, the technology can be practiced in many ways. Details of the system may vary considerably in its specific implementation, while still being encompassed by the technology disclosed herein.
[0140] In figure 1 a restoration protocol in accordance with the prior art is shown. Before proceeding, the Unified Data Management, UDM, and Network Exposure Function, NEF, which may act as UDR / UDM consumers, have registered 110 their NF profiles in the Network Repository function, NRF. This includes a Default Subscription for the Data Restoration Notification.
[0141] This process may not only apply to the NEF as a consumer of both the UDR and UDM but also to any other Network Function, NF, that may act as a consumer of both.
[0142] In a first step 101, the UDR either identifies or is informed of the need to re-create or restore data. This may happen due to data loss within the UDR or be triggered by an O&M command related to subscription data migration. The data loss can affect different sets of UE IDs, such as a SUPI range, an individual UE, a short list of UEs, all UEs, or any UE. At the same time, the UDM is informed that re-synchronization must be performed.
[0143] In a second step 102, the UDR determines where the Data Restoration Notification should be sent to inform UDR consumers that re-synchronization is required. This endpoint is provided as part of the Default Subscription configured in the UDR consumer's NRF profile. The UDR retrieves this information from the NRF. As used herein, the term "determines" or "determining" in the context of a network function ascertaining a need to restore data, may include any of: autonomously detecting a condition requiring restoration, receiving an indication or notification from another network function, being informed via an Operations and Maintenance (O&M) command, or otherwise becoming aware of the need for restoration. For example, the UDR may identify or be informed of the need to re-create or restore data due to data loss within the UDR or triggered by an O&M command related to subscription data migration. The UDR may detect corruption, loss, or inconsistency in temporary data caused due to certain scenarios (e.g. failure and restart of the UDR, or migration of the data from an old UDR to a new UDR). Similarly, the UDM may recognize the need to restore data based on a notification transmitted by the UDR or it may be informed in any other way.
[0144] In a third step 103, the UDR sends the Data Restoration Notification to the endpoint for the NEF as a UDR consumer.P113042W001
[0145] 12
[0146] In a fourth step 104, the NEF processes the notification and initiates data resynchronization for the affected UEs. It then marks all these UEs as "to be restored." In a fifth step 105, the UDR also sends the Data Restoration Notification to the endpoint for the UDM as a UDR consumer.
[0147] In a sixth step 106, the UDM, like the UDR earlier, determines the endpoint where the Data Restoration Notification should be sent to inform its own consumers of the need for re-synchronization. This endpoint is included in the Default Subscription configured in the UDM consumer’s NRF profile. The UDM retrieves this information from the NRF.
[0148] In a seventh step 107, the UDM sends the Data Restoration Notification to the endpoint for the NEF as a UDM consumer. However, this results in the same notification being sent again, containing identical information.
[0149] In an eighth step 108, the NEF, once again, processes the notification, performs data re-synchronization for the listed UEs, and marks them as "to be restored." However, this action is redundant, as it has already been performed earlier.
[0150] At this point, a problem arises. Since the NEF is a consumer of both the UDM and UDR, it receives the exact same Data Restoration Notification twice. The NEF, however, is unable to determine from which NF the notification originated, making it unclear whether the restoration should be executed via the UDM or the UDR. As a result, the NEF does not have enough information to proceed correctly, preventing it from completing the restoration properly.
[0151] In figure 2 another restoration protocol in accordance with the prior art is shown. Here a precondition 210 is provided. This precondition 210 is that the NEF may have registered its NF profile in the NRF, including a Default Subscription for the Data Restoration Notification. Further, another precondition 211 is provided wherein the AF has performed some activity with interactions with the network via the NEF, that has ended up in some data stored in the UDR, e.g. application data like PFD, Event Exposure data.
[0152] Here, the NEF does not retain all the data provided by AFs during their interactions with the network. As a result, any data stored in the UDR, as per precondition 211, that was lost cannot be recovered.
[0153] Additionally, the data migration procedure is unable to transfer all data from the original UDR. In many instances, data created by the AF is not copied, leading to the loss of required use cases for AFs.
[0154] In figure 3, subscription data is shown, i.e. it discloses how a user equipment is registered. Herein the subscription data comprises multiple resources. This figure represents a hierarchical data structure for subscription-data, detailing variousP113042W001
[0155] 13
[0156] subcategories related to user subscription information. The structure is organized under {ueld}, representing a unique User Equipment, UE, identifier, ID. Some of the categories include context-data, amf-non-3gpp-access, and smsf-non-3gpp-access. The ee-subscriptions branch (highlighted) contains {subsld}, further categorized into amf-subscriptions, smf-subscriptions, and hss-subscriptions. This hierarchy represents a data model used in telecommunications for managing user subscription details across different network services.
[0157] Figure 4 depicts an example of a data restoration schematic 400 in accordance with the disclosure. Herein, a precondition is given, after which steps are provided which are followed to correctly allow data restoration in the correct resource of the subscription hierarchy.
[0158] As a precondition 410 a Network Exposure Function, NEF and / or a Unified Data Management, UDM, have registered their Network Function profile in the Network Repository Function, NRF. The NRF facilitates communication between different NFs. The NEF / UDM have a Default Subscription for Data Restoration Notification. This allows the UDR to transmit a notification, specifically the Data Restoration Notification to the respective NFs.
[0159] When the precondition 410 is met, the data restoration schematic 400 may proceed. First 401, the Unified Data Repository, UDR, recognises ( / determines) that data needs to be restored. This triggers the UDR to identify / discover all its consumers that have subscripted to the Data Restoration Notification 202, i.e. the Default Subscription. Then after identifying the respective consumers, it will transmit 403 the Data Restoration Notification to the consumer, first being the NEF. Herein the Data Restoration Notification comprises an identifier identifying the originator of the Data Restoration Notification. Then the NEF is arranged to mark 404 the UEs in the Data Restoration Notification as “to be restored” wherein the marking comprises the identifier. Then, the actual restoration as UDR consumer may take place, as indicated with reference numeral 405.
[0160] A similar process may be done for the UDM, where the UDR first informs the UDM about the Data Restoration after which the UDR informs the NEF.
[0161] First, after identifying the respective consumers, the UDF may transmit 406 a Data Restoration Notification to the consumer, this case being the UDM. The UDM may then discover 407 all its consumers that include a Default Subscription. Next, the UDM may transmit 408 a data restoration notification, including a parameter indicating the originator (i.e. the UDM), to the NEF. Finally, the actual restoration as UDM consumer may take place, as indicated with reference numeral 4010.P113042W001
[0162] 14
[0163] Figure 5 depicts an example of a data restoration schematic 500 in accordance with the disclosure. Herein, another precondition regards the data stored in the UDR as a result of AF interactions. This requires that the AF has performed some activity with the network via the NEF, resulting in data being stored in the UDR regarding the AF. So, in this example there are two preconditions: 1) the NEF has registered its NF profile in the NRF, with a default subscription for data restoration notification and 2), data is stored in UDR as a result of AF interactions.
[0164] When these preconditions 510, 511 are met, the data restoration schematic 500 may proceed. First 501, the Unified Data Repository, UDR, recognises ( / determines) that data needs to be restored. This triggers the UDR to identify / discover 502 all its consumers that have subscripted to the Data Restoration Notification, i.e. the Default Subscription.
[0165] After identifying the respective consumers, the UDR will transmit 503 the Data Restoration Notification to the consumer, first being the NEF. Herein the Data Restoration Notification comprises an identifier identifying the originator of the Data Restoration Notification and it may comprise an indication of the specific data that is to be restored.
[0166] Then the NEF is arranged to inform 504 the respective AF that restoration is needed for its data that was stored in the UDR. The AF then identifies the interactions that are to be repeated 505 and repeats 506 the interactions that result in re-creating the data in the UDR.
[0167] Figure 6 depicts an example of a data restoration schematic 600 in accordance with the disclosure. A precondition 110 is given (being that the UDM consumers have registered its NF profile in the NRF with a default subscription for data restoration notification), after which steps are provided which are followed to correctly allow data restoration in the correct resource of the subscription hierarchy.
[0168] A precondition in figure 6 considers that the data loss may be due to migration from UDR1 to UDR2, but generically the example applies for any data loss in UDR, specifically in this case of the EE subscription context.
[0169] The UDM recognises (i.e. determines) a need to restore at least one of multiple resources of a subscription profile. This may be one of the resources of the subscription profile as provided in figure 3. The UDM recognizes the need based on a notification transmitted by the UDR 602 or it may be informed in any other way 601.
[0170] Due to the recognition of the need to restore at least one of the multiple resources of the subscription profile, the UDM may discover / identify 106 any consumers that areP113042W001
[0171] 15
[0172] subscribed to the Data Restoration Notification, i.e. any consumers that include a Default Subscription. A corresponding UE may registered in the subscription profile.
[0173] Hereafter, the UDM transmits 603 a request for restoring data, wherein said request comprises an identification of said at least one of said multiple resources. This request may be transmitted to any of the consumers that are subscribed to the Data Restoration Notification.
[0174] For example, the Notification is transmitted to the NEF 603. The NEF therefore receives said request for restoring data, wherein said request comprises an identification of said at least one of said multiple resources. The NEF then controls that said requested at least one of said multiple resources of said subscription profile in said UDR is restored at said UDR. For example, the NEF transmits a request for restoring data to an Application Function, AF, 605 wherein said request comprises an identification of said at least one of said multiple resources. In an example, the NEF may mark said at least one of said multiple resources in said profile of said UE as to be restored 604. This may be done to verify whether the to be restored data matches the request.
[0175] The AF receives the request for restoring data, for example from the NEF. Here, the AF is informed 605 by the NEF about the data loss, i.e. the need for data restoration, and identifies the data loss based on the information the AF has received. The data originating from interactions of the AF may be recreated by repeating the interactions that were performed to create the data in the first place 606. This may restore data that was lost. The AF therefore transmits the subscription request, for example an Event Exposure, EE, subscription request 607. This request allows the AF to receive notifications about specific events.
[0176] The NEF receives the request and checks if the UE is marked as to be restored 608. If so, the NEF sends the subscription request, for example the EE subscription request to the UDM 609, this request may be marked with an indication that allows the UDM to identify that this request is transmitted due to a data restoration event.
[0177] The UDM is arranged for requesting the new subscription to be created in the UDR 6010. The subscription response 6011 by the UDR includes the newly created subscription identification created by the UDR. The UDM forwards 6012 this to the originator, in this example the NEF. The NEF then clears 6013 the marking to be restored. The UDM identifies the subscription is created due to a restoration event and then it may recreate the subscription context in the serving nodes, being an AMF, SMF and / or SMSF. In the figure it is covered by the interaction 6014, 6015, 6016 with the AMF, but it is similar for the SMF. The subscription request is marked as well with the same indication.P113042W001
[0178] 16
[0179] The AMF receives 6014 the notification, which comprises an identifier that the subscription is received as per a restoration event. Then the AMF checks 6015 the resource context for the corresponding llEIDs. It is checked to know whether said resource already exists in order to avoid duplication of the data. If a corresponding resource does not exist, a resource will be duplicated and be stored in the UDR. So the AMF recognizes, by the respective notification that data corresponding to a resource needs to be recreated. Then, if needed to be recreated, the AMF indeed recreates the data and transmits 6016 the subscription request to the UDM with corresponding context data. Finally, the data is restored in the steps indicated with 6017 and 6018.
[0180] Figure 7 depicts another example of a data restoration schematic 700 in accordance with the disclosure. In this example, as another precondition 711, the NEF has stored the subscription context data locally. This means the NEF is able to request the modification of the locally stored subscription context data corresponding to a resource.
[0181] In step 701, a Nudm_EE_ModifySubscription_req UE1, EE subs context may be provided 701 to the UDM, which, in turn, provides 702 Nudr_DR_Create_req EE subs context to the UDR. Here, an identifier of the originator may be included, i.e Origin-UDR-allocated-SubsId.
[0182] The UDM may also provide a response back to the NEF as indicated with reference numeral 703.
[0183] Figure 8 depicts another example of a data restoration schematic 800. In this figure, because the NEF has locally stored subscription data corresponding to the AF, it may independently operate the transmission of the context data corresponding to a resource, therefore the correspondence with the AF is not necessary. Therefore, the NEF may transmit said requested at least one of said multiple resources of said subscription profile in said UDR.
[0184] Figure 9 depicts yet another example of a data restoration schematic 900 in accordance with the disclosure. Herein the NEF transmits a subscription request including the subscription context data corresponding to a resource. Herein a recreation indication is included in the subscription request, indicating the UDR that the subscription request follows from the request for restoring data. The NEF as storing the subscription context data locally overwrites the former allocated subscriber identifier corresponding to the UDR for the corresponding UE subscription context data.
[0185] The NEF may select the methodology corresponding to figure 7 or by the abovementioned steps corresponding to figure 9. This allows an improvement of the subscriber ID allocation.P113042W001
[0186] 17
[0187] Figure 10 depicts yet another example of a data restoration schematic in accordance with the disclosure. Herein the methodology described in relation to figure 9 also applies to figure 10, without the interaction with the AF. This may be possible when the NEF stores data locally, such that an interaction with the AF is not required.
[0188] Figure 11 depicts yet another example of a data restoration schematic in accordance with the disclosure. Herein the UDM directly interacts with the AMF by transmitting a data restoration notification, i.e. a request for restoring data, wherein said request comprises an identification of said at least one of said multiple resources. This allows the AMF to restore the data lost in the UDR in its subscription response.
[0189] Figure 12 depicts yet another example of a data restoration schematic in accordance with the disclosure. Herein the UDM marks all the UEs in the context data as needed to be restored. The UDM then transmits a data restoration notification to the AMF / SMF, which then marks all UEs in the data restoration notification as to be restored. Then for each UE, the AMF checks if they are correspondingly marked and the individual methodology of any of the figures 6-11 is followed.
[0190] The following relates to an aspect of the present disclosure.
[0191] This clause describes an optional procedure that may be supported by UDR, UDR consumers (i.e. UDM, PCF, and NEF), and UDM consumers (e.g. AMF, SMF, SMSF, AUSF, NEF...) to re-synchronize profiles in UDR to those in UDR consumers and UDM consumers. When UDR detects corruption, loss, or inconsistency in temporary data stored in UDR, the UDR indicates it to its consumers. UDR should also send notifications to its consumers upon restart based on the deployment policy. If the UDR consumer is UDM, the UDM indicates it to its consumers. Then, those consumers initiate necessary procedures directly or via UDM towards UDR, so that related profiles are re-synchronized and adverse impacts on operator's service can be minimized.
[0192] This procedure may also be used for Subscriber Data Migration, which is the process to move, in an orderly and controlled manner, temporary subscription data (context data) managed by an origin UDR to a target UDR system, usually as a result of the migration of static (provisioned) subscriber data between those UDR systems. This case is described in section 6.7.3.
[0193] Temporary data stored in UDR subject to restoration may be identified within the notification sent to UDR consumers and UDM consumers either by:
[0194] Reset-ID (plus PLMN ID of the UDR): Reset-IDs of temporary data associated to SUPI ranges or GPSI ranges are assigned by UDR in an implementation specific way; e.g. a Reset-ID may identify a hardware resource and may contain a reset-counter. TheP113042WG01
[0195] 18
[0196] Reset-ID is provided to UDR consumers and UDM consumers in the response of a request that has created temporary data (i.e. a resource) in UDR.
[0197] SUPI or GPSI ranges.
[0198] DNNs / S-NSSAIs (plus PLMN ID of the UDR).
[0199] UDR or UDM Group ID (plus PLMN ID of the UDR).
[0200] PLMN ID of the UDR.
[0201] Data to be resynchronized: it identifies the specific data that is required to be restored. For example, AMF Registation data, Event Exposure data.
[0202] Alternatively, the previous step can be understood in the way that the notification sent to UDR consumers and UDM consumers may identify the entities or ranges for which temporary data stored in UDR is subject to restoration, using one or more of the above mentioned identifiers.
[0203] The identifiers used in notifications are optional to be included when sent by UDR or by UDR consumers, but it is recommended that the notification includes some type of identifier to narrow down as much as possible the set of affected profiles. In particular, the notification to UDM consumers in PLMNs different from the PLMN of the UDM shall contain at least one of the identifiers. For the receivers of the notifications, all identifiers shall be supported.
[0204] If multiple identifiers are included in the notification, the set of affected profiles shall consider as a logical "AND" between all the included identifiers.
[0205] The notification sent to UDR consumers and UDM consumers also includes the following time values:
[0206] lastReplicationTime: The last time when UDR replicated the temporary data identified to be potentially lost or corrupted, i.e. before the situation causing the potential data inconsistency occurred. In the case of subscriber data migration procedure, this value indicates the time when a UDR started subscriber data migration.
[0207] recoveryTime: The time when UDR started working properly after the situation causing the potential data inconsistency occurred. In the case of subscriber data migration procedure, this value indicates the time when traffic switch was enforced for a subscriber data migration procedure (e.g. the NFProfile update into NRF).
[0208] Resources related to temporary data stored in UDR are associated in the corresponding user profile stored at UDR consumers or UDM consumers with a timestamp of the time they were created or last modified; i.e. lastSynchronizationTime. Temporary data in UDR created or updated between the lastReplicationTime and the recoveryTime may be inconsistent with profiles in UDR consumers and UDM consumers.P113042W001
[0209] 19
[0210] In order to avoid inconsistency of time due to different timezones, lastReplicationTime, recoveryTime and lastSynchronizationTime shall be identified using UTC.
[0211] UDR consumers and UDM consumers define callbackllri for data restoration notification in their NF profile. This dataRestorationCallbackllRI is an endpoint to receive data restoration notification when potential UDR data inconsistency occurs. In addition, UDR consumers may inform their identity to UDR. Additionally, UDM consumers may inform their dataRestorationCallbackUri to UDM during registration in UDM (e.g. for AMF, SMF, SMSF); if so, such callback URI shall be the same as the URI registered by the UDM consumer in its NF Profile in NRF, and it shall be a same URI for the entire consumer's NF Instance (i.e., the UDM consumer shall not indicate different callback URIs per each UE registration).
[0212] When the UDR detects a potential data inconsistency of temporary data, the UDR notifies the UDR consumers of the potential data inconsistency event using the dataRestorationCallbackUri of the UDR consumer.
[0213] The UDM may notify UDM consumers within its PLMN using the dataRestorationCallbackUri included in the NF profile of the UDM consumer in NRF. This is, a UDM that receives a notification from UDR can discover the dataRestorationCallbackURI of e.g. AMFs, SMFs, SMSFs or AUSFs within its PLMN and forward the notification to all of them. The UDM may also notify UDM consumers using the dataRestorationCallbackUri if provided by UDM consumers during its registration in UDM based on local configuration.
[0214] NOTE 2: The option for UDM consumers to provide its dataRestorationCallbackUri during registration in UDM, and such UDM using these callbackUris to send subsequent notifications, is particularly beneficial to support roaming users connecting via UDM consumers in PLMNs different from the PLMN of the UDM (e.g. AMF, SMSF, and SMF in Local Break Out scenarios), since it avoids the task for UDM to perform an inter-PLMN service discovery.
[0215] The UDR or UDM sends a unique notification per each UDR or UDM consumer, aiming to resynchronize all the data in the NF (UDR or UDM consumer) that is subject to resynchronization, regardless the resynchronization procedure may require the execution of one or multiple NF services (e.g. Nudm_SDM, Nudm_UECM for AMF, Nudm_PP, Nudm_EE for NEF).
[0216] The notification to UDR consumers and UDM consumers includes optionally the identifier of the temporary data subject to restoration (e.g. Reset-IDs), the lastReplicationTime and the recoveryTime. The UDR consumer or UDM consumer may then initiate the restoration of the temporary data identified to be potentially lost or corrupted when theP113042W001
[0217] 20
[0218] last synchronization time recorded at consumer falls between the lastReplicationTime and the recoveryTime as provided by the producer, i.e. UDR or UDM.
[0219] A process corresponding to the above is described in the following.
[0220] 0. UDR consumers and UDM consumers define callbackUri for data restoration notification in the NF profile registered in NRF.
[0221] 1. UDR consumers store temporary data in UDR. The UDR consumers may set its identity in the request to UDR, when accessing it for the first time. The UDR stores the received identity and creates for the UDR consumer a subscription on notification for the potential UDR data inconsistency. The UDR may provide to the UDR consumer the Reset-ID if assigned by the UDR for the temporary data stored in UDR.
[0222] The UDM stores temporary data in UDR as requested by its consumers. UDM consumers may set dataRestorationCallbackUri in the request of their registration to UDM. In this case, the UDM stores the dataRestorationCallbackUri locally and creates for the UDM consumer a subscription on notification for the potential UDR data inconsistency. If received from UDR, the UDM also provides the Reset-ID assigned by the UDR to UDM consumers.
[0223] When an NF other than UDM creates or updates a resource directly or via UDM in UDR, the NF sets or stores lastSynchronizationTime in a relevant profile. If the NF receives a Reset-ID directly or via UDM from UDR, the NF stores it in the profile.
[0224] 2. UDR detects corruption, loss, or inconsistency in temporary data caused due to certain scenarios (e.g. failure and restart of the UDR, or migration of the data from an old UDR to a new UDR).
[0225] NOTE 1: The UDR can recover consistency by different means, e.g. by reloading data from its back-up.
[0226] 3. UDR queries NRF based on the identity stored in step 1 and discovers callbackUri for data restoration notification in UDR consumers' NF profiles. If no UDR consumer impacted by the restoration event provided its identity in step 1, the UDR discovers via NRF the dataRestorationCallbackUri of one suitable UDR consumer instance to send the notification to. The UDR sends Nudr_DR_Notification request to the dataRestorationCallbackUri to notify potential UDR data inconsistency. The Nudr_DR_Notification request may contain temporary data identifier(s) (e.g. Reset-IDs) and an impacted period (i.e. lastReplicationTime and recoveryTime).
[0227] 4. If UDR consumer is UDM, the UDM forwards the notification to UDM consumers. The UDM finds callbackUri for data restoration notification for UDM consumers within its PLMN in UDM consumers' NF profiles through querying NRF. Optionally, the UDM may find callbackUrifor data restoration notification for UDMP113042W001
[0228] 21
[0229] consumers (especially UDM consumers outside its PLMN) if provided by the UDM consumer during UDM consumer registration in UDM and locally stored in UDM in stepl .
[0230] The UDM may control the restoration of data for the same UE, e.g. if both AMF Registration data and Event Exposure (EE) data is required to be restored, the UDM may send the data restoration to the AMF for all required UE Ids, and when for each UE the AMF Registration is received, trigger the data restoration for Event Exposure sending the notification to the NEF.
[0231] 5. When a UDR consumer other than UDM (e.g. PCF, NEF) or a UDM consumer (e.g. AMF, SMF, SMSF) finds that a stored profile is affected by the potential loss or corruption of data, and that the last synchronization time of the profile falls into the impacted period in the notification, then the NF judges that the profile requires resynchronization.
[0232] UDR consumers other than UDM (e.g. PCF, NEF) performs the resynchronization of the impacted resources using Nudr_DataRepository service operations.
[0233] UDM consumers performs the re-synchronization for each impacted UE using different service operations depending on the UDM consumer type. UDM consumers shall include a flag ("udrRestartlnd") indicating that the request is due to a resynchronization event.
[0234] UDM consumers that register in UDM start re-synchronization by sending Nudm_UECM_Registration request for each impacted UE.
[0235] In order to prevent storing obsolete registration information for a given user coming from UDM consumers that trigger resynchronization for the same user, UDM consumers may include the stored last synchronization time within the re-synchronization request. The lastSynchronizationTime provided by the UDM consumer may be used in UDM to compare it with current data stored in UDR and ensure that the registration from the most recent UDM consumer is kept (see step 7). However, if the UDM consumer ensures that its resynchronization is the most recent, accurate and correct (e.g. if the AMF triggers resynchronization upon detection of UE activity), the UDM consumer shall not include the lastSynchronizationTime within the resynchronization request and the UDM stores the UDM consumer registration in the UDR without further processing.
[0236] If data restoration notification indicated the Event Exposure subscription context is to be restored, the UDM sends the EE subscription request to the AMF / SMF including the flag ("udrRestartlnd") indicating that the request is due to a re-synchronization event and the Subscription may already exist in the AMF / SMF (duplication shall be avoided).P113042W001
[0237] 22
[0238] UDM consumers that subscribe to notification of subscription data changes in UDM start re-synchronization of these subscriptions in UDM by sending Nudm_SDM_Subscribe request for each impacted UE and subscription.
[0239] AUSF starts re-synchronization by sending Nudm_UEAuthentication_ResultConfirmation request containing the stored last synchronization timestamp of the authentication for each impacted UE.
[0240] NEF starts re-synchronization of the subscription to exposure events in UDM by sending Nudm_EE_ModifySubscription request for each impacted UE and subscribed event. The NEF may include the EE Subscriptions of the locally stored EE Subscription.
[0241] The NEF overwrites the locally stored EE Subscription Id with the new one received in the Nudm_EE_Subscription response.
[0242] The UDM sends the EE subscription request to the AMF / SMF including the flag ("udrRestartlnd") indicating that the request is due to a re-synchronization event and the Subscription may already exist in the AMF / SMF (duplication shall be avoided).
[0243] 6. The UDR consumers and UDM consumers locally adjusts invocation timing of each of those procedures, in order not to cause congestion in the system. The NF invokes necessary procedures.
[0244] If the data to be restored was requested for an individual UE, the UDM consumers and UDR consumers should invoke the procedure immediately.
[0245] NOTE: If the restoration procedure or data migration procedure is required for a small set of users (e.g. test users), the operator can make use of individual requests in order to trigger the procedure / test in an immediate manner instead of waiting for e.g. traffic activity from the affected UE. It is assumed that these individual requests to restore user data are not sent massively to avoid UDM consumers and UDR consumers being congested and causing congestion in UDM / UDR.
[0246] UDM consumers select a UDM instance to send the re-synchronization signalling as defined in 3GPP TS 23.501 [9], This is, the UDM consumer may not send the resynchronization signalling to the UDM instance from which the UDM consumer received the notification.
[0247] 7. If UDM receives Nudm_UECM_Registration request containing the "udrRestartlnd" flag, the UDM overwrites the related profile in the UDR, or creates it if not available. If the registration request includes a lastSynchronizationTime, the related profile in UDR is overwritten only if the lastsynchronization time received from the UDM consumer is not older than the registration time stored in UDR before resynchronization.P113042WG01
[0248] 23
[0249] In this case, if the UDM replaces or creates the related profile in UDR, the UDM sets the registration time to the current time.
[0250] If UDM receives Nudm_SDM_Subscribe request containing the "udrRestartlnd" flag the UDM sends a corresponding request to UDR, the UDR overwrites the related profile in the UDR or creates it if not available in UDR.
[0251] If UDM receives Nudm_UEAuthentication_ResultConfirmation request containing the "udrRestartlnd" flag, the UDM sends a corresponding request to UDR, the UDR overwrites the related profile in the UDR or creates it if not available in UDR.
[0252] If UDM receives Nudm_EE_ModifySubscription request containing the "udrRestartlnd" flag, the UDM sends a corresponding request to UDR, the UDR overwrites the related profile in the UDR or creates it if not available in UDR.
[0253] During operation of a PLMN, it is a common task to have to re-allocate subscriber's data records across subscriber servers / databases, due to multiple reasons such as, e.g., subscriber re-distribution, network re-dimensioning I scaling-out, replacement I swap of legacy databases (e.g. 4G UDC systems), etc.
[0254] The migration of the temporary data (context data) to the target UDR system may be realized by triggering the restoration of profiles related to UDR.
[0255] Additionally, network traffic shall be properly routed to the target UDR handling the new subscribers, affecting in many cases the traffic from 5GC to UDR consumers, i.e. UDM / PCF. For example, when subscribers are re-allocated to a new UDR group Id and also to a new UDM / PCF group Id, UDM / PCF consumers shall switch traffic related to the migrated subscribers to UDM / PCF instances in the new UDM / PCF group Id. In those cases, UDR rediscovery and / or UDM / PCF rediscovery is required to guarantee proper traffic routing.
[0256] The procedures followed to support subscriber data migration includes both traffic switch and recovery of temporary data in the target UDR (data re-synchronization). These procedures are initiated via GAM once the network has been properly configured, e.g. once static data has been provisioned in the target UDR for the migrated subscribers and other network functions (e.g. NRF and UDR supporting the NF Group ID mapping service), have been configured according to the new subscriber distribution.
[0257] Depending on the network deployment, data re-synchronization, traffic switch with rediscovery or both may be required for the data migration service. For example, in case UDM hides UDR network topology, traffic switch is not necessary for the UDM consumers, or in case temporary data is recovered from origin UDR but subscribers are distributed to a new UDM / UDR / PCF group, traffic switch with rediscovery without data re-synchronization shall be requested to UDM consumers. In case both are required,P113042WG01
[0258] 24
[0259] UDM / PCF / UDR consumers shall execute the traffic switch before the re-synchronization of the impacted resources is initiated.
[0260] For data migration, the restoration procedures described in figure 6.7.2-1 are used with the following adaptations. The notification to UDR consumers and UDM / PCF consumers may specifically include:
[0261] SUPI or GPSI ranges and PLMNId of the UDR: to identify the migrated subscribers
[0262] NF Re-discovery indication: to indicate traffic switch with NF rediscovery is required due to subscriber reallocation in a different NF group Id
[0263] No resynchronization required: to indicate temporary data does not need to be restored in UDR after subscriber reallocation in a different NF group Id
[0264] Time-based indication: to indicate that all identified migrated users need to be restored before a specified absolute time is reached.
[0265] Data to be resynchronized: to indicate the specific data that is required to be restored after migration.
[0266] When UDM / PCF / UDR consumers receive a NF rediscovery indication, it means the relationship between the migrated User and UDM / PCF / UDR Groupld has changed, so UDM / PCF / UDR consumers shall use the user identity to discover and select UDM / PCF / UDR instances serving the affected users in the new UDM / PCF / UDR Group Id, discarding the UDM / PCF / UDR Group Id previously available in the UE context, if any. AMF may additionally update the UDM / PCF group Id information in other NFs in case that information is changed in the UE context as a result of the new UDM / PCF selection.
[0267] The following relates to another aspect of the present disclosure.
[0268] The following table indicates the attributes for the data restoration notification that is transmitted by the UDR or the UDM.
[0269] Type: DataRestorationNotification
[0270] Attribute Data type P Card Descri ption
[0271] name inali
[0272] ty
[0273] lastReplication DateTime 0 0..1 If present, it contains the timestamp of the Time most recent instant when the data was assumed to be consistent at UDR (i.e. the potential data loss event at UDR did not occur before this instant).
[0274]
[0275] P113042WG01
[0276] 25
[0277] recoveryTime DateTime 0 0..1 If present, it contains the timestamp of the instant when the potential data loss event was recovered at UDR (i.e. all data records stored by UDR after this time are assumed to be consistent).
[0278] plmnld Plmnld C 0..1 If present, it shall contain the PLMN-ID of the UDM / UDR that originated the Data Restoration Notification.
[0279] It shall be included in notifications sent by UDM to its NF consumers located in other PLMNs.
[0280] supiRanges array(SupiRan 0 1..N If present, it contains the list of SUPIs ge) potentially subject to a data-loss event, or subject to a Subscriber Data Migration procedure, at the UDR.
[0281] gpsiRanges array(ldentityR 0 1..N If present, it contains the list of GPSIs ange) potentially subject to a data-loss event, or subject to a Subscriber Data Migration procedure, at the UDR.
[0282] resetlds array(string) 0 1..N If present, it contains the list of Reset-IDs of those UEs potentially subject to a data- loss event at the UDR.
[0283] sNssaiList array(Snssai) 0 1..N If present, it contains the list of slices (S- NSSAIs) potentially subject to a data-loss event at the UDR.
[0284] dnnList array(Dnn) 0 1..N If present, it contains the list of DNNs potentially subject to a data-loss event at the UDR.
[0285] udmGroupId NfGroupId 0 1..N If present, it contains the ID of the UDM Group whose UEs have been potentially subject to a data loss event at the UDR. rediscoverylnd boolean 0 0..1 If present with value true, UDM rediscovery is required due to subscriber reallocation in a different UDM group Id.
[0286]
[0287] P113042W001
[0288] 26
[0289] Default: false.
[0290] noResynchron boolean C 0..1 If present, it indicates whether data izationRequire resynchronization is required. It shall only d be present when rediscoverylnd is present and set to true.
[0291] - true: data resynchronization is not required
[0292] - false (default): data resynchronization is required
[0293] resynchronizat DateTime 0 0..1 If present, it indicates that ionTime resynchronization should be completed before the indicated time. It may be present only when noResynchronizationRequired is false or absent.
[0294] dataToResync array(UdmData 0 1..N If present, it indicates the data that is ToResynchroni required to resynchronize.
[0295] ze)
[0296]
[0297] The following relates to the UDM Data To Resynchronize notification sent by the UDM.
[0298] The enumeration UdmDataToResynchronize represents the data to be resynchronized. It shall comply with the provisions defined in the table below
[0299] Enumeration value Description
[0300] AMF_DATA This value indicates the receiver (i.e. AMF) of the Data Restoration Notification shall restore its data, i.e. the one that is created using the Nudm_UECM_Registration and Nudm_SDM_Subscribe. service.
[0301] SMF_DATA This value indicates the receiver (i.e. SMF) of the Data Restoration Notification shall restore its data, i.e. the one that is created using the Nudm_UECM_Registration and Nudm_SDM_Subscribe. service.
[0302] SMSF_DATA This value indicates the receiver (i.e. SMSF) of the Data Restoration Notification shall restore its data, i.e. the one
[0303]
[0304] P113042W001
[0305] 27
[0306] that is created using the Nudm_UECM_Registration and Nudm_SDM_Subscribe. service.
[0307] EE_SUBS_DATA This value indicates the receiver (e.g. NEF) of the Data Restoration Notification shall restore the data that is created using the Nudm_EE_Subscribe service.
[0308]
[0309] The following is yet another aspect of the present disclosure.
[0310] This clause specifies the application data model supported by the API. The table below specifies the data types defined for the Nudr_DataRepository API.
[0311] Data type Clause Description
[0312] defined
[0313] DataRestorationNotificat 6.2.5a.2.2 Contains identities representing those UEs ion potentially affected by a data-loss event at the
[0314] UDR
[0315]
[0316] The tables below specify data types re-used by the Nudr_DataRepository service-based interface protocol from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the Nudr_DataRepository service-based interface.
[0317] Data type Reference Comments
[0318] Dnn 3GPP TS 29.571 Data Network Name with Network Identifier
[0010] only.
[0319] Snssai 3GPP TS 29.571 Single NSSAI
[0320]
[0010]
[0321] NfGroupId 3GPP TS 29.571 NF Group ID
[0322]
[0010]
[0323] IdentityRange 3GPP TS 29.510 Identity Range
[0324]
[0014]
[0325] SupiRange 3GPP TS 29.510 SUPI Range
[0326]
[0014]
[0327] UdmDataToResynch 3GPP TS 29.503 Data that is required to resynchronize from ronize [XX] UDM consumers.
[0328]
[0329] P113042W001
[0330] 28
[0331] The following table relates to the Data Restoration Notification.
[0332] Attribute name Data type P Cardinalit Description
[0333] y
[0334] supiRanges array(SupiRang 0 1..N If present, it contains the list of SLIPIs e) potentially subject to a data-loss event, or subject to a Subscriber Data Migration procedure, at the UDR.
[0335] gpsiRanges array(ldentityRa 0 1..N If present, it contains the list of GPSIs nge) potentially subject to a data-loss event, or subject to a Subscriber Data Migration procedure, at the UDR.
[0336] resetlds array(string) 0 1..N If present, it contains the list of Reset-IDs of those UEs potentially subject to a data-loss event at the UDR.
[0337] sNssaiList array(Snssai) 0 1..N If present, it contains the list of slices (S-NSSAIs) potentially subject to a data-loss event at the UDR. dnnList array(Dnn) 0 1..N If present, it contains the list of DNNs potentially subject to a data-loss event at the UDR. lastReplicationTim DateTime 0 0..1 If present, it contains the timestamp e of the most recent instant when the data was assumed to be consistent at UDR (i.e. the potential data loss event at UDR did not occur before this instant). In the case of subscriber data migration procedure, this value indicates the time when a UDR started subscriber data migration.
[0338]
[0339] P113042WG01
[0340] 29
[0341] recoveryTime DateTime 0 0..1 If present, it contains the timestamp of the instant when the potential data loss event was recovered at UDR (i.e. all data records stored by UDR after this time are assumed to be consistent). In the case of subscriber data migration procedure, this value indicates the time when traffic switch was enforced for a subscriber data migration procedure (e.g. the NFProfile update into NRF). udrGroupId NfGroupId 0 0..1 If present, it contains the ID of the UDR Group whose UEs have been potentially subject to a data loss event at the UDR. rediscoverylnd boolean 0 0..1 If present with value true, UDR rediscovery is required due to subscriber reallocation in a different UDR group Id.
[0342] Default: false. noResynchronizati Boolean C 0..1 If present, it indicates whether data onRequired resynchronization is required. It shall only be present when rediscoverylnd is present and set to true.
[0343] - true: data resynchronization is not required
[0344] false (default): data resynchronization is required UdmDataToResyn array(UdmData 0 1..N If present, it indicates the data that is c ToResynchroniz required to resynchronize from UDM e) consumers.
[0345]
[0346] P113042W001
[0347] 30
[0348] The following relates to yet another aspect of the present disclosure.
[0349] To subscribe to event notifications, the NF service consumer shall send an HTTP POST request with: "{apiRoot} / nsmf-event-exposure / v1 / subscriptions" as Resource URI and the NsmfEventExposure data structure as request body that shall include:
[0350] if the subscription applies to events related to a single PDU session for a UE, the PDU Session ID of that PDU session as "pduSeld" attribute and the UE identification as "supi" or "gpsi" attribute;
[0351] if the subscription applies to events not related to a single PDU session, the Network Function instance identity if "UPEAS" feature is supported and the "eventSubs" attribute contains an entry with the "event" set to the value "UPF_EVENT", and identification of UEs to which the subscription applies via:
[0352] a) identification of a single UE by SUPI as "supi" attribute or GPSI as "gpsi" attribute;
[0353] b) identification of a group of UE(s) via a "groupld" attribute; or
[0354] c) identification of any UE via the "anyUelnd" attribute set to true;
[0355] NOTE 1: The identification of any UE does not apply for local breakout roaming scenarios where the SMF is located in the VPLMN and the NF service consumer is located in the HPLMN.
[0356] an URI where to receive the requested notifications as "notifUri" attribute; a Notification Correlation Identifier provided by the NF service consumer for the requested notifications as "notifld" attribute; and
[0357] if the NF service consumer is an AMF, the GUAMI encoded as "guami" attribute:
[0358] a description of the subscribed events as "eventSubs" attribute that for each event shall include:
[0359] a) an event identifier as "event" attribute; and
[0360] b) for event "UP_PATH_CH", whether the subscription is for early, late, or early and late notifications of UP path reconfiguration in the "dnaiChgType" attribute; c) for event "DDDS", the traffic descriptor(s) of the downlink data source in the "dddTraDescriptors" attribute;
[0361] and that may include:
[0362] a) for event "DDDS", the subscribed delivery statuses in the "dddStati" attribute;
[0363] b) for event "QFI_ALLOC" or "DISPERSION", the application identifiers in the "applds" attribute;P113042WQ01
[0364] 31
[0365] c) for event "SMCC_EXP", the data collection target period in the "targetPeriod" attribute;
[0366] d) for event "DISPERSION", the UE IP Address in the "uelpAddr" attribute, the indication of transaction dispersion collection in the "transacDispInd" attribute and the requested transaction metrics in the "transacMetrics" attribute;
[0367] e) for event "WLAN_INFO", the data collection target period in the "targetPeriod" attribute;
[0368] f) for event "RED_TRANS_EXP", the data collection target period in the "targetPeriod" attribute;
[0369] g) for event "UPF_EVENT", the UPF event exposure information in the "upfEvents" attribute; and / or
[0370] h) for event "QOS_MON", the Application Identifier in the "applds" of the application for which the QoS flows are to be monitored and an indication within the "defQosSupp" attribute to inform whether the NF service consumer supports to receive QoS Flow performance information for the QoS Flow associated with the default QoS rule if there are no measurements available for the provided Application Identifier included within the "applds" attribute.
[0371] NOTE 2: Explicit subscription to "UPF_EVENT" and "QOS_MON" events as described in this clause implies the direct notification from the UPF as specified in 3GPP TS 29.564
[0026] ,
[0372] The NsmfEventExposure data structure as request body may also include:
[0373] if the NF service consumer is an AMF:
[0374] a) the name of a service produced by the AMF that expects to receive the notifications about subscribed events encoded as "serviceName" attribute;
[0375] b) Alternate or backup IPv4 Address(es) where to send Notifications encoded as "altNotiflpv4Addrs" attribute;
[0376] c) Alternate or backup IPv6 Address(es) where to send Notifications encoded as "altNotiflpv6Addrs" attribute;
[0377] d) Alternate or backup FQDN(s) where to send Notifications encoded as "altNotifFqdns" attribute;
[0378] a Data Network Name as "dnn" attribute;
[0379] a single Network Slice Selection Assistance Information as "snssai" attribute;
[0380] an identification of network area by "networkArea" attribute, if the feature AreaFilter or the feature UPEAS is supported and the "anyUelnd" attribute is provided and set to true;P113042W001
[0381] 32
[0382] NOTE 3: Care needs to be taken with regards to load and major signalling caused when requesting Any UE. This could be achieved via utilization of some event filters (e.g. Area of Interest), a specific DNN, S-NSSAI or sampling ratio as part of Event Reporting Information.
[0383] a Data Network Identifier as "dnai" attribute, if the feature LIPEAS is supported;
[0384] the SSI D that the PDU session is related to as "ssid" attribute, if the feature LIPEAS is supported;
[0385] the BSSID that the PDU session is related to as "bssid" attribute, if the feature UPEAS is supported;
[0386] the UPF identifier as "upfld" attribute, if the feature UPEAS is supported; immediate reporting flag as "ImmeRep" attribute;
[0387] NOTE 4: For the "PDU_SES_EST" event subscription, the "ImmeRep" attribute needs to be included to enable the SMF to report the current available "PDU_SES_EST" event information for the subscribed PDU Session which is already established.
[0388] event notification method (periodic, one time, on event detection) as "notifMethod" attribute;
[0389] maximum Number of Reports as "maxReportNbr" attribute; monitoring Duration as "expiry" attribute;
[0390] repetition Period for periodic reporting as "repPeriod" attribute; sampling ratio as "sampRatio" attribute;
[0391] partitioning criteria for partitioning the UEs before performing sampling as "partitioncriteria" attribute if the EneNA feature is supported; and / or
[0392] group reporting guard time as "grpRepTime" attribute;
[0393] a notification flag as "notifFlag" attribute if the EneNA feature is supported; notification muting exception instructions within the "notifFlaglnstruct" attribute, if the EnhDataMgmt feature is supported and the "notifFlag" attribute is provided and set to "DEACTIVATE"; and / or
[0394] if the EnUPEAS feature is supported, the UPF event remaining data reporting indication as "remainRepInd" attribute for UPF relocation and PDU session release.
[0395] UDR Restart Indication, informing the subscription is due to a UDR data restoration, and the requested EE subscription may already exist in the SMF.P113042WQ01
[0396] 33
[0397] Upon the reception of an HTTP POST request with: "{apiRoot} / nsmf-event-exposure / v1 / subscriptions" as Resource URI and NsmfEventExposure data structure as request body, the SMF shall:
[0398] create a new subscription, except if the UDR Restart Indication is present and the corresponding EE subscription already exists;
[0399] assign a subscription correlation ID;
[0400] select an expiry time that is equal to or less than the expiry time potentially received in the request;
[0401] store the subscription;
[0402] if the feature "UPEAS" is supported, and if the NF service consumer subscribed to "QOS_MON" event, the SMF shall check if there is an active PCC rule that includes a Data Collection Application Identifier as described in 3GPP TS 29.512
[0014] that matches the Application Identifier received within "applds" attribute. If there is an active PCC rule, the SMF shall allow the NF service consumer to receive QoS monitoring reports enabled by that PCC rule. If no PCC rule is identified and the "defQosSupp" attribute was received and set to true, the SMF may instruct the UPF to perform QoS monitoring for the QoS Flow associated to the default QoS rule as described in 3GPP TS 29.244
[0023] , If no PCC rule is identified and the "defQosSupp" attribute was received and set to false or not received, the SMF may, based on local configuration, reject the request by sending the NO_ACTIVE_PCC_RULE error described in clause 5.7 or include the "qosMonPending" indication set to true in the response to inform the NF service consumer that the reporting will be activated when the measurements are enabled by a PCC rule;
[0403] NOTE 5: The reporting can be activated when a new PCC rule is installed or an existing one is modified with QoS monitoring information that includes the Data Collection Application Identifier related to the subscription. In this case the SMF will act as if the new subscription is received from the NF service consumer.
[0404] if the feature "UPEAS" is supported and the "upfEvents" attribute is provided together with the "networkArea" attribute in the Eventsubscription data type, the SMF shall subscribe to the UPF for the respective UPF events as described in 3GPP TS 29.564
[0026] only when the UE is located in the indicated area. When the UE leaves the indicated area, the SMF shall unsubscribe those events from the UPF as described in 3GPP TS 29.564
[0026] ,
[0405] NOTE 6: To know when a UE enters or leaves the indicated area, the SMF can subscribe to the respective AMF Event Exposure event.P113042W001
[0406] 34
[0407] send an HTTP "201 Created" response with NsmfEventExposure data structure as response body and a Location header field containing the URI of the created individual subscription resource, i.e. "{apiRoot} / nsmf-event-exposure / v1 / subscriptions / {subld}"; if the feature "ERIR" is not supported, and if the "ImmeRep" attribute is included and set to true in the request, the SMF shall immediately notify the recipient of notification(s) subscribed in the "notifllri" attribute of the current available value(s) using the Nsmf_EventExposure_Notify service operation, as defined in clause 4.2.2.1;
[0408] if the feature "ERIR" is supported, and if the "ImmeRep" attribute is included and set to true, the SMF may immediately notify the NF service consumer with the current available value(s) for the subscribed event(s) within the HTTP "201 Created" response as shown in figure 4.2.3.2-1, step 2. The "NsmfEventExposure" data type in the response may include the corresponding event(s) notification within the "eventNotifs" attribute. if the sampling ratio attribute, as "sampRatio", is included in the subscription without a "partitioncriteria" attribute, the SMF shall select a random subset of UEs among the target UEs according to the sampling ratio and only report the event(s) related to the selected subset of UEs. If the "partitioncriteria" attribute is additionally included, then the SMF shall first partition the UEs according to the value of the "partitioncriteria" attribute and then select a random subset of UEs from each partition according to the sampling ratio and only report the event(s) related to the selected subsets of UEs;
[0409] when the group reporting guard time attribute, as "grpRepTime", is included in the subscription, the SMF shall accumulate all the event reports for the target UEs until the group reporting guard time expires. Then the SMF shall notify the NF service consumer using the Nsmf_EventExposure_Notify service operation, as described in clause 4.2.2.2; and
[0410] if the "notifFlag" attribute is included and set to "DEACTIVATE" in the request, the SMF shall mute the event notification and store the available events until the NF service consumer requests to retrieve them by setting the "notifFlag" attribute to "RETRIEVAL" or until a muting exception occurs (e.g. full buffer). When a muting exception occurs, the SMF may consider the contents of the "notifFlaglnstruct" attribute (if provided) and / or local configuration to determine its actions. If the EnhDataMgmt feature is supported and the SMF accepts the muting instructions provided in the "notifFlag" and / or the "notifFlaglnstruct" attributes, it may indicate the applied muting notification settings within the "mutingSetting" attribute in the response. If the SMF does not accept the muting instructions provided in the "notifFlag" and / or the "notifFlaglnstruct" attributes, it shall send an HTTP "403 Forbidden" error response including the "cause" attribute set to "MUTING_INSTR_NOT_ACCEPTED".P113042W001
[0411] 35
[0412] If the SMF received an GlIAMI, the SMF may subscribe to GlIAMI changes using the AMFStatusChange service operation of the Namf_Communication service specified in 3GPP TS 29.518
[0013] , and it may use the Nnrf_NFDiscovery Service specified in 3GPP TS 29.510
[0012] (using the obtained GLIAMI and possibly service name) to query the other AMFs within the AMF set.
[0413] If errors occur when processing the HTTP POST request, the SMF shall send an HTTP error response as specified in clause 5.7.
[0414] The following table defines the type NsmfEventExposure
[0415] Attribute name Data type P Cardi Description
[0416] nality
[0417] supi Supi C 0..1 Subscription Permanent Identifier (NOTE 1) (NOTE 8)
[0418] gpsi Gpsi C 0..1 Generic Public Subscription Identifier (NOTE 1) (NOTE 8) This IE is not applicable to "SMCC_EXP" event.
[0419] anyllelnd boolean c 0..1 This IE shall be present if the event subscription is applicable to any UE. It indicates whether the event subscription is applicable to any UE: - "true": the event subscription is applicable to any UE;
[0420] "false"(default): the event subscription is not applicable to any UE.
[0421] (NOTE 1) (NOTE 4) (NOTE 7) groupld Groupld c 0..1 Identifies a group of UEs. (NOTE 1) pduSeld PduSessionld c 0..1 PDU session ID (NOTE 1) dnn Dnn 0 0..1 Data Network Name.
[0422] snssai Snssai 0 0..1 A single Network Slice Selection Assistance Information. (NOTE 4) dnai Dnai 0 0..1 Data network access identifier. ssld string 0 0..1 SSID that the PDU session is related to.
[0423]
[0424] P113042W001
[0425] 36
[0426] bssld string 0 0..1 BSSID that the PDU session is related to.
[0427] upfld string 0 0..1 Identifies the UPF.
[0428] nfld Nflnstanceld C 0..1 Indicates the instance identity of the NF creating the subscription. It shall be provided if the "eventSubs" attribute contains an entry with the "event" set to the value "UPF_EVENT".
[0429] subld Subld C 0..1 Subscription ID.
[0430] This parameter shall be supplied by the SMF in HTTP responses that include an object of NsmfEventExposure type. notifld string M 1 Notification Correlation ID provided by the NF service consumer. (NOTE 2)
[0431] notifllri Uri M 1 Identifies the recipient of Notifications sent by the SMF. altNotiflpv4Addrs array(lpv4Add 0 1..N Alternate or backup IPv4 r) Address(es) where to send Notifications.
[0432] altNotiflpv6Addrs array(lpv6Add 0 1..N Alternate or backup IPv6 r) Address(es) where to send Notifications.
[0433] altNotifFqdns array(Fqdn) 0 1..N Alternate or backup FQDN(s) where to send Notifications. eventSubs array(EventSu M 1..N Subscribed events. (NOTE 4)
[0434] bscri ption)
[0435] eventNotifs array(EventN 0 1..N Represents the SMF Events to be otification) reported in the Nsmf_EvenExposure_Subscribe response.
[0436] May be present when the "ERIR" feature is supported and the
[0437]
[0438] P113042W001
[0439] 37
[0440] "ImmeRep" attribute set to true is included in the subscription request. ImmeRep boolean 0 0..1 Indicates whether immediate reporting of the current status of the subscribed event.
[0441] Set to "true": it is requested that the current status of the subscribed event is immediately reported.
[0442] Set to "false": the current status of the subscribed event is not requested to be immediately reported.
[0443] Default value is "false" if omitted.
[0444] (NOTE 6)
[0445] notifMethod NotificationMe 0 0..1 If "notifMethod" is not supplied, the thod default value "ON_EVENT_DETECTION" applies.
[0446] (NOTE 4) (NOTE 5) maxReportNbr Uinteger 0 0..1 If omitted, there is no limit.
[0447] (NOTE 4) (NOTE 5)
[0448] expiry DateTime C 0..1 This attribute indicates the expiry time of the subscription, after which the SMF shall not send any event notifications and the subscription becomes invalid. It may be included in an event subscription request and may be included in an event subscription response based on operator policies. If an expiry time
[0449]
[0450] P113042W001
[0451] 38
[0452] was included in the request, then the expiry time returned in the response should be less than or equal to that value. If the expiry time is not included in the response, the NF service consumer shall not associate an expiry time for the subscription.
[0453] (NOTE 4)
[0454] repPeriod DurationSec C 0..1 This attribute indicates the reporting period. Shall be provided if the notification method is set to "PERIODIC".
[0455] guami Guami C 0..1 The Globally Unique AMF Identifier (GUAMI) shall be provided by an AMF as NF service consumer. serviceName ServiceName 0 0..1 If the NF service consumer is an AMF, it should provide the name of a service produced by the AMF that makes use of the notification about subscribed events. supportedFeatures SupportedFea C 0..1 List of Supported features used as tures described in clause 5.8.
[0456] This parameter shall be supplied by NF service consumer and SMF in the POST request that request the creation of an SMF Notification Subscriptions resource and the related reply, respectively. sampRatio SamplingRati 0 0..1 Indicates the ratio of the random 0 subset to target UEs, event reports only relates to the subset. partitioncriteria array(Partition 0 1..N Defines criteria for partitioning the ingCriteria) UEs in order to apply the sampling
[0457]
[0458] P113042W001
[0459] 39
[0460] ratio for each partition. It may only be included in event subscription requests when the "sampRatio" attribute is also provided. (NOTE 3) grpRepTime DurationSec 0 0..1 Indicates the time for which the SMF aggregates the event reports detected by the UEs in a group and report them together to the NF service consumer.
[0461] notifFlag NotificationFla 0 0..1 Indicates the notification flag, which g is used to mute / unmute notifications and to retrieve events stored during a period of muted notifications. Default: "ACTIVATE" notifFlaglnstruct MutingExcepti 0 0..1 Contains instructions to be executed onlnstructions upon the occurrence of an event muting exception (e.g. full buffer). It may only be provided if the "notifFlag" is provided and set to "DEACTIVATE". mutingSetting MutingNotifica 0 0..1 Contains settings related to the tionsSettings muting of notifications. It may only be provided in the NF service producer response and only if the muting instructions provided in the "notifFlag" and / or the "notifFlaglnstruct" attributes are accepted.
[0462] defQosSupp boolean 0 0..1 Indicates whether the NF service consumer requests to receive QoS Flow performance information for the QoS Flow associated with the default QoS rule if there are no measurements available for the provided Application Identifier
[0463]
[0464] P113042WQ01
[0465] 40
[0466] included within the "applds" attribute.
[0467] Set to "true": NF service consumer requests to receive QoS Flow performance information for the QoS Flow associated with the default QoS rule.
[0468] Set to "false": NF service consumer does not request to receive QoS Flow performance information for the QoS Flow associated with the default QoS rule.
[0469] Default value is "false" if omitted.
[0470] qosMonPending boolean 0 0..1 Indicates whether the reporting will be activated when the measurements are enabled by a PCC rule.
[0471] Set to "true": the reporting will be activated when the measurements are enabled by a PCC rule.
[0472] It shall be always set to "true" when present.
[0473] It may only be provided in the response.
[0474] remainRepInd boolean 0 0..1 Indicates whether the source UPF should send the remaining collected UPF event data to the NF service consumer during UPF relocation and PDU Session release.
[0475]
[0476] P113042W001
[0477] 41
[0478] (NOTE 8)
[0479] Set to "true": the source UPF should send the collected data to the NF service consumer.
[0480] Set to "false": the source UPF should not send the collected data to the NF service consumer.
[0481] Default value is "false" if omitted.
[0482] udrRestartlnd boolean 0 0..1 May be present in EE subscribe messages from the UDM.
[0483] If present:
[0484] - true: indicates that the subscription message sent by the UDM is due to UDR data restoration. Therefore, the EE subscription context may already exist in the SMF.
[0485] - false (or absent): indicates that this is a normal subscription message (i.e., not motivated by a UDR data restoration).
[0486]
[0487] The following is another example of the present disclosure.
[0488] The Subscribe service operation is invoked by a NF Service Consumer, e.g. NEF, towards the AMF, when it needs to create a subscription to monitor at least one event relevant to the AMF. The NF Service Consumer may subscribe to multiple events in a subscription. A subscription may be associated with one UE, a group of UEs or any UE. The NF Service Consumer shall request to create a new subscription by using HTTP method POST with the URI of the subscriptions collection or the URI of the AMF Set level bulk subscription collection, see clauses 6.2.3.2 and 6.2.3.4.P113042W001
[0489] 42
[0490] The NF Service Consumer shall include the following information in the HTTP message body:
[0491] NF ID, indicates the identity of the network function instance initiating the subscription;
[0492] Subscription Target, indicates the target(s) to be monitored, as one of the following types:
[0493] A specific UE, identified with a SlIPI, a PEI or a GPSI;
[0494] A group of UEs, identified with a group identity;
[0495] Any UE, identified by the "anyUE" flag.
[0496] Notification URI, indicates the address to deliver the event notifications generated by the subscription;
[0497] Notification Correlation ID, indicates the correlation identity to be carried in the event notifications generated by the subscription;
[0498] List of events to be subscribed;
[0499] Event Types per event, as specified in clause 5.3.1.
[0500] The NF Service Consumer may include the following information in the HTTP message body:
[0501] Immediate Report Flag per event, indicates an immediate report to be generated with current event status;
[0502] Event Trigger, indicates how the events shall be reported (One-time Reporting or Continuously Reporting).
[0503] Maximum Number of Reports, defines the maximum number of reports after which the event subscription ceases to exist;
[0504] Expiry, defines maximum duration after which the event subscription ceases to exist;
[0505] Sampling ratio, defines the random subset of UEs among target UEs, and AMF only report the event(s) related to the selected subset of UEs;
[0506] partitioning criteria, that defines Criteria for partitioning UEs before applying sampling ratio;
[0507] Periodic Report Flag per event, indicates the report to be generated periodically; Repetition Period, defines the period for periodic reporting;
[0508] Variable reporting periodicity information, defines the list of conditions related to Reporting periodicity and the period per condition.
[0509] Event Filters per applicable event, defines further options on when / how the event shall be reported;P113042W001
[0510] 43
[0511] Reference Id per event, indicates the value of the Reference Id associated with the event to be monitored. If provided, the Reference Id shall be included in the reports triggered by the event;
[0512] a notification flag as "notifFlag" attribute if the EneNA feature is supported;
[0513] Muting Exception Instructions, which specify instructions to apply to the subscription and the stored events when an exception occurs at the AMF while the event is muted (e.g., the buffer of stored event reports is full, or the number of stored event reports exceeds a certain number), if the ENAPH3 feature is supported (see clause 6.2.8); and / or
[0514] UE positioning capabilities requested indication.
[0515] UDR Restart Indication, informing the subscription is due to a UDR data restoration, and the requested EE subscription may already exist in the AMF.
[0516] NOTE: Apart from the aspects specified in clause 5.3.1.4, the functional behavior and contents of messages exchanged for an AMF Set level Bulk Subscription are the same as for bulk subscriptions applying only to a specific AMF instance.
[0517] 1. The NF Service Consumer shall send a POST request to create a subscription resource in the AMF. The content of the POST request shall contain a representation of the individual subscription resource to be created. The request may contain an expiry time, suggested by the NF Service Consumer as a hint, representing the time upto which the subscription is desired to be kept active and the time after which the subscribed event(s) shall stop generating report. If the UDR Restart Indication is included the subscription resource may already exist in the AMF and a new creation shall be avoided.
[0518] 2a. On success, the request is accepted, the AMF shall include a HTTP Location header to provide the location of a newly created resource (subscription) together with the status code 201 indicating the requested resource is created in the response message. If the NF Service Consumer has included more than one events in the event subscription and some of the events are failed to be subscribed, the AMF shall accept the message and provide the successfully subscribed event(s) in AmfEventSubscription. If the NF Service Consumer has included the immediateFlag with value as "true" in the event subscription, the AMF shall include the current status of the events subscribed, if available (e.g. last known location information is included if the subscribed event is LOCATION_REPORT). If the events with immediateFlag set to "true" are subscribed by an NF service consumer on behalf of a third NF and the NF service consumer has not indicated supporting of IERSR feature (see 6.2.8), the notification will be sent to the thirdP113042W001
[0519] 44
[0520] NF directly, i.e. subsChangeNotifyllri is included in the event subscription, the current status of the events subscribed shall not be included in response. The AMF shall subsequently send a notification to the third NF including the current status of the events subscribed.
[0521] If the NF Service Consumer has set the event reporting option as ONE_TIME and if the AMF has included the current status of the events subscribed in the response, then the AMF shall not do any subsequent event notification for the events given in the AmfCreateEventSubscription parameter. If the NF Service Consumer has set the event reporting option as ONE_TIME, the subscribed event as LOCATION_REPORT and the immediateFlag is set to false or absent, the AMF shall send an event notification to notify the current location of the UE after the subscription; if the UE is in RM-REGISTERED and CM-IDLE state over 3GPP access and the UE does not respond to the paging, or if the UE is in RM-REGISTERED over non-3GPP access, the event notification shall include the last known location and the ageOfLocationlnformation IE set to a value other than "0", which indicates to the NF service consumer that the AMF returned the last known location.
[0522] If the NF Service Consumer has set the CONTINUOUS or PERIODIC event reporting option, the subscribed event as LOCATION_REPORT and the immediateFlag is set to false or absent, the AMF shall send a first event notification to notify the current location of the UE after the subscription is created and then subsequent event notifications when the user location changes or according to the requested period respectively; if at the time of the subscription creation the UE is in RM-REGISTERED and CM-IDLE state over 3GPP access and the UE does not respond to the paging, or if the UE is in RM-REGISTERED over non-3GPP access, the AMF shall send the first event notification including the last known location and the ageOfLocationlnformation IE set to a value other than "0", which indicates to the NF service consumer that the AMF returned the last known location.
[0523] The response, based on operator policy and taking into account the expiry time included in the request, may contain the expiry time, as determined by the AMF, after which the subscription becomes invalid. Once the subscription expires, if the NF Service Consumer wants to keep receiving notifications, it shall create a new subscription in the AMF. The AMF shall not provide the same expiry time for many subscriptions in order to avoid all of them expiring and recreating the subscription at the same time. If the expiry time is not included in the response, the NF Service Consumer shall consider the subscription to be valid without an expiry time.P113042W001
[0524] 45
[0525] If the sampling ratio ("sampRatio") attribute is included in the subscription without a partitioningCriteria, the AMF shall select a random subset of UEs among target UEs according to the sampling ratio and only report the event(s) related to the selected subset of UEs. If the partitioningCriteria attribute is also included along with sampling ratio, the AMF shall apply the sampling ratio on the group of UEs determined according to the partitioning criteria.
[0526] If the AMF supports the EneNA feature and the "notifFlag" attribute is included and set to "DEACTIVATE" in the request (by e.g. the NWDAF or DCCF), the AMF shall mute the event notification and store the available events. Additionally, if the AMF also supports the ENAPH3 feature (see clause 6.2.8) and the NF service consumer also included event muting instructions in the request, the AMF should evaluate the received event muting instructions against to local actions (if configured) and, if the subscription creation request is accepted, the AMF may indicate the following information to the NF service consumer in the response:
[0527] the maximum number of notifications that the AMF expects to be able to store for the subscription;
[0528] an estimate of the duration for which notifications can be buffered.
[0529] If the NF service consumer is a UDM, the AMF and the UDM both support the "ESSYNC" feature and the subscription is targeting a specific UE with Reference ld(s) included in the subscription, the AMF shall locally store the information that the event subscription is subject to the Event Subscription Synchronization with UDM during EPS to 5GS mobility as specified in clause 5.3.2.4.2. During inter-AMF mobility procedures, the source AMF shall include the "eventSyncInd" IE (in AmfEventSubscriptionAddlnfo data type) with the value "true" in the UE Context for the event subscriptions that are subject to Event Subscription Synchronization with UDM.
[0530] If the subscription creation request targets a group of U E or any U E, the AM F shall accept the request and create a subscription even if the AMF does not currently serve any UE of the group or any UE respectively, unless other reasons exist to reject the request. 2b. On failure or redirection, one of the HTTP status codes listed in Table 6.2.3.2.3.1-3 shall be returned. For a 4xx / 5xx response, the message body shall contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in Table 6.2.3.2.3.1-3.
[0531] If the subscription creation request targets a specific UE and this UE is not served by the AMF (i.e. it is not known to the AMF), the AMF shall reject the request with a 403 Forbidden response and the application error "UE_NOT_SERVED_BY_AMF", unless theP113042W001
[0532] 46
[0533] request can be redirected to another AMF known to serve the UE (e.g. another AMF of the same AMF set).
[0534] If the AMF supports the EneNA and ENAPH3 features (see clause 6.2.8), the NF service consumer sets the "notifFlag" attribute to "DEACTIVATE" and event muting instructions in the request, but the AMF cannot accept the received instructions, the AMF may reject the request with a 403 Forbidden response and the application error "MUTING_EXC_INSTR_NOT_ACCEPTED".
[0535] The following table defines the AmfCreateEventSubscription
[0536] Attribute name Data type P Cardinali Description
[0537] ty
[0538] subscription AmfEventSubscr M 1 Represents the AMF Event Subscription iption resource to be created. supportedFeatures SupportedFeatur C 0..1 This IE shall be present if at least one es feature defined in clause 6.2.8 is supported.
[0539] oldGuami Guami C 0..1 This IE shall be present during an AMF planned removal procedure when the NF Service Consumer initiates a request towards the target AMF, for a UE associated to an AMF that is unavailable (see clause 5.21.2.2 of 3GPP TS 23.501 [2]).
[0540] udrRestartlnd boolean 0 0..1 May be present in EE subscribe messages from the UDM.
[0541] If present:
[0542] - true: indicates that the subscription message sent by the UDM is due to UDR data restoration. Therefore, the EE subscription context may already exist in the AMF.
[0543] - false (or absent): indicates that this is a normal subscription message (i.e. not motivated by a UDR data restoration).
[0544]
[0545] P113042W001
[0546] 47
[0547] As noted above, particular terminology used when describing certain features or aspects of the technology should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects of the technology with which that terminology is associated. In general, the terms used in the following claims should not be construed to limit the technology to the specific examples disclosed in the specification, unless the Detailed Description section explicitly defines such terms. Accordingly, the actual scope of the technology encompasses not only the disclosed examples, but also all equivalent ways of practicing or implementing the technology under the claims
Claims
P113042WG0148CLAIMS1. A method of restoring data at a Unified Data Repository, UDR, in a telecommunication network, wherein said UDR stores one or more data sets, wherein each of said plurality of data sets comprises a plurality of data records, wherein said method comprises the steps of:determining (401, 501), by said UDR, a need to restore a specific data record within said one or more data sets in said UDR;requesting (503), by said UDR, restoration of data, wherein said requesting comprises an identification of said specific data record within said one of said plurality of data sets in said UDR;receiving (506), by said UDR, said specific data record.
2. A method in accordance with claim 1, wherein said one or more data sets comprise any of:Subscription data;Policy Data;Structured Data for exposure;Application Data.
3. A method in accordance with any of the previous claims, wherein profiles comprise a collection of data records that are associated to corresponding User Equipment, UE, in said telecommunication network, wherein said requesting comprises an identifier for identifying a set of profiles for which said specific data record is to be restored.
4. A method in accordance with claim 3, wherein said identifier for identifying said set of profiles for which said specific data record is to be restored comprises any of:Reset-Identification;Subscription Permanent Identifier or Generic Public Subscription Identifier ranges;Data Network Names or Single Network Slice Selection Assistance Information;UDR or UDM Group Identification;Public Land Mobile Network Identifier Identification, PLMN ID, of the UDR.P113042W001495. A method in accordance with any of the previous claims, wherein said one or more data sets comprises a plurality of data records organized in a hierarchy.
6. A method in accordance with claim 4, wherein said identification of said specific data record within said one of said one or more data sets in said UDR comprises any of: / context- data; / ee-subscriptions; / amf- subscriptions; / smf-subscriptions; / hss- subscriptions; / amf-3gpp-access; / smf-registrations; / smsf-3gpp-access.
7. A method in accordance with any of the previous claims, wherein said identification of said specific data record comprises any of:an identification of any of an Access Management Function, AMF, Session Management Function, SMF, a Short Message Service Function, SMSF, or a Network Exposure Function, NEF.
8. A method of supporting restoration of data at a Unified Data Repository, UDR, by a Unified Data Management, UDM, in a telecommunication network, wherein said UDR stores one or more data sets, wherein each of said one or more data sets comprises a plurality of data records, wherein said method comprises the steps of:determining (601, 602), by said UDM, a need to restore a specific data record within said one or more data sets in said UDR;transmitting (603), by said UDM, a request for restoring data, wherein said request comprises an identification of said specific data record within said one or more data sets in said UDR.
9. A method in accordance with claim 8, wherein said step of determining comprises:receiving, by said UDM, from said UDR, said a request for restoring data, wherein said request comprises an identification of said specific data record within said one or more data sets in said UDR.P113042WG015010. A method in accordance with any of the claims 8 - 9, wherein said step of transmitting comprises:transmitting, by said UDM, said request for restoring data to a Network Exposure Function, NEF, in said telecommunication network.
11. A method in accordance with any of the claims 8 - 10, wherein profiles comprise a collection of data records that are associated to corresponding User Equipment, UE, in said telecommunication network, wherein said request comprises an identifier for identifying a set of profiles for which said specific data record is to be restored.
12. A method in accordance with any of the claims 8 - 11, wherein said identifier for identifying a set of profiles for which said specific data record is to be restored comprises any of:Reset-Identification;Subscription Permanent Identifier or Generic Public Subscription Identifier ranges;Data Network Names or Single Network Slice Selection Assistance Information;UDR or UDM Group Identification;Public Land Mobile Network Identifier Identification, PLMN ID, of the UDR.
13. A method in accordance with any of the claims 8 - 12, wherein each of said one or more data sets comprises a plurality of data records organized in a hierarchy.
14. A method in accordance with claim 13, wherein said identification of said specific data record within said one of said plurality of data sets in said UDR comprises any of: / context- data; / ee-subscriptions; / amf- subscriptions; / smf-subscriptions; / hss- subscriptions; / amf-3gpp-access; / smf-registrations; / smsf-3gpp-access.P113042WG015115. A method of supporting restoration of data at a Unified Data Repository, UDR, in a telecommunication network, wherein said UDR stores a one or more data sets, wherein each of said one or more data sets comprises a plurality of data records, wherein said method comprises the steps ofreceiving (603), by a Network Exposure Function, NEF, a request for restoring data, wherein said request comprises an identification of said specific data record within said one or more data sets in said UDR;controlling, by said NEF, that said requested specific data record is restored at said UDR.
16. A method in accordance with claim 15, wherein said step of controlling comprises any of:transmitting, by said NEF, to said UDR, said requested specific data record;transmitting, by said NEF, to an Application Function, AF, in said telecommunication network, a request for restoring data, wherein said request comprises an identification of said specific data record;marking, by said NEF, said specific data record as to be restored.
17. A method in accordance with any of the previous claims 15 - 16, wherein profiles comprise a collection of data records that are associated to corresponding User Equipment, UE, in said telecommunication network, wherein said request comprises an identifier for identifying a set of profiles for which said specific data record is to be restored.
18. A method in accordance with any of the previous claims 15 - 17, wherein said identifier for identifying a set of profiles for which said specific data record is to be restored is any of:Reset-Identification;Subscription Permanent Identifier or Generic Public Subscription Identifier ranges;Data Network Names or Single Network Slice Selection Assistance Information;UDR or UDM Group Identification;Public Land Mobile Network Identifier Identification, PLMN ID, of the UDR.P113042W0015219. A method in accordance with any of the claims 15 - 18, wherein each of said one or more data sets comprises a plurality of data records organized in a hierarchy.
20. A method in accordance with any of the claims 17 - 19, wherein said identification of said specific data record within said one of said plurality of data sets in said UDR comprises any of: / context- data; / ee-subscriptions; / amf- subscriptions; / smf-subscriptions; / hss- subscriptions; / amf-3gpp-access; / smf-registrations; / smsf-3gpp-access.
21. A method of supporting restoration of data at a Unified Data Repository, UDR, in a telecommunication network, wherein said UDR stores one or more data sets, wherein each of said one or more data sets comprises a plurality of data records, said method comprising the steps of:receiving, by any of a Network Function, NF, in said telecommunication network, an identification of said specific data record within said one or more data sets in said UDR to be restored;transmitting, by said NF, said identification of said specific data record within said one or more of said data sets in said UDR to be restored.
22. A method in accordance with claim 21, wherein said NF is any of an Application Function, AF, a Session Management Function, SMF, or an Application Management Function.
23. A method in accordance with any of the claims 21 - 22, wherein profiles comprise a collection of data records that are associated to corresponding User Equipment, UE, in said telecommunication network, wherein said request comprises an identifier for identifying a set of profiles for which said specific data record is to be restored.P113042WG015324. A method in accordance with any of the claims 21 - 23, wherein said identifier for identifying a set of profiles for which said specific data record is to be restored is any of:Reset-Identification;Subscription Permanent Identifier or Generic Public Subscription Identifier ranges;Data Network Names or Single Network Slice Selection Assistance Information;UDR or UDM Group Identification;Public Land Mobile Network Identifier Identification, PLMN ID, of the UDR.
25. A method in accordance with any of the claims 21 - 24, wherein each of said plurality of data sets comprises a plurality of data records organized in a hierarchy.
26. A method in accordance with claim 25, wherein said identification of said specific data record within said one of said plurality of data sets in said UDR comprises any of: / context- data; / ee-subscriptions; / amf- subscriptions; / smf-subscriptions; / hss- subscriptions; / amf-3gpp-access; / smf-registrations; / smsf-3gpp-access.
27. A Unified Data Repository, UDR, arranged for operating in a telecommunication network, said UDR comprising a processing circuitry and a memory, wherein said processing circuitry is arranged to perform a method in accordance with any of the claims 1 - 7.
28. A Unified Data Management, UDM, arranged for operating in a telecommunication network, said UDR comprising a processing circuitry and a memory, wherein said processing circuitry is arranged to perform a method in accordance with any of the claims 8 - 14.P113042W0015429. A Network Exposure Function, NEF, arranged for operating in a telecommunication network, said UDR comprising a processing circuitry and a memory, wherein said processing circuitry is arranged to perform a method in accordance with any of the claims 15 - 20.
30. A Network Function, NF, arranged for operating in a telecommunication network, said UDR comprising a processing circuitry and a memory, wherein said processing circuitry is arranged to perform a method in accordance with any of the claims 21 - 26.