An eSIM remote configuration management method based on a cloud platform and the cloud platform

Abstract

The present invention provides an eSIM remote configuration management method and a cloud platform based on the cloud platform. Among them, the method includes: obtaining a real-time configuration request of a target eSIM device, and extracting an environment feature set and a device identification feature from the real-time configuration request; matching a corresponding dynamic policy model from a pre-constructed dynamic policy model library according to the device identification feature; generating a configuration policy sequence of the target eSIM device based on the environment feature set and the matched dynamic policy model; generating a remote configuration instruction according to the highest-priority candidate configuration parameter group in the configuration policy sequence, and sending the remote configuration instruction to the target eSIM device through a cloud platform interface; 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. The present invention can improve the automation, adaptability and stability of the remote configuration management of eSIM devices.

Description

Technical Field

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

[0002] Currently, with the popularization of eSIM technology, remote configuration management has become the core link for operators and device manufacturers to achieve large-scale device deployment. In related technologies, configuration policies 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 pre-set static rule library, and a fixed set of configuration parameters is directly called and sent to the target device; for another example, according to the real-time signal strength threshold, it is judged whether to trigger the configuration instruction of the high-power consumption mode. However, the above methods have significant defects when dealing with complex and changeable network environments and a large number of heterogeneous devices: the static rule library cannot dynamically adapt to the upgrade of the device firmware version or the adjustment of operator policies, resulting in mismatches between the configuration parameters and the actual compatibility of the device, causing configuration failures or functional abnormalities; the single signal strength threshold decision ignores the combined effects of geographical location differences (such as urban base station dense areas and remote areas) and network access mode switching (such as seamless switching between 5G / Wi-Fi), resulting in a disconnection between the configuration policy and the actual network conditions, causing resource waste or a decline in connection stability. In addition, the fixed design of the encryption transmission and sharding strategy in the traditional solution is difficult to balance the instruction integrity in low-signal areas and the data protection requirements in high-security scenarios, exacerbating the risk of configuration delay or interruption. The above problems seriously restrict the automation configuration efficiency of eSIM devices and the user experience. Summary of the Invention

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

[0004] According to one aspect of the present invention, there is provided an eSIM remote configuration management method based on a cloud platform, the method comprising:

[0005] Obtaining a real-time configuration request of a target eSIM device, and extracting an environment feature set and a device identification feature from the real-time configuration request; the environment feature set includes a network access mode, geographical location coordinates, and signal strength distribution parameters;

[0006] Matching a corresponding dynamic policy model from a pre-constructed 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;

[0007] Generating a configuration policy sequence for the target eSIM device based on the environment feature set and the matched dynamic policy model; the configuration policy sequence includes a plurality of candidate configuration parameter groups sorted by priority;

[0008] Generate a remote configuration instruction according to the highest-priority candidate configuration parameter group in the described configuration policy sequence, and send the remote configuration instruction to the target eSIM device through the cloud platform interface;

[0009] Receive the 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.

[0010] According to another aspect of the present invention, there is provided a cloud platform, including:

[0011] At least one processor;

[0012] 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 to enable the at least one processor to execute the method described above.

[0013] The present invention has at least the following beneficial effects:

[0014] 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.

[0015] 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

[0016] 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.

[0017] 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.

[0018] Figure 2 The flowchart of a method for remote configuration management of eSIM based on a cloud platform according to an embodiment of the present invention is shown.

[0019] Figure 3 The schematic diagram of the composition of a cloud platform according to an embodiment of the present invention is shown. Detailed implementation manners

[0020] The following describes exemplary embodiments of the present invention with reference to the accompanying drawings. Various details of the embodiments of the present invention are included to facilitate understanding, and they should be considered merely exemplary. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can 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 below.

[0021] In the description of various examples of the present invention, the terms used are only for the purpose of describing specific examples and are not intended to be limiting. Unless otherwise explicitly stated in the context, if the number of elements is not specifically defined, 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.

[0022] Figure 1 The schematic diagram of the application scenario of the 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 that couple one or more eSIM devices 101 to the cloud platform 120. In some embodiments, the cloud platform 120 can also provide eSIM configuration services or software applications. In some embodiments, these services can be provided as web-based services or cloud services, for example, provided to users of the eSIM device 101 under a software as a service (SaaS) model.

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

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

[0025] The network 110 can be any type of network well-known to those skilled in the art, which can support data communication using any one of a variety of available protocols (including but not limited to TCP / IP, SNA, IPX, etc.). By way of example only, one or more networks 110 can be a local area network (LAN), an Ethernet-based network, 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 (such as Bluetooth, WIFI), and / or any combination of these and / or other networks.

[0026] The cloud platform 120 can include one or more general-purpose computers, dedicated server computers (such as PC (personal computer) servers, UNIX servers, midrange servers), blade servers, mainframes, server clusters, or any other suitable arrangement and / or combination. The cloud platform 120 can include one or more virtual machines running a virtual operating system, or other computing architectures involving virtualization (such as one or more flexible pools of logical storage devices that can be virtualized to maintain virtual storage devices for the servers). In various embodiments, the cloud platform 120 can run one or more services or software applications that provide the functions described below.

[0027] The computing units in the cloud platform 120 can run one or more operating systems including any of the above operating systems as well as any commercially available server operating systems. The cloud platform 120 can also run any one of a variety of additional server applications and / or middleware applications, including HTTP servers, FTP servers, CGI servers, JAVA servers, database servers, etc.

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

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

[0030] The application scenario may also include one or more databases 130. In certain 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 databases 130 may reside at various locations. For example, the databases 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 databases 130 may be of different types. In certain embodiments, the databases used by the cloud platform 120 may be relational databases, for example. One or more of these databases may store, update, and retrieve data to and from the databases in response to commands.

[0031] Please refer to Figure 2 , the eSIM remote configuration management method based on a cloud platform provided by an embodiment of the present invention includes the following steps:

[0032] Step S100: Obtain a real-time configuration request of a target eSIM device, and extract an environmental feature set and a device identification feature from the real-time configuration request; the environmental feature set includes a network access mode, geographical location coordinates, and signal strength distribution parameters.

[0033] Exemplarily, a real-time configuration request refers to a request instruction actively initiated by a target eSIM device to a cloud platform via a wireless communication network, demanding to obtain specific configuration parameters. Its triggering conditions include, but are not limited to, device first activation, network environment change, or user manual triggering operation. The environmental feature set is a multi-dimensional parameter set used to describe the current operating environment of the target eSIM device. Among them, the network access mode specifically refers to the combination of the network type and communication protocol to which the device is currently connected. For example, the coexistence of 4G cellular network and Wi-Fi dual mode, 5G standalone networking, or narrowband Internet of Things single-mode connection; the geographical location coordinates are obtained through the Global Positioning System or base station triangulation technology, used to accurately identify the longitude and latitude information where the device is located; 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. For example, the average 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 non-tamperable physical features such as the International Mobile Equipment Identity, 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 the device identification feature from the request header fields and payload content, ensuring that the subsequent policy generation process has accurate input conditions.

[0034] Step S200: Match the corresponding dynamic policy model from the pre-constructed 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.

[0035] Exemplarily, the dynamic policy model library is a set of machine learning models stored in the distributed database of the cloud platform. Its construction process is based on the mapping relationship between the device identification features, environmental features, and the finally effective configuration parameter groups recorded in the historical configuration data. For example, the time series neural network algorithm can be used for training and optimization. Each dynamic policy model corresponds to the configuration policy generation ability of a specific device type or hardware version. For example, the anti-interference configuration model for industrial-grade eSIM devices or the low-power consumption configuration model for consumer-grade devices. The configuration policy generation rules are a set of decision logics embedded in the dynamic policy model, including network access mode priority determination rules, signal strength threshold trigger conditions, and geographical location area division strategies. When the hardware version number in the device identification feature matches the preset version code 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 set of configuration policy generation rules bound to the model, providing a rule basis for the subsequent policy sequence generation. For example, when the device identification feature shows that the target eSIM device is a certain model of in-vehicle terminal, the dynamic policy model will preferentially match the dedicated model that supports multi-network fast switching and high signal fault tolerance mechanism.

[0036] As an implementation manner, the generation process of the dynamic policy model library may include the following steps:

[0037] Step S201: Obtain a configuration operation data set of multiple historical eSIM devices; the configuration operation data set includes environmental feature records, configuration parameter execution records, and configuration result evaluation metrics of each historical eSIM device.

[0038] Exemplarily, the configuration operation data set is a structured set of historical eSIM device full-life cycle operation data collected through a cloud platform logging system, and its data sources cover device activation requests, configuration instruction issuance records, and network performance monitoring results. The environmental feature record refers to, for example, a time-series data set of network access modes, geographical location coordinates, and signal strength distribution parameters reported by the device within a historical time period. For example, the 4G / 5G dual-mode switching records, longitude and latitude trajectories, and mean square deviation values of signal strengths in different frequency bands recorded by a certain model of in-vehicle terminal within 30 consecutive days. The configuration parameter execution record includes network access configurations, frequency band locking policies, and power consumption control parameter combinations actually effective for the device. For example, the 5G NSA mode, 3.5 GHz main frequency band, and dynamic power adjustment threshold enabled in a certain configuration instruction. The configuration result evaluation metric is the quantization 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%.

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

[0040] Exemplarily, the device identification features are, for example, an immutable attribute set extracted from the hardware information and registration information of historical eSIM devices, including the International Mobile Equipment Identity, embedded SIM card serial number, and firmware version number. For example, the device identification features of a certain batch of industrial-grade eSIM devices include a unified hardware version number "HW-5G-IND-01" and a pre-allocated SIM card number segment "89860121". Based on the hardware version number and SIM card number segment prefix in the device identification features, 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" is classified into the same sub-data set. In this process, a distributed hash algorithm is used to quickly group the massive historical data to ensure that the sub-data set corresponding to each device feature group only contains configuration operation records of the same type of devices, thereby providing data consistency guarantee for subsequent rule extraction.

[0041] Among them, for each sub-dataset corresponding to a device feature group, the following processing can be specifically performed:

[0042] Step S203: Build an initial policy generation rule set according to the environmental feature records and configuration parameter executions in the sub-dataset; the initial policy generation rule set includes multiple conditional branches, and each conditional branch corresponds to a set of environmental feature threshold ranges and associated configuration parameter groups.

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

[0044] Step S204: Optimize the initial policy generation rule set by using the configuration result evaluation index in the sub-dataset to generate a dynamic policy model corresponding to the device feature group; among them, the optimization process includes merging redundant conditional branches, adjusting the environmental feature threshold range, and updating the priority of the configuration parameter group.

[0045] In an exemplary embodiment, the optimization process may iteratively correct the initial rules based on the configuration success rate, signal stability gain, and energy consumption change rate in the configuration result evaluation metrics. For example, a certain conditional branch stipulates that "IF the network access mode is 4G single mode AND the standard deviation of the signal strength ≤ 10 dB THEN enable CA carrier aggregation", but its configuration success rate is only 65% and the energy consumption change rate increases by 15%, indicating that there are redundancies or unreasonable threshold settings in this rule. By merging adjacent conditional branches that cover the same range of environmental characteristics and adjusting the signal strength standard deviation threshold to 8 dB, the configuration success rate of the optimized rule is increased to 82%, and at the same time, the energy consumption change rate is decreased to 5%. The priority update dynamically sorts according to the historical effects of the configuration parameter groups. For example, the priority of the configuration parameter groups with a signal stability gain higher than 20% is increased, while the configuration parameter groups with an energy consumption change rate exceeding the preset threshold are downgraded to alternative options. The finally generated dynamic policy model encodes the optimized policy generation rule set into executable decision logic and stores it bound to the device feature group.

[0046] Step S205: Store the optimized dynamic policy model in the dynamic policy model library and establish a mapping relationship between the dynamic policy model and the device identification features of the corresponding device feature group.

[0047] Exemplarily, the dynamic policy model library may adopt a graph database to store the topological relationships between models. Among them, each dynamic policy model uses the hardware version number and SIM card number segment in the device identification features as the index keys. 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 is implemented using a two-way hash table for fast retrieval. When the new device identification features match 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, facilitating subsequent traceability and rollback operations.

[0048] As an embodiment, in step S204, using the configuration result evaluation metrics in the sub-dataset to optimize the initial policy generation rule set includes:

[0049] Step S2041: Extract the configuration success rate, signal stability gain, and energy consumption change rate from the configuration result evaluation metrics of the sub-dataset.

[0050] 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, among 120 configuration operations triggered by a certain rule, 108 times successfully completed APN authentication and frequency band locking, then the configuration success rate is 90%. The signal stability gain is calculated by comparing the changes 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 15 dB to 8 dB, and the gain is 46.7%. The energy consumption change rate is quantified by the ratio of the average power consumption before and after configuration. For example, after configuration, the standby current of the device rises from 12 mA to 13 mA, and the change rate is 8.3%.

[0051] For example, for each conditional branch in the rule set generated for the initial policy, the following operations are performed:

[0052] Step S2042: Calculate the weighted score of the configuration success rate and the signal stability gain of the historical configuration parameter group corresponding to the conditional branch.

[0053] Exemplarily, the determination method of the weighted score is: 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 certain conditional branch is 85% and the signal stability gain is 30%, then its weighted score is 0.6 × 85 + 0.4 × 30 = 63 points.

[0054] Step S2043: If the weighted score is lower than the preset score threshold, delete the conditional branch and merge the environmental feature threshold range covered by the conditional branch into the adjacent conditional branch.

[0055] Exemplarily, the preset score 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 the score of a certain conditional branch is 55 points, the covered signal strength range [-80 dBm, -70 dBm] will be merged into the adjacent [-70 dBm, -60 dBm] interval, and the rule score after merging will be recalculated.

[0056] 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, adjust the power consumption control parameters in the configuration parameter group associated with the conditional branch and recalculate the configuration result evaluation index.

[0057] Exemplarily, the preset energy consumption threshold is set according to the device power capacity. For example, it is 10% for in-vehicle terminals and 5% for wearable devices. If a certain rule has a score of 75 but an energy consumption change rate of 12%, then the transmit power in its configuration parameter group is reduced from 23 dBm to 20 dBm, and historical data is recollected to calculate that the updated energy consumption change rate is 7%.

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

[0059] Exemplarily, rule conflict detection is performed by traversing 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 that "IF the network access mode is 5G AND the geographical location is the city center THEN enable frequency band A" and "IF the signal strength ≥ -65 dBm AND the geographical location is the city center THEN enable frequency band B", a conflict alarm will be triggered in the overlapping coverage area of frequency band A and frequency band B.

[0060] Step S2046: If a rule conflict is detected, reorder the priorities of the conflicting conditional branches until there are no conflicting paths in the policy decision tree model.

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

[0062] As an implementation manner, wherein, the construction process of the policy decision tree model includes the following steps:

[0063] Step S20461: Extract the environmental feature threshold ranges and associated configuration parameter groups of all conditional branches from the updated policy generation rule set.

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

[0065] Step S20462: Using the network access mode as the root node, construct multi-level decision nodes in the order of geographical location coordinates and signal strength distribution parameters.

[0066] Exemplarily, the root node first divides the network access mode in which the device is located. For example, 4G, 5G, and hybrid modes are used as three main branches. Under each main branch, sub-nodes are divided according to the longitude and latitude ranges of the geographical location coordinates. For example, sub-nodes such as "city center", "suburbs", and "remote areas" are created under the 5G branch. The last-level nodes are further subdivided according to the mean and standard deviation of the signal strength distribution parameters. For example, paths such as "signal strength mean ≥ -65dBm" and "signal strength mean < -65dBm" are created under the "city center" sub-node.

[0067] Step S20463: Set the corresponding environmental feature threshold splitting points at each decision node, and point the paths that meet the splitting point conditions to the next-level decision nodes or leaf nodes.

[0068] Exemplarily, the threshold splitting points can be determined by the dichotomy method or the equal-frequency binning method. For example, the signal strength mean is divided into intervals such as [-90dBm, -85dBm), [-85dBm, -80dBm), etc. at intervals of 5dB. When the device environmental features match a certain splitting point condition, the decision path is passed down along the corresponding branch until it reaches the leaf node.

[0069] Step S20464: Associate the corresponding configuration parameter groups at the leaf nodes, and set the execution order of the leaf nodes based on the priorities of the configuration parameter groups.

[0070] For example, at the leaf node where the signal strength mean ≥ -65dBm, two parameter groups of "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 their weighted scores. If the default configuration execution fails, subsequent parameter groups are tried in the order of priority.

[0071] Step S20465: Prune the constructed initial policy decision tree, delete the 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.

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

[0073] As an implementation manner, step S200, which matches the corresponding dynamic policy model from the pre-constructed dynamic policy model library according to the device identification feature, includes:

[0074] Step S210: Decompose the device identification feature into multiple sub-feature sets, where the sub-feature sets include a hardware model code, a firmware version sequence, and an operator code combination.

[0075] Exemplarily, the device identification feature is a set of unique identification data extracted from the non-volatile memory of the target eSIM device, and its decomposition process can be implemented through a feature parsing algorithm. The hardware model code is a hardware version identifier defined by the device manufacturer. For example, "HW-5G-IND-01" represents 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. For example, "FW-2.1.3_20231001" represents the firmware version 2.1.3 released on October 1, 2023. The operator code combination is a set of authorization codes for the network access permission of the operator to which the device belongs. For example, "CN-MOB-001" represents the China Mobile eSIM signing code, and "CN-TEL-005" represents the dedicated access code for China Telecom's Internet of Things. 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.

[0076] 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, and filter out all candidate dynamic policy models containing the hardware model code to form a first candidate model list.

[0077] Exemplarily, the hierarchical index table is a multi-level index table constructed based on the B+ tree structure. Its first-level nodes use the hardware model code as the key value, and each key value is associated with a linked list of dynamic policy models. For example, when the hardware model code is "HW-5G-IND-01", the index table traversal algorithm starts from the root node for matching, locates the leaf node containing this code, and obtains the head address of the linked list it points to. The linked list stores all the metadata of the dynamic policy models that support this hardware model, including the model identifier, the applicable firmware version range, and the operator whitelist. During the traversal process, a prefix matching mechanism can be adopted to ensure that models with partial code matches can also be filtered. For example, "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 the models identified as "MODEL_5G_IND_V3" and "MODEL_5G_IND_LEGACY".

[0078] Step S230: Based on the firmware version sequence, perform second-level matching condition filtering on the first candidate model list, extract the models in the candidate dynamic policy models whose firmware adaptation ranges cover the firmware version sequence, and generate a second candidate model list.

[0079] 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" means supporting 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 detection is performed with the adaptation range of the candidate model. For example, if the adaptation range of a certain model is "≥2.1.0 and <2.2.0", then the target firmware version meets this condition, and this model is retained in the second candidate model list. For the adaptation range defined by the timestamp (such as "20230901 to 20231130"), then extract "20231001" in the firmware version sequence for time window matching. After the second-level filtering, the 12 models in the first candidate model list are reduced to 5. For example, "MODEL_5G_IND_V3" is retained because its adaptation range is "FW-2.1.0 to FW-2.3.0", and "MODEL_5G_IND_LEGACY" is excluded because it only supports "FW-1.4.0 to FW-2.0.0".

[0080] Step S240: According to the operator code combination, perform third-level matching condition mapping on the second candidate model list, and match the target dynamic policy model in the operator whitelist associated with the candidate dynamic policy model that completely contains the operator code combination.

[0081] Exemplarily, the operator whitelist is a set of predefined authorized operator codes 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 both 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 completely included. If the device code combination contains codes unauthorized by the whitelist (such as "CN-GLB-010"), the model is excluded. During this process, the 5 models in the second candidate model list are further reduced to 2. For example, "MODEL_5G_IND_V3" is retained because the whitelist contains "CN-MOB-001" and "CN-TEL-005", while "MODEL_5G_IND_HYBRID" is excluded because the whitelist only contains "CN-UNI-007".

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

[0083] Exemplarily, the activation timestamp is the time identifier when the device first successfully accesses the cloud platform, such as "2023-10-01 08: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", while the update timestamp of "MODEL_5G_IND_V3B" is "2023-10-05 09:00:00". Calculate the absolute time difference between the activation timestamp and the update timestamp. 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. Through ascending order sorting, select "MODEL_5G_IND_V3B" with the smallest time difference as the final matching model to ensure that the device uses the most recently optimized policy rules.

[0084] Step S260: If there is no target dynamic policy model after the third-level matching condition mapping, input the hardware model code and firmware version sequence into the similarity evaluation engine of the dynamic policy model library, calculate the compatibility scores with each candidate dynamic policy model, and select the dynamic policy model with a compatibility score exceeding the preset threshold as the alternative matching result. At the same time, record the unmatched operator code combinations in the difference feature log for subsequent model incremental training.

[0085] Exemplarily, the similarity evaluation engine can adopt a multi-dimensional feature weighting algorithm. Among them, 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, then this model is selected as the alternative matching result. The unmatched operator code combination "CN-GLB-010" is recorded in the difference feature log, and the log structure includes 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, this operator code is included in the white list extension range.

[0086] Step S300: Generate a configuration policy sequence for the target eSIM device based on the environmental feature set and the matched dynamic policy model; the configuration policy sequence includes multiple candidate configuration parameter groups sorted by priority.

[0087] Exemplarily, a configuration policy sequence refers to a parameter combination queue that is dynamically generated according to real-time environmental characteristics and policy generation rules and arranged in descending order of execution priority. Each candidate configuration parameter group includes 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 power consumption indicators. For example, it places the 5G standalone configuration above the 4G / Wi-Fi dual-mode configuration, or automatically raises the priority of the low-frequency band configuration when the standard deviation of the signal strength exceeds a preset threshold. The dynamic policy model analyzes the time-frequency characteristics of the signal strength distribution parameters through convolution operations, combines the geographical location coordinates to match the preset regional network coverage heat map, and finally generates a policy 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 rule constraints preset in the dynamic policy model. For example, when the network access mode is cellular single connection, the heartbeat packet interval optimization strategy is forced to be enabled.

[0088] As an implementation manner, in step S300, based on the environmental feature set and the matched dynamic policy model, a configuration policy sequence for the target eSIM device is generated, which may specifically include the following steps:

[0089] Step S310: Perform conditional branch matching on the network access mode in the environmental feature set and 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.

[0090] Exemplarily, the network access mode threshold range is a predefined set of network types in the rule library of the dynamic policy model. For example, "5G NSA (non-standalone networking)", "4G CA (carrier aggregation)", and "3G / Wi-Fi dual mode" are used 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 rules and filters out valid rules that include "5G NSA" or "5G NSA and 4G CA hybrid mode". For example, a rule defines the network access mode threshold as "5G NSA or 4G CA" and the mean signal strength ≥ -75dBm, then this rule is marked as a valid rule. During 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 only focuses on the policies compatible with the current network environment.

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

[0092] Exemplarily, the signal strength adaptation conditions associated with the geographical location coordinates refer to the longitude and latitude boundary ranges and the corresponding signal strength constraints set in the rule. For example, a certain rule stipulates that in the area with longitude [116.30°, 116.50°] and latitude [39.90°, 40.10°], the average signal strength ≥ -70 dBm and the standard deviation ≤ 10 dB should be satisfied. The geographical location coverage overlap degree is determined by calculating the overlapping area ratio between the current coordinates of the target device and the geographical fence in the rule. For example, when the device coordinates are located at [116.35°, 39.95°], the overlapping area with the rule geographical fence accounts for 92% of its total coverage area. At the same time, the mean and standard deviation in 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 -68 dBm and the standard deviation is 8 dB, it is determined that the rule adaptation conditions are met.

[0093] Step S330: Pre-sort the valid rules with the geographical location coverage overlap degree reaching the preset overlap threshold and the signal strength distribution parameters meeting the adaptation conditions, and generate an initial candidate rule queue.

[0094] Exemplarily, the preset overlap threshold is dynamically adjusted according to the device moving speed. For example, the threshold for a fixed device is 80%, while the threshold for a vehicle-mounted terminal is reduced to 60% to adapt to the high-speed moving scenario. When the geographical location coverage overlap degree of a certain rule is 85% and the signal strength parameters are completely matched, this rule is added to the initial candidate rule queue. The pre-sorting algorithm sorts in descending order based on the signal strength mean requirement of the rule. For example, rules with higher signal strength thresholds are preferred to maximize the connection stability. For example, rule A requires the signal strength ≥ -65 dBm, and rule B requires ≥ -70 dBm, then rule A is ranked higher than rule B in the queue, although its geographical location coverage overlap degree is slightly lower.

[0095] Step S340: According to the rule historical execution success rate and energy consumption efficiency indicators recorded in the dynamic policy model, optimize and adjust the weights of the valid rules in the initial candidate rule queue, and re-determine the priority order.

[0096] Exemplarily, the rule historical execution success rate refers to the proportion of the number of times the rule successfully completed the configuration operation in the past 100 triggers. For example, the success rate of rule A is 95%, and that of rule B is 88%. The energy consumption efficiency index is calculated by the ratio of the average power consumption to the reference power consumption of the configuration parameter group associated with the rule in historical execution. For example, the power consumption ratio of rule A is 110%, and that of rule B is 98%. The weight optimization adopts a multi-objective weighting algorithm, assigning 60% weight to the execution success rate and 40% weight to the energy consumption efficiency, and re-ranking 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. Therefore, the priority of rule B is raised to the top of the queue.

[0097] Step S350: Map the adjusted valid rules to the corresponding candidate configuration parameter groups according to the priority order, and eliminate the redundant parameter items that conflict with the device identification features of the target eSIM device in the candidate configuration parameter groups.

[0098] 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 secondary frequency band 1.8GHz". The detection of device identification feature conflicts 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" while the target device is "HW-5G-IND-01", then the configuration item "4G CA secondary frequency band 1.8GHz" in the parameter group is eliminated because it depends on a specific hardware filter module. After eliminating the redundant parameter items, the remaining parameter groups are encapsulated into a conflict-free standardized instruction template.

[0099] Step S360: Dynamically calibrate the connection stability parameters in the candidate configuration parameter groups according to the real-time fluctuation trend of the signal strength distribution parameters, and form a configuration policy sequence including the calibrated parameters and priority labels.

[0100] Exemplarily, the real-time fluctuation trend of the signal strength can be calculated by the sliding window algorithm for the variance change rate of the signal strength in the recent 5 minutes. For example, if the variance rises from 8dB² to 15dB², it indicates a decrease in signal stability. The dynamic calibration module adjusts the heartbeat packet interval (shortened from 30 seconds to 20 seconds) and the handover decision threshold (increased from -75dBm to -70dBm) in the parameter group accordingly. The calibrated parameter group is attached with a priority label, such as "high stability first" or "low energy consumption first", and the label assignment is based on the scenario identifier in the device identification features. Industrial devices are marked as "high stability", and consumer electronics are marked as "low energy consumption".

[0101] Step S370: When it is detected that the network access mode or geographical location coordinates in the environmental feature set change, trigger a partial reordering of the configuration policy sequence, and perform a secondary verification on the signal strength adaptation conditions of the candidate configuration parameter groups based on the changed environmental feature set.

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

[0103] As an implementation, in the step S300, when generating the configuration policy sequence of the target eSIM device, it further includes:

[0104] Step S301: Real-time monitor the network connection status of the target eSIM device, and when it is detected that the network delay exceeds a preset delay threshold, trigger a dynamic adjustment of the configuration policy sequence.

[0105] Exemplarily, the network delay threshold is set according to the device type. For example, it is 50 ms for industrial control devices and 200 ms for video surveillance devices. The monitoring module continuously sends probe data packets and calculates the round-trip time (RTT). When the average value of RTT exceeds the threshold for 3 consecutive times, a delay alarm event is generated. For example, when the RTT of a vehicle-mounted terminal suddenly increases from 40 ms to 80 ms, the dynamic adjustment process is triggered.

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

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

[0108] Step S303: Insert the adjusted secondary priority candidate configuration parameter group to the head of the configuration policy sequence, and generate a new remote configuration instruction.

[0109] Exemplarily, the new remote configuration instruction overwrites the connection parameters in the original instruction. For example, it changes the APN (Access Point Name) from "industrial.apn" to "lowlatency.apn" and adds an emergency reconfiguration identifier to the instruction header. The cloud platform interface preferentially sends this instruction to the target device to ensure its preemption of the current transmission channel.

[0110] Step S304: After the target eSIM device successfully executes the new remote configuration instruction, record the adjusted secondary priority candidate configuration parameter group and its corresponding network latency parameter into the policy generation rule of the dynamic policy model.

[0111] Exemplarily, after successful execution, the configuration response data uploaded by the device side includes new network latency metrics (such as the RTT dropping to 45 ms) and compression efficiency data. The dynamic policy model updates the rule library through an online learning mechanism. For example, it adds a branch of "enable low-latency APN and lossy compression" under the condition of "network latency > 50 ms" and initializes its historical execution success rate to 100% for subsequent preferential invocation.

[0112] 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.

[0113] Exemplarily, the remote configuration instruction is, for example, a binary data packet conforming to the GSMA remote SIM configuration specification. Its encapsulation process includes, for example, converting the network access parameters in the candidate configuration parameter group into APN access point names, authentication keys, and QoS service quality level identifiers, 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 in fragments to the device side through the HTTPS encrypted transport layer. During the instruction sending process, the cloud platform monitors the network transmission latency and the packet retransmission rate in real time. When it detects a significant change in the signal strength distribution parameter, it automatically triggers the reordering mechanism of the configuration policy sequence. For example, if the standard deviation of the signal strength of the target device suddenly increases beyond the threshold during the instruction transmission stage, the cloud platform will immediately abort the current instruction sending and re-execute step S300 to generate a new configuration policy sequence to ensure the real-time adaptability of the configuration instruction.

[0114] As an implementation manner, in step S400, generating a remote configuration instruction according to the highest priority candidate configuration parameter group in the configuration policy sequence may specifically include the following steps:

[0115] Step S410: Extract the network connection parameters, security authentication parameters, and service subscription parameters from the highest-priority candidate configuration parameter group, and verify the compatibility between the network connection parameters and the hardware model code in the device identification features of the target eSIM device.

[0116] 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 frequency band locking policy. For example, the APN is "industrial.iot", the QoS level is "Priority 5", and the 3.5 GHz frequency band is locked. The security authentication parameters include a pre-shared key identifier, a certificate fingerprint, and a mutual authentication protocol type. For example, the key identifier "KID_2023_V2" is associated with the AES-256 encryption algorithm and the SHA-256 signature mechanism. The service subscription parameters define the cloud service endpoints and the API permission list that the device can access. For example, access to "https: / / api.iotplatform.com / v1 / data" is allowed, but access to "https: / / api.otaupdate.com" is prohibited. The 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 frequency band locking policy requires the hardware to support a 3.5 GHz frequency band filtering module, and the hardware specification document of the device model code "HW-5G-IND-01" clearly includes this module, so it is determined that the verification passes.

[0117] Step S420: If the verification passes, combine the security authentication parameters and the service subscription parameters according to a preset instruction template structure to generate a draft of the initial configuration instruction; the instruction template structure includes a parameter type identifier, a parameter value placeholder, and a check code generation bit.

[0118] Exemplarily, the instruction template structure is an XML schema that conforms to the GSMA specification, where the parameter type identifier is used to distinguish the categories of network connection, security authentication, and service subscription parameters. For example, " <networkconfig> ”" <securityauth> ”" <servicesub>" label. The parameter value placeholder is marked in the format of "${}" for the actual parameter value to be filled. For example, <apn>${apn_value}< / apn> " the "apn_value" in "" corresponds to "industrial.iot". The checksum generation bit is reserved at the end of the instruction for storing the CRC32 checksum calculated later. During the combination process, the key identifier "KID_2023_V2" in the security authentication parameter is filled into <keyid>${key_id}< / keyid> " placeholder, and the API endpoint list in the service subscription parameter is serialized into <allowurl>${url_list}< / allowurl> " in the JSON array format to form a draft of the unencrypted initial configuration instruction.

[0119] Step S430: According to the transmission protocol type of the target eSIM device currently connecting to the cloud platform interface, perform protocol adaptation conversion on the draft of the initial configuration instruction, fill in the protocol header fields, and replace the parameter value placeholder with the actual parameter value.

[0120] Exemplarily, the transmission protocol types include HTTPS, CoAP, and MQTT. For example, when the device currently uses an 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 replacement of the parameter value placeholder is completed through a 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 to the CBOR (Concise Binary Object Representation) format and the Message ID and Token fields in the CoAP message header are added to ensure protocol compatibility.

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

[0122] 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 sequentially and attaches an authentication tag to generate an encrypted configuration instruction data packet in binary format. The data packet structure follows the ISO / IEC 7816-4 specification, including the encryption algorithm identifier "0x01" indicating AES-256-GCM, the ciphertext data segment, and a 16-byte integrity check tag.

[0123] Step S450: Determine the fragmentation strategy and transmission priority marking for the encrypted configuration instruction data packet according to the bandwidth limit and signal strength distribution parameter in the network connection parameter; the fragmentation strategy includes the upper limit of the fragmentation size and the number of retransmission redundant fragments.

[0124] Exemplarily, 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 fragmentation 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 retransmission redundant fragments is increased from the default 1 to 3 to improve transmission reliability. The transmission priority marking is set according to the urgency of the configuration policy. For example, when the device is in a roaming state, it is marked as "high priority", triggering the priority queue scheduling mechanism of the cloud platform interface.

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

[0126] 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 fragmentation size of 1024 bytes) and "0301" (indicating 3 redundant fragments). The transmission priority marking is encoded as type code "0x2A", length "0x01", value "0x01" (high priority). After injection, 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.

[0127] Step S470: If the verification fails, trigger the replacement mechanism of the secondary priority candidate configuration parameter group in the configuration policy sequence, and record the invalid network connection parameters in the highest priority candidate configuration parameter group to the policy generation rule exception list of the dynamic policy model.

[0128] For example, when the frequency band locking strategy in the highest priority parameter group requires the 4.9 GHz frequency band but the hardware of the device model code "HW-5G-IND-01" does not support it, the system automatically selects the secondary priority parameter group (such as the 3.5 GHz frequency band strategy) and re-executes steps S410 to S460. The invalid parameter "4.9 GHz frequency band locking" is recorded in the exception list, and the list entry includes the device identification characteristics, the environmental characteristic 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 conditions of the policy generation rule.

[0129] Step S500: Receive the 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 characteristics in the dynamic policy model library according to the configuration response data.

[0130] Exemplarily, the configuration response data may include, for example, the execution result code of the target eSIM device for the remote configuration instruction, the identifier of the actually effective configuration parameter group, and the network performance metrics measured at the device end, such as the data transmission rate, the steady-state value of the signal strength, and the power consumption level. The cloud platform analyzes the deviation degree between the preset configuration parameter group and the actually effective parameter group through a difference comparison algorithm. When it detects that multiple devices with similar geographical coordinates all have the same configuration parameter group execution failure, it automatically triggers the weight adjustment mechanism of the policy generation rule. 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 handover success rate penalty term to the loss function of the dynamic policy model, and performing online iterative optimization on the configuration policy generation rule based on the reinforcement learning algorithm. For example, if a certain model of in-vehicle terminal frequently experiences 5G configuration connection timeouts in highway scenarios, the dynamic policy model will automatically add a speed threshold condition to the policy generation rule. When the device moving speed exceeds 120 km / h, it will be forced to downgrade to the 4G CA configuration parameter group, and at the same time, this rule will be synchronized to the dynamic policy models of all associated device types in the model library.

[0131] 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:

[0132] Step S510: Analyze the actual configuration parameter execution result and the device status indicators in the configuration response data.

[0133] Exemplarily, the execution result of the actual configuration parameters refers to the operation status code and the list of effective parameters returned after the target eSIM device executes the remote configuration instruction. For example, the status code "0x00" indicates that the APN (Access Point Name) and the frequency band locking policy have been successfully applied, while the status code "0xE1" indicates that the security authentication parameter verification fails. The device status indicators include the real-time network performance data after the configuration takes effect. For example, the network latency drops from 120 ms to 45 ms, the average signal strength stabilizes at -68 dBm, and the standard deviation is 7 dB. The parsing process separates the data fields through regular expression matching and JSON deserialization techniques. For example, key-value pairs such as "APN=industrial.iot" and "QoS=5" are extracted from the response data, and the network latency indicator "latency=45" is converted into a floating-point numerical value and stored in the analysis queue.

[0134] Step S520: Compare the execution result of the actual configuration parameters with the candidate configuration parameter group with the highest priority in the configuration policy sequence to determine the type and magnitude of the parameter deviation.

[0135] 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" while the actually effective APN is "backup.iot", it is determined as "APN parameter deviation"; if the expected average signal strength is -65 dBm while the actual value is -68 dBm, the deviation magnitude is calculated as 3 dB. The parameter deviation types are divided into compatible deviations and incompatible deviations. The former refers to the situation where the parameter value differences do not affect the core functions (such as the QoS level is adjusted from 5 to 4), and the latter refers to the situation where the parameter absence or out-of-bounds causes functional abnormalities (such as the frequency band locking policy does not take effect).

[0136] Step S530: If the parameter deviation type is a compatible deviation and the deviation magnitude is within the preset tolerance range, keep the policy generation rule of the dynamic policy model unchanged and record the execution result of the actual configuration parameters as supplementary training data.

[0137] Exemplarily, the preset tolerance range is dynamically set according to the parameter type. For example, the tolerance for the average signal strength is ±5 dB, and the tolerance for the network latency is ±20 ms. When the APN deviation is a compatible backup access point of the same operator and the signal strength deviation is 2 dB, the rule library of the dynamic policy model maintains the original conditional branch, and at the same time, the actual parameter values "APN=backup.iot" and "signal_mean=-68 dB" are added as new samples to the training data set. The supplementary training data is stored in the unstructured database of the cloud platform, and the device identification features and the environmental feature set associated with it are marked through data version control.

[0138] Step S540: If the parameter deviation type is an incompatible deviation or the deviation magnitude exceeds the preset tolerance range, extract the environmental feature set and device identification features, and initiate incremental training of the dynamic policy model; 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 splitting point thresholds of the policy decision tree model.

[0139] For example, when the frequency band locking policy results in an actual effective frequency band deviating from the expected value by more than 10 MHz 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 central area" as inputs, and re-evaluates the conditional weights of the frequency band selection rules in the policy decision tree. The splitting point threshold adjustment uses the gradient descent algorithm. For example, the signal strength mean threshold is optimized from -70 dBm to -68 dBm to match the actual effective conditions.

[0140] As an implementation, the above incremental training may further include the following steps:

[0141] Step S541: Extract the change trend of the network access mode and the movement trajectory of the geographical location coordinates from the new sample data.

[0142] Exemplarily, the change trend of the network access mode is statistically analyzed by a sliding window to obtain the network type switching frequency of the device in the last 24 hours. For example, the average interval from 5G NSA to 4G CA is 15 minutes. The movement trajectory of the geographical location coordinates is smoothed using the Kalman filter algorithm to generate the longitude and latitude change rate and direction angle. For example, the device moves at a speed of 60 km / h along the direction from longitude 116.30° to 116.45°. The trajectory data is encoded in GeoJSON format and associated with a time stamp sequence for spatio-temporal feature analysis.

[0143] Step S542: Predict the expected environmental features of the target eSIM device within a future time window based on the change trend and movement trajectory.

[0144] Exemplarily, the length of the future time window is adaptively adjusted according to the movement speed. For example, it is set to 5 minutes for high-speed moving devices and 1 hour for fixed devices. The prediction of the expected environmental features uses 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 -72 dBm and the network access mode will switch to 4G CA after 5 minutes. The expected geographical location coordinates are calculated by linear extrapolation. For example, if the current longitude is 116.40° and it increases at a rate of 0.002° / min, the expected longitude after 5 minutes is 116.40° + (0.002 × 5) = 116.41°.

[0145] Step S543: Add a temporary decision path in the policy decision tree model, where the temporary decision path maps the expected environmental features to a preset group of preliminary configuration parameters.

[0146] Exemplarily, the temporary decision path is identified with a prefix of "expected_". 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 dual connection with 2.4GHz Wi-Fi". The path condition is set as "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 will be automatically marked as pending recovery after timeout.

[0147] Step S544: When it is detected that the matching degree between the environmental features of the target eSIM device and the expected environmental features exceeds a preset matching threshold, preferentially execute the remote configuration instructions corresponding to the preliminary configuration parameter group.

[0148] Exemplarily, the matching degree is calculated using the cosine similarity algorithm. For example, if the similarity between the actual environmental feature vector and the expected vector is 0.92 (threshold 0.85), then trigger the download of the preliminary parameter group. The preliminary configuration parameter group is preemptively downloaded through the cloud platform interface. For example, 300 meters before the device enters the longitude area of 116.41°, activate the 4G CA configuration in advance to avoid signal switching delay.

[0149] Step S545: After the end of the future time window, if the preliminary configuration parameter group has not been triggered for execution, remove the temporary decision path from the policy decision tree model.

[0150] 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 paths with the prefix of "expected_". If the "triggered" flag is false, delete the path and release the associated memory resources. The removal operation also clears the instruction cache of the preliminary parameter group to ensure that the policy decision tree model maintains the optimal decision-making efficiency.

[0151] As an implementation manner, the method further includes a process for abnormal configuration handling, specifically including:

[0152] Step S600: After the remote configuration instruction is issued, start a configuration execution countdown.

[0153] Exemplarily, the configured execution countdown is a timeout monitoring window dynamically set based on the network connection quality of the target eSIM device. For example, when the network latency is 50 ms, the countdown duration is set to 30 seconds, and when the latency increases to 150 ms, 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 at the millisecond level, ensuring that the subsequent exception handling process is accurately triggered when no configuration response data is received within the preset time window. For example, when the remote configuration instruction contains a band locking policy and security authentication parameters, the countdown window is adjusted to 45 seconds according to the instruction complexity, leaving sufficient time for the device side to complete radio frequency calibration and key negotiation.

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

[0155] Exemplarily, the configuration status query request adopts a dual composite transmission mechanism. The main request is sent through the currently active cloud platform interface (such as an HTTPS long connection), and the backup request switches to a low-power wide area network protocol (such as NB-IoT) for redundant transmission. The request message structure includes an instruction sequence number, a device identification feature hash value, and a 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 operations. After receiving the query request, the device side interrupts the ongoing data transmission task, prioritizes responding to the status query, and returns a response packet containing a snapshot of the current configuration process.

[0156] Step S800: Determine the exception type based on the feedback result of the configuration status query request. The exception type determination module maps to a predefined exception classification tree by parsing the status code and error log in the response packet.

[0157] For example, the status code "0xE2" corresponds to "security certificate chain verification failed" and is classified as a security authentication exception; the status code "0xD4" corresponds to "band resource unavailable" and is classified as a hardware compatibility exception. The stack trace information in the error log further assists in refining the exception subclass. For example, in the case of unavailable band resources, it distinguishes between two subtypes: "hardware filter failure" and "spectrum authorization expiration", providing accurate input for subsequent processing.

[0158] 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 resend the remote configuration instruction.

[0159] 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.

[0160] 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.

[0161] 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.

[0162] 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.

[0163] 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.

[0164] As an implementation manner, the updating process of the exception handling knowledge base may include the following steps:

[0165] Step S1110: Count the frequency of multiple triggering of the same abnormal type under the same device identification feature.

[0166] Exemplarily, frequency statistics can adopt the sliding time window counting method. For example, count the number of times the device identification feature "HW-5G-IND-01_89860121" triggers the "band resource unavailable" exception in the past 24 hours. The counting result is stored in the time series database, and the exception trigger rate is calculated through the exponentially weighted moving average algorithm. For example, if the number of exceptions per hour exceeds 3 times, it is determined as a high-frequency exception source. During the statistical process, the environmental feature set is associated with the configuration parameter group identifier to establish a multi-dimensional abnormal feature profile.

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

[0168] Exemplarily, the preset frequency threshold can be set hierarchically according to the device type. For example, it is 2 times per hour for industrial-grade devices and 5 times per hour for consumer-grade devices. The marking operation adds a "risk mark" identifier to the metadata area of the dynamic policy model, and multiplies the initial priority weight of the associated parameter group by the downgrading coefficient 0.7. For example, the parameter group with an original priority of 90 points is reduced to 63 points after being marked, resulting in its sorting position moving backward when generating the policy.

[0169] Step S1130: When the priority of the marked configuration parameter group is lower than the preset priority threshold, remove it from the configuration policy sequence and trigger an emergency retraining of the dynamic policy model; wherein, the emergency retraining includes: screening the configuration parameter groups irrelevant to the current abnormal type from the historical configuration data, and reconstructing the policy generation rule set based on the screening result.

[0170] Exemplarily, the preset priority threshold is set to 50 points. When the parameter group priority drops to 49 points, the system automatically removes it from the configuration policy sequence of the current device. The emergency retraining module loads the historical configuration data that has not triggered the same type of exception in the last 30 days, recalculates the condition branch weights of the policy generation rules using the random forest algorithm, and removes the decision paths strongly associated with the abnormal parameter group through pruning operations. For example, delete the rule "IF network access mode = 5G AND frequency band = 4.9GHz THEN enable high-power mode".

[0171] As an implementation, the method further includes a process of cross-model transfer learning, which can specifically include the following steps:

[0172] Step S1200: When it is detected that the device identification feature of the newly added eSIM device does not match any dynamic policy model, select the reference dynamic policy model with the highest device identification feature similarity from the dynamic policy model library.

[0173] Exemplarily, the similarity calculation adopts a hybrid feature weighting algorithm, where the similarity weight of the hardware model encoding accounts for 60%, the similarity of the firmware version sequence accounts for 30%, and the similarity of the operator code combination accounts for 10%. For example, the edit distance of the hardware encoding between the new device identification feature "HW-5G-IND-02_89860122" and the reference model "MODEL_5G_IND_V3" is 1 (similarity 95%), the difference in the firmware version is the minor version number (similarity 85%), and the coincidence degree of the operator code is 80%. The comprehensive similarity score is 0.6×95 + 0.3×85 + 0.1×80 = 90.5 points, making it the best reference model.

[0174] Step S1300: Extract the policy generation rule set of the reference dynamic policy model and remove the rule conditions strongly associated with the device identification features.

[0175] Exemplarily, strongly associated rule conditions refer to decision branches that directly reference specific hardware models or operator codes. For example, "IF hardware model encoding = HW-5G-IND-01 THEN enable proprietary radio frequency calibration" is identified as a device-specific rule. The removal operation parses the rule expression through a syntax analyzer, deletes the logical judgments containing the device identification feature fields, and retains general environmental feature conditions such as "average signal strength ≥ -70dBm" and "network access mode = 5G NSA".

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

[0177] Exemplarily, after the environmental feature set in the real-time configuration request data is feature-extracted, it drives the rule generation engine to create new conditional branches. For example, if it is detected that the standard deviation of the signal strength of the newly added device is stable within 5dB in the 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".

[0178] Step S1500: Package the filled policy generation rule set into a newly added dynamic policy model and add it to the dynamic policy model library.

[0179] Exemplarily, the encapsulation 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 executable code for a policy decision tree. After passing the consistency verification test, the new model 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.

[0180] Please refer to Figure 3 , which is a structural block diagram of the cloud platform 120 of the present invention. The cloud platform 120 includes a computing unit 1001, which can execute 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 into 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 through a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0181] 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 capable of inputting information into the cloud platform 120. The input unit 1006 can receive input digital or character information, and generate key signal inputs related to user settings and / or function controls of the server, and can include, but are 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 capable of presenting information, and can include, but are 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 are not limited to, a magnetic 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 can include, but are not limited to, a modem, a network card, an infrared communication device, a wireless communication transceiver, and / or a chipset, such as a BluetoothTM device, an 802.11 device, a WiFi device, a WiMax device, a cellular communication device, and / or the like.

[0182] The computing unit 1001 can be various general-purpose and / or special-purpose 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, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1001 executes the various methods and processes described above, such as the eSIM remote configuration management method based on a cloud platform. For example, in some embodiments, the eSIM remote configuration management method based on a cloud platform can be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 1008. In some embodiments, part or all of the computer program can be loaded and / or installed onto 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 eSIM remote configuration management method based on a cloud platform described above can be executed. Alternatively, in other embodiments, the computing unit 1001 can be configured to execute the eSIM remote configuration management method based on a cloud platform in any other suitable manner (e.g., by means of firmware).

[0183] The various embodiments of the systems and techniques described above in this document can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGA), application-specific integrated circuits (ASIC), application-specific standard products (ASSP), system-on-a-chip systems (SOC), complex programmable logic devices (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various embodiments 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 dedicated or general-purpose programmable processor, receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting the data and instructions to the storage system, the at least one input device, and the at least one output device.

[0184] 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, such that when the program codes are executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program codes can be executed entirely on the machine, partially on the machine, executed partially on the machine as an independent software package and partially on a remote machine, or executed entirely on a remote machine or server.

[0185] In the context of the present invention, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media would include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0186] In summary, the present invention provides a cloud platform, including: 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 to enable the at least one processor to execute the method provided in the above embodiments of the present invention.

[0187] It should be understood that various forms of the processes shown above can be used, with steps reordered, added, or deleted. For example, the steps recited in the present invention can be executed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions disclosed in the present invention can be achieved, and no limitation is made herein.

[0188] Although embodiments or examples of the present invention have been described with reference to the accompanying drawings, it should be understood that the above 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 only defined by the authorized claims and their equivalent scope. Various elements in the embodiments or examples can be omitted or replaced by their equivalent elements. In addition, the steps can be executed in a different order than described in the present invention. Further, the various elements in the embodiments or examples can be combined in various ways. Importantly, as technology evolves, many of the elements described herein can be replaced by equivalent elements that emerge 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; 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; 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 the dynamic policy model library according to the configuration response data; 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.

2. The method according to claim 1, 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.

3. The method according to claim 2, 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.

4. The method according to claim 3, 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.

5. The method according to claim 4, 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.

6. 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.

7. The method according to claim 6, 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.

8. 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.

9. 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 8.

Images