ESIM remote configuration management method based on cloud platform and cloud platform

Abstract

The invention provides an eSIM remote configuration management method based on a cloud platform and the cloud platform, and the method comprises the steps: obtaining a real-time configuration request of target eSIM equipment, and extracting an environment feature set and equipment identification features in the real-time configuration request, a corresponding dynamic strategy model is matched from a pre-constructed dynamic strategy model library according to the equipment identification features, a configuration strategy sequence of the target eSIM equipment is generated based on the environment feature set and the matched dynamic strategy model, and a remote configuration instruction is generated according to a highest priority candidate configuration parameter group in the configuration strategy sequence, and sending the remote configuration instruction to the target eSIM device through the cloud platform interface, receiving configuration response data returned by the target eSIM device, and updating a policy generation rule of a dynamic policy model associated with the device identification feature in a dynamic policy model library according to the configuration response data. According to the invention, the automation, adaptability and stability of remote configuration management of the eSIM device can be improved.

Description

Technical Field

[0001] The present invention relates to the field of data processing, and in particular to a cloud platform-based eSIM remote configuration management method and a cloud platform. Background Art

[0002] At present, with the popularization of eSIM technology, remote configuration management has become the core link for operators and equipment manufacturers to achieve large-scale equipment deployment. In related technologies, configuration strategies are usually generated based on a single dimension such as device model or network signal strength; for example, the device hardware model is matched with a preset static rule base, and a fixed configuration parameter group is directly called and sent to the target device; for example, the configuration instruction of whether to trigger the high power consumption mode is determined based on the real-time signal strength threshold. However, the above methods have significant defects in dealing with complex and changeable network environments and massive heterogeneous devices: the static rule base cannot dynamically adapt to the device firmware version upgrade or operator policy adjustment, resulting in mismatch between configuration parameters and actual device compatibility, causing configuration failure or functional abnormality; the single signal strength threshold decision ignores the synergistic effects of geographical location differences (such as urban base station dense areas and remote areas) and network access mode switching (such as 5G / Wi-Fi seamless switching), resulting in a disconnect between configuration strategies and actual network conditions, resulting in resource waste or reduced connection stability. In addition, the fixed design of encrypted transmission and fragmentation strategies in traditional solutions makes it difficult to balance the command integrity in low-signal areas and the data protection requirements in high-security scenarios, exacerbating the risk of configuration delays or interruptions. The above problems seriously restrict the automated configuration efficiency and user experience of eSIM devices. Summary of the invention

[0003] The present invention provides an eSIM remote configuration management method based on a cloud platform and a cloud platform.

[0004] According to one aspect of the present invention, a cloud platform-based eSIM remote configuration management method is provided, the method comprising: Obtaining a real-time configuration request of a target eSIM device, and extracting an environmental feature set and a device identification feature in the real-time configuration request; the environmental feature set includes a network access mode, a geographic location coordinate, and a signal strength distribution parameter; According to the device identification feature, a corresponding dynamic policy model is matched from a pre-built dynamic policy model library; the dynamic policy model is generated by training historical configuration data, and each dynamic policy model is associated with at least one set of configuration policy generation rules; Based on the environmental feature set and the matching dynamic policy model, generating a configuration policy sequence for the target eSIM device; the configuration policy sequence includes a plurality of candidate configuration parameter groups sorted by priority; Generate a remote configuration instruction according to the highest priority candidate configuration parameter group in the configuration policy sequence, and send the remote configuration instruction to the target eSIM device through the cloud platform interface; Receive configuration response data returned by the target eSIM device, and update the policy generation rule of the dynamic policy model associated with the device identification feature in the dynamic policy model library according to the configuration response data.

[0005] According to another aspect of the present invention, there is provided a cloud platform, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the above method.

[0006] The present invention has at least the following beneficial effects: The eSIM remote configuration management method based on the cloud platform provided by the present invention obtains the real-time configuration request of the target eSIM device and extracts its environmental feature set and device identification features, matches the corresponding model in the pre-built dynamic policy model library, generates a configuration policy sequence with priority sorting, and then issues remote configuration instructions, and updates the model library according to the device feedback data. In this way, the dynamic policy model library can form a closed-loop optimization mechanism based on historical configuration data and real-time feedback, ensure that the policy generation rules always adapt to the diversity of devices and dynamic changes in the network environment, and significantly improve the accuracy and reliability of configuration instructions. The environmental feature set integrates multi-dimensional information such as network access mode, geographic location coordinates, and signal strength distribution parameters, and through deep matching with the conditional branches in the dynamic policy model, selects the optimal configuration strategy covering the current network status and device location, avoiding policy conflicts or resource waste caused by single parameter decisions. The hierarchical decomposition and multi-level matching mechanism of device identification features accurately locates the most compatible dynamic policy model through layer-by-layer screening of hardware models, firmware versions, and operator codes, and triggers similarity evaluation and alternative model selection when matching fails, effectively solving the configuration adaptation problem in new model devices or cross-operator scenarios. The dynamic calibration and real-time reordering mechanism of the configuration strategy sequence can automatically adjust parameter priorities according to signal fluctuations or network switching, ensuring that the instruction generation and transmission process always adapts to real-time environmental changes and reduces the risk of configuration interruption. In addition, the encryption and fragmentation strategy integrated design of the remote configuration instructions directly drives the encryption process through security authentication parameters, and dynamically optimizes the data packet fragmentation rules based on network bandwidth and signal strength, thereby ensuring the security of data transmission while improving the success rate of instruction transmission in low-signal areas. The synergy of the above technical features has enabled breakthroughs in automation, adaptability and stability in the remote configuration management of eSIM devices, which is especially suitable for highly dynamic network environments and massive heterogeneous device scenarios, significantly reducing the cost of manual intervention and improving global configuration efficiency.

[0007] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The accompanying drawings exemplarily illustrate the embodiments and constitute a part of the specification, and together with the text description of the specification, are used to explain the exemplary implementation of the embodiments. The embodiments shown are for illustrative purposes only and do not limit the scope of the claims. In all drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0009] Figure 1 A schematic diagram of an application scenario of a cloud platform-based eSIM remote configuration management method according to an embodiment of the present invention is shown.

[0010] Figure 2 A flow chart of a cloud platform-based eSIM remote configuration management method according to an embodiment of the present invention is shown.

[0011] Figure 3 A schematic diagram of the composition of a cloud platform according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0012] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be appreciated by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope of the present invention. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0013] The terms used in the description of various examples in the present invention are only for the purpose of describing specific examples and are not intended to be limiting. Unless the context clearly indicates otherwise, if the number of elements is not specifically limited, the element can be one or more. In addition, the term "and / or" used in the present invention covers any one of the listed items and all possible combinations.

[0014] Figure 1 A schematic diagram of an application scenario of a method provided according to an embodiment of the present invention is shown. The application scenario includes one or more eSIM devices 101, a cloud platform 120, and one or more communication networks 110 coupling the one or more eSIM devices 101 to the cloud platform 120. In some embodiments, the cloud platform 120 may also provide eSIM configuration services or software applications. In some embodiments, these services may be provided as web-based services or cloud services, for example, provided to users of the eSIM devices 101 under a software as a service (SaaS) model.

[0015] exist Figure 1 In the configuration shown, the cloud platform 120 may include one or more components that implement the functions performed by the cloud platform 120. These components may include software components, hardware components, or a combination thereof that can be executed by one or more processors. A user operating the eSIM device 101 may in turn utilize one or more applications to interact with the cloud platform 120 to utilize the services provided by these components. It should be understood that a variety of different system configurations are possible, which may differ from application scenarios. Therefore, Figure 1 is one example of a system for implementing the various methods described herein and is not intended to be limiting.

[0016] The eSIM device 101 may include various types of terminal devices, such as portable handheld devices, wearable devices, various messaging devices, tablet computers, etc. Portable handheld devices may include cellular phones, smart phones, tablet computers, personal digital assistants (PDAs), etc. Wearable devices may include head-mounted displays (such as smart glasses) and other devices.

[0017] The network 110 may be any type of network known to those skilled in the art that may support data communications using any of a variety of available protocols, including but not limited to TCP / IP, SNA, IPX, etc. By way of example only, the one or more networks 110 may be a local area network (LAN), an Ethernet-based network, a token ring, a wide area network (WAN), the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a blockchain network, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., Bluetooth, WIFI), and / or any combination of these and / or other networks.

[0018] The cloud platform 120 may include one or more general-purpose computers, dedicated server computers (e.g., PC (personal computer) servers, UNIX servers, mid-range servers), blade servers, mainframe computers, server clusters, or any other suitable arrangement and / or combination. The cloud platform 120 may include one or more virtual machines running virtual operating systems, or other computing architectures involving virtualization (e.g., one or more flexible pools of logical storage devices that may be virtualized to maintain a server's virtual storage device). In various embodiments, the cloud platform 120 may run one or more services or software applications that provide the functionality described below.

[0019] The computing units in the cloud platform 120 may run one or more operating systems including any of the above operating systems and any commercially available server operating systems. The cloud platform 120 may also run any of a variety of additional server applications and / or middle-tier applications, including HTTP servers, FTP servers, CGI servers, JAVA servers, database servers, etc.

[0020] In some embodiments, the cloud platform 120 may include one or more applications to analyze and consolidate data feeds and / or event updates received from users of the eSIM device 101. The cloud platform 120 may also include one or more applications to display the data feeds and / or real-time events via one or more display devices of the eSIM device 101.

[0021] In some embodiments, the cloud platform 120 may be a server of a distributed system, or a server combined with a blockchain. The cloud platform 120 may also be a cloud server, or an intelligent cloud computing server or intelligent cloud host with artificial intelligence technology. A cloud server is a host product in a cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and virtual private servers (VPS) services.

[0022] The application scenario may also include one or more databases 130. In some embodiments, these databases may be used to store data and other information. For example, one or more of the databases 130 may be used to store historical data. The database 130 may reside in various locations. For example, the database used by the cloud platform 120 may be local to the cloud platform 120, or may be remote from the cloud platform 120 and may communicate with the cloud platform 120 via a network-based or dedicated connection. The database 130 may be of different types. In some embodiments, the database used by the cloud platform 120 may be, for example, a relational database. One or more of these databases may store, update, and retrieve data to and from the database in response to a command.

[0023] Please refer to Figure 2 The eSIM remote configuration management method based on the cloud platform provided by the embodiment of the present invention includes the following steps: Step S100: obtaining a real-time configuration request of a target eSIM device, and extracting an environmental feature set and a device identification feature in the real-time configuration request; the environmental feature set includes a network access mode, a geographic location coordinate, and a signal strength distribution parameter.

[0024] Exemplarily, a real-time configuration request refers to a request instruction initiated by the target eSIM device to the cloud platform through a wireless communication network to obtain specific configuration parameters, and its triggering conditions include but are not limited to the first activation of the device, changes in the network environment, or manual triggering by the user. The environmental feature set is a multi-dimensional parameter set used to describe the current operating environment of the target eSIM device, where the network access mode specifically refers to the type of network and the combination of communication protocols to which the device is currently connected, such as the coexistence of 4G cellular network and Wi-Fi dual-mode, 5G independent networking, or narrowband Internet of Things single-mode connection; the geographic location coordinates are obtained through the global positioning system or base station triangulation positioning technology to accurately identify the longitude and latitude information of the device; the signal strength distribution parameters include the signal strength values ​​of each frequency band detected by the device within a preset time period and their fluctuation characteristics, such as the mean signal strength of the 2.4GHz frequency band is -65dBm and the standard deviation is 8.2, and the signal strength of the 5GHz frequency band shows a periodic attenuation trend. The device identification feature is a combination of feature data that uniquely identifies the target eSIM device, including physical features that cannot be tampered with, such as the international mobile equipment identity code, integrated circuit card identifier, and hardware version number. By parsing the data packet structure of the real-time configuration request, the cloud platform uses a feature extraction algorithm to separate the environmental feature set and device identification features from the request header field and payload content, ensuring that the subsequent policy generation process has accurate input conditions.

[0025] Step S200: matching a corresponding dynamic policy model from a pre-built dynamic policy model library according to the device identification feature; the dynamic policy model is generated by training with historical configuration data, and each dynamic policy model is associated with at least one set of configuration policy generation rules.

[0026] Exemplarily, the dynamic policy model library is a collection of machine learning models stored in a distributed database of the cloud platform, and its construction process is based on the mapping relationship between the device identification features, environmental features and the configuration parameter groups that finally take effect recorded in the historical configuration data. For example, a time series neural network algorithm can be used for training and optimization. Each dynamic policy model corresponds to the configuration policy generation capability of a specific device type or hardware version, such as an anti-interference configuration model for industrial-grade eSIM devices or a low-power configuration model for consumer-grade devices. The configuration policy generation rules are a set of decision logic embedded in the dynamic policy model, including network access mode priority determination rules, signal strength threshold trigger conditions and geographic location area division strategies. When the hardware version number in the device identification feature matches the version code preset in the model library, the cloud platform calls the hash index mechanism to quickly locate the associated dynamic policy model, and at the same time loads the configuration policy generation rule set bound to the model to provide a rule basis for subsequent policy sequence generation. For example, when the device identification feature shows that the target eSIM device is a certain model of vehicle-mounted terminal, the dynamic policy model will give priority to matching a dedicated model that supports multi-network fast switching and high signal fault tolerance mechanism.

[0027] As an implementation method, the generation process of the dynamic policy model library may include the following steps: Step S201: Acquire configuration operation data sets of multiple historical eSIM devices; the configuration operation data sets include environmental feature records, configuration parameter execution records, and configuration result evaluation indicators of each historical eSIM device.

[0028] Exemplarily, the configuration operation data set is a structured collection of historical eSIM device full life cycle operation data collected by the cloud platform log system, and its data sources include device activation requests, configuration instruction issuance records, and network performance monitoring results. Environmental feature records, for example, refer to a time series data set of network access modes, geographic location coordinates, and signal strength distribution parameters reported by the device in a historical time period, such as the 4G / 5G dual-mode switching records, longitude and latitude trajectories, and mean square error values ​​of signal strengths in different frequency bands recorded by a certain model of vehicle-mounted terminal for 30 consecutive days. Configuration parameter execution records include the network access configuration, frequency band locking strategy, and power consumption control parameter combinations that are actually effective for the device, such as the 5GNSA mode, 3.5GHz main frequency band, and dynamic power adjustment threshold enabled in a certain configuration instruction. The configuration result evaluation index is a quantitative result of the effect of each configuration operation through a preset algorithm, including configuration success rate, signal stability gain, and energy consumption change rate. For example, a certain configuration operation reduces the signal switching failure rate of the device in a highway scenario by 12% and increases the average power consumption by 8%.

[0029] Step S202: extracting the device identification feature of each historical eSIM device from the configuration operation data set, and grouping the configuration operation data set based on the device identification feature to obtain sub-data sets corresponding to multiple device feature groups.

[0030] Exemplarily, the device identification feature is, for example, a set of immutable attributes extracted from the hardware information and registration information of historical eSIM devices, including the International Mobile Equipment Identity, the embedded SIM card serial number, and the firmware version number. For example, the device identification feature of a batch of industrial-grade eSIM devices contains a unified hardware version number "HW-5G-IND-01" and a pre-assigned SIM card number segment "89860121". Based on the hardware version number and the SIM card number segment prefix in the device identification feature, the configuration operation data set is divided into multiple device feature groups, for example, all device historical data with a hardware version number of "HW-5G-IND-01" and a SIM card number segment of "89860121" are classified into the same sub-data set. In this process, a distributed hashing algorithm is used to quickly group massive historical data to ensure that the sub-data set corresponding to each device feature group only contains configuration operation records for devices of the same type, thereby providing data consistency guarantee for subsequent rule extraction.

[0031] Specifically, for each sub-data set corresponding to each device feature group, the following processing can be performed: Step S203: construct an initial policy generation rule set according to the environmental feature records and configuration parameter execution records in the sub-dataset; the initial policy generation rule set includes multiple conditional branches, each conditional branch corresponds to a set of environmental feature threshold ranges and associated configuration parameter groups.

[0032] Exemplarily, the initial strategy generation rule set is, for example, a decision logic set extracted from the mapping relationship between historical environmental features and configuration parameters through an association rule mining algorithm. For example, for a sub-data set of a certain device feature group, analysis found that when the mean value of the 3.5GHz band strength in the signal strength distribution parameter is higher than -70dBm and the geographical location coordinates are in the central area of ​​the city, 95% of the historical configuration operations selected the 5G NSA mode and 256QAM modulation scheme. Based on such association relationships, an initial rule with a conditional branch of "IF the mean value of the 3.5GHz signal strength is ≥-70dBm AND the geographical location is in the central area of ​​the city THEN enable the 5G NSA mode and 256QAM modulation" is constructed. The environmental feature threshold range of each conditional branch is determined by a clustering algorithm. For example, after K-means clustering of the signal strength distribution parameters, -70dBm to -50dBm is divided into a high signal strength interval, and -90dBm to -70dBm is divided into a medium signal strength interval. The associated configuration parameter group selects the most frequently occurring valid combination from the historical configuration parameter execution records, such as the most frequently occurring 4G CA carrier aggregation and 2.4GHz Wi-Fi dual connection configuration in highway scenarios.

[0033] Step S204: Utilize the configuration result evaluation index in the sub-data set to optimize the initial policy generation rule set, and generate a dynamic policy model corresponding to the device feature group; wherein the optimization process includes merging redundant conditional branches, adjusting the environmental feature threshold range, and updating the priority of the configuration parameter group.

[0034] In an exemplary embodiment, the optimization process can iteratively modify the initial rules based on the configuration success rate, signal stability gain, and energy consumption change rate in the configuration result evaluation indicators. For example, a conditional branch stipulates "IF the network access mode is 4G single mode AND the signal strength standard deviation is ≤10dB THEN enable CA carrier aggregation", but its configuration success rate is only 65% ​​and the energy consumption change rate increases by 15%, indicating that the rule is redundant or the threshold setting is unreasonable. By merging adjacent conditional branches covering the same environmental feature range and adjusting the signal strength standard deviation threshold to 8dB, the optimized rule configuration success rate is increased to 82%, while the energy consumption change rate is reduced to 5%. Priority updates are dynamically sorted according to the historical effects of the configuration parameter group. For example, the priority of the configuration parameter group with a signal stability gain higher than 20% is increased, while the configuration parameter group with an energy consumption change rate exceeding the preset threshold is downgraded to an alternative. The final generated dynamic policy model encodes the optimized policy generation rule set into executable decision logic and stores it in conjunction with the device feature group.

[0035] Step S205: storing the optimized dynamic policy model in the dynamic policy model library, and establishing a mapping relationship between the dynamic policy model and the device identification feature of the corresponding device feature group.

[0036] Exemplarily, the dynamic policy model library can use a graph database to store the topological relationship between models, wherein each dynamic policy model uses the hardware version number and SIM card number segment in the device identification feature as the index key. For example, the dynamic policy model associated with the hardware version number "HW-5G-IND-01" and the SIM card number segment "89860121" is stored as a graph node, and its applicable geographical location area and network access mode constraints are recorded through edge attributes. The mapping relationship establishment process uses a two-way hash table to achieve fast retrieval. When the new device identification feature matches the existing device feature group, the cloud platform can directly call the associated dynamic policy model for real-time decision-making. In addition, the model version control mechanism ensures that each optimized dynamic policy model generates a unique version identifier to facilitate subsequent tracing and rollback operations.

[0037] As an implementation manner, the step S204, optimizing the initial strategy generation rule set using the configuration result evaluation index in the sub-data set, includes: Step S2041: extracting the configuration success rate, signal stability gain and energy consumption change rate from the configuration result evaluation indicators of the sub-data set.

[0038] Exemplarily, the configuration success rate refers to the proportion of historical configuration parameter groups that are successfully effective within the corresponding environmental feature threshold range. For example, if 108 out of 120 configuration operations triggered by a certain rule successfully complete APN authentication and frequency band locking, the configuration success rate is 90%. The signal stability gain is calculated by comparing the change in the standard deviation of signal strength before and after configuration. For example, after configuration, the standard deviation of the signal strength of the device within 24 consecutive hours drops from 15dB to 8dB, and the gain is 46.7%. The energy consumption change rate is quantified by the average power consumption ratio before and after configuration. For example, after configuration, the standby current of the device increases from 12mA to 13mA, and the change rate is 8.3%.

[0039] For example, for each conditional branch in the initial strategy generation rule set, the following operations are performed: Step S2042: Calculate the weighted score of the configuration success rate and signal stability gain of the historical configuration parameter group corresponding to the conditional branch.

[0040] For example, the weighted score is determined as follows: score = 0.6 × configuration success rate + 0.4 × signal stability gain, where the weight coefficients (0.6 and 0.4) are adaptively adjusted according to the device type. For example, industrial-grade devices focus on signal stability, and the weights are set to 0.5 and 0.5. If the configuration success rate of a conditional branch is 85% and the signal stability gain is 30%, then its weighted score is 0.6 × 85 + 0.4 × 30 = 63 points.

[0041] Step S2043: If the weighted score is lower than a preset score threshold, the conditional branch is deleted, and the environmental feature threshold range covered by the conditional branch is merged into an adjacent conditional branch.

[0042] Exemplarily, the preset scoring threshold is set according to the performance baseline of the device feature group, for example, the threshold for consumer-grade devices is 60 points, and the threshold for industrial-grade devices is 70 points. When a conditional branch scores 55 points, the signal strength range [-80dBm, -70dBm] it covers will be merged into the adjacent [-70dBm, -60dBm] interval, and the merged rule score will be recalculated.

[0043] Step S2044: If the weighted score is higher than or equal to the preset score threshold but the energy consumption change rate exceeds the preset energy consumption threshold, the power consumption control parameters in the configuration parameter group associated with the conditional branch are adjusted, and the configuration result evaluation index is recalculated.

[0044] Exemplarily, the preset energy consumption threshold is set according to the power capacity of the device, for example, 10% for vehicle terminals and 5% for wearable devices. If a rule scores 75 points but the energy consumption change rate is 12%, the transmit power in its configuration parameter group is reduced from 23dBm to 20dBm, and the historical data is re-collected to calculate the updated energy consumption change rate of 7%.

[0045] Step S2045: Generate an updated policy generation rule set according to the adjusted conditional branch, and input the updated policy generation rule set into the policy decision tree model for rule conflict detection.

[0046] Exemplarily, rule conflict detection traverses all paths of the policy decision tree model to identify whether there are multiple paths pointing to the same environmental feature range but associated with different configuration parameter groups. For example, when two rules simultaneously stipulate "IF network access mode is 5G AND geographic location is city center THEN enable frequency band A" and "IF signal strength ≥ -65dBm AND geographic location is city center THEN enable frequency band B", a conflict alarm will be triggered in the overlapping area of ​​frequency band A and frequency band B.

[0047] Step S2046: If a rule conflict is detected, the priority of the conflicting conditional branches is reordered until there is no conflicting path in the policy decision tree model.

[0048] For example, the priority reordering can be based on the weighted score of the configuration parameter group and the device type preference. For example, the configuration parameter group with high signal stability gain is preferred in industrial-grade devices, while the configuration parameter group with low energy consumption change rate is preferred in consumer-grade devices. After reordering, the policy decision tree model only retains the highest priority path within the same environmental feature range to ensure the uniqueness of the decision logic.

[0049] As an implementation mode, the process of constructing the strategy decision tree model includes the following steps: Step S20461: extracting the environmental characteristic threshold ranges and associated configuration parameter groups of all conditional branches from the updated policy generation rule set.

[0050] Exemplarily, the environmental feature threshold range is stored in the form of interval coding, for example, the network access mode is {4G, 5G}, the geographic location coordinates are longitude [116.3°, 116.5°] and latitude [39.9°, 40.1°], and the signal strength distribution parameter is the mean [-70dBm, -60dBm] and the standard deviation is ≤8dB. The associated configuration parameter group is converted into a binary instruction template, for example, "0x1A3B" means enabling 5G NSA mode, 3.5GHz frequency band and dynamic power control.

[0051] Step S20462: Taking the network access mode as the root node, construct a multi-layer decision node in the order of geographic location coordinates and signal strength distribution parameters.

[0052] Exemplarily, the root node first divides the network access mode of the device, for example, 4G, 5G and hybrid modes are used as three main branches. Under each main branch, subnodes are divided according to the longitude and latitude ranges of the geographic location coordinates, for example, "city center", "suburbs" and "remote areas" subnodes are created under the 5G branch. The final node is further subdivided according to the mean and standard deviation of the signal strength distribution parameters, for example, "signal strength mean ≥ -65dBm" and "signal strength mean <-65dBm" paths are created under the "city center" subnode.

[0053] Step S20463: Set the corresponding environmental feature threshold segmentation point at each decision node, and point the path that meets the segmentation point condition to the next layer of decision nodes or leaf nodes.

[0054] Exemplarily, the threshold segmentation point can be determined by using a binary method or an equal frequency binning method, for example, dividing the signal strength mean into intervals of [-90dBm, -85dBm), [-85dBm, -80dBm) at intervals of 5dB. When the device environment feature matches a certain segmentation point condition, the decision path is passed down along the corresponding branch until it reaches the leaf node.

[0055] Step S20464: associate the corresponding configuration parameter group at the leaf node, and set the execution order of the leaf node based on the priority of the configuration parameter group.

[0056] For example, at the leaf nodes with a signal strength mean value ≥ -65dBm, two parameter groups, "5G NSA high power configuration" and "5G SA medium power configuration", are associated, and the former is set as the default execution option according to its weighted score. If the default configuration fails to execute, subsequent parameter groups are tried in order of priority.

[0057] Step S20465: Prune the constructed initial policy decision tree, delete redundant paths that do not cover any historical environmental feature records, and use the pruned policy decision tree as the core decision structure of the dynamic policy model.

[0058] For example, the pruning algorithm can traverse all decision paths and remove branches that are not covered by historical data instances, such as deleting the branch of "mean signal strength ≥ -50dBm under 4G network" because this condition has never appeared in historical data. The pruned policy decision tree significantly improves the model execution efficiency and decision accuracy by removing paths with low generalization ability.

[0059] As an implementation manner, the step S200, matching the corresponding dynamic policy model from a pre-built dynamic policy model library according to the device identification feature, includes: Step S210: Decompose the device identification feature into a plurality of sub-feature sets, wherein the sub-feature sets include a hardware model code, a firmware version sequence, and an operator code combination.

[0060] Exemplarily, the device identification feature is a unique identification data set extracted from the non-volatile memory of the target eSIM device, and its decomposition process can be achieved by a feature parsing algorithm. The hardware model is encoded as a hardware version identifier defined by the device manufacturer, such as "HW-5G-IND-01" for the fifth-generation industrial-grade 5G communication module, where "IND" identifies the industrial application scenario. The firmware version sequence consists of the compilation timestamp and version number in the device firmware upgrade log, such as "FW-2.1.3_20231001" for the 2.1.3 version firmware released on October 1, 2023. The operator code combination is a set of authorization codes for the network access rights of the operator to which the device belongs, such as "CN-MOB-001" for China Mobile's eSIM contract code, and "CN-TEL-005" for China Telecom's Internet of Things dedicated access code. Through regular expression matching and field delimiter recognition, the cloud platform disassembles the original device identification feature string into three independent sub-feature sets, providing structured input for subsequent multi-level matching.

[0061] Step S220: traverse the first-level matching conditions in the hierarchical index table of the dynamic policy model library according to the hardware model code, filter out all candidate dynamic policy models containing the hardware model code, and form a first candidate model list.

[0062] Exemplarily, the hierarchical index table is a multi-level index table built based on a B+ tree structure, and its first-level node uses the hardware model code as the key value, and each key value is associated with a dynamic policy model linked list. For example, when the hardware model code is "HW-5G-IND-01", the index table traversal algorithm starts matching from the root node, locates the leaf node containing the code, and obtains the linked list header address it points to. The linked list stores all dynamic policy model metadata that support the hardware model, including the model identifier, the applicable firmware version range, and the operator whitelist. A prefix matching mechanism can be used during the traversal process to ensure that models with partial code matching can also be screened, such as "HW-5G-IND-01" and "HW-5G-IND-01A" share the same prefix branch. Finally, the first candidate model list contains 12 hardware-compatible dynamic policy models, such as models identified as "MODEL_5G_IND_V3" and "MODEL_5G_IND_LEGACY".

[0063] Step S230: performing second-level matching condition filtering on the first candidate model list based on the firmware version sequence, extracting models whose firmware adaptation range covers the firmware version sequence from the candidate dynamic policy models, and generating a second candidate model list.

[0064] Exemplarily, the firmware adaptation range is the firmware version compatibility interval defined in the dynamic policy model metadata, for example, "FW-2.0.0 to FW-2.2.0" indicates support for all firmware versions between 2.0.0 and 2.2.0. During the matching process, the firmware version sequence "FW-2.1.3_20231001" of the target device can be converted into the semantic version number "2.1.3" and the interval inclusion check can be performed with the adaptation range of the candidate model. For example, if the adaptation range of a model is "≥2.1.0 and <2.2.0", the target firmware version meets this condition and the model is retained in the second candidate model list. For the adaptation range defined by a timestamp (such as "20230901 to 20231130"), "20231001" in the firmware version sequence is extracted for time window matching. After the second level of filtering, the 12 models in the first candidate model list were reduced to 5. For example, "MODEL_5G_IND_V3" was retained because its adaptation range was "FW-2.1.0 to FW-2.3.0", and "MODEL_5G_IND_LEGACY" was eliminated because it only supported "FW-1.4.0 to FW-2.0.0".

[0065] Step S240: performing a third-level matching condition mapping on the second candidate model list according to the operator code combination, matching a target dynamic policy model in the operator whitelist associated with the candidate dynamic policy model that completely contains the operator code combination.

[0066] Exemplarily, the operator whitelist is a set of authorized operator codes predefined in the dynamic policy model metadata, for example, "{CN-MOB-001, CN-TEL-005}" indicates that the model is only applicable to devices bound to China Mobile and China Telecom. The matching algorithm verifies whether the operator code combination of the target device is a subset of the whitelist. For example, when the device code combination is "{CN-MOB-001, CN-TEL-005}" and the model whitelist is "{CN-MOB-001, CN-TEL-005,CN-UNI-007}", it is determined to be fully included. If the device code combination contains a code that is not authorized by the whitelist (such as "CN-GLB-010"), the model is excluded. During this process, the five models in the second candidate model list were further reduced to two. For example, “MODEL_5G_IND_V3” was retained because the whitelist included “CN-MOB-001” and “CN-TEL-005”, and “MODEL_5G_IND_HYBRID” was eliminated because the whitelist only included “CN-UNI-007”.

[0067] Step S250: If there are multiple target dynamic policy models after the third-level matching condition mapping, priority is sorted according to the difference between the activation timestamp in the device identification feature and the update timestamp of the target dynamic policy model, and the target dynamic policy model with the smallest difference is selected as the matching result.

[0068] Exemplarily, the activation timestamp is the time identifier when the device successfully accesses the cloud platform for the first time, such as "2023-10-0108:00:00". The update timestamp of the target dynamic policy model records the time of its most recent optimization iteration. For example, the update timestamp of "MODEL_5G_IND_V3" is "2023-09-15 14:30:00", and the update timestamp of "MODEL_5G_IND_V3B" is "2023-10-05 09:00:00". The absolute time difference between the activation timestamp and the update timestamp is calculated. For example, the time difference of "MODEL_5G_IND_V3" is 15 days and 6 hours, and the time difference of "MODEL_5G_IND_V3B" is 3 days and 23 hours. By sorting in ascending order, select "MODEL_5G_IND_V3B" with the smallest time difference as the final matching model to ensure that the device uses the latest optimized policy rules.

[0069] Step S260: If the target dynamic policy model does not exist after the third-level matching condition mapping, the hardware model code and firmware version sequence are input into the similarity evaluation engine of the dynamic policy model library, and the compatibility score with each candidate dynamic policy model is calculated. The dynamic policy model with a compatibility score exceeding a preset threshold is selected as an alternative matching result, and the unmatched operator code combination is recorded in the difference feature log for subsequent model incremental training.

[0070] Exemplarily, the similarity evaluation engine can adopt a multi-dimensional feature weighting algorithm, in which the compatibility weight of the hardware model code accounts for 60% and the compatibility weight of the firmware version sequence accounts for 40%. For example, when the similarity between the target hardware model code "HW-5G-IND-01" and the hardware code "HW-5G-IND-02" of the candidate model "MODEL_5G_IND_V2" is 85%, and the compatibility between the firmware version sequence "FW-2.1.3" and the model adaptation range "FW-2.0.0 to FW-2.2.0" is 90%, the overall compatibility score is 0.6×85+0.4×90=87 points. If the preset threshold is 80 points, the model is selected as an alternative matching result. The unmatched operator code combination "CN-GLB-010" is recorded in the difference feature log. The log structure contains device identification features, environmental feature sets, and configuration policy sequences, which are used to trigger subsequent model incremental training tasks. For example, in the next model training cycle, the operator code is included in the whitelist extension range.

[0071] Step S300: generating a configuration policy sequence for the target eSIM device based on the environment feature set and a matching dynamic policy model; the configuration policy sequence includes a plurality of candidate configuration parameter groups sorted by priority.

[0072] Exemplarily, the configuration strategy sequence refers to a parameter combination queue dynamically generated according to real-time environmental characteristics and strategy generation rules, and arranged in descending order of execution priority. Each candidate configuration parameter group contains a complete network access configuration, a frequency band selection strategy, and a signal strength tolerance threshold. The priority sorting algorithm comprehensively considers network connection stability, data transmission rate, and device energy consumption indicators. For example, the 5G independent networking configuration is placed above the 4G / Wi-Fi dual-mode configuration, or the priority of the low-frequency band configuration is automatically increased when the signal strength standard deviation exceeds the preset threshold. The dynamic strategy model analyzes the time-frequency characteristics of the signal strength distribution parameters through convolution operations, combines the geographic location coordinates to match the preset regional network coverage heat map, and finally generates a strategy sequence containing 3 candidate configuration parameter groups. For example, the first priority parameter group is configured to enable the 5G SA mode and lock the 3.5GHz frequency band with the strongest signal strength, the second priority parameter group is configured to enable 4G CA carrier aggregation and 2.4GHz Wi-Fi dual connection, and the third priority parameter group uses NB-IoT narrowband Internet of Things connection and enables the signal strength adaptive adjustment module. The generation of each parameter group strictly follows the preset rule constraints in the dynamic policy model, such as forcibly enabling the heartbeat packet interval optimization strategy when the network access mode is cellular single connection.

[0073] As an implementation manner, the step S300, based on the environment feature set and the matching dynamic policy model, generates a configuration policy sequence for the target eSIM device, which may specifically include the following steps: Step S310: Conditionally match the network access mode in the environmental feature set with the policy generation rules in the dynamic policy model, and filter out all valid rules whose network access mode threshold range covers the current network access type.

[0074] Exemplarily, the network access mode threshold range is a set of network types predefined in the dynamic policy model rule base, such as "5G NSA (non-standalone networking)", "4G CA (carrier aggregation)" and "3G / Wi-Fi dual-mode" as independent threshold intervals. When the current network access type of the target eSIM device is "5G NSA", the conditional branch matching algorithm traverses the network access mode field in the policy generation rule to filter out valid rules containing "5G NSA" or "5G NSA and 4G CA mixed mode". For example, a rule defines the network access mode threshold as "5G NSA or 4G CA", and the signal strength mean is ≥-75dBm, then the rule is marked as a valid rule. In this process, invalid rules such as those that only support "3G single mode" or "Wi-Fi priority" are automatically excluded to ensure that subsequent processing focuses only on policies that are compatible with the current network environment.

[0075] Step S320: based on the filtered effective rules, extract the signal strength adaptation conditions associated with the geographical location coordinates in the dynamic strategy model, and calculate the geographical location coverage overlap of each effective rule according to the signal strength distribution parameters in the environmental feature set.

[0076] Exemplarily, the signal strength adaptation condition associated with the geographic location coordinates refers to the longitude and latitude boundary range set in the rule and the corresponding signal strength constraint. For example, a rule stipulates that the signal strength mean must be ≥-70dBm and the standard deviation must be ≤10dB in the longitude [116.30°, 116.50°] and latitude [39.90°, 40.10°]. The geographic location coverage overlap is determined by calculating the ratio of the overlapping area between the current coordinates of the target device and the geographic fence in the rule. For example, when the device coordinates are located at [116.35°, 39.95°], the overlapping area with the rule geographic fence accounts for 92% of its total coverage area. At the same time, the mean and standard deviation of the signal strength distribution parameters are substituted into the signal strength constraint conditions in the rule for verification. If the current signal strength mean of the device is -68dBm and the standard deviation is 8dB, it is determined that the rule adaptation condition is met.

[0077] Step S330: pre-prioritize the valid rules whose geographic location coverage overlap reaches a preset overlap threshold and whose signal strength distribution parameters meet the adaptation conditions, and generate an initial candidate rule queue.

[0078] Exemplarily, the preset overlap threshold is dynamically adjusted according to the moving speed of the device. For example, the threshold for fixed devices is 80%, while the threshold for vehicle-mounted terminals is reduced to 60% to adapt to high-speed mobile scenarios. When the geographic location coverage overlap of a rule is 85% and the signal strength parameters are fully matched, the rule is added to the initial candidate rule queue. The pre-sorting algorithm requires descending order based on the signal strength mean of the rules, for example, giving priority to rules with higher signal strength thresholds to maximize connection stability. For example, if Rule A requires a signal strength of ≥-65dBm and Rule B requires ≥-70dBm, Rule A is ranked higher than Rule B in the queue, even though its geographic location coverage overlap is slightly lower.

[0079] Step S340: According to the historical rule execution success rate and energy efficiency index recorded in the dynamic policy model, weight optimization and adjustment are performed on the effective rules in the initial candidate rule queue to redetermine the priority order.

[0080] Exemplarily, the historical execution success rate of a rule refers to the percentage of times that the rule successfully completed configuration operations in the past 100 triggers, for example, the success rate of rule A is 95% and that of rule B is 88%. The energy efficiency index is calculated by the ratio of the average power consumption of the configuration parameter group associated with the rule in the historical execution to the benchmark power consumption, for example, the power consumption ratio of rule A is 110% and that of rule B is 98%. Weight optimization uses a multi-objective weighted algorithm, assigning a 60% weight to the execution success rate and a 40% weight to the energy efficiency, and re-sorting after calculating the comprehensive score. For example, the comprehensive score of rule A is 0.6×95+0.4×(100-110×0.5)=77 points, and that of rule B is 0.6×88+0.4×(100-98×0.5)=82.4 points, so the priority of rule B is raised to the top of the queue.

[0081] Step S350: Mapping the adjusted effective rules to corresponding candidate configuration parameter groups in order of priority, and removing redundant parameter items in the candidate configuration parameter groups that conflict with device identification features of the target eSIM device.

[0082] Exemplarily, the candidate configuration parameter groups are bound to the rules one by one. For example, rule B is mapped to the parameter group "5G NSA main frequency band 3.5GHz + 4G CA auxiliary frequency band 1.8GHz". Device identification feature conflict detection can be achieved by comparing the hardware compatibility list in the parameter group with the hardware model code of the target device. For example, if the parameter group requires support for "HW-5G-IND-02" and the target device is "HW-5G-IND-01", the "4G CA auxiliary frequency band 1.8GHz" configuration item in the parameter group is removed because it depends on a specific hardware filter module. After the redundant parameter items are removed, the remaining parameter groups are encapsulated as conflict-free standardized instruction templates.

[0083] Step S360: Dynamically calibrate the connection stability parameters in the candidate configuration parameter group according to the real-time fluctuation trend of the signal strength distribution parameters to form a configuration strategy sequence including calibrated parameters and priority tags.

[0084] For example, the real-time fluctuation trend of signal strength can be calculated by the sliding window algorithm to calculate the variance change rate of signal strength in the last 5 minutes. For example, the variance increases from 8dB² to 15dB², indicating that the signal stability decreases. The dynamic calibration module adjusts the heartbeat packet interval (shortened from 30 seconds to 20 seconds) and the switching decision threshold (increased from -75dBm to -70dBm) in the parameter group accordingly. The calibrated parameter group is accompanied by a priority label, such as "high stability first" or "low energy consumption first". The label assignment is based on the scene identifier in the device identification feature. Industrial equipment is marked as "high stability" and consumer electronics are marked as "low energy consumption".

[0085] Step S370: When a change in the network access mode or geographic location coordinates in the environmental feature set is detected, a local reordering of the configuration policy sequence is triggered, and a secondary verification of the signal strength adaptation condition of the candidate configuration parameter group is performed based on the changed environmental feature set.

[0086] For example, when the device switches from 5G NSA to 4G CA network access mode, the parameter group that depends on the 5G frequency band in the configuration policy sequence is downgraded, and a 4G CA-specific parameter group is added to the head of the queue. The change in geographic coordinates triggers a recalculation of the geo-fence overlap. If the device enters an area not covered by a rule, the associated parameter group is temporarily disabled. Secondary verification re-evaluates the applicability of the parameter group through real-time collected signal strength data. For example, after the signal mean drops to -72dBm, only the parameter group with a threshold ≤-72dBm is retained.

[0087] As an implementation manner, in step S300, generating a configuration policy sequence for the target eSIM device further includes: Step S301: monitor the network connection status of the target eSIM device in real time, and trigger dynamic adjustment of the configuration strategy sequence when it is detected that the network delay exceeds a preset delay threshold.

[0088] Exemplarily, the network delay threshold is set according to the device type, such as 50ms for industrial control equipment and 200ms for video surveillance equipment. The monitoring module continuously sends detection packets and calculates the round-trip time (RTT). When the average of three consecutive RTTs exceeds the threshold, a delay alarm event is generated. For example, the RTT of the vehicle terminal suddenly increases from 40ms to 80ms, triggering the dynamic adjustment process.

[0089] Step S302: Select a second priority candidate configuration parameter group from the configuration strategy sequence, and adjust the connection retry interval and data compression mode in the second priority candidate configuration parameter group based on the current network delay parameter.

[0090] Exemplarily, the second-priority candidate configuration parameter group is the parameter group ranked second in the sequence, for example, the parameter group with the original priority of "high stability" is replaced by the parameter group of "low latency". The connection retry interval is adjusted from the default 5 seconds to 2 seconds to speed up connection recovery, and the data compression mode is switched from lossless compression to lossy compression, reducing the amount of transmitted data by 30%.

[0091] Step S303: insert the adjusted second priority candidate configuration parameter group into the first position of the configuration policy sequence, and generate a new remote configuration instruction.

[0092] For example, the new remote configuration command overwrites the connection parameters in the original command, such as changing the APN (Access Point Name) from "industrial.apn" to "lowlatency.apn", and adding an emergency reconfiguration identifier to the command header. The cloud platform interface sends the command to the target device first to ensure that it seizes the current transmission channel.

[0093] Step S304: After the target eSIM device successfully executes the new remote configuration instruction, the adjusted second priority candidate configuration parameter group and its corresponding network delay parameter are recorded in the policy generation rule of the dynamic policy model.

[0094] For example, after successful execution, the configuration response data uploaded by the device includes new network delay indicators (such as RTT reduced to 45ms) and compression efficiency data. The dynamic policy model updates the rule base through an online learning mechanism, for example, adding a new "enable low-latency APN and lossy compression" branch under the condition of "network delay>50ms" and initializing its historical execution success rate to 100% for subsequent priority calls.

[0095] Step S400: Generate a remote configuration instruction according to the highest priority candidate configuration parameter group in the configuration policy sequence, and send the remote configuration instruction to the target eSIM device through the cloud platform interface.

[0096] Exemplarily, the remote configuration instruction is, for example, a binary data packet that complies with the GSMA remote SIM configuration specification, and its encapsulation process includes, for example, converting the network access parameters in the candidate configuration parameter group into an APN access point name, an authentication key, and a QoS service quality level identifier, and adding a specific instruction header check code according to the hardware version number of the target eSIM device. The cloud platform interface uses an asynchronous communication protocol to establish a two-way data channel with the target eSIM device, and sends the configuration instruction fragments to the device end through the HTTPS encrypted transport layer. During the instruction issuance process, the cloud platform monitors the network transmission delay and the data packet retransmission rate in real time, and automatically triggers the reordering mechanism of the configuration policy sequence when a significant change in the signal strength distribution parameter is detected. For example, during the instruction transmission stage, if the signal strength standard deviation of the target device suddenly increases by more than a threshold, the cloud platform will immediately terminate the current instruction issuance and re-execute step S300 to generate a new configuration policy sequence to ensure the real-time adaptability of the configuration instruction.

[0097] As an implementation manner, the step S400, generating a remote configuration instruction according to the highest priority candidate configuration parameter group in the configuration strategy sequence, may specifically include the following steps: Step S410: extracting network connection parameters, security authentication parameters and service subscription parameters in the highest priority candidate configuration parameter group, and verifying the compatibility of the network connection parameters with the hardware model code in the device identification feature of the target eSIM device.

[0098] Exemplarily, the network connection parameters are a set of network access configurations defined in the configuration policy, including APN (Access Point Name), QoS (Quality of Service) level, and band locking policy, such as APN "industrial.iot", QoS level "Priority 5", and locking the 3.5GHz band. Security authentication parameters include pre-shared key identifiers, certificate fingerprints, and two-way authentication protocol types, such as key identifier "KID_2023_V2" associated with AES-256 encryption algorithm and SHA-256 signature mechanism. Service subscription parameters define the cloud service endpoints and API permission lists accessible to the device, such as allowing access to "https: / / api.iotplatform.com / v1 / data" but prohibiting access to "https: / / api.otaupdate.com". Compatibility verification is achieved by comparing the hardware dependencies in the network connection parameters with the hardware model code of the target device. For example, the band locking policy requires the hardware to support the 3.5GHz band filter module, and the hardware specification document of the device model code "HW-5G-IND-01" explicitly includes this module, then the verification is determined to be passed.

[0099] Step S420: If the verification is successful, the security authentication parameters and the service subscription parameters are combined according to a preset instruction template structure to generate an initial configuration instruction draft; the instruction template structure includes a parameter type identifier, a parameter value placeholder and a check code generation bit.

[0100] Exemplarily, the instruction template structure is an XML structure that complies with the GSMA specification, wherein the parameter type identifier is used to distinguish network connection, security authentication, and service subscription parameter categories, such as " <networkconfig> ”" <securityauth> ”" <servicesub>" tag. The parameter value placeholder uses the "${}" format to mark the actual parameter value to be filled, for example, " <apn> ${apn_value}< / apn> "apn_value" in " corresponds to "industrial.iot". The checksum generation bit is reserved at the end of the instruction to store the CRC32 checksum calculated later. During the combination process, the key identifier "KID_2023_V2" in the security authentication parameter is filled in" <keyid> ${key_id}< / keyid> " placeholder, the API endpoint list in the service subscription parameter is serialized as " <allowurl> ${url_list}< / allowurl> " in JSON array format, forming an unencrypted initial configuration instruction draft.

[0101] Step S430: According to the transmission protocol type of the target eSIM device currently connected to the cloud platform interface, the initial configuration instruction draft is converted to a protocol adaptation mode, the protocol header field is filled, and the parameter value placeholder is replaced with the actual parameter value.

[0102] Exemplarily, the transmission protocol types include HTTPS, CoAP and MQTT. For example, when the device currently uses HTTPS long connection, the protocol adaptation module adds the HTTP header fields "Host: iot.config.com" and "Content-Type: application / xml" before the instruction draft. The parameter value placeholder replacement is completed through the key-value mapping mechanism, for example, "${apn_value}" is replaced with "industrial.iot", and "${url_list}" is replaced with "['https: / / api.iotplatform.com / v1 / data']". For binary protocols such as CoAP, the instruction draft needs to be converted into CBOR (Concise Binary Object Representation) format, and the Message ID and Token fields in the CoAP message header are added to ensure protocol compatibility.

[0103] Step S440: Based on the key identifier in the security authentication parameter, the corresponding encryption algorithm is called from the security repository of the cloud platform to perform end-to-end encryption on the initial configuration instruction draft after protocol adaptation to generate an encrypted configuration instruction data packet.

[0104] Exemplarily, the secure repository uses a hardware security module (HSM) to manage key materials. When the key identifier "KID_2023_V2" is passed in, the HSM returns the corresponding AES-256-GCM encryption key and initialization vector. The encryption process divides the plaintext instruction draft into 128-byte data blocks, performs encryption operations in sequence and attaches authentication tags to generate an encrypted configuration instruction data packet in binary format. The data packet structure follows the ISO / IEC 7816-4 specification and contains the encryption algorithm identifier "0x01" representing AES-256-GCM, the ciphertext data segment, and a 16-byte integrity check tag.

[0105] Step S450: Determine the fragmentation strategy and transmission priority tag of the encrypted configuration instruction data packet according to the bandwidth limitation and signal strength distribution parameters in the network connection parameters; the fragmentation strategy includes the upper limit of the fragment size and the number of retransmitted redundant fragments.

[0106] For example, the bandwidth limit is determined by the network access mode of the target device. For example, when the 4G network bandwidth is 50Mbps, the upper limit of the fragment size is set to 1024 bytes to avoid single-fragment transmission timeout; if the signal strength distribution parameter shows a standard deviation of 12dB (high volatility), the number of retransmitted redundant fragments is increased from the default 1 to 3 to improve transmission reliability. The transmission priority mark is set according to the urgency of the configuration policy. For example, when the device is in roaming state, it is marked as "high priority", triggering the priority queue scheduling mechanism of the cloud platform interface.

[0107] Step S460: Inject the fragmentation strategy and transmission priority tag into the metadata segment of the encrypted configuration instruction data packet to generate a complete remote configuration instruction.

[0108] Exemplarily, the metadata segment is attached to the encrypted data packet header in TLV (type-length-value) format, for example, the fragmentation strategy is encoded as type code "0x1F", length "0x04", value "0400" (indicating a fragment size of 1024 bytes) and "0301" (indicating the number of redundant fragments 3). The transmission priority tag is encoded as type code "0x2A", length "0x01", value "0x01" (high priority). After the injection is completed, the length of the complete instruction packet is extended to the sum of the encrypted data segment and the metadata segment, and the structural integrity is verified by the status check module of the cloud platform interface.

[0109] Step S470: If the verification fails, a replacement mechanism for the second priority candidate configuration parameter group in the configuration policy sequence is triggered, and invalid network connection parameters in the highest priority candidate configuration parameter group are recorded in the policy generation rule exception list of the dynamic policy model.

[0110] For example, when the band lock policy in the highest priority parameter group requires the 4.9GHz band and the hardware with the device model code "HW-5G-IND-01" does not support it, the system automatically selects the second priority parameter group (such as the 3.5GHz band policy) and re-executes steps S410 to S460. The invalid parameter "4.9GHz band lock" is recorded in the exception list, and the list entry contains the device identification feature, the environmental feature set, and the failure reason code "ERR_HW_INCOMPATIBLE". In the subsequent model incremental training cycle, the conflict relationship between this parameter and the device model code is added to the exclusion condition of the policy generation rule.

[0111] Step S500: receiving configuration response data returned by the target eSIM device, and updating the policy generation rule of the dynamic policy model associated with the device identification feature in the dynamic policy model library according to the configuration response data.

[0112] Exemplarily, the configuration response data includes, for example, the execution result code of the remote configuration instruction of the target eSIM device, the identifier of the configuration parameter group that is actually in effect, and the network performance indicators measured on the device side, such as data transmission rate, signal strength steady-state value, and power consumption level. The cloud platform analyzes the deviation between the preset configuration parameter group and the actual effective parameter group through a difference comparison algorithm. When it is detected that multiple devices with similar geographical coordinates all fail to execute the same configuration parameter group, the weight adjustment mechanism of the policy generation rule is automatically triggered. For example, the specific update process may include: strengthening the decision weight of the standard deviation factor in the signal strength distribution parameter, adding a network switching success rate penalty term to the loss function of the dynamic policy model, and performing online iterative optimization of the configuration policy generation rule based on the reinforcement learning algorithm. For example, if a certain model of vehicle-mounted terminal frequently experiences 5G configuration connection timeouts in a highway scenario, the dynamic policy model will automatically add a speed threshold condition to the policy generation rule, and when the device moves at a speed exceeding 120km / h, it will be forced to downgrade to the 4G CA configuration parameter group, and the rule will be synchronized to the dynamic policy models of all associated device types in the model library.

[0113] As an implementation manner, in step S500, updating the dynamic policy model library according to the configuration response data may specifically include the following steps: Step S510: parsing the actual configuration parameter execution results and device status indicators in the configuration response data.

[0114] Exemplarily, the actual configuration parameter execution result refers to the operation status code and effective parameter list returned by the target eSIM device after executing the remote configuration command. For example, the status code "0x00" indicates that the APN (Access Point Name) and band lock strategy have been successfully applied, while the status code "0xE1" indicates that the security authentication parameter verification has failed. The device status indicator includes real-time network performance data after the configuration takes effect, such as the network delay is reduced from 120ms to 45ms, the signal strength average is stable at -68dBm and the standard deviation is 7dB. The parsing process separates data fields through regular expression matching and JSON deserialization technology, for example, extracting key-value pairs such as "APN=industrial.iot" and "QoS=5" from the response data, and converting the network delay indicator "latency=45" into a floating-point value and storing it in the analysis queue.

[0115] Step S520: comparing the actual configuration parameter execution result with the highest priority candidate configuration parameter group in the configuration strategy sequence to determine the parameter deviation type and deviation amplitude.

[0116] Exemplarily, the difference comparison algorithm adopts a field-by-field comparison mechanism. For example, if the APN defined in the highest priority parameter group is "industrial.iot", and the actual effective APN is "backup.iot", it is determined to be "APN parameter deviation"; if the expected mean signal strength is -65dBm and the actual value is -68dBm, the calculated deviation amplitude is 3dB. Parameter deviation types are divided into compatible deviation and incompatible deviation. The former means that the difference in parameter values ​​does not affect the core function (such as the QoS level is adjusted from 5 to 4), and the latter means that the missing or out-of-bounds parameters lead to functional abnormalities (such as the frequency band locking strategy is not effective).

[0117] Step S530: If the parameter deviation type is a compatible deviation and the deviation amplitude is within a preset tolerance range, the policy generation rule of the dynamic policy model is kept unchanged, and the actual configuration parameter execution result is recorded as supplementary training data.

[0118] Exemplarily, the preset tolerance range is dynamically set according to the parameter type, such as the signal strength mean tolerance of ±5dB and the network delay tolerance of ±20ms. When the APN deviation is a compatible backup access point of the same operator and the signal strength deviation is 2dB, the dynamic policy model rule base maintains the original conditional branch, and adds the actual parameter value "APN=backup.iot" "signal_mean=-68dB" as a new sample to the training data set. The supplementary training data is stored in the unstructured database of the cloud platform, and its associated device identification features and environmental feature sets are marked through data version control.

[0119] Step S540: If the parameter deviation type is an incompatible deviation or the deviation amplitude exceeds the preset tolerance range, the environmental feature set and device identification features are extracted, and the incremental training of the dynamic policy model is started; wherein the incremental training includes: using the environmental feature set, device identification features and actual configuration parameter execution results as new sample data, recalculating the conditional branch weights in the policy generation rules, and updating the split point threshold of the policy decision tree model.

[0120] For example, when the frequency band lock strategy causes the actual effective frequency band to deviate from the expected frequency band by more than 10MHz due to hardware incompatibility, the incremental training module loads the device identification feature "HW-5G-IND-01" and the environmental feature set "5G NSA mode + urban center area" as input to re-evaluate the conditional weights of the frequency band selection rules in the strategy decision tree. The segmentation point threshold adjustment uses a gradient descent algorithm, for example, optimizing the signal strength mean threshold from -70dBm to -68dBm to match the actual effective condition.

[0121] As an implementation method, the above incremental training may further include the following steps: Step S541: extracting the change trend of the network access mode and the movement trajectory of the geographic location coordinates from the newly added sample data.

[0122] Exemplarily, the trend of network access mode changes is calculated by sliding window statistics of the device's network type switching frequency in the last 24 hours. For example, the average interval for switching from 5G NSA to 4G CA is 15 minutes. The geographic location coordinate movement trajectory uses the Kalman filter algorithm to smooth the original coordinate sequence to generate the longitude and latitude change rate and direction angle. For example, the device moves at a speed of 60km / h along the longitude 116.30° to 116.45°. The trajectory data is encoded in GeoJSON format and associated with a timestamp sequence for spatiotemporal feature analysis.

[0123] Step S542: predicting expected environmental characteristics of the target eSIM device in a future time window according to the change trend and the movement trajectory.

[0124] Exemplarily, the length of the future time window is adaptively adjusted according to the mobile rate, for example, it is set to 5 minutes for high-speed mobile devices and 1 hour for fixed devices. The expected environmental characteristics are predicted using the ARIMA (Autoregressive Integrated Moving Average) model, for example, it is predicted that the device will enter an area with a signal strength mean of -72dBm and a network access mode switched to 4G CA in 5 minutes. The expected coordinates of the geographic location are calculated by linear extrapolation. For example, if the current longitude of 116.40° increases at a rate of 0.002° / min, the expected longitude in 5 minutes is 116.40° + (0.002×5)=116.41°.

[0125] Step S543: adding a temporary decision path in the policy decision tree model, wherein the temporary decision path maps the expected environmental characteristics to a preset preliminary configuration parameter group.

[0126] Exemplarily, the temporary decision path is identified with the "expected_" prefix, for example, the newly added path "expected_4G_CA_116.41°" is associated with the preliminary configuration parameter group "Enable 4G CA carrier aggregation and 2.4GHz Wi-Fi dual connection". The path condition is set to "IF network access mode = 4G CA AND longitude ≥ 116.40° AND longitude ≤ 116.42° THEN execute the preliminary parameter group". The validity period of the temporary path is set to the length of the future time window, and it is automatically marked as a pending recovery state after timeout.

[0127] Step S544: when it is detected that the matching degree between the environmental characteristics of the target eSIM device and the expected environmental characteristics exceeds a preset matching threshold, the remote configuration instruction corresponding to the preliminary configuration parameter group is preferentially executed.

[0128] Exemplarily, the matching degree calculation adopts the cosine similarity algorithm. For example, if the similarity between the actual environment feature vector and the expected vector is 0.92 (threshold 0.85), the provisioning parameter group is triggered to be sent. The provisioning configuration parameter group is preemptively sent through the cloud platform interface. For example, when the device enters the 116.41° longitude area 300 meters before, the 4G CA configuration is activated in advance to avoid signal switching delay.

[0129] Step S545: After the future time window ends, if the preliminary configuration parameter group is not triggered for execution, the temporary decision path is removed from the policy decision tree model.

[0130] Exemplarily, the removal mechanism can be implemented through a timer and a status flag. For example, after the end timestamp of the future time window arrives, the system scans all "expected_" prefix paths. If the "triggered" flag is false, the path is deleted and the associated memory resources are released. The removal operation also clears the instruction cache of the prepared parameter group to ensure that the policy decision tree model maintains the optimal decision efficiency.

[0131] As an implementation mode, the method further includes a process of abnormal configuration processing, specifically including: Step S600: After the remote configuration instruction is issued, the configuration execution countdown is started.

[0132] Exemplarily, the configuration execution countdown is a timeout monitoring window that is dynamically set based on the network connection quality of the target eSIM device. For example, when the network delay is 50ms, the countdown duration is set to 30 seconds, and when the delay increases to 150ms, it is extended to 90 seconds. The countdown trigger mechanism is implemented through the task scheduler of the cloud platform, and its internal clock accuracy is in milliseconds, ensuring that the subsequent exception handling process is accurately triggered when the configuration response data is not received within the preset time window. For example, when the remote configuration instruction includes a frequency band locking strategy and security authentication parameters, the countdown window is adjusted to 45 seconds according to the complexity of the instruction, reserving sufficient time for the device to complete RF calibration and key negotiation.

[0133] Step S700: If no configuration response data is received before the countdown ends, a configuration status query request is sent to the target eSIM device.

[0134] Exemplarily, the configuration status query request adopts a dual composite transmission mechanism, where the main request is sent through the currently active cloud platform interface (such as HTTPS long connection), and the backup request is switched to the low-power wide area network protocol (such as NB-IoT) for redundant transmission. The request message structure contains the instruction sequence number, the device identification feature hash value and the query type identifier. For example, the query type identifier "0x03" indicates that the device is required to return the execution status code of the configuration instruction and the error details of the unfinished operation. After receiving the query request, the device side interrupts the ongoing data transmission task, responds to the status query first and returns a response data packet containing a snapshot of the current configuration process.

[0135] Step S800: Determine the exception type according to the feedback result of the configuration status query request. The exception type determination module parses the status code and error log in the response data packet and maps them to a predefined exception classification tree.

[0136] For example, the status code "0xE2" corresponds to "security certificate chain verification failure", which is classified as a security authentication exception; the status code "0xD4" corresponds to "frequency band resources are unavailable", which is classified as a hardware compatibility exception. The stack trace information in the error log further assists in refining the exception subclasses. For example, in the case of frequency band resources being unavailable, the two subtypes of "hardware filter failure" and "spectrum authorization expiration" are distinguished, providing accurate input for subsequent processing.

[0137] Step S900: If the feedback result is that the configuration instruction has not arrived, switch the data transmission channel of the cloud platform interface and re-issue the remote configuration instruction.

[0138] Exemplarily, the data transmission channel switching strategy is dynamically selected based on the network access mode and signal strength distribution parameters of the target device, such as switching from the default HTTPS channel to the MQTT over TCP protocol to bypass firewall restrictions, or enabling the fast retransmission mode of the UDP protocol to improve the command arrival rate. The re-issued remote configuration command is attached with a transmission priority tag and a fragment redundancy check code, for example, a transmission strategy with a fragment size of 512 bytes and a redundant fragment number of 2 is used in the NB-IoT channel to ensure command integrity in a high packet loss environment.

[0139] Step S1000: If the feedback result is that the configuration instruction has been received but the execution fails, then the next priority candidate configuration parameter group is selected from the configuration strategy sequence, and a debugging instruction is attached to regenerate the remote configuration instruction.

[0140] Exemplarily, the next priority candidate configuration parameter group is the alternative solution second only to the highest priority in the current sequence. For example, when the highest priority parameter group fails due to a frequency band conflict, the second priority parameter group enables the alternative frequency band 3.5GHz and a simplified security authentication process. The debugging instructions include enabling the device-side log tracking function, increasing the diagnostic information reporting frequency to once per second, and setting the debugging level to "VERBOSE" to capture underlying driver errors. The regenerated instructions are adapted to the current transmission channel through the protocol conversion module, such as embedding Base64-encoded debugging parameters into the message option field in the CoAP protocol.

[0141] Step S1100: Record the exception type and handling measures in the exception handling knowledge base of the dynamic policy model, and give priority to avoiding the configuration parameter combination that causes the exception in the subsequent policy generation process.

[0142] Exemplarily, the exception handling knowledge base uses a graph database to store the association between exception events and handling measures, such as the node "security certificate chain verification failed" and the edge "switch to secondary CA certificate" and "enable offline signature verification". After the knowledge base is updated, the dynamic policy model calls the graph traversal algorithm when generating the configuration policy sequence, and actively excludes the configuration parameter combinations that have caused similar exceptions in the past. For example, when it is detected that the device identification feature contains "HW-5G-IND-01", the parameter group that depends on the 4.9GHz frequency band is automatically skipped.

[0143] As an implementation manner, the updating process of the exception handling knowledge base may include the following steps: Step S1110: Count the frequency of multiple triggering of the same abnormal type under the same device identification feature.

[0144] Exemplarily, frequency statistics can use a sliding time window counting method, for example, counting the number of times the device identification feature "HW-5G-IND-01_89860121" triggers the "frequency band resource unavailable" anomaly in the past 24 hours. The counting results are stored in the time series database, and the anomaly triggering rate is calculated using an exponentially weighted moving average algorithm. For example, if the number of anomalies exceeds 3 times per hour, it is determined to be a high-frequency anomaly source. In the statistical process, the environmental feature set is associated with the configuration parameter group identifier to establish a multi-dimensional anomaly feature portrait.

[0145] Step S1120: If the frequency exceeds a preset frequency threshold, the associated configuration parameter group in the dynamic policy model is marked, and the priority of the marked configuration parameter group is reduced when generating a configuration policy sequence.

[0146] For example, the preset frequency threshold can be set according to the device type, such as 2 times per hour for industrial-grade devices and 5 times per hour for consumer-grade devices. The marking operation adds a "risk tag" identifier to the metadata area of ​​the dynamic policy model and multiplies the initial priority weight of the associated parameter group by a degradation factor of 0.7. For example, a parameter group with an original priority of 90 points is reduced to 63 points after marking, causing its ranking position to move backward when the policy is generated.

[0147] Step S1130: When the priority of the marked configuration parameter group is lower than a preset priority threshold, it is removed from the configuration policy sequence and emergency retraining of the dynamic policy model is triggered; wherein the emergency retraining includes: filtering configuration parameter groups that are not related to the current abnormality type from historical configuration data, and reconstructing the policy generation rule set based on the filtering results.

[0148] For example, the preset priority threshold is set to 50 points. When the priority of a parameter group drops to 49 points, the system automatically removes it from the configuration policy sequence of the current device. The emergency retraining module loads historical configuration data that has not triggered similar anomalies in the past 30 days, uses the random forest algorithm to recalculate the conditional branch weights of the policy generation rules, and removes decision paths that are strongly associated with abnormal parameter groups through pruning operations, such as deleting the rule "IF network access mode = 5G AND frequency band = 4.9GHz THEN enable high power mode".

[0149] As an implementation mode, the method further includes a process of cross-model transfer learning, which may specifically include the following steps: Step S1200: when it is detected that the device identification feature of the newly added eSIM device is not matched to any dynamic policy model, a reference dynamic policy model with the highest device identification feature similarity is selected from the dynamic policy model library.

[0150] Exemplarily, the similarity calculation adopts a hybrid feature weighted algorithm, with the hardware model code similarity weight accounting for 60%, the firmware version sequence similarity accounting for 30%, and the operator code combination similarity accounting for 10%. For example, the hardware code edit distance between the newly added device identification feature "HW-5G-IND-02_89860122" and the reference model "MODEL_5G_IND_V3" is 1 (similarity 95%), the firmware version difference is the minor version number (similarity 85%), and the operator code overlap is 80%. The comprehensive similarity score is 0.6×95+0.3×85+0.1×80=90.5 points, becoming the best reference model.

[0151] Step S1300: extracting the policy generation rule set of the reference dynamic policy model, and removing rule conditions therein that are strongly associated with device identification features.

[0152] Exemplarily, a strongly associated rule condition refers to a decision branch that directly references a specific hardware model or operator code, such as "IF hardware model code = HW-5G-IND-01 THEN enable proprietary RF calibration" is identified as a device-specific rule. The removal operation parses the rule expression through a syntax analyzer, deletes the logical judgment containing the device identification feature field, and retains the general environment feature conditions such as "Signal strength average ≥ -70dBm" and "Network access mode = 5G NSA".

[0153] Step S1400: The removed policy generation rule set is used as the initial rule set, and the real-time configuration request data of the newly added eSIM device is loaded for rule filling; wherein, the rule filling includes: dynamically adding adaptive threshold conditions of network access mode and signal strength according to the environmental feature set of the newly added eSIM device, and associating the general configuration parameter group.

[0154] Exemplarily, after feature extraction, the environmental feature set in the real-time configuration request data drives the rule generation engine to create a new conditional branch. For example, if it is detected that the signal strength standard deviation of the newly added device is stable within 5dB in 4G CA mode, then add the rule "IF network access mode = 4G CA AND signal strength standard deviation ≤ 6dB THEN enable CA carrier aggregation optimization configuration". The general configuration parameter group is selected from the public pool of the model library, such as "low power basic configuration" and "high throughput default configuration".

[0155] Step S1500: Encapsulate the populated policy generation rule set as a newly added dynamic policy model, and add it to the dynamic policy model library.

[0156] Exemplarily, the packaging process includes assigning a unique model identifier "MODEL_5G_IND_V4" to the rule set, generating version metadata (such as the creation timestamp "20231001T143000" and the applicable device feature range "HW-5G-IND-02 series"), and compiling the rule set into the executable code of the policy decision tree. After the newly added model passes the consistency verification test, it is registered in the index directory of the dynamic policy model library, and subsequent configuration requests can directly call the model through the device identification feature mapping.

[0157] Please refer to Figure 3 , is a structural block diagram of the cloud platform 120 of the present invention, and the cloud platform 120 includes a computing unit 1001, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 1002 or a computer program loaded from a storage unit 1008 to a random access memory (RAM) 1003. In the RAM 1003, various programs and data required for the operation of the cloud platform 120 can also be stored. The computing unit 1001, the ROM 1002, and the RAM 1003 are connected to each other via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0158] Multiple components in the cloud platform 120 are connected to the I / O interface 1005, including: an input unit 1006, an output unit 1007, a storage unit 1008, and a communication unit 1009. The input unit 1006 can be any type of device that can input information to the cloud platform 120. The input unit 1006 can receive input digital or character information, and generate key signal input related to the user settings and / or function control of the server, and can include but is not limited to a mouse, a keyboard, a touch screen, a trackpad, a trackball, a joystick, a microphone, and / or a remote control. The output unit 1007 can be any type of device that can present information, and can include but is not limited to a display, a speaker, a video / audio output terminal, a vibrator, and / or a printer. The storage unit 1008 can include but is not limited to a disk and an optical disk. The communication unit 1009 allows the cloud platform 120 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks, and may include but is not limited to a modem, a network card, an infrared communication device, a wireless communication transceiver and / or a chipset, such as a Bluetooth™ device, an 802.11 device, a WiFi device, a WiMax device, a cellular communication device and / or the like.

[0159] The computing unit 1001 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 1001 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 1001 performs the various methods and processes described above, such as a cloud-based eSIM remote configuration management method. For example, in some embodiments, the cloud-based eSIM remote configuration management method may be implemented as a computer software program, which is tangibly included in a machine-readable medium, such as a storage unit 1008. In some embodiments, part or all of the computer program may be loaded and / or installed on the cloud platform 120 via the ROM 1002 and / or the communication unit 1009. When the computer program is loaded into the RAM 1003 and executed by the computing unit 1001, one or more steps of the cloud-based eSIM remote configuration management method described above may be performed. Alternatively, in other embodiments, the computing unit 1001 may be configured to execute the cloud platform-based eSIM remote configuration management method in any other appropriate manner (for example, by means of firmware).

[0160] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0161] The program code for implementing the method of the present invention can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer or other programmable data processing device, so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code can be executed entirely on the machine, partially on the machine, partially on the machine as a stand-alone software package and partially on a remote machine, or entirely on a remote machine or server.

[0162] In the context of the present invention, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0163] In summary, the present invention provides a cloud platform, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method provided in the above embodiments of the present invention.

[0164] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be performed in parallel, sequentially or in different orders, as long as the desired results of the technical solution disclosed in the present invention can be achieved, and this document is not limited here.

[0165] Although the embodiments or examples of the present invention have been described with reference to the accompanying drawings, it should be understood that the above-mentioned methods, systems and devices are merely exemplary embodiments or examples, and the scope of the present invention is not limited by these embodiments or examples, but is limited only by the claims after authorization and their equivalent scope. Various elements in the embodiments or examples can be omitted or replaced by their equivalent elements. In addition, each step can be performed in an order different from that described in the present invention. Further, the various elements in the embodiments or examples can be combined in various ways. It is important that with the evolution of technology, many elements described herein can be replaced by equivalent elements that appear after the present invention.< / servicesub> < / securityauth> < / networkconfig>

Claims

1. A cloud platform-based eSIM remote configuration management method, characterized in that: The method comprises: Obtaining a real-time configuration request of a target eSIM device, and extracting an environmental feature set and a device identification feature in the real-time configuration request; the environmental feature set includes a network access mode, a geographic location coordinate, and a signal strength distribution parameter; Matching a corresponding dynamic policy model from a pre-built dynamic policy model library according to the device identification feature; the dynamic policy model is generated by training historical configuration data, and each dynamic policy model is associated with at least one set of configuration policy generation rules; Based on the environmental feature set and the matching dynamic policy model, generating a configuration policy sequence for the target eSIM device; the configuration policy sequence includes a plurality of candidate configuration parameter groups sorted by priority; Generate a remote configuration instruction according to the highest priority candidate configuration parameter group in the configuration policy sequence, and send the remote configuration instruction to the target eSIM device through the cloud platform interface; Receive configuration response data returned by the target eSIM device, and update the policy generation rule of the dynamic policy model associated with the device identification feature in the dynamic policy model library according to the configuration response data.

2. The method according to claim 1, characterized in that The generation process of the dynamic strategy model library includes the following steps: Acquire a configuration operation data set of multiple historical eSIM devices; the configuration operation data set includes an environmental feature record, a configuration parameter execution record, and a configuration result evaluation index for each historical eSIM device; Extracting a device identification feature of each historical eSIM device from the configuration operation data set, and grouping the configuration operation data set based on the device identification feature to obtain sub-data sets corresponding to multiple device feature groups; For each sub-dataset corresponding to the device feature group, perform the following processing: According to the environmental feature records and configuration parameter execution records in the sub-dataset, an initial policy generation rule set is constructed; the initial policy generation rule set includes a plurality of conditional branches, each conditional branch corresponds to a set of environmental feature threshold ranges and an associated configuration parameter group; The initial policy generation rule set is optimized using the configuration result evaluation index in the sub-data set to generate a dynamic policy model corresponding to the device feature group; wherein the optimization process includes merging redundant conditional branches, adjusting the environmental feature threshold range, and updating the priority of the configuration parameter group; The optimized dynamic policy model is stored in the dynamic policy model library, and a mapping relationship between the dynamic policy model and the device identification feature of the corresponding device feature group is established.

3. The method according to claim 2, characterized in that The optimizing the initial strategy generation rule set by using the configuration result evaluation index in the sub-data set includes: Extracting configuration success rate, signal stability gain and energy consumption change rate from the configuration result evaluation indicators of the sub-dataset; For each conditional branch in the initial strategy generation rule set, the following operations are performed: Calculating a weighted score of a configuration success rate and a signal stability gain of a historical configuration parameter group corresponding to the conditional branch; If the weighted score is lower than the preset score threshold, the conditional branch is deleted, and the environmental feature threshold range covered by the conditional branch is merged into the adjacent conditional branch; If the weighted score is higher than or equal to the preset score threshold but the energy consumption change rate exceeds the preset energy consumption threshold, the power consumption control parameter in the configuration parameter group associated with the conditional branch is adjusted, and the configuration result evaluation index is recalculated; Generate an updated policy generation rule set according to the adjusted conditional branch, and input the updated policy generation rule set into the policy decision tree model for rule conflict detection; If a rule conflict is detected, the conflicting conditional branches are re-prioritized until no conflicting paths exist in the policy decision tree model.

4. The method according to claim 3, characterized in that: in, The construction process of the strategy decision tree model includes the following steps: Extracting environmental feature threshold ranges and associated configuration parameter groups of all conditional branches from the updated policy generation rule set; Taking the network access mode as the root node, a multi-layer decision node is constructed in the order of geographic location coordinates and signal strength distribution parameters; Set the corresponding environmental feature threshold segmentation point at each decision node, and direct the path that meets the segmentation point condition to the next layer of decision nodes or leaf nodes; Associating the corresponding configuration parameter groups at the leaf nodes, and setting the execution order of the leaf nodes based on the priority of the configuration parameter groups; Prune the constructed initial strategy decision tree, delete redundant paths that do not cover any historical environmental feature records, and use the pruned strategy decision tree as the core decision structure of the dynamic strategy model; The generating of the configuration strategy sequence of the target eSIM device further includes: Monitor the network connection status of the target eSIM device in real time, and trigger dynamic adjustment of the configuration strategy sequence when it is detected that the network delay exceeds a preset delay threshold; Selecting a second-priority candidate configuration parameter group from the configuration strategy sequence, and adjusting a connection retry interval and a data compression mode in the second-priority candidate configuration parameter group based on a current network delay parameter; Insert the adjusted second priority candidate configuration parameter group into the first position of the configuration policy sequence and generate a new remote configuration instruction; After the target eSIM device successfully executes the new remote configuration instruction, the adjusted second priority candidate configuration parameter group and its corresponding network delay parameter are recorded in the policy generation rule of the dynamic policy model.

5. The method according to claim 1, characterized in that The updating of the dynamic strategy model library according to the configuration response data comprises: Parsing actual configuration parameter execution results and device status indicators in the configuration response data; Compare the actual configuration parameter execution result with the highest priority candidate configuration parameter group in the configuration strategy sequence to determine the parameter deviation type and deviation amplitude; If the parameter deviation type is a compatible deviation and the deviation amplitude is within a preset tolerance range, the policy generation rule of the dynamic policy model is kept unchanged, and the actual configuration parameter execution result is recorded as supplementary training data; If the parameter deviation type is an incompatible deviation or the deviation amplitude exceeds a preset tolerance range, extracting the environmental feature set and the device identification feature, and starting incremental training of the dynamic strategy model; The incremental training includes: using the environmental feature set, device identification features and actual configuration parameter execution results as new sample data, recalculating the conditional branch weights in the policy generation rules, and updating the segmentation point threshold of the policy decision tree model.

6. The method according to claim 5, characterized in that The incremental training also includes: Extract the changing trend of network access mode and the movement trajectory of geographic location coordinates from the newly added sample data; Predicting expected environmental characteristics of the target eSIM device in a future time window based on the change trend and movement trajectory; Adding a temporary decision path in the strategy decision tree model, wherein the temporary decision path maps the expected environmental characteristics to a preset preliminary configuration parameter group; When it is detected that the matching degree between the environmental characteristics of the target eSIM device and the expected environmental characteristics exceeds a preset matching threshold, the remote configuration instruction corresponding to the preliminary configuration parameter group is preferentially executed; After the future time window ends, if the preliminary configuration parameter group is not triggered for execution, the temporary decision path is removed from the policy decision tree model.

7. The method according to claim 1, characterized in that The method also includes a process of abnormal configuration processing, including: After the remote configuration command is issued, the configuration execution countdown is started; If no configuration response data is received before the countdown ends, a configuration status query request is sent to the target eSIM device; Determine the exception type based on the feedback result of the configuration status query request: If the feedback result is that the configuration command has not arrived, switch the data transmission channel of the cloud platform interface and resend the remote configuration command; If the feedback result is that the configuration instruction has been received but the execution fails, the next priority candidate configuration parameter group is selected from the configuration strategy sequence, and the debugging instruction is attached to regenerate the remote configuration instruction; The exception types and handling measures are recorded in the exception handling knowledge base of the dynamic policy model, and in the subsequent policy generation process, the configuration parameter combinations that cause exceptions are avoided first.

8. The method according to claim 7, characterized in that The updating process of the exception handling knowledge base includes: Count the frequency of multiple triggering of the same exception type under the same device identification feature; If the frequency exceeds a preset frequency threshold, marking the associated configuration parameter group in the dynamic policy model, and reducing the priority of the marked configuration parameter group when generating the configuration policy sequence; When the priority of the marked configuration parameter group is lower than the preset priority threshold, it is removed from the configuration strategy sequence and the emergency retraining of the dynamic strategy model is triggered; The emergency retraining includes: screening configuration parameter groups irrelevant to the current abnormality type from historical configuration data, and reconstructing a strategy generation rule set based on the screening result.

9. The method according to claim 1, characterized in that: The method also includes a process of cross-model transfer learning, including: When it is detected that the device identification feature of the newly added eSIM device does not match any dynamic policy model, a reference dynamic policy model with the highest device identification feature similarity is selected from the dynamic policy model library; Extracting the policy generation rule set of the reference dynamic policy model, and removing the rule conditions therein that are strongly associated with the device identification feature; The removed policy generation rule set is used as the initial rule set, and the real-time configuration request data of the newly added eSIM device is loaded for rule filling; The rule filling includes: dynamically adding adaptive threshold conditions of network access mode and signal strength according to the environmental feature set of the newly added eSIM device, and associating the general configuration parameter group; The populated policy generation rule set is encapsulated as a new dynamic policy model and added to the dynamic policy model library.

10. A cloud platform, characterized in that: include: at least one processor; and a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method described in any one of claims 1 to 9.

Images