Communication quality monitoring method, apparatus and device

Abstract

The method provided by the embodiment of the present disclosure comprises: acquiring communication link state data of a terminal where the smart card is located; in the case that there is no service processing request in the terminal where the smart card is located, determining a monitoring window according to interruption information of a historical monitoring task and a predicted idle duration of the terminal; in the monitoring window, processing the communication link state data of the terminal where the smart card is located through a plurality of atomic steps corresponding to a communication quality monitoring task, to obtain a communication quality score of the terminal where the smart card is located; and obtaining a communication quality monitoring result based on the communication quality score. The process of data collection, analysis, decision and reporting is concentrated in the operating system inside the smart card, which can realize autonomous monitoring, adapt to the scene, and also reduce the lag and delay experience of the user when using the terminal.

Description

Technical Field

[0001] This disclosure pertains to smart card management technology, and particularly relates to a communication quality monitoring method, apparatus, and device. Background Technology

[0002] Existing network monitoring solutions primarily utilize smart cards (Subscriber Identity Modules, SIMs) for remote network quality detection. Raw data is transmitted back to the cloud monitoring platform for analysis and decision-making via signaling between the smart card and the platform. However, this approach employs a passive, on-demand diagnostic model, lacking foresight; it heavily relies on the terminal's main processor to execute detection tasks, failing to guarantee the independent and stable operation of the monitoring link; and when the quality of the main communication link deteriorates, command issuance and data transmission become difficult and delayed, failing to meet the real-time requirements for emergency link switching by drones. Summary of the Invention

[0003] This disclosure provides a communication quality monitoring method, apparatus, and device that can achieve proactive, reliable, and efficient monitoring of terminal communication quality.

[0004] In a first aspect, embodiments of this disclosure provide a communication quality monitoring method applied to a smart card, the method comprising: Obtain communication link status data of the terminal where the smart card is located; When there is no business processing request at the terminal where the smart card is located, the monitoring window is determined based on the interruption information of historical monitoring tasks and the predicted idle time of the terminal. Within the monitoring window, the communication link status data of the terminal where the smart card is located is processed through multiple atomic steps corresponding to the communication quality monitoring task to obtain the communication quality score of the terminal where the smart card is located. Communication quality monitoring results are obtained based on communication quality scores.

[0005] In one feasible implementation, when there is no service processing request at the terminal where the smart card is located, the monitoring window is determined based on historical monitoring task interruption information and the predicted terminal idle time, including: If there is no business processing request at the terminal where the smart card is located, obtain the interruption information of historical monitoring tasks and predict the idle time of the terminal. The completion rate and interruption rate of historical monitoring tasks are calculated based on the interruption information of historical monitoring tasks. Based on the historical monitoring task completion rate and historical monitoring task interruption rate, the terminal idle time is corrected to obtain the monitoring window.

[0006] In one feasible implementation, within the monitoring window, the communication link status data of the terminal where the smart card is located is processed through multiple atomic steps corresponding to the communication quality monitoring task to obtain the communication quality score of the terminal where the smart card is located, including: Within the monitoring window, the first atomic step corresponding to the communication quality monitoring task is used to perform feature quantization on the communication link status data of the terminal where the smart card is located, and a feature vector is obtained. Through the second atomic step corresponding to the communication quality monitoring task, the feature vector is subjected to fixed-point multiplication and addition operations based on the parameter set corresponding to multiple risk types, and the target risk type and the failure risk type are determined according to the operation results. The communication quality score of the terminal where the smart card is located is calculated based on the deviation between the calculation results of the target risk type and the rejection risk type through the third atomic step corresponding to the communication quality monitoring task.

[0007] In one feasible implementation, the communication quality score of the terminal where the smart card is located is calculated based on the deviation between the calculation results of the target risk type and the rejection risk type through the third atomic step corresponding to the communication quality monitoring task, including: If a new business processing request is made or the remaining time of the monitoring window is less than the remaining execution time of the third atomic step, the third atomic step is interrupted and the interruption point is recorded. In the next monitoring window adjacent to the monitoring window, continue executing the third atomic step after the step interruption point to obtain the communication quality score of the terminal where the smart card is located.

[0008] In one feasible implementation, obtaining the communication link status data of the terminal where the smart card is located includes: Based on the page number and description information of the shared pages, a set of shared pages is determined; the shared pages are stored in a shared page memory pool. If a tail index exists in the shared page set, read the contents of the shared page set and calculate the checksum based on the reading result; the tail index is used to characterize the storage status of each data in the shared page set. If the checksum matches the verification checksum in the description information, the data stored in the shared page set is used as the communication link status data.

[0009] In one feasible implementation, after obtaining the communication quality monitoring results based on the communication quality score, the method further includes: If the communication quality monitoring result indicates that the communication quality score meets the preset alarm conditions, then the preset instruction corresponding to the communication quality score and the service scenario type of the terminal where the smart card is located is obtained from the preset instruction mapping relationship. The preset instruction mapping relationship is used to characterize the communication quality score and service scenario type corresponding to each preset instruction. Execute preset instructions corresponding to the communication quality score and business scenario type to obtain the execution result; Alarm information is generated based on communication quality monitoring results and execution results.

[0010] In one feasible implementation, after executing preset instructions corresponding to the communication quality score and service scenario type, the method further includes: After the preset instructions corresponding to the communication quality score and business scenario type have been executed, obtain the communication link status data within the target time interval; The communication link status data within the target time interval is normalized to obtain the mapping adjustment coefficient; The mapping score between business scenario types and preset instructions is updated based on the mapping adjustment coefficient. The mapping score is used to characterize the degree of matching between business scenario types and preset instructions. The preset instruction mapping relationship is updated based on the updated mapping score.

[0011] In one feasible implementation, after generating alarm information based on communication quality monitoring results and execution results, the method further includes: Establish a data channel between smart cards and the cloud; Alarm information is reported to the cloud via the data channel between the smart card and the cloud. In the event of a reporting failure, the alarm information is reported to the cloud via the signaling channel between the smart card and the base station.

[0012] Secondly, embodiments of this disclosure provide a communication quality monitoring device, the device comprising: The data acquisition module is used to acquire communication link status data of the terminal where the smart card is located; The window creation module is used to create a monitoring window based on historical monitoring task interruption information and predicted terminal idle time when there is no business processing request at the terminal where the smart card is located. The monitoring module is used to process the communication link status data of the terminal where the smart card is located through multiple atomic steps corresponding to the communication quality monitoring task within the monitoring window, and obtain the communication quality score of the terminal where the smart card is located. The generation module is used to obtain communication quality monitoring results based on the communication quality score.

[0013] Thirdly, this disclosure provides a communication quality monitoring device, which includes a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the above-described communication quality monitoring method.

[0014] The communication quality monitoring method, apparatus, and device of this disclosure centralize the data acquisition and analysis process within the smart card's internal operating system. This allows for autonomous monitoring without waiting for cloud-based instructions, and reduces the terminal-cloud interaction response time during monitoring, improving efficiency and timeliness. Furthermore, it eliminates the need for test traffic beyond service traffic, reducing the possibility of network resource contention and avoiding inaccurate monitoring due to inconsistencies between service and test traffic levels. Moreover, communication quality monitoring is achieved through a monitoring window when there are no service processing requests on the terminal, reducing lag and latency for users. Additionally, the monitoring task is broken down into multiple atomic steps, minimizing the impact of service interruptions. It allows for pause and restart at any time without losing progress, resuming execution of the next atomic step or interrupted atomic steps in the next monitoring window, thus improving robustness. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments of this disclosure will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating a communication quality monitoring method provided in an embodiment of this disclosure; Figure 2 This is a flowchart illustrating a data writing method provided in an embodiment of this disclosure; Figure 3 This is a flowchart illustrating a data reading method provided in an embodiment of this disclosure; Figure 4 This is a flowchart illustrating a communication quality monitoring task provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of the process for establishing a monitoring window and executing a communication quality monitoring task, provided in an embodiment of this disclosure. Figure 6 This is a schematic diagram of the interactive process for updating a communication quality monitoring model provided in an embodiment of this disclosure; Figure 7 This is a schematic diagram of the structure of a communication quality monitoring device provided in an embodiment of this disclosure; Figure 8 This is a schematic diagram of the structure of a communication quality monitoring device provided in an embodiment of this disclosure. Detailed Implementation

[0017] The features and exemplary embodiments of various aspects of this disclosure will now be described in detail. To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description, in conjunction with the accompanying drawings and specific embodiments, will provide a further detailed description. It should be understood that the specific embodiments described herein are intended only to explain this disclosure and not to limit it. For those skilled in the art, this disclosure can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this disclosure by illustrating examples.

[0018] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0019] The acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of national laws and regulations.

[0020] In the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the applicant has used or necessarily used the solution.

[0021] Currently, drones other than micro-drones can report identification information to the integrated monitoring service platform for unmanned aerial vehicles (UAVs). Flight applications are required when UAVs conduct relay flights via communication base stations or the internet. Furthermore, due to production and communication management requirements, civilian UAVs using cellular networks must use dedicated SIM cards, and basic telecommunications companies should support effective monitoring and handling of network-connected UAVs. In monitoring technology, the SIM card, as a trusted root, undertakes the task of connecting to the monitoring platform and reporting regulatory information. The Bearer Independent Protocol (BIP) is a crucial connection for the SIM card's external communication, involving the stability of the entire link from the terminal signal, the SIM card to the UAV terminal, and then to the BIP gateway and its monitoring platform. Therefore, the reliability and stability of the BIP connection are particularly important. However, the industry has very few use cases for BIP connections, and there is currently no monitoring system for the BIP connection status of smart cards. In recent years, with the rapid development of super SIM card chips, the main frequency of the chip's central processing unit (CPU) has exceeded 120MHz, the random access memory (RAM) has exceeded 144KB, and the flash memory (Flash) has reached 2.5MB. The SIM card is no longer just a low-computing-power module; it can undertake more and more complex tasks.

[0022] More specifically, existing technologies primarily utilize SIM cards to assist in remote network quality detection. First, the network quality detection platform writes a set of instructions, including the target address and network detection commands, into a SIM card with specific storage space within the terminal device via Over-The-Air (OTA) technology. Then, when network diagnostics are needed, the platform sends a trigger command to the terminal device. Upon receiving the trigger command, the terminal device reads and executes the pre-stored instructions from its SIM card, thereby obtaining metrics such as network latency and packet loss rate when accessing the target address. Finally, the terminal transmits this basic network layer metrics back to the platform for subsequent analysis.

[0023] However, this method cannot meet the needs of mission-critical scenarios such as real-time monitoring, and has fundamental flaws.

[0024] First, the existing technology's workflow must be initiated by an external monitoring platform. It can only perform a one-time snapshot inspection when the connection quality has deteriorated or the platform has suspected a problem through other means (such as data not being reported for a long time). It cannot analyze the trend of data changes, lacks proactive prediction capabilities, and cannot reserve a valuable time window for switching drone emergency plans.

[0025] Secondly, the SIM card is merely a passive instruction storage medium, while the core task of network detection is handled by the drone's main processor. This binds the reliability of monitoring to an unrelated and more complex system, making the detection susceptible to the real-time load of the terminal flight control system and other components, thus compromising reliability.

[0026] Furthermore, since the execution entity is the terminal, this solution cannot perceive the actual operating status inside the smart card. For example, it cannot distinguish whether the root cause of the BIP response delay is an external network problem or a problem with the SIM card itself due to internal resource constraints.

[0027] Furthermore, network detection commands such as Ping and Traceroute are used to actively generate test traffic to probe the network. However, this active probing consumes valuable wireless network bandwidth, data traffic, and limited onboard battery power from the drone, resulting in additional resource consumption and making it unsuitable for scenarios requiring long-term, high-frequency monitoring. Additionally, the test traffic used for active probing (such as Internet Control Message Protocol, ICMP packets) may differ from the actual BIP (Browser Information Processing) traffic (such as Transmission Control Protocol, TCP, or User Datagram Protocol, UDP packets) in terms of network routing policies and Quality of Service (QoS) levels. Therefore, the probing results may not fully and accurately reflect the actual performance of core service links.

[0028] Furthermore, the terminal transmits the detected raw indicators back to the platform for analysis, judgment, and decision-making. In this centralized model, the entire decision-making chain requires a complete round trip to the cloud, introducing significant communication latency and failing to meet the requirement for immediate response. When the performance of the main BIP link deteriorates, the channel used to report detection results and receive platform decision instructions also becomes unreliable, creating a paradox: the worse the link, the more necessary the switching, but precisely because of the poor link, the switching decision cannot be completed.

[0029] Therefore, existing technical solutions have fundamental defects in core dimensions such as predictive ability, autonomous controllability, resource efficiency, and real-time decision-making.

[0030] To address the problems of existing technologies, embodiments of this disclosure provide a communication quality monitoring method, apparatus, and device. This disclosure centralizes data collection, analysis, and decision-making within the operating system of the SIM card for autonomous operation; it continuously analyzes real-world service traffic using a lightweight machine learning model to proactively predict network activity; it accurately assesses connection health without generating any additional network traffic or power consumption; and it deploys intelligent decision-making logic at the network's edge—the smart card—generating alarm signals locally on the card to achieve real-time decision-making at the network edge, significantly shortening emergency response time.

[0031] Furthermore, this embodiment implements the communication quality monitoring method through a communication quality monitoring system. Specifically, the system's resource budget can be adjusted according to the chip. For example, Flash ≤ 2KB / slot, algorithm code ≤ 12KB increments. In RAM, the circular buffer ≤ 2KB, and the inference and transaction buffers ≤ 1KB. CPU idle on-chip inference p95 ≤ 0.3ms / record; zero-copy BIP inline acquisition (Zero... The average probe duration of ZBIT (Bip Inline Telemetry) is <5μs / event. ZBIT runs on the same thread as BIP; Predictive Idle Preemptive Scheduling (PIPS) is a low-priority preemptive task; the CSEA module and the reporting single-state machine drive the process. For example, key interfaces include scheduling functions such as `os_idle_cb_register(pips_idle_handler)`, `pips_enqueue(record_ptr)`, and `pips_resume(checkpoint)`; probe functions such as `bip_probe_on_send(len,ts)`, `bip_probe_on_ack(ts)`, and `bip_probe_on_recv(len,ts)`; actions such as `adjust_retry(timeout,backoff)`, `switch_endpoint(primary / backup)`, `run_selfcheck()`, and `rate_limit(level)`; update transactions such as `start_update(manifest)`, `write_chunk(offset,data,crc16)`, `commit()`, and `rollback()`; and exception rollback: model file corruption, signature verification failure, health endorsement failure, and action execution timeout all trigger rollback to the old slot and platform alarms; and external output includes failure reason codes and active slot information.

[0032] Furthermore, to demonstrate that the communication quality monitoring method meets the resource and timing constraints of smart cards, this disclosure also includes effectiveness verification. The experimental environment was CC2560A@120MHz, 144KB RAM; 4G / 5G weak network simulation (packet loss 0-10%, latency 50-800ms, jitter 0-200ms); drone monitoring reports 1-10 times / minute; primarily using BIP, with SMS service as a fallback. The comparison baselines included baseline A and baseline B, where baseline A was a passive diagnosis triggered by OTA, without prediction or handling; baseline B handled according to fixed rules, without online annealing. The verification results are shown below and will not be repeated here.

[0033] This communication quality monitoring method can be applied to scenarios involving communication quality testing of terminal devices. The executing entity of this method can be the operating system of the smart card within the terminal device. Here, the terminal device can be a low-altitude aircraft such as a drone connected via a cellular network, or it can be a regular communication device. The smart card can be a SIM card in a mobile phone.

[0034] The communication quality monitoring method provided in the embodiments of this disclosure will be introduced first.

[0035] Figure 1 A flowchart illustrating a communication quality monitoring method according to an embodiment of this disclosure is shown. Figure 1 As shown, this method, applied to smart cards, may include the following steps: S110. Obtain the communication link status data of the terminal where the smart card is located; S120. When there is no business processing request in the terminal where the smart card is located, determine the monitoring window based on the interruption information of historical monitoring tasks and the predicted idle time of the terminal. S130. Within the monitoring window, the communication link status data of the terminal where the smart card is located is processed through multiple atomic steps corresponding to the communication quality monitoring task to obtain the communication quality score of the terminal where the smart card is located. S140. Obtain communication quality monitoring results based on communication quality scores.

[0036] The communication link state data is used to characterize information such as congestion, communication quality, and communication results, including state transitions, queue length, communication quality indicators, result codes, and throughput windows. Specifically, BIP state transitions include the time, success reason, and failure reason for key state transition points such as CONNECT, SEND, ACK, RECV, and CLOSE. Queue length includes the length of the sending queue and the length of the receiving queue. Communication quality indicators include round-trip time (RTT) / jitter, retransmissions and packet loss, failure codes, and scenario codes.

[0037] Here, "service processing request" refers to the main service needs of the terminal where the smart card is located, excluding communication quality monitoring tasks. The monitoring window is the time window used for communication quality monitoring, representing the idle time between two terminal service requests. "Historical monitoring tasks" refers to historical communication quality monitoring tasks.

[0038] Here, the communication quality monitoring results can be used to make decisions on whether to issue an alarm.

[0039] The communication quality monitoring method, apparatus, device, and storage medium disclosed in this invention centralize the data acquisition and analysis processes within the smart card's internal operating system. This allows for autonomous monitoring without waiting for cloud-based instructions, and reduces the terminal-cloud interaction response time during monitoring, improving efficiency and timeliness. Furthermore, it eliminates the need for test traffic beyond service traffic, reducing the possibility of network resource contention and avoiding inaccurate monitoring due to inconsistencies between service and test traffic levels. Moreover, communication quality monitoring is achieved through a monitoring window when there are no service processing requests on the terminal, reducing lag and latency for users. Additionally, the monitoring task is broken down into multiple atomic steps, minimizing the impact of service interruptions. It allows for immediate pause and resumption without losing progress, continuing execution of the next atomic step in the next monitoring window, thus improving robustness.

[0040] The above steps are explained in detail below: Regarding S110, the traditional smart card acquisition process requires frequent communication status queries, which generates additional traffic and power consumption. Furthermore, during the copying of data from the smart card outside the smart card stack, in addition to generating additional traffic and power consumption, context switching, copying, and lock contention also occur. To prevent the data being modified from being copied, the data is locked, causing higher-priority transmission and reception operations in the protocol stack to wait for the acquisition program to finish reading and release the lock before continuing, resulting in lock contention. In this embodiment, considering the limited resources within the smart card, this disclosure proposes a ZBIT scheme to reduce the resource consumption of the acquisition module.

[0041] In one optional implementation, obtaining the communication link status data of the terminal where the smart card is located includes: Based on the page number and description information of the shared pages, a set of shared pages is determined; the shared pages are stored in a shared page memory pool. If a tail index exists in the shared page set, read the contents of the shared page set and calculate the checksum based on the reading result; the tail index is used to characterize the storage status of each data in the shared page set. If the checksum matches the verification checksum in the description information, the data stored in the shared page set is used as the communication link status data.

[0042] In this system, communication link status data is stored in shared pages, and data reading and writing are performed in pages as the smallest unit, preventing the occurrence of half-pages. This is because if data within a shared page is not completely written, a tail index will not be written, and thus that portion of the content cannot be recognized.

[0043] Here, the description information of a shared page can be metadata and a verification checksum. The metadata includes a timestamp and length. The page number is the industry-standard cursor. The verification checksum is used to verify whether the data has been corrupted during transmission or storage. The shared page memory pool is obtained by allocating controlled storage space within the smart card.

[0044] For example, all data is stored in a shared memory pool, and read-only probes are inserted at critical state transition points in the BIP protocol stack without moving the data payload, achieving zero-copy, lock-free, or low-locking operation. Furthermore, to monitor operational health, a small number of frame-level records can be stored in the shared pages, such as page corruption counts, sample loss counts, backpressure in / out counts, and high-water mark occupancy.

[0045] In a specific example, shared pages are arranged into a circular buffer, with multiple shared pages linked end-to-end to form a circular queue. When writing data, the data can be recorded in the form of a Type-Length-Value (TLV) record header. The data writer (producer) only writes the page cursor and the TLV record header, without data movement or memory copying; while the data reader (consumer) consumes data in page cursor order, naturally avoiding the additional overhead and jitter caused by memory copying (memcpy). For example, the data writer puts a shared page full of data into the queue from the tail, and the data reader takes a shared page from the head of the queue for processing. When the last page is read, it automatically returns to the first page to continue reading. Here, the data writer can be a protocol stack or kernel probe, and the data reader can be the inference side used to calculate communication quality scores.

[0046] In addition, to ensure multi-version compatibility and low parsing cost, all records use unified TLV encoding, and the timestamp uses a monotonic clock ts_mono (monotonic) with an additional drift correction field; the page header contains magic, version, pg_seq, crc and ts_base, which the data reader uses to complete cross-page splicing and exception skipping.

[0047] More specifically, to improve robustness and consistency, ZBIT adopts a commit order of writing data first, then the tail index for each page, and maintains page number pg_seq and verification code criterion in the page header. The write path is lock-free as much as possible, with the writer only briefly entering the critical section at page switching and high-water mark checks. The reader only reads the page content after seeing the tail index and verifying its consistency; if a half-written page or verification failure is encountered, it is skipped and the bad page count is incremented, subsequently reported along with the summary record. Lightweight memory barriers ensure sequential visibility for both readers and writers, avoiding prolonged blocking of critical business paths. For large records spanning multiple pages, such as one-time aggregated snapshots, ZBIT provides a page chaining mechanism, concatenating multiple physical pages using next pointers. Consumers read by chain and check the chain-level verification at the end; in case of an anomaly, the entire chain is discarded without affecting subsequent new pages.

[0048] Figure 2 A flowchart illustrating a data writing method according to an embodiment of this disclosure is shown. Figure 2 As shown, it includes steps S112 to S114.

[0049] S112. Perform event capture and package the event data into TLV format and perform point-to-point formatting. The system begins processing the event, packaging the data into TLV format and performing point-to-point formatting. Then, it checks if the remaining space on the current shared page is sufficient. It determines whether the remaining space on the current page is greater than or equal to the sum of the TLV data length and the tail index length. If so, execute S1131; otherwise, execute S1132.

[0050] S1131: Write the packaged and fixed-point data into the shared page and update the cursor within the page. Write the current TLV into the shared page and update the current write position.

[0051] S1132, Switch to a new page and write page header information. Switch to the new shared page and write page header information, such as page number pg_seq and timestamp base ts_base. After completing the writing or page switching, check if the current page usage has reached a high watermark, such as page space utilization exceeding a certain threshold. If so, execute S114; otherwise, return directly to S112 to continue processing the next event or wait for subsequent operations.

[0052] S114, Enter summary mode. Triggers summary generation, index building, or spatial organization.

[0053] Figure 3 A flowchart illustrating a data reading method provided in one embodiment of this disclosure is shown. Figure 3 As shown, it includes steps S116 to S117.

[0054] S116, Read the description information of the shared page. Starting from the current page, first read the page header information. Check whether the page's suffix and cyclic redundancy check (CRC) meet the requirements. If the suffix exists and the CRC check matches, execute S1171; otherwise, execute S1172.

[0055] S1171: Read data from the shared page and update the in-page read cursor. Consume the TLV data within the shared page sequentially according to the order of the in-page read cursors (read_cursor). After consuming all TLVs, update the position of the read_cursor. Check if the end of the page has been reached. If not, return to S1171 and continue consuming the next TLV. If the end of the page has been reached, advance to the next page and return to step S116 to continue processing the next page.

[0056] S1172, Determine that the current shared page is a bad page, skip the page and increment the bad page count.

[0057] Furthermore, to facilitate subsequent inference and threshold determination, link-related time-series metrics are uniformly processed using fixed-point methods (Q15 / Q7), and are displayed in a mixed layout of fixed-length and variable-length metrics within the shared page. Statistical operations for sliding windows such as EMA, quantile approximation, and median are completed using inline instructions to keep single-event processing at the 50-microsecond level and CPU usage less than 1%. During updates, features (RTT, Jitter, Loss, Throughput) are updated using sliding window incremental updates and fixed-point EMA. When the circular buffer usage exceeds the high-water mark threshold, ZBIT automatically enters summary mode, outputting windowed statistics and key counts at fixed intervals, pausing fine-grained event writing. After the usage drops back to the low-water mark, it automatically resumes detailed mode, thereby minimizing business latency and inference window gaps.

[0058] Furthermore, ZBIT enables online business modes based on lightweight discrimination of packet length distribution, packet interval, and direction sequence, identifying heartbeats, reporting, and large files to drive differentiated thresholds and policies. In terms of configuration and operation, ZBIT supports the distribution of collection policies (event white / black lists, sampling period and window size, high / low watermark thresholds, digest period, and maximum number of pages to retain) via Manifest, and provides runtime self-checks and probes (including CRC self-checks, bad page injection drills, and replay window baseline alignment), decoupling the collection layer from the inference layer. To facilitate end-to-end correlation, ZBIT includes lightweight identifiers such as device_id, slot_id, scenario_id, and tx_id in the TLV; all fields avoid user data and privacy information, retaining only anonymous indicators related to network quality, meeting the minimum necessary principle and compliance requirements. This provides stable and predictable input for PIPS slice inference, and maintains the overall availability and observability of the system under congestion and anomaly conditions through backpressure and digest mechanisms.

[0059] Thus, using the tail label as a clear marker for data writing completion, consumers only read data after the producer has completed the full data writing process, ensuring data integrity. Through a checksum comparison mechanism, only data with matching checksums is adopted as communication link status data, effectively detecting potential data corruption during transmission or storage. In this way, the producer is responsible for writing data and the tail label, while the consumer is responsible for verifying the tail label and checksum. Producers and consumers can cooperate securely without using mutex locks, avoiding the performance overhead and real-time jitter caused by lock contention. Furthermore, shared pages are stored in a pre-divided shared page memory pool. The set of shared pages is determined by page numbers and description information, achieving fixed-overhead memory management and reducing fragmentation issues caused by dynamic memory allocation and release. This enables high-throughput, low-jitter data planes on resource-constrained cards.

[0060] Involving S120 and S130, under current smart card RTOS, services have higher priority and stricter timing. However, in traditional communication quality detection processes, using fixed-period inference can interrupt services and introduce uncontrollable jitter, while using a low-priority background resident thread mode may lead to prolonged starvation under high load, resulting in unstable inference output, excessive tail latency, and even power consumption strategy failure. To address this issue, this disclosure proposes PIPS, which fully utilizes the predicted terminal idle time for inference without affecting service timing and low-power consumption strategies.

[0061] The S120 is mainly used to determine the total idle time after no service processing requests are received, so as to conduct communication quality monitoring during this period.

[0062] In one optional implementation, when there is no service processing request at the terminal where the smart card is located, the monitoring window is determined based on historical monitoring task interruption information and the predicted terminal idle time, including: If there is no business processing request at the terminal where the smart card is located, obtain the interruption information of historical monitoring tasks and predict the idle time of the terminal. The completion rate and interruption rate of historical monitoring tasks are calculated based on the interruption information of historical monitoring tasks. Based on the historical monitoring task completion rate and historical monitoring task interruption rate, the terminal idle time is corrected to obtain the monitoring window.

[0063] Here, the service in the service processing request can be the main service of the terminal where the smart card is located. For example, it can be Application Protocol Data Unit (APDU) processing, SIM card toolkit, or BIP state machine.

[0064] Here, the terminal idle time can be the predicted idle time provided by the kernel within the current prepare-to-sleep callback. The completion rate (CR) can be the number of atomic steps actually completed / the theoretical number of atomic steps that can be completed in the past M monitoring windows. The drop rate (DR) can be the percentage of atomic steps that were forcibly interrupted / abandoned in the past M monitoring windows.

[0065] In a specific example, the recent service interruption intensity L(t) is also introduced during the correction, which is determined based on the historical monitoring task interruption rate. L(t) can also represent the service busyness level. Relying on the tickless / prepare-to-sleep callback provided by the Real-Time Operating System (RTOS), the predicted idle time T_idle(t) is obtained before the system enters low power or prepares to sleep. The available time slice T_avail is estimated using the predicted idle time and the recent service interruption intensity, and the monitoring window T_slice(t) is obtained accordingly. Specifically, the monitoring window can be calculated using equation (1): T_slice(t)=clamp(T_min,T_max,αT_idle(t)-βL(t)) (1) Here, α and β are adaptive adjustment coefficients, which are automatically adjusted based on historical task completion rate and fragment loss rate (EMA). For example, T_min = 0.2ms, T_max = 1.0ms, and recovery timeout threshold = 2 × T_slice can be set. Clamp represents the limit function, which uses the lower and upper limits of the available time slices to prune the slices, avoiding the management overhead caused by excessively short slices or the blocking of sleep by excessively long slices.

[0066] In addition, a minimum working time can be set to avoid starting monitoring tasks during extremely short idle periods; a sleep protection margin T_guard can be set to ensure that the system can stably enter hibernation. For example, T_guard = 0.5ms. When the monitoring window is less than 0.5ms or there are no monitoring tasks, the system will directly enter hibernation.

[0067] In this way, interruption rates identify easily interrupted time periods, and the monitoring window is adjusted accordingly to avoid initiating monitoring during periods of high traffic or unstable channels, thereby reducing interference with normal user operations. Completion rates are used to adjust idle time, ensuring that the allocated monitoring window is sufficient to complete the expected atomic steps, reducing task interruptions or repeated restarts due to insufficient time, and improving the overall execution efficiency of monitoring tasks. Furthermore, real-time historical task statistics are used to dynamically adjust the monitoring window, allowing the smart card to adaptively select relatively stable monitoring periods under different traffic loads and network environments.

[0068] Involving S130, within the monitoring window of S120, the communication quality monitoring task is performed.

[0069] Before performing the communication quality monitoring task, this disclosure establishes a complete reasoning process corresponding to the communication quality monitoring task.

[0070] In a specific example, during inference, a multi-class logistic regression (Softmax) model is used, employing fixed-point integers and table lookups for computation, and outputting a communication quality score. Through fixed feature quantization, fixed-point multiplication and addition, selection of the most likely type, and calculation of the probability of the largest type using a table-lookup Softmax model, computational determinism and extremely low resource consumption are ensured.

[0071] For example, the communication quality score can be a risk level (risk_level) and a corresponding risk probability (risk_q15), where the risk probability is the Q15 probability, which is the Softmax probability of the selected risk level category.

[0072] First, a structured data structure is established, with input record fields collected by the S110. These record fields include the business scenario code (scenario, uint8), round-trip time (RTT, uint16, ms), the difference between two adjacent RTTs (jitter, uint16, ms), packet loss rate (packet_loss, stored in ppm, uint32, comma-separated values, conversion required for CSV), sliding window throughput (throughput, uint32, kbps), and session failure rate (session_fail_rate, stored in ppm, uint32). The final outputs are risk_level and risk. The risk level (risk_level) ranges from 0 to 3, corresponding to low, medium, high, and severe levels, respectively.

[0073] Secondly, the feature quantization module maps the original acquired features of different dimensions to a unified dimension of fixed-point integers, so that subsequent inference can be completed deterministically and with low power consumption on resource-constrained microcontroller units (MCUs).

[0074] In one embodiment, two read-only constants, offset[i] and mul_q15[i], are pre-set for each feature i. Both are fixed to Flash along with the model, where mul_q15 is a fixed-point scaling factor with a fixed-point number format of Q0.15. When implementing feature quantization, the units of each input are kept consistent with the acquisition caliber. For example, latency and jitter are in milliseconds, packet_loss and session_fail_rate are in ppm, throughput is in kbps, and scenario is encoded as a small integer. The quantization parameters are determined by offline statistics to ensure that the main interval of the training distribution falls within [-100, 100], thereby balancing accuracy and saturation safety. The quantization calculation is performed according to formula (2) to achieve the process of subtracting the baseline, multiplying by scaling, rounding, and saturation truncation.

[0075] q[i]=clip_int8(((x[i] offset[i])×mul_q15[i]+2^14)>>15)(2) Here, clip_int8 restricts the result to the Q7 interval [-128, 127] to avoid overflow; q[i] represents the feature vector of feature i; x[i] represents the original data of feature i.

[0076] Then, the linear discriminant value calculation module is used to perform fixed-point multiply-add operations for multi-class logistic regression, which are used to generate the linear discriminant score logit for each risk level.

[0077] In one embodiment, four types are preset based on the total type c, and a linear discrimination score is calculated for each type using fixed-point multiply-accumulate operations. The entire calculation involves only a constant number of integer multiply-accumulate operations and several additions, with fixed time and space overhead, meeting the real-time and auditability requirements of the smart card operating system. For example, 6×4 multiply-accumulate operations (MAC) can be used. The formula for fixed-point multiply-accumulate operations is shown in formula (3): z[c]=B[c]+Σ_iW[c,i]×q[i] (3) Among them, the weight W[c,i] is stored in Q7 (int8); the bias B[c] is stored in Q14 (int16), and the product naturally falls in Q14; the accumulation uses a 32-bit integer to prevent overflow; the size of z[c] represents the linear discrimination score corresponding to type c; type c has four subclasses, such as k, j, etc.

[0078] Then, the final risk level is output based on the maximum value of the classification score through the category selection module, ensuring that the judgment process is monotonous, definite and unambiguous.

[0079] In one embodiment, the linear discriminant scores corresponding to all types are iterated, and the linear discriminant score with the maximum value is taken as the risk level. When there is a tie for the maximum, in order to ensure that the output is repeatable and consistent with the training, a fixed priority order is adopted to select the type with the smaller index as the winning target type k, and the remaining types are the losing types, thereby avoiding oscillations and randomness in boundary cases. Specifically, the formula is as shown in equation (4): risk_level=argmax_c z[c] (4) Then, the probability calculation module is used to perform numerically stable fixed-point calculations on the relative confidence of the target type, outputting a probability score corresponding to the risk level. To avoid the cost and instability caused by exponential overflow and multiple divisions, in one embodiment, the probability score is calculated only for target type k. In implementation, Δ_j is first right-shifted by 4 bits from Q14 to obtain Q10 representation, and then the interval [-8,0] is truncated and mapped to the Q15 lookup table of e^x, for example, 2^8=256 items, covering the sparse tail, exp(≤ 8) Approximately 0. Then, sum all exp(Δ_j) and the constant term exp(0) to obtain the denominator, and then use integer division of Q30 / Q15 to obtain the Q15 representation of p_k, which is finally output as risk_q15. This path uses a lookup table instead of an exponential function, balancing efficiency and numerical stability. The main formula is shown in equation (5): p_k=1 / (1+Σ_{j≠k}exp(z[j] z[k]))(5) Where, Δ_j = z[j] z[k]≤0.

[0080] Finally, the inference results are written back to the endpoint recording and shared data area through the result output module, so that the upper-layer strategy and log links can directly consume them.

[0081] In one embodiment, after inference is completed, the risk level (risk_level) and probability score (risk_q15) are output and populated into the corresponding fields of the current record according to the collection criteria. Simultaneously, metadata such as the input timestamp and scenario are retained for subsequent CSV disk storage, online strategy decision-making, and remote diagnostics. The entire output process does not rely on dynamic memory, but is completed using static buffers or structure pointers provided by the caller, ensuring controllability and traceability in the RTOS environment.

[0082] Furthermore, to accommodate the limited computing resources of smart cards, the inference process can be implemented using a lightweight approach without the need for a third-party inference framework. This involves establishing an inference module based on fixed-dimensional, tabular features (scenario, latency_ms, jitter_ms, packet_loss, throughput_kbps, session_fail_rate) to achieve stable output of communication quality scores. It's worth noting that, when hardware conditions permit, other mature inference frameworks can also be used, such as TensorFlow Lite for Micro and the open-source TinyMaix. The model format can be replaced with other fixed-point auditable linear / tree models, but monotonic constraints and QSMR stabilization and order-preserving mechanisms must be retained.

[0083] It should be noted that, to constrain the jitter introduced by fixed-point quantization at the boundaries, this disclosure mandates non-negative weights for features positively correlated with risk (latency, jitter, loss, fail_rate) and non-positive weights for features negatively correlated with risk (throughput); the scenario uses grouped bias, and the constraints are generated and signed during training and consolidation. Input features are uniformly quantized using fixed-point quantization (Q7), and the logit uses Q7 / Q14 fixed-point multiplication and addition; the winning class probability uses Q15 lookup table and piecewise linear calibration to output risk_q15. Neighborhood order-preserving correction is performed on local boundary jitter to ensure monotonic non-decreasing of deterioration indicators. This improves consistency between the edge and offline modes by 3-6%, reduces false triggering in boundary scenarios by >30%, and achieves approximately 100% monotonicity satisfaction.

[0084] After defining the communication quality monitoring task, the above reasoning process is implemented in the monitoring window in a micro-time slice and atomic step preemptive manner to obtain the communication quality score.

[0085] In one optional implementation, within the monitoring window, the communication link status data of the terminal where the smart card is located is processed through multiple atomic steps corresponding to the communication quality monitoring task to obtain a communication quality score for the terminal where the smart card is located, including: Within the monitoring window, the first atomic step corresponding to the communication quality monitoring task is used to perform feature quantization on the communication link status data of the terminal where the smart card is located, and a feature vector is obtained. Through the second atomic step corresponding to the communication quality monitoring task, the feature vector is subjected to fixed-point multiplication and addition operations based on the parameter set corresponding to multiple risk types, and the target risk type and the failure risk type are determined according to the operation results. The communication quality score of the terminal where the smart card is located is calculated based on the deviation between the calculation results of the target risk type and the rejection risk type through the third atomic step corresponding to the communication quality monitoring task.

[0086] Here, atomic steps are used to achieve micro-time slices. These atomic steps are obtained by breaking down the above reasoning process after defining the communication quality monitoring task. For example, atomic steps can be feature quantization, linear discriminant analysis, probability scoring, and output backfilling. Feature quantization is used to standardize and quantize the original data; linear discriminant analysis and probability scoring are used to calculate the communication quality score; and output backfilling is used to output the final result.

[0087] More specifically, the first atomic step corresponds to the feature quantization module. The second atomic step corresponds to the linear discriminant value calculation module and the category selection module, where the category is the risk type, the winning category is the target risk type, and the losing category is the rejected risk type. The third atomic step corresponds to the probability calculation module, where the communication quality score is the risk level and the corresponding risk probability. The feature quantization module, linear discriminant value calculation module, category selection module, and probability calculation module have been detailed previously and will not be repeated here.

[0088] Furthermore, to complete the task within an extremely short and uncertain working window, each atomic step takes no more than 50 microseconds. Each atomic step corresponds to one atomic execution unit, and each atomic execution unit takes ≤50 microseconds.

[0089] In this way, by predicting the idle time, the entire quality monitoring task is completed by executing atomic steps with shortened execution time within the monitoring window. Multiple atomic steps help ensure that the atomic steps make full use of the idle time and avoid being arbitrarily affected by the main business; at the same time, they will not interfere with the sudden business due to excessive recklessness. The deterministic time slice and protection margin guarantee the priority of the business and significantly reduce the disturbance to the business sequence.

[0090] Furthermore, considering situations where the remaining time in the monitoring window is insufficient or the main business needs to be processed immediately, the same atomic step cannot be completed within the same monitoring window. Therefore, the arbitrary boundaries of the atomic step can be set to be interruptible, allowing the working time of the monitoring window to be given up for the business, and continuing from the interruption point in the next monitoring window.

[0091] In one optional implementation, the communication quality score of the terminal where the smart card is located is calculated based on the deviation of the calculation results between the target risk type and the rejection risk type through the third atomic step corresponding to the communication quality monitoring task, including: If a new business processing request is made or the remaining time of the monitoring window is less than the remaining execution time of the third atomic step, the third atomic step is interrupted and the interruption point is recorded. In the next monitoring window adjacent to the monitoring window, continue executing the third atomic step after the step interruption point to obtain the communication quality score of the terminal where the smart card is located.

[0092] It should be noted that in the above scheme, the first atomic step and the second atomic step are both completed within the monitoring window. When the third atomic step is executed in the monitoring window, it needs to be interrupted immediately and the interruption point needs to be recorded.

[0093] Of course, any atomic step should be able to be interrupted, so any boundary of the atomic step can be interrupted, while saving the step interruption checkpoint, and resuming the execution of the interrupted atomic step from the saved checkpoint in the next gap.

[0094] Here, the next monitoring window adjacent to the current monitoring window is generated in step S120. In other words, in this embodiment of the present disclosure, it is possible to continuously determine whether a business processing request exists. When no business processing request exists, a monitoring window is calculated, but when a business processing request is generated later, the atomic steps being executed in that monitoring window need to be interrupted. At this time, the monitoring window is no longer valid, and business processing must be prioritized. After the business processing is completed and no business processing request exists, a new monitoring window is calculated, that is, the next monitoring window adjacent to the current monitoring window, and the interrupted atomic steps continue to be executed within this monitoring window.

[0095] Figure 4A flowchart illustrating a communication quality monitoring task provided in one embodiment of this disclosure is shown. Figure 4 As shown, the communication quality monitoring task is implemented using a deterministic state machine. The state machine includes multiple states, and in each state, corresponding atomic steps are executed. When executing the communication quality monitoring task, it starts from the waiting state (IDLE), sequentially going through the quantization state (QUANTIZE), the scoring state (SCORE), the output state (OUTPUT), etc., until the final completion state (DONE). When a new service processing request is received or the monitoring window is exhausted, it enters the interruption state (PREEMPT), where the state machine immediately saves its state and waits for the next opportunity to continue executing the steps following the interruption. Specifically, the quantization state (QUANTIZE) corresponds to the quantization step, which includes at least one atomic step, such as the first atomic step; the scoring state (SCORE) corresponds to the scoring step, which includes at least one atomic step, such as the second atomic step; and the output state (OUTPUT) corresponds to the output step, which includes at least one atomic step.

[0096] Figure 5 This illustration shows a flowchart of the monitoring window establishment and communication quality monitoring task execution provided in one embodiment of this disclosure. Figure 5 As shown, steps S122-S135 are included. This process can be implemented through the QSMR module, ultimately outputting a communication quality score. Here, a first-in, first-out (FIFO) task queue is designed to manage pending communication quality monitoring tasks. The task queue not only ensures the fairness of task processing but also has an intelligent backpressure function: when there are too many pending tasks, the system will automatically filter and prioritize important and urgent data, discarding some redundant information, thereby preventing the system from crashing due to data congestion.

[0097] S122, enter the prepare-to-sleep callback to calculate the available time window. If there are no business processing requests, the system is about to enter a sleep state. At this time, the prepare-to-sleep callback is triggered, retrieving the estimated idle time T_idle from the system or prediction module. For example, the predicted CPU or event idle time. Then, calculate the available time window T_avail, where T_avail = T_idle - T_guard. If the available time window is greater than or equal to the minimum execution threshold, and the task queue is not empty, proceed to S123; otherwise, return directly to S135, and the system enters a sleep state.

[0098] S123, calculate the monitoring window using the adaptive weight formula. Calculate the dynamic time slice T_slice using formula (1), where α and β are the adaptive weights.

[0099] S132, according to the quality monitoring tasks, execute the corresponding atomic steps cyclically. Prioritize the execution of important and urgent quality monitoring tasks in the task queue, and limit the execution time of each atomic step. During the loop, continuously check whether the atomic steps are interrupted, such as when a business processing request occurs or the current monitoring window expires. If either condition is met, exit the loop and proceed to S133.

[0100] S133, save the current step breakpoint to maintain the current progress. After exiting the loop, save the breakpoint of the background task so that execution can be resumed next time.

[0101] S134, Update the adaptive weights of the monitoring window. Adjust α and β based on the current execution results for the next dynamic time slice calculation. For example, consider actual execution time, interrupt frequency, etc.

[0102] In this way, the task can be safely paused after any atomic step is completed. If an urgent task arrives at this time, the CPU will be immediately relinquished, and the interruption point will be remembered. When the next idle period arrives, execution will resume from the last interruption point. The entire process is flexible and does not lose computational progress, enabling efficient, stable, and unaffected intelligent inference on resource-constrained smart cards. Verification shows that this method has a <5% impact on business timing, an interruption recovery success rate >99.9%, and reduces inference tail latency by >60% compared to a fixed period, meeting audit and repeatability requirements.

[0103] Regarding S140, communication quality monitoring results can be used to characterize whether an alarm is needed. Specifically, the communication quality score can be compared to see if it meets preset alarm conditions. If it does, an alarm event is generated to facilitate alarm processing based on the alarm event. Accordingly, alarm decision-making is implemented within the smart card.

[0104] In a specific example, a multi-level threshold judgment is used to interpret and decide the communication quality score of the original output. Configurable probability thresholds are pre-stored, such as a normal alarm threshold p_warn=0.60 and a critical alarm threshold p_crit=0.80. These thresholds are securely stored in non-volatile memory (NVM) and can be remotely updated via encrypted APDUs. Furthermore, to prevent boundary jitter, a hysteresis bandwidth threshold δp=0.05 can be set. In addition, hysteresis logic can be introduced, with the trigger condition for a critical alarm being risk_q15≥Q15 or risk_level≥3, and the release condition being risk_q15≤Q15. Similar alarms are merged within a short period and enter a suppression window, generating only one alarm event and not retransmitting before the timer expires to avoid alarm storms. These alarm events can be generated at key hooks in the card-side BIP protocol stack.

[0105] After S140, when it is determined that an alarm needs to be issued, two types of actions are completed within the same execution unit: first, local processing is performed based on a lightweight rule table; second, a simplified uplink alarm message is generated and reported externally. The two actions are performed in parallel without blocking each other, aiming to solve the problem that traditional IoT terminals only issue alarms but do not report them and have rigid processing strategies.

[0106] In one alternative implementation, after obtaining the communication quality monitoring results based on the communication quality score, the method further includes: If the communication quality monitoring result indicates that the communication quality score meets the preset alarm conditions, then the preset instruction corresponding to the communication quality score and the service scenario type of the terminal where the smart card is located is obtained from the preset instruction mapping relationship. The preset instruction mapping relationship is used to characterize the communication quality score and service scenario type corresponding to each preset instruction. Execute preset instructions corresponding to the communication quality score and business scenario type to obtain the execution result; Alarm information is generated based on communication quality monitoring results and execution results.

[0107] Here, the business scenario type is called "scenario"; the preset instruction is called "action".

[0108] It should be noted that the recovery capability inside the smart card is atomically made through preset instructions. Each preset instruction is encapsulated as a function with a fixed ID and parameter structure, such as adjust_retry(count, interval). All preset instructions are designed to be idempotent and have a state rollback interface to ensure that the system can recover to the previous stable checkpoint when execution fails or the effect is not good.

[0109] The preset commands are local actions that the terminal or smart card can perform, including various security operations such as parameter adjustment, connection switching, status self-check, and service degradation. For example, they can also include adjusting retry / timeout parameters, triggering a connectivity self-check, switching primary / backup destination addresses, and recording black box and local prompts. Furthermore, preset commands can be stored in the form of a command library.

[0110] In a specific example, this disclosure establishes a rule table. When a risk warning is generated, a hierarchical action graph is built using a two-dimensional array embedded in the NVM. Using `risk_level` and `scenario` as indexes, the rule table directly queries the hierarchical action graph to retrieve a byte string containing a candidate preset instruction ID. This static lookup table-based design ensures that an initial decision response can be completed within tens of microseconds after receiving a risk signal, avoiding the overhead of complex logical judgments.

[0111] More specifically, the rule table is fixed in the form of a security configuration, and the matching items use only limited conditions, such as alarm type, level, scenario, and consecutive count threshold, to generate the currently required action plan in a deterministic order. A fixed-capacity lock-free circular queue is used to cache pending events; all objects are statically created, without using dynamic memory; the enqueuing end applies suppression windows to events of the same type / same scenario / same level to avoid storms; the processing end executes local actions first and then pushes outwards, ensuring local closed loop priority.

[0112] Furthermore, to ensure stability and effective information transmission, an alarm suppression and parallel processing mechanism was designed. The system maintains a hash-based recent alarm record table. When the hash value of a new alarm (risk_level, scenario) already exists within the suppression window (e.g., 30 seconds), the alarm is discarded, and only the counter is incremented. When a valid preset instruction is triggered, the execution request corresponding to the preset instruction is placed in a high-priority local execution queue and executed immediately by a state machine.

[0113] In this way, by establishing a mapping relationship between communication quality scores, business scenario types, and preset instructions, differentiated actions can be taken for different business scenarios and communication conditions, improving the accuracy and flexibility of the response. Furthermore, alarm information includes not only the original monitoring results but also the execution results of preset instructions, making the alarm information more contextually relevant and actionable, facilitating the operation and maintenance platform or operators to understand the current status and take further action.

[0114] Furthermore, in order to achieve intelligent and adaptive decision-making, the mapping relationship is adjusted based on the execution status of preset instructions to enhance the effectiveness of subsequent filtering of preset instructions.

[0115] In one alternative implementation, after executing preset instructions corresponding to the communication quality score and service scenario type, the method further includes: After the preset instructions corresponding to the communication quality score and business scenario type have been executed, obtain the communication link status data within the target time interval; The communication link status data within the target time interval is normalized to obtain the mapping adjustment coefficient; The mapping score between business scenario types and preset instructions is updated based on the mapping adjustment coefficient. The mapping score is used to characterize the degree of matching between business scenario types and preset instructions. The preset instruction mapping relationship is updated based on the updated mapping score.

[0116] In a specific example, a lightweight Contextual Multi-Armed Bandit model is introduced at the smart card end and implemented using the policy annealing concept.

[0117] For each (scenario, action) pair, a 32-bit floating-point Q-value is maintained as a mapping score between the business scenario type and the preset instruction, and stored in a two-dimensional array Q[S][A]. When a preset instruction needs to be selected from the candidate action list, the Epsilon-Greedy strategy is adopted. A random number r is generated. If r > ε, the candidate actions are traversed and the execution with the highest Q-value is selected; otherwise, an execution is randomly selected from the candidate actions for exploration. The key annealing mechanism is implemented by the formula ε_t = max(ε_min, ε_0 * decay_rate^t), where t is the execution count counter, ensuring that the exploration rate ε decays smoothly but does not fall below a minimum threshold ε_min, preserving long-term adaptability to environmental changes. After the action is executed, the system immediately starts a short observation window, such as monitoring the subsequent 3-5 BIP interactions. During this period, the mapping adjustment coefficient R is calculated using communication link status data collected by the ZBIT module. The formula is R = w1 * Δ(RTT_norm) + w2 * Δ(Loss_norm) + w3 * Δ(Success_Rate), where Δ represents the normalized improvement of the indicator. Finally, the Q value is updated using the incremental formula Q_new(s,a) = Q_old(s,a) + learning_rate * (R - Q_old(s,a)). All calculations employ fixed-point arithmetic to avoid floating-point overhead, ensuring efficient operation on resource-constrained MCUs.

[0118] The determination of preset instructions and the updating of mapping relationships can be implemented in the same CSEA module.

[0119] Thus, by adjusting the mapping score through execution result feedback, the dynamic optimization of the preset instruction mapping relationship is achieved. This allows the matching relationship between preset instructions and business scenarios to change with variations in the network environment, enhancing adaptability. Furthermore, the mapping adjustment coefficient obtained through normalization processing can quantitatively evaluate the actual effect of the just-executed preset instruction in the current scenario. Mapping scores with good results are increased, while those without are decreased, making subsequent preset instruction selection more accurate. Mean Time To Repair (MTTR) decreases by >25%, mishandling rate decreases by >20%, and the action set adaptively converges to a high-yield combination under multi-business modes.

[0120] In addition, smart cards can interact with external business systems. These external business systems include a cloud monitoring platform, a Trusted Service Manager (TSM) platform, a BIP gateway, and terminals. The cloud monitoring platform receives uplink alarms / indicators, drives system training backflow, and provides visualization. The TSM platform, as the chip's backend management system, is responsible for card management, task orchestration, and model update distribution, operating within the Issuer Security Domain (ISD) / Security Domain (SD). The BIP gateway carries uplink and downlink business data and alarms, forwarding them to the platform. The terminal is the counterpart to the BIP channel, initiating business requests. The external training system, serving as the offline training and deployment center for intelligent inference of the card's network quality monitoring tasks, aggregates, cleans, models, and versions the runtime data from the terminals, achieving a closed loop between data, models, and the card.

[0121] After receiving alarm information, it is necessary to report the alarm information to the cloud monitoring platform. This public reporting adopts a single-state machine approach with BIP as the priority and SMS as a backup.

[0122] In one optional implementation, after generating alarm information based on communication quality monitoring results and execution results, the method further includes: Establish a data channel between smart cards and the cloud; Alarm information is reported to the cloud via the data channel between the smart card and the cloud. In the event of a reporting failure, the alarm information is reported to the cloud via the signaling channel between the smart card and the base station.

[0123] Here, alarm information can be encapsulated into a compressed TLV, which contains a lightweight message with type, level, timestamp, risk score and key indicator snapshot, transaction number and CRC. The length is controlled and the bandwidth usage is constant, and it can be stably delivered on a limited link.

[0124] In a specific example, this disclosure creates an alarm event object and pushes it into a separate, low-priority reporting queue while executing preset instructions. The alarm event object contains a complete context, such as a timestamp, risk details, action ID, and execution result. This reporting queue is handled by another task, which first attempts to send a formatted TLV packet through the main BIP channel. If it fails consecutively (e.g., timeout or receiving a NACK), it automatically calls the underlying interface to encode the event content into a 7-bit or 8-bit format and sends it via the SMS-SUBMIT command through the SMS channel. Successful reporting is archived upon receipt; failed reports are retried up to the maximum limit or discarded upon expiration.

[0125] For example, when reporting is required, it can be done without relying on an external host or external network stack, by actively issuing commands such as SEND DATA through the BIP inside the smart card.

[0126] Thus, by adopting an asynchronous dual-queue design that prioritizes local execution and allows for parallel execution and reporting, inconsistencies caused by the separation of processing and transmission are avoided. This solves the latency issue in traditional models where recovery actions require waiting for cloud instructions, truly achieving efficient, intelligent, and resource-controllable autonomous closed-loop recovery on smart cards. Simultaneously, using the signaling channel as a backup channel enhances the success rate of reporting, ensuring reliable external status synchronization even when the main link is damaged.

[0127] Furthermore, the smart card's operating system can be remotely updated via an external training system. This external training system serves as an offline training and deployment center for intelligent inference in the card-side network quality monitoring task. It aggregates, cleans, models, and versions the operational data from the terminal, and distributes model parameter packages to the smart card's operating system, achieving a closed-loop update of data, models, and the card itself.

[0128] Accordingly, to facilitate updates to the smart card's operating system, the system is expanded to mimic the existing Radio Frequency SIM (RFM) and RAM systems of smart card systems. Externally distributed model parameter packages are reliably written into the card and switched to the effective version. The overall approach follows the remote file management principles of smart cards: file-based boundary, segmented writing, two-phase commit, and power-off recovery as core principles, reusing existing BIPs or SMS. The PPOTA transmission channel and APDU instruction set handle data transmission and security control. An independent model-specific file field, DF.MODEL, is allocated within the card. Internally, a dual-slot A / B structure stores the model text, while metadata and transaction control files are configured for version management and rollback. The update process begins with the platform issuing a Manifest to initiate a transaction. Then, the model text is written in segments according to offsets. Once full, integrity and signature verification are performed on the card side. If verification passes, a pointer switch atomically activates the new slot. If verification fails or an anomaly is detected in the health check window, the system rolls back to the old slot and records the reason. The module uses only statically allocated buffers and fixed-length files, without relying on dynamic memory, ensuring verifiability and determinism in resource-constrained and high-security scenarios.

[0129] Specifically, when laying out the card files and memory, a DF.MODEL file is created under the Master File (MF), containing three types of transparent files. The first is EF.MANIFEST (transparent EF, approximately 128–256 bytes), which stores the currently active slot marker active_slot, the standby slot marker stage_slot, the model version number model_seq, the creation time, the feature dimension / number of categories (should be 6 / 4), the quantization format (Q7 / Q14 / Q15), the length of each segment and CRC32, the signature algorithm and digest, etc. The second is EF.MODEL_A and EF.MODEL_B (transparent EF, each with 2–4KB reserved), which store the fixed-length packaged data of the model text. The third is EF.TXN (transparent EF, 32–64 bytes), which records the current transaction status (Idle / Downloading / Verified / Committed), the last written offset, the cumulative written CRC, and the last error code, for continuation or rollback during power failure recovery. During runtime, the inference module reads the contents of the corresponding slot based on the active_slot of EF.MANIFEST and maps them to constant arrays by offset (offset[6], mul_q15[6], W_cls[4][6], B_cls[4], exp_lut

[256] ), which are directly accessed from Flash / EF in read-only mode without needing to be moved to RAM.

[0130] The transport layer is segmented according to the RFM approach. Each segment carries a target slot marker, write offset, data block, and block CRC16. The card side verifies each block and writes it to EF.MODEL_stage, performing idempotent processing on out-of-order / duplicate blocks to ensure consistency under link jitter and retransmission. To adapt to SMS, the recommended length for the text segment is 120–160 bytes; the BIP can be relaxed to 512–1024 bytes. The typical total packet size is <1KB (including 512Bexp_lut), reserving up to 4KB slot volume for future expansion.

[0131] For security and policy control, update transactions are carried within the Global Platform Secure Channel (GP) or other security packages. Manifest signatures and sequence numbers are enforced to prevent rollback and forgery. The card maintains trust anchors and a minimum allowed version policy (min_major / min_seq); manifests that do not meet the policy are directly rejected. Both EF.MANIFEST and EF.TXN writes include CRC and version fields; any corruption is detected during power-on self-test and automatically reverts to a conservative, usable state. To reduce RAM pressure, segmented writes are performed while receiving data, using only a static buffer of 256–1024 bytes, eliminating the need for full packet caching.

[0132] In terms of resource and performance evaluation, the typical model text is approximately 600–800 bytes; the manifest is <200 bytes; 2KB per slot is sufficient for redundant storage. Both the write and verification processes are linear in time. The EF write rate is limited by the card memory medium and APDU round-trip time; under BIP, a complete update takes milliseconds to hundreds of milliseconds; under SMS, it takes several seconds due to segmentation and retries. The inference module reads the new slot constant with zero copy after activation, without introducing additional runtime overhead.

[0133] Figure 6 A schematic diagram illustrating the interactive process of updating a communication quality monitoring model according to an embodiment of this disclosure is shown. Figure 6 As shown, it includes at least steps S1 to S4. This is mainly achieved through interaction between the TSM platform, the external training system, the cloud monitoring platform, and the smart card's internal operating system. Alternatively, only the inference model can be updated; the inference model is primarily used to implement step S130.

[0134] S1. The model is trained and validated in the off-card training system. The training interaction process involves S11~S14, and the validation interaction process involves S15. The system continuously collects the inference output and processing results after going live, constructs a golden sample set for periodic replay, and monitors the deviation of online / offline indicators and data distribution drift. When a threshold is triggered (such as a drop in accuracy or a change in scene distribution) or a rule is set (such as monthly iteration), the next round of training and release is automatically started, and a complete version lineage (parameters, list, signature, evaluation report) is retained to ensure traceability and rapid rollback.

[0135] S11. Aggregate samples from the monitoring platform, obtaining operational metrics / events and alarm samples from the card. For example, receive standardized records: utc_ms, scenario, latency_ms, jitter_ms, packet_loss, throughput_kbps, session_fail_rate, risk, and risk_level. These samples are established using reported information. S12. Deduplicate data, align metrics, complete / remove anomalies, and complete labeling and quantization calibration. Specifically, perform time alignment, device deduplication, and outlier processing on multi-source data of standardized records, unify unit metrics (ms / kbps / ppm), remove missing and out-of-bounds samples, and merge sudden duplicate records from the same device / scenario to ensure the representativeness and consistency of the training samples. S13. Construct labels and samples. The risk_level is used as the main supervision signal, and risk(0..1) is used as the probability calibration reference. When there are external handling results (such as session failure, network switching), it is used to strengthen the labeling of positive and negative samples and generate a difficult sample set. The sample partitioning adopts a dual strategy of time stratification and device grouping (train / valid / test) to avoid information leakage, and class imbalance is alleviated by class weights or controlled undersampling. S14, feature processing and modeling are performed. The six-dimensional table features scenario, latency, jitter, loss, kbps, and fail_rate are retained. Logarithmic or piecewise scaling of kbps can be selected to suppress long tails. The model adopts multi-class logistic regression (Softmax, L2 regularization) with the goal of minimizing cross-entropy, combined with class weights and early stopping strategy. The evaluation index is macro / micro average F1, Top 1. Accuracy and stability (variance under different scenarios) are the main considerations, and temperature calibration is performed on the validation set to improve probabilistic interpretability. S15. Validation and consistency verification are completed through mirror inference comparison on the smart card side. The quantization caliber of q[i] is determined based on the execution status of the card side, and the offset and scaling factor mul_q15 of each feature are estimated offline to map the main interval of the training distribution to [-128, 127] of Q7; the floating-point weights and biases are converted to Q7 / Q14, and the validation set is compared item by item with fixed-point mirror inference to record the Top 1. Consistency rate and probability error (Mean Absolute Error, MAE): If the threshold is exceeded, the scaling or regularization intensity will be automatically adjusted back to ensure that the accuracy at the end side does not decrease significantly.

[0136] S2. Export and publish the model. The out-of-card training system generates a manifest and a model payload, which are submitted to the TSM platform for publication. After producing a validated model, the training pipeline generates a parameter package and manifest for the card, and uses a signature service to complete integrity and identity verification. The parameters are then organized into a two-part container (manifest and payload), which is delivered to the TSM platform or OTA via BIP or SMS. PP is issued to facilitate atomic switching on the card side based on update transactions. The manifest is a small TLV / CBOR structure, containing a custom magic word BIPM, package version pkg_version, model sequence number model_seq (monotonically increasing to prevent rollback), feature dimension feature_dim, number of classes num_classes, exponent lookup table width exp_lut_bits, segment lengths and CRC32 (offset, mul_q15, W, B, exp_lut), and signature algorithm (e.g., ECDSA). P256 or HMAC The model consists of SHA256 and the signature value; the model body is a fixed-length binary segment concatenated in the above order.

[0137] S3. Update the model on the card side, including S31~S34. S31: The TSM platform transmits the list to the ISD / management domain via the BIP gateway. The model management module on the card side verifies the capacity, signer, and policy. The TSM platform first issues the Start Update List APDU. The card side verifies the list's structure and policy. After successful verification, "Downloading" is written to EF.TXN, and "stage_slot" is set to an empty slot, while the data in that slot is erased. For example, the verification conditions are: feature dimension 6, number of categories 4, total length not exceeding the slot limit, model_seq newer than the current one, and the signer in the trust list. S32: The TSM platform issues the model text segment by segment. The card side writes it according to the offset and completes CRC / signature verification, marking the status as "Verified". The TSM platform sends segmented write commands sequentially or out of order based on offsets. The card side performs CRC16 verification and updates the EF.TXN progress for each block. When the cumulative write length reaches the total length declared in the manifest, the card side recalculates the full-text CRC32 and verifies the manifest signature; if successful, EF.TXN is set to Verified. In S33, the TSM platform issues a commit activation command, and simultaneously, the model management module atomically switches slots A and B and notifies the AI ​​prediction engine to load the new version. Internally, after the platform issues the commit activation command, the card side switches the active_slot in a two-phase commit: first, it updates the new version field and verification information in EF.MANIFEST, then atomically updates the active_slot pointer and sets EF.TXN to Committed; if any step fails, the pointer is immediately rolled back to maintain the old version. In the event of a power outage at any point in the process, upon restart, EF.TXN is read and the process automatically continues based on the status. Downloading continues to receive blocks, while Verified waits for commit or times out and rolls back, ensuring transaction semantics. In S34, the card side performs a health check. Within the window, quantization saturation / overflow / probability anomalies are monitored. Success is reported upon passing these checks; failure results in rollback to the old slot and a report of the reason. To prevent verifiable but unusable parameters (such as mismatched dimensions) from causing operational anomalies, a lightweight health check window (e.g., the first 100 inferences) is set after activation. This window tracks abnormal indicators such as the number of quantization saturation events, the number of logit overflow protection triggers, and whether the output probability is consistently 0 / 1. If these indicators exceed the limits, automatic rollback to the old slot is initiated, and the health check is marked as failed in EF.MANIFEST. The platform then triggers an alarm and reissues the data accordingly. Rollback does not clear data from the new slot, facilitating subsequent discrepancy diagnosis.

[0138] The card-side implementation employs a dual-slot transactional model update strategy. In S33, an RFM / RAM-style A / B slot segmented update and signature verification are used, with two-phase atomic activation, including post-activation health checks and automatic rollback, ensuring the algorithm can safely evolve on the card. Under DF.MODEL, EF.MODEL_A / B stores the model text, EF.MANIFEST stores metadata / signature / version / quantization caliber, and EF.TXN stores the transaction status. Segmented writing, block-level CRC16 and full-packet CRC32 verification, and atomic activation via pointer switching after successful signature verification are implemented. In S34, a health endorsement window (e.g., for the first 100 inferences) is set after activation, and anomalies such as quantization saturation, logit overflow, and constant probability are statistically analyzed. If an anomaly exceeds the threshold, the old slot is automatically rolled back and the reason is recorded. A minimum available version / trust anchor strategy is executed, with SCP02 / SCP03 secure channels providing support. This ensures recovery after power failure, and verifiable but unusable models are automatically rolled back within the window, significantly improving update success rate and online stability.

[0139] S4. Monitor communication quality at the card end. The terminal initiates a service APDU, and the card end calls the BIP protocol stack to establish a session and send and receive data. Execute step S110, where the BIP hook records time and status at the sending / receiving point, samples from the circular buffer, and organizes features. Execute steps S120 and S130 to obtain the risk level (risk_level) and corresponding risk probability (risk_q15) within the monitoring window. Execute step 140 and subsequent steps. If the risk level and risk probability are greater than the threshold, take action and report: alarm processing and reporting execute rule matching and debouncing, prioritizing the execution of preset instructions (retry / timeout, address switching, self-check), generating an alarm TLV and sending it to the BIP gateway through the uplink reporting channel. The gateway forwards it to the monitoring platform, archives it locally after receiving an ACK, and if BIP transmission fails, it uses SMS. PP is used for backup reporting. If the risk level and risk probability are less than the threshold, the merged record will only be locally merged and the event count will be persisted, without external reporting.

[0140] Following this, closed-loop feedback control and model iteration updates are implemented. The cloud monitoring platform continuously receives operational metrics / events, converts them into new samples, and feeds them back to the external training system. The external training system initiates model retraining according to a periodic or trigger-based strategy, generates the next version, and distributes it through the TSM platform, entering a new round of closed-loop operation.

[0141] Furthermore, business pattern identification can be expanded to include categories or thresholds / policies issued by the platform, while the SIM card retains the ZBIT and PIPS mechanisms. Alternatively, no machine learning judgment or proactive BIP alarms can be performed on the SIM card; it can only handle minimal data collection and transparent transmission. Alarm generation and classification are all completed on the host application or cloud platform, with the reporting link handled by the host-side network channel (HTTP / MQTT / SMS, etc.). This alternative places core intelligence and analysis functions in the cloud, circumventing the SIM card-integrated machine learning and proactive early warning scheme protected by this proposal. However, the trade-off is the loss of the core advantages emphasized in this proposal, such as SIM card autonomy and low-latency early warning.

[0142] In summary, this disclosure implements the entire process of data collection, judgment, decision reporting, and reporting within the smart card without generating any active test traffic. Both data collection and inference are embedded in the business fast path bypass, achieving high-fidelity, low-jitter timing characteristics with extremely low overhead, providing stable input for subsequent scoring and handling. Furthermore, it does not rely on platform triggering or command issuance; the card continuously collects data and performs real-time calculations in the BIP stack bypass, providing immediate alarms when risks occur. Compared to on-demand diagnostics, this significantly shortens alarm latency and can still operate in offline scenarios, while also enabling proactive communication quality monitoring. In short, this disclosure cleverly encapsulates network quality monitoring within the neutral carrier of the SIM card, decoupling the conflict between operator network optimization and the main business of terminal equipment, resulting in high promotional value and broad market prospects.

[0143] Figure 7 This is a schematic diagram of a communication quality monitoring device provided in an embodiment of this disclosure. Figure 7 As shown, the communication quality monitoring device 200 may include a data acquisition module 210, a window creation module 220, a monitoring module 230, and a generation module 240.

[0144] The data acquisition module 210 is used to acquire communication link status data of the terminal where the smart card is located; The window creation module 220 is used to create a monitoring window based on the interruption information of historical monitoring tasks and the predicted idle time of the terminal when there is no business processing request in the terminal where the smart card is located. The monitoring module 230 is used to process the communication link status data of the terminal where the smart card is located through multiple atomic steps corresponding to the communication quality monitoring task within the monitoring window, and obtain the communication quality score of the terminal where the smart card is located. The generation module 240 is used to obtain communication quality monitoring results based on the communication quality score.

[0145] Optionally, the window creation module 220 is also used for: If there is no business processing request at the terminal where the smart card is located, obtain the interruption information of historical monitoring tasks and predict the idle time of the terminal. The completion rate and interruption rate of historical monitoring tasks are calculated based on the interruption information of historical monitoring tasks. Based on the historical monitoring task completion rate and historical monitoring task interruption rate, the terminal idle time is corrected to obtain the monitoring window.

[0146] Optionally, the monitoring module 230 is also used for: Within the monitoring window, the first atomic step corresponding to the communication quality monitoring task is used to perform feature quantization on the communication link status data of the terminal where the smart card is located, and a feature vector is obtained. Through the second atomic step corresponding to the communication quality monitoring task, the feature vector is subjected to fixed-point multiplication and addition operations based on the parameter set corresponding to multiple risk types, and the target risk type and the failure risk type are determined according to the operation results. The communication quality score of the terminal where the smart card is located is calculated based on the deviation between the calculation results of the target risk type and the rejection risk type through the third atomic step corresponding to the communication quality monitoring task.

[0147] Optionally, the monitoring module 230 is also used for: If a new business processing request is made or the remaining time of the monitoring window is less than the remaining execution time of the third atomic step, the third atomic step is interrupted and the interruption point is recorded. In the next monitoring window adjacent to the monitoring window, continue executing the third atomic step after the step interruption point to obtain the communication quality score of the terminal where the smart card is located.

[0148] Optionally, the data acquisition module 210 is also used for: Based on the page number and description information of the shared pages, a set of shared pages is determined; the shared pages are stored in a shared page memory pool. If a tail index exists in the shared page set, read the contents of the shared page set and calculate the checksum based on the reading result; the tail index is used to characterize the storage status of each data in the shared page set. If the checksum matches the verification checksum in the description information, the data stored in the shared page set is used as the communication link status data.

[0149] Optionally, after obtaining the communication quality monitoring results based on the communication quality score, the generation module 240 is further configured to: If the communication quality monitoring result indicates that the communication quality score meets the preset alarm conditions, then the preset instruction corresponding to the communication quality score and the service scenario type of the terminal where the smart card is located is obtained from the preset instruction mapping relationship. The preset instruction mapping relationship is used to characterize the communication quality score and service scenario type corresponding to each preset instruction. Execute preset instructions corresponding to the communication quality score and business scenario type to obtain the execution result; Alarm information is generated based on communication quality monitoring results and execution results.

[0150] Optionally, after executing preset instructions corresponding to the communication quality score and business scenario type, the generation module 240 is further configured to: After the preset instructions corresponding to the communication quality score and business scenario type have been executed, obtain the communication link status data within the target time interval; The communication link status data within the target time interval is normalized to obtain the mapping adjustment coefficient; The mapping score between business scenario types and preset instructions is updated based on the mapping adjustment coefficient. The mapping score is used to characterize the degree of matching between business scenario types and preset instructions. The preset instruction mapping relationship is updated based on the updated mapping score.

[0151] Optionally, after generating alarm information based on communication quality monitoring results and execution results, the generation module 240 is further configured to: Establish a data channel between smart cards and the cloud; Alarm information is reported to the cloud via the data channel between the smart card and the cloud. In the event of a reporting failure, the alarm information is reported to the cloud via the signaling channel between the smart card and the base station.

[0152] Figure 8 A schematic diagram of the hardware structure of the communication quality monitoring device provided in an embodiment of this disclosure is shown.

[0153] The communication quality monitoring device may include a processor 301 and a memory 302 storing computer program instructions.

[0154] Specifically, the processor 301 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this disclosure.

[0155] Memory 302 may include mass storage for data or instructions. For example, and not limitingly, memory 302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 302 may include removable or non-removable (or fixed) media, or memory 302 may be non-volatile solid-state memory. Memory 302 may be internal or external to the integrated gateway disaster recovery device.

[0156] In one instance, memory 302 may be read-only memory (ROM). In one instance, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0157] Memory 302 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0158] The processor 301 reads and executes computer program instructions stored in the memory 302 to achieve... Figures 1 to 6 The communication quality monitoring method in the illustrated embodiment.

[0159] In one example, the communication quality monitoring device may further include a communication interface 303 and a bus 304. Wherein, for example... Figure 8 As shown, the processor 301, memory 302, and communication interface 303 are connected through bus 304 and complete communication with each other.

[0160] The communication interface 303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this disclosure.

[0161] Bus 304 includes hardware, software, or both, that couples components of a device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 304 may include one or more buses. Although specific buses are described and illustrated in embodiments of this disclosure, this disclosure contemplates any suitable bus or interconnect.

[0162] Furthermore, in conjunction with the communication quality monitoring methods in the above embodiments, this disclosure can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the communication quality monitoring methods in the above embodiments.

[0163] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the communication quality monitoring methods described in the above embodiments.

[0164] It should be clarified that this disclosure is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this disclosure is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this disclosure.

[0165] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this disclosure are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0166] It should also be noted that the exemplary embodiments mentioned in this disclosure describe methods or systems based on a series of steps or apparatus. However, this disclosure is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0167] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0168] The above description is merely a specific embodiment of this disclosure. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this disclosure is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this disclosure, and these modifications or substitutions should all be covered within the protection scope of this disclosure.

Claims

1. A communication quality monitoring method, characterized in that, Applied to smart cards, the method includes: Obtain communication link status data of the terminal where the smart card is located; When there is no business processing request at the terminal where the smart card is located, the monitoring window is determined based on the interruption information of historical monitoring tasks and the predicted idle time of the terminal. Within the monitoring window, the communication link status data of the terminal where the smart card is located is processed through multiple atomic steps corresponding to the communication quality monitoring task to obtain the communication quality score of the terminal where the smart card is located. The communication quality monitoring results are obtained based on the communication quality score.

2. The communication quality monitoring method according to claim 1, characterized in that, The step of determining the monitoring window based on historical monitoring task interruption information and predicted terminal idle time when there is no service processing request at the terminal where the smart card is located includes: If there is no business processing request at the terminal where the smart card is located, obtain the interruption information of historical monitoring tasks and predict the idle time of the terminal. The historical monitoring task completion rate and historical monitoring task interruption rate are calculated based on the interruption information of the historical monitoring tasks. Based on the historical monitoring task completion rate and the historical monitoring task interruption rate, the terminal idle time is adjusted to obtain the monitoring window.

3. The communication quality monitoring method according to claim 1, characterized in that, Within the monitoring window, the communication link status data of the terminal where the smart card is located is processed through multiple atomic steps corresponding to the communication quality monitoring task to obtain a communication quality score for the terminal where the smart card is located, including: Within the monitoring window, the first atomic step corresponding to the communication quality monitoring task is used to perform feature quantization on the communication link status data of the terminal where the smart card is located, to obtain a feature vector. Through the second atomic step corresponding to the communication quality monitoring task, the feature vector is subjected to fixed-point multiplication and addition operations based on the parameter set corresponding to multiple risk types, and the target risk type and the rejection risk type are determined according to the operation results. Through the third atomic step corresponding to the communication quality monitoring task, the communication quality score of the terminal where the smart card is located is calculated based on the deviation of the calculation results between the target risk type and the rejection risk type.

4. The communication quality monitoring method according to claim 3, characterized in that, The third atomic step corresponding to the communication quality monitoring task calculates the communication quality score of the terminal where the smart card is located based on the deviation of the calculation results between the target risk type and the rejection risk type, including: If a new business processing request is requested or the remaining duration of the monitoring window is less than the remaining execution duration of the third atomic step, the third atomic step is interrupted and the interruption point is recorded. In the next monitoring window adjacent to the monitoring window, the third atomic step continues to be executed after the step interruption point to obtain the communication quality score of the terminal where the smart card is located.

5. The communication quality monitoring method according to claim 1, characterized in that, The acquisition of communication link status data of the terminal where the smart card is located includes: A set of shared pages is determined based on the page number and description information of the shared pages; wherein the shared pages are stored in a shared page memory pool; If a tail index exists in the shared page set, the contents of the shared page set are read, and a checksum is calculated based on the reading result; the tail index is used to characterize the storage status of each data in the shared page set. If the verification code matches the verification code in the description information, the data stored in the shared page set is used as the communication link status data.

6. The communication quality monitoring method according to claim 1, characterized in that, After obtaining the communication quality monitoring result based on the communication quality score, the method further includes: When the communication quality monitoring result indicates that the communication quality score meets the preset alarm conditions, a preset instruction corresponding to the communication quality score and the service scenario type of the terminal where the smart card is located is obtained from the preset instruction mapping relationship. The preset instruction mapping relationship is used to characterize the communication quality score and service scenario type corresponding to each preset instruction. Execute the preset instructions corresponding to the communication quality score and the service scenario type to obtain the execution result; Alarm information is generated based on the communication quality monitoring results and the execution results.

7. The communication quality monitoring method according to claim 6, characterized in that, After executing the preset instructions corresponding to the communication quality score and the service scenario type, the method further includes: After the preset instructions corresponding to the communication quality score and the service scenario type have been executed, obtain the communication link status data within the target time interval; The communication link status data within the target time interval is normalized to obtain the mapping adjustment coefficient; The mapping score between the business scenario type and the preset instruction is updated based on the mapping adjustment coefficient, and the mapping score is used to characterize the degree of matching between the business scenario type and the preset instruction; The preset instruction mapping relationship is updated based on the updated mapping score.

8. The communication quality monitoring method according to claim 6, characterized in that, After generating alarm information based on the communication quality monitoring results and the execution results, the method further includes: Establish a data channel between the smart card and the cloud; The alarm information is reported to the cloud via the data channel between the smart card and the cloud. In the event of a reporting failure, the alarm information is reported to the cloud via the signaling channel between the smart card and the base station.

9. A communication quality monitoring device, characterized in that, The device includes: The data acquisition module is used to acquire communication link status data of the terminal where the smart card is located; The window creation module is used to create a monitoring window based on historical monitoring task interruption information and predicted terminal idle time when there is no business processing request at the terminal where the smart card is located. The monitoring module is used to process the communication link status data of the terminal where the smart card is located through multiple atomic steps corresponding to the communication quality monitoring task within the monitoring window, and obtain the communication quality score of the terminal where the smart card is located. The generation module is used to obtain communication quality monitoring results based on the communication quality score.

10. A communication quality monitoring device, characterized in that, The device includes: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the communication quality monitoring method as described in any one of claims 1-8.

Images