A terminal intelligent non-perception upgrading method and system and a terminal device

Abstract

The application provides a terminal intelligent non-perception upgrade method, which comprises the following steps: first, according to the upgrade instruction, completing pre-check and right confirmation, and then establishing a private upgrade data channel with the server, completing two-way identity authentication and channel trust confirmation; then, through the channel, receiving the upgrade package in the block transmission and breakpoint resume transmission mode, completing block-by-block and full-amount integrity confirmation, and then according to the multi-dimensional business state matrix, determining the idle upgrade opportunity, writing the confirmed upgrade image into the dual-partition backup area and completing partition readiness confirmation; then, atomically modifying the start flag and completing the pre-start check, and after restarting the terminal, carrying out multi-level progressive health check, and after the check, carrying out two-way confirmation with the server; finally, completing the whole-process hash chain check, permanently switching the partition role, persisting the state, and generating the final confirmation voucher of the successful upgrade. The application solves the problem that the prior art lacks a terminal intelligent non-perception upgrade method which takes into account business non-perception, safe and controllable transmission upgrade and large scale.

Description

Technical Field

[0001] This invention relates to the field of terminal intelligent seamless upgrade technology, and in particular to a terminal intelligent seamless upgrade method and system. Background Technology

[0002] With the widespread application of IP voice communication technology, tens of thousands or even hundreds of thousands of SIP voice terminals have been deployed on a large scale in enterprise, operator, financial, energy and other scenarios. Remote upgrade of terminal firmware is a core necessity for device function iteration, vulnerability repair and operation and maintenance management.

[0003] Existing SIP terminal upgrade technologies can be mainly divided into two categories. One category is the traditional approach, which primarily involves manual upgrades on a per-device basis or TFTP / HTTP broadcast upgrades. The other category is an improved approach, which involves localized optimizations in areas such as server distribution strategies, embedded dual-partition upgrades, and SIP protocol-borne upgrade data, attempting to address the shortcomings of the traditional upgrade model.

[0004] However, existing upgrade solutions are not systematically designed for the characteristics of real-time voice services on SIP terminals. They not only suffer from problems such as coupling between signaling and upgrade channels, leading to upgrade traffic preempting service bandwidth, causing call interruptions and registration failures, but also cannot achieve reliable transmission and breakpoint resumption of large upgrade packets in weak network environments. Furthermore, they lack state control and bidirectional synchronization mechanisms covering the entire upgrade process, which can easily lead to process skipping, inconsistencies between terminal and server states, and untraceable anomalies. In addition, the lack of a complete dual-partition security upgrade and atomic rollback mechanism increases the risk of terminal bricking during upgrades. Moreover, in large-scale distributed deployment scenarios, they cannot adapt to complex network environments such as NAT traversal, achieve closed-loop management of batch upgrades, or meet the high security and compliance requirements of identity trust, data tamper-proofing, and full-process auditability. Overall, they cannot simultaneously meet the core needs of seamless service, high-reliability transmission, secure and controllable upgrades, and efficient large-scale operation and maintenance. Summary of the Invention

[0005] Based on this, the purpose of this invention is to provide a terminal intelligent seamless upgrade method, system, and terminal device, aiming to solve the problem in the prior art of lacking a terminal intelligent seamless upgrade method that takes into account seamless service, high transmission reliability, secure and controllable upgrades, and efficient large-scale operation and maintenance.

[0006] A terminal intelligent seamless upgrade method according to an embodiment of the present invention includes: Based on the upgrade command, a pre-verification is performed to complete the pre-authorization, and then a private TCP upgrade data channel is established with the UMS server to complete two-way identity authentication and channel trust authorization. The upgrade packet is received through the TCP upgrade data channel in a block-by-block transmission and breakpoint resume mode, and the block-by-block real-time rights confirmation and full integrity rights confirmation are completed. Then, the idle upgrade opportunity is determined based on the multi-dimensional business status matrix. After the condition of no business interference is met, the rights-confirmed upgrade image is written to the spare partition of the dual partition, and the partition writing and ready rights confirmation are completed. Complete the atomic modification of the boot flag and the pre-boot check to complete the pre-boot ready authorization, confirm that it can boot normally after restart, execute the terminal restart, and perform multi-level progressive health checks in sequence after booting from the spare partition, and complete bidirectional authorization with the UMS server after all checks pass. Complete the entire upgrade process with the UMS server through hash chain verification, permanently switch partition roles and persist the entire process status, and generate the final confirmation certificate for successful upgrade.

[0007] In addition, the terminal intelligent seamless upgrade method according to the above embodiments of the present invention may also have the following additional technical features: Furthermore, the authorization certificate generated by each status node adopts a hash chain structure, and the authorization certificate of the next node contains at least the hash value of the previous node, the unique task ID, and the unique terminal device ID.

[0008] Furthermore, the terminal can obtain the upgrade task in either Push mode or Pull mode. The Push mode is characterized by the UMS server sending an upgrade task instruction to the terminal through a SIP signaling channel, and the terminal establishing a private TCP upgrade data channel with the UMS server based on the upgrade packet metadata in the instruction. The Pull mode involves the terminal periodically polling the UMS server for upgrade tasks via a SIP signaling channel or a private TCP channel. If there is an upgrade task to be executed for the corresponding terminal, the terminal obtains the upgrade package metadata and establishes a private TCP upgrade data channel.

[0009] Furthermore, the block-by-block real-time rights confirmation specifically means that each data block must complete four layers of verification: transmission integrity rights confirmation, hash anti-tampering rights confirmation, sequence number continuity rights confirmation, and storage persistence rights confirmation. Only after all four layers pass the verification can the block be confirmed as having been received. The breakpoint resume mechanism works as follows: if the TCP connection is interrupted during transmission, the terminal persists a list of block indexes that have been verified and confirmed, along with their corresponding hash values. After reconnection, the terminal carries the list of confirmed blocks and hash values. After verification by UMS, the transmission continues from the missing block index without retransmitting the entire data.

[0010] Furthermore, the multi-dimensional business status matrix covers at least the call status, conference status, RTP audio stream activity, user operation status, CPU load status, idle memory status, and SIP registration status. The multi-level idle threshold verification and continuous stability observation are as follows: First, the basic idle threshold verification of multiple dimensions is completed. After passing the verification, the system enters a stable observation window for a preset time period. Only when all dimensions in the window continuously meet the idle threshold are the system finally determined to meet the idle admission conditions.

[0011] Furthermore, the multi-level progressive health check specifically involves sequentially performing kernel and system startup health checks, basic network and SIP registration health checks, voice service core function health checks, and system stability and full-function compliance checks. If a previous level of check fails, an atomic rollback is immediately triggered, and the next level of check is never initiated. The atomic rollback operation specifically involves the bootloader performing an atomic write operation to modify the boot flag, rolling back the boot partition to the original running partition, performing a terminal restart after a readback and verification, and completing a health check after the rollback to confirm that the terminal has returned to normal business status.

[0012] Furthermore, if any node fails to confirm ownership during the upgrade process, an atomic rollback operation is triggered. This process includes rollback trigger confirmation, rollback execution confirmation, post-rollback health check, and final rollback completion confirmation, ensuring that the terminal is restored to its normal business state before the upgrade.

[0013] Another objective of this invention is to provide a terminal intelligent seamless upgrade system, including a SIP server, an upgrade management server UMS, and multiple SIP terminals, which work together to achieve the above-mentioned terminal intelligent seamless upgrade method. The SIP server is used to complete the registration and keep-alive interaction with the SIP terminal through the SIP signaling channel, maintain the registration status and keep-alive information of the terminal, and open the terminal registration status query interface to UMS. The UMS server is used for upgrade package management, upgrade task creation and scheduling, and provides a private TCP upgrade data channel that is completely independent of the SIP signaling channel. It receives the authorization certificate of each status node reported by the terminal and completes remote verification. After the verification is successful, it returns the corresponding authorization certificate to the terminal. Without authorization, the terminal is strictly prohibited from entering the next status. The SIP terminal is used to complete SIP registration and keep-alive, local authorization of each status node in the entire upgrade process, block reception and verification of upgrade packets, idle state determination, upgrade execution, rollback control and result reporting.

[0014] Furthermore, the UMS and the SIP terminal adopt a completely decoupled architecture between the SIP signaling channel and the private TCP upgrade data channel. The SIP signaling channel only carries registration keep-alive, status interaction and upgrade instructions, and does not carry any upgrade data traffic throughout the process.

[0015] Another objective of this invention is to provide a SIP terminal device, including a SIP protocol stack module, a service status monitoring module, a private TCP transmission module, a status confirmation core module, an upgrade control module, an A / B dual-partition storage module, and an upgrade boot module, for executing the terminal intelligent seamless upgrade method described above. The SIP protocol stack module is used to complete registration and keep-alive with the SIP server through the SIP signaling channel and maintain the SIP registration status; The service status monitoring module is used to collect the multi-dimensional operating status of the terminal for SIP voice services in real time, construct and update the service status matrix, and complete the confirmation of idle access status. The private TCP transmission module is used to establish a private TCP upgrade data channel with UMS that is independent of the SIP signaling channel, to perform block transmission of upgrade packets, breakpoint resumption, and data encryption and decryption, and to complete the status confirmation of the transmission stage. The core module for status confirmation is used to coordinate the status verification, credential generation, and two-way synchronization of the entire upgrade process, and to perform local confirmation, credential reporting, and permission reception for each status node. Without permission, it is strictly forbidden to trigger the next status action. The upgrade control module is used to coordinate the entire upgrade process, including upgrade package verification, idle state monitoring, upgrade partition writing, startup flag modification, rollback control and upgrade result reporting. The A / B dual-partition storage module is divided into a current running partition and a backup upgrade partition, which are used to store system images and upgrade data, and provide a carrier for partition writing, switching, and rollback status confirmation. The upgrade boot module is used to select the boot partition according to the boot flag bit when the terminal starts, perform a progressive four-level health check on the new partition, and trigger an atomic automatic rollback process when the health check fails.

[0016] This invention achieves pre-verification of rights based on upgrade commands, establishes a private TCP upgrade data channel with the UMS server and completes two-way identity authentication and channel trust confirmation, then receives upgrade packets through the TCP upgrade data channel in a block-by-block real-time and full-integrity manner, determines idle upgrade opportunities based on a multi-dimensional business status matrix, writes the confirmed upgrade image to the dual-partition backup partition, performs atomic modification of the startup flag and pre-startup boot verification, executes terminal restart and performs multi-level progressive health checks, and then completes full-process hash chain verification, permanent partition role switching and full-process state persistence with the UMS server to generate a final confirmation certificate for successful upgrade. This makes the entire upgrade process rigorous and the process closed-loop controllable, without relying on fragmented steps without stateless management to perform upgrade operations, without using a transmission architecture that couples signaling and upgrade channels to cause bandwidth contention, and without relying on a forced upgrade triggering method without idle judgment. The upgrade transmission is stable, the service is not interfered with, and the status is traceable. Furthermore, this solution achieves automatic protection against upgrade anomalies through dual partitioning and atomic operations, ensuring secure and stable terminal upgrades without requiring continuous centralized management or additional hardware redundancy. Therefore, this invention addresses the lack of a smart, seamless terminal upgrade method in existing technologies that balances seamless service delivery, high transmission reliability, secure and controllable upgrades, and efficient large-scale maintenance. Attached Figure Description

[0017] Figure 1 This is a flowchart of the terminal intelligent seamless upgrade method in the first embodiment of the present invention. Detailed Implementation

[0018] To facilitate understanding of the present invention, a more complete description will be given below with reference to the accompanying drawings. Several embodiments of the invention are illustrated in the drawings. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0020] Example 1 Please see Figure 1 The figure shows a terminal intelligent seamless upgrade method in the first embodiment of the present invention, which specifically includes steps S01-S04.

[0021] S01, based on the upgrade command, performs pre-verification to complete pre-authorization, then establishes a private TCP upgrade data channel with the UMS server, and completes two-way identity authentication and channel trust authorization.

[0022] Specifically, the terminal obtains upgrade tasks using either Push or Pull mode. In Push mode, the UMS server sends upgrade task instructions to the terminal via a SIP signaling channel, and the terminal establishes a private TCP upgrade data channel with the UMS server based on the upgrade packet metadata in the instruction. In Pull mode, the terminal periodically polls the UMS server for upgrade tasks via either a SIP signaling channel or a private TCP channel. If a corresponding upgrade task exists for the terminal, the terminal obtains the upgrade packet metadata and establishes a private TCP upgrade data channel. In practical implementation, two upgrade task acquisition methods are provided to the terminal. The SIP signaling channel only carries instructions and not data, decoupling the signaling and data channels. This adapts to complex network environments such as public networks and NAT traversal, ensuring accurate reach of upgrade tasks and channel establishment, avoiding the problem of a single mode being unsuitable for distributed deployment scenarios. Furthermore, it ensures that SIP terminals in different network environments can normally obtain upgrade tasks and establish dedicated upgrade channels, improving the reachability and adaptability of upgrade tasks in large-scale deployment scenarios.

[0023] S02, the upgrade packet is received through the TCP upgrade data channel in the form of block transmission and breakpoint resume transmission, and the block-by-block real-time confirmation and full integrity confirmation are completed. Then, the idle upgrade time is determined based on the multi-dimensional business status matrix. After the condition of no business interference is met, the confirmed upgrade image is written to the backup partition of the dual partition, and the partition writing and ready confirmation are completed.

[0024] Specifically, the block-by-block real-time rights confirmation involves four layers of verification for each data block: transmission integrity rights confirmation, hash anti-tampering rights confirmation, sequence number continuity rights confirmation, and storage persistence rights confirmation. Only after all four layers pass the verification is the reception of that block confirmed. The breakpoint resumption mechanism works as follows: if the TCP connection is interrupted during transmission, the terminal locally persists a list of verified and confirmed block indices and their corresponding hash values. Upon reconnection, the terminal carries the list of verified blocks and their hash values. After UMS verification, transmission continues from the missing block index, without retransmitting the entire dataset. In practice, four layers of verification achieve precise verification at the data block level, breakpoint resumption ensures smooth continuation after transmission interruption, and local persistence ensures that the transmission status is not lost even when power is lost. This guarantees the reliability, integrity, and anti-tampering of large-volume upgrade package transmission in weak network environments, solving problems such as transmission interruption, data corruption, and duplicate transmission. This significantly improves the success rate of upgrade package transmission in weak network conditions, avoids wasting bandwidth through full retransmission, ensures that upgrade data is undamaged, untampered, and without block loss, and that the transmission status is traceable.

[0025] Furthermore, the multi-dimensional business status matrix covers at least call status, conference status, RTP audio stream activity, user operation status, CPU load status, idle memory status, and SIP registration status. The multi-level idle threshold verification and continuous stability observation specifically involve: first, completing basic idle threshold verification across multiple dimensions; after passing, entering a preset time period for stable observation; and only when all dimensions continuously meet the idle thresholds within the window is the idle access condition finally met. In practical implementation, by comprehensively monitoring terminal services and system status, and using multi-level thresholds and a stable window to avoid instantaneous idle misjudgments, service priority is strictly guaranteed. This accurately determines the upgrade timing without service interference, avoiding interruptions to core SIP voice services during the upgrade process, achieving truly seamless upgrades. Consequently, the entire upgrade process does not affect core services such as calls and conferences, is imperceptible to users, and eliminates service interruptions and registration failures caused by upgrades.

[0026] S03, complete the atomic modification of the boot flag and the pre-boot verification to complete the pre-boot ready authorization, confirm that it can boot normally after restart, execute the terminal restart, and perform multi-level progressive health checks in sequence after booting from the spare partition, and complete bidirectional authorization with the UMS server after all checks pass.

[0027] Specifically, the multi-level progressive health check involves sequentially performing kernel and system startup health checks, basic network and SIP registration health checks, voice service core function health checks, and system stability and full-function compliance checks. If a previous check fails, an atomic rollback is immediately triggered, preventing the next level of checks from proceeding. The atomic rollback operation involves the bootloader performing an atomic write operation to modify the startup flag, rolling back the startup partition to the original running partition, and performing a terminal restart after a successful readback verification. Following the restart, a post-rollback health check confirms that the terminal has returned to normal service status. In practice, this four-level progressive check system verifies system availability, atomic operations ensure that startup flag modification / rollback does not cause damage, and post-rollback health checks verify service recovery. This verifies the availability of the new partition system, preventing terminal bricking or functional abnormalities after upgrades and enabling automatic and secure rollback in abnormal scenarios. Furthermore, when the new system experiences startup anomalies, it can automatically and quickly roll back to the original normal version, ensuring the terminal always remains service-available and completely resolving the issue of embedded terminal bricking after upgrades.

[0028] S04, complete the hash chain verification of the entire upgrade process with the UMS server, complete the permanent switch of partition roles and the persistence of the entire process status, and generate the final confirmation certificate of successful upgrade.

[0029] Specifically, the authorization certificate generated by each status node adopts a hash chain structure. The authorization certificate of the subsequent node contains at least the hash value of the previous node, the unique task ID, and the unique terminal device ID. In practice, the hash chain binds the certificates of each status node, associating the task with the unique device identifier, ensuring that the process is tamper-proof and the status is traceable. This upgrades the entire process to be traceable and tamper-proof, allowing for rapid location of anomalies and meeting the auditing needs of high-compliance scenarios such as finance and telecommunications.

[0030] Furthermore, if any node fails to confirm ownership during the upgrade process, an atomic rollback operation is triggered. This rollback process includes triggering ownership confirmation, confirming rollback execution, performing a health check after rollback, and finally confirming ownership upon completion, ensuring the terminal returns to its normal business state before the upgrade. In practice, triggering rollback upon ownership confirmation failure and completing ownership verification throughout the entire rollback process ensures the rollback operation is effective and services are fully restored. This achieves closed-loop management of anomalies throughout the upgrade process, ensuring safe recovery even if any stage fails, guaranteeing business continuity for the terminal. Consequently, the upgrade is free from the risk of loss of control, any anomalies are automatically repaired, and the terminal always returns to a normal business state.

[0031] In summary, the method of this invention completes pre-authorization by performing pre-verification based on upgrade instructions, establishes a private TCP upgrade data channel with the UMS server and completes two-way identity authentication and channel trust authorization, then receives upgrade packets through the TCP upgrade data channel in a block-by-block transmission and breakpoint resume mode to complete block-by-block real-time authorization and full integrity authorization, determines idle upgrade timing based on a multi-dimensional business status matrix and writes the authorized upgrade image to the dual-partition backup partition, completes atomic modification of the startup flag and pre-startup boot verification, executes terminal restart and performs multi-level progressive health checks, and then completes full-process hash chain verification, permanent partition role switching and full-process state persistence with the UMS server to generate the final authorization certificate for successful upgrade. This makes the entire upgrade process authorization rigorous and the process closed-loop controllable, without relying on stateless control of scattered steps to perform upgrade operations, without using a transmission architecture that couples signaling and upgrade channels to cause bandwidth contention, and without relying on a forced upgrade triggering method without idle judgment. The upgrade transmission is stable, the service is not interfered with, and the status is traceable. Furthermore, this solution achieves automatic protection against upgrade anomalies through dual partitioning and atomic operations, ensuring secure and stable terminal upgrades without requiring continuous centralized management or additional hardware redundancy. Therefore, this invention addresses the lack of a smart, seamless terminal upgrade method in existing technologies that balances seamless service delivery, high transmission reliability, secure and controllable upgrades, and efficient large-scale maintenance.

[0032] Example 2 In another aspect, this invention proposes a terminal intelligent seamless upgrade system, comprising a SIP server, an upgrade management server (UMS), and multiple SIP terminals, which work together to implement the aforementioned terminal intelligent seamless upgrade method. The SIP server is used to complete registration and keep-alive interactions with SIP terminals via a SIP signaling channel, maintain the terminal's registration status and keep-alive information, and provide a terminal registration status query interface to the UMS. The UMS server is used for upgrade packet management, upgrade task creation and scheduling, provides a private TCP upgrade data channel completely independent of the SIP signaling channel, receives the authorization credentials for each status node reported by the terminal and performs remote verification. After successful verification, it returns the corresponding authorization permission credential to the terminal; without permission, the terminal is strictly prohibited from entering the next state. The SIP terminals are used to complete SIP registration and keep-alive, local authorization of each status node throughout the upgrade process, segmented reception and verification of upgrade packets, idle state determination, upgrade execution, rollback control, and result reporting.

[0033] The system will now be described by way of example to make it easier to understand.

[0034] Specifically, the system includes three core components: a SIP server, an upgrade management server (hereinafter referred to as UMS), and several SIP terminals (hereinafter referred to as UE). The overall architecture follows the core design of completely separating the signaling and data dual channels, and all components serve the core mechanism of status confirmation throughout the upgrade process.

[0035] The SIP server is responsible for handling SIP registration and keep-alive of terminals. It listens on port 5060 / UDP or 5060 / TCP by default (configurable). Internally, it maintains a real-time updated registration status table, recording each terminal's unique device ID, IP address, port number, last active time, and registration status (online / offline). The SIP server provides a standardized REST interface for UMS to query the list of currently online terminals. For example, it can retrieve information on all online terminals via the GET / api / v1 / registrations interface, and query the real-time registration status of a single terminal via GET / api / v1 / registrations / {device_id}, providing data support for UMS to filter target terminals and verify their SIP registration status.

[0036] The Upgrade Management Server (UMS) is responsible for uploading and managing upgrade packages, creating and scheduling upgrade tasks, maintaining task queues, controlling concurrency, verifying status and authorization, executing failure retry strategies, and summarizing upgrade results. It is the core control node for batch upgrade tasks and the main server for bidirectional status and authorization verification. UMS includes a web-based front-end management interface for administrators to perform fully visual operations, allowing them to view the current upgrade status, authorization credentials, and anomaly alarms for each terminal in real time. Internally, it is configured with a relational database to store task tables, device tables, upgrade log tables, chunked transmission record tables, and status and authorization credential tables. The default concurrent push limit is configurable (default 100 concurrent connections, dynamically adjustable based on network bandwidth and server performance). It provides standardized REST API interfaces, with core interfaces including: creating upgrade tasks, querying task status, obtaining upgrade package metadata, receiving terminal status and authorization reports, receiving terminal upgrade result reports, and returning authorization and authorization credentials.

[0037] A SIP terminal (UE) is a voice terminal based on the SIP protocol, including IP phones, embedded voice terminals, and soft terminals. It has the following core functional modules built-in, working together to complete intelligent, seamless upgrades and full-process status confirmation, serving as the main terminal-side entity for bidirectional status confirmation: SIP Status Monitoring Module: Responsible for interacting with the SIP server, maintaining SIP registration and keep-alive status, synchronously receiving upgrade commands from the SIP channel, and reporting registration status to the SIP server in real time; Service Status Monitoring Module: Collects core indicators such as terminal calls, conferences, RTP audio streams, user operations, and system load in real time, constructs and updates the service status matrix, and completes idle access status confirmation; Private TCP Client Module: Establishes a private TCP upgrade data channel with the UMS, independent of the SIP signaling channel, to complete the segmented transmission of upgrade packets, breakpoint resumption, data encryption / decryption and verification, and complete status confirmation during the transmission phase; Status Confirmation Core. The core module of this invention coordinates the entire upgrade process, including status verification, credential generation, and bidirectional synchronization. It is responsible for local authorization of each status node, credential reporting, and permission reception; triggering the next status action is strictly prohibited without permission. The upgrade control module coordinates the entire upgrade process, including upgrade package verification, idle state monitoring, partition write control, startup flag modification, rollback triggering, and upgrade result reporting. The dual-partition storage module divides the terminal's non-volatile storage into two completely independent redundant partitions, A and B, serving as the current running partition and the backup upgrade partition, respectively, providing a carrier for partition writing, switching, and rollback status authorization. The upgrade bootloader selects the startup partition based on the startup flag during terminal startup, performs a progressive four-level health check on the new partition, and triggers an atomic automatic rollback process when the health check fails, completing the status authorization during startup and rollback phases. The terminal listens on a fixed TCP port 8080 by default (configurable), or supports dynamically allocated ports by UMS to receive upgrade connection requests.

[0038] In addition, the upgrade package adopts a standardized directory structure and includes a manifest file, block data files, differential patch files (optional), and signature files. All files are packaged into a single compressed package, supporting Zstd or gzip compression format, providing a basic verification basis for the whole process of status confirmation.

[0039] The manifest file uses a JSON structured format (XML format is also acceptable) and is the core control file for the upgrade process, as well as the core verification basis for status confirmation. It includes the following required fields:

[0040] Before downloading the upgrade package, the terminal first obtains and parses the manifest file to know the complete information of the upgrade package in advance, and completes pre-verification, block transmission planning and differential upgrade adaptation, providing a foundation for subsequent full-process status confirmation.

[0041] Furthermore, the private TCP protocol is completely independent of the SIP signaling channel, consisting of two parts: control message interaction and binary data block transmission. Control messages are exchanged using a JSON structured format, while data blocks are directly transmitted as binary streams. Encrypted transmission, flow control, and breakpoint resumption are supported throughout the process, providing channel support for state confirmation during the transmission phase. The handshake and two-way authentication process involves the terminal initiating a TCP connection to the UMS and sending a ClientHello control message. This message includes the terminal's unique device ID, a pre-set certificate fingerprint, a list of blocks that have been received and confirmed (for breakpoint resumption scenarios), and a task ID. Upon receiving the connection request, the UMS returns a ServerHello control message, containing the server certificate fingerprint, the corresponding device's upgrade task ID, a suggested starting block number, session negotiation parameters, and transmission confirmation rules. Both parties perform two-way certificate authentication using the standard TLS 1.3 handshake process. After successful authentication, a session key and a unique session ID are negotiated. The session key is used only for this upgrade task and is destroyed immediately after the task ends. After authentication, a channel trusted confirmation credential is generated, and the block data transmission phase begins. The UMS sends each data block to the terminal sequentially according to the block list in the manifest file.

[0042] When transmitting via a private channel, for each data block, UMS first sends a block metadata control message, including the block index, block size, CRC32 checksum, and SHA256 hash value, and then sends the corresponding block's binary data. After receiving the complete block data, the terminal immediately calculates the CRC32 checksum and compares it with the checksum in the metadata. If they match, it proceeds to the hash verification stage; otherwise, it returns a block denial message (NACK) and requests a retransmission of the corresponding block. The terminal calculates the SHA256 hash value of the block data and compares it with the hash value in the metadata. If they match, the block verification is confirmed, and the data is written to the non-volatile cache partition. After a readback and verification confirming no errors, a block confirmation message is returned. ACK is returned, and the list of confirmed block indexes is persistently updated; if there is a discrepancy, NACK is returned, requesting retransmission; UMS maintains a retransmission counter for each block. If the number of retransmissions for a single block exceeds a preset threshold (3 times by default), the transmission is deemed to have failed, the error information is recorded, and the process is transferred to the failure handling procedure; Built-in flow control capability: UMS can send flow control commands to the terminal based on network congestion status, server load, or load reported by the terminal, informing the terminal to adjust the receiving rate (e.g., target rate 2Mbps). The terminal adjusts the receiving buffer and write storage speed accordingly to avoid network congestion or excessive terminal load, while ensuring priority for SIP service bandwidth. If the TCP connection is interrupted during transmission, the terminal persists a record locally of the successfully received and verified block index list and corresponding hash values ​​to ensure no data loss in the event of power failure. After re-establishing the connection with UMS, the terminal includes the verified block list and corresponding hash values ​​in the ClientHello message. UMS verifies the validity of the block list and hash values. If correct, it continues transmission from the next missing block without retransmitting the full upgrade package, significantly improving transmission efficiency in weak network environments. If UMS fails to verify the hash value, it determines that the received block data has been tampered with. The terminal immediately destroys all received block data and restarts transmission from block 0 to ensure data integrity.

[0043] Furthermore, the specific upgrade process divides the entire upgrade lifecycle into 10 consecutive progressive state nodes, with the execution logic and details of each state node as follows: Status Node 1: Upgrade task ready status confirmed (preliminary rights confirmation stage).

[0044] Status definition: When the terminal receives the upgrade command, it completes the pre-upgrade legality verification of the upgrade task, confirms that the task can be executed, and enters the "task ready to be executed" state.

[0045] Confirmation Module: Terminal Status Confirmation Module + UMS Task Management Module.

[0046] Detailed rights confirmation rules: First, verify the legitimacy of the task identity: verify that the globally unique ID of the upgrade task, the target device ID, and the locally unique device ID of the terminal are completely consistent to prevent mismatch upgrades; verify the legitimacy of the entity issuing the upgrade command: commands issued through the SIP signaling channel must be verified against the SIP server source address whitelist; commands issued through the TCP channel must be verified against the UMS digital signature to prevent forged upgrade commands; confirm that the current time is within the administrator's preset task validity time window, and tasks that have expired will be terminated directly.

[0047] Secondly, pre-confirmation of upgrade package compatibility: Parse the upgrade package manifest file and verify the matching of terminal hardware model, baseline version and upgrade package: For full packages, confirm that the hardware model is compatible; for differential packages, confirm that the current running version is completely consistent with the differential baseline version; confirm that the spare partition storage space is ≥ 1.2 times the total size of the upgrade package (reserve write cache) and the available memory is ≥ 4MB. If resources are insufficient, terminate the task directly.

[0048] Finally, upgrade policy permissions are confirmed: verify the terminal's local upgrade permissions, i.e., determine whether remote upgrades are allowed, whether nighttime upgrade restrictions are enabled, and whether there are upgrade prohibition rules locked by the administrator; confirm upgrade mode compatibility, i.e., by matching the task's preset Push / Pull mode, automatically switch to Pull mode in NAT environment to ensure that the channel can be established.

[0049] Confirmation credential: The terminal generates a "task ready confirmation hash value", which includes the task ID, device ID, manifest file hash, and full verification result. It adopts a hash chain structure, with the initial chain hash being the hash value of device ID + task ID. It is persistently stored locally and reported to UMS. After the UMS verification is successful, it returns a "task execution license credential". Without this credential, it is strictly forbidden to enter the next state.

[0050] Error handling: If any authorization fails, the task will directly enter the "task termination state", will not be reported as ready, will not trigger any subsequent upgrade actions, and will report the corresponding error code and failure reason to UMS.

[0051] Business avoidance rules: The entire verification process is performed in the background. If a call / conference service is detected to be starting, the verification will be paused immediately and resumed after the service ends. The entire process does not consume business resources.

[0052] State Node 2: Upgrade Channel Establishment and Identity Trust Status Confirmation.

[0053] State definition: The terminal and UMS have completed the establishment of a private TCP upgrade channel, completed two-way authentication and encrypted session negotiation, confirmed that the channel is trustworthy and available, and entered the "channel ready for transmission" state.

[0054] Confirmed entities: Terminal private TCP client module + UMS TCP server module.

[0055] Refine the rights confirmation rules: First, network connectivity rights confirmation: The terminal and UMS complete the TCP three-way handshake to confirm that there is no firewall blocking or NAT blocking. The connection timeout is 30 seconds. If the connection fails to retry 3 times after the timeout, it enters the "network abnormal state". Then, the link quality is confirmed. After the connection is established, the round-trip delay of three consecutive bidirectional heartbeat probes is ≤500ms and the packet loss rate is ≤1%. In the weak network environment, the chunk size and transmission rate are automatically adjusted.

[0056] Secondly, two-way identity trust confirmation: Two-way certificate authentication is performed: The terminal submits the device's pre-installed certificate and fingerprint, and UMS verifies the certificate issuing authority, validity period, and device ID binding relationship; UMS submits the server certificate, and the terminal verifies the root certificate trust chain and IP / domain name binding relationship to prevent man-in-the-middle attacks; Based on the TLS 1.3 protocol, a session key and a unique session ID are negotiated. The session key is only used for this upgrade task and is destroyed immediately after the task is completed.

[0057] Finally, the channel is exclusively bound and authorized: confirm that this TCP channel is uniquely bound to the task ID, device ID, and session ID, and that only upgrade data and status instructions for this task are allowed to be transmitted within the channel; and confirm that the channel and the SIP signaling channel are completely physically / logically isolated, completely independent in terms of port, protocol stack, and process, and that the transmission bandwidth limit does not exceed 30% of the terminal's total bandwidth by default, and will never preempt the bandwidth of SIP signaling and RTP media streams.

[0058] Confirmation of Rights: Both parties negotiate and generate a "Channel Trusted Confirmation of Rights Certificate," which includes the session ID, task ID, device ID, session key hash, and the confirmation hash value of the previous node, forming a chained hash, and is persistently stored separately; all subsequent data packets must carry a valid session ID, and data packets without the certificate are directly discarded. The terminal reports the certificate to UMS, and after UMS verifies it, it returns a "Transmission License Certificate."

[0059] Error handling: If identity authentication fails, the channel connection will be terminated directly and the task will enter the "task termination state"; if network connectivity fails, the task will enter the "retry waiting state"; if the maximum number of retries is exceeded, the task will be terminated.

[0060] Service avoidance rules: If a SIP call / conference service is detected to be started, immediately suspend the channel establishment, release network resources, and re-initiate the connection after the service ends, ensuring that the service bandwidth is prioritized.

[0061] State Node 3: Upgrade Packet Block Transmission and Integrity Status Confirmation (Block-by-Block + Full Second-Level Rights Confirmation).

[0062] Status definition: After the terminal completes the reception and verification of the full data block of the upgrade package, confirms that the upgrade package is complete, untampered, and undamaged, it enters the "upgrade package ready to be written" state.

[0063] Confirmation Module: Terminal Status Confirmation Module + UMS Transmission Control Module.

[0064] The rules for confirming ownership have been refined: they are divided into two levels, namely, real-time ownership confirmation on a block-by-block basis and final ownership confirmation of the entire data, which completely solves the problems of data corruption, tampering, and inconsistent status during the transmission process.

[0065] Level 1: Real-time rights confirmation on a block-by-block basis (each data block must complete 4 layers of verification).

[0066] First, block transmission integrity verification: if the block size is completely consistent with the preset value in the manifest file, it is determined that the transmission is truncated and a NACK is returned to request retransmission; if the block CRC32 value is consistent with the preset value, it is determined that the transmission is corrupted and a retransmission is requested.

[0067] Secondly, the block hash anti-tampering and rights confirmation: calculate the SHA256 hash value of the block data, and make it completely consistent with the preset value in the manifest file. If they are inconsistent, the transmission will be terminated directly, a data tampering alarm will be reported, and all received block data will be destroyed.

[0068] Then, the block sequence number continuity is confirmed: the current block index is checked to be continuous with the maximum index of the confirmed block, skipped blocks are not allowed to be received, out-of-order blocks are only cached and checked after the previous block is confirmed. Finally, the block storage persistently confirms ownership: the block data that passes the verification is written to the non-volatile cache partition. After the writing is completed, the data is read back for verification. Only when the written data is completely consistent with the received data is an ACK returned to UMS, and the list of confirmed block indexes is updated persistently.

[0069] Level 2: Full final confirmation of rights (after all blocks have been received, 5 layers of full verification).

[0070] First, full block continuity confirmation: verify that the list of confirmed block indexes covers all blocks, with no missing or duplicate blocks, and that the total number of blocks matches the list file; Secondly, full data integrity verification: all verification blocks are spliced ​​into a complete image, and the full SHA256 hash value is calculated, which is completely consistent with the overall verification value of the manifest file; Then, the upgrade package digital signature is verified: the RSA-SHA256 signature value of the upgrade package is verified using the preset root public key to confirm that the upgrade package is officially issued and has not been injected with malicious code; Next, differential packet synthesis and confirmation (differential scenario): verify that the hash value of the complete image after synthesis is consistent with the preset value. If synthesis fails, it will automatically switch to full packet transmission mode. Finally, secondary verification of image compatibility: verifying that the hardware adaptation information and version number in the image header match the terminal to avoid incorrect image flashing.

[0071] Confirmation of rights certificate: The terminal generates a "complete confirmation of rights certificate for the upgrade package", which includes the full image hash, signature verification result, total number of blocks, task ID, and confirmation hash value of the previous node, forming a chain hash, which is persistently stored and reported to UMS; after confirmation by UMS, it returns an "image write license certificate".

[0072] Anomaly Handling: If a single block verification fails, it will be retransmitted a preset number of times. If the number of times is exceeded, it will enter the "Transmission Failure State"; if a full verification fails, all cached data will be destroyed and the task will enter the "Task Retry State"; if signature verification fails, the task will be terminated directly, the upgrade package will be permanently blacklisted, and an alarm will be reported.

[0073] Service avoidance rules: If a service is detected to be starting during transmission, the transmission is immediately paused to release bandwidth. Transmission is resumed from the breakpoint after the service ends, without the need to retransmit the full amount of data, and the normal operation of the service is not affected throughout the process.

[0074] Status Node 4: Terminal idle upgrade access status confirmation.

[0075] Status definition: After the terminal completes the upgrade package authorization, it continuously monitors the business status matrix to confirm that the terminal is in a completely idle state without business interference, and then enters the "upgrade execution access ready" state.

[0076] Confirmation Entities: Terminal Service Status Monitoring Module + Status Confirmation Module.

[0077] Refine the rights confirmation rules: deepen them into two levels of idle judgment + continuous stability confirmation, solve the problem of instantaneous idle misjudgment, and achieve a truly seamless upgrade.

[0078] Level 1: Determining the rights of idle thresholds based on 7 dimensions.

[0079]

[0080] Level 2: Determining the continuous stability of the overall idle state.

[0081] Once the basic threshold is passed, the system must enter a stable observation window (default 30 seconds). Only when all dimensions within the window continuously meet the idle threshold and no warning events are triggered will the system be finally determined to be in an idle state. If any dimension within the observation window triggers a warning, the observation window will be immediately reset, and the timer will restart once all dimensions have returned to idle status. Supports two configurable modes: One is the strict mode (default): all dimensions must meet the threshold 100% and there are no warnings in the observation window before the upgrade can be allowed to proceed; Another option is the compatibility mode: each status item is assigned a weight, and only when the overall idle score is ≥95 points and the core business items (calls, conferences, SIP registration) are 100% met, can the upgrade be allowed to proceed.

[0082] Level 3: Upgrade Timing Strategy Confirmation: Verify that the current time meets the preset upgrade time window (e.g., 23:00 at night to 6:00 the next day). If not, continue to wait. For battery-powered terminals, it must be confirmed that the power is ≥50% or that the terminal is charging to avoid power interruption during the upgrade.

[0083] Confirmation of Rights: The terminal generates an "Idle Access Confirmation of Rights", which includes the full sampled data of the observation window, the comprehensive judgment result, the time window verification result, and the confirmation hash value of the previous node, forming a chain hash, which is persistently stored and reported to UMS.

[0084] Error handling: If the maximum waiting time exceeds the preset limit (default 72 hours) and the admission conditions are not met, the upgrade package cache will be automatically destroyed, the task will be terminated, and the waiting timeout status will be reported.

[0085] Forced business avoidance rules: After entering the upgrade execution state, if a business warning such as an incoming call or meeting invitation is detected, the upgrade action will be immediately suspended; if the partition has been written but the startup partition has not been switched, the partition write state will be immediately rolled back to ensure that the terminal can respond to business requests at any time.

[0086] Status Node 5: Upgrade image write and partition ready status confirmed.

[0087] Status definition: The terminal writes the authorized upgrade image to the backup partition, performs a full verification after writing, confirms that the backup partition image is complete and bootable, and enters the "partition ready to switch" state.

[0088] Confirmed entities: Terminal upgrade control module + Dual-partition storage module + Status confirmation module.

[0089] The rules for confirming ownership have been refined: they are divided into three levels: block-based write ownership confirmation, full partition verification, and partition boot attribute confirmation, to prevent boot failures caused by writing bad blocks.

[0090] First, block-by-block writing with real-time authorization: The upgraded image is written to the spare partition block by block. After each block is written, it is immediately read back for verification. Only when the read-back data is completely consistent with the CRC32 and SHA256 values ​​of the original block is the block written successfully confirmed. Storage bad blocks are monitored in real time. Bad blocks are automatically marked when detected. Data is rewritten using spare blocks. If the number of bad blocks exceeds the preset threshold, the writing is terminated and the storage medium is reported as abnormal.

[0091] Secondly, the integrity of the full partition image is verified: after all blocks are written, the complete content of the spare partition is read sector by sector, spliced ​​into a complete image, and the full SHA256 hash value is calculated. This is then verified against the overall checksum of the manifest file and the complete verification hash value of the upgrade package. The image boot header information is verified: the bootloader parameters, kernel loading address, and root file system partition information are confirmed to be completely correct and meet the requirements for terminal hardware booting.

[0092] Finally, partition attributes and environment readiness verification: Verify read / write permissions and boot flag permissions for the spare partition to confirm that the partition can be recognized by the bootloader and can be set as the boot partition; verify the backup status of user configuration data: Automatically back up user data such as accounts and key configurations to a separate configuration partition, and confirm that the backup data is complete and recoverable; confirm that there are no other storage read / write operations on the terminal, and that no system processes occupy the spare partition to prevent the image from being tampered with.

[0093] Confirmation of rights certificate: The terminal generates a "partition ready confirmation certificate", which includes the full hash of partition writing, bad block detection results, startup header verification results, configuration backup status, and the confirmation hash value of the previous node, forming a chain hash, which is persistently stored and reported to UMS; after confirmation by UMS, it returns a "startup partition switching license certificate".

[0094] Error handling: If a single block write fails, bad block rewriting is performed. If more than 3 failures occur, the write operation is terminated and a partition write failure is reported. If a full image verification fails, the backup partition data is immediately erased and the task is put into "task retry state".

[0095] Business avoidance rules: If a business is detected to be starting during the write process, the write is immediately paused to release IO resources. The write is resumed from the position of the authorized write block after the business ends, without affecting the business response.

[0096] Status Node 6: Startup partition switching and pre-boot status confirmation.

[0097] State definition: The terminal modifies the boot flag, sets the next boot partition as the backup partition, completes the environment preparation before restart, confirms that it can boot normally after restart, and enters the "Pre-boot ready to restart" state.

[0098] Confirmed entities: Terminal upgrade control module + bootloader module + status confirmation module.

[0099] Refine the rights confirmation rules: First, atomic write confirmation of the startup flag bit: The startup flag bit is stored in an independent security partition and is written atomically to ensure that power interruption during writing will not damage the flag bit; the written content includes the primary startup partition (backup partition), backup startup partition (original running partition), health check flag, timeout time, rollback enable flag, and number of consecutive upgrades; after the write is completed, it is immediately read back for verification, and the flag bit modification is confirmed to be successful only after confirming that the content is completely consistent with the preset.

[0100] Secondly, restart the environment to ensure security and authorization: shut down all non-core system processes, release user-space resources, and ensure that there are no process crashes or data loss during the restart; synchronize all cached data to the storage medium, perform file system unmounting and mounting checks to ensure that there is no file system corruption or dirty data; confirm that the SIP protocol stack has been properly deregistered to avoid the SIP server registration status becoming abnormal due to the restart.

[0101] Finally, the pre-boot verification and authorization process involves the bootloader pre-reading the boot header of the spare partition, verifying the image boot signature and kernel checksum to confirm that the image can be booted normally, without having to reboot to discover the boot failure; and pre-configuring boot parameters to confirm that the parameters completely match the spare partition image, thus avoiding kernel crashes caused by incorrect boot parameters.

[0102] Confirmation of Rights: The terminal generates a "Pre-start Ready Confirmation of Rights", which includes the startup flag verification result, the boot pre-verification result, the restart environment status, and the confirmation hash value of the previous node, forming a chain hash, which is persistently stored in the security partition (not lost when power is off), and is also reported to UMS.

[0103] Error handling: If the flag bit write fails, immediately restore the original boot flag bit, erase the data in the spare partition, and report the flag bit modification failure; if the boot pre-verification fails, immediately restore the original flag bit and report the image boot failure.

[0104] Business avoidance rule: This phase is only executed when the terminal is continuously idle. If a business request is detected, the original start flag is immediately restored, the restart process is terminated, and the business is returned to the business ready state, ensuring that business priority is absolutely guaranteed.

[0105] Status Node 7: New system hierarchical health status confirmed.

[0106] Status definition: The terminal restarts from the backup partition, completes the full-process health check of the new system, confirms that the new system functions normally and services are available, and enters the "Health check passed, pending authorization" status.

[0107] Entities to be verified: Terminal bootloader + System initialization service + Status verification module + UMS remote verification module Refine the rights confirmation rules: The original single health check has been deepened into a four-level progressive health check rights confirmation system. Failure to pass the previous level will directly trigger a rollback, and the system will never proceed to the next level, thus completely resolving the issues of system unavailability and bricking after the upgrade. Level 1: Kernel and system startup health check (executed by bootloader, timeout 30 seconds).

[0108] The objectives of the inspection are to confirm that the kernel can boot normally, the root file system can be mounted normally, and the core hardware drivers are normal.

[0109] Detailed inspection items: Kernel image verification: The bootloader verifies the kernel image checksum and signature, confirming it is not damaged or tampered with; if the verification fails, a rollback is triggered directly; Kernel boot status: Confirms that the kernel decompresses and boots normally, with no kernel panics, no Oops errors, and no hardware driver errors; Root file system mounting: Confirms that the root file system is mounted normally, without damage or mounting failures, and with normal read and write permissions; Core hardware drivers: Confirms that network interface, SIP voice chip, storage media, and input / output device drivers are loaded normally, with no hardware faults; System process initialization: Confirms that the init process starts normally, and core system services such as syslog, dbus, and network management run normally, with no process crashes.

[0110] Passing rule: If all checks pass 100% and are completed within 30 seconds, this level is considered passed; if any check fails or times out, an atomization automatic rollback is immediately triggered.

[0111] Level 2: Basic network and SIP registration health check (executed by system initialization service, timeout 60 seconds).

[0112] Inspection objectives: Confirm that the network connection is normal, SIP registration can be completed normally, and core communication capabilities are normal.

[0113] Detailed inspection items: Network connectivity check: Confirm that the network interface is normally up, IP address acquisition is normal, and the gateway, SIP server, and UMS server can be pinged. Network latency and packet loss rate meet the requirements. DNS resolution check: Confirm that the DNS service is normal and can resolve the domain names of the SIP server and UMS server normally. SIP protocol stack check: Confirm that the SIP protocol stack service starts normally, without crashes or configuration errors. SIP registration status check: Initiate registration with the SIP server, and all three consecutive registrations are successful. The keep-alive response is normal, the registration stability time is ≥30 seconds, and the registration status is consistent with the original system. Dual-channel connectivity check: Confirm that the SIP signaling channel is normally connected, the private TCP channel can establish a normal connection with UMS, and two-way authentication is normal.

[0114] Passing rule: If all checks pass 100% and are completed within 60 seconds, this level is considered passed; if any check fails or times out, an atomization automatic rollback is immediately triggered.

[0115] Level 3: Health check of core voice service functions (executed by the status confirmation module, timeout 60 seconds). Inspection objective: To confirm that the core functions of the SIP voice service are fully functional and meet the requirements for service use. Detailed inspection items: Voice chip and codec check: Confirm that the voice codec is loaded normally, supports preset codec formats such as G.711 and G.729, and that the voice chip has no errors or mute faults; RTP media stream check: Confirm that the RTP port is listening normally, can send and receive RTP media streams normally, has no packet loss or jitter abnormalities, and that media stream forwarding is normal; Basic call function simulation check: Execute the simulated call process to confirm that the INVITE request can be sent normally, the 180 ring / 200 OK response can be received normally, the BYE hang-up process is normal, and there are no signaling abnormalities; Input / output function check: Confirm that peripherals such as buttons, handset, speaker, and microphone are working normally and there are no hardware faults; User configuration recovery check: Confirm that the original system user configuration data is restored normally, SIP accounts and personalized configurations are fully retained, and there is no configuration loss.

[0116] Passing rule: If all checks pass 100% and are completed within 60 seconds, this level is considered passed; if any check fails or times out, an atomization automatic rollback is immediately triggered.

[0117] Level 4: System stability and full functionality compliance check (executed by the status confirmation module, timeout 120 seconds, configurable) Inspection objective: To confirm that the new system is fully functional, runs stably, has no abnormal alarms, and meets the upgrade requirements. Detailed inspection items: System resource stability check: Sample CPU and memory usage for 60 consecutive seconds to confirm that the average CPU usage is ≤30%, memory usage is stable, and there are no memory leaks or abnormal process usage; Full service operation status check: Confirm that all system services and application services are started normally, with no crashes, abnormal exits, or error logs; Upgrade function integrity check: Confirm that the new system upgrade control module, dual partition management module, and TCP transmission module are running normally and support subsequent upgrade functions; Security compliance check: Confirm that the system firewall, certificate trust chain, and encryption module are running normally, with no security vulnerabilities or abnormal permissions; Version number verification: Confirm that the current running system version number is completely consistent with the preset target version number of the upgrade task, with no version errors.

[0118] Passing rule: If all check items pass 100% and are completed within 120 seconds, the full health check is considered passed; if any item fails or times out, an atomization automatic rollback is immediately triggered.

[0119] Confirmation of Rights: After each level of inspection passes, a "Health Check Confirmation Certificate" is generated for that level. This certificate includes all inspection results, sampled data, verification hash, and the confirmation hash value of the previous level node, forming a chained hash. This chained hash is persistently stored and reported to UMS in real time. After all four levels of inspections pass, a "Full Health Check Pass Confirmation Certificate" is generated and reported to UMS. Upon receiving the report, UMS proactively initiates remote verification, including SIP registration status query, terminal status query, and version number query, to reconfirm the terminal's health status. After successful verification, a "Health Check Confirmation Permission" is returned.

[0120] Anti-frequent restart rule: The terminal records the number of consecutive health check failures. If the number of consecutive failures exceeds 3, automatic upgrades will be stopped, the boot partition will be locked to the original running partition, an alarm will be reported, and manual intervention will be required.

[0121] State Node 8: Successful upgrade, final confirmation of rights and persistence of state.

[0122] Status definition: The terminal completes a full health check, obtains UMS remote authorization permission, confirms that the upgrade is completely successful, and enters the "Upgrade successful and finalized" status.

[0123] Confirmation Module: Terminal Status Confirmation Module + UMS Task Management Module.

[0124] Detailed rights confirmation rules: First, two-way final rights confirmation upon successful upgrade: The terminal sends a "final confirmation request for successful upgrade" to the UMS, carrying the full health check rights confirmation certificate, new version number, device ID, task ID, and full-process status hash chain; the UMS verifies the integrity and legality of the full-process hash chain, confirms that all status nodes have completed rights confirmation, without skipping steps or anomalies, and at the same time performs a secondary verification of the terminal's online status, registration status, and version number. After confirming that there are no errors, it returns the "final rights confirmation certificate for successful upgrade".

[0125] Secondly, the partition role is permanently switched and rights are confirmed: After the terminal receives the final rights confirmation certificate, the boot flag is permanently modified, the original spare partition is set as the default primary boot partition, and the original running partition is set as the new spare upgrade partition, thus completing the permanent switch of partition roles; the old system image of the original running partition is erased to free up storage space.

[0126] Then, upgrade the persistence of the status confirmation of the entire process: The terminal will upgrade the confirmation credentials, verification data and logs of all status nodes in the entire process, package and encrypt them and store them in the local audit log partition, set them to be tamper-proof and non-deletable, and the storage time will be no less than 180 days; The terminal will report the full upgrade log to UMS, and UMS will bind and archive it with task information, and long-term storage will meet the compliance audit requirements.

[0127] Finally, the business capabilities are confirmed: the terminal re-registers with SIP, enters the normal business ready state, and confirms that all business functions are normal and without any abnormalities.

[0128] Confirmation of rights: The terminal and UMS jointly generate the "final confirmation of rights hash chain for successful upgrade", which contains the confirmation of rights hashes of all status nodes in the entire process, forming a chain-like anti-tampering structure, which is persistently stored separately.

[0129] Anomaly Handling: If the final authorization confirmation fails in UMS, the terminal immediately triggers the rollback process, restores the original running partition, and reports the authorization failure status.

[0130] Status Node 9: Confirmation of the entire rollback process under abnormal conditions.

[0131] Status definition: If any node fails to confirm rights during the upgrade process, an automatic rollback is triggered. The rollback process is completed and the status is confirmed to ensure that the terminal is restored to the normal state before the upgrade and enters the "Rollback Completed and Business Restored" state.

[0132] Confirmation Entities: Terminal bootloader + Status Confirmation Module + UMS Task Management Module.

[0133] Refine the rights confirmation rules: Construct a closed-loop rights confirmation process for the entire rollback phase to eliminate the risk of data loss due to rollback failure. First, the rollback trigger conditions must be clearly defined: a rollback is only permitted when any of the following conditions are triggered, and accidental triggering is strictly prohibited: kernel and system startup health check failure; SIP registration health check failure; voice service core function health check failure; system stability full-function check failure; final authorization failure after successful upgrade; three consecutive SIP keep-alive failures after the new system starts, resulting in service unavailability. Before triggering a rollback, the triggering reason, failure point, and error log must be recorded and persistently stored in a secure partition, and a rollback trigger alarm must be sent to UMS.

[0134] Secondly, the rollback execution performs atomic rights confirmation: the bootloader performs atomic operations, modifies the boot flag, rolls the boot partition back to the original running partition, clears the health check flag, upgrades the temporary state, and writes the rollback count and rollback reason; after writing, it immediately reads back to verify that the boot flag has been completely restored to the state before the upgrade, and only then is the rollback execution confirmed to be successful; the terminal is forced to restart and start from the original running partition.

[0135] Then, a health check is performed after the rollback to confirm permissions: After the terminal restarts, a simplified health check is performed to confirm that: the system starts normally, SIP registration is normal, voice core functions are normal, user configuration is fully restored, and the version number is restored to the original version; only when the health check passes is the rollback confirmed to be successful and the terminal returns to normal business status.

[0136] Finally, the rollback is completed and the final rights are confirmed: the terminal sends a "rollback completion confirmation request" to UMS, carrying the rollback trigger reason, execution log, health check results after rollback, and original version number; after verification, UMS returns a "rollback completion confirmation certificate" and updates the task status to "upgrade failed - rolled back"; the terminal erases the failed upgrade image of the backup partition, releases storage space, clears the temporary upgrade status, and fully returns to the business ready state.

[0137] Error handling: If the rollback fails, the bootloader immediately enters emergency recovery mode, loads the pre-stored recovery image, and reports an alarm to UMS, prompting manual intervention.

[0138] Anti-frequent rollback rule: If the number of consecutive rollbacks exceeds 3, the upgrade function will be locked immediately, automatic execution of upgrade tasks will be prohibited, an alarm will be reported, and manual investigation will be required.

[0139] State Node 10: Terminal-Server State Synchronization and Closed-Loop Confirmation Status Definition: Regardless of whether the upgrade is successful / failure / rollback, the terminal and UMS complete the final synchronization of the entire process status, confirm the task loop closure, and enter the "Task Final Completion" state. Confirmation Modules: Terminal Status Confirmation Module + UMS Task Management Module Refine the rights confirmation rules: First, the final status of the task is confirmed through bidirectional synchronization: The terminal reports the final status of the task (success / failure / rollback / timeout / termination) to the UMS, carrying the full-process status confirmation certificate, error code, and detailed logs; After receiving the report, the UMS updates the terminal status in the task database and returns a "task closure confirmation receipt" to the terminal; After receiving the receipt, the terminal clears the temporary cache and temporary status of this upgrade task and terminates all upgrade-related processes.

[0140] Secondly, the batch task closed-loop management and authorization: UMS summarizes the final status of all terminals of the batch task, counts the number of successes, failures, rollbacks, and timeouts, and generates the final task report; for failed terminals, retry is performed according to the preset strategy, and terminals that exceed the maximum number of retries are marked as abnormal terminals, and an alarm is generated to notify the administrator; after all terminals have completed the status report or the task validity period has expired, UMS marks the task as "final closed loop" and archives the task data and logs.

[0141] Then, auditing and traceability confirmation: UMS stores the entire task operation log, administrator operation records, terminal upgrade full log, and status confirmation data in a hash chain to ensure immutability and meet compliance audit requirements; it supports administrators to query the entire status details, confirmation credentials, and error logs of any terminal upgrade at any time, realizing full traceability.

[0142] Confirmation of Rights: UMS generates a "Final Confirmation of Rights for Task Closure", which includes the task ID, total number of target terminals, number of successes, number of failures, task completion time, and full log hash, and archives it.

[0143] In addition, UMS's task management is the core control module for batch upgrades and the core of the server-side for two-way status confirmation. It includes the following core mechanisms to achieve closed-loop management of the entire lifecycle of upgrade tasks: First, task creation and target device selection: Administrators upload upgrade packages and manifest files through the web front-end management interface, complete signature verification, and set target device selection criteria, including device model, current software version, device group, geographical location, etc., or manually select specific target devices; UMS calls the SIP server interface to obtain the list of currently online terminals, automatically filters offline devices, and generates the final target device list.

[0144] Secondly, the dual-mode delivery adapts to complex network environments: It supports two upgrade task delivery modes, which can automatically adapt to the terminal's network environment: Push mode: UMS actively initiates a TCP connection to the target terminal, pushing upgrade tasks and upgrade instructions. It is suitable for scenarios where the terminal is located on the public network or behind NAT but the port can be accessed by the external network; Pull mode: UMS stores the task information in the database. The terminal polls UMS for pending upgrade tasks through a SIP signaling channel or a private TCP channel according to a preset period (default 1 hour). If there is a task for the corresponding terminal, it actively pulls the upgrade packet metadata and establishes a transmission connection. It is suitable for scenarios where the terminal is behind NAT and cannot be actively accessed by the external network.

[0145] Then, concurrency control and canary release: UMS limits the number of terminals that can be upgraded simultaneously (default 200) based on network bandwidth and server performance to avoid network congestion and server overload; for large-scale upgrade scenarios across countries and carriers, terminals can be grouped based on their geographical location or AS number to perform batch rolling upgrades; it also supports canary release capabilities, allowing you to set an initial upgrade ratio (e.g., upgrade 1% of devices first), and after observing for a preset period without any abnormalities, gradually increase the upgrade ratio to reduce the risk of large-scale upgrades.

[0146] Next, status confirmation and anomaly alarm: UMS receives the confirmation credentials of each status node reported by the terminal in real time, verifies the legality of the credentials and the integrity of the hash chain, and immediately returns an anomaly command to terminate the upgrade task if the verification fails; for high-risk alarms such as authentication failure, data tampering, continuous rollback, and storage anomaly that occur during the upgrade process, it pushes notifications to the administrator in real time to handle the anomalies in a timely manner.

[0147] Finally, retrying on failure and summarizing the results: For terminals experiencing abnormal situations such as transmission failure, verification failure, timeout, upgrade failure, or automatic rollback, UMS adds them to the retry queue and re-initiates the upgrade according to a preset strategy (a maximum of 3 retries by default, with retry intervals increasing sequentially). Devices exceeding the maximum number of retries are marked as upgrade failed, and an alarm message is generated. UMS receives upgrade results reported by terminals in real time and displays task progress, a list of successful / failed devices, and error type statistics on the web front end. It also supports exporting upgrade logs and result reports to meet operational and maintenance auditing needs.

[0148] In addition, the terminal retains complete upgrade logs locally, including the reception time, retransmission count, verification results, authorization records of each status node, idle status determination records, health check output, rollback logs, etc. The logs are stored in encrypted form and cannot be tampered with. They can be downloaded and analyzed remotely by administrators through a specific interface. Furthermore, UMS records all upgrade task operation logs, administrator operation records, the entire history of device upgrade process, status confirmation credentials, and error statistics. The logs are stored using a hash chain, are immutable, and can be stored long-term to meet compliance audit and problem tracing requirements. Furthermore, based on the hash chain-style rights confirmation credential throughout the entire upgrade process, all states, operations, and verification results of the entire upgrade process can be traced through the credential of any node, achieving full-chain traceability and enabling rapid location of abnormal issues.

[0149] Therefore, the system of the present invention, by constructing an upgrade control system with a hierarchical two-way status confirmation and closed-loop control mechanism as its absolute core, and supplemented by a series of targeted supporting technologies, has the following beneficial effects: First, it achieves manageable, controllable, and traceable upgrade processes, fundamentally addressing the industry's core pain point of upgrade failure (stemming from the core hierarchical two-way status confirmation mechanism). Through 10 continuously progressive status nodes and two-way confirmation rules, it sets rigid flow standards for the entire SIP terminal upgrade process, completely resolving the core pain points of existing technology upgrade processes such as lack of status control, skipped execution, inconsistencies between terminal and server states, and inability to trace anomalies. This achieves 100% manageable and controllable upgrade processes and improves upgrade anomaly location efficiency by 100%. At the same time, through hash chain-based tamper-proof storage, it achieves full-process immutability and full-link traceability, perfectly meeting the requirements of high compliance scenarios.

[0150] Secondly, it achieves truly seamless upgrades with zero service interruption, completely resolving the fundamental conflict between upgrades and core business operations (stemming from a dual-channel separation architecture and a multi-dimensional business state matrix mechanism). By completely decoupling the SIP signaling channel from the upgrade data channel, upgrade traffic and business signaling traffic are isolated at the architectural root, completely avoiding interference from upgrade traffic to SIP registration and voice services. This solves the problems of service interruption and registration failure caused by upgrades, ensuring the continuity of voice services and reducing the service interruption rate to 0. Simultaneously, through 7-dimensional idle time determination and continuous stability observation for SIP voice services, terminals can autonomously choose idle times without business interference to perform upgrades, completely unaffecting users' normal calls, conferences, and other core operations, achieving truly seamless upgrades.

[0151] Then, it achieves highly reliable transmission and ultimate anti-bricking capabilities under extreme scenarios, ensuring the stability of the entire upgrade process (derived from the block-based breakpoint resumption mechanism + A / B dual partitioning and four-level health check mechanism). Through block-based transmission, block-level ACK confirmation, and breakpoint resumption mechanism, the transmission reliability of large-volume upgrade packages in weak network environments is greatly improved. Even if the network is interrupted and reconnected, there is no need to retransmit the entire amount of data, increasing the transmission success rate by more than 90%. At the same time, block-level ownership confirmation ensures zero data corruption and zero tampering. With the supporting progressive four-level health check and atomic automatic rollback mechanism, even if extreme anomalies such as power outages or image corruption occur during the upgrade process, it can automatically roll back to the original normal operating version, completely solving the industry problem of bricking during embedded terminal upgrades, with an upgrade success rate of nearly 100%.

[0152] Next, end-to-end full-link security protection is implemented to meet high-level security compliance requirements (derived from the full-link security protection mechanism). Through two-way certificate authentication, encrypted transmission, block-level and overall verification, digital signatures, and hash chain-based tamper-proof storage, end-to-end security is provided for upgrade data, status authorization certificates, and upgrade commands, effectively preventing security risks such as identity forgery, data tampering, malicious code injection into upgrade packages, and tampering of status certificates, fully meeting the compliance requirements of high-security scenarios such as operators, finance, and energy.

[0153] Finally, it achieves simplified operation and maintenance management for large-scale distributed deployments, significantly reducing the cost of batch upgrades (due to the closed-loop management mechanism for batch upgrades on the server side). By connecting to SIP registration status, it enables precise online terminal screening; Push / Pull dual-mode perfectly adapts to complex network environments such as public networks and NAT; concurrency control and canary release capabilities support large-scale batch upgrades of tens of thousands of terminals; simultaneously, through bidirectional state synchronization between terminals and servers, it achieves fully closed-loop, visualized management from task creation to result aggregation, significantly reducing operation and maintenance costs and improving operation and maintenance efficiency by over 80%.

[0154] Example 3 In another aspect, the present invention also proposes a SIP terminal device, including a SIP protocol stack module, a service status monitoring module, a private TCP transmission module, a status confirmation core module, an upgrade control module, an A / B dual-partition storage module, and an upgrade boot module, for executing the above-mentioned intelligent and seamless terminal upgrade method. The SIP protocol stack module is used to complete registration and keep-alive with the SIP server through the SIP signaling channel and maintain the SIP registration status; The service status monitoring module is used to collect the multi-dimensional operating status of the terminal for SIP voice services in real time, construct and update the service status matrix, and complete the confirmation of idle access status. The private TCP transmission module is used to establish a private TCP upgrade data channel with UMS that is independent of the SIP signaling channel, to perform block transmission of upgrade packets, breakpoint resumption, and data encryption and decryption, and to complete the status confirmation of the transmission stage. The core module for status confirmation is used to coordinate the status verification, credential generation, and two-way synchronization of the entire upgrade process, and to perform local confirmation, credential reporting, and permission reception for each status node. Without permission, it is strictly forbidden to trigger the next status action. The upgrade control module is used to coordinate the entire upgrade process, including upgrade package verification, idle state monitoring, upgrade partition writing, startup flag modification, rollback control and upgrade result reporting. The A / B dual-partition storage module is divided into a current running partition and a backup upgrade partition, which are used to store system images and upgrade data, and provide a carrier for partition writing, switching, and rollback status confirmation. The upgrade boot module is used to select the boot partition according to the boot flag bit when the terminal starts, perform a progressive four-level health check on the new partition, and trigger an atomic automatic rollback process when the health check fails.

[0155] Those skilled in the art will understand that the logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as a ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0156] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0157] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0158] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this patent should be determined by the appended claims.

Claims

1. A method for seamless intelligent upgrade of a terminal, characterized in that, The method includes: Based on the upgrade command, a pre-verification is performed to complete the pre-authorization, and then a private TCP upgrade data channel is established with the UMS server to complete two-way identity authentication and channel trust authorization. The upgrade packet is received through the TCP upgrade data channel in a block-by-block transmission and breakpoint resume mode, and the block-by-block real-time rights confirmation and full integrity rights confirmation are completed. Then, the idle upgrade opportunity is determined based on the multi-dimensional business status matrix. After the condition of no business interference is met, the rights-confirmed upgrade image is written to the spare partition of the dual partition, and the partition writing and ready rights confirmation are completed. Complete the atomic modification of the boot flag and the pre-boot check to complete the pre-boot ready authorization, confirm that it can boot normally after restart, execute the terminal restart, and perform multi-level progressive health checks in sequence after booting from the spare partition, and complete bidirectional authorization with the UMS server after all checks pass. Complete the entire upgrade process with the UMS server through hash chain verification, permanently switch partition roles and persist the entire process status, and generate the final confirmation certificate for successful upgrade.

2. The terminal intelligent seamless upgrade method according to claim 1, characterized in that, Each status node generates a confirmation credential using a hash chain structure. The confirmation credential of the next node must contain at least the hash value of the previous node, the unique task ID, and the unique terminal device ID.

3. The terminal intelligent seamless upgrade method according to claim 1, characterized in that, The terminal can obtain the upgrade task in either Push or Pull mode. The Push mode is characterized by the UMS server sending an upgrade task instruction to the terminal through a SIP signaling channel, and the terminal establishing a private TCP upgrade data channel with the UMS server based on the upgrade packet metadata in the instruction. The Pull mode involves the terminal periodically polling the UMS server for upgrade tasks via a SIP signaling channel or a private TCP channel. If there is an upgrade task to be executed for the corresponding terminal, the terminal obtains the upgrade package metadata and establishes a private TCP upgrade data channel.

4. The terminal intelligent seamless upgrade method according to claim 2, characterized in that, The block-by-block real-time rights confirmation specifically means that each data block must complete four layers of verification: transmission integrity rights confirmation, hash anti-tampering rights confirmation, sequence number continuity rights confirmation, and storage persistence rights confirmation. Only after all four layers pass the verification can the block be confirmed as having been received. The breakpoint resume mechanism works as follows: if the TCP connection is interrupted during transmission, the terminal persists a list of block indexes that have been verified and confirmed, along with their corresponding hash values. After reconnection, the terminal carries the list of confirmed blocks and hash values. After verification by UMS, the transmission continues from the missing block index without retransmitting the entire data.

5. The terminal intelligent seamless upgrade method according to claim 1, characterized in that, The multi-dimensional business status matrix covers at least the call status, conference status, RTP audio stream activity, user operation status, CPU load status, idle memory status, and SIP registration status. The multi-level idle threshold verification and continuous stability observation are as follows: First, the basic idle threshold verification of multiple dimensions is completed. After passing the verification, the system enters a stable observation window for a preset time period. Only when all dimensions in the window continuously meet the idle threshold are the system finally determined to meet the idle admission conditions.

6. The terminal intelligent seamless upgrade method according to claim 5, characterized in that, The multi-level progressive health check is performed in sequence as follows: kernel and system startup health check, basic network and SIP registration health check, voice service core function health check, and system stability and full-function compliance check. If the previous level check fails, atomic rollback is immediately triggered, and the next level check is never performed. The atomic rollback operation specifically involves the bootloader performing an atomic write operation to modify the boot flag, rolling back the boot partition to the original running partition, performing a terminal restart after a readback and verification, and completing a health check after the rollback to confirm that the terminal has returned to normal business status.

7. The terminal intelligent seamless upgrade method according to claim 1, characterized in that, If any node fails to confirm ownership during the upgrade process, an atomic rollback operation is triggered. This process includes rollback trigger confirmation, rollback execution confirmation, post-rollback health check, and final rollback completion confirmation, ensuring that the terminal is restored to its normal business state before the upgrade.

8. A terminal intelligent seamless upgrade system, characterized in that, The system includes a SIP server, an upgrade management server UMS, and multiple SIP terminals, which work together to implement the intelligent and seamless terminal upgrade method described in any one of claims 1 to 6. The SIP server is used to complete the registration and keep-alive interaction with the SIP terminal through the SIP signaling channel, maintain the registration status and keep-alive information of the terminal, and open the terminal registration status query interface to UMS. The UMS server is used for upgrade package management, upgrade task creation and scheduling, and provides a private TCP upgrade data channel that is completely independent of the SIP signaling channel. It receives the authorization certificate of each status node reported by the terminal and completes remote verification. After the verification is successful, it returns the corresponding authorization certificate to the terminal. Without authorization, the terminal is strictly prohibited from entering the next status. The SIP terminal is used to complete SIP registration and keep-alive, local authorization of each status node in the entire upgrade process, block reception and verification of upgrade packets, idle state determination, upgrade execution, rollback control and result reporting.

9. The terminal intelligent seamless upgrade system according to claim 8, characterized in that, The UMS and SIP terminal adopt a completely decoupled architecture between the SIP signaling channel and the private TCP upgrade data channel. The SIP signaling channel only carries registration keep-alive, status interaction and upgrade instructions, and does not carry any upgrade data traffic throughout the process.

10. A SIP terminal device, characterized in that, It includes a SIP protocol stack module, a service status monitoring module, a private TCP transmission module, a status confirmation core module, an upgrade control module, an A / B dual-partition storage module, and an upgrade boot module, used to execute the terminal intelligent seamless upgrade method according to any one of claims 1 to 6; The SIP protocol stack module is used to complete registration and keep-alive with the SIP server through the SIP signaling channel and maintain the SIP registration status; The service status monitoring module is used to collect the multi-dimensional operating status of the terminal for SIP voice services in real time, construct and update the service status matrix, and complete the confirmation of idle access status. The private TCP transmission module is used to establish a private TCP upgrade data channel with UMS that is independent of the SIP signaling channel, to perform block transmission of upgrade packets, breakpoint resumption, and data encryption and decryption, and to complete the status confirmation of the transmission stage. The core module for status confirmation is used to coordinate the status verification, credential generation, and two-way synchronization of the entire upgrade process, and to perform local confirmation, credential reporting, and permission reception for each status node. Without permission, it is strictly forbidden to trigger the next status action. The upgrade control module is used to coordinate the entire upgrade process, including upgrade package verification, idle state monitoring, upgrade partition writing, startup flag modification, rollback control and upgrade result reporting. The A / B dual-partition storage module is divided into a current running partition and a backup upgrade partition, which are used to store system images and upgrade data, and provide a carrier for partition writing, switching, and rollback status confirmation. The upgrade boot module is used to select the boot partition according to the boot flag bit when the terminal starts, perform a progressive four-level health check on the new partition, and trigger an atomic automatic rollback process when the health check fails.

Images