In-container mobile network stability enhancement method based on cross-system network pass-through

Abstract

This invention discloses a method for enhancing the stability of in-container mobile networks based on cross-system network pass-through. The host starts a mobile network coordinator and loads a forwarding component to intercept uplink and downlink traffic from the container's cellular interface. Traffic is distributed according to a feature-matching rule set, and a hierarchical transmission resource pool is constructed. The container assigns a first identifier to network-enabled applications and enables a network adaptation proxy and request routing module. When an application calls cellular capabilities, the proxy uploads the identifier and permissions to the coordinator for verification. If verification is successful, the request context is encapsulated and written to shared memory, synchronized to the coordinator by the routing module. The coordinator encapsulates cellular network data for delivery and sends a ready notification. The proxy reads the data through the shared data channel to complete the network update. The forwarding component captures uplink and downlink traffic and extracts process and identifier information, matching it with the rule set. If a match is found, the uplink is bound to a tunnel identifier, and the downlink is reset to a link identifier, which is then forwarded to the corresponding resource pool. If a match fails, the data packet is discarded.

Description

Technical Field

[0001] This invention belongs to the field of computer software development technology, specifically relating to a method for enhancing the stability of containerized mobile networks based on cross-system network pass-through. Background Technology

[0002] In host systems, container application compatibility through container technology has become the mainstream solution, and the basic capability of container applications and native host applications to concurrently access 4G / 5G mobile networks has been achieved. However, in existing technologies, core issues brought about by containerization, such as network virtualization isolation, cross-system state synchronization lag, compatibility conflicts between container network subsystems and container environments, and processing bottlenecks caused by resource contention, have not been fundamentally resolved: 4G / 5G networks for applications within containers frequently experience connection drops and drastic fluctuations in data transmission rates, resulting in stability far lower than native container systems.

[0003] Existing solutions suffer from the following main shortcomings: some solutions rely on command-line parameter configuration, such as fixed allocation of Cgroups resource quotas and static configuration of iptables rules, which cannot adapt to the dynamic changes in mobile networks; some solutions use traditional virtualization forwarding technologies, such as veth-pair and bridges, and simple NAT translation, which leads to increased network latency and increased throughput loss; a few solutions attempt to optimize through a single module, such as independent eBPF forwarding and local state synchronization, but lack cross-system end-to-end collaborative design, especially in areas such as permission coordination, application layer data parsing, and long-term connection keep-alive, making it difficult to fundamentally solve stability problems. Summary of the Invention

[0004] In view of this, the present invention provides a method for enhancing the stability of in-container mobile networks based on cross-system network pass-through. By building a cellular permission mapping system between the host and the container, a hierarchical network resource isolation pool and a kernel pass-through forwarding component, and based on cross-system physical network authentication, real-time cellular state synchronization injection, high-precision traffic rule matching and uplink / downlink pass-through forwarding mechanism, the method eliminates container virtual network forwarding and false network states, and achieves low-loss, high-reliability, and high-precision data transmission and network state adaptation for all network requests of container applications based on the real host 4G / 5G physical cellular links.

[0005] The method for enhancing the stability of in-container mobile networks based on cross-system network pass-through provided by this invention specifically includes the following steps:

[0006] The host starts the mobile network coordinator, deploys a loading and forwarding component between the network protocol stack and the mobile network data interface, intercepts uplink traffic from the container and downlink traffic from the cellular physical interface, and uses a built-in feature matching rule set to distinguish traffic based on the first identifier and permission verification results, and establishes a hierarchical resource pool for container mobile network transmission; the container assigns a first identifier to applications with network access permissions and starts the network adaptation proxy and request routing module.

[0007] When a container application initiates a mobile network capability call, the container network adaptation agent forwards the first identifier and the permissions to be verified to the mobile network coordinator for verification. If the verification fails, the network adaptation agent terminates the network request; otherwise, the network adaptation agent encapsulates the permission verification result, the first identifier, and the network request parameters into a request context data packet and writes it to shared memory, which is then synchronized to the mobile network coordinator by the request routing module. The mobile network coordinator encapsulates the mobile network data corresponding to the application into a state synchronization data packet, sends a ready notification, and then distributes the data. After receiving the notification, the network adaptation agent reads the data from the shared data channel. The network adaptation agent uses the state synchronization data packet to update the relevant parameters of the virtual network interface card, verifies network connectivity, sets the application to prioritize the use of the host network, and then pushes the change broadcast.

[0008] When a container application sends a data packet, the forwarding component intercepts the uplink traffic to obtain core parameters and the application process identifier. When the network interface receives the data packet, the forwarding component intercepts the downlink traffic to determine the target application's first identifier and application process identifier. The data packet is compared with the feature matching rule set. If a match is successful, the comparison is terminated. For uplink data packets, the cellular tunnel identifier is bound, and the corresponding hierarchical resource pool is allocated according to the traffic type before forwarding to the network interface. For downlink data packets, the corresponding hierarchical resource pool is allocated, and then the packet is sent to the target container network space and the link layer identifier is reset. If a match fails, the data packet is discarded.

[0009] Furthermore, the hierarchical resource pool is divided into a high-priority service sub-pool, a normal-priority service sub-pool, and a system network process sub-pool based on the network priority of the container application, corresponding to high-priority applications, normal-priority applications, and underlying network service processes, respectively.

[0010] Furthermore, the rule types in the feature matching rule set include tunnel transmission protocol, mobile communication control plane, general user IP and service permission association. Each rule adopts a fixed-length storage structure to record the communication protocol, transceiver port, bidirectional address, tunnel identifier, first identifier, authorization validity and wireless link status, and reserves expansion space.

[0011] Furthermore, the kernel forwarding component sets up forwarding queues, each hierarchical resource pool is configured with an independent forwarding queue, each queue is configured with a differentiated capacity threshold based on the wireless link status, a first-in-first-out scheduling method is adopted, and scheduling weights are allocated according to application priority; when the queue occupancy reaches the threshold, low-priority data packets are dropped first.

[0012] Furthermore, a hierarchical load balancing collection unit is deployed within the container to continuously collect application operation data at fixed intervals for hierarchical resource pool groups. This data includes the total number of cellular transmission connections, real-time uplink and downlink throughput, data packet retransmission ratio, frequency of permission changes, and number of network request failures. The collected data is encapsulated into hierarchical load balancing feedback data packets and synchronized to the mobile network coordinator.

[0013] The kernel forwarding component has a built-in hierarchical traffic statistics unit that counts uplink and downlink forwarding success rates, average forwarding latency, queue congestion frequency, and rule matching anomalies according to the hierarchical resource pools. The host collects the computing power usage, buffer memory usage, and resource temporary borrowing and release frequency of each hierarchical resource pool, and generates resource statistics snapshots at fixed intervals for the mobile network coordinator to read.

[0014] After obtaining hierarchical load feedback packets, traffic statistics, and resource usage snapshots, the mobile network coordinator performs adaptive control: when the throughput rate of a high-priority sub-pool is lower than the threshold or the packet retransmission rate is higher than the threshold, the collection frequency of cellular dynamic network indicators is increased; if the system network sub-pool modulation and demodulation instruction processing delay is greater than the threshold, the scheduling authority of the underlying network process is increased, and the collection frequency of cellular access configuration parameters is increased.

[0015] Furthermore, when a container application initiates a cellular network transmission, it identifies the currently used cellular link and uses the obtained network connectivity status and gateway response identifier as the basis for judgment. The link connectivity determination prioritizes reading the injected physical cellular data link status, and when wireless link switching causes data stream interruption or increased transmission latency, the data reading waiting time is extended.

[0016] Create physical network anomaly classification identifiers to distinguish between cellular link failures such as wireless handover and access configuration changes; after capturing physical network anomalies, push network status change notifications to drive the application to execute adaptation and recovery logic, and re-initiate transmission after the wireless link stabilizes.

[0017] Furthermore, the system builds cellular network status monitoring capabilities, enabling applications to receive real-time notifications of network changes such as cellular link connectivity, link congestion, and link disconnection after registration.

[0018] Furthermore, the container network is equipped with a long-connection service registration capability. When an application registers, it submits its first identifier and default heartbeat sending cycle. After the host completes the network access permission verification, it binds the corresponding application's first identifier and stores all long-connection configuration information, which is then synchronized to the mobile network coordinator. The mobile network coordinator has a built-in long-connection status record table to record the establishment time of each long connection, the most recent heartbeat sending and receiving time, real-time transmission latency, and wireless link status. The data refresh cycle is the same as the physical network status collection cycle.

[0019] Furthermore, when the number of invalid network permission verifications for the application corresponding to the first identifier exceeds the threshold, and the number of network request failures for the application exceeds the threshold, it is determined that a permission abnormality fault has occurred; if the number of interrupted long-connection services in the same hierarchical resource pool exceeds the threshold, and the duration of physical cellular network base station handover exceeds the threshold, it is determined that a batch long-connection fault has occurred.

[0020] In response to permission anomalies, the mobile network coordinator first refreshes the global permission cache. If the cache repair fails, it rebuilds the corresponding application permission mapping entry. If the failure persists, it isolates the application's traffic resources and restarts the container network adaptation proxy. After the repair is completed, it issues a permission recovery broadcast notification, removes the network access rate limit for the application, and updates the permission verification status identifier synchronously.

[0021] For batch long connection failures, the mobile network coordinator clears the congested packet cache in the hierarchical resource pool and batch resets failed cellular tunnel sessions; if the connection interruption is caused by resource exhaustion, the computing power and buffer memory of the corresponding hierarchical resource pool are temporarily expanded; if the link is still not restored, the feature matching rule set of the reload forwarding component is used to complete the repair.

[0022] Furthermore, a memory usage limit and a warning and reclamation threshold are set for each type of sub-pool. The memory reclamation mechanism is activated when the memory usage is not less than the warning threshold. Each sub-pool is configured with a dedicated CPU core binding range and differentiated computing power scheduling weights. High-level real-time scheduling permissions are configured for system network processes and high-priority applications, while ordinary applications adopt a time-sharing scheduling mechanism.

[0023] Beneficial effects:

[0024] This invention first initiates a mobile network coordinator on the host, establishing a cellular network permission mapping relationship between container applications and the host. Before container startup, a kernel forwarding component is deployed and a hierarchical priority network resource pool is built. Simultaneously, a unique network identifier is assigned to all container network applications, and network adaptation and routing capabilities are enabled. When a container application initiates a network request, the system blocks the container's virtual network permission verification logic. The container reports its application identifier and permission information to the host to complete physical cellular network authentication. After successful authentication, the request context data is encapsulated and synchronized to the host via a cross-domain channel. The native virtual network process is blocked, and timeout retries are supported. After receiving the request data, the host coordinator reads the corresponding application's real-time data pre-collected by the kernel. The system tracks real-time cellular network metrics, differentiates and synchronizes static and dynamic network states, generates state synchronization data packets, and distributes them to containers. Containers inject real physical network states by overriding virtual network information, resetting link priorities, and rewriting state query logic, and then broadcast network state change information. Based on the kernel forwarding component, it performs unified interception of uplink and downlink traffic, multi-layer packet parsing, and precise matching of multi-dimensional rule priorities. It encapsulates legitimate traffic through cellular tunnels, performs direct forwarding through physical interfaces, and accurately delivers container processes. Abnormal and unauthorized traffic is directly discarded, enabling container application traffic to bypass virtual bridge forwarding and achieve reliable, low-loss, and high-precision transmission based entirely on real physical 4G / 5G cellular links. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating the method for enhancing the stability of intra-container mobile networks based on cross-system network pass-through provided by the present invention. Detailed Implementation

[0026] The present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0027] The core idea of ​​the container-based mobile network stability enhancement method based on cross-system network pass-through provided by this invention is as follows: First, the host starts the mobile network coordinator to establish a cellular network permission mapping relationship between the container application and the host. Before the container starts, a kernel forwarding component is deployed and a hierarchical priority network resource pool is built. At the same time, a unique network identifier is assigned to all container network applications and network adaptation and routing capabilities are enabled. When a container application initiates a network request, the system blocks the container's virtual network permission verification logic. The container reports the application identifier and permission information to the host to complete physical cellular network authentication. After successful authentication, the request context data is encapsulated and synchronized to the host through a cross-domain channel. At the same time, the native virtual network process is blocked and timeout retries are supported. The host coordinator receives the request... After obtaining the data, the system reads the corresponding application's real-time cellular network metrics pre-collected by the kernel, differentiates and synchronizes static and dynamic network states, generates state synchronization data packets, and sends them to the container. The container injects the real physical network state by overriding virtual network information, resetting link priorities, and rewriting the state query logic, and broadcasts network state change information to the outside world. Based on the kernel forwarding component, the system performs unified interception of uplink and downlink traffic, multi-layer packet parsing, and precise matching of multi-dimensional rule priorities. For legitimate traffic, it performs cellular tunnel encapsulation, physical interface direct forwarding, and precise delivery to container processes. Abnormal and unauthorized traffic is directly discarded, enabling container application traffic to be bypassed by virtual bridge forwarding and achieve reliable, low-loss, and high-precision transmission based entirely on real physical 4G / 5G cellular links.

[0028] The stability enhancement method for in-container mobile networks based on cross-system network pass-through provided by this invention has the following processing flow: Figure 1 As shown, the specific steps include:

[0029] Step 1: Start the mobile network coordinator within the host to establish a permission mapping table between the container application's full lifecycle mobile cellular network permissions and the host's network permissions. Before the container starts, the mobile network coordinator loads and deploys a kernel forwarding component between the kernel network protocol stack and the physical cellular data interface to intercept the container's outgoing uplink traffic and cellular network downlink traffic. It has a built-in fixed feature matching rule set conforming to mobile communication industry standards to distinguish traffic based on the container application's network identifier and permission verification results. A resource pool is built for the container's 4G / 5G cellular transmission, which is divided into a high-priority service sub-pool, a normal-priority service sub-pool, and a system network process sub-pool according to the application's network priority, corresponding to high-priority applications, normal-priority applications, and underlying network service processes, respectively. All container applications with network access permissions within the container are assigned a globally unique container application network identifier during the deployment and installation phase, and the network adaptation proxy and request routing module are started.

[0030] Among them, the full lifecycle permissions of container applications for mobile cellular networks include permissions such as basic network access, obtaining network status, obtaining wireless network information, and modifying network settings.

[0031] The container application network identifier is 16 bytes long. The first part is the container instance number, the middle part is the unique hash digest of the business program, and the last part is the network access type distinguishing code. The distinguishing code is used to distinguish between 4G dedicated, 5G dedicated, and general cellular networks. The container application network identifier is encrypted and persistently stored. The encryption key is dynamically managed by the system security component to prevent the identifier configuration from being tampered with.

[0032] The fixed feature matching rule set is divided into four categories: tunnel transmission protocol, mobile communication control plane, general user IP, and service permission association. Each category supports up to 256 independent entries. Each rule uses a unified fixed-length storage structure to record matching fields such as communication protocol, transceiver port, bidirectional address, tunnel identifier, service-specific network identity, authorization validity, and wireless link status, with reserved expansion space. Tunnel-related identifiers are updated periodically by the mobile network coordinator in real time based on the cellular link status. The control plane and user plane address ranges are taken from the synchronously issued operator network configuration. The service permission association rules correspond one-to-one with the protocol, address, port, service identity, and valid permissions carried in a single request. The rule set supports uninterrupted dynamic updates in the background. When operator parameters or authorization status change, a double-buffering switching mechanism is used to load new rules.

[0033] Furthermore, the system configures dedicated computing power binding ranges for each sub-pool of the resource pool, and uses a computing power weighting mechanism to achieve fine-grained allocation of computing power resources, fixing the allocation of designated core resources to the corresponding sub-pools. The mobile network coordinator identifies all network-related application processes within the container, classifies them according to service priority, and assigns the system's underlying network service processes, high-priority service processes, and ordinary service processes to their respective sub-pools for isolated operation. The system adjusts the process scheduling strategy of each sub-pool in a tiered manner, configuring high-level real-time scheduling permissions for system network processes and high-priority services, while ordinary services adopt the conventional scheduling mechanism, ensuring that core cellular network services have priority access to computing power scheduling resources and eliminating scheduling waiting latency.

[0034] Furthermore, a fixed amount of physical memory is allocated as dedicated memory for container cellular transmission, and it is split into independent resources according to service priority, for high-priority service data transmission, ordinary service data transmission, and underlying network service buffering respectively; a memory usage limit and warning reclamation threshold are set for each type of sub-pool, and the memory reclamation mechanism is automatically activated when the memory usage reaches the warning threshold; the network buffering capacity is adjusted differently for different sub-pools, and the underlying system network process is configured with a maximum number of connections and a larger send / receive buffer; high-priority services are equipped with medium-specification buffer parameters; ordinary services use lightweight buffer configuration to match the throughput requirements of various services.

[0035] Furthermore, the dedicated memory for each sub-pool is locked in physical memory throughout the process, and will not be transferred to the swap partition to cause latency fluctuations. In addition, the memory area is access isolated, and can only be read and written by the corresponding internal processes of the sub-pool.

[0036] Step 2: When a container application initiates a mobile network-related capability call, the container's local verification logic switches to physical network-specific verification, and it no longer reads the container's virtual network permission record. The container network adaptation proxy forwards the container application's network identifier and the permissions to be verified to the host mobile network coordinator to complete the physical network authorization verification. The host mobile network coordinator sends the verification result back to the network adaptation proxy. If the verification fails, the current network request is terminated and a permission exception is thrown. If the verification passes, the pre-allocated container application network identifier is read, network request parameters are collected, and the verification result, container application network identifier, and network request parameters are encapsulated into a request context data packet and written to the container's dedicated isolated shared memory.

[0037] The container-side request routing module listens for write events to shared memory, captures data packets, and synchronizes them to the host mobile network coordinator via a cross-domain communication channel. The synchronization temporarily blocks the container's native virtual network processing flow, sets a maximum waiting time limit, and executes a set number of retry logics if no host link readiness feedback is received within the time limit.

[0038] The network request parameters include the target IP address, transport protocol type, request priority, data transmission direction, and request timeout. The request context packet is in big-endian byte order and has a total length of 68 bytes.

[0039] Step 3: The host mobile network coordinator receives the request context data packet, extracts the application network identifier, network access type, and permission verification result from the data packet, and reads the pre-collected real-time mobile network metrics corresponding to the application from the kernel ring cache. It then filters the mobile network data corresponding to the application. Static parameters such as IP, domain name server, and cellular access configuration are only synchronized when the content changes, while dynamic metrics such as signal strength, transmission latency, and wireless connection status are continuously pushed at fixed intervals. When a request is received, the latest snapshot is synchronously sent. The cross-domain bidirectional communication channel is reused to transmit data, and the mobile network data is encapsulated into a state synchronization data packet, which consists of a checksum and a service data segment. Before sending, a ready notification is sent through an independent control channel. After receiving the notification, the container-side network adaptation agent reads the state synchronization data packet from the shared data channel.

[0040] After the network adaptation agent receives the status synchronization data packet, it overwrites and replaces the original virtual network card network information in the container, and synchronously updates the wireless signal parameters, data link connectivity status, operator configuration, and service permission activation flags. The container network management component completes connectivity verification based on the injected data, adjusts the network link priority sorting rules, sets the physical cellular link as the highest scheduling priority, and ensures that the application uses the host hardware cellular network first. Various network status and permission query logics are rewritten, and the real mobile network data issued by the host is uniformly returned when the service queries.

[0041] After the container network adaptation agent completes state injection, it pushes a broadcast notification of network state changes carrying complete and real cellular parameters. Upper-layer services can obtain information on signal strength, link connectivity, and permission changes in real time through the state monitoring mechanism.

[0042] Step 4: When the data packets generated by the container application are sent out through the container's internal protocol stack and virtual interface, the kernel forwarding component intercepts the uplink traffic and captures the data packets; it parses the header information of the link layer, network layer, and transport layer layer layer by layer, extracts core parameters such as communication address, port, and protocol type, and queries the fixed feature matching rule set according to the packet sending application process identifier to match the corresponding business container network identifier and authorization status.

[0043] After the cellular hardware interface receives and processes external data packets, the kernel forwarding component intercepts downlink traffic and captures the data packets; the encapsulated tunnel data packets are stripped of the outer tunnel header to extract the tunnel identifier, while the ordinary control plane data packets are parsed for network and transport headers, and the target application's container application network identifier and process identifier are matched in reverse based on the data packet address and port;

[0044] Data packets are compared against a fixed set of matching rules in a fixed priority order. Priority is given to verifying the business traffic rules bound to permissions, followed by the rules for tunnel transmission, mobile communication control plane, and general user IP. The comparison ends when a single data packet is successfully matched. Data packets with no matching rules or invalid permissions are discarded directly, and corresponding abnormal statistics records are retained.

[0045] After the rule matching is successful, the uplink traffic binds the cellular tunnel identifier to the data packet and sends it to the physical cellular hardware interface; the downlink traffic locates the target container process according to the network identity of the service container, sends the data packet to the corresponding container network space and binds it to the target application process, and simultaneously resets the link layer identification information to adapt to the internal network environment of the container.

[0046] Furthermore, the kernel forwarding component sets up a forwarding queue. This queue has differentiated capacity thresholds based on the synchronously acquired wireless link status and employs a first-in, first-out (FIFO) scheduling method, allocating scheduling weights according to application priority. When the queue reaches its threshold, low-priority data packets are discarded first to prevent queue overflow and packet loss. The matching process uses a full-field precise comparison method, sequentially verifying the protocol, port, address, service identity or tunnel identifier, and authorization status.

[0047] Furthermore, addressing the issue that fixed static parameters across the entire link cannot adapt to real-time fluctuations in cellular network scenarios, this invention receives three types of information: traffic forwarding operation metrics, dedicated resource usage data, and service permission activation status. It then dynamically adjusts the network status collection frequency, forwarding queue capacity threshold, and resource scheduling upper and lower limits in reverse to achieve end-to-end adaptive control. The specific process includes:

[0048] A hierarchical load balancing unit is created within the container, and operational metrics are collected according to three resource sub-pools: high priority, normal priority, and system network. These metrics include the total number of cellular transmission connections in each sub-pool, real-time uplink and downlink throughput, data packet retransmission ratio, frequency of permission changes, and number of network request failures. Data is continuously collected at fixed intervals, hierarchical load balancing feedback data packets are encapsulated, and cross-domain channels are reused to synchronize the data to the host mobile network coordinator.

[0049] The kernel forwarding component creates a hierarchical traffic statistics unit to count uplink and downlink forwarding success rates, average forwarding latency, queue congestion frequency, and rule matching anomalies according to resource sub-pools; the host resource management component's sub-pool resource monitoring unit continuously records the computing power usage, memory cache usage, and resource temporary borrowing and release frequency of each sub-pool; and generates statistical snapshots at fixed intervals, which are read by the mobile network coordinator.

[0050] After the host mobile network coordinator obtains load feedback, forwarding statistics, and resource usage data, it executes fixed threshold-based control logic for different sub-pools. When the throughput rate and packet retransmission rate of high-priority sub-pools reach the set threshold, the refresh frequency of cellular dynamic indicator collection is increased; when the service load decreases and the transmission quality is stable, the collection cycle is reduced to reduce kernel collection overhead; when the system network sub-pool modulation and demodulation instruction processing latency exceeds the standard, the collection frequency of permission and cellular access configuration parameters is increased; when the link processing latency is low, the normal collection cycle is restored.

[0051] The queue limit is adjusted based on the wireless link operation status and sub-pool congestion statistics. When high-priority and ordinary-priority sub-pools experience continuous queue congestion, the queue length is appropriately increased; when there is no congestion for a long period of time, the queue capacity is reduced; the data packet forwarding service is not interrupted throughout the parameter update process.

[0052] When the memory cache of a high-priority sub-pool is occupied for a long period of time and traffic continues to rise, the memory expansion limit is increased; when computing power is idle for a long period of time and business traffic fluctuations are stable, the temporary computing power borrowing limit is relaxed; when the system network sub-pool modulation and demodulation instruction processing latency continues to exceed the standard, the temporary computing power borrowing limit is increased, and the original scheduling threshold is restored after the link recovers and stabilizes; all adjusted scheduling thresholds are persistently saved in partitions and automatically loaded and taken effect after the device restarts.

[0053] Furthermore, to address the issue of inconsistencies between the virtual network state within a container and the real cellular physical network information, which can lead to errors in upper-layer business data parsing and abnormal logical judgments, this invention provides transmission data for upper-layer services by outputting the original business data packets during the traffic forwarding stage. The physical network state synchronization injection stage injects real link metrics, providing accurate network judgment criteria for upper-layer data parsing and business logic analysis. The specific implementation process is as follows:

[0054] To improve web access capabilities, a physical link judgment branch is added. When identifying the current hardware cellular link used by the service, the real network connectivity status and gateway response identifier are directly used as the judgment basis, instead of relying on the container virtual interface status. This can accurately distinguish real network anomalies such as traffic throttling and congestion on the operator side, and avoid the service misjudging network failures and making meaningless repeated requests.

[0055] A new logic for verifying the real link connectivity of socket communication capabilities has been added. The link connectivity determination prioritizes reading the injected physical cellular data link status. When wireless link switching causes a brief interruption of the data stream and a significant increase in transmission latency, the data reading waiting time is automatically extended to prevent the service from prematurely throwing read / write exceptions.

[0056] A new dedicated physical network anomaly classification identifier has been added to distinguish cellular link-specific faults such as wireless handover and access configuration changes. A global anomaly capture and processing mechanism is also provided to push network status change notifications after capturing physical link-specific anomalies, guide services to execute adaptation and recovery logic, and wait for the wireless link to stabilize before re-initiating transmission.

[0057] The application's basic operating framework now includes a new capability to monitor real cellular network status, providing standardized status monitoring callback capabilities. Businesses can register to receive real-time notifications of real network changes such as cellular link connectivity, link congestion, and link disconnection, replacing the original monitoring mechanism that could only read virtual network card information.

[0058] Furthermore, for TCP long-connection business scenarios such as instant messaging and IoT connections, issues such as heartbeat packet loss, connection timeout misjudgment, and long-connection disconnection caused by wireless link switching in container environments are addressed in this invention. The kernel pass-through forwarding link ensures priority transmission of heartbeat packets, the network status synchronization link provides transmission latency and wireless connection management status as the basis for adjusting keep-alive parameters, and the end-to-end feedback adjustment mechanism continuously optimizes the long-connection scheduling parameters. The implementation process is as follows:

[0059] The container network management component extends the long-connection service registration capability. When registering a service, it submits its own identity and default heartbeat sending cycle. After the system completes the network access permission verification, it binds the corresponding service-specific network identifier and stores all long-connection configuration information, which is then synchronized to the global mobile network coordinator. The coordinator builds a long-connection-specific status record table to record the establishment time, most recent heartbeat sending and receiving time, real-time transmission latency, and wireless link status of each long-connection. The data refresh cycle is consistent with the physical network status collection cycle, continuously monitoring the health of each long-connection.

[0060] Specifically, a two-layer mechanism of kernel forwarding components and dedicated resource pools ensures low-latency and low-loss forwarding of heartbeat packets: a dedicated identification rule for heartbeat packets is added to the kernel matching rule set, which identifies heartbeat traffic based on business network identifiers, standard heartbeat communication ports, and small packet length characteristics, and configures the highest matching priority. After a packet is successfully matched, the forwarding queue logic is skipped, and uplink and downlink delivery is completed directly, which greatly reduces forwarding latency; an independent computing power slice and a dedicated buffer area are allocated for long-connection services in the hierarchical resource scheduling sub-pool. The dedicated resources are used only for heartbeat packet processing and are not affected by the preemption of ordinary business traffic, keeping the heartbeat packet loss rate at an extremely low level.

[0061] Accurate identification and rapid, tiered recovery of long-connection failures: Connection interruption is determined when any of the following conditions are met: prolonged lack of heartbeat response, wireless link switching timeout, or persistent high packet loss in long-connection messages. The entire identification process responds quickly. In mild no-response scenarios, an expedited heartbeat notification is sent to guide the service to quickly resend multiple heartbeat messages, and the kernel prioritizes the scheduling of this service's traffic in the forwarding link. In moderate link interruption scenarios, emergency resource expansion and scheduling are initiated to maximize the allocation of computing power and memory resources to the sub-pool to which the service belongs, clear backlogged data in the queue, and ensure priority transmission of recovery messages. In severe link disconnection scenarios, a long-connection interruption callback notification is pushed to the service to guide the service to execute rapid reconnection logic, while simultaneously sending the latest physical cellular network status to ensure that reconnection requests are directly connected to the hardware cellular link for recovery.

[0062] Furthermore, to address the issue of network connection interruptions and subsequent business disruptions in scenarios such as extremely weak networks, link switching, resource congestion, and abnormal permissions, this invention monitors the real-time status of traffic forwarding, physical network and permission activation, dynamic adjustment data across the entire link, and long-connection keep-alive status. Upon identifying link anomalies, permission failures, or batch failures of long connections, it automatically triggers tiered circuit breaker isolation and precise recovery logic to prevent the spread of faults, ensure rapid self-healing of network connections, and maintain business continuity.

[0063] Specifically, for permission invalidation anomalies, if the network permissions corresponding to the business's dedicated network identifier fail to pass multiple rounds of verification and the business experiences multiple network request failures, it is determined to be a permission anomaly. For long connection avalanche anomalies, if more than half of the long connection services in the same resource sub-pool simultaneously trigger connection interruption judgment and the physical cellular network is in a wireless handover state for a long time, it is determined to be a batch long connection failure. The general anomaly thresholds are synchronously and finely adjusted to shorten the link interruption judgment time, improve the traffic forwarding success rate judgment standard, and lower the throughput attenuation judgment range, so that even slight network fluctuations can be accurately detected and early intervention and protection can be carried out.

[0064] Based on the scope of the fault's impact, duration, and severity, three levels of circuit breaker strategies—mild, moderate, and severe—are implemented. Differentiated rate limiting and isolation are applied to business resource sub-pools to prioritize the stable operation of high-priority services and long-connection core services.

[0065] Mild anomaly scenarios include single-service permission failures, slightly substandard forwarding success rates, and brief periods of no heartbeat response for a single long-lived connection. The overall handling primarily involves localized rate limiting and retry repair, temporarily blocking new network requests from ordinary priority non-long-lived connection services to prevent invalid requests from consuming link resources; initiating a permission re-verification process for services with permission anomalies, and implementing mild keep-alive recovery logic for briefly lost long-lived connections.

[0066] Moderate anomaly scenarios include short-term link interruptions, insufficient system resources, and unresponsive heartbeats in long connections. The system initiates emergency scheduling and link cleanup mechanisms across the entire network, clearing backlogged forwarding traffic from the ordinary priority sub-pool and retaining only queue resources for high-priority services and system network services; it maximizes the release of core computing power and memory resources to ensure the normal operation of basic cellular links and high-priority services; and it simultaneously strengthens long-connection keep-alive capabilities, shortens heartbeat sending intervals, and expedites link activity maintenance.

[0067] Severe anomaly scenarios include extreme situations such as prolonged link interruptions, abnormal synchronization of the entire link status, batch avalanche failures of long connections, and a significant drop in the success rate of network-wide forwarding. The system triggers a mechanism for overall reset of container network links and batch service reconnection, resetting the container virtual network runtime environment and clearing abnormal network states; it also triggers batch reconnection processes for all long-connection services, with all reconnection requests being forwarded through high-priority channels, completing the restart of the entire network link and service recovery within a limited time.

[0068] A layered, rapid self-healing recovery mechanism provides corresponding recovery logic for abnormal permissions, long-connection failures, and network-wide link anomalies. After the fault is resolved, it automatically reverts to normal operating mode, restoring the dynamic adjustment capability across the entire link. Specifically, for permission self-healing recovery, once the business network permission verification status returns to normal, the system broadcasts a permission recovery notification, lifting restrictions on business network requests; it also synchronously updates the permission verification status in the network-wide forwarding rules to ensure normal traffic forwarding. For long-connection self-healing recovery, once the physical network transmission latency returns to the normal range and the wireless link returns to a stable connection state, the expedited keep-alive strategy is canceled, and the business heartbeat interval is restored to the default normal configuration; the standard forwarding priority of long-connection heartbeat packets is simultaneously restored, and the special resource protection strategy ends. Finally, after all anomaly repairs are completed, the system performs closed-loop verification using three core indicators: forwarding success rate, resource utilization rate, and long-connection reconnection success rate. Once it confirms that the entire network link, resource scheduling, and business connections have fully recovered and stabilized, the normal dynamic fine-tuning and adaptive adjustment mechanism is restarted, and the system returns to normal operating status.

[0069] Example:

[0070] This embodiment employs the container-based mobile network stability enhancement method based on cross-system network direct access provided by this invention. Using OpenHarmony as the host system and Android as the container system, it constructs a cross-system mobile network Hard DirectAccess Architecture (HDAA) through deep coupling of cross-system protocol stacks, hardware-level resource isolation adaptation, and end-to-end state closed-loop synchronization. This integrates core modules such as a permission mapping verification module, a request routing interception module, a three-level state synchronization module, an eBPF protocol feature forwarding module, a dedicated resource pool allocation module, a bidirectional feedback adjustment module, an application layer adaptation module, a long connection maintenance module, and an anomaly circuit breaker recovery module, forming a stability enhancement scheme with no intelligent dependencies across the entire link. The specific process includes:

[0071] S1, Cross-system mapping and container-based verification of Android application network permissions, is used to resolve the inconsistency between Android application permissions within a container and OpenHarmony physical network permissions.

[0072] Cross-system permission mapping rule definition: Modify the code of OpenHarmony and Android container to establish a mapping table from Android application permissions to OpenHarmony physical network permissions, and clarify the correspondence of mobile network related permissions as shown in the table below to avoid permission misjudgment.

[0073] Table 1. Correspondence between Mobile Network-Related Permissions

[0074] The mapping table is stored in / etc / hdaa_perm_map.xml in OpenHarmony and / system / etc / cni_perm_map.xml in the Android container, and the HDAA coordinator ensures data consistency between the two ends.

[0075] Modification of the container permission verification mechanism: The checkPermission() method of the Android container PMS has been modified to add a physical network permission verification branch: When an application requests mobile network-related permissions, PMS does not rely on the permission status of the container's virtual network. Instead, it sends a permission verification request to the OpenHarmony HDAA coordinator through the MNA client, carrying the application's CNI and the requested permission identifier. The HDAA coordinator calls the verifyPermission() interface of OpenHarmony Permission ManagerService to verify whether the host machine's physical network permissions have been granted. The verification result is returned to the MNA client through the IPC channel, and then fed back to the application by PMS. The verification delay is controlled to be no more than 30ms.

[0076] Deployment of network request interception points within containers: Modify the framework layer code of the Android container, adding a network application identifier registration mechanism in ActivityManagerService (AMS) and PMS. All Android applications with network access permissions are assigned a unique Container Network ID (CNI) by PMS during installation. The CNI is assigned by the OpenHarmony container management service, using a fixed-length 16-byte design. The first 4 bytes are the unique container identifier, the middle 8 bytes are the application package name hash value (the first 8 bytes are truncated using the SHA-256 algorithm), and the last 4 bytes are the network access type identifier: 0x0001 for 4G dedicated, 0x0002 for 5G dedicated, and 0x0003 for general mobile networks. This is stored in the ` / data / system / cni_map.xml` file, which is stored using XML encryption. The key is dynamically assigned by the OpenHarmony security service to prevent tampering. Meanwhile, in the com.android.server.am.ActivityManagerService class of AMS, lifecycle methods such as startActivity() and bindService() are overridden to insert request interception hooks. The interception timing is set within 1μs after the application calls network request APIs such as ConnectivityManager.Network.openConnection, Socket.connect(), and OkHttpClient.newCall(). The method call stack is intercepted through Hook technology to ensure that the request is captured as soon as it is initiated, without affecting other business logic of the application.

[0077] Permission and request association: During request interception, the AMS interception hook first calls the PMS's checkPermission() method to complete permission verification. If the verification passes, it then queries the application's CNI; if the verification fails, it directly returns a SecurityException, blocking the subsequent request process and preventing invalid requests from consuming system resources. Simultaneously, the permission verification result, along with the CNI and request parameters, is encapsulated into a subsequent request context structure (RCS), providing the forwarding module with the basis for associating permissions, requests, and identifiers.

[0078] S2, Container-based targeted interception and identification encapsulation of network requests for Android applications, is used to solve the problem that application requests within a container cannot be directly associated with the physical 4G / 5G network.

[0079] Network request context encapsulation: When an Android application initiates a 4G / 5G network request and the permission verification passes, AMS's interception hook obtains the current application's process ID (PID) and user ID (UID) through ActivityThread. Combining the PID, it queries the corresponding CNI from ` / data / system / cni_map.xml`. Simultaneously, it extracts the core request parameters using reflection: the target IP address (supports IPv4 / IPv6, IPv4 occupies 4 bytes, IPv6 occupies 16 bytes), the port number (TCP / UDP port, occupies 2 bytes), and the transmission... Protocol types, such as 0x01 for TCP, 0x02 for UDP, and 0x03 for SCTP, occupy 1 byte. Request priority is defined by the `android:networkPriority` attribute in the application's Manifest file, including levels 0 to 5, with level 0 being the highest, occupying 1 byte. Data transmission direction, such as 0x01 for uplink, 0x02 for downlink, and 0x03 for bidirectional transmission, occupies 1 byte. The default request timeout is 500ms, which can be customized by the application, occupying 4 bytes. Permission verification results, such as 0x00 for pass and 0x01 for deny, occupy 1 byte. The above information is encapsulated into a Request Context Structure (RCS). The structure uses big-endian byte order, with a total length of 68 bytes, including 35 bytes reserved for future feature expansion. The RCS is written to a pre-defined shared memory block within the container using memory copy technology. This block is 1MB in size, with read and write permissions, and access is only allowed to root and system processes, avoiding the overhead of serialization and deserialization during data transmission.

[0080] Cross-system request routing: Modify the `com.android.server.ConnectivityService` class of the `ConnectivityManager` service in the Android container, adding an HDAA request routing module. This module listens for write events to shared memory blocks through the `inotify` mechanism. When an RCS write is detected, it immediately uses the inter-container IPC channel provided by the OpenHarmony system. Based on the OpenHarmony IPC framework extension, it adopts a hybrid transmission mode of Socket control channel and shared memory data channel: the Socket channel is used to transmit control signals such as RCS ready and route confirmed, with a transmission latency of no more than 2μs; the shared memory channel is used to transmit RCS data, with a transmission latency of no more than 1μs, synchronizing the RCS to the HDAA coordinator in the OpenHarmony user space. Simultaneously, by calling the `Looper.myQueue().postSyncBarrier()` method, the original network request message loop of the Android application is blocked, with a blocking timeout set to 50ms. If a route ready signal is not received within the timeout period, a local retry mechanism is triggered, retrying a maximum of 2 times with a retry interval of 100ms, ensuring that the request is not mishandled by virtual network interfaces within the container such as `veth0`, avoiding the performance loss of traditional virtualization forwarding.

[0081] S3, cross-system three-level network status synchronization and precise injection within containers, is used to solve the problem that the Android system within a container cannot obtain the physical 4G / 5G network status in real time, providing accurate network environment information for application requests.

[0082] Comprehensive Physical Network Status Acquisition: A new network status acquisition driver module, NetStateCollector, is added to the OpenHarmony kernel space based on the Linux 5.10 kernel. This module is compiled as a kernel module .ko file. After the OpenHarmony kernel initialization is completed and before the user-space service starts, the driver initialization is automatically executed during the kernel system startup phase via the module_init() function. The RMNET driver generates a logical 4G / 5G data virtual interface rmnet_data0 based on the Modem USB / PCIe physical channel. This driver is located between the baseband L2 wireless link layer and the kernel IP L3 protocol stack. During driver initialization, a net_device_ops structure is registered for the network interface, implementing the ndo_start_xmit data packet sending callback and the ndo_change_mtu MTU modification callback interface, achieving non-intrusive acquisition of the physical interface status. The acquisition dimensions and parameter definitions are shown in the table below.

[0083] Table 2. Data Collection Dimensions and Parameter Definitions

[0084] All collected data is stored in a kernel-mode shared buffer with a size of 1MB and a circular buffer structure. When the buffer is full, the oldest data is overwritten to avoid data loss. Each data item carries a microsecond-level timestamp obtained by the kernel's ktime_get_ns() function to ensure timing consistency.

[0085] Three-level state synchronization channel construction: Constructing a three-level synchronization channel for kernel mode, user mode, and container mode to ensure low-latency transmission of state data. The synchronization details for each level are as follows:

[0086] Kernel-to-user-space synchronization employs a hybrid mode of interrupt triggering and polling. For critical events such as RRC state transitions, interface state changes, GTP-U TEID changes, and permission state changes, the NetStateCollector module triggers a kernel interrupt via the wake_up_interruptible() function, waking up the blocked thread of the OpenHarmony user-space HDAA coordinator. The coordinator maps the kernel-space shared buffer using mmap() and directly reads the latest state data; this path latency is no greater than 3μs. For high-frequency, small-variable data such as signal strength, throughput, and packet loss rate, the HDAA coordinator actively reads data from the kernel buffer via the ioctl() system call at 5ms intervals, avoiding kernel overhead caused by frequent interrupts; this path latency is no greater than 5μs. During data synchronization, the HDAA coordinator performs CRC32 verification on the data, with the verification field overriding the data content and timestamp. If the verification fails, the data item is discarded to avoid dirty data transmission.

[0087] User-space to container-space synchronization: The HDAA coordinator categorizes the collected physical network status data into static and dynamic parameters. Static parameters, such as IP addresses, DNS servers, APN configurations, and permission mapping tables, are synchronized only when their values ​​change. Dynamic parameters, such as RSSI, RTT, RRC status, and permission activation status, are synchronized every 10ms to ensure real-time performance. The synchronization channel reuses the inter-container IPC channel, and the data is encapsulated into a State Sync Structure (SSS). The SSS consists of a header and a data body: the header occupies 8 bytes, including a 2-byte status type identifier, a 2-byte data length, and a 4-byte CRC32 checksum; the data body contains the specific status parameters, arranged in the order of collection dimensions. During synchronization, a 1-byte SSS ready signal is first sent through the Socket control channel. After receiving the signal, the MNA client inside the container reads the SSS data from the shared memory channel. This path delay is no greater than 20μs, and the total synchronization delay is no greater than 50ms.

[0088] Injecting Android system state within a container is achieved by modifying the framework layer and system service code of the Android container, as detailed below:

[0089] TelephonyManager Adaptation: Modify the underlying Android container telephony system service PhoneInterfaceManager, and add a custom Binder interface setPhysicalNetworkState(CustomNetworkState sss). After receiving the underlying physical cellular SSS network status data, the custom-developed MNA state client calls this new interface through Binder to overwrite the original virtual network interface cache state inside the container. A new internal unified cache object replaces the native scattered state, covering content including the native SignalStrength signal strength, DataState data connection enumeration, CarrierConfig carrier configuration, and permission bitmap based on container CNI custom mapping. At the same time, the system standard status and permission query APIs such as getSignalStrength(), getDataState(), getNetworkOperatorName(), and checkNetworkPermission() are rewritten to prioritize returning the injected underlying physical cellular network status and authentication results. The native NetworkInterface.getNetworkInterfaces() virtual network card status query logic is deprecated to avoid conflicts between the container virtual network and the real modem physical network status and permission judgment.

[0090] After the self-developed MNA client completes the physical network state injection, it calls the system's native Context.sendBroadcastAsUser() to send standard Android network state broadcasts, including the native deprecated network broadcast CONNECTIVITY_ACTION, cellular signal change broadcast SIGNAL_STRENGTHS_CHANGED_ACTION, and cellular data connection broadcast DATA_CONNECTION_STATE_CHANGED_ACTION. A custom permission change broadcast Action is added, constructing an Intent and attaching self-developed extended parameters: a custom signal strength extended field carrying the RSSI value and a custom permission bitmap extended field carrying the CNI-mapped permission status. Upper-layer applications synchronously obtain the underlying real physical network and permission information through a dynamic broadcast receiver. The ActivityManagerService broadcast distribution and scheduling logic is modified from the source code, marking the above network state broadcasts as high-priority foreground delivery, compressing broadcast queuing latency, and using self-developed scheduling optimization methods to control the overall broadcast distribution latency to within 10ms.

[0091] S4, kernel-mode eBPF protocol feature hard matching forwarding, is used to solve the performance loss and data loss problems caused by virtualization forwarding.

[0092] Between the kernel TCP / IP L3 protocol stack and the rmnet_data0 cellular logical L2 virtual network interface card, a self-developed HDAA-eBPF kernel eBPF forwarding module is deployed, based on the libbpf 1.2 toolchain. The eBPF program is compiled to generate the bpf_prog.o object file, which is verified and loaded into the kernel through the standard bpf() system call. The loading sequence is controlled by the self-developed HDAA coordinator, and loading is completed after the OpenHarmony system initialization is completed and before the Android container starts. HDAA-eBPF does not rely on traditional container forwarding components such as veth-pair virtual bridge and NAT address translation. It achieves traffic forwarding based on Linux TC traffic control hook mounting: container uplink traffic from the container to the cellular physical channel is mounted to the egress exit hook under TC_H_CLSACT, and the data packet is allowed to return TC_ACT_OK if it passes normally; downlink traffic from the physical network to the Android container cellular is mounted to the ingress entry hook of the same device; both types of filters are configured with prio=0 as the highest priority to ensure that mobile cellular traffic is intercepted and forwarded first.

[0093] Construction of a 4G / 5G protocol feature hard matching rule base: A protocol feature hard matching rule base is preset in the HDAA-eBPF module. The rule base is based on the protocol standards defined by 3GPP TS 23.003, TS 29.274, etc., and covers key protocol features of the 4G / 5G core network user plane and control plane. Combined with permission verification results and CNI identifiers, no intelligent learning or dynamic training is required. The rule base is designed as follows:

[0094] The rule base storage structure uses a two-dimensional array, with the array dimensions being [rule type][rule entry]. Rule types include four categories: GTP-U protocol rules, LTE control plane rules, user plane IP rules, and application request-permission association rules. Each category supports a maximum of 256 rule entries. Each rule entry occupies a fixed length of 68 bytes, and its structure is defined as follows:

[0095] struct bpf_match_rule {

[0096] __u8 protocol_type; / / Protocol type, such as TCP, UDP, SCTP, GTP-U

[0097] __u16 src_port; / / Source port

[0098] __u16 dst_port; / / Destination port

[0099] __u32 src_ip[4]; / / Source IP address, IPv4 occupies 4 bytes, IPv6 occupies 16 bytes

[0100] __u32 dst_ip[4]; / / Destination IP address

[0101] __u32 teid; / / GTP-U TEID, only valid for GTP-U rules

[0102] __u8 cni

[16] ; / / Container network identifier, only valid when applying request rules

[0103] __u8 perm_state; / / Permission status, 0x00 indicates valid, 0x01 indicates invalid, only the request-permission association rule is valid.

[0104] __u8 rrc_state; / / Matching RRC state, optional, used for conditional filtering

[0105] __u8 reserved

[11] ; / / Reserved field

[0106] };

[0107] Core rule definition:

[0108] GTP-U protocol rules: protocol_type=0x04 (GTP-U), dst_port=2152 is the standard GTP-U port, teid is synchronized from SSS by the HDAA coordinator and updated every 10ms;

[0109] LTE control plane rules: protocol_type=0x03 (SCTP), src_ip is the MME address range obtained synchronously from the operator's network parameters, dst_port=36412 is the SCTP standard port;

[0110] User plane IP rules: protocol_type=0x01 / 0x02 such as TCP or UDP, src_ip / dst_ip is a user plane IP address range based on IMSI binding;

[0111] Application request-permission association rules: protocol_type matches the transport protocol type in RCS, cni matches the CNI in RCS, dst_ip or dst_port matches the target address and port in RCS, and perm_state=0x00 indicates that the permission is in effect;

[0112] The rule base supports dynamic updates via the HDAA coordinator. When operator network parameters or permission status change, the update method is to modify the rule entries in the eBPF mapping table. The update process does not interrupt the forwarding service and adopts a double buffering mechanism. The new rule takes effect after it is loaded.

[0113] Packet interception and field extraction:

[0114] Uplink packet interception: Data packets from Android applications within the container are processed by the Android kernel protocol stack and sent through virtual interfaces such as lo in the container's network namespace. These packets are intercepted by the TC egress hook of the HDAA-eBPF module. The eBPF program first extracts the Ethernet header (14 bytes), the IP header (20 bytes representing IPv4), and the transport layer header (e.g., TCP 20 bytes or UDP 8 bytes) from the data packet. It then parses out core fields such as source IP, destination IP, source port, destination port, and protocol type. Simultaneously, it obtains the sending process PID and, combined with the PID, queries the corresponding CNI and permission status from the eBPF mapping table. The parsing time is no more than 1μs.

[0115] Downlink packet interception: Data packets received by the physical 4G / 5G data interface are processed at Layer 2 and then intercepted by the TC ingress hook of the HDAA-eBPF module. For GTP-U encapsulated data packets, the eBPF program first parses the GTP header (8 bytes), extracts the TEID field with an offset of 4 bytes, and then parses the inner IP or transport layer header. For non-GTP-U data packets, such as control plane SCTP data packets, the IP or transport layer header is directly parsed. At the same time, the CNI and PID of the target application are determined by querying the eBPF mapping table through the inner IP and port. The parsing time is no more than 2μs.

[0116] Hard matching and forwarding path optimization:

[0117] Rule matching logic: A rule type-based sequential matching strategy is adopted, prioritizing application request-permission association rules (priority 1) to ensure permission validity before forwarding. Next are GTP-U protocol rules (priority 2), LTE control plane rules (priority 3), and user plane IP rules (priority 4). Each data packet matches a maximum of one rule, and the matching process immediately exits upon successful matching. The matching process is a hard comparison of each field, without fuzzy or intelligent matching. The comparison order is from protocol type, port, IP address, CNI or TEID to permission status, with a matching time not exceeding 2μs. If a match fails (e.g., invalid permission, no corresponding rule), the data packet is discarded and the reason for the failure is recorded in the eBPF statistical mapping table.

[0118] Uplink forwarding path: After successful matching, the HDAA-eBPF program sets the tunnel identifier TEID of the data packet using the skb_set_tunnel_key() function, and then redirects the data packet to the physical 4G / 5G data interface rmnet_data0, skipping the bridge forwarding and NAT translation process of the OpenHarmony kernel. During forwarding, the data packet is converted into a linear buffer to avoid the copy overhead caused by scattered buffer aggregation, reducing the number of memory copies from 3 copies in traditional virtualization to 1 copy, with a forwarding time of no more than 3μs.

[0119] Downlink forwarding path: After successful matching, the HDAA-eBPF program obtains the target application's PID through the CNI-PID mapping table, sends the data packet directly to the Android container's network namespace, and then binds the data packet to the target application process's file descriptor to ensure accurate delivery. During delivery, the MAC header of the data packet is reset to match the interface MAC address of the container's network namespace, and the forwarding time is no more than 3μs.

[0120] Forwarding queue management: Based on the RRC connection status synchronized in step 3, a forwarding queue length threshold is statically set. The queue adopts a FIFO scheduling strategy to avoid out-of-order packets, and differentiated scheduling is achieved by combining application priorities.

[0121] In RRC connection mode, high throughput scenario: the queue length threshold is set to 2048, each queue item corresponds to 1 data packet with a maximum size of 1500 bytes, high priority applications are level 0 to 2, the data packet scheduling weight is set to 3, and the normal priority is set to 1.

[0122] RRC idle state, low power consumption scenario: the queue length threshold is set to 512, and only high-priority application data packet forwarding is guaranteed;

[0123] RRC switching state, balanced scenario: the queue length threshold is set to 1024, the scheduling weight of high priority applications is 2, and the normal priority is 1;

[0124] Queue congestion detection: When the queue length reaches 80% of the threshold, ordinary priority data packets are discarded, and high priority data packets are retained to avoid critical business interruptions caused by queue overflow.

[0125] S5, dedicated allocation of cross-system resources, is used to solve the problem of unstable transmission caused by resource contention under high network load.

[0126] Dedicated resource pool initialization configuration: Modify the underlying resource management service ResourceManagerService and Cgroups v2 kernel module of OpenHarmony to create a dedicated 4G / 5G network resource pool for Android containers. The resource pool is independent of the resource allocation of other applications and containers on the host machine. The resource sub-pools are divided according to application priority. The initialization process is as follows:

[0127] Resource pool creation timing: When the OpenHarmony system starts, ResourceManagerService reads the configuration file, predefines the initial parameters of the resource pool and the priority sub-pool division, calls the mkdir command of Cgroups v2 to create a dedicated resource group / sys / fs / cgroup / hdaa_android_container under / sys / fs / cgroup, and creates 3 sub-resource groups: high_prio for high-priority applications with priority levels 0 to 2, normal_prio for normal-priority applications with priority levels 3 to 5, and system_net for system network processes such as rild. The resource group permissions are set to allow only root and HDAA coordinator access.

[0128] CPU-dedicated resource configuration:

[0129] Resource allocation and sub-pool division: The ResourceManagerService service queries the number of currently online CPU cores through the sysfs interface / sys / devices / system / cpu / online, and allocates dedicated CPU cores based on 30% of the total number of physical cores, with a minimum of 3 cores and a maximum of 4 cores. Sub-pools are then divided: high_prio is allocated 1.5 cores, normal_prio is allocated 1 core, and system_net is allocated 0.5 cores, prioritizing high-performance cores, such as the ARM architecture Cortex-A78 core.

[0130] Core binding: Configure CPU affinity for each sub-pool through the ccpuset.cpus file of Cgroups v2 to restrict processes from different sub-pools to run on a specified set of CPU cores, thereby achieving scheduling isolation. For example, when the total number of cores is 0 to 3, high_prio is bound to cores 0 to 1, normal_prio is bound to core 2, and system_net is bound to core 3. Execute echo "0-1" > / sys / fs / cgroup / hdaa_android_container / high_prio / cpuset.cpus;

[0131] Process binding: The HDAA coordinator uses the ps command to query network-related processes within the Android container and binds them to the corresponding sub-pools according to priority: rild and system_server network threads are bound to system_net; high-priority application processes (such as instant messaging) are bound to high_prio; and normal-priority application processes are bound to normal_prio. The binding command is cgclassify -g cpu,cpuset: / hdaa_android_container / high_prio [PID];

[0132] Scheduling strategy optimization: The coordinator iterates through all process PIDs within the group and executes the chrt command in batches to set the scheduling policy of the system_net sub-pool processes to SCHED_FIFO real-time priority (e.g., priority value of 98), the high_prio sub-pool to SCHED_FIFO priority of 95, and the normal_prio sub-pool to SCHED_NORMAL priority of 0, ensuring that system network processes and high-priority applications are executed first and avoiding scheduling delays.

[0133] Dedicated memory resource configuration:

[0134] Resource partitioning and sub-pool allocation: Allocate 1.5GB of physical memory as dedicated memory for container networking, and divide it into sub-pools: high_prio 600MB, normal_prio 400MB, and system_net 500MB, which are used for high-priority application data transmission, normal-priority application data transmission, and system network process buffer, respectively.

[0135] Container memory limits: Container memory resource isolation is implemented based on the Cgroups v2 memory controller. The hard upper limit of memory for each service sub-pool is configured through memory.max. Taking the high_prio group as an example, the command echo "629145600" > / sys / fs / cgroup / hdaa_android_container / high_prio / memory.max limits the maximum available memory to 600MB. The soft reclamation threshold of memory.high is configured at 90% of this hard upper limit. When the process memory usage exceeds this threshold, the kernel actively initiates page reclamation to prevent peak business traffic from triggering OOM.

[0136] Buffer parameter optimization: Modify kernel parameters by sub-pool (via sysctl command) to optimize socket buffer size:

[0137] system_net subpool: net.core.somaxconn = 8192, tcp_rmem = "8192 1310728388608", tcp_wmem = "8192 131072 8388608";

[0138] high_prio subpool: net.core.somaxconn = 4096, tcp_rmem = "4096 873804194304", tcp_wmem = "4096 16384 4194304";

[0139] normal_prio subpool: net.core.somaxconn = 2048, tcp_rmem = "2048 436902097152", tcp_wmem = "2048 8192 2097152";

[0140] Memory locking: The mlockall() system call locks the dedicated memory of each sub-pool to physical memory, avoiding the latency caused by swapping, and only allows the process of the corresponding sub-pool to access the memory area.

[0141] Disrupt dedicated resource configuration:

[0142] IRQ lookup: Execute the native cat / proc / interrupts command to read the interrupt IRQs of the data channel corresponding to the cellular virtual network interface rmnet_data0, such as IRQ 128, and the IRQs of the modem control channel, such as IRQ 129.

[0143] Disrupt affinity binding: Bind both cellular data IRQ 128 and modem control IRQ 129 to CPU core 3 of the system_netcgroup sub-pool, and execute standard commands:

[0144] echo "3" > / proc / irq / 128 / smp_affinity_list;

[0145] Interrupt isolation: By configuring the black-and-white filtering rules of the irqbalance process, other peripheral interrupts are prohibited from being scheduled to CPU3, ensuring that this core only handles 4G / 5G cellular-related interrupts; this control logic is implemented by a self-developed interrupt scheduling management component.

[0146] Interrupt trigger mode optimization: The edge trigger mode of cellular modem interrupts is statically configured by the underlying HDF driver and device tree. The hardware adopts an edge trigger mechanism to avoid continuous and repeated level reporting, reduce interrupt wake-up frequency and reduce CPU usage.

[0147] Load fine-tuning mechanism design: Based on synchronized transport layer state data and forwarding priorities, a non-intelligent threshold-triggered fine-tuning strategy is designed to adjust the load according to sub-pool differences, avoiding resource waste or insufficiency. The specific process is as follows:

[0148] Load monitoring: The HDAA coordinator collects the resource usage status of each sub-pool every 20ms, including CPU utilization, memory buffer utilization, TCP connection count, and throughput;

[0149] Fine-tuning CPU load by sub-pool: High_prio sub-pool expansion conditions: Within 60ms for 3 consecutive monitoring cycles, the sub-pool throughput is not less than 100Mbps and the CPU utilization is not less than 90%; temporarily borrow CPU from the normal_prio sub-pool for a maximum of 5 seconds to achieve expansion operation.

[0150] The conditions for shrinking the high_prio subpool are as follows: within three consecutive monitoring cycles (e.g., 60ms), the subpool throughput is no greater than 30Mbps and the CPU utilization is no greater than 30%; then the CPU is released to the normal_prio subpool to achieve the shrinking operation.

[0151] System_net subpool expansion conditions: Within two consecutive monitoring cycles of 40ms, the Modem control command processing delay is not less than 50μs; borrow CPU from the normal_prio subpool, prioritize command processing, and realize the expansion operation;

[0152] Fine-tune memory load on a sub-pool basis:

[0153] The conditions for expanding the high_prio sub-pool are as follows: within three consecutive monitoring periods (e.g., within 60ms), the number of TCP connections in the sub-pool is not less than 30 and the buffer utilization rate is not less than 85%; the maximum memory limit of the sub-pool is expanded to 800MB, and the buffer parameters are updated synchronously to achieve expansion.

[0154] The conditions for shrinking the high_prio sub-pool are: if the number of TCP connections in the sub-pool is no more than 10 and the buffer utilization rate is no more than 30% within 3 consecutive monitoring periods (e.g., within 60ms), the maximum memory limit of the sub-pool is reduced to 400MB to achieve shrinkage.

[0155] System_net subpool expansion conditions: Within two consecutive monitoring cycles (e.g., 40ms), the Modem command buffer usage rate is not less than 90%; the subpool memory limit is expanded to 600MB to achieve expansion.

[0156] Fine-tuning constraints: Set the minimum interval for resource adjustments to 1 second to avoid resource jitter caused by frequent adjustments; the high_prio sub-pool has a maximum of 2 CPU cores and 1GB of memory, while the normal_prio sub-pool has a minimum of 0.5 CPU cores and 200MB of memory to ensure that the basic needs of the host machine's native applications and low-priority applications are not affected.

[0157] S6, bidirectional status feedback adjustment, dynamically optimizes transmission parameters to solve the problem that static configuration of full-link parameters cannot adapt to dynamic network scenarios.

[0158] Container-side status feedback collection: Modify the native TrafficStatsService and NetworkStatsService of Android containers, and add a self-developed priority-based network load status collection module. Collect multi-dimensional network metrics in layers according to cgroup-divided system_net, high_prio, and normal_prio sub-pools: total TCP / UDP connections in each sub-pool, application uplink and downlink real-time throughput, TCP packet retransmission rate, number of network permission changes, and number of application network request failures. Custom timed scheduling logic is used to execute one round of metric collection every 20ms. After collection, the data is reported to the HDAA coordinator through a custom HDAAIPC channel and uniformly encapsulated into a self-developed load feedback structure PLFS (Priority-based Load Feedback Structure). This structure is an extension of the original custom LFS load structure, adding a 1-byte sub-pool identifier field while retaining the original field layout to ensure compatibility between previous and subsequent transmissions.

[0159] Forwarding and Resource Status Feedback Collection: A priority-based traffic statistics unit is added to the custom HDAA-eBPF kernel forwarding module. Statistical data is stored based on the Linux standard BPF_MAP_TYPE_HASH hash mapping table, using a custom sub-pool identifier as the hash key. The kernel TC hook accumulates in real-time the uplink and downlink packet forwarding success rate, average forwarding latency, queue congestion events, and traffic rule matching failures for each sub-pool. Simultaneously, the OpenHarmony native ResourceManagerService is modified to add a self-developed sub-pool hardware resource statistics unit, continuously collecting CPU utilization, memory buffer usage, and resource borrowing and returning event counts for each cgroup sub-pool. The custom HDAA coordinator pulls statistical data in two ways at 10ms intervals: network traffic metrics are read from the eBPF hash mapping table via the standard bpf_map_lookup_elem() function; CPU and memory resource metrics are read via the kernel sysfs file interface. Both types of statistical data are uniformly synchronized to the user-space business processing logic.

[0160] Closed-loop adjustment strategy execution: After receiving PLFS and forwarding and resource status data, the HDAA coordinator executes the following non-intelligent adjustment strategy according to sub-pools.

[0161] Adjust the status acquisition frequency on a sub-pool basis:

[0162] high_prio sub-pool: When the detected throughput is not less than 120Mbps or the retransmission rate is not less than 2%, the dynamic parameter collection frequency is increased from 10ms / time to 5ms / time; when the throughput is not greater than 20Mbps and the retransmission rate is not greater than 0.5%, it is reduced to 20ms / time.

[0163] system_net sub-pool: When the Modem command processing delay is not less than 30μs, the acquisition frequency of permission status and Modem parameters is increased to 2ms / time; when the delay is not greater than 10μs, it is reduced to 15ms / time.

[0164] Adjust the forwarding queue threshold on a sub-pool basis:

[0165] high_prio sub-pool: In RRC connected state, when the number of queue congestion times is not less than 3 times for 3 consecutive cycles, the threshold is increased from 2048 to 2457; when there is no congestion for 5 consecutive cycles, it is reduced to 1843.

[0166] normal_prio sub-pool: In RRC connected state, when the number of queue congestion times is not less than 3 times for 3 consecutive cycles, the threshold is increased from 2048 to 2252; when there is no congestion for 5 consecutive cycles, it is reduced to 1638.

[0167] The adjustment process is achieved by updating the queue threshold parameter in the eBPF mapping table without interrupting the forwarding service.

[0168] Adjust resource allocation thresholds on a sub-pool basis:

[0169] The high_prio sub-pool: When the memory buffer utilization rate is not less than 90% for three consecutive cycles and the throughput increases by not less than 10% month-on-month, the memory expansion limit is increased from 800MB to 1GB; when the CPU utilization rate is not greater than 20% for three consecutive cycles and the throughput is stable, the CPU borrowing threshold is increased from 0.5 cores to 1 core.

[0170] The system_net sub-pool: When the Modem instruction processing latency is not less than 40μs for three consecutive cycles, the CPU borrowing threshold is increased from 0.5 cores to 1 core; when the latency is not greater than 15μs, it reverts to 0.5 cores.

[0171] The adjusted threshold parameters are stored in the / etc / hdaa_adjust.conf file, partitioned by sub-pool, and automatically loaded after a system reboot.

[0172] S7, Application Layer Data Processing Adaptation, ensures data correctness under physical network conditions, and is used to solve data parsing anomalies caused by mismatch between container virtual state and physical network state in Android application layers.

[0173] Android application framework layer network data parsing and adaptation: Modify the Android container framework layer code, focusing on adapting the java.net package and the core classes of okhttp3 to ensure that the application correctly handles transmitted data under physical network conditions.

[0174] HttpURLConnection adaptation: Modify the getResponseCode() and getResponseMessage() interfaces of the native HttpURLConnection in the Android container, and add a custom physical network status adaptation branch; when the current network is identified as a real 4G / 5G cellular network marked by the custom MNA component, read the real connectivity status of the operator gateway and the HTTP response code in the custom SSS memory cache structure, overriding the original response judgment logic based on the container virtual network card.

[0175] When a link congestion occurs in the cellular physical network and the gateway returns the standard 429 congestion status code, the framework can accurately identify it as congestion in the underlying modem physical network, instead of misjudging it as a container virtual network failure, thus preventing upper-layer applications from making meaningless repeated retries.

[0176] Socket class adaptation: Modify the java.net.Socket core interface to achieve cross-layer compatibility, and override isConnected() to prioritize querying the real Modem data link status stored in the SSS structure from the custom MNA client, instead of relying solely on the virtual Socket cache status within the container; override getInputStream() to read the RTT latency metric in the SSS. If an RRC handover causes a sudden increase in RTT exceeding a custom threshold of 200ms, automatically and dynamically extend the read timeout by 100ms to avoid the application prematurely throwing an IOException due to short-term interruptions in cellular data streams.

[0177] Network exception class adaptation: A new PhysicalNetworkException exception class has been added, inheriting from IOException, to identify exceptions specific to the physical network, such as RRC handover interruption and operator APN configuration changes. The exception capture process of the Android application has been modified, and a custom global physical network exception interceptor handler has been registered in the application initialization entry point of ActivityThread's handleBindApplication(). When a network request throws a custom cellular network exception, the system's native CONNECTIVITY_ACTION network change broadcast is actively sent to notify the upper layer application to execute the recovery and retry logic adapted to the physical cellular link, and to re-initiate the network request after the RRC handover on the modem side is completed.

[0178] Application-layer network state awareness adaptation: Modify the Application and Activity base classes of the Android container to add physical network state awareness interfaces, including a new abstract class PhysicalNetworkObserver, which provides callback methods such as onPhysicalNetworkConnected(), onPhysicalNetworkCongested(), and onPhysicalNetworkDisconnected(). Applications can register observers through registerPhysicalNetworkObserver() to receive real-time notifications of physical network state changes, replacing the original ConnectivityObserver which relies on virtual network state.

[0179] Automatically register PhysicalNetworkObserver in the Activity's onResume() method and automatically unregister it in the onPause() method to ensure that the application lifecycle is synchronized with the physical network status awareness and avoid memory leaks. At the same time, add physical network status initialization verification in the onCreate() method. If the physical network is not ready, display a prompt waiting for mobile network connection instead of directly throwing a network unavailable error.

[0180] Data caching and retry strategy adaptation: Modify the android.webkit package and androidx.room of the Android container's web page and local persistent storage components to ensure that data caching and retry strategies adapt to physical network characteristics. For WebView caching optimization, listen to the physical signal strength parameter injected by the custom MNA. When the signal strength is no greater than -110dBm in a weak network scenario, automatically call WebSettings.setCacheMode() to switch the caching strategy from the native LOAD_DEFAULT to LOAD_CACHE_ELSE_NETWORK, prioritizing reading from the local cache to reduce network requests in weak network conditions. When the signal strength recovers to a good range of no less than -90dBm, automatically switch back to LOAD_DEFAULT mode, proactively obtain the latest business data, and update the local cache.

[0181] Network request retry strategy adaptation: Modify okhttp3's RetryInterceptor to add physical network retry rules. The retry interval is dynamically adjusted based on RTT and signal strength in SSS. For example, when RTT=100ms, the retry interval is 200ms, and when RTT=500ms, the retry interval is 1000ms. The number of retries decreases as the signal strength increases: 3 retries at -110dBm and 1 retry at -90dBm, to avoid ineffective retries under weak signals exacerbating network congestion.

[0182] S8, Long-Term Connection Maintenance, solves the problem of keeping long-term connections alive in container environments, and is used to resolve issues such as lost heartbeat packets, misjudgment of timeouts, and interruption of RRC switching in container environments.

[0183] Modify the TelephonyManager and ConnectivityManager framework logic within the Android container to create a custom registration management mechanism for new long-connection applications. Provide a custom extended registration interface, where applications pass in their package name and a custom heartbeat interval to complete registration. After the PMS verifies that the application has INTERNET network permissions, persist the application's container sub-pool identifier, heartbeat interval, and other long-connection attributes to a custom configuration file / data / system / long_conn_map.xml. Simultaneously, synchronize this registration information to a custom HDAA coordinator for the kernel eBPF forwarding and cgroup scheduling modules to identify and optimize long-connection business traffic.

[0184] The HDAA coordinator establishes a long-connection status tracking table to record the long-connection establishment time, the most recent heartbeat packet transmission and reception time, the current RTT, and the RRC status for each CNI. The tracking frequency is consistent with the status acquisition frequency to ensure real-time monitoring of the long-connection health status.

[0185] Heartbeat packet transmission optimization: Through collaboration between the HDAA-eBPF module and the resource sub-pool, heartbeat packets are prioritized for transmission.

[0186] eBPF heartbeat identification and forwarding: A new heartbeat matching rule has been added to the HDAA-eBPF rule base. Based on the CNI of long-connection applications, the default heartbeat port such as the 5222 port commonly used in instant messaging, and the data packet length of the heartbeat packet, which is usually no more than 100 bytes, the heartbeat packet is identified, the matching priority is set to the highest, and the queue is skipped during forwarding, and the packet is directly delivered to the physical interface or the target application. The heartbeat packet forwarding delay is controlled to be no more than 5μs.

[0187] Resource subpool heartbeat protection: In resource subpool scheduling, an independent CPU time slice is allocated to the heartbeat packets of the subpool where the long connection application is located, such as allocating a dedicated time slice of 1ms every 10ms and a memory buffer such as a dedicated buffer of 20MB, to ensure that the heartbeat packet processing is not affected by other traffic and the heartbeat packet loss rate is controlled to no more than 0.1%.

[0188] Dynamic heartbeat interval adjustment: The heartbeat interval is dynamically optimized based on the physical network status to avoid timeouts or resource waste caused by fixed intervals. Based on RTT adjustment, the HDAA coordinator dynamically adjusts the heartbeat interval to 5 times the RTT according to the synchronized physical network RTT. For example, when RTT=100ms, the heartbeat interval is set to 500ms, and when RTT=500ms, the heartbeat interval is set to 2500ms. The adjustment result is synchronized to the container MNA client via SSS. The custom MNA client remotely calls the modified container-interface ConnectivityManager custom extension interface, passing in the application package name and the updated heartbeat keep-alive interval newInterval, synchronously updating the long connection configuration of the corresponding application in / data / system / long_conn_map.xml, and synchronously pushing it to the HDAA coordinator to update the eBPF forwarding and scheduling policy, notifying the application to update the heartbeat interval.

[0189] Adjustments based on RRC status: When the RRC status in the SSS is connected, the heartbeat interval can be extended to 1.5 times the default value, such as extending the default 30 seconds to 45 seconds; when the RRC status is idle or handover, the heartbeat interval is shortened to 0.5 times the default value, such as 15 seconds, to avoid long connection interruptions caused by the base station releasing the connection in the RRC idle state.

[0190] Long-term connection interruption detection and rapid recovery: Combining physical network status and forwarding feedback, it accurately detects interruptions and quickly recovers.

[0191] Interruption Detection: The HDAA coordinator determines long-lived connection interruptions based on the following conditions: the long-lived application has not received a heartbeat response for more than 3 heartbeat intervals; the physical network RRC handover lasts for more than 1 second without receiving application data; and the packet loss rate of long-lived connections forwarded by eBPF is not less than 5% for 3 consecutive periods. The detection latency is controlled to be no more than 100ms to avoid false positives.

[0192] Fast recovery mechanism:

[0193] For minor interruptions such as no response for one heartbeat interval: the HDAA coordinator triggers the application to send heartbeat packets urgently through the MNA client. The application sends two additional heartbeat packets within 50ms, and the eBPF module prioritizes forwarding the application's data packets.

[0194] For moderate interruptions such as no response for 2 heartbeat intervals or RRC handover interruption: trigger emergency resource scheduling, fully utilize the CPU and memory resources of the sub-pool where the long-connection application is located, such as the high_prio sub-pool with 2 CPU cores and 1GB of memory, clear the backlog of data in the forwarding queue, and ensure that recovery data packets are transmitted first;

[0195] In the event of a severe interruption, such as no response for 3 heartbeat intervals or a brief physical network disconnection: the MNA client guides the application to perform a fast reconnection, with a reconnection timeout of 1 second and 2 reconnection attempts. At the same time, the HDAA coordinator synchronizes the physical network recovery status to ensure that the reconnection request is accurately routed to the physical network.

[0196] S9, Abnormal Circuit Breaker and Fast Recovery, is used to solve the problem of network connection interruption that cannot be recovered in extreme scenarios.

[0197] The definition of anomaly types and detection thresholds are improved by adding two core anomalies to the existing anomaly types and clarifying the detection thresholds to avoid false triggers: Permission invalidation anomaly: the permission status of a certain CNI in SSS is 0x01 for three consecutive cycles, indicating invalidity, and the application request corresponding to that CNI fails at least 5 times; Long connection avalanche anomaly: more than 50% of long connection applications in the same sub-pool simultaneously trigger interruption detection, and the physical network RRC handover lasts for more than 2 seconds. The thresholds for existing anomaly types are optimized: the duration threshold for connection interruption anomalies is adjusted from 100ms to 80ms, the success rate threshold for forwarding failure anomalies is increased, and the throughput threshold for resource insufficiency anomalies is reduced, thereby improving the sensitivity of anomaly detection.

[0198] The abnormal circuit breaker mechanism triggers tiered circuit breakers based on sub-pools and abnormal levels when an abnormality is detected, prioritizing the protection of high-priority applications and long-lived connections.

[0199] In case of minor anomalies, such as invalid permissions, forwarding success rate dropping below the threshold, or long-lived connections not responding for one heartbeat interval, new network requests from non-long-lived connection applications in the normal_prio sub-pool are suspended, and these new requests are rejected, returning a network unavailable exception; for CNIs with invalid permissions, a permission re-verification process is triggered; for long-lived connection applications, a minor interruption recovery is performed.

[0200] In cases of moderate anomalies, such as connection interruption of 80ms to 500ms, insufficient resources, or no response for two heartbeat intervals in long connections, the forwarding queue is cleared, resources are urgently scheduled, and long connection keep-alive enhancement is triggered. The HDAA-eBPF module clears the normal_prio sub-pool forwarding queue, while retaining the high_prio and system_net sub-pool queues; the resources of the high_prio and system_net sub-pools are fully utilized; for long connection applications, the heartbeat interval is shortened to 0.3 times the default value, and heartbeat packets are sent urgently.

[0201] In the event of severe anomalies, such as connection interruption of no less than 500ms, state synchronization failure, long connection avalanche, or forwarding success rate of less than 95%, the container network is reset and long connection batch reconnection is triggered. The HDAA coordinator sends a reset signal to the MNA client to reset the Android container network protocol stack. At the same time, the MNA client triggers batch reconnection of all long connection applications, and reconnection requests are forwarded preferentially through the high_prio sub-pool. The total time for reset and reconnection is controlled to be no more than 1.5 seconds.

[0202] The rapid recovery mechanism works as follows: When the permission invalidation anomaly is resolved (i.e., the permission validity status in the SSS returns to 0x00), the MNA client triggers a broadcast to notify the application to resume network requests. Simultaneously, the HDAA coordinator updates the permission status in the eBPF rule base to ensure that forwarding rules are effective. When the long connection interruption anomaly is resolved, such as when the physical network RTT recovers to no more than 200ms and the RRC falls back to the connected state, the HDAA coordinator notifies the MNA client to restore the heartbeat interval to the default value. The MNA client then triggers the application to resume normal heartbeats. At the same time, the HDAA-eBPF module restores the normal forwarding priority of long connection heartbeat packets. After recovery, the HDAA coordinator verifies the end-to-end recovery status by measuring the values ​​of three parameters: forwarding success rate, resource utilization rate, and long connection reconnection success rate. Once verification is successful, the normal feedback adjustment and resource fine-tuning mechanism is restored.

[0203] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for enhancing the stability of intra-container mobile networks based on cross-system network pass-through, characterized in that, Specifically, the following steps are included: The host starts the mobile network coordinator, deploys a loading and forwarding component between the network protocol stack and the mobile network data interface, intercepts uplink traffic from the container and downlink traffic from the cellular physical interface, and uses a built-in feature matching rule set to distinguish traffic based on the first identifier and permission verification results, and establishes a hierarchical resource pool for container mobile network transmission; the container assigns a first identifier to applications with network access permissions and starts the network adaptation proxy and request routing module. When a container application initiates a mobile network capability call, the container network adaptation agent forwards the first identifier and the permissions to be verified to the mobile network coordinator for verification. If the verification fails, the network adaptation agent terminates the network request; otherwise, the network adaptation agent encapsulates the permission verification result, the first identifier, and the network request parameters into a request context data packet and writes it into shared memory, which is then synchronized to the mobile network coordinator by the request routing module. The mobile network coordinator encapsulates the mobile network data corresponding to the application into a state synchronization data packet, sends a readiness notification, and then distributes the data. The network adaptation agent receives the notification and reads the data from the shared data channel. The network adaptation agent uses the state synchronization data packet to update the relevant parameters of the virtual network card, verify network connectivity, set the application to prioritize the use of the host network, and then pushes the change broadcast. When a container application sends a data packet, the forwarding component intercepts the uplink traffic to obtain core parameters and the application process identifier. When the network interface receives the data packet, the forwarding component intercepts the downlink traffic to determine the target application's first identifier and application process identifier. The data packet is compared with the feature matching rule set. If a match is successful, the comparison is terminated. For uplink data packets, the cellular tunnel identifier is bound, and the corresponding hierarchical resource pool is allocated according to the traffic type before forwarding to the network interface. For downlink data packets, the corresponding hierarchical resource pool is allocated, and then the packet is sent to the target container network space and the link layer identifier is reset. If a match fails, the data packet is discarded.

2. The method for enhancing the stability of mobile networks within a container according to claim 1, characterized in that, The hierarchical resource pool is divided into a high-priority service sub-pool, a normal-priority service sub-pool, and a system network process sub-pool based on the network priority of container applications, corresponding to high-priority applications, normal-priority applications, and underlying network service processes, respectively.

3. The method for enhancing the stability of mobile networks within a container according to claim 1, characterized in that, The rule types in the feature matching rule set include tunnel transmission protocol, mobile communication control plane, general user IP and service permission association. Each rule adopts a fixed-length storage structure to record the communication protocol, transceiver port, bidirectional address, tunnel identifier, first identifier, authorization validity and wireless link status, and reserves expansion space.

4. The method for enhancing the stability of mobile networks within a container according to claim 1, characterized in that, The kernel forwarding component sets up forwarding queues, each hierarchical resource pool is configured with an independent forwarding queue, each queue is configured with a differentiated capacity threshold based on the wireless link status, and a first-in-first-out scheduling method is adopted, with scheduling weights allocated according to application priority; when the queue occupancy reaches the threshold, low-priority data packets are dropped first.

5. The method for enhancing the stability of mobile networks within a container according to claim 2, characterized in that, The container deploys a hierarchical load balancing collection unit to continuously collect application operation data at fixed intervals for hierarchical resource pool groups. This includes the total number of cellular transmission connections, real-time uplink and downlink throughput, data packet retransmission ratio, frequency of permission changes, and number of network request failures. The collected data is encapsulated into hierarchical load balancing feedback data packets and synchronized to the mobile network coordinator. The kernel forwarding component has a built-in hierarchical traffic statistics unit that counts uplink and downlink forwarding success rates, average forwarding latency, queue congestion frequency, and rule matching anomalies according to the hierarchical resource pools. The host collects the computing power usage, buffer memory usage, and resource temporary borrowing and release frequency of each hierarchical resource pool, and generates resource statistics snapshots at fixed intervals for the mobile network coordinator to read. After obtaining hierarchical load feedback packets, traffic statistics, and resource usage snapshots, the mobile network coordinator performs adaptive control: when the throughput rate of a high-priority sub-pool is lower than the threshold or the packet retransmission rate is higher than the threshold, the collection frequency of cellular dynamic network indicators is increased; if the system network sub-pool modulation and demodulation instruction processing delay is greater than the threshold, the scheduling authority of the underlying network process is increased, and the collection frequency of cellular access configuration parameters is increased.

6. The method for enhancing the stability of mobile networks within a container according to claim 1, characterized in that, When a container application initiates a cellular network transmission, it identifies the currently used cellular link and uses the obtained network connectivity status and gateway response identifier as the basis for judgment. Link connectivity determination prioritizes reading the injected physical cellular data link status, and extends the data reading waiting time when wireless link switching causes data stream interruption or increased transmission latency; Create physical network anomaly classification identifiers to distinguish between cellular link failures such as wireless handover and access configuration changes; after capturing physical network anomalies, push network status change notifications to drive the application to execute adaptation and recovery logic, and re-initiate transmission after the wireless link stabilizes.

7. The method for enhancing the stability of mobile networks within a container according to claim 6, characterized in that, Build cellular network status monitoring capabilities, enabling applications to receive real-time network change notifications such as cellular link connectivity, link congestion, and link disconnection after registration.

8. The method for enhancing the stability of mobile networks within a container according to claim 1, characterized in that, To build the long-connection service registration capability of the container network, when an application registers, it submits the first identifier and the default heartbeat sending period. After the host completes the network access permission verification, it binds the first identifier of the corresponding application and stores all long-connection configuration information, and synchronizes it to the mobile network coordinator. The mobile network coordinator has a built-in long connection status log table to record the establishment time of each long connection, the most recent heartbeat transmission and reception time, real-time transmission latency, and wireless link status. The data refresh cycle is the same as the physical network status collection cycle.

9. The method for enhancing the stability of mobile networks within a container according to claim 1, characterized in that, When the number of invalid network permission verifications for the first identifier of an application exceeds the threshold, and the number of network request failures for the application exceeds the threshold, it is determined that a permission abnormality fault has occurred; if the number of interrupted long-connection services in the same hierarchical resource pool exceeds the threshold, and the duration of physical cellular network base station handover exceeds the threshold, it is determined that a batch long-connection fault has occurred. In response to permission anomalies, the mobile network coordinator first refreshes the global permission cache. If the cache repair fails, it rebuilds the corresponding application permission mapping entries. If the failure persists, it isolates the application's traffic resources and restarts the container network adaptation proxy. After the repair is completed, a permission restoration broadcast notification will be issued to lift the network access rate restriction for the application and update the permission verification status indicator simultaneously. For batch long connection failures, the mobile network coordinator clears the congested packet cache in the hierarchical resource pool and batch resets failed cellular tunnel sessions; if the connection interruption is caused by resource exhaustion, the computing power and buffer memory of the corresponding hierarchical resource pool are temporarily expanded; if the link is still not restored, the feature matching rule set of the reload forwarding component is used to complete the repair.

10. The method for enhancing the stability of mobile networks within a container according to claim 2, characterized in that, Set memory usage limits and warning / reclaim thresholds for each type of sub-pool. Initiate the memory reclamation mechanism when memory usage is not less than the warning threshold. Configure a dedicated CPU core binding range for each sub-pool and set differentiated computing power scheduling weights. Configure high-level real-time scheduling permissions for system network processes and high-priority applications, while ordinary applications adopt a time-sharing scheduling mechanism.

Images