An internet of things card connection management method, system, device and product

Abstract

The application discloses a kind of Internet of Things card connection management method, system, equipment and product, method includes: obtaining connection request by physical network card;The connection request is carried out number attribution identification processing by global connection management platform, and the operator interface is obtained;The operator interface is carried out timeout retry detection processing, and the detection result is obtained;According to the detection result, the operator interface is carried out dynamic service polling processing, and the service processing result is obtained;The service processing result is carried out multi-dimensional result check processing, and the check result is obtained.The application embodiment can improve the connection efficiency of Internet of Things card, and can be widely applied in wireless communication technical field.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and in particular to an IoT card connection management method, system, device and product. Background Technology

[0002] Because global IoT SIM card suppliers vary widely in interface types, data formats, authentication methods, and business processes, related technologies typically require customized development and maintenance for each interface from each supplier. However, in practical applications, it has been found that customizing the connection management of each IoT SIM card leads to high system integration costs, long development cycles, and difficulty in quickly responding to market changes.

[0003] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention

[0004] The main objective of this application is to propose an IoT card connection management method, system, device, and product that can improve the connection efficiency of IoT cards.

[0005] To achieve the above objectives, one aspect of this application proposes an IoT card connection management method, the method comprising: The connection request is obtained through the physical network card; The connection request is processed by the global connection management platform to identify the number's attribution, thus obtaining the operator's interface. The timeout retry detection process is performed on the operator interface to obtain the detection result; Based on the detection results, the operator interface is dynamically polled to obtain the service processing results. The business processing results are subjected to multi-dimensional result verification to obtain the verification results.

[0006] In some embodiments, the timeout retry detection process for the operator interface to obtain the detection result includes the following steps: The call time is obtained by processing the call to the operator's interface through the global connectivity management platform; Data collection and processing are performed on the calling process of the operator interface to obtain multi-factor timeout data; The multi-factor timeout data is retried based on the call time to obtain the detection result.

[0007] In some embodiments, the retry detection processing of the multi-factor timeout data based on the call time to obtain the detection result includes the following steps: The timeout data from the multiple factors are subjected to weighted statistical processing to obtain the timeout threshold; The call time is compared with the timeout threshold, and the interface call is retried based on the comparison result to obtain the detection result.

[0008] In some embodiments, the step of performing dynamic service polling on the operator interface based on the detection results to obtain service processing results includes the following steps: Based on the detection results, the operator interface is subjected to business verification processing to obtain asynchronous request parameters; Based on the asynchronous request parameters, a thread construction process is performed to obtain a dynamic polling thread pool; The service polling process is performed on the operator interface using the dynamic polling thread pool to obtain the service processing result.

[0009] In some embodiments, the step of performing thread construction processing based on the asynchronous request parameters to obtain a dynamically polling thread pool includes the following steps: The global connectivity management platform is processed to collect and process thread status data to obtain the total number of threads. The available thread count is obtained by performing an available thread calculation on the asynchronous request parameters based on the total thread count. The dynamic polling thread pool is obtained by constructing a dynamic thread pool and a priority queue based on the number of available threads.

[0010] In some embodiments, the step of performing service polling processing on the operator interface according to the dynamic polling thread pool to obtain the service processing result includes the following steps: The operator interface is subjected to serial number matching processing based on the dynamic polling thread pool to obtain the matching result; When the matching result is that the interface matching fails, the thread state of the operator interface is updated and the serial number matching process is performed again. When the matching result indicates a successful interface match, the operator interface is processed to obtain the processing result.

[0011] In some embodiments, performing multi-dimensional result verification processing on the business processing result to obtain the verification result includes the following steps: Obtain operator benchmark data; The verification priority score is calculated and processed on the operator interface to obtain the verification level; The operator's baseline data and the service processing results are verified according to the verification level to obtain the verification result.

[0012] To achieve the above objectives, another aspect of this application proposes an IoT SIM card connection management system, the system comprising: The connection request module is used to obtain connection requests through the physical network card. The interface identification module is used to perform number attribution identification processing on the connection request through the global connection management platform to obtain the operator interface; The timeout retry detection module is used to perform timeout retry detection processing on the operator interface and obtain the detection result; The dynamic service polling module is used to perform dynamic service polling on the operator interface based on the detection results to obtain the service processing results. The multi-dimensional result verification module is used to perform multi-dimensional result verification processing on the business processing results to obtain the verification results.

[0013] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0014] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0015] The embodiments of this application include at least the following beneficial effects: This application provides an IoT SIM card connection management method, system, device, and product. This solution obtains a connection request through a physical network card; performs number attribution identification processing on the connection request through a global connection management platform to obtain the operator interface; performs timeout retry detection processing on the operator interface to obtain a detection result; performs dynamic service polling processing on the operator interface based on the detection result to obtain a service processing result; and performs multi-dimensional result verification processing on the service processing result to obtain a verification result. The embodiments of this application improve the connection management efficiency of IoT SIM cards by constructing an adaptation layer processing system that includes multi-factor timeout retry, dynamic service polling, and multi-dimensional weighted result consistency verification. This system enables intelligent adaptation, efficient processing, and high reliability of global IoT SIM card supplier interfaces. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of an implementation environment provided in the embodiments of this application; Figure 2 This is a flowchart of an IoT card connection management method provided in an embodiment of this application; Figure 3 yes Figure 2 The flowchart of step S203 in the process; Figure 4 yes Figure 3The flowchart of step S303 in the process; Figure 5 yes Figure 2 The flowchart of step S204 in the process; Figure 6 yes Figure 5 The flowchart of step S502 in the document; Figure 7 yes Figure 5 The flowchart of step S503 in the process; Figure 8 yes Figure 2 The flowchart of step S205 in the text; Figure 9 This is a schematic diagram of the structure of an IoT card connection management system provided in an embodiment of this application; Figure 10 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of systems and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0018] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0019] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0021] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0022] 1) IoT SIM cards are data cards specifically designed for IoT devices. They support low-power wide-area networks and are widely used in smart devices and various IoT scenarios. IoT SIM cards are primarily used for wireless communication in IoT devices, supporting basic communication services such as SMS and wireless data, and are suitable for various application scenarios such as connected vehicles, smart homes, and environmental monitoring.

[0023] 2) Application Programming Interfaces (APIs) serve as standardized bridges for communication between different software systems. By defining rules and data formats, they enable systems to efficiently exchange data or invoke functions. They hide the underlying implementation details, exposing only the necessary functional interfaces, thereby improving security and development efficiency.

[0024] 3) Thread pools are a technique for managing and reusing threads, widely used in concurrent programming. A thread pool pre-creates a certain number of threads and stores them in the pool. When a task needs to be executed, an idle thread is retrieved from the pool to perform the task. After the task is completed, the thread returns to the pool and can be reused by other tasks.

[0025] Because domestic connectivity management platforms manage IoT cards based on domestic operators, they can obtain data from network element information and detailed billing information regarding the card's lifecycle and traffic. However, global connectivity management platforms manage IoT cards from multiple global suppliers, including TATA and Florive, and the companies involved are also global. Therefore, connectivity management of IoT cards presents some challenges. 1. Interface diversity leads to complex and inefficient adaptation: Global IoT SIM card suppliers vary widely in interface types, data formats, authentication methods, and business processes (synchronous / asynchronous / polling / batch query). Existing solutions typically require customized development and maintenance for each interface of each supplier, resulting in high system integration costs, long development cycles, and difficulty in quickly responding to market changes. When expanding to new countries or integrating new suppliers, extensive manual intervention is required for adaptation and testing, leading to extremely low efficiency.

[0026] 2. Uncertainty in the international network environment leads to inconsistencies in service status: The international network environment is complex, and interface call latency is unstable, frequently resulting in timeouts. When a timeout occurs on the client side, the existing system struggles to determine whether the service has been successfully processed by the operator. Simply assuming failure and retrying may lead to duplicate operations; abandoning the service altogether could result in inconsistent service statuses, leaving customers unaware of the true outcome and severely impacting user experience and service reliability. For example, a customer initiates a service suspension request, the client disconnects due to network latency, but the operator has already successfully suspended the service. In this case, the customer's interface may still display "Processing" or "Failed," leading to information asymmetry.

[0027] 3. Lack of intelligent fault diagnosis and recovery mechanisms: When interface calls fail, existing systems often cannot intelligently distinguish whether the problem stems from the program itself (e.g., network connection failure, configuration error) or from external operator service issues (e.g., non-existent ICCID, expired service plan). This lack of diagnostic capabilities prevents the system from adopting targeted recovery strategies. For example, failures caused by momentary network jitter should be automatically retried; however, clear service errors should not be retried. This leads to ineffective retries that waste resources or fail to address problems promptly and effectively, reducing the system's automation level and fault tolerance.

[0028] 4. Rigid retry strategies that fail to adapt to load: Existing retry mechanisms typically employ fixed retry counts and intervals, failing to adequately consider the current system load, the health status of external interfaces, and the importance of the business. Under high system load or persistently unstable external interfaces, rigid retry strategies can lead to a backlog of retry requests, further deteriorating system performance and even triggering a "avalanche effect."

[0029] In view of this, the embodiments of this application construct a three-in-one adaptation layer processing system of "dynamic business polling - multi-factor timeout retries - multi-dimensional weighted result consistency verification" to achieve intelligent adaptation, efficient processing and high reliability of global IoT card supplier interfaces. The embodiments of this application can solve technical problems in the prior art such as the complexity of multi-supplier adaptation of IoT cards, inconsistencies in business states caused by the uncertainty of the international network environment, lack of intelligent fault diagnosis and recovery, and rigid retry strategies.

[0030] This application provides an IoT SIM card connection management method, relating to the field of wireless communication technology. This IoT SIM card connection management method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing an IoT SIM card connection management method, but is not limited to the above forms.

[0031] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0032] Figure 1 This is a schematic diagram illustrating the implementation environment of a method provided in this application. (Refer to...) Figure 1 The main hardware and software components of this implementation environment include a terminal 101 and a server 102, which are communicatively connected. The method can be executed based on the interaction between the terminal 101 and the server 102. Furthermore, the terminal 101 and the server 102 can be nodes in a blockchain; this embodiment does not specifically limit this.

[0033] Figure 2 This is an optional flowchart of an IoT card connection management method provided in an embodiment of this application. Figure 2 The method may include, but is not limited to, steps S201 to S205.

[0034] Step S201: Obtain the connection request through the physical network card; Step S202: The connection request is processed by the global connection management platform to identify the number affiliation and obtain the operator interface; Step S203: Perform timeout retry detection processing on the operator interface to obtain the detection result; Step S204: Perform dynamic service polling on the operator interface based on the detection results to obtain the service processing results; Step S205: Perform multi-dimensional result verification processing on the business processing result to obtain the verification result.

[0035] Steps S201 to S205 of this embodiment involve obtaining a connection request through the physical network card. This connection request allows the user to manage the connection of the corresponding interface through an interactive interface or platform. For example, by initiating an order request to a global connection management platform, the platform can perform number attribution identification processing on the connection request, assign the corresponding supplier for data processing, and obtain the operator interface. Then, multi-factor timeout retry detection is performed on the operator interface. Client timeout, server timeout, available thread count, and service priority are collected at the input end, and a retry is triggered or marked "pending verification" at the output end to obtain the detection result. Based on the detection result, dynamic service polling processing is performed on the operator interface. Asynchronous serial number and service priority are received at the input end, and the result is obtained through dynamic polling of the thread pool at the output end to obtain the service processing result. Finally, multi-dimensional result verification processing is performed on the service processing result. By reading interface attribute data such as the current attribute and historical consistency deviation rate of the interface, as well as benchmark data of foreign operators, the platform judges and returns a "consistent / inconsistent / pending confirmation" result, thereby completing the interface connection management of the IoT card and obtaining the data processing result of the corresponding request.

[0036] In step S201 of some embodiments, the IoT card can be set to promiscuous mode by creating a raw socket, receiving all data packets passing through the network card, binding to a specific network interface, listening to Ethernet frames, filtering and analyzing data packets, and identifying connection requests to be established.

[0037] In step S202 of some embodiments, the connection request can be processed for number attribution identification through a global connectivity management platform. First, the calling number information is extracted from the connection request. The country code (e.g., +86), area code, and operator identification code are analyzed using a number resolution engine. The platform accesses the International Telecommunication Union's number planning database and operator routing table to match the number's attribution operator and its service area in real time. Based on the identification results, the platform dynamically selects the optimal operator interface from the interface resource pool, comprehensively considering interface load rate, tariff costs, and communication quality indicators to generate a standardized interface configuration containing operator authentication tokens, API gateway addresses, and protocol parameters. It is conceivable that the platform can also establish a number attribution caching mechanism to preprocess high-frequency numbers, ensuring that the entire process from number identification to interface scheduling is completed within milliseconds.

[0038] Please see Figure 3 In some embodiments 203, the timeout retry detection process for the operator interface to obtain the detection result includes the following steps: Step S301: The operator interface is invoked through the global connectivity management platform to obtain the invocation time; Step S302: Perform data collection and processing on the calling process of the operator interface to obtain multi-factor timeout data; Step S303: Perform retry detection processing on the multi-factor timeout data according to the call time to obtain the detection result.

[0039] In this embodiment, timeout retry detection is performed on calls to the operator's interface. This involves collecting timeout data from multiple factors, including client-side timeout, server-side timeout, available thread count, and service priority, to determine whether a retry is necessary and obtain the corresponding detection result. This result may include retrying the call to the operator's interface or marking the interface for subsequent retry processing.

[0040] In step S301 of some embodiments, the operator interface is invoked through the global connectivity management platform to obtain the invocation time; In this embodiment, when processing calls to operator interfaces through the global connectivity management platform, the platform first establishes a secure connection channel with the target operator system according to the interface configuration, recording a precise start timestamp before sending the request. Then, it constructs a complete request message according to the operator interface specifications, including an interface authentication token, service parameters, and a session identifier, and selects the optimal service node to send the request through a load balancer. While waiting for a response, the platform monitors connection timeout and read timeout thresholds, tracking the request status in real time. Upon receiving a response from the operator system, it immediately records the end timestamp and calculates the difference between the end timestamp and the start timestamp as the precise call time. It is conceivable that the platform can also associate and store the call time with metadata such as response status codes and error messages, forming a complete interface call performance record, providing data support for subsequent routing optimization and troubleshooting.

[0041] In step S302 of some embodiments, data acquisition and processing are performed on the calling process of the operator interface to obtain multi-factor timeout data; In this embodiment, data collection and processing are performed on the call process of the operator's interface. The platform implants monitoring probes at key nodes of the interface call through a distributed tracing system: recording the connection establishment time and monitoring the three-way handshake time during the TCP connection phase; recording the security handshake time and detecting certificate verification and key exchange delays during the SSL / TLS handshake phase; recording the request transmission time and tracking the interval between sending data packets to receiving the first response byte during the request sending phase; and recording the data download time and monitoring the transmission time of the complete response body during the response receiving phase. Simultaneously, the system collects network-level indicators such as DNS resolution time, gateway routing time, and operator core network processing time. Combined with the business context of the interface call (such as request type, data size, and concurrency), it constructs a multi-factor timeout data set including time series distribution, timeout frequency statistics, and performance bottleneck location, providing comprehensive data support for interface performance optimization and fault diagnosis.

[0042] Please see Figure 4 In step S303 of some embodiments, the retry detection process of the multi-factor timeout data based on the call time to obtain the detection result includes the following steps: Step S401: Perform weighted statistical processing on the multi-factor timeout data to obtain the timeout threshold; Step S402: Compare the call time according to the timeout threshold, trigger the interface call for retry processing based on the comparison result, and obtain the detection result.

[0043] In one feasible embodiment, the present application obtains a timeout threshold by weighting and statistically analyzing multi-factor timeout data. The calculation formula for the timeout threshold is as follows: S = (Tclient ×0.3 + Tserver ×0.3 + T×0.2 + Wservice ×0.1 + Wsensitivity ×0.1) ×0.7; wherein, S represents a timeout threshold (in milliseconds), and a retry is triggered when the interface calling time > S; Tclient represents a client timeout (1500 ms preset by the platform); Tserver represents a server timeout (2000 ms returned by operator A); T represents the current number of available threads (50); the weight coefficient Wservice = 5, and the weight coefficient Wsensitivity = 3; the coefficient 0.7 represents a safety factor.

[0044] In the embodiment of the present application, by calling the interface of operator A, it is monitored that the calling time reaches 800 ms (> S), the first retry is triggered, and the interval S×0.3=222.77 ms is calculated (the retry interval is shortened for high-sensitivity orders); when the first retry succeeds (the calling time is 650 ms < S), a retry log is recorded, and the detection result obtained is that call retry processing is performed on the interface of operator A.

[0045] Please refer to Figure 5 , in step S204 of some embodiments, said performing dynamic service polling processing on said operator interface according to said detection result to obtain a service processing result comprises the following steps: step S501, performing service verification processing on said operator interface according to said detection result to obtain asynchronous request parameters; step S502, performing thread construction processing according to said asynchronous request parameters to obtain a dynamic polling thread pool; step S503, performing service polling processing on said operator interface according to said dynamic polling thread pool to obtain a service processing result.

[0046] In this embodiment, when performing dynamic service polling on operator interfaces based on detection results, the platform first establishes an intelligent routing decision engine based on multi-factor timeout data: when the response time of an operator interface exceeds a threshold or the error rate increases, its weight in the polling queue is automatically reduced, while the priority of backup interfaces is increased; the system analyzes the connection success rate, average response time, and concurrent processing capability of each interface in real time, constructs a dynamic weight allocation model, and automatically adjusts the service request distribution ratio according to the interface performance; during the polling process, the platform adopts a gradual switching strategy, first verifying the stability of backup interfaces with a small proportion of traffic, and gradually increasing the load after confirming normal operation to ensure a smooth service transition; at the same time, an abnormal rollback mechanism is established, automatically switching traffic back to the primary interface when a performance degradation of the backup interface is detected. The final service processing result is the response data based on the optimal interface path. The platform records detailed logs of each polling decision, including the interface selection basis, performance comparison data, and actual processing effect, forming a closed-loop optimized service scheduling system.

[0047] In step S501 of some embodiments, the operator interface is subjected to service verification processing based on the detection result to obtain asynchronous request parameters; In this embodiment, when performing business verification processing on the operator interface based on the detection results, the platform first establishes a multi-dimensional verification matrix. Based on the response time stability, error code distribution, and concurrent processing capability indicators in the interface performance detection results, the platform classifies the operator interface for business availability. The verification engine analyzes the matching degree between the interface's business carrying capacity and current business requirements, and combines historical business processing success rate data to generate a supplier serial number containing a unique identifier and business priority parameters based on business urgency, resource consumption estimation, and SLA requirements. During the asynchronous request parameter construction process, the system assigns a globally unique supplier serial number to each business request to ensure request traceability. Simultaneously, it dynamically calculates business priority weights based on business type (e.g., real-time voice, batch SMS, IoT data) and customer level, ultimately generating a standardized set of asynchronous request parameters to provide a complete execution context for subsequent asynchronous business scheduling.

[0048] Please see Figure 6 In step S502 of some embodiments, thread construction processing is performed based on the asynchronous request parameters to obtain a dynamic polling thread pool, including the following steps: Step S601: Perform thread status acquisition and processing on the global connection management platform to obtain the total number of threads; Step S602: Calculate the available thread count based on the total number of threads for the asynchronous request parameters; Step S603: Based on the number of available threads, a dynamic thread pool and priority queue are constructed to obtain the dynamic polling thread pool.

[0049] In step S601 of some embodiments, the global connection management platform is subjected to thread status acquisition processing to obtain the total number of threads; In this embodiment, the platform's built-in monitoring agent can collect the thread running status of each service node in real time. For example, the monitoring agent can obtain detailed thread information for each process through JVM MXBean (for Java platforms) or the system-level thread API, including the number of active threads, blocked threads, waiting threads, and daemon threads. Simultaneously, a distributed tracing system aggregates the thread status data of all service nodes to establish a global thread view. During data collection, the system filters out system maintenance threads and temporary threads, focusing on the statistics of business processing threads. A time window algorithm is used to eliminate the impact of instantaneous fluctuations, ultimately obtaining an accurate total thread count metric that reflects the platform's current load status, providing crucial information for resource scheduling and capacity planning.

[0050] In step S602 of some embodiments, the available thread count is calculated based on the total number of threads in the asynchronous request parameters. In this embodiment, the available resources are calculated by reading the maximum thread pool capacity and the number of reserved threads from the system configuration and combining them with the current total number of threads. Specifically, by analyzing the business priority in the asynchronous request parameters, dedicated thread quotas are reserved for high-priority businesses to ensure that critical businesses are not affected by resource contention. The system uses a dynamic weighting algorithm to predict the thread recycling speed based on historical thread usage efficiency and current load trends, and comprehensively calculates the accurate number of available threads. During the calculation process, the platform considers the thread lifecycle state (such as new, running, blocked, terminated), excludes threads that are about to end and unavailable threads, and finally obtains an indicator of the number of available threads that reflects the actual processing capacity, providing an accurate resource assessment basis for asynchronous request scheduling.

[0051] In step S603 of some embodiments, a dynamic thread pool and priority queue are constructed based on the number of available threads to obtain the dynamic polling thread pool.

[0052] In some feasible implementations, by calling the asynchronous interface of operator A, the serial number "UCM20250610001" is received, the business priority Wbusiness = 5 (urgent traffic fee calculation), and the data sensitivity Wsensitivity = 3 (high value of billing data); and the thread status is collected in real time: Ttotal = 80, Toccupancy = 30. Substituting the values ​​into the available thread calculation formula, we can obtain the number of available threads. The expression for the available thread calculation formula is as follows: T = (T_total - T_percentage) × (W_industry × 0.6 + W_sensitivity × 0.4) + T_prediction; Where T represents the current number of available asynchronous polling threads (integer, minimum 1, maximum ≤ T_total); T_total represents the preset total number of core threads in the adaptation layer (e.g., 80); T_occupy represents the number of threads currently occupied by synchronous interfaces / low-priority services; W_service represents the service priority weight (levels 1-5, high priority W_service = 5); W_sensitivity represents the data sensitivity weight (levels 1-3, high sensitivity W_sensitivity = 3); T_preset represents the number of reserved emergency threads (fixed at 10).

[0053] Through actual calculation, we can obtain T≤T_total - T_occupy = 50, and the actual number of available threads = 50. In this embodiment, a dynamic polling thread pool (50 threads) is opened, with a polling interval of 3 seconds (the interval is shortened for high-priority and high-sensitivity orders). The billing data returned by operator A ("100MB of traffic used, $5 cost") is obtained by polling and pushed to the result analysis unit.

[0054] Please see Figure 7 In step S503 of some embodiments, the step of performing service polling processing on the operator interface according to the dynamic polling thread pool to obtain the service processing result includes the following steps: Step S701: Perform serial number matching processing on the operator interface according to the dynamic polling thread pool to obtain the matching result; Step S702: When the matching result is that the interface matching fails, the thread state of the operator interface is updated and the serial number matching process is performed again. Step S703: When the matching result is that the interface is successfully matched, the operator interface is processed to obtain the service processing result.

[0055] In this embodiment, when performing serial number matching for the operator's interface using a dynamic polling thread pool, the platform employs a multi-level matching algorithm: First, hash matching is performed on the supplier's serial number in the polling thread pool to route the request to the corresponding thread group; then, the session context of the serial number is retrieved from the thread's local storage to verify the binding relationship between the request and the interface. When the matching result indicates interface matching failure, the system immediately updates the thread status of the operator's interface to "waiting for retry" and records the reason for failure in the interface health profile; simultaneously, an interface weight downgrade mechanism is triggered, temporarily reducing the priority of the interface in the polling pool, and after a short cooling-off period, serial number matching is re-initiated. When the matching result indicates interface matching success, the system locks the interface thread resource and executes the complete business processing flow: including parameter verification, request encryption, protocol conversion, and response parsing, ultimately generating a business processing result containing processing status codes, business data, and performance indicators. Simultaneously, the thread lock is released and the interface load statistics are updated to provide real-time data support for subsequent request allocation.

[0056] Please see Figure 8 In step S205 of some embodiments, the multi-dimensional result verification processing of the business processing result to obtain the verification result includes the following steps: Step S801: Obtain operator baseline data; Step S802: Perform verification priority scoring on the operator interface to obtain the verification level; Step S803: Perform verification processing on the operator's baseline data and the service processing result according to the verification level to obtain the verification result.

[0057] In this embodiment, the verification level is obtained by calculating the verification priority score of the operator interface. This embodiment pre-classifies the interface and service type. First, it assigns weights to the interface type: synchronous interface = 1, asynchronous interface = 2. Then, it assigns weights to the interface's return speed: ≤100ms = 1, 100ms-5s = 2, >5s = 3. It also assigns weights to the interface's return status code: 200 = 1, non-200 (e.g., 202 / 404) = 2. Furthermore, it assigns weights to the interface's historical deviation rate: ≤2% = 1, 2%-5% = 2, >5% = 3. Finally, it assigns weights to the service sensitivity: low (status data) = 1, medium (traffic data) = 2, high (billing / recharge data) = 3. The verification priority score (P') is calculated as Σ(dimension weight × dimension assignment), with a range of 1-2.8. The higher the score, the higher the verification priority. This application's embodiments classify verification levels based on calculated verification priority values ​​and match differentiated strategies. When the calculated value is in the range of 1.0-1.5, the verification level is basic verification, the verification strategy is set to verification-free, and consistency is directly determined. This is applicable to scenarios such as synchronization, 100ms return, 200 codes, historical consistency deviation rate = 1%, and low sensitivity (state). When the calculated value is in the range of 1.5-2.2, the verification level is enhanced verification, the verification strategy is set to sampling verification (sampling rate = P' × 50%), and a single review is performed if there is a discrepancy. This is applicable to scenarios such as synchronization, 2s return, 200 codes, historical consistency deviation rate = 3%, and medium sensitivity (traffic). When the calculated value is in the range of 1.5-2.2, the verification level is enhanced verification, the verification strategy is set to sampling verification (sampling rate = P' × 50%), and a single review is performed if there is a discrepancy. This is applicable to scenarios such as synchronization, 2s return, 200 codes, historical consistency deviation rate = 3%, and medium sensitivity (traffic). When the calculated value is in the range of 2.2-2.8, the verification level is strict verification, and the verification strategy is set to real-time dual-source verification (simultaneously calling the supplier's + foreign operator's interface for comparison). If there is a discrepancy, a third verification and an alarm will be triggered. This is suitable for asynchronous, 8-second return, 200 codes, historical consistency deviation rate of 6%, and high sensitivity (billing) scenarios.

[0058] The solutions of this application embodiment will be described in detail and explained below with reference to specific application examples: This application embodiment is applied to the connection management of IoT cards, which manages IoT cards through a global connection management platform and initiates the data pool limit order acceptance interface. Taking "a cross-border cargo ship logistics" as an example: Users (such as multinational freight companies) manage IoT cards through a global connectivity management platform, initiate a traffic pool limit order acceptance interface, and initiate a request for "monthly traffic billing query and limit based on IoT pool number + traffic threshold" (highly sensitive data involving traffic cost calculation); the platform queries the pool number to identify the supplier of the number in the pool as "Southeast Asian Operator A" (this operator's billing data consistency deviation rate in the past 30 days is 6%, higher than the average of 3%); "Southeast Asian Operator B" (this operator's billing data consistency deviation rate in the past 30 days is 5%, higher than the average of 2%); "Southeast Asian Operator C" (this operator's billing data consistency deviation rate in the past 30 days is 10%, higher than the average of 5%); dynamically configure the interfaces of operators A, B, and C. If the interface is asynchronous (returns serial number "ASN20240610001"), times out (exceeds the client's preset 1500ms), or the returned billing data is inconsistent with the benchmark data of foreign operators, it needs to be processed through the embodiment of this application, and finally returns "acceptance successful +" to the user. The billing data is consistent with the result of "speed limit after reaching the limit".

[0059] Please see Figure 9 This application also provides an IoT card connection management system that can implement the above-described IoT card connection management method. The system includes: The connection request module 901 is used to obtain connection requests through the physical network card. Interface identification module 902 is used to perform number attribution identification processing on the connection request through the global connection management platform to obtain the operator interface; The timeout retry detection module 903 is used to perform timeout retry detection processing on the operator interface and obtain the detection result. The dynamic service polling module 904 is used to perform dynamic service polling on the operator interface based on the detection results to obtain service processing results. The multi-dimensional result verification module 905 is used to perform multi-dimensional result verification processing on the business processing result to obtain the verification result.

[0060] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0061] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0062] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0063] Please see Figure 10 , Figure 10 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 1001 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 1002 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1002 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1002 and is called and executed by the processor 1001. Input / output interface 1003 is used to implement information input and output; The communication interface 1004 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1005 transmits information between various components of the device (e.g., processor 1001, memory 1002, input / output interface 1003, and communication interface 1004); The processor 1001, memory 1002, input / output interface 1003 and communication interface 1004 are connected to each other within the device via bus 1005.

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

[0065] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0066] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0067] This application provides an IoT SIM card connection management method, system, device, and product. The solution obtains a connection request through a physical network card; performs number attribution identification processing on the connection request through a global connection management platform to obtain the operator interface; performs timeout retry detection processing on the operator interface to obtain a detection result; performs dynamic service polling processing on the operator interface based on the detection result to obtain a service processing result; and performs multi-dimensional result verification processing on the service processing result to obtain a verification result. This application improves the efficiency of IoT SIM card connection management by constructing an adaptation layer processing system that includes multi-factor timeout retry, dynamic service polling, and multi-dimensional weighted result consistency verification. It enables intelligent adaptation, efficient processing, and high reliability of global IoT SIM card vendor interfaces.

[0068] This application embodiment utilizes a multi-dimensional weighted result consistency verification algorithm, combining the dimensions of "historical consistency deviation rate of global supplier interfaces and business data sensitivity" to calculate the result verification priority and match differentiated verification strategies. This achieves stricter verification of high-risk, high-value data and reduces invalid verification of low-risk, low-value data, thereby improving the accuracy of business consistency and resource utilization.

[0069] Furthermore, this application embodiment utilizes dynamic business polling, combining business priority and data sensitivity to allocate threads, thereby increasing the thread allocation priority of high-value data (such as billing data) by 40% and avoiding waiting for high-value data.

[0070] In addition, the embodiments of this application utilize multi-factor timeout retry thresholds, combined with data sensitivity dimensions, to improve the flexibility of retry strategies, adapt to load, and reduce business delays.

[0071] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0072] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0073] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0074] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0075] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0076] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0077] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0078] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0079] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0080] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0081] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for managing IoT card connections, characterized in that, The method includes the following steps: The connection request is obtained through the physical network card; The connection request is processed by the global connection management platform to identify the number's attribution, thus obtaining the operator's interface. The timeout retry detection process is performed on the operator interface to obtain the detection result; Based on the detection results, the operator interface is dynamically polled to obtain the service processing results. The business processing results are subjected to multi-dimensional result verification to obtain the verification results; The process of performing timeout retry detection on the operator interface to obtain the detection result includes the following steps: The call time is obtained by processing the call to the operator's interface through the global connectivity management platform; Data collection and processing are performed on the calling process of the operator interface to obtain multi-factor timeout data; The multi-factor timeout data is retryed based on the call time to obtain the detection result; The retry detection process based on the call time for the multi-factor timeout data, to obtain the detection result, includes the following steps: The timeout data from the multiple factors are subjected to weighted statistical processing to obtain the timeout threshold; The call time is compared with the timeout threshold, and the interface call is retried based on the comparison result to obtain the detection result.

2. The method according to claim 1, characterized in that, The step of performing dynamic service polling on the operator interface based on the detection results to obtain service processing results includes the following steps: Based on the detection results, the operator interface is subjected to business verification processing to obtain asynchronous request parameters; Based on the asynchronous request parameters, a thread construction process is performed to obtain a dynamic polling thread pool; The service polling process is performed on the operator interface using the dynamic polling thread pool to obtain the service processing result.

3. The method according to claim 2, characterized in that, The process of constructing threads based on the asynchronous request parameters to obtain a dynamic polling thread pool includes the following steps: The global connectivity management platform is processed to collect and process thread status data to obtain the total number of threads. The available thread count is obtained by performing an available thread calculation on the asynchronous request parameters based on the total thread count. The dynamic polling thread pool is obtained by constructing a dynamic thread pool and a priority queue based on the number of available threads.

4. The method according to claim 2, characterized in that, The step of performing business polling processing on the operator interface based on the dynamic polling thread pool to obtain the business processing result includes the following steps: The operator interface is subjected to serial number matching processing based on the dynamic polling thread pool to obtain the matching result; When the matching result is that the interface matching fails, the thread state of the operator interface is updated and the serial number matching process is performed again. When the matching result indicates a successful interface match, the operator interface is processed to obtain the processing result.

5. The method according to claim 1, characterized in that, The process of performing multi-dimensional result verification on the business processing result to obtain the verification result includes the following steps: Obtain operator benchmark data; The verification priority score is calculated and processed on the operator interface to obtain the verification level; The operator's baseline data and the service processing results are verified according to the verification level to obtain the verification result.

6. An IoT SIM card connection management system, wherein the IoT SIM card connection management system is applied to the IoT SIM card connection management method as described in claim 1, characterized in that, The system includes: The connection request module is used to obtain connection requests through the physical network card. The interface identification module is used to perform number attribution identification processing on the connection request through the global connection management platform to obtain the operator interface; The timeout retry detection module is used to perform timeout retry detection processing on the operator interface and obtain the detection result; The dynamic service polling module is used to perform dynamic service polling on the operator interface based on the detection results to obtain the service processing results. The multi-dimensional result verification module is used to perform multi-dimensional result verification processing on the business processing results to obtain the verification results.

7. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 5.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 5.

Images