An eSIM management method, system, device and medium for internet of things devices

Abstract

The present disclosure relates to the technical field of communication management, in particular to an eSIM management method and system for Internet of Things devices, a device and a medium. A data model containing device entities, configuration files and operation tasks is constructed, and the association relationship among the three is established; based on a preset life cycle state machine, the state of the device at each stage of the life cycle and the state migration rules are defined; a batch operation request initiated by an external system is received through a northbound interface, corresponding task records are generated, and the state machine is used to drive the state transition of the device; the tasks are sharded and concurrently scheduled by a batch processing engine, and the life cycle operations are executed by calling the operator interface or the device side interface. The present disclosure can solve the problems of eSIM management process fragmentation, state tracking difficulty and lack of unified batch scheduling capability in the cross-operator scenario, realize the full-process automated management of large-scale Internet of Things devices, and improve the traceability and security of the operation.

Description

Technical Field

[0001] This disclosure relates to the field of communication management technology, and in particular to an eSIM management method, system, device and medium for Internet of Things (IoT) devices. Background Technology

[0002] With the rapid development of IoT technology, the scale of IoT device connections has exploded. To meet the demands for device miniaturization, flexibility, and global roaming, a large number of IoT terminals are gradually migrating from traditional physical SIM cards to eSIM (Embedded SIM) solutions. eSIM technology enables remote configuration and management by directly embedding SIM card functionality into the device chip, greatly improving the flexibility of device deployment.

[0003] However, in the current large-scale application and management of eSIM IoT devices, the following technical problems and challenges still exist: 1. Management processes are fragmented and lack unified batch scheduling capabilities.

[0004] Currently, the mainstream approach to downloading and managing eSIM profiles still relies on manual processing by operators or on single-device scanning via the LPA (Local Profile Assistant) application on the terminal side. This "single SIM, single operation" model is extremely inefficient when dealing with scenarios such as "mass number writing at the factory" and "large-scale on-site deployment" involving millions of devices. Furthermore, the interface standards of different operators' Connection Management Platforms (CMPs) vary significantly, often requiring companies to write specific scripts for each operator. These scripts are not only difficult to reuse and maintain, but also lack a unified batch processing scheduling mechanism, failing to support high-concurrency, large-scale automated management needs.

[0005] 2. The lifecycle management is rudimentary, making it difficult to guarantee the accuracy and consistency of data.

[0006] Existing IoT SIM card lifecycle management largely relies on offline ledgers such as Excel for recording, mainly covering static data such as activation time, operator information, device binding relationships, and deregistration status. This offline management method lacks platform-level state machine support and cannot reflect the actual current state of the device in real time (such as intermediate states like "writing card" or "activating"). Due to the lack of a unified data model and state transition mechanism, data is prone to recording errors or update delays, leading to a disconnect between the business system and the actual state of the device.

[0007] 3. Operation and maintenance are highly dependent on manual labor, with insufficient fault tolerance and traceability capabilities.

[0008] In critical stages such as equipment manufacturing, carrier switching, and project decommissioning, maintenance personnel often need to intervene manually frequently. This manual operation mode is not only inefficient but also carries a high risk of human error, and information synchronization is prone to discrepancies. Furthermore, existing log records are mostly simple API call records, lacking chain-like, tamper-proof auditing capabilities. In the event of business disputes or system failures, it is difficult to reconstruct the complete operational chain, hindering subsequent problem tracing, responsibility determination, and risk control and compliance management.

[0009] In summary, existing technologies lack an eSIM automated management solution that can operate across operators, support large-scale concurrency, have a full lifecycle state machine drive, and be auditable and traceable, making it difficult to meet the needs of the future IoT industry for refined and intelligent operation. Summary of the Invention

[0010] To address the aforementioned issues, this disclosure provides an eSIM management method, system, device, and medium for Internet of Things (IoT) devices.

[0011] Firstly, an eSIM management method for IoT devices includes: Construct a data model that includes device entities, configuration files, and operational tasks, and establish the relationships among the three. Based on a preset lifecycle state machine, manage the state and state transition rules of the device at each stage of its lifecycle; The system receives batch operation requests from external systems via an interface, generates corresponding task records, and uses a lifecycle state machine to drive the flow of device states. The batch processing engine segments and concurrently schedules tasks, executing lifecycle operations. Handle exceptions during task execution through strategic retries; Record lifecycle operations and build an immutable audit log using a chained hash structure.

[0012] Furthermore, the data model specifically includes a device table, a configuration file table, and a task table: The device table is used to record the unique identifier of the IoT terminal, the project to which it belongs, the currently bound eSIM identifier, the current lifecycle status, and the operator information; The configuration file table is used to record the identifier, type, operator, and download status of the eSIM configuration file; The task table is used to record the type of operation performed on the device and configuration file, the task status, the number of retries, and the execution channel information; The device table, configuration file table, and task table are linked through foreign keys to establish the binding relationship between devices and configuration files, as well as the driving relationship between lifecycle status and operation tasks.

[0013] Furthermore, the lifecycle state machine includes the stages of manufacturing, card writing, activation, use, card replacement and cancellation, with each stage containing at least one subdivided state; State transition rules are used to characterize the forward transition paths between sub-states and the fallback paths in abnormal situations; When an external request, interface callback result, or device status report is received, the device status in the lifecycle state machine is updated according to the current status and migration rules, and the associated task records are updated synchronously.

[0014] Furthermore, the states at each stage of the lifecycle include at least the following states: Factory release, card pending, card writing, card pending activation, card activation in progress, activated, in use, card pending replacement, card replacement in progress, card pending cancellation, card cancellation in progress, card cancellation already cancelled.

[0015] Furthermore, the batch processing engine performs task partitioning and concurrent scheduling, including: The task queue is segmented according to the carrier, project, and batch of the device, and the segmented tasks are then assigned to the corresponding execution channels. Monitor the interface rate limit indicators and queue depth of each execution channel, and dynamically adjust the concurrency of each channel; Multithreading or distributed message queues are used to consume tasks in each channel in parallel.

[0016] Furthermore, exceptions during task execution are handled through strategic retries, including: When a task fails, a fallback path is entered for abnormal situations, and a retry strategy is matched according to the error type: exponential backoff retry is performed for transient failures, and business errors are marked as permanent failures. Monitor the online status of devices, identify offline devices that are in the middle of execution, and automatically trigger the continuation process of unfinished tasks after the device comes back online.

[0017] Furthermore, an immutable audit log is constructed using a chained hash structure, including: Retrieve the content of the current operation log and the first hash value of the previous operation log; Add the first hash value to the current operation log and calculate the second hash value; Each log entry contains the hash value of the previous log entry, forming a chain hash structure; During the audit verification phase, the continuity of hash values ​​in the log chain is checked to determine whether the log records have been tampered with.

[0018] Secondly, an eSIM management system for IoT devices includes: Data modeling unit, status management unit, task scheduling unit, fault tolerance processing unit, and audit log unit; The data modeling unit is used to build a data model that includes device entities, configuration files, and operational tasks, and to establish the relationship between the three. The state management unit, based on a preset lifecycle state machine, is used to manage the state and state transition rules of the device at each stage of its lifecycle. The task scheduling unit is used to receive batch operation requests initiated by external systems through an interface, generate corresponding task records, and drive the device state transition using a lifecycle state machine. The task scheduling unit is also used to shard and concurrently schedule tasks through the batch processing engine and execute lifecycle operations; The fault tolerance unit is used to handle exceptions during task execution through strategic retries; The audit log unit is used to record lifecycle process operations and uses a chained hash structure to build an immutable audit log.

[0019] Thirdly, an electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, which stores computer programs; When a processor executes a computer program stored in memory, it implements the aforementioned eSIM management method for Internet of Things (IoT) devices.

[0020] Fourthly, a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned eSIM management method for Internet of Things (IoT) devices.

[0021] This disclosure includes at least the following beneficial effects: This disclosure can solve the problems of fragmented eSIM management processes, difficulty in status tracking, and lack of unified batch scheduling capabilities in cross-carrier scenarios, realize full-process automated management of large-scale IoT devices, and improve the traceability and security of operations.

[0022] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objects and other advantages of this disclosure may be realized and obtained by means of the structures pointed out in the description and the accompanying drawings. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0024] Figure 1 This is a schematic diagram of the management method flow according to an embodiment of the present disclosure; Figure 2 This is a schematic diagram of the management system architecture according to an embodiment of the present disclosure; Figure 3 This is a schematic diagram of the electronic device structure according to an embodiment of the present disclosure. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0026] like Figure 1 As shown, an eSIM management method for IoT devices includes: S101, Construct a data model that includes device entities, configuration files and operation tasks, and establish the relationship between the three; S102, based on a preset lifecycle state machine, manages the state and state transition rules of the device at each stage of its lifecycle; S103 receives batch operation requests initiated by external systems through an interface, generates corresponding task records, and uses a lifecycle state machine to drive the device state transition. S104 uses a batch processing engine to slice and concurrently schedule tasks, and executes lifecycle operations. S105, handles exceptions during task execution through strategic retries; S106 records lifecycle process operations and uses a chained hash structure to build an immutable audit log.

[0027] In practice: Construct a three-table data model: "Device – Profile – Task": The device table records information such as the unique identifier (e.g., EID / IMEI / SN) of each IoT terminal, the project to which it belongs, the currently bound eSIM card number, the current lifecycle status, and the operator to which it belongs.

[0028] The Profile table is used to record eSIM profile information for different operators, including ICCID, Profile type, operator, and status (not downloaded, downloaded, activated, deactivated), etc.

[0029] The task table records various lifecycle operations performed on devices and profiles, such as "card writing task," "activation task," "card replacement task," and "card cancellation task," and includes fields such as task status, retry count, error code, and resource channel. The three tables are linked through foreign keys, enabling relationship modeling where one device corresponds to one or more profiles, and one lifecycle operation corresponds to one or more tasks.

[0030] Design a 12-level lifecycle state machine: The device lifecycle is subdivided into at least 12 states: factory, card pending, card writing, pending activation, activation in progress, activated, in use, card pending replacement, card replacement in progress, pending cancellation, cancellation in progress, and cancelled.

[0031] The state machine defines the legal transition relationships between states, such as "card to be written → card writing → card to be activated → card activation → activated → in use", and specifies the fallback path in case of abnormal situations, such as "activation → abnormal → retry" or "activation → failure → manual processing".

[0032] The state machine is linked with the task table, and the corresponding task record is automatically generated or updated when the life cycle state changes.

[0033] Batch-Task batch processing engine: The batch processing engine supports concurrent processing of more than 10,000 tasks at a time. Tasks are sharded and allocated to different execution channels based on factors such as the device's operator, project, and batch.

[0034] The engine adopts a multi-threaded or distributed execution architecture to consume task queues from different channels in parallel, and dynamically adjusts the concurrency based on information such as queue depth and carrier interface rate limits.

[0035] For each task, it is executed according to a predefined sequence of steps. For example, the card writing task includes obtaining an available profile, issuing a writing command, waiting for callback or polling results, and updating the device status.

[0036] A three-step fault-tolerance mechanism: "Asynchronous – Callback – Retry" All calls to the device or operator platform are made in an asynchronous mode. The platform first creates a task and sends an instruction, and then immediately returns the acceptance result, which is then listened to and called back asynchronously by the background.

[0037] For device or carrier interfaces that support callbacks, the system updates the task status and lifecycle status based on the callback results; for scenarios that do not support callbacks, the system obtains the execution results by periodically polling the interface.

[0038] When a task fails, a retry strategy is matched based on the error code and the reason for failure: for example, network timeouts can be retried multiple times at intervals, while parameter errors are directly marked as "permanent failure pending manual handling"; for devices that go offline during execution, when the device comes back online and reports its status, the system automatically identifies that it is in an intermediate state and continues to execute subsequent steps, realizing "automatic resume after offline devices come back online".

[0039] Northbound RESTful API integration with business systems: The platform provides a set of RESTful APIs to interface with CRM / ERP / production management systems, supporting requests such as "factory card writing", "batch activation", "batch card replacement", and "batch cancellation" based on equipment batch, order number, or work order ID.

[0040] The docking system only requires submitting the device list and target lifecycle actions. The platform automatically generates corresponding tasks and promotes the state machine flow, realizing activation upon leaving the factory and automatic closed-loop of work orders.

[0041] Blockchain-based audit log recording mechanism: All critical operations (task creation, state transition, API calls, exception handling, etc.) form a chain log, with each log containing the hash value of the previous log, forming an immutable structure similar to a blockchain.

[0042] In the event of a dispute or failure, the log chain can be used to verify whether the operation record has been tampered with and to restore the execution status of each step in the lifecycle, thereby improving auditability and compliance.

[0043] Optionally, in the implementation of the batch processing task engine, a message queue system (such as Kafka, Pulsar, etc.) can be used to replace the self-developed task table, and the life cycle tasks can be encapsulated as messages for distributed consumption, but the state machine and channel sharding logic proposed in this invention are still used.

[0044] Optionally, blockchain-based audit logs can be downgraded to a local verification structure based on Merkle Tree in some scenarios. That is, by building a hash tree on batch logs, the log set can be verified to see if it has been tampered with, achieving lightweight anti-tampering capabilities without introducing a complete blockchain system.

[0045] Optionally, for the interaction protocol with the device, MQTT queues, HTTP long connections, or WebSocket protocols can be used to achieve lifecycle process management through asynchronous callbacks and task status updates.

[0046] Most existing solutions are geared towards single-card or small-batch operations, lacking unified batch processing and scheduling capabilities for millions of IoT terminals, making it difficult to support high-concurrency scenarios such as "card writing at the factory" and "centralized online deployment".

[0047] Existing systems generally do not model "device-Profile-task" in a unified way, lack fine-grained lifecycle state management and automatic flow mechanism, resulting in operations such as activation, card replacement, and cancellation being highly dependent on manual judgment and intervention.

[0048] Existing solutions primarily rely on simple API call records for logs, lacking chain-like and tamper-proof auditing capabilities, which hinders traceability in operational and security compliance scenarios. The purpose of this invention is to provide an automated batch lifecycle management method for eSIM devices in the Internet of Things (IoT) sector. Through state machine-driven and task orchestration, it achieves fully automated management across operators and batches, forming a complete and traceable audit chain.

[0049] This disclosure represents a leap from discrete management to refined state machine-driven management, significantly improving management accuracy and controllability. Existing technologies largely rely on Excel or simple information tables, resulting in fragmented states and delayed updates. This invention constructs a three-table data model of "device – profile – task" and designs a 12-level lifecycle state machine, providing fine-grained digital modeling of the entire process of equipment from manufacturing to deregistration. This state machine-driven approach ensures that every state change follows a predefined legal path (e.g., "card to be written → card writing in progress → pending activation") and can automatically handle exception rollbacks. Compared to manual ledgers, this solution completely eliminates the risk of information omissions and record errors, achieving precise control and automated flow of the status of millions of devices.

[0050] This invention possesses the capability for batch processing tens of thousands of concurrent requests, significantly improving the efficiency of large-scale deployments. Addressing the issues of low script invocation efficiency and inability to handle large-scale concurrency in existing technologies, the batch processing task engine provided by this invention supports intelligent sharding of massive tasks based on dimensions such as carrier and project. Through parallel task consumption using a multi-threaded or distributed architecture, combined with an adaptive concurrency adjustment algorithm based on interface rate limiting and queue depth, the system can maximize throughput under carrier interface constraints. This effectively solves performance bottlenecks in scenarios such as "batch number writing at the factory" and "centralized deployment," reducing the total activation time for large numbers of devices from several days to several hours, greatly improving the speed of business deployment.

[0051] This disclosure constructs an intelligent three-level fault-tolerance mechanism, significantly reducing operation and maintenance costs and manual intervention. Existing solutions often require manual re-execution of scripts or troubleshooting when facing network fluctuations or device outages. This invention achieves automatic recovery from transient failures such as network timeouts through a fault-tolerance framework of "asynchronous call – callback / polling – strategic retry". In particular, for the common "outage" problem of IoT devices, the system has the ability of "automatic resume upon reconnection", which can automatically identify that the device is in an intermediate state and continue to execute unfinished tasks. This mechanism greatly reduces manual intervention due to network instability, improves the final success rate of task execution, and significantly reduces operation and maintenance costs.

[0052] This disclosure establishes a chain-like, tamper-proof audit system that meets high standards of compliance and risk control. Traditional log records are easily tampered with and difficult to prove their innocence, hindering security auditing. This invention innovatively introduces a chain-like hash structure to store audit logs, where each operation log contains the hash value of the previous log, forming an immutable chain of operations. In the event of disputes or failures, the execution details of each step in the lifecycle can be fully reconstructed, verifying the authenticity of the records. This provides enterprises with a powerful data traceability tool, effectively improving the system's security compliance level and risk management capabilities.

[0053] This disclosure achieves business closed-loop and ecosystem integration, enhancing user experience and system scalability. Through a standardized northbound RESTful API, this invention can seamlessly connect to enterprise CRM, ERP, or production management systems, directly transforming business work orders into underlying technical tasks. This closed-loop mechanism, which connects the entire process of "business order placement – ​​automatic execution – status feedback," eliminates information silos, allowing business personnel to complete complex eSIM management operations without needing to concern themselves with underlying technical details, greatly improving cross-departmental collaboration efficiency and end-user experience.

[0054] like Figure 2 As shown, an eSIM management system for Internet of Things (IoT) devices includes: Data modeling unit 201, status management unit 202, task scheduling unit 203, fault tolerance processing unit 204, and audit log unit 205; Data modeling unit 201 is used to construct a data model that includes device entities, configuration files and operation tasks, and to establish the relationship between the three. The state management unit 202, based on a preset lifecycle state machine, is used to manage the state and state transition rules of the device at each stage of its lifecycle. The task scheduling unit 203 is used to receive batch operation requests initiated by external systems through an interface, generate corresponding task records, and drive the device state transition using a lifecycle state machine. The task scheduling unit 203 is also used to slice and concurrently schedule tasks through the batch processing engine and perform lifecycle operations; The fault tolerance processing unit 204 is used to handle exceptions during task execution through strategic retries; Audit log unit 205 is used to record lifecycle process operations and uses a chained hash structure to build an immutable audit log.

[0055] In practice: This disclosure constructs a data model comprising device entities, configuration files, and operational tasks, establishing the relationships among these three elements. Based on a pre-defined lifecycle state machine, it defines the device's state and state transition rules at each stage of its lifecycle. It receives batch operation requests from external systems via a northbound interface, generates corresponding task records, and uses the state machine to drive device state transitions. A batch processing engine segments and concurrently schedules tasks, calling operator interfaces or device-side interfaces to execute lifecycle operations. This disclosure addresses the issues of fragmented eSIM management processes, difficulties in state tracking, and lack of unified batch scheduling capabilities in cross-operator scenarios, enabling fully automated management of large-scale IoT devices and improving operational traceability and security.

[0056] This disclosure addresses the lack of a unified state machine and batch scheduling mechanism in the eSIM lifecycle management of bulk IoT devices, enabling automated closed-loop management of "device leaving the factory → activation → SIM card replacement → cancellation".

[0057] This disclosure addresses the current issues of SIM card writing, activation, replacement, and cancellation operations being highly reliant on manual processes, having non-reusable scripts, and inconsistent failure handling in cross-carrier and multi-batch scenarios.

[0058] This disclosure addresses the challenges of tracking and auditing the state during the lifecycle process by constructing traceable operation logs and anomaly recovery mechanisms.

[0059] By using a three-table model of "device-profile-task" and a 12-level lifecycle state machine, we can achieve refined management of the eSIM lifecycle. Compared with manual ledgers based on Excel, the status is complete, traceable, and machine-readable, which greatly reduces information omissions and incorrect records.

[0060] This disclosure utilizes a Batch-Task batch processing engine and a channel sharding mechanism to support the concurrent execution of tens of thousands of tasks under the premise of operator interface rate limiting, significantly reducing the total activation time of a large number of devices and improving overall deployment efficiency.

[0061] This disclosure utilizes a three-level fault-tolerance framework of "asynchronous-callback-retry" and the ability to automatically resume operations after device launch to automate the handling of common abnormal scenarios such as disconnection and interface timeout, reducing manual intervention and improving the success rate and stability of lifecycle operations.

[0062] This disclosure establishes an immutable record of every step of the lifecycle through a blockchain-based audit log structure, providing a reliable basis for subsequent problem investigation, responsibility determination, and security compliance.

[0063] This disclosure integrates with systems such as CRM / ERP through a northbound RESTful API, enabling automatic card writing and activation during the factory process. Card replacement and cancellation are performed remotely by the platform, eliminating the need for on-site manual card removal and replacement operations, reducing maintenance costs and improving user experience.

[0064] like Figure 3 As shown, this disclosure provides an electronic device, including a processor 301, a communication interface 302, a memory 303, and a communication bus 304, wherein the processor 301, the communication interface 302, and the memory 303 communicate with each other through the communication bus 304; Memory 303 stores computer programs; The processor 301 implements the above method when executing a computer program stored in the memory 303.

[0065] This disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0066] The computer-readable storage medium may be included in the device / apparatus described in the above embodiments; or it may exist independently and not assembled into the device / apparatus. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0067] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0068] Although the present disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure.

Claims

1. A method for eSIM management of Internet of Things (IoT) devices, characterized in that, include: Construct a data model that includes device entities, configuration files, and operational tasks, and establish the relationships among the three. Based on a preset lifecycle state machine, manage the state and state transition rules of the device at each stage of its lifecycle; The system receives batch operation requests from external systems via an interface, generates corresponding task records, and uses a lifecycle state machine to drive the flow of device states. The batch processing engine segments and concurrently schedules tasks, executing lifecycle operations. Handle exceptions during task execution through strategic retries; Record lifecycle operations and build an immutable audit log using a chained hash structure.

2. The eSIM management method for IoT devices according to claim 1, characterized in that, The data model specifically includes a device table, a configuration file table, and a task table: The device table is used to record the unique identifier of the IoT terminal, the project to which it belongs, the currently bound eSIM identifier, the current lifecycle status, and the operator information; The configuration file table is used to record the identifier, type, operator, and download status of the eSIM configuration file; The task table is used to record the type of operation performed on the device and configuration file, the task status, the number of retries, and the execution channel information; The device table, configuration file table, and task table are linked through foreign keys to establish the binding relationship between devices and configuration files, as well as the driving relationship between lifecycle status and operation tasks.

3. The eSIM management method for IoT devices according to claim 1, characterized in that, The lifecycle state machine includes the stages of manufacturing, card writing, activation, use, card replacement and cancellation, and each stage contains at least one sub-state. State transition rules are used to characterize the forward transition paths between sub-states and the fallback paths in abnormal situations; When an external request, interface callback result, or device status report is received, the device status in the lifecycle state machine is updated according to the current status and migration rules, and the associated task records are updated synchronously.

4. The eSIM management method for IoT devices according to claim 1, characterized in that, The states at each stage of the lifecycle must include at least the following states: Factory release, card pending, card writing, card pending activation, card activation in progress, activated, in use, card pending replacement, card replacement in progress, card pending cancellation, card cancellation in progress, card cancellation already cancelled.

5. The eSIM management method for IoT devices according to claim 1, characterized in that, Tasks are sharded and concurrently scheduled using a batch processing engine, including: The task queue is segmented according to the carrier, project, and batch of the device, and the segmented tasks are then assigned to the corresponding execution channels. Monitor the interface rate limit indicators and queue depth of each execution channel, and dynamically adjust the concurrency of each channel; Multithreading or distributed message queues are used to consume tasks in each channel in parallel.

6. The eSIM management method for IoT devices according to claim 1, characterized in that, Handling exceptions during task execution through strategic retries includes: When a task fails, a fallback path is entered for abnormal situations, and a retry strategy is matched according to the error type: exponential backoff retry is performed for transient failures, and business errors are marked as permanent failures. Monitor the online status of devices, identify offline devices that are in the middle of execution, and automatically trigger the continuation process of unfinished tasks after the device comes back online.

7. The eSIM management method for IoT devices according to claim 1, characterized in that, An immutable audit log is constructed using a chained hash structure, including: Retrieve the content of the current operation log and the first hash value of the previous operation log; Add the first hash value to the current operation log and calculate the second hash value; Each log entry contains the hash value of the previous log entry, forming a chain hash structure; During the audit verification phase, the continuity of hash values ​​in the log chain is checked to determine whether the log records have been tampered with.

8. An eSIM management system for Internet of Things (IoT) devices, characterized in that, include: Data modeling unit, status management unit, task scheduling unit, fault tolerance processing unit, and audit log unit; The data modeling unit is used to build a data model that includes device entities, configuration files, and operational tasks, and to establish the relationship between the three. The state management unit, based on a preset lifecycle state machine, is used to manage the state and state transition rules of the device at each stage of its lifecycle. The task scheduling unit is used to receive batch operation requests initiated by external systems through an interface, generate corresponding task records, and drive the device state transition using a lifecycle state machine. The task scheduling unit is also used to shard and concurrently schedule tasks through the batch processing engine and execute lifecycle operations; The fault tolerance unit is used to handle exceptions during task execution through strategic retries; The audit log unit is used to record lifecycle process operations and uses a chained hash structure to build an immutable audit log.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, which stores computer programs; A processor, when executing a computer program stored in memory, implements an eSIM management method for Internet of Things (IoT) devices according to any one of claims 1-7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements an eSIM management method for Internet of Things (IoT) devices as described in any one of claims 1-7.

Images