WO2022121772A1 - 数据容灾备份方法、统一数据管理udm实体和存储介质 - Google Patents

数据容灾备份方法、统一数据管理udm实体和存储介质 Download PDF

Info

Publication number
WO2022121772A1
WO2022121772A1 PCT/CN2021/135100 CN2021135100W WO2022121772A1 WO 2022121772 A1 WO2022121772 A1 WO 2022121772A1 CN 2021135100 W CN2021135100 W CN 2021135100W WO 2022121772 A1 WO2022121772 A1 WO 2022121772A1
Authority
WO
WIPO (PCT)
Prior art keywords
subscription data
user
udm entity
identification information
user subscription
Prior art date
Application number
PCT/CN2021/135100
Other languages
English (en)
French (fr)
Inventor
魏伟
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2022121772A1 publication Critical patent/WO2022121772A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1456—Hardware arrangements for backup
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments

Definitions

  • 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.
  • UDM Unified Data Management
  • the 5th generation (5G) communication system puts forward higher requirements on the disaster recovery capability of the core network.
  • Unified Data Management is the entity of the public control plane of the 5G core network and is responsible for the management of user subscription data.
  • 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.
  • the embodiments of the present application provide a data disaster recovery backup method, a unified data management UDM entity, and a storage medium.
  • 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.
  • 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.
  • 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.
  • 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 is described in the aspect or the second 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 .
  • FIG. 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
  • FIG. 3 is a flowchart of a data disaster recovery backup method provided by an embodiment of the present application.
  • FIG. 4 is a flowchart of a data disaster recovery backup method provided by an embodiment of the present application.
  • FIG. 5 is a flowchart of a data disaster recovery backup method provided by an embodiment of the present application.
  • FIG. 6 is a flowchart of a data disaster recovery backup method provided by an embodiment of the present application.
  • FIG. 7 is a flowchart of a data disaster recovery backup method provided by an embodiment of the present application.
  • FIG. 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.
  • FIG. 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.
  • FIG. 12 is a schematic structural diagram of a first UDM entity provided by an embodiment of the present application.
  • FIG. 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.
  • 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.
  • 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).
  • 5G Core 5G Core
  • 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.
  • BOSS Business Operation Support Systems
  • an enterprise 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.
  • MEC Mobile Edge Computing
  • the operator deploys a dedicated core network in the dedicated network, so that the dedicated network forms a network that can operate completely independently.
  • the dedicated network forms a network that can operate completely independently.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • the first UDM entity and the second UDM entity in this embodiment of the present application are deployed in different core networks.
  • the first UDM entity described in the embodiment of this method may be the UDM entity in the public core network
  • the second UDM entity may be the UDM entity in the public core network. It is the UDM entity in the dedicated core network.
  • the first UDM entity may be a UDM entity in a dedicated core network
  • the second UDM entity may be a UDM entity in a public core network.
  • 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).
  • SDM Subscriber Data Management, subscription data management
  • 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.
  • the second UDM entity 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • AM Access and Mobility Management
  • SM Session Management
  • Short Message Service Short Message Service (Short Message Service, SMS) subscription data.
  • SMS Short Message Service
  • 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)).
  • RAT radio access type
  • FSP radio frequency selection priority
  • 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).
  • 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.
  • 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.
  • 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.
  • the first UDM entity can request the second UDM entity to acquire all types of user subscription data through one request message.
  • 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.
  • 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 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.
  • the first UDM entity acquires user subscription data from the response message.
  • the first UDM entity parses the response message to parse the user subscription data from the response message.
  • 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.
  • the first UDM entity saves user subscription data.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the data disaster recovery and backup method may further include the following method steps:
  • 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.
  • 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.
  • Nudm_SDM_Subscribe is a service message defined by a 3GPP standard protocol
  • 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.
  • 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).
  • Nudm_SDM_Subscribe(AM data) 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).
  • 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.
  • the data disaster recovery method may further include the following method steps:
  • the first UDM entity receives a notification of user subscription data change corresponding to the user identification information sent by the second UDM entity.
  • the first UDM entity updates the user subscription data corresponding to the user identification information according to the user subscription data change notification.
  • 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.
  • the method 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:
  • the first UDM entity obtains user authentication data, where the user authentication data carries user identification information.
  • the BOSS 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.
  • the user authentication data stored in the UDM entity belongs to the confidential data of the user.
  • the BOSS terminal can be used to directly issue the user authentication data to the first UDM entity and the second UDM entity synchronously.
  • 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.
  • the first UDM entity acquires user identification information according to the user authentication data.
  • the user authentication data carries the user identification information
  • 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.
  • 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.
  • 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.
  • 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 can also be sent 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the response message of the data encapsulation the response message is sent to the first UDM entity.
  • 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.
  • 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.
  • 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.
  • the data disaster recovery method provided in the embodiment of the present application further includes:
  • 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.
  • 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.
  • the second UDM entity sends the user subscription data modification notification corresponding to the user identification information to the first UDM entity.
  • Nudm_SDM_Subscribe is a service message defined by the current standard protocol
  • 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.
  • the data disaster recovery and backup method provided by the embodiment of the present application also includes:
  • 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.
  • 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.
  • the second UDM entity changes the user subscription data corresponding to the user identification information according to the user subscription data modification message.
  • 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.
  • 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.
  • 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.
  • a data disaster tolerance method includes the following method steps:
  • the BOSS end issues user authentication data to the first UDM entity and the second UDM entity synchronously;
  • the BOSS end issues user subscription data to the second UDM entity
  • the first UDM entity obtains at least one user identification information according to the user authentication data
  • the first UDM entity triggers a user subscription data backup operation according to a preset time interval
  • the first UDM entity determines current user identification information from at least one user identification information
  • the first UDM entity sends a Nudm_SDM_GET (AM data) request message carrying the current user identification information to the second UDM entity;
  • 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.
  • 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;
  • the first UDM entity sends a Nudm_SDM_GET (SM data) request message carrying the current user identification information to the second UDM entity;
  • SM data Nudm_SDM_GET
  • 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.
  • SM data the current user identification information carried by Nudm_SDM_GET
  • 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;
  • the first UDM entity sends a Nudm_SDM_GET (SMS data) request message carrying the current user identification information to the second UDM entity;
  • SMS data Nudm_SDM_GET
  • 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.
  • SMS data the current user identification information carried by Nudm_SDM_GET
  • 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;
  • step 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.
  • 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.
  • a data disaster tolerance method includes the following method steps:
  • the BOSS end synchronously sends user authentication data to the first UDM entity and the second UDM entity;
  • the BOSS end sends user subscription data to the second UDM entity
  • the first UDM entity obtains at least one user identification information according to the user authentication data
  • the first UDM entity triggers a user subscription data backup operation when receiving the backup instruction from the network administrator
  • the first UDM entity determines current user identification information from at least one user identification information
  • the first UDM entity sends a Nudm_SDM_GET (data set) request message carrying the current user identification information to the second UDM entity;
  • 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;
  • the first UDM entity saves the subscription data parsed from the full-type subscription data carried in the response message locally;
  • the first UDM entity sends a Nudm_SDM_Subscribe (AM data) subscription request carrying the current user identification information to the second UDM entity;
  • AM data Nudm_SDM_Subscribe
  • the second UDM entity returns a subscription response according to Nudm_SDM_Subscribe(AM data) to the first UDM entity;
  • the first UDM entity sends a Nudm_SDM_Subscribe (SM data) subscription request carrying the current user identification information to the second UDM entity;
  • SM data Nudm_SDM_Subscribe
  • the second UDM entity returns a subscription response according to Nudm_SDM_Subscribe(SM data) to the first UDM entity;
  • the first UDM entity sends a Nudm_SDM_Subscribe (SMS data) subscription request carrying the current user identification information to the second UDM entity;
  • SMS data Nudm_SDM_Subscribe
  • the second UDM entity returns a subscription response according to Nudm_SDM_Subscribe (SMS data) to the first UDM entity;
  • step 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.
  • 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.
  • 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.
  • 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.
  • a data disaster tolerance method includes the following method steps:
  • the BOSS terminal sends an AM subscription data modification message carrying user identification information to a second UDM entity;
  • the second UDM entity sends an AM subscription data change notification carrying user identification information to the first UDM entity;
  • 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;
  • the BOSS end sends the SM subscription data modification message carrying the user identification information to the second UDM entity;
  • the second UDM entity sends the SM subscription data change notification carrying the user identification information to the first UDM entity;
  • 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;
  • the BOSS end sends an SMS subscription data modification message carrying the user identification information to the second UDM entity;
  • the second UDM entity sends an SMS subscription data change notification carrying the user identification information to the first UDM entity;
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first receiving module 610 is further configured to obtain user authentication data, where the user authentication data carries user identification information.
  • the first processing module 630 is further configured to obtain user identification information according to the user authentication data.
  • 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.
  • 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:
  • a user subscription data acquisition request message carrying the user identification information is sent to the second UDM entity.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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 .

Abstract

一种数据容灾备份方法、统一数据管理UDM实体和存储介质，该方法包括，第一UDM实体向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息，其中，所述用户签约数据获取请求消息是标准协议定义的消息(S110)；第一UDM实体接收所述第二UDM实体根据所述用户签约数据获取请求消息发送的响应消息，所述响应消息携带与所述用户标识信息对应的用户签约数据(S120)；第一UDM实体从所述响应消息中获取所述用户签约数据(S130)；第一UDM实体保存所述用户签约数据(S140)。

Description

数据容灾备份方法、统一数据管理UDM实体和存储介质
相关申请的交叉引用
本申请基于申请号为202011435456.2、申请日为2020年12月10日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请涉及通信技术领域，具体涉及一种数据容灾备份方法、统一数据管理UDM实体和存储介质。
背景技术
第五代(5rd generation，5G)通信系统对核心网的容灾能力提出更高的要求。统一数据管理(Unified Data Management，UDM)是5G核心网公共控制面的实体，负责用户签约数据管理。为了确保核心网容灾功能的可靠性，应对UDM实体中的签约数据进行异地备份，并需确保数据备份的一致性，否则在应急容灾切换后，极可能出现业务操作失败，降低容灾效果。可见，如何为UDM实体提供一种可靠的数据容灾备份方法已成为亟待解决的问题。
发明内容
以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。
本申请实施例提供一种数据容灾备份方法、统一数据管理UDM实体和存储介质。
第一方面，本申请实施例提供了一种数据容灾备份方法，应用于第一统一数据管理UDM实体，所述方法包括：向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息，其中，所述用户签约数据获取请求消息是标准协议定义的消息；接收所述第二UDM实体根据所述用户签约数据获取请求消息发送的响应消息，所述响应消息携带与所述用户标识信息对应的用户签约数据；从所述响应消息中获取所述用户签约数据；保存所述用户签约数据。
第二方面，本申请实施例提供了一种数据容灾备份方法，应用于第二统一数据管理UDM实体，所述方法包括：接收第一UDM实体发送的携带用户标识信息的用户签约数据获取请求消息，其中，所述用户签约数据获取请求消息是标准协议定义的消息；根据所述用户签约数据获取请求消息，向所述第一UDM实体发送响应消息，所述响应消息携带与所述用户标识信息对应的用户签约数据，以使所述第一UDM实体保存所述用户签约数据。
第三方面，本申请实施例提供了一种第一UDM实体，包括：第一发送模块，被设置成向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息，其中，所述用户签约数据获取请求消息为标准协议定义的消息；第一接收模块，被设置成接收所述第二UDM实体根据所述用户签约数据获取请求消息发送的响应消息，所述响应消息携带与所述用户标识信息对应的用户签约数据；第一处理模块，被设置成从所述响应消息中获取所述用户签约数据；第一保存模块，被设置成保存所述用户签约数据。
第四方面，本申请实施例提供了一种第二UDM实体，包括：第二接收模块，被设置成接收第一UDM实体发送的携带用户标识信息的用户签约数据获取请求消息，其中，所述用户签约数据获取请求消息为标准协议定义的消息；第二发送模块，被设置成根据所述用户签约数据获取请求消息，向所述第一UDM实体发送响应消息，所述响应消息携带与所述用户标识信息对应的用户签约数据，以使所述第一UDM实体保存所述用户签约数据。
第五方法，本申请实施例提供了一种UDM实体包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上第一方面或者第二方面所述的数据容灾备份方法。
第六方面，本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序，所述计算机 程序被处理器执行时实现如上第一方面或者第二方面所述的数据容灾备份方法。
本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本申请技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请的技术方案，并不构成对本申请技术方案的限制。
图1是本申请提供的一种数据容灾备份的应用场景示意图；
图2是本申请实施例提供的一种数据容灾备份方法的流程图；
图3是本申请实施例提供的一种数据容灾备份方法的流程图；
图4是本申请实施例提供的一种数据容灾备份方法的流程图；
图5是本申请实施例提供的一种数据容灾备份方法的流程图；
图6是本申请实施例提供的一种数据容灾备份方法的流程图；
图7是本申请实施例提供的一种数据容灾备份方法的流程图；
图8是本申请实施例提供的一种数据容灾备份方法的流程图；
图9本申请实施例提供的一种数据容灾备份方法的流程图；
图10本申请实施例提供的另一种数据容灾备份方法的流程图；
图11本申请实施例提供的另一种数据容灾备份方法的流程图；
图12是本申请实施例提供的第一UDM实体的结构示意图；
图13是本申请实施例提供的第二UDM实体的结构示意图；
图14是本申请实施例提供的一种UDM实体的结构示意图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。
应了解，在本申请实施例的描述中，如果有描述到“第一”、“第二”等只是用于区分技术特征为目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量或者隐含指明所指示的技术特征的先后关系。“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示单独存在A、同时存在A和B、单独存在B的情况。其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项”及其类似表达，是指的这些项中的任意组合，包括单项或复数项的任意组合。例如，a，b和c中的至少一项可以表示：a，b，c，a和b，a和c，b和c或a和b和c，其中a，b，c可以是单个，也可以是多个。
此外，下面所描述的本申请各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
为了便于理解，首先对本申请实施例的应用场景作一介绍。
图1示出了本申请提供的一种数据容灾备份的应用场景示意图。该应用场景中包括公用网络和企业专用网络，公用网络和企业专用网络分别部署有独立的5G核心网(5G Core，5GC)，每个5GC具体包括UDM、AMF、SMF、NEF等实体。公用网络中还包括业务运营支撑系统(Business Operation Support Systems，BOSS)，BOSS端负责将用户的鉴权数据、签约数据下发给公用网络中的UDM实体进行统一管理。
应当理解的是，企业专用网络(简称专用网络)是指利用5G切片、移动边缘计算(Mobile Edge Computing,MEC)等技术，为企业客户提供专属覆盖、网络定制、数据隔离、质量保证的基础连接网络，实现大带宽、广连接、低时延、安全可靠的数据传输。在图1所示的应用场景中，运营商为了提高专用网络的可靠性，在专用网络部署专用核心网，使专用网络形成可完全独立运转的网络。为确保各种意外场景下的行业用户的业务可用性，以最大程度提升用户体验，使A地的公用核心网与B地的专用核心网之间能够相互容灾备份是运营商期望实现的。
为了确保核心网容灾功能的可靠性，公用核心网的UDM和专用核心网的UDM中的用户签约数据应当一致，否则在应急容灾切换后，极可能出现业务操作失败，降低容灾效果。
在相关的技术方案中，通常是两个UDM实体采用同一设备商的设备，两个UDM实体通过设备商设置的私有协议接口建立传输连接，并进行用户签约数据的复制备份。这种方案由于受到设备需同属一个设备商的限制，很难大规模应用。
实际情况中，也可以通过BOSS将用户签约数据同步至两个UDM实体，但是目前BOSS为提升开通效率，使用了大量业务签约模板，因此如若通过BOSS实现两个UDM实体之间的用户签约数据同步，专用网络UDM实体也需要如公用网络UDM实体一样维护业务签约模板数据，以根据业务签约模板数据进行用户签约数据转换，否则会影响用户业务体验。由于未来会部署大量的专用网络UDM实体，导致这种维护工作也不可持续。
本申请实施例提供一种数据容灾备份方法、统一数据管理UDM实体和存储介质，能够为UDM实体实现可靠的数据容灾备份，同时可解决相关的技术方案中受到设备需同属一个设备商的限制的问题，且无需维护业务签约模板数据。
请参见图2，示出了本申请实施例提供的一种数据容灾备份方法。如图2所示，本申请实施例包括如下方法步骤：
S110，第一UDM实体向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息，其中，用户签约数据获取请求消息是标准协议定义的消息。
可理解的是，本申请实施例的第一UDM实体和第二UDM实体部署在不同的核心网中。例如，将本申请实施例提供的数据容灾备份方法应用于图1所示的应用场景中时，本法实施例描述的第一UDM实体可以为公用核心网中的UDM实体，第二UDM实体为专用核心网中的UDM实体。当然也可以是，第一UDM实体为专用核心网中的UDM实体，第二UDM实体为公用核心网中的UDM实体。如此，将本申请实施例提供的数据容灾备份方法应用于图1所示的应用场景中时，能够实现公用核心网UDM与专用核心网UDM之间能够相互容灾备份。
作为示例，第一UDM实体可以基于用户签约数据获取服务消息Nudm_SDM_GET(SDM：Subscriber Data Management，签约数据管理)向第二UDM实体发送用户签约数据获取请求消息。
可以理解的是，Nudm_SDM_GET是3GPP标准协议定义的服务消息，该Nudm_SDM_GET服务允许除UDM自身外的功能实体向UDM实体请求获取用户的签约数据，UDM实体基于该Nudm_SDM_GET服务消息提供直接的用户签约数据获取访问。如此，在本申请实施例中，第二UDM实体接收到基于Nudm_SDM_GET的用户签约数据获取请求消息后，响应于该请求消息从本地获取用户签约数据，以反馈给发送该请求消息的第一UDM实体。
可以理解的是，由于本申请实施例的用户签约数据获取请求消息基于当前标准协议定义的Nudm_SDM_GET消息，所以第一UDM实体可以通过自身的标准协议接口将该用户签约数据获取请求消息发送至第二UDM实体的标准协议接口，使第二UDM实体接收该用户签约数据获取请求消息。如此，克服了相关的技术方案中第一UDM实体和第二UDM实体只能是同一设备商设备和只能通过私有协议接口建立传输连接的缺点，使得本申请实施例具有良好的通用性，可应用在不同设备商的UDM实体设备上。
可以理解的是，本申请实施例的用户签约数据获取请求消息不仅限于3GPP标准协议定义的消息，也可以是企业标准/行业标准定义的消息，还可以是行业中的其他通用型消息，本申请实施例对此不作具体限定。
可以理解的是，标准协议接口可以是3GPP标准协议定义的接口，也可以是企业标准/行业标准定义的接口，还可以是行业中其他通用型的传输接口。
具体实现时，第一UDM实体和第二UDM实体通过预先协定的标准协议接口建立传输连接，以通过标准协议接口传输请求消息/响应消息，实现第一UDM实体和第二UDM实体之间用户签约数据的同步，达到容灾备份的目的。
可以理解的是，用户签约数据获取请求消息还可以携带请求获取的用户签约数据类型；用户签约数据类型包括以下一种或者多种：
接入和移动管理(Access and Mobility Management，AM)签约数据；
会话管理(Session Management，SM)签约数据；
短信息服务(Short Message Service，SMS)签约数据。
全类型签约数据；
定制类签约数据。
作为示例，第一UDM实体向第二UDM实体发送Nudm_SDM_GET(AM data)请求消息，以模拟接入和移动管理功能实体(Access and Mobility Management Function，AMF)向第二UDM实体请求获取AM签约数据。其中，AM签约数据可以包括上下行速率、网络切片、RFSP(无线接入类型(radio access type，RAT)以及无线频率优先级(frequency selection priority，FSP))等签约数据。
作为示例，第一UDM实体向第二UDM实体发送Nudm_SDM_GET(SM data)请求消息，以模拟会话管理功能(Session Management Function，SMF)实体向第二UDM实体请求获取SM签约数据。其中，SM签约数据可以包括网络切片、数据网络名称(Data Network Name，DNN)、服务质量(Quality of Service，QoS)等签约数据。
作为示例，第一UDM实体向第二UDM实体发送Nudm_SDM_GET(SMS data)请求消息，以模拟短信息服务功能(Short Message Service Function，SMSF)实体向第二UDM实体请求获取SMS签约数据。其中，SMS签约数据可以包括非接入层上的短信息服务(SMS over NAS；SMS：Short Message Service，短信息服务；NAS：Non Access Stratum，非接入层)、SMS限制类等签约数据。
作为示例，第一UDM实体向第二UDM实体发送Nudm_SDM_GET(data set)请求消息，以向第二UDM实体请求全类型的用户签约数据集合，用户签约数据集合包括AM签约数据、SM签约数据和SMS签约数据等所有类型的用户签约数据集合。如此，第一UDM实体通过一条请求消息即可向第二UDM实体请求获取全部类型的用户签约数据。
作为示例，第一UDM实体还可以根据企业标准/行业标准定制Nudm_SDM_GET请求获取的签约数据类型，以使第二UDM实体根据定制的Nudm_SDM_GET请求消息获取对应类型的签约数据并将该签约数据反馈给第一UDM实体。
S120，第一UDM实体接收第二UDM实体根据用户签约数据获取请求消息发送的响应消息，其中，响应消息携带与用户标识信息对应的用户签约数据。
可以理解的是，第二UDM实体从自身标准协议接口接收到第一UDM实体发送的用户签约数据获取请求消息后，解析该用户签约数据获取请求消息携带的用户标识信息，根据用户标识信息从本地获取对应的用户签约数据，将获取的用户签约数据封装至响应消息中并发送给第一UDM实体，使第一UDM实体接收该携带与用户标识信息对应的用户签约数据的响应消息。
S130，第一UDM实体从响应消息中获取用户签约数据。
可以理解的是，第一UDM实体接收到第二UDM实体发送的携带与用户标识信息对应的用户签约数据之后，对该响应消息进行解析，以从响应消息中解析出用户签约数据。
例如，从AM签约数据中解析出上下行速率、网络切片、RFSP等签约数据；从SM签约数据中解析出网络切片、DNN、QoS等签约数据；从SMS签约数据中解析出SMS over NAS、SMS限制类等签约数据。
S140，第一UDM实体保存用户签约数据。
可以理解的是，第一UDM实体从来自第二UDM实体的响应消息中解析出用户签约数据之后，对该用户签约数据进行保存，使第一UDM实体对来自第二UDM实体的用户签约数据的容灾备份。
具体实现过程中，第一UDM实体可以根据用户签约数据对应的用户标识信息，确定本地的存储地址，将该用户签约数据保存在与存储地址匹配的本地存储空间中。
本申请实施例提供的数据容灾备份方法，第一UDM实体基于当前标准协议提供的服务消息向第二UDM实体发送用户签约数据获取请求消息，以使第二UDM实体接收到用户签约数据获取请求消息后，响应于该请求从本地获取用户签约数据，并将用户签约数据反馈给发送该请求的第一UDM实体。如此，第一UDM实体直接从第二UDM实体获取用户签约数据进行保存，以达到容灾备份目的，这种方式安全可靠，大大降低数据同步失败的可能性。
本申请实施例的方案中，第一UDM实体可通过标准协议接口直接从第二UDM实体中获取到用户签约数据，克服了相关的技术方案中第一UDM实体和第二UDM实体只能通过私有协议接口传输用户 签约数据的缺点，使得本申请实施例提供的数据容灾备份方法能够适用于不同设备厂商的UDM设备之间的用户签约数据备份，通用性好，具有广阔的应用场景。
另外，本申请实施例的方案中，第一UDM实体也无需维护业务签约模板数据，大大地降低了运营商、企业客户的日常运维压力。
请参见图3，在第一UDM实体向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息之后，本申请实施例提供的数据容灾备份方法还可以包括如下方法步骤：
S150,第一UDM实体向第二UDM实体发送与用户标识信息对应的用户签约数据变更通知订阅请求消息，其中，用户签约数据变更通知订阅请求消息是标准协议定义的消息。
作为示例，第一UDM实体可以通过用户签约数据订阅服务消息Nudm_SDM_Subscribe向第二UDM实体发送用户签约数据变更通知订阅请求消息，以使第二UDM实体在与用户标识信息对应的用户签约数据发生变更时，向第一UDM实体发送与用户标识信息对应的用户签约数据变更通知。
可以理解的是，Nudm_SDM_Subscribe是3GPP标准协议定义的服务消息，该Nudm_SDM_Subscribe服务允许除UDM自身外的功能实体向UDM实体订阅用户的签约数据变更的通知。由于Nudm_SDM_Subscribe是当前标准协议定义的服务消息，所以第一UDM实体可以通过自身的标准协议接口将该用户签约数据变更通知订阅请求消息发送至第二UDM实体的标准协议接口，使第二UDM实体接收该用户签约数据变更通知订阅请求消息。
可以理解的是，用户签约数据变更通知订阅请求消息具体可以包括：Nudm_SDM_Subscribe(AM data)、Nudm_SDM_Subscribe(SM data)、Nudm_SDM_Subscribe(SMS data)、Nudm_SDM_Subscribe(NE data)中的一种或者多种。如此，向第二UDM实体请求订阅AM签约数据、SM签约数据和SMS签约数据中的一种或者多种签约数据的变更通知。
可以理解的是，本申请实施例的用户签约数据变更通知订阅请求消息不仅限于3GPP标准协议定义的消息，也可以是企业标准/行业标准定义的消息，还可以是行业中的其他通用型消息，本申请实施例对此不作具体限定。
请参见图4，在第一UDM实体向第二UDM实体发送与用户标识信息对应的用户签约数据变更通知订阅请求消息之后，本申请实施例提供的数据容灾备份方法还可以包括如下方法步骤：
S160,第一UDM实体接收第二UDM实体发送的与用户标识信息对应的用户签约数据变更通知。
可以理解的是，当第一UDM实体向第二UDM实体发送了与用户标识信息对应的用户签约数据变更通知订阅请求消息，第二UDM实体在与用户标识信息对应的用户签约数据发生变更时，向第一UDM实体发送与用户标识信息对应的用户签约数据变更通知。
S170,第一UDM实体根据用户签约数据变更通知，更新与用户标识信息对应的用户签约数据。
可以理解的是，第一UDM实体根据该来自第二UDM实体的用户签约数据变更通知，更新与用户标识信息对应的用户签约数据，以达到与第二UDM实体中的用户签约数据保持同步一致的目的。
请参见图5，在第一UDM实体向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息之前，方法还包括：
S180，第一UDM实体获取用户鉴权数据，用户鉴权数据携带用户标识信息。
在一种可能的实现方式中，BOSS端将用户鉴权数据下发给第二UDM实体时，也同时将用户鉴权数据下发给第一UDM实体，以实现第一UDM实体和第二UDM实体之间的用户鉴权数据的同步。如此，第一UDM实体从BOSS端获取用户鉴权数据。
可以理解的是，UDM实体中存放的用户鉴权数据属于用户的机密数据，出于安全性考虑，可以采用BOSS端直接向第一UDM实体、第二UDM实体同步发放用户鉴权数据。当然，也可以通过其他保密途径将用户鉴权数据传输复制至第一UDM实体，本申请实施例对此不作限制。
S190，第一UDM实体根据用户鉴权数据获取用户标识信息。
可以理解的是，用户鉴权数据中携带用户标识信息，第一UDM实体能从用户鉴权数据中中提取出用户标识信息，以根据用户标识信息向第二UDM实体发送用户签约数据获取请求消息和/或用户签约数据变更通知订阅请求消息。
可以理解的是，第一UDM实体可以按照预设的时间间隔，向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息，以达到定时备份第二UDM实体的用户签约数据的目的。
可以理解的是，若第一UDM实体与第二UDM实体的通信连接发生中断，当中断恢复时，也可以使第一UDM实体向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息，以在中断恢复后使第一UDM实体及时对第二UDM实体中的用户签约数据进行备份，避免容灾场景发生时，第一UDM实体与第二UDM实体中的用户签约数据不一致。
可以理解的是，也可以由网络管理人员采用人工的方式向第一UDM实体发送备份指令，使第一UDM实体接收到备份指令时，根据备份指令，向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息。
请参见图6，示出了本申请实施例提供的一种数据容灾备份方法。如图6所示，本申请实施例包括如下方法步骤：
S210，第二UDM实体接收第一UDM实体发送的携带用户标识信息的用户签约数据获取请求消息，其中，用户签约数据获取请求消息是标准协议定义的消息。
作为示例，第一UDM实体可以基于用户签约数据获取服务消息Nudm_SDM_GET向第二UDM实体发送用户签约数据获取请求消息。Nudm_SDM_GET是当前标准协议定义的服务消息，Nudm_SDM_GET服务允许除UDM自身外的功能实体向UDM实体请求获取用户的签约数据，因此第二UDM实体基于第一UDM实体发送的Nudm_SDM_GET请求消息后，将响应于该请求从本地获取与用户标识信息对应的用户签约数据，以反馈给发送该请求的第一UDM实体。
可以理解的是，由于本申请实施例的用户签约数据获取请求消息基于当前标准协议定义的Nudm_SDM_GET消息，所以第一UDM实体可以通过自身的标准协议接口将该用户签约数据获取请求消息发送至第二UDM实体，第二UDM实体可以通过自身的标准协议接口接收该用户签约数据获取请求消息。如此，克服了相关的技术方案中第一UDM实体和第二UDM实体只能是同一设备商设备和只能通过私有协议接口建立传输连接的缺点。
S220，第二UDM实体根据用户签约数据获取请求消息，向第一UDM实体发送响应消息，响应消息携带与用户标识信息对应的用户签约数据，以使第一UDM实体保存用户签约数据。
可以理解的是，第二UDM实体接收到来自第一UDM实体的Nudm_SDM_GET请求消息后，解析请求消息中携带的用户标识信息，在本地查找与该用户标识信息对应的用户签约数据，并将查找到的用户签约数据封装之响应消息中，将该响应消息发送给第一UDM实体。
可以理解的是，第一UDM实体发送的用户签约数据获取请求消息还可以携带请求获取的用户签约数据类型；用户签约数据类型包括以下一种或者多种：AM签约数据、SM签约数据、SMS签约数据、全类型签约数据、定制类签约数据。
可以理解的是，当用户签约数据获取请求消息携带请求获取的用户签约数据类型时，第二UDM实体根据该用户标识信息和用户签约数据类型查找对应的用户签约数据，并将查找到的用户签约数据封装之响应消息中，将该响应消息发送给第一UDM实体。
本申请实施例提供的数据容灾备份方法，第一UDM实体基于当前标准协议提供的服务向第二UDM实体发送用户签约数据获取请求消息，以使第二UDM实体接收到用户签约数据获取请求消息后，响应于该请求从本地获取用户签约数据，并将用户签约数据反馈给发送该请求的第一UDM实体。如此，第一UDM实体直接从第二UDM实体获取用户签约数据进行保存，以达到容灾备份目的，这种方式安全可靠，大大降低数据同步失败的可能性。
本申请实施例的方案中，第一UDM实体可通过标准协议接口直接从第二UDM实体中获取到用户签约数据，克服了相关的技术方案中第一UDM实体和第二UDM实体只能通过私有协议接口传输用户签约数据的缺点，使得本申请实施例提供的数据容灾备份方法能够适用于不同设备厂商的UDM设备之间的用户签约数据备份，兼容性好，具有广阔的应用场景。
另外，本申请实施例的方案中，第一UDM实体也无需维护业务签约模板数据，大大地降低了运营商、企业客户的日常运维压力。
请参见图7，第二UDM实体在接收第一UDM实体发送的携带用户标识信息的用户签约数据获取请求消息之后，本申请实施例提供的数据容灾备份方法还包括：
S230,第二UDM实体接收第一UDM实体发送的与用户标识信息对应的用户签约数据变更通知订阅请求消息，其中，用户签约数据变更通知订阅请求消息是标准协议定义的消息。
作为示例，第一UDM实体可以通过用户签约数据订阅服务消息Nudm_SDM_Subscribe向第二UDM实体发送用户签约数据变更通知订阅请求消息。第二UDM实体在与用户标识信息对应的用户签约数据发生变更时，向第一UDM实体发送与用户标识信息对应的用户签约数据变更通知。
可以理解的是，Nudm_SDM_Subscribe是当前标准协议定义的服务消息，Nudm_SDM_Subscribe服务允许除UDM自身外的功能实体向UDM实体订阅用户的签约数据变更的通知。由于Nudm_SDM_Subscribe是当前标准协议定义的服务消息，所以第一UDM实体可以通过自身的标准协议接口将该用户签约数据变更通知订阅请求消息发送至第二UDM实体，第二UDM实体可以通过自身的标准协议接口接收该用户签约数据变更通知订阅请求消息。
请参见图8，第二UDM实体在接收第一UDM实体通过用户签约数据订阅服务发送的与用户标识信息对应的用户签约数据变更通知订阅请求消息之后，本申请实施例提供的数据容灾备份方法还包括：
S240,第二UDM实体接收BOSS端发送的用户签约数据修改消息，其中，用户签约数据修改消息携带用户标识信息。
可以理解的是，当用户的签约数据发生修改时，BOSS端向第二UDM实体发送用户签约数据修改消息，该用户签约数据修改消息携带用户标识信息，使第二UDM实体能根据用户标识信息，修改存储在本地的对应于该用户标识信息的用户签约数据。
S250,第二UDM实体根据用户签约数据修改消息，变更与用户标识信息对应的用户签约数据。
可以理解的是，第二UDM实体根据用户签约数据修改消息，对存储在本地的对应于该用户标识信息的用户签约数据进行修改，从而变更与用户标识信息对应的用户签约数据。
S260,第二UDM实体向第一UDM实体发送与用户标识信息对应的用户签约数据变更通知，以使第一UDM实体根据用户签约数据变更通知，更新与用户标识信息对应的用户签约数据。
可以理解的是，由于第二UDM实体对存储在本地的对应于该用户标识信息的用户签约数据进行修改后，用户签约数据发生了变更，而此前第一UDM实体向第二UDM实体订阅了与用户标识信息对应的用户签约数据变更通知，所以第二UDM实体向第一UDM实体发送与用户标识信息对应的用户签约数据变更通知，以使第一UDM实体根据用户签约数据变更通知，更新与用户标识信息对应的用户签约数据，达到数据同步的目的。
以下将通过具体的实例对本申请实施例提供的数据容灾方法作说明。
示例一：
请参见图9，本申请实施例的一种数据容灾方法包括以下方法步骤：
S301，BOSS端向第一UDM实体和第二UDM实体同步发放用户鉴权数据；
S302，BOSS端向第二UDM实体发放用户签约数据；
S303，第一UDM实体根据用户鉴权数据获取至少一个用户标识信息；
S304，第一UDM实体按照预设的时间间隔触发用户签约数据备份操作；
S305，第一UDM实体从至少一个用户标识信息中确定当前用户标识信息；
S306，第一UDM实体向第二UDM实体发送携带当前用户标识信息的Nudm_SDM_GET(AM data)请求消息；
S307，第二UDM实体根据Nudm_SDM_GET(AM data)携带的当前用户标识信息，查找与当前用户标识信息对应的AM签约数据，并发送携带与当前用户标识信息对应的AM签约数据的响应消息给第一UDM实体；
S308，第一UDM实体将从响应消息携带的AM签约数据中解析出的上下行速率、网络切片、RFSP等签约数据保存至本地；
S309，第一UDM实体向第二UDM实体发送携带当前用户标识信息的Nudm_SDM_GET(SM data)请求消息；
S310，第二UDM实体根据Nudm_SDM_GET(SM data)携带的当前用户标识信息，查找与当前用户标识信息对应的SM签约数据，并发送携带与当前用户标识信息对应的SM签约数据的响应消息给第一UDM实体；
S311，第一UDM实体将从响应消息携带的SM签约数据中解析出的网络切片、DNN、QoS等签约 数据保存至本地；
S312，第一UDM实体向第二UDM实体发送携带当前用户标识信息的Nudm_SDM_GET(SMS data)请求消息；
S313，第二UDM实体根据Nudm_SDM_GET(SMS data)携带的当前用户标识信息，查找与当前用户标识信息对应的SMS签约数据，并发送携带与当前用户标识信息对应的SMS签约数据的响应消息给第一UDM实体；
S314，第一UDM实体将从响应消息携带的SMS签约数据中解析出的SMS over NAS、SMS限制类等签约数据保存至本地；
S315，返回步骤S305，直至遍历所有的用户标识信息，以完成对所有用户标识信息对应的用户签约数据进行保存备份。
在图9所示的示例中，第一UDM实体通过发送多条Nudm_SDM_GET请求消息至第二UDM实体，以从第二UDM实体获取用户的AM签约数据、SM签约数据和SMS签约数据，完成对第二UDM实体中的AM签约数据、SM签约数据和SMS签约数据进行保存备份。
示例二：
请参见图10，本申请实施例的一种数据容灾方法包括以下方法步骤：
S401，BOSS端向第一UDM实体和第二UDM实体同步发送用户鉴权数据；
S402，BOSS端向第二UDM实体发送用户签约数据；
S403，第一UDM实体根据用户鉴权数据获取至少一个用户标识信息；
S404，第一UDM实体在接收到网络管理人员的备份指令时，触发用户签约数据备份操作；
S405，第一UDM实体从至少一个用户标识信息中确定当前用户标识信息；
S406，第一UDM实体向第二UDM实体发送携带当前用户标识信息的Nudm_SDM_GET(data set)请求消息；
S407，第二UDM实体根据Nudm_SDM_GET(data set)携带的当前用户标识信息，查找与当前用户标识信息对应的全类型签约数据，并发送携带与当前用户标识信息对应的全类型签约数据的响应消息给第一UDM实体；
S408，第一UDM实体将从响应消息携带的全类型签约数据中解析出的签约数据保存至本地；
S409，第一UDM实体向第二UDM实体发送携带当前用户标识信息的Nudm_SDM_Subscribe(AM data)订阅请求；
S410，第二UDM实体向第一UDM实体返回根据Nudm_SDM_Subscribe(AM data)的订阅响应；
S411，第一UDM实体向第二UDM实体发送携带当前用户标识信息的Nudm_SDM_Subscribe(SM data)订阅请求；
S412，第二UDM实体向第一UDM实体返回根据Nudm_SDM_Subscribe(SM data)的订阅响应；
S413，第一UDM实体向第二UDM实体发送携带当前用户标识信息的Nudm_SDM_Subscribe(SMS data)订阅请求；
S414，第二UDM实体向第一UDM实体返回根据Nudm_SDM_Subscribe(SMS data)的订阅响应；
S415，返回步骤S405，直至遍历所有的用户标识信息，以完成对所有用户标识信息对应的用户签约数据进行保存备份以及订阅用户签约数据变更通知。
在图10所示的示例中，第一UDM实体通过发送一条Nudm_SDM_GET请求消息至第二UDM实体，以从第二UDM实体获取用户的全类型签约数据，完成对第二UDM实体中的全类型签约数据进行保存备份，同时向第二UDM实体订阅用户签约数据变更通知。
可以理解的是，本示例中的步骤S409至S414是可选的步骤，若此前已针对当前用户标识信息提交了相关用户签约数据变更通知的订阅请求，则可省略以上步骤。而且，用户签约数据变更通知的订阅请求消息也不仅限于Nudm_SDM_Subscribe(AM data)、Nudm_SDM_Subscribe(SM data)、Nudm_SDM_Subscribe(SMS data)消息，具体实现过程中还可以包括其他签约数据类型的订阅请求消息，本申请实施例对此不作过多限定。
示例三：
请参见图11，本申请实施例的一种数据容灾方法包括以下方法步骤：
S501，BOSS端向第二UDM实体发送携带用户标识信息的AM签约数据修改消息；
S502，第二UDM实体向第一UDM实体发送携带用户标识信息的AM签约数据变更通知；
S503，第一UDM实体根据接收到的携带用户标识信息的AM签约数据变更通知，更新保存在本地的与用户标识信息对应的AM签约数据；
S504，BOSS端向第二UDM实体发送携带用户标识信息的SM签约数据修改消息；
S505，第二UDM实体向第一UDM实体发送携带用户标识信息的SM签约数据变更通知；
S506，第一UDM实体根据接收到的携带用户标识信息的SM签约数据变更通知，更新保存在本地的与用户标识信息对应的SM签约数据；
S507，BOSS端向第二UDM实体发送携带用户标识信息的SMS签约数据修改消息；
S508，第二UDM实体向第一UDM实体发送携带用户标识信息的SMS签约数据变更通知；
S509，第一UDM实体根据接收到的携带用户标识信息的SMS签约数据变更通知，更新保存在本地的与用户标识信息对应的SMS签约数据。
在图11所示的示例中，在第一UDM实体已向第二UDM实体订阅AM、SM、SMS签约数据变更通通知的情况下，当第二UDM实体中的AM/SM/SMS签约数据发生变更时，第二UDM实体向第一UDM实体发送AM/SM/SMS签约数据变更通知，以使第一UDM实体变更本地保存的AM/SM/SMS签约数据，实现与第二UDM实体的签约数据同步。
进一步可以理解的是，本申请实施例中尽管在附图中以特定的顺序描述操作，但是不应将其理解为要求按照所示的特定顺序或是串行顺序来执行这些操作，或是要求执行全部所示的操作以得到期望的结果。在特定环境中，多任务和并行处理可能是有利的。
请参见图12，示出了本申请实施例提供的第一UDM实体，该第一UDM实体包括：第一发送模块620、第一接收模块610、第一处理模块630和第一保存模块640。
第一发送模块620，被设置成向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息，其中，用户签约数据获取请求消息是标准协议定义的消息；
第一接收模块610，被设置成接收第二UDM实体根据用户签约数据获取请求消息发送的响应消息，响应消息携带与用户标识信息对应的用户签约数据；
第一处理模块630，被设置成从响应消息中获取用户签约数据；
第一保存模块640，被设置成保存用户签约数据。
在一些实施例中，第一发送模块620，还被设置成向第二UDM实体发送与用户标识信息对应的用户签约数据变更通知订阅请求消息，其中，用户签约数据变更通知订阅请求消息是标准协议定义的消息。
在一些实施例中，第一接收模块610，还被设置成接收第二UDM实体发送的与用户标识信息对应的用户签约数据变更通知。
在一些实施例中，第一处理模块630，还被设置成根据用户签约数据变更通知，更新第一保存模块640中与用户标识信息对应的用户签约数据。
在一些实施例中，第一接收模块610，还被设置成获取用户鉴权数据，用户鉴权数据携带用户标识信息。
在一些实施例中，第一处理模块630，还被设置成根据用户鉴权数据获取用户标识信息。
可以理解的是，第一发送模块620发送的用户签约数据获取请求消息还携带请求获取的用户签约数据类型；用户签约数据类型包括以下一种或者多种：AM签约数据、SM签约数据；SMS签约数据、全类型签约数据和定制类签约数据。
可以理解的是，第一发送模块620向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息，具体包括：
按照预设的时间间隔，向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息；
或者，当与第二UDM实体的通信连接中断恢复时，向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息；
或者，当接收到备份指令时，根据备份指令，向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息。
请参见图13，示出了本申请实施例提供的第二UDM实体，该第二UDM实体包括：第二接收模块710和第二发送模块720。
第二接收模块710，被设置成接收第一UDM实体发送的携带用户标识信息的用户签约数据获取请求消息，其中，用户签约数据获取请求消息是标准协议定义的消息；
第二发送模块720，被设置成根据用户签约数据获取请求消息，向第一UDM实体发送响应消息，响应消息携带与用户标识信息对应的用户签约数据，以使第一UDM实体保存用户签约数据。
在一些实施例中，第二接收模块710，还被设置成接收第一UDM实体发送的与用户标识信息对应的用户签约数据变更通知订阅请求消息，其中，用户签约数据变更通知订阅请求消息是标准协议定义的消息。
在一些实施例中，第二接收模块710，还被设置成接收业务运营支撑系统BOSS端发送的用户签约数据修改消息，其中，用户签约数据修改消息携带用户标识信息。
在一些实施例中，第二UDM实体还包括第二处理模块，第二处理模块被设置成根据用户签约数据修改消息，变更与用户标识信息对应的用户签约数据。
在一些实施例中，第二发送模块720还被设置成向第一UDM实体发送与用户标识信息对应的用户签约数据变更通知，以使第一UDM实体根据用户签约数据变更通知，更新与用户标识信息对应的用户签约数据。
可以理解的是，第二接收模块710接收的用户签约数据获取请求消息还携带请求获取的用户签约数据类型；用户签约数据类型包括以下一种或者多种：AM签约数据、SM签约数据；SMS签约数据、全类型签约数据和定制类签约数据。
需要说明的是，上述模块之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其他实施例的相关描述。
请参见图14，示出了本申请实施例提供的一种UDM实体，包括：存储器810、处理器820及存储在存储器810上并可在处理器820上运行的计算机程序。
处理器820和存储器810可以通过总线或者其他方式连接。
存储器810作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器810可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可包括相对于处理器820远程设置的存储器，这些远程存储器可以通过网络连接至该处理器820。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
实现上述实施例的数据容灾备份方法所需的非暂态软件程序以及指令存储在存储器810中，当被处理器820执行时，执行上述实施例中的数据容灾备份方法，例如，执行图2至图8任一所示实施例中的步骤。
本申请实施例包括：第一UDM实体向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息，其中，所述用户签约数据获取请求消息是标准协议定义的消息；第一UDM实体接收所述第二UDM实体根据所述用户签约数据获取请求消息发送的响应消息，所述响应消息携带与所述用户标识信息对应的用户签约数据；第一UDM实体从所述响应消息中获取所述用户签约数据；第一UDM实体保存所述用户签约数据。本申请实施例的方案，第一UDM实体向第二UDM实体发送的用户签约数据获取请求消息是标准协议定义的消息，如此，第一UDM实体可以通过标准协议定义的消息直接从第二UDM实体获取用户签约数据进行保存，以达到容灾备份目的，这种方式安全可靠，大大降低数据同步失败的可能性。
以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
此外，本申请的一个实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被一个处理器或控制器执行，当计算机程序被处理器或控制器执行时， 执行上述实施例中的数据容灾备份方法，例如，执行图2至图8任一所示实施例中的步骤。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。
以上是对本申请的一些实施进行了具体说明，但本申请并不局限于上述实施方式，熟悉本领域的技术人员在不违背本申请范围的前提下还可作出种种的等同变形或替换，这些等同的变形或替换均包含在本申请权利要求所限定的范围内。

Claims (14)

  1. 一种数据容灾备份方法，应用于第一统一数据管理UDM实体，所述方法包括：
    向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息，其中，所述用户签约数据获取请求消息是标准协议定义的消息；
    接收所述第二UDM实体根据所述用户签约数据获取请求消息发送的响应消息，所述响应消息携带与所述用户标识信息对应的用户签约数据；
    从所述响应消息中获取所述用户签约数据；
    保存所述用户签约数据。
  2. 根据权利要求1所述的方法，其中，在向所述第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息之后，所述方法还包括：
    向所述第二UDM实体发送与所述用户标识信息对应的用户签约数据变更通知订阅请求消息，其中，所述用户签约数据变更通知订阅请求消息为标准协议定义的消息。
  3. 根据权利要求2所述的方法，其中，在向所述第二UDM实体发送与所述用户标识信息对应的用户签约数据变更通知订阅请求消息之后，所述方法还包括：
    接收所述第二UDM实体发送的与所述用户标识信息对应的用户签约数据变更通知；
    根据所述用户签约数据变更通知，更新与所述用户标识信息对应的所述用户签约数据。
  4. 根据权利要求1所述的方法，其中，在向所述第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息之前，所述方法还包括：
    获取用户鉴权数据，所述用户鉴权数据携带所述用户标识信息；
    根据所述用户鉴权数据获取所述用户标识信息。
  5. 根据权利要求1所述的方法，其中，所述用户签约数据获取请求消息还携带请求获取的用户签约数据类型；所述用户签约数据类型包括以下一种或者多种：
    接入和移动管理AM签约数据；
    会话管理SM签约数据；
    短信息服务SMS签约数据；
    全类型签约数据；
    定制类签约数据。
  6. 根据权利要求1所述的方法，其中，所述向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息，包括：
    按照预设的时间间隔，向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息；
    或者，当与所述第二UDM实体的通信连接中断恢复时，向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息；
    或者，当接收到备份指令时，根据所述备份指令，向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息。
  7. 一种数据容灾备份方法，应用于第二统一数据管理UDM实体，所述方法包括：
    接收第一UDM实体发送的携带用户标识信息的用户签约数据获取请求消息，其中，所述用户签约数据获取请求消息是标准协议定义的消息；
    根据所述用户签约数据获取请求消息，向所述第一UDM实体发送响应消息，所述响应消息携带与所述用户标识信息对应的用户签约数据，以使所述第一UDM实体保存所述用户签约数据。
  8. 根据权利要求7所述的方法，其中，在接收第一UDM实体发送的携带用户标识信息的用户签约数据获取请求消息之后，所述方法还包括：
    接收所述第一UDM实体发送的与所述用户标识信息对应的用户签约数据变更通知订阅请求消息，其中，所述用户签约数据变更通知订阅请求消息为标准协议定义的消息。
  9. 根据权利要求8所述的方法，其中，在接收所述第一UDM实体发送的与所述用户标识信息对应的用户签约数据变更通知订阅请求消息之后，所述方法还包括：
    接收业务运营支撑系统BOSS端发送的用户签约数据修改消息，其中，所述用户签约数据修改消息携带所述用户标识信息；
    根据所述用户签约数据修改消息，变更与所述用户标识信息对应的所述用户签约数据；
    向所述第一UDM实体发送与所述用户标识信息对应的用户签约数据变更通知，以使所述第一UDM实体根据所述用户签约数据变更通知，更新与所述用户标识信息对应的所述用户签约数据。
  10. 根据权利要求7所述的方法，其中，所述用户签约数据获取请求消息还携带请求消息获取的用户签约数据类型；所述用户签约数据类型包括以下一种或者多种：
    接入和移动管理AM签约数据；
    会话管理SM签约数据；
    短信息服务SMS签约数据；
    全类型签约数据；
    定制类签约数据。
  11. 一种第一统一数据管理UDM实体，包括：
    第一发送模块，被设置成向第二UDM实体发送携带用户标识信息的用户签约数据获取请求消息，其中，所述用户签约数据获取请求消息为标准协议定义的消息；
    第一接收模块，被设置成接收所述第二UDM实体根据所述用户签约数据获取请求消息发送的响应消息，所述响应消息携带与所述用户标识信息对应的用户签约数据；
    第一处理模块，被设置成从所述响应消息中获取所述用户签约数据；
    第一保存模块，被设置成保存所述用户签约数据。
  12. 一种第二统一数据管理UDM实体，包括：
    第二接收模块，被设置成接收第一UDM实体发送的携带用户标识信息的用户签约数据获取请求消息，其中，所述用户签约数据获取请求消息为标准协议定义的消息；
    第二发送模块，被设置成根据所述用户签约数据获取请求消息，向所述第一UDM实体发送响应消息，所述响应消息携带与所述用户标识信息对应的用户签约数据，以使所述第一UDM实体保存所述用户签约数据。
  13. 一种统一数据管理UDM实体，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现如权利要求1至10任意一项所述的数据容灾备份方法。
  14. 一种计算机可读存储介质，存储有计算机程序，其中，所述计算机程序被处理器执行时实现如权利要求1至10中任意一项所述的数据容灾备份方法。
PCT/CN2021/135100 2020-12-10 2021-12-02 数据容灾备份方法、统一数据管理udm实体和存储介质 WO2022121772A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011435456.2A CN114625565A (zh) 2020-12-10 2020-12-10 数据容灾备份方法、统一数据管理udm实体和存储介质
CN202011435456.2 2020-12-10

Publications (1)

Publication Number Publication Date
WO2022121772A1 true WO2022121772A1 (zh) 2022-06-16

Family

ID=81896447

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/135100 WO2022121772A1 (zh) 2020-12-10 2021-12-02 数据容灾备份方法、统一数据管理udm实体和存储介质

Country Status (2)

Country Link
CN (1) CN114625565A (zh)
WO (1) WO2022121772A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115396930A (zh) * 2022-08-19 2022-11-25 中国联合网络通信集团有限公司 容灾处理方法、装置及存储介质
WO2024012203A1 (zh) * 2022-07-11 2024-01-18 中兴通讯股份有限公司 用户数据存储容灾方法、装置、电子设备和存储介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116112910A (zh) * 2023-01-12 2023-05-12 中国联合网络通信集团有限公司 数据处理方法、装置及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110535676A (zh) * 2018-05-25 2019-12-03 中兴通讯股份有限公司 Smf动态容灾的实现方法、装置、设备及存储介质
CN110944361A (zh) * 2018-09-21 2020-03-31 华为技术有限公司 用于负载均衡的方法与网元
WO2020099958A1 (en) * 2018-11-16 2020-05-22 Telefonaktiebolaget Lm Ericsson (Publ) Efficient handling of subscriptions
CN111278034A (zh) * 2020-01-21 2020-06-12 北京佰才邦技术有限公司 一种信息备份方法、装置、存储介质和计算机设备
CN111278010A (zh) * 2020-01-21 2020-06-12 北京佰才邦技术有限公司 一种备份信息方法、装置、存储介质和计算机设备
CN111436160A (zh) * 2019-01-15 2020-07-21 华为技术有限公司 一种局域网通信方法、装置及系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110535676A (zh) * 2018-05-25 2019-12-03 中兴通讯股份有限公司 Smf动态容灾的实现方法、装置、设备及存储介质
CN110944361A (zh) * 2018-09-21 2020-03-31 华为技术有限公司 用于负载均衡的方法与网元
WO2020099958A1 (en) * 2018-11-16 2020-05-22 Telefonaktiebolaget Lm Ericsson (Publ) Efficient handling of subscriptions
CN111436160A (zh) * 2019-01-15 2020-07-21 华为技术有限公司 一种局域网通信方法、装置及系统
CN111278034A (zh) * 2020-01-21 2020-06-12 北京佰才邦技术有限公司 一种信息备份方法、装置、存储介质和计算机设备
CN111278010A (zh) * 2020-01-21 2020-06-12 北京佰才邦技术有限公司 一种备份信息方法、装置、存储介质和计算机设备

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024012203A1 (zh) * 2022-07-11 2024-01-18 中兴通讯股份有限公司 用户数据存储容灾方法、装置、电子设备和存储介质
CN115396930A (zh) * 2022-08-19 2022-11-25 中国联合网络通信集团有限公司 容灾处理方法、装置及存储介质
CN115396930B (zh) * 2022-08-19 2024-05-03 中国联合网络通信集团有限公司 容灾处理方法、装置及存储介质

Also Published As

Publication number Publication date
CN114625565A (zh) 2022-06-14

Similar Documents

Publication Publication Date Title
WO2022121772A1 (zh) 数据容灾备份方法、统一数据管理udm实体和存储介质
EP3468100B1 (en) Method and apparatus for managing network slice
EP1830515B1 (en) A method for transferring the network management configuration information between the element management systems
EP3573390A1 (en) Paging message sending method and related device
CN110192428B (zh) 用于消息处理的方法及相关联的设备和装置
CN108200219B (zh) 数据同步方法、装置、服务器及存储介质
CN108282846B (zh) 一种业务请求处理方法及装置
CN110337071B (zh) 一种基于LoRaWAN实现分组广播的方法及系统
CN104902444A (zh) 一种集群系统的动态重组方法及系统
EP2654242A1 (en) Device management method and apparatus
CN107347202B (zh) 一种终端在网络切片架构下的初始接入方法及装置
BR112019018987A2 (pt) método, aparelho e sistema para adquirir informações do sistema.
CN112540773A (zh) 一种云游戏安装方法、装置、电子设备及存储介质
CN112511993B (zh) 一种群组传输数据的方法、装置及终端
WO2016173077A1 (zh) 用于终端直连通信的设备发现方法、装置和终端
EP2467974B1 (en) Data completion for managed objects
WO2019223478A1 (zh) 信息处理方法及装置、网元及存储介质
CN104221463B (zh) 用于自发执行隐式分离操作的设备和方法
JP6984016B2 (ja) 警報情報を伝送するための方法および装置
WO2015081552A1 (zh) 一种终端接入基站的方法及装置
CN114884805B (zh) 数据传输方法、装置、终端及存储介质
WO2022111113A1 (zh) 频点切换方法、终端、基站和存储介质
EP2426859B1 (en) Method and server for transferring large object
EP3972197A1 (en) Method and apparatus for customer premise equipment configuration management
CN113660121A (zh) 基于分布式系统的信息管理方法、装置及计算机存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21902479

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21902479

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 021123)