Operator network selection method, terminal device, readable storage medium and program product

Abstract

The embodiment of the invention provides an operator network selection method, terminal equipment, a readable storage medium and a program product, and relates to the technical field of mobile communication, the method comprises the following steps: receiving update information of a policy rule file issued by a server; the strategy rule file comprises an acquisition triggering rule and an operator switching rule, the acquisition triggering rule defines a condition for triggering acquisition of a network environment state, and the operator switching rule defines a logic rule for deciding whether to switch an operator network according to the network environment state; according to the updating information of the strategy rule file, updating the strategy rule file locally stored in the terminal equipment; when a condition meeting the definition of the acquisition triggering rule is monitored, acquiring the current network environment state of the terminal equipment; and based on an operator switching rule, according to the current network environment state, deciding whether to switch the currently used operator configuration file. According to the embodiment of the invention, the flexibility of switching the operator network is improved.

Description

Technical Field

[0001] This application relates to the field of mobile communication technology, and in particular to a method for selecting an operator network, a terminal device, a readable storage medium, and a program product. Background Technology

[0002] As eSIM technology matures, devices can store multiple operator profiles, providing a foundation for flexible mobile network switching. However, existing technologies have not fully realized their advantages. In complex scenarios, mobile network environments are dynamic and ever-changing. When roaming across regions, using the original operator profile can easily result in high roaming fees and high latency. In indoor and outdoor environments, as well as densely populated areas, network signal and load fluctuate in real time. The network quality and tariffs in areas with overlapping coverage from multiple operators also change over time, and traditional switching methods have significant limitations.

[0003] Existing technologies either rely on manual user decision-making, which is unfriendly to non-professional users and results in slow switching, making them unsuitable for scenarios such as cross-border roaming and unattended operation; or they are based on simple static rules, ignoring multi-dimensional key factors and leading to suboptimal choices; some solutions rely on cloud-based decision-making, which is susceptible to network latency and weak network environments. For business scenarios such as industrial IoT, connected vehicles, and cross-border logistics, there is an urgent need for devices to have autonomous sensing, dynamic decision-making, and local execution eSIM profile switching capabilities to meet the requirements of connection stability, transmission quality, and cost control. Therefore, a more flexible operator network switching solution is urgently needed. Summary of the Invention

[0004] This application provides a method for selecting an operator network, a terminal device, a readable storage medium, and a program product to alleviate or solve one or more technical problems existing in the prior art.

[0005] In a first aspect, embodiments of this application provide a method for selecting a carrier network. The method is applied to a terminal device with a built-in embedded universal integrated circuit card (eUICC) capable of storing multiple carrier configuration files. The method includes: Receive update information of policy rule files sent by the server; the policy rule files include collection trigger rules and operator switching rules, the collection trigger rules define the conditions for triggering the collection of network environment status, and the operator switching rules define the logical rules for deciding whether to switch operator networks based on the network environment status; The policy rule file stored locally on the terminal device is updated according to the update information in the policy rule file; If the conditions that meet the defined collection trigger rules are detected, the current network environment status of the terminal device is collected; Based on the operator switching rules, a decision is made on whether to switch the currently used operator configuration file according to the current network environment status.

[0006] In some embodiments of this application, the method is applied to the processor in the terminal device, and the step of collecting the current network environment status of the terminal device includes: Based on the network modulator in the terminal device, query multiple of the following network status parameters: network registration status parameter, data connection status parameter, signal strength parameter, location identifier parameter of the currently connected base station, and network connection speed. Based on the positioning module in the terminal device, query the current location information of the terminal device.

[0007] In some embodiments of this application, the detection of conditions that meet the definition of the collection triggering rule includes at least one of the following: The policy rule file stored locally has been updated; Triggered by a timer in the terminal device; The network modulator receives a first notification message; the first notification message is sent based on the Unrequested Result Code (URC) mechanism when a change in the network state parameters is detected. The system receives a second notification message from the positioning module; the second notification message is sent based on a change in the current positioning information of the terminal device.

[0008] In some embodiments of this application, the step of deciding whether to switch the currently used carrier configuration file based on the carrier switching rules and the current network environment status includes: Based on the sorting rules in the operator switching rules, the configuration files of each operator are sorted according to the current network environment status; Select the target configuration file from the multiple operator configuration files based on the sorting results; If the currently used operator configuration file is not the target configuration file, and the frequency of switching the operator configuration file exceeds a preset frequency threshold within a preset time period before the current time, then the current operator configuration file will continue to be used until the anti-shake termination condition defined in the operator switching rule is met, and the system will wait for the next detection of a condition that meets the conditions defined in the collection triggering rule; otherwise, the system will switch to using the target configuration file.

[0009] In some embodiments of this application, the network environment state includes multiple network state parameters, the sorting rule includes a weighted calculation model for calculating operator scores, the weighted calculation model includes each of the network state parameters used to calculate the operator scores, and a weighting factor for each of the network state parameters, and the sorting of each operator configuration file according to the current network environment state based on the sorting rule in the operator switching rule includes: Based on the weight calculation model, the operator score corresponding to each operator configuration file is calculated. The sorting results are obtained by ranking the operator ratings in the respective operator configuration files.

[0010] In some embodiments of this application, the sorting rule further includes attribute parameters configured by the server for each of the operators under at least one network condition, the attribute parameters including at least one of the following: tariff and stability parameters; the weight calculation model further includes the attribute parameters used to calculate the operator score and the weight factors of the attribute parameters, and before calculating the operator score corresponding to each operator configuration file based on the weight calculation model, the method further includes: Among at least one of the network conditions, a first network condition is determined to be met by the current network environment state; The weight calculation model is configured based on the attribute parameters set for each operator under the first network conditions.

[0011] In some embodiments of this application, the carrier switching rule further includes a carrier restriction list configured by the server for at least one network condition, and the step of selecting a target configuration file from multiple carrier configuration files according to the sorting result includes: Among at least one of the network conditions, determine a second network condition that the current network environment state meets; Based on the carrier restriction list configured under the second network condition, the disabled carrier profiles are removed from the sorting results.

[0012] Secondly, embodiments of this application provide a terminal device, including an eUICC, a memory, a processor, and a computer program stored in the memory. When the processor executes the computer program, it implements the method of any one of the embodiments of this application. The eUICC can store multiple operator configuration files.

[0013] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method of any one of the embodiments of this application.

[0014] Fourthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, implements any of the methods described in the embodiments of this application.

[0015] Based on the above-mentioned operator network selection method, terminal equipment, readable storage medium, and program product, this application has at least the following beneficial effects or advantages: This embodiment of the application receives update information from a policy rule file sent by a server. The policy rule file includes data collection trigger rules and carrier switching rules. The data collection trigger rules define the conditions for triggering the collection of network environment status, and the carrier switching rules define the logical rules for deciding whether to switch carrier networks based on the network environment status. Based on the update information in the policy rule file, the policy rule file stored locally on the terminal device is updated. If the conditions defined by the data collection trigger rules are detected, the current network environment status of the terminal device is collected. Based on the carrier switching rules, a decision is made on whether to switch the currently used carrier configuration file according to the current network environment status. This embodiment of the application improves the flexibility of switching carrier networks by sending updated policy rule files from the server and executing decisions locally on the terminal device.

[0016] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0017] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments according to this application and should not be construed as limiting the scope of this application.

[0018] Figure 1 This application illustrates a flowchart of a method for selecting an operator according to an embodiment of the present application. Figure 1 ; Figure 2 This illustration shows a schematic diagram of the system architecture used in an operator selection method provided in an embodiment of this application; Figure 3 This illustration shows a schematic diagram of the data collection principle of an operator selection method provided in an embodiment of this application; Figure 4 This application illustrates a flowchart of a method for selecting an operator according to an embodiment of the present application. Figure 2 ; Figure 5A block diagram of a terminal device provided in an embodiment of this application is shown. Detailed Implementation

[0019] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the concept or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0020] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following related technologies are optional solutions and can be arbitrarily combined with the technical solutions of the embodiments of this application, all of which fall within the protection scope of the embodiments of this application. It should be noted that the application scenarios or application examples provided in this application are for ease of understanding, and the embodiments of this application do not specifically limit the application of the technical solutions.

[0021] Furthermore, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0022] The following is an explanation of some of the technical terms that appear in this application: SIM: Subscriber Identity Module. It stores user identity information, authentication keys, and contact data. It can be inserted into or embedded in a device to enable access to mobile networks and identity authentication.

[0023] eSIM: Embedded Subscriber Identification Module. It's a SIM card soldered directly onto the device's motherboard, allowing for remote download of the operator's profile without needing to be removed.

[0024] Profile: The full English name is Mobile Network Operator Profile, a carrier configuration file. It's a "virtual SIM package" containing data such as IMSI, key, and authentication parameters. After downloading it to eUICC, it allows access to the corresponding carrier's network.

[0025] eUICC: Short for Embedded Universal Integrated Circuit Card. Specifically refers to a security chip that carries eSIM functionality, capable of storing multiple profiles and switching between them remotely.

[0026] IMSI stands for International Mobile Subscriber Identity. It is a globally unique 15-digit number that identifies a SIM card or eSIM profile, containing MCC, MNC, and MSIN (Mobile Country Code, Mobile Network Code, and Mobile Subscriber Identification Number). Networks use this number to identify the user's operator and account.

[0027] MCC: Mobile Country Code. A 3-digit number, for example, 460 represents China.

[0028] MNC: Mobile Network Code. A 2-3 digit number that, when combined with the MCC, uniquely identifies a mobile network operator. For example, 460-00 corresponds to China Mobile.

[0029] MSIN: Mobile Subscriber Identification Number. Assigned by the operator, it, along with MCC and MNC, forms the IMSI, used to uniquely identify a user within its network.

[0030] PLMN: Public Land Mobile Network. It is a globally unique identifier consisting of a country code and a network code, used to identify the connected operator's base station network.

[0031] Modem: A modem-demodulator is a communication module that modulates digital signals into radio waves for transmission and demodulates received wireless signals into digital data.

[0032] APDU: Application Protocol Data Unit. It is the smallest communication unit for command-response messages exchanged between the terminal and the SIM / eUICC, such as for operations like reading files and authentication.

[0033] CSQ stands for Cellular Signal Quality. It is usually represented by a value of 0–31 to indicate the current base station signal strength, with higher values ​​indicating better signal strength.

[0034] URC stands for Unsolicited Result Code. It refers to information proactively reported by the modem, such as incoming calls, SMS messages, and network status changes, without requiring prior commands from the host computer.

[0035] PRI: Priority. It's a parameter that determines the order of priority during profile selection, network registration, or service scheduling.

[0036] ICD: Short for IoT Connection Desk Server, it's a cloud platform deployed by operators or enterprises, responsible for eSIM remote download, lifecycle management, pricing policies, and device connection monitoring.

[0037] ICA: Short for ICD Agent, an IoT connectivity management client. It's a lightweight client running on the device, interfacing with the ICD platform to perform profile downloads, switching, and status reporting.

[0038] AT commands: The full English name is Attention Command. It's a 3GPP standardized modem command language, beginning with "AT" and ending with a carriage return. It's used to set up communication functions such as dialing, SMS, network registration, and SIM card reading / writing.

[0039] CellID: Short for Cell Identifier, it is a numerical identifier assigned by the base station controller to uniquely identify a cell within a location or tracking area. Terminals use the CellID to assist the network in location and handover.

[0040] APN: Access Point Name. It's the "gateway domain name" that a terminal must carry when activating a data bearer, used to tell the core network which packet data network (such as the Internet, enterprise private network, etc.) it should connect to.

[0041] CSIM: The full English name is Card SIM Toolkit Interface / Card SIM Application Toolkit Interface. In Chinese, it is usually directly called SIM card toolkit interface or card-side SIM application toolkit interface. It is the interaction channel between SIM cards and mobile devices defined by 3GPP.

[0042] Mobile Equipment (ME), in this application embodiment, refers to any terminal-side device equipped with a UICC / eUICC interface and capable of accessing a cellular network via a wireless interface. Examples include Industrial Internet of Things (IIoT) gateways, Customer Premises Equipment (CPE), cameras, Automated Guided Vehicles (AGVs), logistics forklifts, Telematics Boxes (T-Boxes), On-Board Units (OBUs), and Trackers.

[0043] The technical solutions of this application and how they solve the aforementioned technical problems will be described in detail below with specific embodiments. The listed specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0044] See Figure 1 The flowchart shown is a method for selecting operator networks. This method is applied to terminal devices with a built-in embedded general-purpose integrated circuit card (eUICC) that can store multiple operator configuration files. The method specifically includes steps 101-104.

[0045] Step 101: Receive the update information of the policy rule file sent by the server.

[0046] Step 102: Update the policy rule file stored locally on the terminal device according to the update information in the policy rule file.

[0047] Step 103: If the conditions that meet the collection trigger rule definition are detected, collect the current network environment status of the terminal device.

[0048] Step 104: Based on the operator switching rules, decide whether to switch the currently used operator configuration file according to the current network environment status.

[0049] This application can be applied to business scenarios such as Industrial Internet of Things (IIoT), Vehicle Networking (V2X), and cross-border logistics. For example, the terminal device can be an IIoT gateway / camera, an in-vehicle T-Box, etc. The terminal device is configured with an eUICC. It is understood that the eUICC can store multiple operator configuration files. The operator configuration files can be stored in the eUICC when the terminal device leaves the factory or downloaded and imported into the eUICC storage after the terminal device leaves the factory. This application does not make specific limitations. The operator configuration files stored in the eUICC need to be activated before use. The operator configuration file is a configuration file generated by the operator for the terminal and contains complete information required for network access. The operator configuration file contains core parameters such as IMSI (Integrated Product Identity) and Ki (Authentication Key) that can prove the legitimate identity of the terminal device and authenticate through the operator's network. Activating the operator configuration file is to initiate registration with the operator and apply to the operator to enable the above-mentioned core parameters.

[0050] An example system architecture of this application embodiment is as follows: Figure 2 As shown, the system includes server-side and terminal devices, as referenced. Figure 2 The server is an IoT Connection Desk Server (ICD) in this embodiment. The ICD is the policy formulation center, event control center and permission management center of the entire system, providing policy support, event monitoring and security for the intelligent operation of the client.

[0051] A client corresponding to the server can be installed in the terminal device, namely the Internet of Things Connection Management Client (ICDAgent, referred to as ICA in this embodiment). The ICA client runs on the terminal device to implement the operator network selection method provided in this embodiment. The ICA mainly undertakes the functions of status acquisition, policy decision-making and policy execution. It is the core intermediate layer connecting the hardware layer and ICD, realizing intelligent management and control of eUICC in the terminal device.

[0052] The hardware layer is the hardware layer of the terminal device, including but not limited to: positioning modules such as GPS / BeiDou, network modulators such as 2G, 3G, 4G, 5G, etc., and eUICC. The hardware layer can realize functions such as positioning, communication, and remote management of communication cards. Through active reporting or passive collection, it transmits various status information of the terminal device to the ICA status acquisition module, providing basic hardware support for status acquisition, decision-making, and execution. It can be understood that the ICA client can be run by the terminal device's processor, and the processor and hardware layer transmit data through an interface to realize information transfer, thereby cooperating to implement the operator network selection method provided in the embodiments of this application.

[0053] The server can design different policy rule files for each client, or it can design a common policy rule file for all clients. When the server determines that a client needs to update the policy rule file, it can push update information to the client on the terminal device. The update information can be incremental or full update content of the policy rule file. The client receives the update information of the policy rule file sent by the server and updates the policy rule file stored locally on the terminal device according to the update information. Optionally, the policy rule file stored locally on the terminal device can be stored in a pre-specified location. This application embodiment does not specifically limit the storage method or storage location; it can be designed as needed.

[0054] The policy rule file includes: data collection trigger rules and carrier switching rules. Data collection trigger rules define the conditions that trigger the terminal device to collect network environment status locally; that is, under what circumstances the terminal device starts collecting network environment status, such as timed collection intervals and collection trigger conditions. Network environment status refers to status information related to the terminal device's network environment, such as location information from the positioning module, base station location information, base station connection switching, network registration status, data link status, network signal strength changes, etc. Carrier switching rules define the logical rules for deciding whether to switch carrier networks based on network environment status. That is, the terminal device can trigger the collection of network environment status according to the data collection trigger rules, and then, based on the carrier switching rules, determine whether the current network environment status requires switching carrier networks. If a switch to the target carrier network is required, the target carrier configuration file corresponding to the target carrier network is used; otherwise, if no switch is required, the current carrier configuration file is maintained until the next data collection of network environment status is triggered according to the data collection trigger rules, and the next round of decision-making is performed.

[0055] refer to Figure 2 Given the system architecture, an example of the operator network selection method in this application embodiment is as follows: First, the ICA client on the terminal device (which can communicate via a network modulator) receives the policy rule file from the ICD server. The ICD server is the policy formulation center, capable of pre-editing policy rules based on the terminal device's application scenario, such as cross-border roaming or industrial IoT scenarios. The policy rule file contains data collection trigger rules and carrier handover rules. Upon receiving the updated information, the terminal device overwrites the locally stored old policy rule file, ensuring that the decision-making basis remains synchronized with the updated policy on the server, thus preventing handover inaccuracies due to policy rule lag.

[0056] Next, the terminal device's ICA client continuously monitors whether the conditions defined by the data collection trigger rules are met. The design of the data collection trigger conditions can adopt a dual-mode collaborative mechanism for status data collection, including various scenarios such as timed triggering and event triggering, to ensure the timeliness and accuracy of network status data collection. When the data collection trigger conditions are detected to be met, the terminal device activates the network environment status collection module, interacting with the hardware layer to collect network environment status. The collection scope includes, but is not limited to, core parameters such as network registration status, signal strength, and data connection status. These parameters provide the basic data support for subsequent decision-making.

[0057] Then, the decision module of the terminal device's ICA client, based on the operator switching rules and the collected network environment status, decides whether to switch operator configuration files. The decision module, based on the server-side policy, comprehensively assesses the current network status to determine the optimal operator configuration file.

[0058] Finally, if a switch is required, the execution module of the terminal device's ICA client, based on the decision result, controls the hardware layer's eUICC to activate the target profile and disable the original profile, thus achieving the switch of the operator network. For example, when cross-border logistics equipment enters another country, the location information collected by the terminal device and the PLMN identifier match the server's preset cross-border scenario triggering conditions. The decision module determines that the current roaming operator's tariff is too high based on the switching rules, thereby triggering a switch to the current country's local operator profile, adapting to the application scenario of automatic cross-regional roaming adaptation. The entire process requires no manual intervention from the user and does not rely on real-time cloud decision-making, fully realizing the core objectives of autonomous perception, dynamic decision-making, and local execution.

[0059] This application's embodiments significantly improve the flexibility and adaptability of operator network handover through a collaborative design of server-side policy distribution and terminal-side local decision-making. The terminal, based on eUICC's multi-configuration file storage capability and coupled with dynamically updated server-side policy rules, can autonomously respond to changes in the network environment without manual user intervention. This solves the problems of traditional manual handover, which requires high levels of expertise, is cumbersome, and has a delayed response time. It is particularly suitable for scenarios such as unattended industrial IoT devices and high-speed mobile vehicle-to-everything (V2X) terminals. Flexible setting of collection trigger rules ensures the real-time and accuracy of network status data, providing reliable support for decision-making and avoiding suboptimal choices due to information lag under static rules. The standardized design of operator handover rules enables the terminal to dynamically adjust its handover logic according to different scenarios, adapting to complex network environments such as cross-regional roaming and overlapping multi-operator coverage. This ensures both communication stability and data transmission quality while controlling costs through reasonable operator selection. Meanwhile, the local decision-making mode reduces reliance on the cloud, avoiding network latency and failures in weak network environments caused by cloud decision-making. It ensures fast and stable network switching in complex scenarios such as remote areas and high-speed mobile environments, fully leveraging the flexibility advantages of eSIM multi-profile.

[0060] In some embodiments of this application, the method provided in this application can be executed by the processor in the terminal device. Accordingly, the step of collecting the current network environment status of the terminal device includes: querying multiple of the following network status parameters based on the network modulator in the terminal device: network registration status parameter, data connection status parameter, signal strength parameter, location identifier parameter of the currently connected base station, and network connection speed; and querying the current location information of the terminal device based on the positioning module in the terminal device.

[0061] This embodiment further provides the implementation method of the network environment status collection subject and specific collection content. Based on the collaborative architecture of the hardware layer and the ICA status collection module, it ensures the comprehensiveness and accuracy of the collected data. The collection process is led by the processor in the terminal device, which coordinates the network modulator and positioning module of the terminal device hardware layer to realize data collection.

[0062] Regarding network status parameter acquisition, the processor obtains various key parameters through the network modulator. The specific implementation is as follows: It queries network registration status parameters, including unregistered, successfully registered, and successfully roaming registered status, corresponding to monitoring scenarios of network registration status changes, by sending AT commands to the modulator; it queries data connection status parameters, including whether the data link is disconnected or connected; it queries signal strength parameters, i.e., the CSQ value, to quantify the strength of the base station signal received by the terminal; it obtains the location identifier parameters of the currently connected base station through AT commands, including CellID, MCC, and MNC, which are core components of auxiliary positioning data, used to determine operator affiliation and assist in positioning; and it obtains network connection speed by pinging a pre-set list of servers to evaluate data transmission efficiency.

[0063] Regarding location information collection, the processor can query current location information through a positioning module such as GPS or BeiDou. The positioning module is responsible for positioning functions, providing accurate location information to the terminal device, which can be used for location-based policy decisions or device positioning management. Specific collection mechanisms include, but are not limited to: the positioning module can periodically respond to the processor's query commands and report location information, or it can proactively report when the location changes, improving the real-time performance of positioning data. For example, the current location can be detected every 10 seconds, or when a cross-border logistics device enters country B from country A, the positioning module will monitor and proactively report changes in latitude and longitude. The processor combines this positioning information with the MCC parameters of the base station (e.g., country B's MCC is xxx) to accurately determine the country where the terminal device is located, providing a basis for subsequent switching of local operator configuration files.

[0064] The collected network status parameters and location information are used to construct complete network environment status data. The collection of multi-dimensional network status parameters can cover dimensions such as network access, signal quality, data transmission, and base station affiliation, avoiding the one-sidedness of decision-making caused by the collection of a single parameter, and can comprehensively reflect the current real status of the network.

[0065] In some embodiments of this application, the condition that meets the definition of the data collection triggering rule is detected, including at least one of the following: The locally stored policy rule file has been updated; Triggered by a timer in the terminal device; Received the first notification message sent by the network modulator; the first notification message is sent based on the Unrequested Result Code (URC) mechanism when a change in network state parameters is detected; The system receives a second notification message from the positioning module; the second notification message is sent based on a change in the current positioning information of the terminal device.

[0066] This embodiment designs a dual-mode collaborative mechanism for the status acquisition function to implement the acquisition triggering rules. By triggering multiple scenarios, it ensures the timeliness and comprehensiveness of network environment status acquisition and avoids the switching lag problem caused by untimely acquisition.

[0067] refer to Figure 3 The first trigger scenario is update-triggered data collection. This occurs when the local policy rule file is updated, and the ICD issues a new policy file, triggering real-time status data collection. When the server adjusts policy rules based on business needs, such as updating tariff thresholds for cross-border scenarios or adjusting signal strength trigger conditions, the terminal device will immediately trigger network environment status data collection after completing the local policy file update. This ensures that the new policy takes effect as soon as possible, allowing decisions to be made based on the latest network data and avoiding decision-making biases caused by asynchronous rule updates and data collection. For example, if the server adjusts the signal strength threshold for industrial scenarios from CSQ greater than or equal to 15 to CSQ greater than or equal to 18, the terminal device will immediately collect the current signal strength after updating the policy file. If the current signal strength is 16, it can trigger a switch to the operator's configuration file with a stronger signal based on the new rule.

[0068] refer to Figure 3 The second triggering scenario is timer-based triggering, which uses a timer to periodically send commands to collect device status data. The terminal can automatically trigger data collection based on the sampling intervals set in the server-side policy, such as a 5-second interval for signal quality sampling and a 10-second interval for network connection speed sampling. This ensures continuous monitoring of network status even without event triggers, avoiding missing dynamic changes in the network environment. This timed collection mechanism allows for flexible interval settings based on the characteristics of different parameters. For example, a shorter sampling interval is set when signal strength fluctuates rapidly, while a longer interval is set when operator priority changes slowly, ensuring data real-time performance while reducing terminal power consumption.

[0069] refer to Figure 3 The third triggering scenario involves receiving a first notification message from the network modulator based on the URC mechanism. This allows the network modulator to proactively notify the mobile network of changes in its status. When the network modulator detects a change in network status parameters—for example, a change in network registration status from successful to unregistered, a sudden increase in signal strength, base station switching, or data link disconnection—it proactively sends a notification message to the processor via the URC mechanism, triggering the terminal device to immediately collect the latest network status. Alternatively, based on the network modulator's PING mechanism, if the network connection speed drops below a threshold, data collection is triggered. For instance, if the terminal device is in a densely populated area and the signal strength suddenly drops from CSQ 22 to CSQ 8, the network modulator triggers data collection via a URC message, allowing the terminal device to quickly respond and decide whether to switch operators.

[0070] refer to Figure 3 The fourth trigger scenario involves receiving a second notification message from the positioning module, employing a design where the positioning module proactively reports its current location information after a change in location. When the positioning module detects a significant change in the terminal device's location, such as cross-border movement or movement from indoors to outdoors, it proactively sends a notification message to trigger data collection. This allows the terminal device to promptly obtain the network environment status of the new location, providing a basis for scenario-based switching. For example, when a vehicle-to-everything (V2X) terminal moves from urban roads into a remote area, after the positioning module reports the location change, the terminal device immediately collects signals from surrounding operators and switches to an operator profile with more stable coverage.

[0071] This embodiment improves the timeliness, comprehensiveness, and flexibility of network environment status collection through the design of multi-dimensional collection trigger conditions, providing a solid foundation for subsequent accurate decision-making. The policy file update trigger mechanism synchronizes rules and data, avoiding decision-making delays caused by policy adjustments and ensuring that server-side policies can be quickly implemented and take effect. The timer-based trigger mechanism ensures continuous monitoring of network status, avoiding missing network changes when no events occur, and allows for flexible setting of intervals based on parameter characteristics, achieving a balance between power consumption and real-time performance. The event-driven mode of URC mechanism triggering and location change triggering can quickly respond to sudden changes in network status and geographical location, reducing handover latency, especially suitable for high-speed mobile scenarios and scenarios with frequent network fluctuations. The coordinated use of multiple trigger scenarios allows the terminal to flexibly adjust the collection timing according to different situations, ensuring both data real-time performance and accuracy while avoiding resource waste caused by invalid collection. This significantly improves the terminal's adaptability to dynamic network environments, providing key support for achieving fast and accurate operator network handover, and effectively solving the problems of delayed response and poor adaptability in traditional solutions.

[0072] In some embodiments of this application, the decision to switch the currently used operator configuration file based on the operator switching rules and the current network environment status includes: sorting the operator configuration files according to the current network environment status based on the sorting rules in the operator switching rules; selecting a target configuration file from multiple operator configuration files according to the sorting results; if the currently used operator configuration file is not the target configuration file, and the frequency of switching operator configuration files exceeds a preset frequency threshold within a preset time period before the current time, then the current operator configuration file is maintained until the anti-jitter termination condition defined in the operator switching rules is met, and the system waits for the next detection of a condition that meets the collection trigger rule definition; otherwise, the system switches to using the target configuration file.

[0073] To improve the rationality of handover decisions and the stability of network connections, a sorting mechanism and anti-jitter control are introduced to address the decision-making and handover process based on operator configuration files.

[0074] First, the terminal device sorts the configuration files of each operator based on the sorting rules in the operator handover rules and the current network environment status. The terminal device can comprehensively consider network status parameters such as network registration status, signal strength, and data transmission speed to prioritize all stored operator configuration files and select the optimal target configuration file. For example, in an area with overlapping coverage from multiple operators, if the terminal device detects that operator A has a signal strength (CSQ) of 23 and a network connection speed of 2Mbps, while operator B has a signal strength (CSQ) of 18 and a network connection speed of 1.5Mbps, according to the sorting rules, operator A's configuration file has the highest ranking and is therefore the target configuration file.

[0075] Next, the terminal device determines whether the currently used configuration file is the target configuration file. If they match, the current network connection is maintained without switching; if they do not match, the anti-jitter judgment process begins. The anti-jitter control design follows the technical concept of anti-jitter delay switching parameters, aiming to avoid frequent invalid switching caused by instantaneous fluctuations in network signal and ensure communication stability. The terminal device can count the switching frequency within a preset time period before the current moment. If the switching frequency exceeds a preset frequency threshold, such as more than 2 switchings within 1 minute, it is determined to be a frequent switching state. In this case, the terminal device will maintain the current configuration file until the anti-jitter termination condition is met, such as waiting for a 3-second signal stabilization period, and then re-evaluating after the next acquisition trigger; if the switching frequency does not exceed the threshold, it directly switches to the target configuration file.

[0076] For example, in indoor-outdoor handover scenarios, when a terminal device moves from indoors to outdoors, the signal strength fluctuates instantaneously, potentially causing frequent switching of the target configuration file between operator A and operator B. In this case, the anti-jitter mechanism activates, and the terminal device maintains the current configuration file until the signal stabilizes, avoiding communication interruptions or data transmission lag caused by frequent switching. If the terminal device is in a cross-border scenario, the network environment is stable, the target configuration file is clearly defined (i.e., the local operator's configuration file), and the recent switching frequency is low, then the handover is performed directly to ensure rapid adaptation to the local network.

[0077] Through the coordinated design of a sorting mechanism and anti-jitter control, the scientific nature, stability, and reliability of operator network handover are effectively improved. The application of sorting rules enables terminal devices to select the optimal operator profile based on objective network environment conditions, avoiding suboptimal selections under traditional static rules and ensuring network connection quality and efficiency. The anti-jitter control mechanism successfully solves the problem of frequent handovers caused by instantaneous network signal fluctuations, reducing communication interruptions, data loss, and power waste during handover, ensuring communication continuity and stability, especially suitable for scenarios with frequent network fluctuations such as indoor / outdoor handovers, densely populated areas, and tunnel entry / exit. The entire process requires no user intervention and does not rely on real-time cloud decision-making; it is entirely executed locally by the terminal device, ensuring rapid response and autonomous controllability during handover. It is suitable for scenarios with stringent communication stability requirements, such as industrial IoT and vehicle-to-everything (V2X) networks, fully leveraging the flexibility of eSIM's multi-profile capabilities and solving the problems of blind and unstable handovers in traditional solutions.

[0078] In some embodiments of this application, the network environment status includes multiple network status parameters, and the sorting rules include a weighted calculation model for calculating operator scores. The weighted calculation model includes each network status parameter used to calculate the operator score and a weight factor for each network status parameter. Based on the sorting rules in the operator handover rules, each operator configuration file is sorted according to the current network environment status, including: calculating the operator score corresponding to each operator configuration file based on the weighted calculation model; and sorting the configuration files according to their operator scores to obtain a sorting result.

[0079] This embodiment introduces a weight calculation model for the sorting rules of operator configuration files, and adopts ICD dynamic weight parameters and allocation strategies to achieve scientific quantitative evaluation of multi-dimensional parameters and improve the accuracy of sorting results.

[0080] Network environment status includes multiple network status parameters, including but not limited to collected parameters such as network registration status, signal strength, and network connection speed. These parameters form the basis of the weighted calculation model. Each parameter is assigned a corresponding weight factor, which is preset and distributed by the server (ICD) based on scenario requirements, reflecting the importance of different parameters in decision-making. For example, in industrial IoT scenarios, data transmission stability is crucial; the server might assign a high weight (e.g., 0.4) to signal strength and a medium weight (e.g., 0.3) to network connection speed. In cross-border scenarios, cost control is a core requirement; if cost parameters are subsequently introduced, the server will adjust the weight allocation accordingly.

[0081] When calculating operator scores, the terminal quantifies the network status parameters corresponding to each operator profile according to the rules of the weighted calculation model, and then calculates the weighted total score by combining the weighting factors. For example, for operator C's profile, the quantized value of the collected signal strength parameter is 85 out of 100, with a weighting factor of 0.4; the quantized value of the network connection speed parameter is 90, with a weighting factor of 0.3; and the quantized value of the data connection status parameter is 100, with a weighting factor of 0.3. Then, the operator's score is 85 multiplied by 0.4 plus 90 multiplied by 0.3 plus 100 multiplied by 0.3, which equals 89 points. The terminal performs the same scoring calculation process for all operator profiles to obtain the operator score for each profile.

[0082] Terminal devices sort all configuration files according to operator scores from highest to lowest, resulting in a ranking. The configuration file with the highest score becomes the target configuration file. By quantifying scores and assigning weights, the bias of evaluating a single parameter is avoided, making the ranking results more closely reflect actual scenario requirements. For example, operator D may have a high signal strength score of 90 but a low network connection speed score of 70, while operator E may have a medium signal strength score of 80 but a high network connection speed score of 95. Through weight calculation, if the network connection speed has a higher weight, operator E's score may surpass operator D's, making it the target configuration file. This ensures that the ranking results conform to the server's preset strategy.

[0083] This embodiment achieves rationality and adaptability in operator profile sorting by introducing a weighted calculation model. Comprehensive evaluation of multiple network state parameters avoids biased selection caused by single-parameter judgment, comprehensively reflecting the actual quality of the operator's network. Flexible configuration of weighting factors allows the sorting rules to adapt to the core needs of different scenarios. The server can adjust the weights of each parameter according to the priority orientation of different scenarios such as Industrial IoT, IoV, and cross-border logistics, achieving different strategy objectives such as stability priority, speed priority, and cost priority, solving the problem of poor adaptability of traditional static rules. Quantitative scoring and ordered sorting make the decision-making basis more objective and transparent, avoiding bias caused by subjective judgment and ensuring that the terminal can select the optimal operator profile. The synergy between the weighted calculation model and the server-side strategy enables the terminal's decision logic to flexibly respond to the server's strategy adjustments, improving the scalability and scenario adaptability of the entire system, providing core technical support for achieving dynamic and accurate operator network switching, and further releasing the flexibility advantages of eSIM multi-profile.

[0084] In some embodiments of this application, the sorting rules also include attribute parameters configured by the server for each operator under at least one network condition. The attribute parameters include at least one of the following: tariff and stability parameters. The weight calculation model also includes attribute parameters used to calculate operator scores and weight factors for the attribute parameters.

[0085] The ranking rules now include attribute parameters configured by the server for at least one network condition. These attribute parameters are predefined by the server and sent to the terminal, rather than being measured in real time by the terminal. They include core dimensions such as pricing and stability parameters, and are completely consistent with the definitions of pre-configured policy attribute parameters. Pricing parameters represent the operator's usage costs, such as unit data traffic fees and roaming package fees. The server can preset different pricing levels for different operators based on cooperation agreements and package types, such as low, medium, and high pricing. Stability parameters represent the long-term reliability of the operator's network. The server presets stability ratings based on the operator's historical network operation data and service level agreements, such as high stability, medium stability, and low stability. These parameters are inherent attributes or service agreements of the operator and are unlikely to change in the short term. This embodiment introduces pre-configured static attribute parameters from the server into the weight calculation model, combining them with the real-time network environment status collected by the terminal device, thus enriching the dimensions of the ranking rules. The addition of static attribute parameters compensates for the limitations of real-time measurement data from the terminal, incorporates key decision-making factors such as tariff costs and long-term stability into the evaluation system, avoids the one-sidedness of decision-making caused by relying solely on dynamic network status, and makes the selection of the optimal operator more in line with overall usage needs.

[0086] Furthermore, in some embodiments of this application, before calculating the operator score corresponding to each operator's configuration file based on the weight calculation model, the method further includes: determining a first network condition that the current network environment state meets in at least one network condition; configuring the weight calculation model according to the attribute parameters set for each operator under the first network condition.

[0087] In some implementations, the policy rule file issued by the server may include different weight calculation models configured for different network conditions. For example, the server may preset different weight factors for the weight calculation models for different network conditions, and after the terminal device determines that the first network condition is met, it automatically loads the corresponding weight configuration to calculate the operator score.

[0088] The terminal device can determine the first network condition that its current network environment status meets from at least one network condition preset by the server, and then select a weight calculation model that matches the current first network condition to perform calculations. Network conditions can be divided based on multi-dimensional network environment parameters of the network environment status. Specific division rules can be set by the server, for example, providing corresponding ranges of network environment parameters for cross-border roaming scenarios, indoor weak signal scenarios, and densely populated scenarios. For instance, if the terminal device determines that it is currently in a cross-border roaming scenario (i.e., the first network condition) based on location information and PLMN identifier, it will then call the operator attribute parameters configured by the server for this scenario.

[0089] If the current network environment meets multiple network conditions, in some implementations, the server can configure priorities for different weight calculation models and select the weight calculation model with the highest priority to perform the calculation. In other implementations, the server can configure rules for selecting weight calculation models in the policy rule file. For example, when determining network conditions, different network conditions may use different dimensions of network environment parameters. The server can select the network condition with the most dimensions used in the determination and select the weight calculation model that matches the network condition to perform the calculation, thereby improving the comprehensiveness of network condition determination.

[0090] For example, in cross-border roaming scenarios, the weighting factor for tariff parameters is set to 0.5, the weighting factor for stability parameters to 0.3, and the weighting factor for signal strength parameters to 0.2. When calculating operator scores, the terminal quantifies the server-preset tariff level and stability rating, and then performs a weighted calculation based on the real-time collected signal strength parameters. In industrial IoT scenarios, the weighting factor for stability parameters is set to 0.6, the weighting factor for tariff parameters to 0.2, and the weighting factor for signal strength parameters to 0.2, ensuring that the ranking results prioritize stable and reliable operators. This scenario-based weighting configuration makes the ranking rules more aligned with actual needs and improves the accuracy of decision-making.

[0091] This embodiment provides different weight calculation model designs for different network environment scenarios, further improving the scientific nature and scenario adaptability of the ranking rules. The scenario-based weight configuration mechanism enables terminal devices to adaptively adjust their decision orientation according to different network conditions. For example, in cross-border scenarios, priority can be given to controlling tariffs, while in industrial scenarios, priority can be given to ensuring stability, solving the problem that traditional solutions with single rules cannot adapt to diverse scenarios.

[0092] In some embodiments of this application, the operator switching rule further includes an operator restriction list configured by the server for at least one network condition, and selecting a target configuration file from multiple operator configuration files according to the sorting result, including: determining a second network condition that the current network environment state meets in at least one network condition; and removing disabled operator configuration files from the sorting result according to the operator restriction list configured under the second network condition.

[0093] The carrier restriction list is used to limit the carrier networks that can be used in different scenarios. The list can explicitly mark disabled carrier profiles, such as those with high tariffs, unreliable services, or unauthorized carriers. This static restriction avoids selecting carriers that users do not want. The carrier restriction list can be implemented as a whitelist or a blacklist. This embodiment introduces a carrier restriction list based on the sorting results to further optimize the selection logic of the target profile. The server can pre-configure the carrier restriction list for at least one network condition and distribute it in the carrier switching rules within the policy rule file. The server can set restriction rules according to scenario characteristics and business needs. For example, in cross-border roaming scenarios, it can disable roaming carriers with excessively high tariffs; in industrial IoT scenarios, it can disable carriers with low stability ratings; and in sensitive area scenarios, it can disable unauthorized carriers, ensuring the security, compliance, and economy of network switching.

[0094] The terminal device can determine whether it meets the network conditions of a certain operator's restriction list based on the current network environment status. If it meets the second network conditions, the terminal device will remove the disabled operator configuration files from the sorting results according to the operator restriction list under the second network conditions.

[0095] The specific implementation of the second network condition classification rule can refer to the first network condition classification rule mentioned above. Based on the scenario classification preset by the server, the terminal device performs scenario matching by collecting network environment status, such as location information, PLMN identifier, signal environment, etc. For example, if the location information collected by the terminal device shows that it is in a remote area and the signal strength is generally weak, which meets the server's preset remote area weak signal scenario, i.e., the second network condition, then the corresponding operator restriction list under this scenario is called.

[0096] For example, if operator F has the highest score in the ranking results, but is disabled by the second network condition restriction list (e.g., insufficient service coverage in remote areas), the terminal device will remove it from the ranking results and select operator G, which has the second highest score and is not disabled, as the target configuration file. If the top three operators in the ranking results are all disabled, the terminal device can continue to backtrack the ranking results until it finds an operator configuration file that is not disabled. If all operator configuration files are disabled, the terminal will trigger a backup mechanism to maintain the current network connection and report the anomaly to the server, ensuring uninterrupted communication. The entire process ensures both the optimality of the ranking results and scenario-based security control through the restriction list, which is highly consistent with the design concept of fine-grained control of policy parameters.

[0097] This embodiment achieves secure control and precise adaptation of operator network switching through a collaborative design of operator restriction lists and scenario matching, further enhancing the rationality and reliability of decision-making. The operator restriction list is uniformly configured by the server, limiting the range of usable operators according to scenario requirements. This prevents terminals from switching to unauthorized, high-cost, or unreliable operators, ensuring the security, compliance, and economy of network use, especially suitable for scenarios with special requirements for operator selection, such as cross-border roaming and sensitive areas. The scenario matching mechanism based on network conditions ensures the accurate application of the restriction list, enabling terminals to invoke corresponding restriction rules based on the current network environment, avoiding switching restrictions caused by rule abuse. The design of removing banned operators based on the ranking results retains the optimal selection logic of the weight calculation model while mitigating potential risks through the restriction list, achieving a balance between optimal selection and security compliance. The entire mechanism requires no user intervention, relying entirely on local terminal execution and server-side policy collaboration, improving the system's automation and intelligence, solving the problem of traditional solutions lacking scenario-based security control, providing security guarantees for network switching in complex scenarios, and further enhancing the practicality and adaptability of the solution.

[0098] refer to Figure 4This is a flowchart illustrating an example of a carrier network selection method in an embodiment of this application. It assumes the terminal device is a cross-border logistics vehicle terminal with a built-in eUICC, an ICD server, and runs an ICA client. The hardware layer includes a GPS positioning module, a 4G modem, and an eUICC. The ICA client includes a decision module and an execution module. The decision module first determines whether it is the first time the device is powered on. If it is, it queries the eUICC status using the AT+CSIM command to confirm the storage and activation status of each carrier's configuration file, performs a mobile network availability check, performs mobile network initialization processing, and then checks the validity of the handover result. If the result is valid, it triggers the corresponding subsequent actions; if the result is invalid, it marks it as an abnormal state. If it is not the first time the device is powered on, it reads the previous mobile network handover result, matches the current network region using the PLMN identifier, and similarly checks the validity of the handover result. If valid, it triggers subsequent actions; if invalid, it marks it as an abnormal state. Next, the anti-shake control phase begins. If frequent switching is detected, switching is temporarily suspended until the anti-shake timeout expires. If there are no non-frequent switching instances, an abnormal state is assessed. If an abnormal state exists, anomaly recovery is performed, followed by the configuration file selection process. Otherwise, the configuration file selection process proceeds directly. In the configuration file selection process, the acquisition status is analyzed first. Network connection speed is measured using pingICD's preset server list in priority order. Based on the status and the attribute parameters corresponding to each configuration file, all configuration files are pre-sorted. The pre-sorted results undergo secondary testing to generate a candidate configuration file list. Finally, the target configuration file is determined, and the execution module sends an activation command to eUICC to activate the target configuration file while disabling the currently used configuration file. AT commands are used to configure the APN parameters of the PLMN corresponding to the target configuration file for the Modem, completing the switching and other related processing, and recording the switching result. If no network signal is detected after switching, the execution module will trigger re-acquisition according to the resampling time after the eUICC configuration file switching without network access, as set in the policy rules. If the switching is normal, it waits for the next trigger.

[0099] Figure 5 This is a block diagram of a terminal device used to implement embodiments of this application. Figure 5 As shown, the terminal device includes a memory 501 and a processor 502. The memory 501 stores a computer program that can run on the processor 502. The terminal device also includes an eUICC 504, which can store multiple operator configuration files. When the processor 502 executes the computer program, it implements the method described in the above embodiments. The number of memories 501 and processors 502 can be one or more. In a specific implementation, the terminal device may also include a communication interface 503 for communicating with external devices and performing data exchange and transmission.

[0100] In practical implementation, if the memory 501, processor 502, and communication interface 503 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0101] Optionally, in a specific implementation, if the memory 501, processor 502 and communication interface 503 are integrated on a single chip, the memory 501, processor 502 and communication interface 503 can communicate with each other through an internal interface.

[0102] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in this application.

[0103] This application provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in this application.

[0104] This application also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.

[0105] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.

[0106] It should be understood that the aforementioned processor can be a CPU (Central Processing Unit), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0107] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0108] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0109] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0110] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0111] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0112] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0113] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0114] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0115] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for selecting an operator network, characterized in that, The method is applied to a terminal device with a built-in embedded general-purpose integrated circuit card (eUICC) and the eUICC can store multiple operator configuration files. The method includes: Receive update information of policy rule files sent by the server; the policy rule files include collection trigger rules and operator switching rules, the collection trigger rules define the conditions for triggering the collection of network environment status, and the operator switching rules define the logical rules for deciding whether to switch operator networks based on the network environment status; The policy rule file stored locally on the terminal device is updated according to the update information in the policy rule file; If the conditions that meet the defined collection trigger rules are detected, the current network environment status of the terminal device is collected; Based on the operator switching rules, a decision is made on whether to switch the currently used operator configuration file according to the current network environment status.

2. The method according to claim 1, characterized in that, The method is applied to the processor in the terminal device, and the step of collecting the current network environment status of the terminal device includes: Based on the network modulator in the terminal device, query multiple of the following network status parameters: network registration status parameter, data connection status parameter, signal strength parameter, location identifier parameter of the currently connected base station, and network connection speed. Based on the positioning module in the terminal device, query the current location information of the terminal device.

3. The method according to claim 2, characterized in that, The detected conditions that meet the definition of the data collection triggering rule include at least one of the following: The policy rule file stored locally has been updated; Triggered by a timer in the terminal device; The network modulator receives a first notification message; the first notification message is sent based on the Unrequested Result Code (URC) mechanism when a change in the network state parameters is detected. The system receives a second notification message from the positioning module; the second notification message is sent based on a change in the current positioning information of the terminal device.

4. The method according to claim 1, characterized in that, The step of deciding whether to switch the currently used carrier configuration file based on the carrier switching rules and the current network environment status includes: Based on the sorting rules in the operator switching rules, the configuration files of each operator are sorted according to the current network environment status; Select the target configuration file from the multiple operator configuration files based on the sorting results; If the currently used operator configuration file is not the target configuration file, and the frequency of switching the operator configuration file exceeds a preset frequency threshold within a preset time period before the current time, then the current operator configuration file will continue to be used until the anti-shake termination condition defined in the operator switching rule is met, and the system will wait for the next detection of a condition that meets the conditions defined in the collection triggering rule; otherwise, the system will switch to using the target configuration file.

5. The method according to claim 4, characterized in that, The network environment status includes multiple network status parameters. The sorting rule includes a weighted calculation model for calculating operator scores. The weighted calculation model includes each of the network status parameters used to calculate the operator scores and a weighting factor for each of the network status parameters. The sorting of each operator configuration file based on the sorting rule in the operator handover rule, according to the current network environment status, includes: Based on the weight calculation model, the operator score corresponding to each operator configuration file is calculated. The sorting results are obtained by ranking the operator ratings in the respective operator configuration files.

6. The method according to claim 5, characterized in that, The sorting rules also include attribute parameters configured by the server for each of the operators under at least one network condition, the attribute parameters including at least one of the following: tariff and stability parameters; the weight calculation model also includes the attribute parameters used to calculate the operator score and the weight factors of the attribute parameters, and before calculating the operator score corresponding to each operator configuration file based on the weight calculation model, the method further includes: Among at least one of the network conditions, a first network condition is determined to be met by the current network environment state; The weight calculation model is configured based on the attribute parameters set for each operator under the first network conditions.

7. The method according to claim 4, characterized in that, The carrier switching rules also include a list of carrier restrictions configured by the server for at least one network condition, and the step of selecting a target configuration file from multiple carrier configuration files based on the sorting result includes: Among at least one of the network conditions, determine a second network condition that the current network environment state meets; Based on the carrier restriction list configured under the second network condition, the disabled carrier profiles are removed from the sorting results.

8. A terminal device, characterized in that, The device includes an eUICC, a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the method of any one of claims 1-7, and the eUICC may store multiple operator configuration files.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1-7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.

Images