MCPTT user management method in IMS network

Abstract

The invention discloses an MCPTT user management method in an IMS network, and belongs to the technical field of wireless communication network management and user data configuration.The method is executed by an operation maintenance system and comprises the following steps that a user management request is received, an MCX system interface is called to conduct first operation on user data in an MCX system according to the user management request, and the MCX system interface is called to conduct second operation on the user data in the MCX system; calling an API (Application Program Interface) of the IMS system to carry out corresponding second operation on the user data in the IMS system; wherein in the calling process, if the first operation succeeds and the second operation fails, a rollback operation is executed; according to the method, a technical closed loop of unified user request receiving, dual-system collaborative issuing, failure real-time sensing and cross-system automatic rollback is constructed, MCX service issuing and IMS network user data management are deeply coupled, and fundamental transformation from manual asynchronous operation to system active synchronous management and control is achieved.

Description

Technical Field

[0001] This invention belongs to the field of wireless communication network management and user data configuration technology, and relates to a method for managing MCPTT users in an IMS network. Background Technology

[0002] The MCX system, or critical communication system, includes MCPTT (critical communication group call), MCVideo (critical communication video), and MCData (critical communication data), all built on the IMS (IP Multimedia Subsystem) network architecture. This dependency determines a fundamental prerequisite for the system's normal operation: a corresponding user account must be synchronously created for each MCX user in the IMS network, and it must be ensured that MCX users can successfully complete registration and authentication in the IMS system.

[0003] However, the MCX system and the IMS system are physically independent, and their user data is stored separately in the MCX system's own database and the IMS system's HSS (Home Subscriber Server). Therefore, ensuring the consistency of user registration and authentication data between the two systems has become a key technical challenge. Currently, there are two main methods for user data management in the industry: First, operations personnel manually perform operations (such as adding, modifying, and deleting users) on the management platforms of both the MCX and IMS systems, relying on manual comparison to ensure data consistency; second, after completing the operation in one system, the user data is exported and then asynchronously imported into the other system using scripts or tools.

[0004] Essentially, the aforementioned existing technologies all belong to the asynchronous user management model, with very weak data correlation between the two systems, thus revealing many problems in practice: First, the operation is inefficient and prone to errors. Maintenance personnel need to perform repetitive or similar operation procedures in two independent systems, which is not only heavy and inefficient, but also prone to errors due to manual operation.

[0005] Secondly, data consistency is difficult to guarantee. Because operations are asynchronous, during user additions, information modifications, or account deletions, it's easy for one system to succeed while another fails. Furthermore, when user data is modified in one system, the other system cannot directly detect it. If maintenance personnel fail to synchronize updates, it will directly lead to data inconsistency. The consequences of this inconsistency are very serious; it can cause user registration and authentication failures on the IMS network, thus rendering critical services such as MCPTT unusable.

[0006] Third, the system maintenance costs are high. Whether adding a new user or modifying or deleting an existing user, maintenance personnel must remember to perform the operation in both systems, which carries a high risk of oversight. Once a business failure is caused by data inconsistency, the difficulty of fault location and troubleshooting is extremely high because the problem involves two independent systems. It requires cross-checking logs from multiple sources, which significantly increases maintenance time and costs.

[0007] In summary, current asynchronous user management solutions have significant shortcomings. There is an urgent need in this field for an innovative method that enables synchronous and collaborative user lifecycle management between the MCX system and the IMS system, in order to fundamentally solve the data consistency problem, improve operational efficiency, and reduce maintenance costs. Summary of the Invention

[0008] The purpose of this invention is to overcome the technical bottleneck in existing MCX system user management technology, which is that asynchronous operation and strong data verification are disconnected, and the consistency of user data across systems cannot be effectively guaranteed. This invention provides an MCPTT user management method in an IMS network. Through the linkage of multiple modules such as unified reception of user requests, collaborative issuance by two systems, real-time failure detection, and cross-system rollback, it realizes closed-loop automated management from user creation, data synchronization to exception handling and state restoration, fundamentally preventing user service registration and usage failures caused by data inconsistency.

[0009] The technical solution adopted in this invention is an MCPTT user management method in an IMS network. The key is that the above method is executed by the operation and maintenance system and includes the following steps: receiving user management requests and user data. The user management requests include adding users, modifying user data, or deleting users. The user data includes MC account and login password used for MCX system business authentication, and registration authentication data used for IMS network access authentication. Based on the aforementioned user management request, the MCX system interface is invoked to perform a first operation on the user data in the MCX system, including creating a user, modifying user data, and deleting a user. After the first operation is successful, the IMS system API interface is invoked according to the user management request to send the registration and authentication data to the HSS of the IMS network, and a second operation corresponding to the first operation is performed on the user data in the IMS system.

[0010] Specifically, if the second operation fails, a rollback operation is performed; the rollback operation includes rolling back the data from the second operation in the IMS system and undoing the effects of the first operation in the MCX system.

[0011] Specifically, the aforementioned registration and authentication data includes IMPI information, IMPU information, KI information, OP / OPc information, and AMF information.

[0012] Furthermore, when the above user management request is to add a user: the first operation refers to creating a user account in the MCX system; the second operation refers to creating a user account in the HSS of the IMS system; if creation in the HSS fails, the above rollback operation includes rolling back the data on the HSS and deleting the user data already created in the MCX system. Adding user actions specifically includes the following steps: S1. Receiving Requests and Preparing Data: The operation and maintenance system receives user management requests to add users; Adding users to S2 and MCX systems: Call the MCX system interface to create a user account in the MCX system; S3 and IMS systems add users simultaneously: If a user account is successfully created in the MCX system, the operation and maintenance system calls the user addition API interface exposed by the IMS system to send the registration and authentication data to the HSS of the IMS network, so as to create the user account synchronously in the IMS system. If creation on the HSS fails, a rollback operation is performed, which includes rolling back the data on the HSS and deleting the corresponding user data already created in the MCX system.

[0013] Furthermore, if creating a user account in the MCX system fails, the process is terminated, and the creation operation is not performed in the HSS.

[0014] Furthermore, when the aforementioned user management request involves modifying user data: first, the user data is modified in the MCX system. If the modification is successful, the corresponding user data is modified in the HSS of the IMS system. If the modification in the HSS fails, the aforementioned rollback operation includes rolling back the data on the HSS and restoring the modified user data in the MCX system.

[0015] Furthermore, when the aforementioned user management request is to delete a user: first delete the user in the MCX system. If the deletion is successful, then delete the corresponding user data in the HSS of the IMS system. If the deletion in the HSS fails, then generate an alarm message to prompt the administrator to check the cause and manually process the user data in the HSS system.

[0016] Specifically, the steps of calling the IMS system's API interface are completed by the operation and maintenance system integrating and executing scripts provided by the IMS system.

[0017] It should be noted that business-related data is distributed and managed independently on the MCX system and the IMS system.

[0018] Compared with the prior art, the present invention has the following advantages: This invention proposes a method for managing MCPTT users in an IMS network. By constructing a closed-loop technology of unified user request reception, dual-system collaborative distribution, real-time failure detection, and automatic cross-system rollback, it deeply couples MCX service distribution with IMS network user data management, achieving a fundamental shift from manual asynchronous operation to proactive system synchronization control.

[0019] Specifically, the technical solution of the present invention has the following advantages: First, this invention fundamentally guarantees data consistency. Addressing the core flaw of existing asynchronous user management methods, which easily lead to inconsistencies between user data in the MCX and IMS systems, resulting in business registration failures, this invention's embodiments verify that it can ensure strong consistency between the two systems through a transactional control mechanism across all scenarios, including adding, modifying, and deleting users. Through the core logic of "MCX first, then IMS, with bidirectional rollback in case of failure," it fundamentally eliminates the data silo problem caused by a successful operation in one system while the operation in the other fails, filling a gap in existing user data distribution technologies in this critical process.

[0020] Secondly, this invention significantly improves user management efficiency and operational accuracy. Addressing the efficiency bottleneck of existing methods that require repetitive operations in two systems or rely on manual synchronization, this invention provides a unified entry point through the operation and maintenance system, achieving "one-time entry, dual-end synchronization." This invention demonstrates that the entire user management process is automated, integrating previously discrete multi-step operations into a single atomic transaction, significantly improving efficiency and completely avoiding errors and omissions that may be introduced by manual intervention, resulting in a qualitative leap in operational accuracy.

[0021] Third, this invention forms a complete closed loop for user lifecycle management. The core advantage of this invention lies in achieving a complete automated management closed loop from user creation and data synchronization to anomaly handling and state restoration. The system of this invention not only completes synchronized user management under normal circumstances, but also proactively triggers a rollback mechanism when IMS system operations fail, or provides precise alerts when rollback is not possible. This overcomes the passivity and high cost of relying solely on post-event troubleshooting by maintenance personnel, achieving truly intelligent operation and maintenance.

[0022] Fourth, the system of this invention exhibits enhanced robustness and ease of maintenance. For telecommunications systems operating in complex environments such as network outages and high system loads, the embedded anomaly handling and rollback mechanisms of this invention endow the system with strong self-recovery capabilities. Whether adding, modifying, or deleting users, the system can properly handle various abnormal states, ensuring the stability of the system data baseline. Simultaneously, clear success / failure returns and alarm information make fault location extremely intuitive, greatly reducing maintenance difficulty and costs.

[0023] Fifth, this invention possesses high architectural compatibility and implementation feasibility. By integrating existing MCX interfaces with IMS standard APIs (such as RESTful APIs and scripts) through the operation and maintenance system, this invention eliminates the need for deep modifications to MCX or IMS core network elements. This makes the implementation cost of this invention controllable, the integration path clear, and facilitates rapid deployment and promotion in existing networks. Simultaneously, this invention supports independent distribution of service data, reflecting a design philosophy that combines mandatory consistency of core authentication data with flexible management of service data. While ensuring the reliability of core processes, it maximizes the flexibility of service deployment. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the user data distribution process according to an embodiment of the present invention.

[0025] Figure 2 This is a schematic diagram of the MC login and registration authentication process according to an embodiment of the present invention. Detailed Implementation

[0026] Various exemplary embodiments of the present invention will now be described in detail. This detailed description should not be considered as a limitation of the present invention, but rather as a more detailed description of certain aspects, features, and embodiments of the present invention.

[0027] It should be understood that the terminology used in this invention is merely for describing particular embodiments and is not intended to limit the invention. Furthermore, with respect to numerical ranges in this invention, it should be understood that each intermediate value between the upper and lower limits of the range is also specifically disclosed. Any stated value or intermediate value within a stated range, as well as each smaller range between any other stated value or intermediate value within said range, is also included in this invention. The upper and lower limits of these smaller ranges may be independently included or excluded from the range.

[0028] Unless otherwise stated, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. While only preferred methods and materials have been described herein, any methods and materials similar or equivalent to those described herein may be used in the implementation or testing of this invention. All references to this specification are incorporated by way of citation to disclose and describe methods and / or materials associated with those references. In the event of any conflict with any incorporated reference, the content of this specification shall prevail.

[0029] Various modifications and variations can be made to the specific embodiments described in this specification without departing from the scope or spirit of the invention, as will be apparent to those skilled in the art. Other embodiments derived from this specification will also be readily apparent to those skilled in the art. This specification and embodiments are merely exemplary.

[0030] The terms “include,” “including,” “have,” “contain,” etc., used in this article are all open-ended terms, meaning that they include but are not limited to. Example

[0031] This embodiment provides a method for managing MCPTT users in an IMS network, which is executed by an operation and maintenance system that integrates the management capabilities of the MCX system and the IMS system.

[0032] The operation and maintenance system in this embodiment provides users with a unified operation entry point through a web interface, and has integrated the RESTful API scripts provided by the IMS system for communication with the HSS of the IMS core network.

[0033] Taking user "10001" as an example, this demonstrates the entire process of adding, modifying, and deleting users.

[0034] The core registration and authentication data involved includes: MCX business authentication data: MC account is 10001, login password is a123456.

[0035] The registration and authentication data for IMS network access includes: IMPI: 460010000000101; IMPU: sip:10001@example.com; KI: 128 bit; OP: 128 bit; AMF: 16 ​​bits.

[0036] See the attached diagram for the user data distribution process and the MC login and registration authentication process in this embodiment. Figure 1 and 2 .

[0037] Scenario 1: Adding a user, specifically including the following steps: S1. Receiving Requests and Preparing Data: The operation and maintenance system receives user addition requests and user data from the administrator. The user data includes all the necessary registration and authentication data for user "10001", such as MC account, login password, IMPI information, IMPU information, KI information, OP information, and AMF information, as well as optional ue_init_config business configuration information.

[0038] Adding users to S2 and MCX systems: The operation and maintenance system first calls the MCX system's interface to create a user account in the MCX system, which is the first operation. The data distributed includes MC account and login password for business login, and IMPI, IMPU, KI, OP, AMF and ue_init_config are also distributed to the MCX system for subsequent synchronization to the terminal. Among them, IMPI, KI, OP, AMF and other data are also the core parameters for identity authentication when the terminal initiates the "Register" registration request. If adding a user to the MCX fails, the MCX system will return a failure message, and the operation and maintenance system will immediately terminate the entire user addition process and will not subsequently call the IMS system's API. If the user addition to the MCX is successful, the MCX system will return a success message, and the operation and maintenance system will continue to execute step S3.

[0039] S3 and IMS systems add users simultaneously: After a user is successfully added to the MCX system, the operation and maintenance system calls the integrated IMS API script to send the registration and authentication data, including IMPI, IMPU, KI, OP, and AMF, to the HSS of the IMS network to request the creation of the corresponding user, which is to perform the second operation.

[0040] If IMS successfully adds a user, HSS will return a success message, i.e., return "200", indicating that the user addition process is complete.

[0041] If adding a user in IMS fails, HSS returns a failure message, i.e., "401". The operation and maintenance system immediately performs a rollback operation, i.e., rolls back the operation on HSS and calls the MCX system interface to delete the data of user "10001" that was successfully created in step S2.

[0042] Scenario 2: Modifying user information, specifically including the following steps: S1. Receiving Requests and Preparing Data: The operation and maintenance system receives a request from the administrator to modify the information of user "10001"; The request includes user data that needs to be updated, such as a new login password or new KI and OP keys.

[0043] S2 and MCX system modifications: The operation and maintenance system first calls the interface of the MCX system to update the data of user "10001" in the MCX system, which is to perform the first operation.

[0044] If the MCX modification fails, the MCX system will return a failure message, and the operation and maintenance system will immediately terminate the entire modification process and will not subsequently call the IMS system's API.

[0045] If the MCX modification is successful, the MCX system will return a success message, and the operation and maintenance system will continue to execute step S3.

[0046] S3 and IMS systems were modified simultaneously: After the MCX system is successfully modified, the operation and maintenance system calls the integrated IMS API script to send the new KI, OP and other registration and authentication data that need to be synchronized to the HSS of the IMS network, requesting the update of the corresponding user data, that is, to perform the second operation.

[0047] If the IMS modification is successful, the HSS will return a success message, and the user information modification process will be completed.

[0048] If the IMS modification fails, the HSS will return a failure, and the operation and maintenance system will immediately perform a rollback operation, that is, roll back the data modification on the HSS and call the MCX system interface to restore the relevant data of user "10001" to the state before the modification.

[0049] Scenario 3: Deleting user information, specifically including the following steps: S1, Receive request: The operation and maintenance system receives a request from the administrator to delete user "10001" along with corresponding user data, such as the MC account and login password.

[0050] S2 and MCX systems deleted: The operation and maintenance system first calls the interface of the MCX system to delete the data of user "10001" in the MCX system, which is to perform the first operation.

[0051] If the MCX deletion fails, the MCX system will return a failure message, and the operation and maintenance system will immediately terminate the entire deletion process without subsequently calling the IMS system's API.

[0052] If the MCX is successfully deleted, the MCX system returns a success message, and the operation and maintenance system continues to execute step S3.

[0053] S3 and IMS systems simultaneously delete: After the deletion is successful in the MCX system, the operation and maintenance system calls the integrated IMS API script to request the deletion of the data of the corresponding user "10001" in the HSS of the IMS network, that is, to perform the second operation.

[0054] If IMS deletion is successful, HSS will return a success message, and the user deletion process will be complete.

[0055] If IMS deletion fails, HSS will return a failure message.

[0056] Since the user data in the MCX system has been physically deleted and is irreversible, automatic rollback cannot be performed. At this time, the operation and maintenance system generates and reports an alarm message, clearly prompting the administrator: "User 10001 has been deleted from the MCX system, but deletion failed in IMS-HSS. Please check the HSS status and manually clean up the user data." After completing the user management process described above, such as adding users or modifying user data, when user "10001" logs in on the MC terminal, the terminal will use authentication parameters obtained from the MCX system (such as IMPI, KI, OP, AMF, etc.) to initiate a registration request to the IMS network (as shown in the attached document). Figure 2 (As shown). Because the method of this invention ensures that the core authentication parameters stored in the MCX system and the IMS HSS are completely consistent, the authentication calculation on the network side and the calculation result on the terminal side will inevitably match, thereby ensuring the success of the IMS registration process and enabling the MCPTT service to be used normally.

[0057] In this embodiment, ue_init_config and other business data can be distributed separately on the MCX and IMS. This process does not affect the consistency of the core registration and authentication data. That is, business-related data is distributed and managed independently on the MCX system and the IMS system.

[0058] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for managing MCPTT users in an IMS network, characterized in that, The method is executed by the operation and maintenance system and includes the following steps: receiving user management requests and user data, wherein the user management requests include adding users, modifying user data, or deleting users; the user data includes MC account and login password for MCX system business authentication, and registration authentication data for IMS network access authentication; Based on the user management request, the MCX system interface is invoked to perform a first operation on the user data in the MCX system, including creating a user, modifying user data, and deleting a user. After the first operation is successful, the IMS system API interface is invoked according to the user management request to send the registration and authentication data to the HSS of the IMS network and perform a second operation on the user data in the IMS system corresponding to the first operation.

2. The method according to claim 1, characterized in that, If the second operation fails, a rollback operation is performed; the rollback operation includes rolling back the data of the second operation in the IMS system and undoing the effects of the first operation in the MCX system.

3. The method according to claim 1, characterized in that, The registration and authentication data includes IMPI information, IMPU information, KI information, OP / OPc information, and AMF information.

4. The method according to claim 1, characterized in that, When the user management request is to add a user: the first operation refers to creating a user account in the MCX system; the second operation refers to creating a user account in the HSS of the IMS system; If creation in the HSS fails, the rollback operation includes rolling back the data on the HSS and deleting the user data already created in the MCX system. Adding user actions specifically includes the following steps: S1. Receiving Requests and Preparing Data: The operation and maintenance system receives user management requests to add users; Adding users to S2 and MCX systems: Call the MCX system interface to create a user account in the MCX system; S3 and IMS systems add users simultaneously: If a user account is successfully created in the MCX system, the operation and maintenance system calls the user addition API interface exposed by the IMS system to send the registration and authentication data to the HSS of the IMS network, so as to create the user account synchronously in the IMS system. If creation on the HSS fails, a rollback operation is performed, which includes rolling back the data on the HSS and deleting the corresponding user data already created in the MCX system.

5. The method according to claim 3, characterized in that, If creating a user account in the MCX system fails, the process will be terminated, and the creation operation will not be performed in the HSS.

6. The method according to claim 1, characterized in that, When the user management request is to modify user data: first modify the user data in the MCX system; if the modification is successful, then modify the corresponding user data in the HSS of the IMS system. If modification in the HSS fails, the rollback operation includes rolling back the data on the HSS and restoring the modified user data in the MCX system.

7. The method according to claim 1, characterized in that, When the user management request is to delete a user: first delete the user in the MCX system; if the deletion is successful, then delete the corresponding user data in the HSS of the IMS system. If deletion in the HSS fails, an alarm message is generated to prompt the administrator to check the cause and manually process the user data in the HSS system.

8. The method according to claim 1, characterized in that, The step of calling the API interface of the IMS system is completed by the operation and maintenance system integrating and executing the script provided by the IMS system.

9. The method according to claim 1, characterized in that, Business-related data is distributed and managed independently on the MCX system and the IMS system.

Images