Cloud phone streaming system based on edge computing

Abstract

This invention relates to the field of cloud phone technology, specifically a cloud phone streaming system based on edge computing. The system includes a cloud phone client, edge nodes, and a cloud phone server. The client monitors screen status and network quality, autonomously selects target streaming parameters from its local multi-level parameter storage unit, uses the parameters recommended by the edge nodes as initial default values, and sends an adjustment request to the server. The server updates the encoding parameters, encodes the audio and video streams, and sends them to the client for decoding and display. When the screen is black, it automatically switches to a maintenance mode, reducing the bitrate and resolution and periodically sending keyframes. The edge nodes generate a network quality profile based on base station identifiers and network type clustering, recommend parameters for new clients, and implement hierarchical congestion control. This invention achieves near real-time decision-making driven by screen status, reduces invalid bandwidth during black screens, protects user privacy, improves cold start smoothness, and enhances system scalability.

Description

Technical Field

[0001] This invention relates to the field of cloud phone technology, and more specifically to a cloud phone streaming system based on edge computing. Background Technology

[0002] Cloud phones deploy a complete mobile operating system on a cloud server in a virtualized manner, allowing users to remotely access and operate the cloud phone instance through their terminal devices. During cloud phone usage, the cloud server needs to encode and transmit the audio and video streams generated by the cloud phone instance to the user's terminal in real time. The proper configuration of streaming parameters directly affects the user experience and system resource consumption.

[0003] Currently, cloud phone streaming systems mainly employ the following technical solutions: One approach is to use fixed streaming parameters, where the cloud phone server uses the same encoding parameters (such as fixed bitrate, resolution, and frame rate) to encode and push content to all terminal devices. This approach cannot adapt to the network conditions and display requirements of different terminals, and is prone to stuttering or image quality degradation when the network fluctuates.

[0004] Another approach is to determine playback parameters based on network communication status (such as RSRP, SINR) and service type (e.g., Chinese patent application CN114760309A, Service Interaction Method, Apparatus, Device and Medium for Cloud-Based Services). While this approach achieves dynamic adaptation based on network quality, its decision-making is made by the network side or the cloud, failing to fully utilize the local sensing capabilities of the terminal device and neglecting the real-time impact of the terminal screen status on streaming demands.

[0005] Another approach involves the cloud server querying the backend platform for matching streaming parameters based on the currently running application process (such as video, game, or utility applications) (e.g., Chinese invention patent CN117768448B, "A Method, System, and Cloud Server for Audio and Video Stream Transmission Based on Stream Parameter Adaptation"). This approach has the following drawbacks: First, the decision-making relies on a centralized backend platform, requiring the collection of data such as the terminal's IP address, region, and network type, posing a privacy risk. Second, the decision-making process requires round-trip network queries, resulting in high response latency. Third, the backend platform is susceptible to single-point-of-failure risks, limiting system scalability.

[0006] Furthermore, existing cloud phone streaming systems typically continue to encode and transmit audio and video using normal parameters when the terminal device is in a black screen state (such as when the user locks the screen or switches to other local applications), resulting in significant unnecessary bandwidth usage and wasted encoding resources. Chinese invention patent CN117768448B and Chinese patent application CN114760309A do not address the perception and processing of the terminal screen state; they continue to encode and transmit using parameters corresponding to normal service types or network states even in a black screen state, failing to solve the problem of unnecessary bandwidth usage in this state. Simultaneously, newly connected cloud phone clients lack a reasonable initial parameter recommendation mechanism, and unreasonable parameters during the cold start phase can easily lead to lag, affecting user experience. During network congestion, multiple clients independently adjusting parameters can easily cause parameter oscillations and exacerbate congestion; existing systems also lack a trial-and-error parameter adjustment mechanism, and after a one-way degradation, they cannot automatically recover or actively explore better parameter combinations.

[0007] Therefore, how to provide a cloud phone streaming system that can quickly respond to changes in terminal status, protect user privacy, and has good scalability has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0008] In view of this, the present invention provides a cloud phone streaming system based on edge computing, which aims to solve the technical problems of cloud phones in the prior art, such as invalid bandwidth occupation in the black screen state, lack of reasonable initial parameters in the cold start stage, privacy leakage of centralized backend platforms and single point of failure, and provides a screen state driven near real-time adaptive streaming solution.

[0009] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a cloud mobile phone streaming system based on edge computing, comprising: At least one cloud mobile client is deployed on the user's terminal device; At least one edge node is communicatively connected to the cloud mobile client; At least one cloud phone server is communicatively connected to the edge node and the cloud phone client, and cloud phone instances are running on the cloud phone server; The cloud mobile client is configured as follows: Monitor the screen status and current network quality of the user terminal device, wherein the screen status includes at least a bright screen state and a black screen state; Based on the screen status and the current network quality, the cloud mobile client autonomously selects and determines the target streaming parameters from the multi-level parameter storage unit in local storage. The target streaming parameters include at least the target bitrate, target resolution, target frame rate, and encoder preset. In determining the target streaming parameters, the cloud mobile client uses the recommended streaming parameters provided by the edge node as the initial default value, and dynamically adjusts them autonomously based on the real-time monitored current network quality and decoding playback stuttering rate during operation. Send a streaming parameter adjustment request to the cloud phone server, wherein the streaming parameter adjustment request carries the target streaming parameter; The cloud phone server is configured as follows: Receive the stream parameter adjustment request and update the encoder's encoding parameters according to the target stream parameters; The audio and video streams generated by the cloud phone instance are encoded using the updated encoding parameters to obtain the encoded audio and video streams. The encoded audio and video streams are sent to the cloud mobile client; The cloud mobile client is also configured to: when the screen state is black screen, map the target streaming parameters to the black screen maintenance mode, where the target bit rate, target resolution and target frame rate under the black screen maintenance mode are all lower than the normal transmission mode under the screen-on state; Receive and decode the encoded audio and video streams, and display them on the user terminal device; The cloud phone server is also configured to: immediately encode and send a key frame in response to a key frame request sent by the cloud phone client; and, when the screen state is black, to forcibly encode and send a key frame every first preset period according to the request of the cloud phone client.

[0010] In one specific implementation scheme, the cloud mobile client is further configured as follows: When the screen state is black screen, the target streaming parameters are set to the black screen maintenance mode: the target bit rate is set to the minimum non-zero bit rate to maintain the connection heartbeat, the target resolution is reduced to a placeholder resolution lower than the normal transmission threshold, the target frame rate is set to the first preset frame rate, and the cloud phone server is requested to force encoding and send a key frame every first preset period. When the screen state changes from black screen to bright screen, the cloud phone server is immediately requested to send the latest key frame, and the target streaming parameter is dynamically selected from multiple preset parameter levels according to the current network quality. When the screen is on, the current network quality selects a high bitrate and high resolution mode when the first bandwidth condition is met, a medium bitrate and medium resolution mode when the second bandwidth condition is met, and a low bitrate and low resolution mode when the third bandwidth condition is met. The bitrate and resolution in the black screen maintenance mode are both lower than the corresponding values ​​of the low bitrate and low resolution mode.

[0011] In one specific implementation, the edge node is configured as follows: It receives session-level anonymous operation data reported by multiple cloud mobile clients within its coverage area. The session-level anonymous operation data includes at least the network type, time period, currently used streaming parameters, lag rate, signal strength index, and access base station identifier, but does not include the personal identification of the user terminal device or long-term device fingerprint. Based on the access base station identifier and network type, the session-level anonymous operation data is clustered and statistically analyzed to obtain network quality profiles for different time periods within the coverage area of ​​the same base station, and streaming parameters with a stuttering rate lower than a preset threshold and a frequency higher than a preset proportion in each time period are extracted as recommended streaming parameters. In response to the access request from the NewCloud mobile client, the corresponding network quality profile is matched according to the base station identifier currently accessed by the NewCloud mobile client, and the recommended streaming parameters are sent to the NewCloud mobile client. The cloud mobile client is also configured to receive the recommended streaming parameters as initial default values ​​upon first startup or detection of cross-base station handover or a drastic change in the current network quality exceeding a preset range, and initiate local autonomous dynamic adjustment based on the initial default values.

[0012] In one specific implementation, the edge node is further configured as follows: Monitor the outbound bandwidth utilization of the edge node, and set an early warning threshold, a first congestion threshold, and a second congestion threshold, wherein the early warning threshold is lower than the first congestion threshold, and the first congestion threshold is higher than the second congestion threshold; When the outbound bandwidth utilization exceeds the warning threshold but is lower than the first congestion threshold, a load reduction suggestion signal is sent to the cloud mobile clients within the coverage area; When the outbound bandwidth utilization exceeds the first congestion threshold and continues for more than the first preset duration, a forced congestion indication signal is broadcast to all cloud mobile clients within the coverage area. When the outbound bandwidth utilization rate falls below the second congestion threshold and continues for more than the second preset duration, a congestion relief signal is broadcast. The cloud mobile client is also configured to: respond to the load reduction suggestion signal, decide whether to reduce the streaming parameters based on its current network quality; respond to the forced congestion indication signal, immediately reduce the current target bitrate by at least one level; if the current target streaming parameters are already in a low bitrate and low resolution range, maintain the bitrate and resolution of that range and reduce the target frame rate to a preset emergency frame rate; and prohibit sending adjustment requests to increase the streaming parameter level during the duration of the forced congestion indication signal; and respond to the congestion relief signal, allow tentative upward adjustment requests after a third preset duration, with each upward adjustment only allowed to increase by one level, with an interval of at least a fourth preset duration.

[0013] In one specific implementation scheme, the cloud mobile client is further configured to perform the trial adjustments as follows: Establish a trial decision-making window mechanism: When the screen is on and the bandwidth assessment value of the current network quality is consistently higher than the preset redundancy ratio of the current target bitrate for more than a fifth preset duration, an uplink probing window is opened. Within the uplink probing window, the target bitrate is temporarily increased by a preset percentage, and the decoding playback stuttering rate is monitored. If the decoding playback stuttering rate does not exceed a preset stuttering threshold within a sixth preset duration, the increased bitrate is determined as the official target bitrate. Otherwise, it immediately reverts to the original target bitrate, closes the uplink probing window, and enters the first cooling-off period. When the screen is on and the bandwidth assessment value of the current network quality is lower than the preset safety ratio of the current target bitrate for more than a seventh preset time, a downlink probing window is opened. Within the downlink probing window, the target resolution or the target frame rate is temporarily reduced by one level, and the image quality score is monitored. If the image quality score does not fall below the preset tolerance threshold within an eighth preset time, the reduced parameters are maintained. If the image quality score falls below the preset tolerance threshold, the original parameters are restored and the downlink probing window is closed to enter the second cooling-off period. The uplink and downlink probe windows are mutually exclusive, and new probe triggering conditions are prohibited from being responded to while either window is open.

[0014] In one specific implementation scheme, the cloud mobile client is further configured as follows: When reporting the session-level anonymous operation data to the edge node, a temporary session identifier is used instead of the long-term device fingerprint and personal identification identifier of the user terminal device, and the IP address of the user terminal device is not reported. The edge nodes are deployed in the edge equipment room on the base station side or co-located with the base station. Each edge node corresponds to at least one access base station, and its local coverage area is the coverage area of ​​its corresponding base station. The edge nodes are independent of each other. Each edge node only maintains the statistical data and cached content of the corresponding base station within its local coverage area and does not share data with other edge nodes.

[0015] In a specific feasible implementation, the cloud mobile client specifically includes: The status monitoring module is used to periodically monitor the screen status, current network quality, and real-time stuttering rate of the decoding playback of the user terminal device. The screen status includes at least a bright screen state and a black screen state. The local parameter decision engine includes a multi-level parameter storage unit, a state mapping unit, and a trial adjustment unit. The multi-level parameter storage unit stores high, medium, and low normal transmission parameter files as well as a black screen maintenance file. The state mapping unit queries the corresponding parameter file based on the screen state and selects specific parameter values ​​within the parameter file based on the bandwidth assessment value of the current network quality. The trial adjustment unit periodically initiates trial adjustment requests in the screen-on state and determines whether to solidify the adjustment results based on the adjusted stuttering rate or image quality feedback. The request sending module is used to send streaming parameter adjustment requests to the cloud phone server; The stream receiving and decoding module is used to receive encoded audio and video streams and decode and display them. The edge collaboration interface is used for control signaling interaction with edge nodes.

[0016] In one specific implementation scheme, the multi-level parameter storage unit stores a high bitrate high-resolution profile, a medium bitrate medium-resolution profile, a low bitrate low-resolution profile, and a black screen maintenance profile; the state mapping unit is used to directly map to the black screen maintenance profile when the screen state is black screen state; when the screen state is on screen state, it maps to the corresponding profile among the high, medium, and low profiles according to the bandwidth evaluation value of the current network quality.

[0017] In one specific implementation scheme, the edge nodes specifically include: The data collection module is used to receive session-level anonymous operation data reported by multiple cloud mobile clients within its coverage area. The session-level anonymous operation data includes at least the network type, time period, streaming parameters used, lag rate, signal strength index, and access base station identifier. The statistical recommendation module is used to perform cluster statistics on the session-level anonymous operation data based on the access base station identifier and network type, generate network quality profiles for different time periods within the coverage area of ​​the same base station, extract streaming parameters with a stuttering rate lower than a preset threshold and an occurrence frequency higher than a preset proportion in each time period as recommended streaming parameters, and respond to the access request of the New Cloud mobile client by matching the corresponding network quality profile according to the access base station identifier of the New Cloud mobile client and returning the recommended streaming parameters. The congestion control module is used to monitor the outbound bandwidth utilization of the edge node and set an early warning threshold, a first congestion threshold, and a second congestion threshold. When the outbound bandwidth utilization exceeds the first congestion threshold and continues for more than a first preset duration, a forced congestion indication signal is broadcast to all cloud mobile clients within the coverage area. When the outbound bandwidth utilization falls below the second congestion threshold and continues for more than a second preset duration, a congestion relief signal is broadcast.

[0018] In a specific feasible implementation, the cloud phone server specifically includes: The cloud phone instance runtime module is used to generate audio and video streams; An encoder, used to encode the audio and video streams; The parameter adjustment interface is used to receive the streaming parameter adjustment request sent by the cloud mobile client, and update the encoder's encoding parameters according to the target streaming parameters carried in the streaming parameter adjustment request. The streaming push module is used to send the encoded audio and video streams to the cloud mobile client.

[0019] Compared with existing technologies, the cloud mobile phone streaming system based on edge computing described in this invention has the following advantages: 1. This invention autonomously monitors the screen status (on / off screen) and current network quality through a cloud phone client, and accordingly selects and determines the target streaming parameters from a local multi-level parameter storage unit, achieving near real-time decision-making driven by screen status (the decision delay mainly depends on the local query operation and does not require waiting for a cloud response). When the screen is off, it automatically switches to the black screen maintenance mode (minimum heartbeat bitrate, placeholder resolution, periodic keyframes). Compared with the existing technology that still streams with normal parameters when the screen is off, this can reduce the invalid bandwidth transmission in the black screen state (theoretically, it can be reduced to the minimum bitrate required to maintain the connection, which effectively reduces bandwidth usage compared to the normal transmission mode). At the same time, it significantly reduces the encoding load of the cloud phone server and the decoding power consumption of the terminal device, effectively improving resource utilization efficiency.

[0020] 2. This invention introduces an edge node clustering and statistical mechanism based on base station identifiers and network types. By generating network quality profiles for different time periods within the coverage area of ​​the same base station, it provides newly connected cloud mobile clients with recommended streaming parameters that are accurately matched with the current geographical location and network environment as initial default values. This solves the initial lag problem caused by unreasonable parameters during the cold start phase in traditional solutions, and effectively improves the smooth experience for users when they first connect and when switching between base stations.

[0021] 3. This invention sets early warning thresholds, a first congestion threshold, and a second congestion threshold at edge nodes to achieve hierarchical congestion control: when the outbound bandwidth utilization exceeds the early warning threshold, a load reduction suggestion signal is sent, allowing clients to decide whether to lower parameters. When the first congestion threshold is exceeded, a forced congestion indication signal is broadcast, causing all clients to collectively degrade. After the congestion is relieved, a gradual recovery mechanism is adopted (only one level is raised each time with an interval of protection time), avoiding parameter oscillations and congestion aggravation caused by independent decisions by multiple clients, and ensuring the stability and fairness of the overall service in large-scale concurrent scenarios.

[0022] 4. This invention establishes mutually exclusive uplink and downlink probing windows through a cloud mobile client. When the screen is on and the network quality meets the redundancy conditions, it actively probes to increase the bit rate. When the network quality is below the safe ratio, it actively probes to decrease the resolution or frame rate. A cooldown period is set to prevent frequent probes. This achieves the dynamic exploration of the optimal parameter combination under the current network conditions without affecting the user experience, overcoming the defect of existing technologies that cannot automatically recover or probe for upgrades after unidirectional degradation.

[0023] 5. This invention adopts a decentralized decision-making architecture that integrates end-edge-cloud collaboration. The cloud mobile client serves as the real-time decision-making entity, the edge nodes are responsible for regional statistics and congestion coordination, and the cloud mobile server only undertakes the encoding and push function. There is no need to set up a centralized parameter decision-making backend platform. Compared with the existing technology that relies on a centralized backend to collect sensitive information such as IP and region, it can enhance the user privacy protection capability, eliminate the risk of single point of failure, and the system has good horizontal scalability.

[0024] 6. When the screen state changes from black to bright, the cloud phone client immediately requests the server to send the latest key frame. Based on the current network quality, it dynamically selects three parameter levels: high, medium, and low. Combined with the key frame caching mechanism that is periodically sent during the black screen maintenance, the screen can be quickly restored after wake-up. The latency is lower than the waiting time for the normal encoding cycle in the traditional solution, ensuring the continuity of user interaction and the smoothness of visual experience.

[0025] 7. This invention achieves flexible adjustment of encoding efficiency and real-time performance by incorporating encoder preset profiles into the target streaming parameters: in the black screen maintenance mode, a low-latency preset profile (such as Ultrafast) is configured to sacrifice compression efficiency for the fastest encoding speed, thereby significantly reducing encoding power consumption; in the bright screen high dynamic scenario, a low-latency preset profile can also be configured to optimize real-time performance, achieving a fine balance between encoding quality and computing resources. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0027] Figure 1 This is a schematic diagram of the architecture of a cloud mobile phone streaming system based on edge computing, provided in an embodiment of the present invention.

[0028] Figure 2 This is a schematic diagram of the structure of a cloud mobile client provided in an embodiment of the present invention.

[0029] Figure 3 This is a schematic diagram of the structure of an edge node provided in an embodiment of the present invention.

[0030] Figure 4 This is a schematic diagram of the structure of a cloud mobile phone server provided in an embodiment of the present invention. Detailed Implementation

[0031] The technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0032] Example 1: System Overall Architecture and Client-Side Autonomous Decision-Making Mechanism like Figure 1 As shown, the cloud mobile phone streaming system based on edge computing provided in this embodiment adopts an end-edge-cloud collaborative architecture, including three major functional entities: cloud mobile phone client, edge node, and cloud mobile phone server.

[0033] The cloud phone client is deployed on user terminal devices (such as smartphones, tablets, or PCs) to achieve local perception, autonomous decision-making, and stream reception and decoding. The edge nodes are deployed near 5G MEC (Multi-access Edge Computing) servers or base station edge data centers close to the user side to achieve regional statistical analysis and congestion coordination. The cloud phone server is deployed in a cloud data center, running cloud phone instances and providing audio and video encoding services.

[0034] In one alternative implementation, such as Figure 2 As shown, the cloud mobile client includes a status monitoring module, a local parameter decision engine, a request sending module, a stream receiving and decoding module, and an edge collaboration interface. The local parameter decision engine further includes a multi-level parameter storage unit, a status mapping unit, and a trial adjustment unit. The multi-level parameter storage unit stores a multi-level parameter configuration table for the client to autonomously select target stream parameters. The multi-level parameter configuration table includes at least a high bitrate / high resolution setting, a medium bitrate / medium resolution setting, a low bitrate / low resolution setting, and a black screen maintenance setting. The status mapping unit is used to directly map to the black screen maintenance setting when the screen is in a black screen state; and when the screen is in a bright screen state, it maps to the corresponding setting among the high, medium, and low settings based on the bandwidth evaluation value of the current network quality.

[0035] The status monitoring module periodically (e.g., every 100 to 500 milliseconds) monitors the screen status (on or off) and current network quality (including real-time bandwidth assessment, packet loss rate, RTT latency, etc.) of the user terminal device by calling system APIs provided by the terminal operating system (such as the PowerManager service in Android or the UIApplication status callback interface in iOS). Simultaneously, the status monitoring module monitors the real-time stuttering rate during decoding playback (e.g., by counting the number of decoding buffer underflows or frame drop rates per unit time).

[0036] When the screen state is black (e.g., the user presses the power button to lock the screen or switches to another local application), the state mapping unit immediately queries the black screen maintenance profile from the multi-level parameter storage unit. In an optional embodiment, the target bitrate in the black screen maintenance profile can be set to the lowest non-zero bitrate in the range of 10kbps to 100kbps (this range can be adjusted according to the actual encoding format and network transmission protocol used to the minimum bitrate that can maintain the TCP / UDP connection heartbeat; for example, a non-zero bitrate in the range of 20kbps to 50kbps can be selected under the H.264 encoding format), and the target resolution can be set to a placeholder resolution of 64×64 pixels to 128×128 pixels. The choice of this resolution range is based on the following technical considerations: First, 64×64 pixels is divisible by the standard macroblock / coding unit size of H.264 and H.265 encoders (H.264 uses 16×16 macroblocks, which can be divided into 4×4 macroblocks; H.265 supports coding units from 8×8 to 64×64), allowing the encoder to complete the entire encoding process, including intra / inter-frame prediction, transform, quantization, and entropy coding. Second, when the 64×64 pixel decoded image is stretched and displayed on a terminal device, it still presents a blurred but recognizable outline of color blocks. Users can perceive that the cloud phone instance is still running, rather than having no screen at all; third, this resolution can significantly reduce the amount of encoded data in the black screen state (the number of pixels is reduced by about 99% compared to the normal 720p resolution), effectively reducing bandwidth usage and encoding power consumption. The target frame rate can be set from 1fps to 5fps (e.g., 1fps), and the encoder preset can be set to a low latency preset (such as the `ultrafast` or `superfast` preset of the H.264 encoder) to prioritize encoding speed and reduce encoding latency and power consumption.

[0037] The cloud phone client sends a streaming parameter adjustment request to the cloud phone server through the request sending module. The request carries the target streaming parameters and optionally includes a forced keyframe request flag. The cloud phone server, as... Figure 4 As shown, the system includes a cloud phone instance running module, an encoder, a parameter adjustment interface, and a stream push module. After receiving the adjustment request, the parameter adjustment interface updates the encoder's encoding parameters (including bitrate, resolution, frame rate, and encoder preset). The encoder uses the updated parameters to encode the audio and video streams generated by the cloud phone instance, and then sends the encoded audio and video streams to the cloud phone client through the stream push module.

[0038] During the black screen maintenance, the cloud phone server is configured to forcibly encode and send a key frame (I-frame) every first preset period (e.g., 5 to 30 seconds, which can be set according to network stability requirements) to ensure that the encoding context of the cloud phone instance remains continuous while maintaining a minimum connection heartbeat.

[0039] Example 2: Statistical Recommendation and Congestion Control Mechanism for Edge Nodes like Figure 3 As shown, the edge node specifically includes a data collection module, a statistical recommendation module, and a congestion control module.

[0040] Deployment correspondence between edge nodes and base stations The edge nodes are deployed in the edge equipment room on the base station side or co-located with the base station (for example, 5G MEC servers are deployed in the base station equipment room, in the edge data center adjacent to the base station, or directly connected to the base station and the edge node via fiber optic cable). Each edge node corresponds to at least one access base station, and its local coverage area is the wireless signal coverage area of ​​its corresponding base station.

[0041] In one optional implementation, an edge node corresponds to a single base station (such as a macro base station or a micro base station). The edge node only receives and maintains cloud mobile client data within the coverage area of ​​the base station, and the statistical recommendation module only generates a network quality profile for that base station.

[0042] In another alternative implementation, an edge node corresponds to multiple geographically adjacent base station clusters (such as three micro base stations in the same block or multiple indoor distributed base stations in the same building). The edge node maintains an independent network quality profile for each base station and distinguishes the data of different base stations by base station identifiers (such as ECGI, Cell ID or PCI) to avoid confusion of statistical data between different base stations.

[0043] New client access routing mechanism When the new cloud mobile client initiates an access request, it first accesses the core network through its currently connected base station (e.g., accessing base station A via a 5G network). The core network then routes the new cloud mobile client's session-level anonymous operation data reporting request and parameter acquisition request to the edge node corresponding to base station A based on the identifier of base station A.

[0044] The data collection module of the edge node receives session-level anonymous operation data reported by multiple cloud mobile clients within its coverage area. This session-level anonymous operation data includes at least the network type (e.g., 5G, 4G, WiFi), time period (e.g., peak hours, off-peak hours), currently used streaming parameters (bitrate, resolution, frame rate), stuttering rate (e.g., frame loss rate or decoding failure rate), signal strength indicators (e.g., RSRP, RSSI), and access base station identifier (e.g., ECGI or Cell ID). The data does not contain the user terminal device's personal identification identifier (e.g., IMEI, IMSI) or long-term device fingerprint. Furthermore, when reporting, the cloud mobile clients use temporary session identifiers (e.g., UUID v4 or hash values ​​generated based on timestamps and random numbers) instead of long-term device fingerprints, and do not report the user terminal device's IP address.

[0045] The statistical recommendation module performs clustering statistics on the session-level anonymous operation data based on the access base station identifier and network type. In an optional embodiment, the clustering can construct a three-dimensional profile index: base station coverage area × network type × time period. For the same cluster unit (e.g., 5G network within the coverage area of ​​base station A during the evening period of 20:00-22:00), the statistical recommendation module extracts streaming parameter combinations with a stuttering rate lower than a preset quality threshold (e.g., 3% to 8%, which can be dynamically set according to user experience requirements) and an occurrence frequency higher than a preset proportion (e.g., 50% to 70%) in each time period as recommended streaming parameters.

[0046] In response to the access request from the new cloud mobile client, the edge node queries the locally maintained mapping relationship based on the access base station identifier of the new cloud mobile client, matches the corresponding network quality profile, and sends the recommended streaming parameters to the new cloud mobile client as initial default values. When the cloud mobile client starts up for the first time, detects a cross-base station handover (e.g., from base station A to base station B), or experiences a drastic change in the current network quality exceeding a preset change range (e.g., a bandwidth sudden change exceeding 50%), it receives the recommended streaming parameters as initial default values ​​and initiates local autonomous dynamic adjustment based on the initial default values ​​(i.e., subsequent autonomous fine-tuning based on real-time monitoring data).

[0047] Tiered congestion control and minimum protection mechanism The congestion control module monitors the egress bandwidth utilization of the edge nodes and sets three threshold levels to achieve hierarchical congestion control: A. Warning threshold: For example, 70% to 80% of the outbound bandwidth utilization. When the utilization exceeds this threshold but is lower than the first congestion threshold, a load reduction suggestion signal is sent to the cloud mobile clients within the coverage area (e.g., via UDP broadcast or WebSocket push). The cloud mobile clients then decide whether to reduce the streaming parameters based on their current network quality (e.g., whether the real-time bandwidth monitored locally is sufficient). B. First congestion threshold: For example, 85% to 95% of the outbound bandwidth utilization. When this threshold is exceeded and continues for more than a first preset duration (e.g., 20 to 60 seconds), a forced congestion indication signal is broadcast to all cloud mobile clients within the coverage area, requiring the clients to immediately reduce the current target bitrate by at least one level (e.g., from high bitrate to medium bitrate), and during the duration of the forced congestion indication signal, requests to increase the streaming parameter level are prohibited. C. Second congestion threshold: For example, 60% to 70% of the outbound bandwidth utilization (fallback threshold). When the outbound bandwidth utilization falls below this threshold and continues for more than a second preset duration (e.g., 40 seconds to 120 seconds), a congestion relief signal is broadcast.

[0048] Forced congestion degradation logic: In response to the forced congestion indication signal, the cloud mobile client immediately reduces the current target bitrate by at least one level. For example, if it is currently in a high bitrate, high resolution setting, it will be reduced to a medium bitrate, medium resolution setting; if it is currently in a medium bitrate, medium resolution setting, it will be reduced to a low bitrate, low resolution setting.

[0049] If the cloud mobile client is currently in a low bitrate, low resolution mode (i.e., the lowest level under normal transmission conditions), since there are no other available normal transmission modes below this level (the black screen maintenance mode is specifically for black screen states, and its placeholder resolution is indistinguishable under bright screen conditions), the bitrate and resolution of this low bitrate, low resolution mode are maintained unchanged. However, the target frame rate is further reduced to a preset emergency frame rate (e.g., 10fps to 15fps, or the lowest smooth frame rate supported by the terminal's decoding capabilities). This is to minimize bandwidth usage while ensuring basic image recognizability, thus ensuring the effective execution of congestion control commands. The emergency frame rate is designed based on the fact that in forced congestion scenarios, user actions are typically static or quasi-static interactions such as viewing notifications, browsing desktop icons, and reading text messages, with slow changes in screen content. Research on human visual characteristics shows that for slow-changing scenarios, a frame rate of 10-15fps is sufficient for users to clearly distinguish text, icons, and interface layouts on the screen, thereby achieving "basic image recognizability." This emergency frame rate is only used temporarily during the duration of the forced congestion indication signal. Once the congestion is relieved, the system will gradually restore to the normal frame rate according to the gradual recovery mechanism. For dynamic scenarios (such as games and video playback), since forced congestion is usually caused by instantaneous traffic peaks and lasts for a short period of time (usually within tens of seconds), the temporary drop in frame rate during the emergency frame rate will not have a long-term negative impact on the overall user experience.

[0050] The cloud mobile client is prohibited from sending adjustment requests to increase the streaming parameter level during the duration of the forced congestion indication signal. In response to the congestion relief signal, the cloud mobile client is allowed to initiate tentative adjustment requests after a third preset duration (e.g., an initial cooldown period of 20 to 40 seconds), and each adjustment is only allowed to increase by one level (e.g., from emergency frame rate to low bitrate standard frame rate, or from low bitrate to medium bitrate), with an interval of at least a fourth preset duration (e.g., 30 to 60 seconds) to prevent congestion bounce and parameter oscillation.

[0051] In this embodiment: The first preset duration is used to determine whether the outbound bandwidth utilization rate continuously exceeds the first congestion threshold, so as to avoid erroneously triggering the forced congestion indication due to instantaneous traffic fluctuations. It can be understood as the congestion duration confirmation duration. The second preset duration is used to confirm that the outbound bandwidth utilization has stabilized and fallen below the second congestion threshold, in order to exclude false relief caused by brief jitters. It can be understood as the congestion relief stabilization duration. The third preset duration is used to give the system a cooling-off period after the congestion is cleared, to prevent multiple clients from simultaneously initiating upgrade requests and causing secondary congestion. It can be understood as the congestion clearing cooling-off period. The fourth preset duration is used to limit the minimum interval during the trial adjustment process of the client, so as to avoid congestion rebound caused by frequent parameter adjustments. It can be understood as the trial adjustment interval duration.

[0052] The specific values ​​of the above preset durations can be configured according to the actual network environment and system stability requirements. The numerical ranges given in this embodiment (e.g., 20-60 seconds, 40-120 seconds, etc.) are only examples.

[0053] Example 3: Trial Adjustment Mechanism and Session-Level Anonymity Protection like Figure 2 As shown, the cloud mobile client's trial adjustment unit establishes a trial decision window mechanism, and uses a state machine to achieve mutual exclusion control of uplink and downlink trials.

[0054] The state machine includes at least the following states: Idle, Uplink Probe, Downlink Probe, Uplink Cooling Up, and Downlink Cooling Down.

[0055] Uplink probing logic: When the screen is on and the bandwidth assessment value of the current network quality is consistently higher than the preset redundancy ratio (e.g., 110% to 130%) of the current target bitrate for more than a fifth preset duration (e.g., 20 to 60 seconds), the state machine transitions from the IDLE state to the UP_PROBE state, opening the uplink probing window. Within the uplink probing window, the cloud phone client temporarily increases the target bitrate by a preset percentage (e.g., 10% to 30%) for a sixth preset duration (e.g., a probing observation period of 5 to 15 seconds), and monitors the decoding playback stuttering rate. If the decoding playback stuttering rate does not exceed the preset stuttering threshold (e.g., 5% to 10%) within the sixth preset duration, the increased bitrate is determined as the official target bitrate, and the state machine returns to IDLE; otherwise, it immediately reverts to the original target bitrate, and the state machine enters a first cooldown period (e.g., 30 to 90 seconds) before returning to IDLE.

[0056] Downlink Probing Logic: When the screen is on and the bandwidth assessment value of the current network quality is lower than the preset safety ratio (e.g., 70% to 90%) of the current target bitrate for more than a seventh preset duration (e.g., 15 to 40 seconds), the state machine transitions from the IDLE state to the DOWN_PROBE state, opening the downlink probing window. Within the downlink probing window, the target resolution is temporarily reduced by one level (e.g., from 1080p to 720p) or the target frame rate is reduced by one level (e.g., from 60fps to 30fps) for an eighth preset duration (e.g., 10 to 20 seconds), monitoring the image quality score and network recovery indicators. If the image quality score does not fall below the preset tolerance threshold within the eighth preset duration, the reduced parameters are maintained; otherwise (i.e., the image quality score falls below the preset tolerance threshold), the original parameters are restored and the downlink probing window is closed, entering a second cooldown period (e.g., 45 to 120 seconds). Image quality scores can be obtained through objective no-reference image quality assessment algorithms, such as image complexity analysis based on natural scene statistics (including but not limited to calculating structural similarity (SSIM), peak signal-to-noise ratio (PSNR), or image gradient changes between adjacent frames), or blind image quality assessment algorithms based on pre-trained models, such as NIQE (Natural Image Quality Evaluator) and BRISQUE (Blind / Referenceless Image Spatial Quality Evaluator). If the performance of the terminal device allows, no-reference image quality assessment models based on deep neural networks can also be used.

[0057] Mutual exclusion mechanism: The uplink and downlink probing windows are mutually exclusive. Specifically, when the state machine is in the UP_PROBE or COOLING_UP state, it is prohibited from responding to downlink probing trigger conditions; when it is in the DOWN_PROBE or COOLING_DOWN state, it is prohibited from responding to uplink probing trigger conditions. The state machine implements this mutual exclusion logic through a mutex lock or a state flag, ensuring that new probing trigger conditions are prohibited during the opening of either window, thus preventing parameter oscillations.

[0058] Session-level anonymity is implemented as follows: When the cloud mobile client reports session-level anonymous runtime data to the edge node, a temporary session identifier (Session ID) is generated. This identifier can be a 128-bit UUID or generated by concatenating the current timestamp with a 16-bit random number and then hashing it using SHA-256 to obtain the first 32 bits. The lifecycle of the session identifier is bound to the cloud mobile streaming session; it is destroyed when the session ends and is not stored in the terminal's persistent storage medium. The edge nodes are independent of each other. Each edge node only maintains statistical data and cached content within its local coverage area and does not share data with other edge nodes. Local data storage is achieved through physical isolation or logical isolation (such as independent database instances and no cross-node API calls).

[0059] Example 4: Quick Screen Resume and Parameter Mapping like Figure 2 As shown, the state mapping unit in the local parameter decision engine performs parameter level mapping based on the screen state and the current network quality.

[0060] The multi-level parameter storage unit stores four levels of parameter configurations: high bitrate and high resolution, medium bitrate and medium resolution, low bitrate and low resolution, and black screen persistence. In an optional embodiment, the mapping logic of the four levels of parameters is shown in the table below (the numerical range can be adjusted according to the actual network environment and terminal performance): Note 1: The emergency frame rate (10-15fps) in forced congestion scenarios is lower than the normal low bitrate 24fps. The emergency frame rate is only used for a brief transition during extreme congestion. Its design is based on the fact that when the human eye is viewing static or quasi-static images, 10-15fps is sufficient to ensure the basic recognition ability of interface elements (text, icons, buttons). At the same time, this mode, combined with placeholder resolution (the low bitrate is already a non-placeholder resolution, and the emergency frame rate does not further reduce the resolution), ensures that users can still perform basic operations during congestion.

[0061] Note 2: The target frame rate for the black screen maintenance mode (e.g., 1fps to 5fps) is defined as the first preset frame rate, used to maintain the heartbeat connection of audio and video streams at an extremely low frame rate in the black screen state, while minimizing encoding and transmission overhead. The specific value of this frame rate can be adjusted according to network connection stability requirements.

[0062] When the screen state returns from black to bright, the cloud phone client immediately sends a request for the latest keyframe (carrying the `ForceKeyFrame=1` flag) to the cloud phone server through the request sending module. The cloud phone server responds to the request by immediately encoding and sending the latest keyframe, instead of waiting for the next periodic keyframe (e.g., the next I-frame in a P-frame sequence), thereby achieving a sub-second (e.g., 100 to 500 milliseconds) screen recovery delay.

[0063] The state mapping unit dynamically selects the corresponding level among the high, medium, and low levels according to the current network quality, and can optionally configure a progressive improvement strategy: for example, when recovering from the black screen maintenance level, it can first switch to the low bit rate level, and after the network quality is stabilized for a second preset time (such as 5 seconds), it can then be improved to the medium bit rate level as appropriate to avoid visual discomfort caused by sudden changes in the screen.

[0064] Those skilled in the art will understand that the parameter ranges (such as bit rate range, threshold percentage, and time duration) involved in the above embodiments are merely illustrative examples. In actual deployment, they can be adaptively adjusted according to the specific network environment (such as 5G / 4G / WiFi characteristics), terminal device performance (such as decoding capability and battery capacity), and business requirements (such as different QoS requirements for cloud gaming, cloud office, and cloud video). These adjustments do not depart from the protection scope of this invention.

[0065] The above description is merely an optional embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0066] The various embodiments described in this specification are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A cloud mobile phone streaming system based on edge computing, characterized in that, include: At least one cloud mobile client is deployed on the user's terminal device; At least one edge node is communicatively connected to the cloud mobile client; At least one cloud phone server is communicatively connected to the edge node and the cloud phone client, and cloud phone instances are running on the cloud phone server; The cloud mobile client is configured as follows: Monitor the screen status and current network quality of the user terminal device, wherein the screen status includes at least a bright screen state and a black screen state; Based on the screen status and the current network quality, the cloud mobile client autonomously selects and determines the target streaming parameters from the multi-level parameter storage unit in local storage. The target streaming parameters include at least the target bitrate, target resolution, target frame rate, and encoder preset. In determining the target streaming parameters, the cloud mobile client uses the recommended streaming parameters provided by the edge node as the initial default value, and dynamically adjusts them autonomously based on the real-time monitored current network quality and decoding playback stuttering rate during operation. Send a streaming parameter adjustment request to the cloud phone server, wherein the streaming parameter adjustment request carries the target streaming parameter; The cloud phone server is configured as follows: Receive the stream parameter adjustment request and update the encoder's encoding parameters according to the target stream parameters; The audio and video streams generated by the cloud phone instance are encoded using the updated encoding parameters to obtain the encoded audio and video streams. The encoded audio and video streams are sent to the cloud mobile client; The cloud mobile client is also configured to: when the screen state is black screen, map the target streaming parameters to the black screen maintenance mode, where the target bit rate, target resolution and target frame rate under the black screen maintenance mode are all lower than the normal transmission mode under the screen-on state; Receive and decode the encoded audio and video streams, and display them on the user terminal device; The cloud phone server is also configured to: immediately encode and send a key frame in response to a key frame request sent by the cloud phone client; and, when the screen state is black, to forcibly encode and send a key frame every first preset period according to the request of the cloud phone client.

2. The cloud mobile phone streaming system based on edge computing according to claim 1, characterized in that, The cloud mobile client is also configured as follows: When the screen state is black screen, the target streaming parameters are set to the black screen maintenance mode: the target bit rate is set to the minimum non-zero bit rate to maintain the connection heartbeat, the target resolution is reduced to a placeholder resolution lower than the normal transmission threshold, the target frame rate is set to the first preset frame rate, and the cloud phone server is requested to force encoding and send a key frame every first preset period. When the screen state changes from black screen to bright screen, the cloud phone server is immediately requested to send the latest key frame, and the target streaming parameter is dynamically selected from multiple preset parameter levels according to the current network quality. When the screen is on, the current network quality selects a high bitrate and high resolution mode when the first bandwidth condition is met, a medium bitrate and medium resolution mode when the second bandwidth condition is met, and a low bitrate and low resolution mode when the third bandwidth condition is met. The bitrate and resolution in the black screen maintenance mode are both lower than the corresponding values ​​of the low bitrate and low resolution mode.

3. The cloud mobile phone streaming system based on edge computing according to claim 1, characterized in that, The edge node is configured as follows: It receives session-level anonymous operation data reported by multiple cloud mobile clients within its coverage area. The session-level anonymous operation data includes at least the network type, time period, currently used streaming parameters, lag rate, signal strength index, and access base station identifier, but does not include the personal identification of the user terminal device or long-term device fingerprint. Based on the access base station identifier and network type, the session-level anonymous operation data is clustered and statistically analyzed to obtain network quality profiles for different time periods within the coverage area of ​​the same base station, and streaming parameters with a stuttering rate lower than a preset threshold and a frequency higher than a preset proportion in each time period are extracted as recommended streaming parameters. In response to the access request from the NewCloud mobile client, the corresponding network quality profile is matched according to the base station identifier currently accessed by the NewCloud mobile client, and the recommended streaming parameters are sent to the NewCloud mobile client. The cloud mobile client is also configured to receive the recommended streaming parameters as initial default values ​​upon first startup or detection of cross-base station handover or a drastic change in the current network quality exceeding a preset range, and initiate local autonomous dynamic adjustment based on the initial default values.

4. The cloud mobile phone streaming system based on edge computing according to claim 2, characterized in that, The edge node is also configured to: Monitor the outbound bandwidth utilization of the edge node, and set an early warning threshold, a first congestion threshold, and a second congestion threshold, wherein the early warning threshold is lower than the first congestion threshold, and the first congestion threshold is higher than the second congestion threshold; When the outbound bandwidth utilization exceeds the warning threshold but is lower than the first congestion threshold, a load reduction suggestion signal is sent to the cloud mobile clients within the coverage area; When the outbound bandwidth utilization exceeds the first congestion threshold and continues for more than the first preset duration, a forced congestion indication signal is broadcast to all cloud mobile clients within the coverage area. When the outbound bandwidth utilization rate falls below the second congestion threshold and continues for more than the second preset duration, a congestion relief signal is broadcast. The cloud mobile client is also configured to: respond to the load reduction suggestion signal, decide whether to reduce the streaming parameters based on its current network quality; respond to the forced congestion indication signal, immediately reduce the current target bitrate by at least one level; if the current target streaming parameters are already in a low bitrate and low resolution range, maintain the bitrate and resolution of that range and reduce the target frame rate to a preset emergency frame rate; and prohibit sending adjustment requests to increase the streaming parameter level during the duration of the forced congestion indication signal; and respond to the congestion relief signal, allow tentative upward adjustment requests after a third preset duration, with each upward adjustment only allowed to increase by one level, with an interval of at least a fourth preset duration.

5. The cloud mobile phone streaming system based on edge computing according to claim 1, characterized in that, The cloud mobile client is also configured to perform the trial adjustments as follows: Establish a trial decision-making window mechanism: When the screen is on and the bandwidth assessment value of the current network quality is consistently higher than the preset redundancy ratio of the current target bitrate for more than a fifth preset duration, an uplink probing window is opened. Within the uplink probing window, the target bitrate is temporarily increased by a preset percentage, and the decoding playback stuttering rate is monitored. If the decoding playback stuttering rate does not exceed a preset stuttering threshold within a sixth preset duration, the increased bitrate is determined as the official target bitrate. Otherwise, it immediately reverts to the original target bitrate, closes the uplink probing window, and enters the first cooling-off period. When the screen is on and the bandwidth assessment value of the current network quality is lower than the preset security ratio of the current target bitrate for more than the seventh preset time, the downlink probing window is opened; within the downlink probing window, the target resolution or the target frame rate is temporarily reduced by one level, and the image quality score is monitored. If the image quality score does not fall below the preset tolerance threshold within the eighth preset time period, the reduced parameters are maintained; if the image quality score falls below the preset tolerance threshold, the original parameters are restored and the downlink probe window is closed to enter the second cooling period. The uplink and downlink probe windows are mutually exclusive, and new probe triggering conditions are prohibited from being responded to while either window is open.

6. The cloud mobile phone streaming system based on edge computing according to claim 3, characterized in that, The cloud mobile client is also configured as follows: When reporting the session-level anonymous operation data to the edge node, a temporary session identifier is used instead of the long-term device fingerprint and personal identification identifier of the user terminal device, and the IP address of the user terminal device is not reported. The edge nodes are deployed in the edge equipment room on the base station side or co-located with the base station. Each edge node corresponds to at least one access base station, and its local coverage area is the coverage area of ​​its corresponding base station. The edge nodes are independent of each other. Each edge node only maintains the statistical data and cached content of the corresponding base station within its local coverage area and does not share data with other edge nodes.

7. The cloud mobile phone streaming system based on edge computing according to claim 1, characterized in that, The cloud mobile client specifically includes: The status monitoring module is used to periodically monitor the screen status, current network quality, and real-time stuttering rate of the decoding playback of the user terminal device. The screen status includes at least a bright screen state and a black screen state. The local parameter decision engine includes a multi-level parameter storage unit, a state mapping unit, and a trial adjustment unit. The multi-level parameter storage unit stores high, medium, and low normal transmission parameter files as well as a black screen maintenance file. The state mapping unit queries the corresponding parameter file based on the screen state and selects specific parameter values ​​within the parameter file based on the bandwidth assessment value of the current network quality. The trial adjustment unit periodically initiates trial adjustment requests in the screen-on state and determines whether to solidify the adjustment results based on the adjusted stuttering rate or image quality feedback. The request sending module is used to send streaming parameter adjustment requests to the cloud phone server; The stream receiving and decoding module is used to receive encoded audio and video streams and decode and display them. The edge collaboration interface is used for control signaling interaction with edge nodes.

8. The cloud mobile phone streaming system based on edge computing according to claim 7, characterized in that, The multi-level parameter storage unit stores high bitrate and high resolution profiles, medium bitrate and medium resolution profiles, low bitrate and low resolution profiles, and black screen maintenance profiles. The state mapping unit is used to directly map the screen to the black screen maintenance profile when the screen state is black screen; when the screen state is on screen, it maps the screen to the corresponding profile among the high, medium, and low profiles based on the bandwidth evaluation value of the current network quality.

9. The cloud mobile phone streaming system based on edge computing according to claim 1, characterized in that, Edge nodes specifically include: The data collection module is used to receive session-level anonymous operation data reported by multiple cloud mobile clients within its coverage area. The session-level anonymous operation data includes at least the network type, time period, streaming parameters used, lag rate, signal strength index, and access base station identifier. The statistical recommendation module is used to perform cluster statistics on the session-level anonymous operation data based on the access base station identifier and network type, generate network quality profiles for different time periods within the coverage area of ​​the same base station, extract streaming parameters with a stuttering rate lower than a preset threshold and an occurrence frequency higher than a preset proportion in each time period as recommended streaming parameters, and respond to the access request of the New Cloud mobile client by matching the corresponding network quality profile according to the access base station identifier of the New Cloud mobile client and returning the recommended streaming parameters. The congestion control module is used to monitor the outbound bandwidth utilization of the edge node and set an early warning threshold, a first congestion threshold, and a second congestion threshold. When the outbound bandwidth utilization exceeds the first congestion threshold and continues for more than a first preset duration, a forced congestion indication signal is broadcast to all cloud mobile clients within the coverage area. When the outbound bandwidth utilization falls below the second congestion threshold and continues for more than a second preset duration, a congestion relief signal is broadcast.

10. The cloud mobile phone streaming system based on edge computing according to claim 1, characterized in that, Cloud phone servers specifically include: The cloud phone instance runtime module is used to generate audio and video streams; An encoder, used to encode the audio and video streams; The parameter adjustment interface is used to receive the streaming parameter adjustment request sent by the cloud mobile client, and update the encoder's encoding parameters according to the target streaming parameters carried in the streaming parameter adjustment request. The streaming push module is used to send the encoded audio and video streams to the cloud mobile client.

Images