WO2022121772A1

WO2022121772A1 - Data disaster recovery backup method, and unified data management (udm) entity and storage medium

Info

Publication number: WO2022121772A1
Application number: PCT/CN2021/135100
Authority: WO
Inventors: 魏伟
Original assignee: 中兴通讯股份有限公司
Priority date: 2020-12-10
Filing date: 2021-12-02
Publication date: 2022-06-16
Also published as: CN114625565A

Abstract

A data disaster recovery backup method, and a unified data management (UDM) entity and a storage medium. The method comprises: a first UDM entity sending, to a second UDM entity, a user subscription data acquisition request message that carries user identification information, wherein the user subscription data acquisition request message is a message defined by a standard protocol (S110); the first UDM entity receiving a response message sent by the second UDM entity according to the user subscription data acquisition request message, wherein the response message carries user subscription data corresponding to the user identification information (S120); the first UDM entity acquiring the user subscription data from the response message (S130); and the first UDM entity saving the user subscription data (S140).

Description

Data disaster recovery backup method, unified data management UDM entity and storage medium

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based on the Chinese patent application with the application number of 202011435456.2 and the filing date of December 10, 2020, and claims the priority of the Chinese patent application. The entire content of the Chinese patent application is incorporated herein by reference.

technical field

The present application relates to the field of communication technologies, and in particular to a data disaster recovery backup method, a unified data management UDM entity and a storage medium.

Background technique

The 5th generation (5G) communication system puts forward higher requirements on the disaster recovery capability of the core network. Unified Data Management (UDM) is the entity of the public control plane of the 5G core network and is responsible for the management of user subscription data. In order to ensure the reliability of the disaster recovery function of the core network, the contracted data in the UDM entity should be backed up in different places, and the consistency of the data backup should be ensured. Otherwise, after the emergency disaster recovery switchover, business operations are likely to fail, reducing the disaster recovery effect. . It can be seen that how to provide a reliable data disaster recovery backup method for UDM entities has become an urgent problem to be solved.

SUMMARY OF THE INVENTION

The following is an overview of the topics detailed in this article. This summary is not intended to limit the scope of protection of the claims.

The embodiments of the present application provide a data disaster recovery backup method, a unified data management UDM entity, and a storage medium.

In a first aspect, an embodiment of the present application provides a data disaster recovery and backup method, which is applied to a first unified data management UDM entity, the method comprising: sending a user subscription data acquisition request message carrying user identification information to a second UDM entity , wherein the user subscription data acquisition request message is a message defined by a standard protocol; a response message sent by the second UDM entity according to the user subscription data acquisition request message is received, and the response message carries the user identification information corresponding user subscription data; obtain the user subscription data from the response message; save the user subscription data.

In a second aspect, an embodiment of the present application provides a data disaster recovery and backup method, which is applied to a second unified data management UDM entity. The method includes: receiving a user subscription data acquisition request carrying user identification information sent by the first UDM entity message, wherein the user subscription data acquisition request message is a message defined by a standard protocol; according to the user subscription data acquisition request message, a response message is sent to the first UDM entity, and the response message carries the user identifier. User subscription data corresponding to the information, so that the first UDM entity saves the user subscription data.

In a third aspect, an embodiment of the present application provides a first UDM entity, including: a first sending module configured to send a user subscription data acquisition request message carrying user identification information to a second UDM entity, wherein the user The subscription data acquisition request message is a message defined by a standard protocol; the first receiving module is configured to receive a response message sent by the second UDM entity according to the user subscription data acquisition request message, and the response message carries information with the user User subscription data corresponding to the identification information; a first processing module configured to obtain the user subscription data from the response message; and a first storage module configured to save the user subscription data.

In a fourth aspect, an embodiment of the present application provides a second UDM entity, comprising: a second receiving module configured to receive a user subscription data acquisition request message carrying user identification information sent by the first UDM entity, wherein the The user subscription data acquisition request message is a message defined by a standard protocol; the second sending module is configured to send a response message to the first UDM entity according to the user subscription data acquisition request message, the response message carrying the User subscription data corresponding to the user identification information, so that the first UDM entity saves the user subscription data.

The fifth method, an embodiment of the present application provides a UDM entity including: a memory, a processor, and a computer program stored in the memory and running on the processor, the processor implements the first above when executing the computer program The data disaster recovery backup method described in the aspect or the second aspect.

In a sixth aspect, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, the data disaster recovery and backup method described in the first aspect or the second aspect is implemented .

Other features and advantages of the present application will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the present application. The objectives and other advantages of the application may be realized and attained by the structure particularly pointed out in the description, claims and drawings.

Description of drawings

The accompanying drawings are used to provide a further understanding of the technical solutions of the present application, and constitute a part of the specification. They are used to explain the technical solutions of the present application together with the embodiments of the present application, and do not constitute a limitation on the technical solutions of the present application.

1 is a schematic diagram of an application scenario of a data disaster recovery backup provided by the present application;

FIG. 2 is a flowchart of a data disaster recovery backup method provided by an embodiment of the present application;

3 is a flowchart of a data disaster recovery backup method provided by an embodiment of the present application;

4 is a flowchart of a data disaster recovery backup method provided by an embodiment of the present application;

5 is a flowchart of a data disaster recovery backup method provided by an embodiment of the present application;

6 is a flowchart of a data disaster recovery backup method provided by an embodiment of the present application;

7 is a flowchart of a data disaster recovery backup method provided by an embodiment of the present application;

8 is a flowchart of a data disaster recovery backup method provided by an embodiment of the present application;

FIG. 9 is a flowchart of a data disaster tolerance backup method provided by an embodiment of the present application;

10 is a flowchart of another data disaster recovery backup method provided by an embodiment of the present application;

FIG. 11 is a flowchart of another data disaster recovery backup method provided by an embodiment of the present application;

12 is a schematic structural diagram of a first UDM entity provided by an embodiment of the present application;

13 is a schematic structural diagram of a second UDM entity provided by an embodiment of the present application;

FIG. 14 is a schematic structural diagram of a UDM entity provided by an embodiment of the present application.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present application more clearly understood, the present application will be described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, but not to limit the present application.

It should be understood that in the description of the embodiments of the present application, if there is a description of "first", "second", etc., it is only for the purpose of distinguishing technical features, and should not be understood as indicating or implying relative importance or implicitly indicating that The number of indicated technical features or implicitly indicates the order of the indicated technical features. "At least one" means one or more, and "plurality" means two or more. "And/or", which describes the association relationship of the associated objects, means that there can be three kinds of relationships, for example, A and/or B, which can indicate the existence of A alone, the existence of A and B at the same time, and the existence of B alone. where A and B can be singular or plural. The character "/" generally indicates that the associated objects are an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c may represent: a, b, c, a and b, a and c, b and c or a and b and c, where a, b, c may be single, or Can be multiple.

In addition, the technical features involved in the various embodiments of the present application described below can be combined with each other as long as there is no conflict with each other.

For ease of understanding, an application scenario of the embodiments of the present application is first introduced.

FIG. 1 shows a schematic diagram of an application scenario of a data disaster recovery backup provided by the present application. This application scenario includes a public network and an enterprise private network. The public network and the enterprise private network are respectively deployed with independent 5G core networks (5G Core, 5GC). Each 5GC specifically includes entities such as UDM, AMF, SMF, and NEF. The public network also includes Business Operation Support Systems (BOSS), and the BOSS end is responsible for delivering the user's authentication data and subscription data to the UDM entity in the public network for unified management.

It should be understood that an enterprise private network (referred to as a private network) refers to the use of 5G slicing, Mobile Edge Computing (MEC) and other technologies to provide enterprise customers with exclusive coverage, network customization, data isolation, and basic connections for quality assurance. network to achieve large bandwidth, wide connection, low latency, safe and reliable data transmission. In the application scenario shown in Figure 1, in order to improve the reliability of the private network, the operator deploys a dedicated core network in the dedicated network, so that the dedicated network forms a network that can operate completely independently. In order to ensure the service availability of industrial users in various unexpected scenarios and maximize the user experience, it is the operator's expectation to enable mutual disaster recovery and backup between the public core network at location A and the private core network at location B.

In order to ensure the reliability of the disaster recovery function of the core network, the user subscription data in the UDM of the public core network and the UDM of the dedicated core network should be consistent. Otherwise, after the emergency disaster recovery switchover, business operations may fail, reducing the disaster recovery effect.

In a related technical solution, usually two UDM entities use equipment from the same equipment manufacturer, and the two UDM entities establish a transmission connection through a private protocol interface set by the equipment manufacturer, and perform duplication and backup of user subscription data. This solution is difficult to apply on a large scale due to the restriction that the equipment must belong to the same equipment manufacturer.

In practice, it is also possible to synchronize user subscription data to two UDM entities through BOSS, but currently BOSS uses a large number of service subscription templates to improve activation efficiency. Therefore, if BOSS is used to synchronize user subscription data between two UDM entities , the private network UDM entity also needs to maintain the service subscription template data like the public network UDM entity, so as to perform user subscription data conversion according to the service subscription template data, otherwise the user service experience will be affected. This maintenance effort is also unsustainable due to the deployment of a large number of dedicated network UDM entities in the future.

The embodiments of the present application provide a data disaster recovery backup method, a unified data management UDM entity and a storage medium, which can realize reliable data disaster recovery backup for the UDM entity, and can solve the problem that the equipment needs to belong to the same equipment manufacturer in the related technical solution. limitations, and there is no need to maintain business contract template data.

Referring to FIG. 2 , a method for data disaster recovery and backup provided by an embodiment of the present application is shown. As shown in Figure 2, the embodiment of the present application includes the following method steps:

S110: The first UDM entity sends a user subscription data acquisition request message carrying user identification information to the second UDM entity, where the user subscription data acquisition request message is a message defined by a standard protocol.

It is understandable that the first UDM entity and the second UDM entity in this embodiment of the present application are deployed in different core networks. For example, when the data disaster recovery and backup method provided by the embodiment of the present application is applied to the application scenario shown in FIG. 1 , the first UDM entity described in the embodiment of this method may be the UDM entity in the public core network, and the second UDM entity may be the UDM entity in the public core network. It is the UDM entity in the dedicated core network. Of course, the first UDM entity may be a UDM entity in a dedicated core network, and the second UDM entity may be a UDM entity in a public core network. In this way, when the data disaster recovery backup method provided by the embodiment of the present application is applied to the application scenario shown in FIG. 1 , mutual disaster recovery backup between the public core network UDM and the dedicated core network UDM can be realized.

As an example, the first UDM entity may send a user subscription data acquisition request message to the second UDM entity based on the user subscription data acquisition service message Nudm_SDM_GET (SDM: Subscriber Data Management, subscription data management).

It can be understood that Nudm_SDM_GET is a service message defined by the 3GPP standard protocol. The Nudm_SDM_GET service allows functional entities other than UDM itself to request the UDM entity to obtain user subscription data, and the UDM entity provides direct user subscription data acquisition based on the Nudm_SDM_GET service message. access. In this way, in the embodiment of the present application, after receiving the request message for obtaining user subscription data based on Nudm_SDM_GET, the second UDM entity obtains user subscription data locally in response to the request message, and feeds back to the first UDM entity that sent the request message .

It can be understood that, since the user subscription data acquisition request message in this embodiment of the present application is based on the Nudm_SDM_GET message defined by the current standard protocol, the first UDM entity can send the user subscription data acquisition request message to the second UDM entity through its own standard protocol interface. The standard protocol interface of the UDM entity enables the second UDM entity to receive the user subscription data acquisition request message. In this way, the shortcomings of the related technical solutions that the first UDM entity and the second UDM entity can only be equipment of the same equipment manufacturer and can only establish a transmission connection through a private protocol interface are overcome, so that the embodiments of the present application have good versatility, and can It is applied to UDM physical devices of different equipment manufacturers.

It can be understood that the user subscription data acquisition request message in this embodiment of the present application is not limited to the message defined by the 3GPP standard protocol, but may also be a message defined by an enterprise standard/industry standard, and may also be other general-purpose messages in the industry. The embodiment does not specifically limit this.

It can be understood that the standard protocol interface may be an interface defined by a 3GPP standard protocol, an interface defined by an enterprise standard/industry standard, or other general-purpose transmission interface in the industry.

During specific implementation, the first UDM entity and the second UDM entity establish a transmission connection through a pre-agreed standard protocol interface, so as to transmit a request message/response message through the standard protocol interface, so as to realize user signing between the first UDM entity and the second UDM entity. Data synchronization to achieve the purpose of disaster recovery backup.

It can be understood that the user subscription data acquisition request message may also carry the requested user subscription data type; the user subscription data type includes one or more of the following:

Access and Mobility Management (AM) subscription data;

Session Management (SM) subscription data;

Short Message Service (Short Message Service, SMS) subscription data.

All types of contract data;

Customized contract data.

As an example, the first UDM entity sends a Nudm_SDM_GET (AM data) request message to the second UDM entity to simulate an Access and Mobility Management Function (AMF) requesting the second UDM entity to acquire AM subscription data. The AM subscription data may include subscription data such as uplink and downlink rates, network slices, RFSP (radio access type (RAT) and radio frequency selection priority (FSP)).

As an example, the first UDM entity sends a Nudm_SDM_GET (SM data) request message to the second UDM entity to simulate a Session Management Function (Session Management Function, SMF) entity requesting the second UDM entity to obtain SM subscription data. The SM subscription data may include subscription data such as network slice, data network name (Data Network Name, DNN), quality of service (Quality of Service, QoS).

As an example, the first UDM entity sends a Nudm_SDM_GET (SMS data) request message to the second UDM entity to simulate a short message service function (Short Message Service Function, SMSF) entity requesting the second UDM entity to obtain SMS subscription data. The SMS subscription data may include subscription data such as short message service (SMS over NAS; SMS: Short Message Service, short message service; NAS: Non Access Stratum, non-access stratum) on the non-access stratum, SMS restrictions, and the like.

As an example, the first UDM entity sends a Nudm_SDM_GET(data set) request message to the second UDM entity to request all types of user subscription data sets from the second UDM entity, where the user subscription data sets include AM subscription data, SM subscription data and SMS A collection of all types of user subscription data such as subscription data. In this way, the first UDM entity can request the second UDM entity to acquire all types of user subscription data through one request message.

As an example, the first UDM entity may also customize the subscription data type obtained by the Nudm_SDM_GET request according to the enterprise standard/industry standard, so that the second UDM entity obtains the subscription data of the corresponding type according to the customized Nudm_SDM_GET request message and feeds back the subscription data to the third UDM entity. A UDM entity.

S120: The first UDM entity receives a response message sent by the second UDM entity according to the user subscription data acquisition request message, where the response message carries user subscription data corresponding to the user identification information.

It can be understood that, after receiving the user subscription data acquisition request message sent by the first UDM entity from its own standard protocol interface, the second UDM entity parses the user identification information carried in the user subscription data acquisition request message, and obtains the user subscription data from the local user identification information according to the user identification information. Acquire corresponding user subscription data, encapsulate the acquired user subscription data into a response message and send it to the first UDM entity, so that the first UDM entity receives the response message carrying the user subscription data corresponding to the user identification information.

S130, the first UDM entity acquires user subscription data from the response message.

It can be understood that after receiving the user subscription data corresponding to the user identification information sent by the second UDM entity, the first UDM entity parses the response message to parse the user subscription data from the response message.

For example, subscription data such as uplink and downlink rates, network slices, and RFSP are parsed from AM subscription data; subscription data such as network slice, DNN, and QoS are parsed from SM subscription data; SMS over NAS, SMS are parsed from SMS subscription data. Contract data such as restricted classes.

S140, the first UDM entity saves user subscription data.

It can be understood that, after parsing the user subscription data from the response message from the second UDM entity, the first UDM entity saves the user subscription data, so that the first UDM entity can interpret the user subscription data from the second UDM entity. Disaster recovery backup.

In a specific implementation process, the first UDM entity may determine a local storage address according to user identification information corresponding to the user subscription data, and save the user subscription data in a local storage space matching the storage address.

In the data disaster recovery and backup method provided by the embodiment of the present application, the first UDM entity sends a user subscription data acquisition request message to the second UDM entity based on the service message provided by the current standard protocol, so that the second UDM entity receives the user subscription data acquisition request. After the message is sent, the user subscription data is obtained locally in response to the request, and the user subscription data is fed back to the first UDM entity that sent the request. In this way, the first UDM entity directly obtains the user subscription data from the second UDM entity for storage, so as to achieve the purpose of disaster recovery and backup, which is safe and reliable, and greatly reduces the possibility of data synchronization failure.

In the solution of the embodiment of the present application, the first UDM entity can directly obtain the user subscription data from the second UDM entity through a standard protocol interface, which overcomes the problem that the first UDM entity and the second UDM entity can only use private The disadvantage of the protocol interface for transmitting user subscription data makes the data disaster recovery and backup method provided by the embodiments of the present application applicable to the backup of user subscription data between UDM devices of different device manufacturers, with good versatility and broad application scenarios.

In addition, in the solution of the embodiment of the present application, the first UDM entity also does not need to maintain service subscription template data, which greatly reduces the daily operation and maintenance pressure of operators and enterprise customers.

Referring to FIG. 3 , after the first UDM entity sends a user subscription data acquisition request message carrying user identification information to the second UDM entity, the data disaster recovery and backup method provided by the embodiment of the present application may further include the following method steps:

S150, the first UDM entity sends a user subscription data change notification subscription request message corresponding to the user identification information to the second UDM entity, where the user subscription data change notification subscription request message is a message defined by a standard protocol.

As an example, the first UDM entity may send the user subscription data change notification subscription request message to the second UDM entity through the user subscription data subscription service message Nudm_SDM_Subscribe, so that the second UDM entity can change the user subscription data corresponding to the user identification information when the user subscription data is changed. , sending a user subscription data change notification corresponding to the user identification information to the first UDM entity.

It can be understood that Nudm_SDM_Subscribe is a service message defined by a 3GPP standard protocol, and the Nudm_SDM_Subscribe service allows functional entities other than the UDM itself to subscribe to the UDM entity for notification of changes in subscription data of the user. Since Nudm_SDM_Subscribe is a service message defined by the current standard protocol, the first UDM entity can send the user subscription data change notification subscription request message to the standard protocol interface of the second UDM entity through its own standard protocol interface, so that the second UDM entity can receive The user subscription data change notification subscription request message.

It can be understood that the user subscription data change notification subscription request message may specifically include: one or more of Nudm_SDM_Subscribe(AM data), Nudm_SDM_Subscribe(SM data), Nudm_SDM_Subscribe(SMS data), Nudm_SDM_Subscribe(NE data). In this way, the second UDM entity is requested to subscribe to the notification of modification of one or more subscription data among AM subscription data, SM subscription data and SMS subscription data.

It can be understood that the user subscription data change notification subscription request message in the embodiment of the present application is not limited to the message defined by the 3GPP standard protocol, but can also be a message defined by an enterprise standard/industry standard, and can also be other general-purpose messages in the industry. This embodiment of the present application does not specifically limit this.

Referring to FIG. 4 , after the first UDM entity sends a user subscription data change notification subscription request message corresponding to the user identification information to the second UDM entity, the data disaster recovery method provided in the embodiment of the present application may further include the following method steps:

S160: The first UDM entity receives a notification of user subscription data change corresponding to the user identification information sent by the second UDM entity.

It can be understood that when the first UDM entity sends the user subscription data change notification subscription request message corresponding to the user identification information to the second UDM entity, when the second UDM entity changes the user subscription data corresponding to the user identification information, Send a user subscription data change notification corresponding to the user identification information to the first UDM entity.

S170, the first UDM entity updates the user subscription data corresponding to the user identification information according to the user subscription data change notification.

It can be understood that the first UDM entity updates the user subscription data corresponding to the user identification information according to the user subscription data change notification from the second UDM entity, so as to achieve synchronization and consistency with the user subscription data in the second UDM entity. Purpose.

Referring to FIG. 5, before the first UDM entity sends a user subscription data acquisition request message carrying user identification information to the second UDM entity, the method further includes:

S180, the first UDM entity obtains user authentication data, where the user authentication data carries user identification information.

In a possible implementation manner, when the BOSS sends the user authentication data to the second UDM entity, it also sends the user authentication data to the first UDM entity at the same time, so as to realize the first UDM entity and the second UDM entity. Synchronization of user authentication data between entities. In this way, the first UDM entity obtains user authentication data from the BOSS end.

It can be understood that the user authentication data stored in the UDM entity belongs to the confidential data of the user. For security reasons, the BOSS terminal can be used to directly issue the user authentication data to the first UDM entity and the second UDM entity synchronously. Of course, the user authentication data may also be transmitted and copied to the first UDM entity through other secret methods, which is not limited in this embodiment of the present application.

S190, the first UDM entity acquires user identification information according to the user authentication data.

It can be understood that the user authentication data carries the user identification information, and the first UDM entity can extract the user identification information from the user authentication data, so as to send the user subscription data acquisition request message to the second UDM entity according to the user identification information. And/or user subscription data change notification subscription request message.

It can be understood that the first UDM entity may send a user subscription data acquisition request message carrying user identification information to the second UDM entity according to preset time intervals, so as to achieve the purpose of regularly backing up the user subscription data of the second UDM entity.

It can be understood that if the communication connection between the first UDM entity and the second UDM entity is interrupted, when the interruption is restored, the first UDM entity can also be made to send the user subscription data acquisition request message carrying the user identification information to the second UDM entity. , so that the first UDM entity backs up the user subscription data in the second UDM entity in time after the interruption is restored, so as to avoid inconsistency between the user subscription data in the first UDM entity and the second UDM entity when a disaster recovery scenario occurs.

It can be understood that, the network management personnel can also send the backup instruction to the first UDM entity in a manual manner, so that when the first UDM entity receives the backup instruction, according to the backup instruction, the second UDM entity sends a message carrying the user identification information to the second UDM entity. User subscription data acquisition request message.

Referring to FIG. 6 , a data disaster recovery and backup method provided by an embodiment of the present application is shown. As shown in Figure 6, the embodiment of the present application includes the following method steps:

S210: The second UDM entity receives a user subscription data acquisition request message that is sent by the first UDM entity and carries user identification information, where the user subscription data acquisition request message is a message defined by a standard protocol.

As an example, the first UDM entity may send a user subscription data acquisition request message to the second UDM entity based on the user subscription data acquisition service message Nudm_SDM_GET. Nudm_SDM_GET is a service message defined by the current standard protocol. The Nudm_SDM_GET service allows functional entities other than UDM itself to request the UDM entity to obtain user subscription data. Therefore, the second UDM entity will respond to the Nudm_SDM_GET request message sent by the first UDM entity based on the Nudm_SDM_GET request message sent by the first UDM entity. The request obtains user subscription data corresponding to the user identification information locally, and feeds it back to the first UDM entity that sends the request.

It can be understood that, since the user subscription data acquisition request message in this embodiment of the present application is based on the Nudm_SDM_GET message defined by the current standard protocol, the first UDM entity can send the user subscription data acquisition request message to the second through its own standard protocol interface. The UDM entity and the second UDM entity may receive the user subscription data acquisition request message through its own standard protocol interface. In this way, the disadvantages of the related technical solutions that the first UDM entity and the second UDM entity can only be equipment of the same equipment manufacturer and can only establish a transmission connection through a private protocol interface are overcome.

S220, the second UDM entity sends a response message to the first UDM entity according to the user subscription data acquisition request message, where the response message carries the user subscription data corresponding to the user identification information, so that the first UDM entity saves the user subscription data.

It can be understood that after receiving the Nudm_SDM_GET request message from the first UDM entity, the second UDM entity parses the user identification information carried in the request message, locally searches for the user subscription data corresponding to the user identification information, and finds In the response message encapsulated by the user subscription data, the response message is sent to the first UDM entity.

It can be understood that the user subscription data acquisition request message sent by the first UDM entity may also carry the user subscription data type requested to be acquired; the user subscription data type includes one or more of the following: AM subscription data, SM subscription data, and SMS subscription. Data, all types of contract data, customized contract data.

It can be understood that when the user subscription data acquisition request message carries the user subscription data type requested to be acquired, the second UDM entity searches for the corresponding user subscription data according to the user identification information and the user subscription data type, and searches the found user subscription data. In the response message of the data encapsulation, the response message is sent to the first UDM entity.

In the data disaster recovery and backup method provided by the embodiment of the present application, the first UDM entity sends a user subscription data acquisition request message to the second UDM entity based on the service provided by the current standard protocol, so that the second UDM entity receives the user subscription data acquisition request message. Then, in response to the request, the user subscription data is obtained locally, and the user subscription data is fed back to the first UDM entity that sent the request. In this way, the first UDM entity directly obtains the user subscription data from the second UDM entity for storage, so as to achieve the purpose of disaster recovery and backup, which is safe and reliable, and greatly reduces the possibility of data synchronization failure.

In the solution of the embodiment of the present application, the first UDM entity can directly obtain the user subscription data from the second UDM entity through a standard protocol interface, which overcomes the problem that the first UDM entity and the second UDM entity can only use private The disadvantage of transmitting user subscription data through the protocol interface makes the data disaster recovery and backup method provided by the embodiments of the present application applicable to the backup of user subscription data between UDM devices of different device manufacturers, with good compatibility and broad application scenarios.

Referring to FIG. 7 , after the second UDM entity receives the user subscription data acquisition request message carrying the user identification information sent by the first UDM entity, the data disaster recovery method provided in the embodiment of the present application further includes:

S230, the second UDM entity receives the user subscription data change notification subscription request message corresponding to the user identification information sent by the first UDM entity, where the user subscription data change notification subscription request message is a message defined by a standard protocol.

As an example, the first UDM entity may send a user subscription data change notification subscription request message to the second UDM entity through the user subscription data subscription service message Nudm_SDM_Subscribe. When the user subscription data corresponding to the user identification information is changed, the second UDM entity sends the user subscription data modification notification corresponding to the user identification information to the first UDM entity.

It can be understood that Nudm_SDM_Subscribe is a service message defined by the current standard protocol, and the Nudm_SDM_Subscribe service allows functional entities other than the UDM itself to subscribe to the UDM entity for notification of changes to the user's subscription data. Since Nudm_SDM_Subscribe is a service message defined by the current standard protocol, the first UDM entity can send the user subscription data change notification subscription request message to the second UDM entity through its own standard protocol interface, and the second UDM entity can use its own standard protocol. The interface receives the user subscription data change notification subscription request message.

Referring to FIG. 8 , after the second UDM entity receives the user subscription data change notification subscription request message corresponding to the user identification information sent by the first UDM entity through the user subscription data subscription service, the data disaster recovery and backup method provided by the embodiment of the present application Also includes:

S240, the second UDM entity receives the user subscription data modification message sent by the BOSS, where the user subscription data modification message carries user identification information.

It can be understood that when the user's subscription data is modified, the BOSS end sends a user subscription data modification message to the second UDM entity, and the user subscription data modification message carries the user identification information, so that the second UDM entity can, according to the user identification information, Modify the locally stored user subscription data corresponding to the user identification information.

S250, the second UDM entity changes the user subscription data corresponding to the user identification information according to the user subscription data modification message.

It can be understood that the second UDM entity modifies the locally stored user subscription data corresponding to the user identification information according to the user subscription data modification message, thereby changing the user subscription data corresponding to the user identification information.

S260, the second UDM entity sends the user subscription data change notification corresponding to the user identification information to the first UDM entity, so that the first UDM entity updates the user subscription data corresponding to the user identification information according to the user subscription data change notification.

It can be understood that, after the second UDM entity modifies the locally stored user subscription data corresponding to the user identification information, the user subscription data is changed, and the first UDM entity subscribes to the second UDM entity with the second UDM entity. The user subscription data change notification corresponding to the user identification information, so the second UDM entity sends the user subscription data change notification corresponding to the user identification information to the first UDM entity, so that the first UDM entity updates the user subscription data change notification according to the user subscription data change notification. User subscription data corresponding to the identification information to achieve the purpose of data synchronization.

The data disaster tolerance method provided by the embodiment of the present application will be described below by using a specific example.

Example one:

Referring to FIG. 9 , a data disaster tolerance method according to an embodiment of the present application includes the following method steps:

S301, the BOSS end issues user authentication data to the first UDM entity and the second UDM entity synchronously;

S302, the BOSS end issues user subscription data to the second UDM entity;

S303, the first UDM entity obtains at least one user identification information according to the user authentication data;

S304, the first UDM entity triggers a user subscription data backup operation according to a preset time interval;

S305, the first UDM entity determines current user identification information from at least one user identification information;

S306, the first UDM entity sends a Nudm_SDM_GET (AM data) request message carrying the current user identification information to the second UDM entity;

S307, the second UDM entity searches for the AM subscription data corresponding to the current user identification information according to the current user identification information carried by Nudm_SDM_GET(AM data), and sends a response message carrying the AM subscription data corresponding to the current user identification information to the first UDM entity. UDM entity;

S308, the first UDM entity saves the subscription data such as uplink and downlink rates, network slices, and RFSPs parsed from the AM subscription data carried in the response message locally;

S309, the first UDM entity sends a Nudm_SDM_GET (SM data) request message carrying the current user identification information to the second UDM entity;

S310, the second UDM entity searches for the SM subscription data corresponding to the current user identification information according to the current user identification information carried by Nudm_SDM_GET (SM data), and sends a response message carrying the SM subscription data corresponding to the current user identification information to the first UDM entity. UDM entity;

S311, the first UDM entity will save the subscription data such as network slice, DNN, QoS etc. parsed out from the SM subscription data carried by the response message to the local;

S312, the first UDM entity sends a Nudm_SDM_GET (SMS data) request message carrying the current user identification information to the second UDM entity;

S313, the second UDM entity searches for the SMS subscription data corresponding to the current user identification information according to the current user identification information carried by Nudm_SDM_GET (SMS data), and sends a response message carrying the SMS subscription data corresponding to the current user identification information to the first UDM entity. UDM entity;

S314, the first UDM entity will save the subscription data such as SMS over NAS and SMS restricted classes from the SMS subscription data carried in the response message to the local;

S315, returning to step S305 until all user identification information is traversed, so as to complete the saving and backup of the user subscription data corresponding to all the user identification information.

In the example shown in FIG. 9 , the first UDM entity obtains the user's AM subscription data, SM subscription data and SMS subscription data from the second UDM entity by sending multiple Nudm_SDM_GET request messages to the second UDM entity, and completes the request for the first UDM entity. The AM subscription data, the SM subscription data and the SMS subscription data in the two UDM entities are saved and backed up.

Example two:

Referring to FIG. 10, a data disaster tolerance method according to an embodiment of the present application includes the following method steps:

S401, the BOSS end synchronously sends user authentication data to the first UDM entity and the second UDM entity;

S402, the BOSS end sends user subscription data to the second UDM entity;

S403, the first UDM entity obtains at least one user identification information according to the user authentication data;

S404, the first UDM entity triggers a user subscription data backup operation when receiving the backup instruction from the network administrator;

S405, the first UDM entity determines current user identification information from at least one user identification information;

S406, the first UDM entity sends a Nudm_SDM_GET (data set) request message carrying the current user identification information to the second UDM entity;

S407, the second UDM entity searches for the full-type subscription data corresponding to the current user identification information according to the current user identification information carried by Nudm_SDM_GET (data set), and sends a response message carrying the full-type subscription data corresponding to the current user identification information to the the first UDM entity;

S408, the first UDM entity saves the subscription data parsed from the full-type subscription data carried in the response message locally;

S409, the first UDM entity sends a Nudm_SDM_Subscribe (AM data) subscription request carrying the current user identification information to the second UDM entity;

S410, the second UDM entity returns a subscription response according to Nudm_SDM_Subscribe(AM data) to the first UDM entity;

S411, the first UDM entity sends a Nudm_SDM_Subscribe (SM data) subscription request carrying the current user identification information to the second UDM entity;

S412, the second UDM entity returns a subscription response according to Nudm_SDM_Subscribe(SM data) to the first UDM entity;

S413, the first UDM entity sends a Nudm_SDM_Subscribe (SMS data) subscription request carrying the current user identification information to the second UDM entity;

S414, the second UDM entity returns a subscription response according to Nudm_SDM_Subscribe (SMS data) to the first UDM entity;

S415, return to step S405 until all user identification information is traversed, so as to complete the saving and backup of the user contract data corresponding to all the user identification information and the subscription of the user contract data change notification.

In the example shown in FIG. 10 , the first UDM entity obtains the user's full-type subscription data from the second UDM entity by sending a Nudm_SDM_GET request message to the second UDM entity, and completes the full-type subscription in the second UDM entity The data is saved and backed up, and at the same time, the user subscription data change notification is subscribed to the second UDM entity.

It can be understood that steps S409 to S414 in this example are optional steps, and if a subscription request for the relevant user subscription data change notification has been submitted for the current user identification information before, the above steps may be omitted. Moreover, the subscription request message of the user subscription data change notification is not limited to Nudm_SDM_Subscribe(AM data), Nudm_SDM_Subscribe(SM data), Nudm_SDM_Subscribe(SMS data) messages, and may also include subscription request messages of other subscription data types in the specific implementation process. The application examples do not limit this too much.

Example three:

Referring to FIG. 11 , a data disaster tolerance method according to an embodiment of the present application includes the following method steps:

S501, the BOSS terminal sends an AM subscription data modification message carrying user identification information to a second UDM entity;

S502, the second UDM entity sends an AM subscription data change notification carrying user identification information to the first UDM entity;

S503, the first UDM entity updates the locally stored AM subscription data corresponding to the user identification information according to the received AM subscription data change notification carrying the user identification information;

S504, the BOSS end sends the SM subscription data modification message carrying the user identification information to the second UDM entity;

S505, the second UDM entity sends the SM subscription data change notification carrying the user identification information to the first UDM entity;

S506, the first UDM entity updates the locally stored SM subscription data corresponding to the user identification information according to the received SM subscription data change notification carrying the user identification information;

S507, the BOSS end sends an SMS subscription data modification message carrying the user identification information to the second UDM entity;

S508, the second UDM entity sends an SMS subscription data change notification carrying the user identification information to the first UDM entity;

S509, the first UDM entity updates the locally stored SMS subscription data corresponding to the user identification information according to the received SMS subscription data change notification carrying the user identification information.

In the example shown in FIG. 11 , in the case that the first UDM entity has subscribed the AM, SM, SMS subscription data change notification to the second UDM entity, when AM/SM/SMS subscription data in the second UDM entity occurs When changing, the second UDM entity sends the AM/SM/SMS subscription data change notification to the first UDM entity, so that the first UDM entity changes the locally stored AM/SM/SMS subscription data, and realizes the subscription data with the second UDM entity. Synchronize.

It should be further understood that, although the operations in the embodiments of the present application are described in a specific order in the drawings, it should not be construed as requiring that these operations be performed in the specific order shown or in a serial order, or requiring Perform all operations shown to obtain the desired result. In certain circumstances, multitasking and parallel processing may be advantageous.

Referring to FIG. 12 , the first UDM entity provided by the embodiment of the present application is shown. The first UDM entity includes: a first sending module 620 , a first receiving module 610 , a first processing module 630 , and a first saving module 640 .

The first sending module 620 is configured to send a user subscription data acquisition request message carrying user identification information to the second UDM entity, wherein the user subscription data acquisition request message is a message defined by a standard protocol;

The first receiving module 610 is configured to receive a response message sent by the second UDM entity according to the user subscription data acquisition request message, and the response message carries the user subscription data corresponding to the user identification information;

The first processing module 630 is configured to obtain user subscription data from the response message;

The first saving module 640 is configured to save user subscription data.

In some embodiments, the first sending module 620 is further configured to send a user subscription data change notification subscription request message corresponding to the user identification information to the second UDM entity, wherein the user subscription data change notification subscription request message is a standard protocol defined message.

In some embodiments, the first receiving module 610 is further configured to receive a user subscription data change notification corresponding to the user identification information sent by the second UDM entity.

In some embodiments, the first processing module 630 is further configured to update the user subscription data corresponding to the user identification information in the first saving module 640 according to the user subscription data change notification.

In some embodiments, the first receiving module 610 is further configured to obtain user authentication data, where the user authentication data carries user identification information.

In some embodiments, the first processing module 630 is further configured to obtain user identification information according to the user authentication data.

It can be understood that the user subscription data acquisition request message sent by the first sending module 620 also carries the requested user subscription data type; the user subscription data type includes one or more of the following: AM subscription data, SM subscription data; SMS subscription data, all types of contract data and customized contract data.

It can be understood that the first sending module 620 sends the user subscription data acquisition request message carrying the user identification information to the second UDM entity, which specifically includes:

According to the preset time interval, send the user subscription data acquisition request message carrying the user identification information to the second UDM entity;

Or, when the communication connection with the second UDM entity is interrupted and restored, sending a user subscription data acquisition request message carrying the user identification information to the second UDM entity;

Or, when the backup instruction is received, according to the backup instruction, a user subscription data acquisition request message carrying the user identification information is sent to the second UDM entity.

Referring to FIG. 13 , a second UDM entity provided by an embodiment of the present application is shown. The second UDM entity includes: a second receiving module 710 and a second sending module 720 .

The second receiving module 710 is configured to receive a user subscription data acquisition request message carrying user identification information sent by the first UDM entity, wherein the user subscription data acquisition request message is a message defined by a standard protocol;

The second sending module 720 is configured to send a response message to the first UDM entity according to the user subscription data acquisition request message, where the response message carries the user subscription data corresponding to the user identification information, so that the first UDM entity saves the user subscription data.

In some embodiments, the second receiving module 710 is further configured to receive a user subscription data change notification subscription request message corresponding to the user identification information sent by the first UDM entity, wherein the user subscription data change notification subscription request message is a standard Protocol-defined messages.

In some embodiments, the second receiving module 710 is further configured to receive a user subscription data modification message sent by the BOSS end of the service operation support system, wherein the user subscription data modification message carries user identification information.

In some embodiments, the second UDM entity further includes a second processing module configured to modify the user subscription data corresponding to the user identification information according to the user subscription data modification message.

In some embodiments, the second sending module 720 is further configured to send a user subscription data change notification corresponding to the user identification information to the first UDM entity, so that the first UDM entity updates the user identification data according to the user subscription data change notification User subscription data corresponding to the information.

It can be understood that the user subscription data acquisition request message received by the second receiving module 710 also carries the user subscription data type requested to be acquired; the user subscription data type includes one or more of the following: AM subscription data, SM subscription data; SMS subscription data, all types of contract data and customized contract data.

It should be noted that the information exchange, execution process and other contents between the above modules are based on the same concept as the method embodiments of the present application, and the specific functions and technical effects brought by them can be found in the method embodiments section for details. Repeat.

In the foregoing embodiments, the description of each embodiment has its own emphasis. For parts that are not described or described in detail in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

Referring to FIG. 14 , a UDM entity provided by an embodiment of the present application is shown, including: a memory 810 , a processor 820 , and a computer program stored in the memory 810 and running on the processor 820 .

The processor 820 and the memory 810 may be connected by a bus or otherwise.

The memory 810, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Additionally, memory 810 may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory may include memory located remotely from the processor 820, which may be connected to the processor 820 through a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

The non-transitory software programs and instructions required to realize the data disaster recovery backup method of the above embodiment are stored in the memory 810, and when executed by the processor 820, the data disaster recovery backup method in the above embodiment is executed. For example, the execution diagram is as follows. 2 to the steps in any of the embodiments shown in FIG. 8 .

The embodiments of the present application include: a first UDM entity sends a user subscription data acquisition request message carrying user identification information to a second UDM entity, where the user subscription data acquisition request message is a message defined by a standard protocol; the first UDM entity receives A response message sent by the second UDM entity according to the user subscription data acquisition request message, where the response message carries user subscription data corresponding to the user identification information; the first UDM entity acquires the user subscription data from the response message User subscription data; the first UDM entity saves the user subscription data. In the solution of this embodiment of the present application, the user subscription data acquisition request message sent by the first UDM entity to the second UDM entity is a message defined by a standard protocol. Obtain user contract data and save it to achieve disaster recovery backup. This method is safe and reliable, and greatly reduces the possibility of data synchronization failure.

The apparatus embodiments described above are only illustrative, and the units described as separate components may or may not be physically separated, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution in this embodiment.

In addition, an embodiment of the present application also provides a computer-readable storage medium, the computer-readable storage medium stores a computer program, the computer program is executed by a processor or a controller, when the computer program is executed by the processor or control When the server is executed, the data disaster recovery backup method in the foregoing embodiment is executed, for example, the steps in any of the embodiments shown in FIG. 2 to FIG. 8 are executed.

Those of ordinary skill in the art can understand that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and appropriate combinations thereof. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit . Such software may be distributed on computer-readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). As known to those of ordinary skill in the art, the term computer storage media includes both volatile and nonvolatile implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules or other data flexible, removable and non-removable media. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cartridges, magnetic tape, magnetic disk storage or other magnetic storage devices, or may Any other medium used to store desired information and which can be accessed by a computer. In addition, communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and can include any information delivery media, as is well known to those of ordinary skill in the art .

The above is a specific description of some implementations of the present application, but the present application is not limited to the above-mentioned embodiments. Those skilled in the art can also make various equivalent modifications or replacements without departing from the scope of the present application. These equivalents Variations or substitutions of the above are all included within the scope defined by the claims of the present application.

Claims

A data disaster recovery backup method, applied to a first unified data management UDM entity, the method comprising:

sending a user subscription data acquisition request message carrying user identification information to the second UDM entity, wherein the user subscription data acquisition request message is a message defined by a standard protocol;

receiving a response message sent by the second UDM entity according to the user subscription data acquisition request message, where the response message carries user subscription data corresponding to the user identification information;

Obtain the user subscription data from the response message;

The user subscription data is saved.
The method according to claim 1, wherein after sending a user subscription data acquisition request message carrying user identification information to the second UDM entity, the method further comprises:

Send a user subscription data change notification subscription request message corresponding to the user identification information to the second UDM entity, where the user subscription data change notification subscription request message is a message defined by a standard protocol.
The method according to claim 2, wherein after sending a user subscription data change notification subscription request message corresponding to the user identification information to the second UDM entity, the method further comprises:

receiving a notification of user subscription data change corresponding to the user identification information sent by the second UDM entity;

According to the user contract data change notification, the user contract data corresponding to the user identification information is updated.
The method according to claim 1, wherein before sending a user subscription data acquisition request message carrying user identification information to the second UDM entity, the method further comprises:

obtaining user authentication data, where the user authentication data carries the user identification information;

The user identification information is acquired according to the user authentication data.
The method according to claim 1, wherein the user subscription data acquisition request message also carries the user subscription data type requested to be acquired; the user subscription data type includes one or more of the following:

Access and mobility management AM subscription data;

session management SM subscription data;

Short message service SMS subscription data;

All types of contract data;

Customized contract data.
The method according to claim 1, wherein the sending a user subscription data acquisition request message carrying user identification information to the second UDM entity comprises:

According to the preset time interval, send the user subscription data acquisition request message carrying the user identification information to the second UDM entity;

Or, when the communication connection with the second UDM entity is interrupted and restored, sending a user subscription data acquisition request message carrying the user identification information to the second UDM entity;

Alternatively, when the backup instruction is received, according to the backup instruction, a user subscription data acquisition request message carrying the user identification information is sent to the second UDM entity.
A data disaster tolerance backup method, applied to a second unified data management UDM entity, the method comprising:

receiving a user subscription data acquisition request message carrying user identification information sent by the first UDM entity, wherein the user subscription data acquisition request message is a message defined by a standard protocol;

Send a response message to the first UDM entity according to the user subscription data acquisition request message, where the response message carries the user subscription data corresponding to the user identification information, so that the first UDM entity saves the user contract data.
The method according to claim 7, wherein after receiving a user subscription data acquisition request message carrying user identification information sent by the first UDM entity, the method further comprises:

A user subscription data change notification subscription request message corresponding to the user identification information sent by the first UDM entity is received, wherein the user subscription data change notification subscription request message is a message defined by a standard protocol.
The method according to claim 8, wherein, after receiving the subscription request message of user subscription data change notification corresponding to the user identification information sent by the first UDM entity, the method further comprises:

receiving a user subscription data modification message sent by the BOSS end of the service operation support system, wherein the user subscription data modification message carries the user identification information;

According to the user subscription data modification message, the user subscription data corresponding to the user identification information is changed;

Send the user subscription data change notification corresponding to the user identification information to the first UDM entity, so that the first UDM entity updates the user subscription data change notification corresponding to the user identification information according to the user subscription data change notification. User subscription data.
The method according to claim 7, wherein the user subscription data acquisition request message also carries the user subscription data type acquired by the request message; the user subscription data type includes one or more of the following:

Access and mobility management AM subscription data;

session management SM subscription data;

Short message service SMS subscription data;

All types of contract data;

Customized contract data.
A first unified data management UDM entity, comprising:

The first sending module is configured to send a user subscription data acquisition request message carrying user identification information to the second UDM entity, wherein the user subscription data acquisition request message is a message defined by a standard protocol;

a first receiving module, configured to receive a response message sent by the second UDM entity according to the user subscription data acquisition request message, where the response message carries user subscription data corresponding to the user identification information;

a first processing module, configured to obtain the user subscription data from the response message;

The first saving module is configured to save the user subscription data.
A second unified data management UDM entity, comprising:

The second receiving module is configured to receive a user subscription data acquisition request message carrying user identification information sent by the first UDM entity, wherein the user subscription data acquisition request message is a message defined by a standard protocol;

The second sending module is configured to send a response message to the first UDM entity according to the user subscription data acquisition request message, where the response message carries the user subscription data corresponding to the user identification information, so that the The first UDM entity stores the user subscription data.
A unified data management UDM entity, comprising: a memory, a processor and a computer program stored in the memory and running on the processor, wherein the processor implements any of claims 1 to 10 when executing the computer program The one described data disaster recovery backup method.
A computer-readable storage medium storing a computer program, wherein, when the computer program is executed by a processor, the data disaster recovery and backup method according to any one of claims 1 to 10 is implemented.