Communication method and device

By carrying network congestion condition parameters and forwarding rate indication information in data packets, the congestion level of network equipment is dynamically adjusted, solving the high latency problem caused by network congestion in interactive media services and improving data transmission efficiency and user experience.

CN120602989APending Publication Date: 2025-09-05HUAWEI CLOUD COMPUTING TECHNOLOGIES CO LTD +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202410251088.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-03-05
Publication Date
2025-09-05

AI Technical Summary

Technical Problem

In interactive media services, the high latency problem caused by network congestion makes it difficult to meet low latency requirements. Existing technologies cannot effectively alleviate the congestion of network equipment, affecting the quality of data transmission.

Method used

By carrying network congestion condition parameters and forwarding rate indication information in data packets, network devices dynamically adjust the network congestion level. The sender adjusts the data transmission strategy based on the feedback information to reduce the congestion level of network devices and meet the low latency requirements of interactive media services.

Benefits of technology

It achieves accurate assessment and dynamic adjustment of network congestion, reduces congestion of network equipment, reduces data transmission delay, and improves the user experience of interactive media services.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120602989A_ABST
    Figure CN120602989A_ABST
Patent Text Reader

Abstract

The invention provides a communication method and device, and the method comprises the steps: obtaining a network congestion condition parameter in response to a first data packet transmitted by a transmitting end; and determining the network congestion degree based on the network congestion condition parameters. And according to the obtained network congestion degree, adding a network congestion identifier to at least one data packet from the sending end. Thus, the dynamic adjustment of the network congestion condition parameters of the network equipment side can be realized, and the network equipment can obtain the network congestion degree corresponding to the sending end based on the network congestion parameters indicated by the sending end, so that the accuracy of judgment of the network congestion degree is improved, the control of the sending end on the network congestion degree is more accurate, and the user experience is improved. And the requirement of the sending end on low time delay is met.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The embodiments of the present application relate to the field of communications, and in particular to a communication method and apparatus. Background Art

[0002] Interactive media services generally refer to services where hardware on cloud infrastructure performs real-time rendering and video encoding of service-related content based on operational instructions uploaded by client terminals. The encoded video stream is then transmitted to the client terminal over the internet for decoding and display. Examples of interactive media services include cloud phones, cloud desktops, and cloud gaming. These services all share a common requirement for low latency in operational interactions. However, as systems expand and data volumes increase, network congestion may occur. Therefore, meeting the low latency requirements of interactive media services in the face of network congestion is a pressing issue. Summary of the Invention

[0003] The present application provides a communication method and apparatus that can meet the low-latency requirements of interactive media services.

[0004] In a first aspect, the present application provides a communication method, comprising: obtaining a network congestion condition parameter in response to a first data packet sent by a transmitter; determining a network congestion level based on the network congestion condition parameter; and adding a network congestion indicator to at least one data packet from the transmitter based on the obtained network congestion level. In this manner, the transmitter in the present application can set corresponding network congestion condition parameters based on scenario requirements, and the network device can dynamically set network congestion condition parameters corresponding to the data packet from the transmitter based on the transmitter's instructions, and determine the network congestion level between the transmitter and the transmitter based on the network congestion condition parameters. In other words, in the present application, the network device can obtain the network congestion levels corresponding to different transmitters with different services based on the network congestion conditions set by different transmitters, thereby meeting the different service requirements of different transmitters. For example, for services with low latency requirements, such as interactive media services, the corresponding transmitter can set appropriate network congestion conditions so that the network device can determine the corresponding network congestion level based on the network congestion condition parameters, thereby improving the accuracy of measuring the network congestion level. In this way, after the network device can accurately obtain the network congestion level corresponding to the sending end, each device in the system can execute corresponding measures based on the network congestion level of the network device to alleviate the pressure on the network device side, thereby reducing the congestion level of the network device and avoiding affecting the data transmission delay of the interactive media service. It can be understood that the sending end can achieve precise control of data transmission based on the network congestion level fed back by the network device through the network congestion identifier, and meet the low latency requirements of interactive media services. In addition, by adding a network congestion identifier, the network device enables other devices to estimate the network congestion level of the network device based on the network congestion identifier and adjust the data transmission status in the system in a timely manner, thereby increasing or decreasing the forwarding rate of the network device according to the network congestion level of the network device.

[0005] Illustratively, the first data packet may be included in at least one data packet, or may not be included in at least one datagram.

[0006] Illustratively, the marked data packet may be a data packet received after the first data packet.

[0007] Exemplarily, the network device may perform a network congestion level determination on each received data packet based on the acquired network congestion condition parameters.

[0008] Exemplarily, each data packet sent by the sending end may include a network congestion condition parameter.

[0009] In one possible implementation, the method further includes: forwarding a data packet from the sending end to the receiving end; receiving a second data packet; wherein the first receiving interval between the first data packet and the second data packet is different from the second receiving interval between the first data packet and the third data packet, the third data packet is the previous data packet of the first data packet, the first receiving interval is adjusted by the sending end based on the number of network congestion identifiers, and the number of network congestion identifiers is obtained by the receiving end based on the statistics of the received data packets and sent to the sending end. In this way, the receiving end can count the number of network congestion identifiers based on the network congestion identifiers carried by the data packets and feed it back to the sending end. The sending end can estimate the degree of network congestion on the network device side based on the number of network congestion identifiers. Therefore, based on the degree of network congestion, the rate of sending data to the network device can be updated to increase or decrease the transmission load of the network device.

[0010] In one possible implementation, the network congestion condition parameters include a maximum delay and a minimum delay. Thus, the transmitting end in the embodiment of the present application can set the maximum delay and the minimum delay corresponding to the transmitting end based on service requirements, etc., so that the network device can estimate the network congestion level for the transmitting end based on the maximum delay and the minimum delay, thereby improving the accuracy of the network congestion level judgment.

[0011] In one possible implementation, the maximum and minimum delay values ​​are set by the transmitter based on the service type. Thus, the transmitter in this application can set the corresponding maximum and minimum delay values ​​based on the service type to meet the needs of different service scenarios. In other words, the network device in this application can adjust the corresponding network congestion condition parameters for different services to improve the accuracy of network congestion level estimation.

[0012] In one possible implementation, determining the degree of network congestion based on network congestion condition parameters includes: placing a first data packet in a target cache queue; obtaining a delay value corresponding to the first data packet in the target cache queue, where the delay value indicates the duration between the first data packet being placed in the target cache queue and being removed from the target cache queue; and determining the degree of network congestion based on the delay value, the maximum delay value, and the minimum delay value. In this way, the network device can apply the network congestion condition parameters indicated by the sender to the cache queue corresponding to the sender, thereby estimating the degree of network congestion in the cache queue based on the queuing delay of the data packet in the cache queue and the network congestion condition parameters.

[0013] In one possible implementation, the network congestion condition parameter is carried in a header field of the first data packet. In this way, the network device can obtain the network congestion condition parameter by reading the header field, providing a way to carry or indicate the network congestion condition parameter.

[0014] For example, the header field may also be referred to as a control field, which is not limited in this application.

[0015] In a possible implementation, the network congestion condition is carried in the IP field of the first data packet. Alternatively, the network congestion condition may also be carried in the TCP field.

[0016] In one possible implementation, the first data packet also includes forwarding rate acquisition indication information, and the method further includes: acquiring the forwarding rate based on the forwarding rate acquisition indication information; adding the forwarding rate to the first data packet; and sending the first data packet to the receiving end. In this way, the network device of the present application feeds back the forwarding rate of the local end to the receiving end through the data packet in real time, so that the receiving end feeds back the forwarding rate to the sending end. The sending end can further estimate the network congestion level more accurately based on the forwarding rate of the network device. It can also be understood as predicting the network congestion level of the network device in advance based on the forwarding rate, and timely adjusting the rate of sending data packets to the network device, thereby avoiding network device congestion and affecting the data interaction delay between the sending end and the receiving end.

[0017] In one possible implementation, the method further includes: receiving a fourth data packet; wherein the third receiving interval between the first data packet and the fourth data packet is different from the second receiving interval between the first data packet and the third data packet, the third data packet is the data packet preceding the first data packet, the third receiving interval is adjusted by the sender based on the number of network congestion identifiers and the forwarding rate, the number of network congestion identifiers is obtained by the receiver based on the statistics of the received data packets and sent to the sender, and the forwarding rate is sent to the sender when the receiver detects that the forwarding rate carried by the first data packet is different from the forwarding rate obtained previously. In this way, the network device of the present application feeds back the forwarding rate of the local end to the receiver via data packets in real time, so that the receiver feeds back the forwarding rate to the sender. The sender can further estimate the network congestion level more accurately based on the forwarding rate of the network device. It can also be understood that the network congestion level of the network device is predicted in advance based on the forwarding rate, and the rate of sending data packets to the network device is adjusted in a timely manner, thereby avoiding network device congestion and affecting the data exchange delay between the sender and the receiver.

[0018] In a possible implementation manner, the forwarding rate acquisition indication information is carried in a header field of the first data packet.

[0019] In a possible implementation manner, the forwarding rate acquisition indication information is carried in the IP field of the first data packet.

[0020] In a second aspect, the present application provides a communication device, characterized in that it includes: an acquisition module for acquiring network congestion condition parameters in response to a first data packet sent by a sending end; a determination module for determining the degree of network congestion based on the network congestion condition parameters; and a marking module for adding a network congestion identifier to at least one data packet from the sending end according to the acquired network congestion degree.

[0021] In one possible implementation, the device also includes: a communication module, used to forward the data packet from the sending end to the receiving end; the communication module, also used to receive the second data packet; wherein, the first receiving interval between the first data packet and the second data packet is different from the second receiving interval between the first data packet and the third data packet, the third data packet is the previous data packet of the first data packet, the first receiving interval is adjusted by the sending end based on the number of network congestion identifiers, and the number of network congestion identifiers is obtained by the receiving end based on the statistics of the received data packets and sent to the sending end.

[0022] In a possible implementation, the network congestion condition parameters include a maximum delay and a minimum delay.

[0023] In a possible implementation, the maximum delay value and the minimum delay value are set by the transmitting end based on the service type.

[0024] In one possible implementation, the determination module is specifically used to: place a first data packet in a target cache queue; obtain a delay value corresponding to the first data packet in the target cache queue, where the delay value is used to indicate the duration between the first data packet being placed in the target cache queue and being removed from the target cache queue; and determine a degree of network congestion based on the delay value, the maximum delay value, and the minimum delay value.

[0025] In a possible implementation manner, the network congestion condition parameter is carried in a header field of the first data packet.

[0026] In a possible implementation, the network congestion condition is carried in the IP field of the first data packet.

[0027] In one possible implementation, the first data packet also includes forwarding rate acquisition indication information, and the device also includes a communication module for: acquiring the forwarding rate based on the forwarding rate acquisition indication information; increasing the forwarding rate to the first data packet; and sending the first data packet to the receiving end.

[0028] In one possible implementation, the communication module is also used to: receive a fourth data packet; wherein, the third receiving interval between the first data packet and the fourth data packet is different from the second receiving interval between the first data packet and the third data packet, the third data packet is the previous data packet of the first data packet, the third receiving interval is adjusted by the sending end based on the number of network congestion identifiers and the forwarding rate, the number of network congestion identifiers is obtained by the receiving end based on the statistics of the received data packets and sent to the sending end, and the forwarding rate is sent to the sending end when the receiving end detects that the forwarding rate carried by the first data packet is different from the forwarding rate obtained last time.

[0029] In a possible implementation manner, the forwarding rate acquisition indication information is carried in a header field of the first data packet.

[0030] In a possible implementation manner, the forwarding rate acquisition indication information is carried in the IP field of the first data packet.

[0031] In a third aspect, an embodiment of the present application provides a computer-readable medium for storing a computer program, wherein the computer program includes instructions for executing the method in the first aspect or any possible implementation of the first aspect.

[0032] In a fourth aspect, an embodiment of the present application provides a computer program comprising instructions for executing the method in the first aspect or any possible implementation of the first aspect.

[0033] In a fifth aspect, embodiments of the present application provide a chip comprising a processing circuit and transceiver pins. The transceiver pins and the processing circuit communicate with each other via an internal connection path, and the processing circuit executes the method of the first aspect or any possible implementation of the first aspect to control the receive pin to receive a signal and to control the transmit pin to send a signal.

[0034] In a sixth aspect, an embodiment of the present application provides a communication system, which includes the transmitting end, the communication device and the receiving end involved in the first aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 This is a schematic diagram illustrating an exemplary scenario of a cloud phone service;

[0036] Figure 2 is a schematic diagram of an exemplary tail drop mechanism;

[0037] Figure 3 This is a schematic diagram illustrating an exemplary technology for linking video coding with available network bandwidth;

[0038] Figure 4 is a schematic diagram of an exemplary data packet encapsulation format;

[0039] Figure 5 Schematic diagram of an IP header shown as an example;

[0040] Figure 6 is a schematic diagram of an exemplary service type field;

[0041] Figure 7 This is a schematic diagram of the structure of an option field shown as an example;

[0042] Figure 8 is an exemplary communication system architecture diagram;

[0043] Figure 9 A flow chart of an exemplary communication method;

[0044] Figure 10 is a schematic diagram of an exemplary data structure;

[0045] Figure 11 This is a schematic diagram showing an exemplary network congestion condition parameter determination;

[0046] Figure 12 is a flow chart of an exemplary communication method;

[0047] Figure 13a is a schematic diagram of an exemplary data structure;

[0048] Figure 13b is a schematic diagram of an exemplary data structure;

[0049] Figure 14 A flow chart of an exemplary communication method is shown;

[0050] Figure 15 is a schematic structural diagram of an exemplary communication device;

[0051] Figure 16 A schematic diagram of the structure of a computing device is shown as an example;

[0052] Figure 17 A schematic diagram of the structure of a computing device is shown as an example;

[0053] Figure 18 The figure is a schematic diagram of the structure of a computing device cluster shown as an example. DETAILED DESCRIPTION

[0054] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0055] The term "and / or" in this article is merely a description of the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0056] In the description and claims of the embodiments of this application, the terms "first" and "second" are used to distinguish different objects, rather than to describe a specific order of objects. For example, the terms "first target object" and "second target object" are used to distinguish different objects, rather than to describe a specific order of objects.

[0057] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0058] In the description of the embodiments of this application, unless otherwise specified, "multiple" means two or more. For example, "multiple processing units" means two or more processing units; "multiple systems" means two or more systems.

[0059] First, some key technologies involved in this application are briefly described:

[0060] A public cloud is a cloud platform provided by a third-party public cloud provider to individuals and businesses. In a public cloud, the hardware, software, and other infrastructure are all owned and managed by the third-party public cloud provider.

[0061] The cloud platform, which may also be referred to as a cloud management platform or cloud management platform in the embodiments of the present application, is a software system for cloud technology (also known as cloud computing technology) services provided by a cloud provider, which is used to provide an interface related to cloud services for tenants to remotely access cloud services. Tenants can log in to the cloud platform on the cloud service access page using a pre-registered account and password, and after a successful login, select and purchase the corresponding cloud service on the cloud service access page, such as object storage services, virtual machine services, container services, etc. Exemplarily, the cloud management platform can provide a unified entrance (also known as an operation and maintenance entrance), and users can access the cloud management platform through the unified entrance and manage the cloud resources (including hardware and software) of the corresponding cloud through the cloud management platform.

[0062] Cloud services include computing services, storage services, virtual machine services, network services, etc. Any device or function that a user device can access on the cloud platform can be considered a service provided by the cloud platform.

[0063] Cloud resources are hardware resources (also referred to as cloud infrastructure or infrastructure) and software resources (also referred to as public cloud services) used to provide services. For example, the hardware resources corresponding to software resources such as computing services, storage services or network services include computing resources, storage resources or network resources. Optionally, computing resources include central processing unit (CPU) resources, memory resources and / or hard disk resources. For example, a user (also referred to as a tenant) purchases a large number of virtual machine resources, and a large number of applications (also referred to as cloud applications) are deployed on the virtual machine resources. In this instance, the virtual machine and the applications in the virtual machine all belong to the cloud service (i.e., software resources), and the server and other equipment to which the virtual machine belongs are the corresponding hardware resources.

[0064] Interactive media services generally refer to hardware on cloud infrastructure (such as cloud servers). Based on operating instructions uploaded by client terminals, it performs real-time rendering and video encoding of business-related content, transmits the encoded video stream to the client terminals via the Internet, and finally decodes and displays the video at the client terminals.

[0065] The purpose of this type of cloud service is to offload the computing power required for rendering to the cloud infrastructure. The client terminal only performs video decoding, effectively reducing the hardware requirements of the real-time rendering service for the client terminal and improving the compatibility and promotion of the real-time rendering service.

[0066] Currently, typical cloud services include cloud phones, cloud desktops, and cloud games. These services all have one thing in common: they require low latency for operational interactions.

[0067] Figure 1This is a schematic diagram of a cloud phone service scenario, please refer to Figure 1 In the cloud phone business scenario, the user's mobile phone (i.e., the user's mobile phone in the figure) is installed with an OS (Operating System) (i.e., the mobile phone OS in the figure). At least one APP (Application) is installed on the operating system, including but not limited to: touch, game screen, APP business functions, etc. The touch application is used to send and obtain instructions, and the game screen application is used to receive game screens and decode and render game screens. The touch application responds to the user operations received and uploads the touch instructions triggered by the user to the cloud phone in the cloud through the network.

[0068] Still refer to Figure 1 The cloud phone includes but is not limited to the cloud phone OS, which has APPs and games installed on it. The command application (or command module) in the cloud phone receives the touch command sent by the user's mobile phone. The cloud phone can perform corresponding operations on the cloud phone based on the touch command, and encode the screen displayed after the operation to generate an image frame. The cloud phone sends the image frame to the user's mobile phone through the network. After receiving the image frame, the user's mobile phone decodes and renders the image frame and displays the corresponding image.

[0069] Tail drop mechanism:

[0070] If the amount of data to be forwarded by traditional network devices on the Internet exceeds the device's capacity, the data packets will first queue in the device's cache. If the amount of data cached in the network device's cache is greater than or equal to the cache threshold, the cache is deemed overloaded and the network device discards all data at the end of the cache queue. This is the classic tail drop mechanism of network devices.

[0071] Figure 2 For an exemplary diagram of the tail drop mechanism, please refer to Figure 2 The network device may place the received data packets 1 to n in a cache queue in the order of reception. When the network device detects that the cache is overloaded, at least one data at the tail of the cache queue may be discarded.

[0072] The tail drop mechanism of traditional network equipment currently running on the Internet has two major impacts on interactive media services:

[0073] 1. Packet loss due to the tail drop mechanism of network devices requires data retransmission through another network to successfully send the data to the receiver. Before the receiver receives the retransmitted data, the video may have already played to the frame corresponding to the retransmitted data. Due to data loss, the screen displayed on the receiver will be distorted.

[0074] 2. Before tail drop occurs on a network device, a certain amount of data is accumulated in the device's cache. This data backlog increases data transmission latency. For example, if there is a large backlog of data in the cache queue, new data will wait longer in the queue, increasing data transmission latency and impacting the user experience.

[0075] In interactive media scenarios, when a sender detects that data being transmitted to a network device has been lost, it can determine that this is due to tail drop caused by congestion on a device in the network. In this case, the sender will take appropriate measures to prevent further network congestion for subsequent data transmission.

[0076] Figure 3 For an exemplary diagram of the linkage technology between video coding and network available bandwidth, please refer to Figure 3 Specifically, the video transmission module obtains transmission indicators during the process of transmitting video streams (including receiving video streams sent by the video encoder module and sending video streams to terminal users), such as but not limited to transmission packet loss rate and transmission network delay. The video transmission module feeds back the transmission indicators to the network bandwidth prediction module. The network bandwidth prediction module predicts the available bandwidth in the current network transmission process based on the tail drop mechanism of the network device. In simple terms, after detecting data packet loss, a speed reduction prediction is performed. After no data packet loss is detected for a period of time, a speed increase prediction is performed. Finally, the predicted network available bandwidth is fed back to the video encoder module to guide the video encoding bandwidth.

[0077] The video encoder module obtains the image content, and then encodes it according to the guidance encoding bandwidth feedback from the network bandwidth prediction module, and finally sends the encoded video stream to the end user through the video transmission module.

[0078] TCP / IP protocol:

[0079] The TCP / IP protocol, short for Transmission Control Protocol / Internet Protocol, consists of a five-layer model, including but not limited to the application layer, transport layer, network layer, data link layer, and physical layer. Within the seven-layer model, the application layer can be further divided into the application layer, presentation layer, and session layer. The application layer provides services to applications and specifies the details of communication within them, including protocols such as file transfer, email, and remote login. The transport layer ensures reliable transmission. Data is processed only at the communicating nodes, not at routers. The session layer determines when to establish and disconnect connections, while the transport layer performs the actual establishment and disconnection processing. The network layer transmits data to the destination address. The destination address can be an address on multiple networks connected by routers. Therefore, this layer is primarily responsible for addressing and routing. The data link layer is responsible for interconnecting the physical layer and transmitting communication between nodes. The physical layer is used to transmit bit streams onto the physical medium. TCP / IP uses an encapsulation strategy in its data packet design. Encapsulation means that when an application sends data, each layer adds corresponding header information (or, in other words, encapsulates the previous layer's data with the corresponding header information of the current layer). This information is used to communicate with the receiving end at the same level. In other words, each layer on the receiving end decapsulates the data packet. Figure 4 This is a diagram showing an exemplary data packet encapsulation format. Figure 4 After the application layer obtains the user data, it encapsulates the user data, that is, adds an APP header (also known as an APP control field, an APP header field, which is not limited in this application) to obtain the application data. The TCP layer (i.e., the transport layer) encapsulates the application data, adds a TCP header (also known as a TCP control field, a TCP header field, which is not limited in this application) to obtain a TCP segment. The IP layer (i.e., the network layer) encapsulates the TCP end, adds an IP header (also known as an IP control field, an IP header field, which is not limited in this application) to obtain an IP datagram. The data link layer encapsulates the IP datagram, adds an Ethernet header and an Ethernet tail to obtain an Ethernet frame, which can also be called a data packet, a TCP / IP data packet, etc., which is not limited in this application.

[0080] Figure 5 For an example of an IP header, please refer to Figure 5 , including but not limited to the following fields:

[0081] Version: indicates the version of the IP protocol.

[0082] Header Length: Indicates the length of the header.

[0083] Service type, length is 8 bits. Figure 6 For an example of the service type field, please refer to Figure 6 Optionally, the service type field includes a 6-bit DS (Differentiated Services) field and a 2-bit ECN (Explicit Congestion Notification) field.

[0084] Differentiated Services: This field is 6 bits long and was originally defined as the Type of Service field. It was not actually used, but was redefined by the IETF as Differentiated Services RFC 2474 in 1998. This field is effective only when Differentiated Services is used and is not used in general.

[0085] Explicit Congestion Notification: Length is 2 bits. ECN(00), that is, the ECN value is 00, indicating that the packet does not support ECN. Accordingly, the network device can process the packet carrying ECN(00) according to the original processing flow, that is, overload packet loss. ECN(01), that is, the ECN value is 01, ECN(10), that is, the ECN value is 10, and ECN(11), that is, the ECN value is 11, are all used to indicate that the datagram supports ECN. Among them, if congestion occurs, ECN is set to 11.

[0086] Still refer to Figure 5 , the IP header also includes:

[0087] Total length: The sum of the header and data, in bytes. When the total length of a datagram exceeds the maximum transmission unit of the data link layer, fragmentation is necessary. An IP datagram is divided into multiple fragments, each of which has an IP header.

[0088] Identification: Identify the fragments. Fragments of the same datagram have the same identification.

[0089] Flags: 3 bits in length. The least significant bit is MF (More Fragment). MF = 1 indicates "more fragments" are coming, while MF = 0 indicates this is the last of multiple datagram fragments. The middle bit is DF (Don't Fragment). Fragmentation is allowed only when DF = 0.

[0090] Fragment offset: indicates the relative position of the fragment in the original packet. The fragment offset is in units of 8 bytes.

[0091] Lifetime: Indicates the number of times the datagram can be forwarded in the network. The value decreases by 1 each time it is forwarded.

[0092] Header checksum: This field only checks the header of the datagram, not the data part.

[0093] Source address: used to carry the source address.

[0094] Destination address: used to carry the destination address.

[0095] Options: The length of this field can be set according to actual needs. Figure 7 For an example of the structure of the option field, please refer to Figure 7 , including but not limited to the following fields:

[0096] Type: 8 bits in length, used to indicate the specific type of the Option.

[0097] Optionally, the type field includes but is not limited to:

[0098] Copy: Set to 1 when this option needs to be backed up to all shards.

[0099] Class: General option category, the value "0" is used to indicate "Control", the value "2" is used to indicate "Error Detection and Measures", and 1 and 3 are reserved.

[0100] Number: Used to indicate an option. Currently supported options include: Loose source routing, Strict source routing, Record route, and Timestamps.

[0101] In an embodiment of the present application, Class=2 and Number=01101 are used to indicate that the data field carries network congestion condition parameters. Class=2 and Number=01111 can be called forwarding rate acquisition indication information, which is used to indicate the feedback forwarding rate. The above two indication methods in the embodiment of the present application are only illustrative examples and can be set according to actual needs. For example, Class=1 or 3 and Number=01101 are used to indicate that the data field carries network congestion condition parameters, and this application does not limit them. It should be noted that the indication method is the agreed result of each device in the system, that is, each device can determine the corresponding indication content based on the above numerical values. For example, the option field of the IP field of the data packet sent by the sender includes Class=2 and Number=01101. Accordingly, when the network device receives the data packet and reads the IP field, it can determine that the data field in the option field includes network congestion condition parameters based on Class=2 and Number=01101 in the option field.

[0102] Length: 8 bits, used to indicate the length of the entire option field.

[0103] Data (Value): The length is the length specified by Length, and carries the specific content related to the option.

[0104] The communication method in the embodiment of the present application is described in detail below:

[0105] Figure 8 For an exemplary communication system architecture diagram, please refer to Figure 8 , specifically including but not limited to: a sending end (also called a server end), a network device (also called a forwarding device or an intermediate device, etc.) and a receiving end (also called a client, etc.).

[0106] In an embodiment of the present application, the system may include one or more transmitting terminals. The service types run by each transmitting terminal may be the same or different. For example, some transmitting terminals may run interactive media services, while other transmitting terminals may run non-interactive media services. Among them, the specific services run by the transmitting terminals running interactive media services may also be different. For example, transmitting terminal 1 may run a cloud mobile phone service, while transmitting terminal 2 may run a cloud gaming service, etc. This application does not limit this.

[0107] In the embodiment of the present application, the sending end can be a cloud server in a cloud system or a server in a non-cloud scenario, and this application does not limit it.

[0108] Exemplarily, the system may include one or more network devices. The network devices involved in the embodiments of the present application are all network devices that support the communication method in the present application. The network device may be a router or other device. Optionally, the communication link between the sending end and the receiving end may include multiple network devices, which may also be referred to as intermediate nodes. In the embodiments of the present application, the network device that executes the method in the embodiments of the present application may optionally be the network device closest to the receiving end, which may also be referred to as a user-side network device, such as a router in the user's home.

[0109] Exemplarily, the system may include one or more receiving terminals, which may be mobile stations, subscriber units, stations, terminal equipment (TE), etc. The terminal may be a cellular phone, a personal digital assistant (PDA), a wireless modem, a handheld device, a laptop computer, a cordless phone, a wireless local loop (WLL) station, a tablet computer, etc. With the development of wireless communication technology, devices that can access a communication system, communicate with the network side of a communication system, or communicate with other objects through a communication system can be terminals in the embodiments of the present application, such as terminals and cars in intelligent transportation, household appliances in smart homes, power meter reading instruments, voltage monitoring instruments, environmental monitoring instruments in smart grids, video surveillance instruments in intelligent security networks, cash registers, etc. In the embodiments of the present application, a terminal can communicate with a network device, multiple terminals can communicate with each other, and a terminal can be static or mobile.

[0110] The above-mentioned communication system can be used to support fourth generation (4G) access technology, such as long term evolution (LTE) access technology; alternatively, the communication system can also support fifth generation (5G) access technology, such as new radio (NR) access technology.

[0111] Exemplarily, the network device and the receiving end may be connected by a wired connection or a wireless connection (such as a Wi-Fi connection). The specific communication method can be set according to actual needs and is not limited in this application.

[0112] Still refer to Figure 8 For example, the transmitting end is used to respond to the reception statistics fed back by the receiving end, dynamically adjust the encoding rate and / or data transmission rate of the transmitting end, so as to adjust the data reception rate on the network device side. In addition, the transmitting end encodes data of the corresponding rate (also referred to as user data). And, the encoded data is encapsulated (the encapsulation process and structure can be referred to in Figure 4 ), generates a data packet, and sends the data packet according to the determined data sending rate.

[0113] Exemplarily, a network device is used to receive a data packet (also referred to as a data message) whose destination address is the network device. The control field of the data packet (or may be referred to as a header field or a head field, etc., which is not limited in this application and will not be repeated in the following text) is read to obtain a network congestion condition parameter. Based on the network congestion condition parameter, it is determined whether congestion occurs and the degree of network congestion corresponding to the congestion. Based on the degree of network congestion, the number of data packets that need to be marked with ECN (11) is determined. It should be noted that this application only uses ECN (11) to indicate network congestion as an example for explanation, which is not limited in this application. And, receiving a data packet and decapsulating the data packet. Exemplarily, the network device is also used to mark ECN (11) when recapsulating a data packet. And, when the control field of the read data packet includes forwarding rate acquisition indication information (for example, Class = 2 and Number = 01111, which is only an illustrative example and can be set according to actual needs, which is not limited in this application and will not be repeated in the following text), the forwarding rate of the device is obtained, and the forwarding rate is increased in the control field during the recapturing process. Exemplarily, if the amount of data that needs to be processed by the network device exceeds the processing capacity of the network device (a processing capacity upper limit is preset), the network device determines that congestion has occurred. The network device is further configured to send the re-encapsulated data packet to the receiving end.

[0114] Exemplarily, the receiving end includes a device for receiving a data packet whose destination address is the receiving end, performing decapsulation and other processing on the data packet, and obtaining the data in the data packet. Also, in reading the control field in the data packet, if the network congestion condition parameter and / or forwarding rate is read, the network congestion condition parameter and / or forwarding rate is recorded. The statistical data information collected is fed back to the sending end according to a predetermined period (for example, 100ms or 200ms, which can be set according to actual needs and is not limited in this application) or a preset trigger condition. The statistical data information includes, but is not limited to: the number of network congestion identifiers, and / or the forwarding rate. Among them, the forwarding rate is sent after the receiving end detects a change in the forwarding rate.

[0115] Combine Figure 8 , the communication method in the embodiment of the present application is described in detail below. Figure 9 For a flow chart showing an exemplary communication method, please refer to Figure 9 , specifically including but not limited to the following steps:

[0116] S901: The sending end determines an encoding method based on data statistical information and generates a data packet.

[0117] In this embodiment of the present application, the transmitting end may obtain data statistical information fed back by the receiving end (for a specific process, see S908 below). In this embodiment of the present application, the data statistical information includes, but is not limited to, the number of network congestion indicators and / or the forwarding rate (for a method in which the receiving end obtains the data statistical information, see S907 below).

[0118] The transmitting end may determine (or estimate) the degree of network congestion on the network device side based on the data statistical information, and determine whether the current encoding method needs to be adjusted based on the degree of network congestion on the network device side.

[0119] For example, after adjusting the encoding method, the data transmission rate is also adjusted. It can be understood that the sender adjusts the data transmission rate by adjusting the encoding method based on data statistical information, thereby achieving the purpose of adjusting the data packet reception rate on the network device side.

[0120] The sender encodes the data according to the adjusted encoding method (or not adjusted), and generates a data packet based on the encoded data. The method of generating the data packet can refer to Figure 4 , I will not go into details here.

[0121] Exemplarily, the control field of the data packet generated by the sender includes network congestion condition parameters and / or forwarding rate acquisition indication information. In an embodiment of the present application, the network congestion condition parameters and / or forwarding rate acquisition indication information can be carried in the IP field or in the TCP field. In the embodiment of the present application, only the option field in which the parameters are carried in the IP field is used as an example for explanation. The processing method carried in the TCP field (or the option field in the TCP field) is similar to that of the IP field, and this application will no longer give examples one by one.

[0122] In this example, the control field includes the network congestion condition parameter as an example for explanation. For the scenario where the control field includes the forwarding rate acquisition indication information, please refer to the description in the following embodiment.

[0123] In an embodiment of the present application, the network congestion condition parameter is used to indicate the delay range of the network device acceptable to the sending end. Optionally, the network congestion condition parameter includes but is not limited to: the maximum delay (denoted as t_max) and the minimum delay (denoted as t_min), which are used to indicate the minimum delay and maximum delay of the network device acceptable to the sending end.

[0124] Exemplarily, the transmitting end may set network congestion condition parameters in response to received user operations. In an embodiment of the present application, the network congestion condition parameters are set based on the service type of the transmitting end. As mentioned above, some interactive media services have strict requirements on latency, such as cloud phones, cloud games, etc. For the transmitting end running such services, the network congestion condition parameters set therefor are relatively small, for example, t_min and t_max need to be set to 20ms and 50ms. For some interactive media services with lower latency requirements, the network congestion condition parameters set therefor can be larger (compared to services with higher latency requirements), for example, t_min and t_max can be set to 100ms and 300ms. The numerical values ​​in this application are all illustrative examples and are not limited to these.

[0125] Interactive media services can further include services that prioritize clarity (such as video conferencing) and services that prioritize fluency (such as interactive games). Among them, if the t_min and t_max values ​​are large, more data can be temporarily accumulated in the network device cache. In this way, at the moment when the network communication status improves, more data packets can be sent out quickly in the network device, which can increase the amount of service data that can be forwarded to a certain extent. Therefore, for interactive media services that can tolerate a certain delay, you can try to increase t_min and t_max to obtain a higher network transmission rate, thereby bringing better video clarity. For interactive media services that have higher delay requirements, it is necessary to set lower t_min and t_max values. Even if the video clarity is compromised, priority is given to ensuring a lower operation interaction delay.

[0126] As described above, a system can contain multiple senders, each of which can operate the same or different service types. Accordingly, the network congestion condition parameters carried in the data packets sent by each sender can be set based on the service type of the device, thereby achieving the purpose of adjusting the network congestion parameters according to different needs. This allows the network device to estimate the corresponding network congestion level based on the network congestion parameters corresponding to different senders, thereby achieving dynamic adjustment of the network congestion condition parameters on the network device side.

[0127] In the embodiment of the present application, the network congestion condition parameter is carried in the option field of the IP field as an example. Figure 10 For an exemplary data structure diagram, please refer to Figure 10In this embodiment of the present application, the value in the Copy field of the IP field is 1, the value in the Class field is 2, the value in the Number field is 0b01101 (other values ​​are possible and are not limited by this application), the value in the Length field is 5, and the Value field occupies 24 bits. Among them, t_min (which can represent 2 to the power of 12, 0 to 4095ms) occupies 12 bits, and t_max (which can represent 2 to the power of 12, 0 to 4095ms) occupies 12 bits.

[0128] In the embodiment of the present application, for the sender of interactive media services or other types of services with high latency requirements, the messages (i.e., data packets) sent by them can implement the steps performed by the sender in the embodiment of the present application. In this scenario, the ECN identifier in the data packet sent by this type of sender is 01, i.e., ECN (01), which is used to indicate that ECN is supported. For the sender of other types of services, the ECN in the data packet can be identified as 00, which is used to indicate that ECN is not supported. Accordingly, the network device processes the data of this type of sender according to the traditional process. For example, when the cache is overloaded (i.e., network congestion occurs), the tail drop mechanism described above is executed.

[0129] In one possible implementation, the sender may include network congestion condition parameters in each service data packet sent. Optionally, the sender may also send network congestion condition parameters at a preset period (e.g., 50ms, which may be set based on actual needs and is not limited by this application). This period may be set based on actual needs and is not limited by this application.

[0130] S902: The sending end sends a data packet to the network device.

[0131] For example, the sending end sends the encapsulated data packet to the network device via the network. The specific transmission method can refer to the existing technology and will not be described in detail in this application.

[0132] S903: The network device places the data packet in a designated queue.

[0133] In the embodiment of the present application, a corresponding cache queue is stored in the network device for each sender communicating with the network device. The network device receives a data packet and places the data packet in the cache queue corresponding to the sender based on the address information carried in the data packet.

[0134] In an embodiment of the present application, the network device may optionally be provided with two types of cache queues. One is a low-latency cache queue, and the other is a non-low-latency cache queue. The length of the low-latency cache queue is less than the length of the non-low-latency cache queue. For example, the length of the low-latency cache queue may be one-third of the length of the non-low-latency cache queue (this is for illustrative purposes only and may be set according to actual needs, and is not limited by this application).

[0135] For example, the low-latency buffer queue can be used to buffer data packets of services with low latency requirements, such as interactive media services, while the non-low-latency queue can be used to buffer other types of data packets.

[0136] In an embodiment of the present application, as described above, the control field of the data packet sent by the sender running an interactive media service or other low-latency service includes ECN (01). The network device receives the data packet, decapsulates the data packet, reads the IP field, and detects ECN (01), then the queue allocated by the network device to the sender is a low-latency cache queue. For example, the network device receives a data packet sent by sender A and detects ECN (01). The network device determines that the sender corresponding to the data packet is a low-latency demand sender, that is, the service of the sender is a low-latency service (for example, an interactive media service). The network device allocates cache queue A to the sender, and the type of the cache queue is a low-latency cache queue. Accordingly, before the network device disconnects from the sender, the network device places the data packet in the cache queue A each time it receives a data packet from the sender.

[0137] Optionally, if it is another data packet that does not carry ECN (01), the network device places it in a cache queue of a non-low-latency cache queue type corresponding to the sender.

[0138] Exemplarily, after the network device reads the ECN (01) identifier carried in the data packet, it further reads the value in the option field. In one example, if a predetermined value is read, such as the value in the Copy field is 1, the value in the Class field is 2, the value in the Number field is 0b01101 (it can also be other values, not limited in this application), and the value in the Length field is 5, it is determined that the Value field in the option field carries the network congestion condition parameter. The network device can obtain the network congestion condition parameter, such as the t_min (minimum delay) and t_max (maximum delay) values.

[0139] Exemplarily, the network device obtains and saves network congestion condition parameters, and records the correspondence between the network congestion condition parameters, the sender, and the cache queue corresponding to the sender, so that in the subsequent process, the network congestion condition parameters from the sender are applied to the cache queue corresponding to the sender, that is, applied to the data packets from the sender.

[0140] S904: The network device determines the degree of network congestion based on the network congestion condition parameter.

[0141] For example, after the network device obtains the network congestion condition parameters and places the data packet in the cache queue corresponding to the sender, the network device can apply the network congestion condition parameters corresponding to the sender to the cache queue of the sender. As described above, there can be multiple senders in the system, each of which corresponds to a different cache queue, and the corresponding network congestion condition parameters can be the same or different. In the embodiments of this application, only the scenario of the network congestion condition parameters of a single sender is used as an example for explanation. The processing of other senders is the same, and this application will not further illustrate them one by one.

[0142] Optionally, as described above, the sender may include the network congestion condition parameter in each data packet, or may periodically send the network congestion condition parameter. Accordingly, the network device may execute S904 based on the most recently acquired network congestion condition parameter from the sender.

[0143] Exemplarily, the network device determines the degree of network congestion based on the network congestion condition parameters. Specifically, the network device obtains the delay of the currently received data packet (hereinafter referred to as the first data packet), which can also be called the sending delay or the queuing delay, etc., and is used to indicate the queuing time of the first data packet in the cache queue, which can also be understood as the time between the moment the first data packet is placed in the cache queue and the moment the first data packet is sent out. The network device determines the network congestion degree of the corresponding cache queue based on the queuing delay of the first data packet and the network congestion condition parameters, which can also be understood as the network congestion degree corresponding to the data forwarding of the sending end.

[0144] Figure 11 For an example diagram showing the parameters for judging network congestion conditions, please refer to Figure 11 In one example, when the queuing delay t is less than or equal to t_min, the network congestion level can be determined to be 0, that is, no network congestion occurs. In another example, when the queuing delay t is greater than or equal to t_max, the network congestion level is determined to be 1 (i.e., 100%), that is, severe congestion occurs. In another example, if the queuing delay t is greater than t_min and less than t_max, the network device can determine that slight network congestion occurs. The network device determines the network congestion level p based on the following formula:

[0145]

[0146] Exemplarily, each time the network device receives a data packet carrying ECN (01) from the sender, it executes S904 and subsequent processing.

[0147] S905: The network device determines whether to add a network congestion indicator to the data packet based on the degree of network congestion.

[0148] Exemplarily, the network device may determine the number of data packets that need to carry a network congestion identifier based on the degree of network congestion. In one example, if the congestion degree of the network device is zero, that is, no network congestion occurs. In this example. The number of data packets that need to carry a network congestion identifier is 0. In another example, if the network congestion degree of the network device is 1 (i.e., 100%), it can also be understood as severe congestion. In this example. The network device determines that the proportion of data packets that need to carry a network congestion identifier is 100%, that is, starting from the currently received data packet (e.g., the first data packet), all subsequently received data packets will have a network congestion identifier added. In another example, if the network congestion degree is greater than 0 and less than 1 (i.e., 100%), the network device determines the percentage of data packets that need to have a network congestion identifier added based on the percentage corresponding to the network congestion degree.

[0149] Exemplarily, the network device may determine whether to add a network congestion identifier, i.e., ECN (11), to the current data packet based on the percentage of data packets that need to add a network congestion identifier after determination. For example, if the percentage corresponding to the network congestion level is 10%, the percentage of data packets that need to add a network congestion identifier is 10%, that is, the network device starts with the currently received data packet (i.e., the first data packet), and adds a network congestion identifier to one data packet out of every 10 data packets. The network device determines that the network congestion identifier needs to be added to the first data packet. The network device receives the second data packet from the sender and executes the above steps, i.e., places the second data packet in the cache queue, and after obtaining the network congestion level, determines that the network congestion level has not changed, i.e., it still processes according to the most recent result, i.e., the number of data packets that have added a network congestion identifier is 10%. Since the first data packet has already added a network congestion identifier, the network device determines that the second data packet does not need to add a network congestion identifier. The network device repeats the above process for the subsequently received data packets. When the eleventh data packet is received, based on the number of data packets that have added a network congestion identifier being 10%, it determines that the eleventh data packet needs to add a network congestion identifier.

[0150] Optionally, the network device may update the percentage of data packets that need to increase the network congestion flag in real time based on the real-time changes in the network congestion level, and determine whether the network congestion flag needs to be increased for the currently received data packets based on the updated percentage.

[0151] S906: The network device sends a data packet to the receiving end.

[0152] Exemplarily, after the network device determines that a network congestion flag needs to be added to a currently received data packet (e.g., a first data packet), the network device sequentially sends the data packets in the cache queue. When sending the first data packet, during the process of re-encapsulating the first data packet, the network congestion flag is added to the first data packet, i.e., the ECN flag is set to 11, to indicate that network congestion has occurred on the network device. The network device then sends the re-encapsulated data packet to the receiving end.

[0153] S907, receiving end statistics information.

[0154] For example, as described above, when network congestion occurs on a network device, the network device can mark a specified number of data packets as congestion based on the degree of network congestion. The ratio of the number of marked data packets to the total number of data packets sent can be used to indicate the degree of network congestion. Accordingly, after receiving the data packet, the receiving end decapsulates the data packet and processes the data packet to obtain the data carried by the data packet. Furthermore, the control field of the obtained data packet includes ECN (11), thereby determining that the network device is congested.

[0155] The receiving end periodically counts the number of received data packets and the number of data packets carrying a congestion indicator (ECN(11)). Specifically, each time the network device receives a data packet, it counts the total number of received data packets. Furthermore, each time the network device receives a data packet carrying a network congestion indicator, it also counts the network congestion indicator.

[0156] Optionally, the network device may also start counting the number of received data packets carrying the network congestion indicator from the time the data packet carrying the congestion indicator is received, so as to reduce the load of the network device.

[0157] S908: The receiving end feeds back data statistical information to the sending end.

[0158] Exemplarily, the receiving end can set a feedback period, such as 100ms or 200ms, or other durations, which can be set according to actual needs and are not limited in this application. The receiving end can periodically feedback data statistical information (also referred to as reception statistical information, which is not limited in this application) to the sending end. The data statistical information includes but is not limited to the number of network congestion identifiers counted during this period, and can also be the total number of received data packets and the number of data packets carrying network congestion identifiers counted during this period.

[0159] Exemplarily, the receiving end may send data statistical information to the sending end through network devices and other devices. The specific data transmission process may refer to existing technologies and will not be described in detail here.

[0160] Exemplarily, the sending end receives data statistical information from the receiving end. Based on the total number of data packets received by the receiving end and the number of data packets carrying the network congestion indicator in the data statistical information, and the total number of data packets sent in the current cycle (the total number of data packets received by the receiving end may be less than or equal to the total number of data packets sent by the sending end to the receiving end), the sending end calculates the proportion of data packets marked with the network congestion indicator (i.e., ECN(11)) by the network device in the current cycle. However, due to network packet loss and other reasons, the proportion of data packets with the network congestion indicator obtained by the sending end may differ from the proportion of data packets with the network congestion indicator of the network device (the difference is usually small), which is not limited in this application.

[0161] For example, as described in S901 above, the sending end can estimate the degree of network congestion on the network device side based on the proportion of data packets marked with a network congestion mark (i.e., ECN (11)) by the network device. The sending end can adjust the encoding method of the local end based on the degree of network congestion. For example, if the ratio obtained by statistics is greater than the ratio preset by the business, the video encoding bit rate is reduced (the reduction range can be set according to actual needs and is not limited in this application), and the data transmission rate is reduced at the same time. If the ratio obtained by statistics is less than the ratio preset by the business, the sending end increases the video encoding bit rate and increases the data transmission rate at the same time.

[0162] Optionally, the transmitting end can also set the corresponding encoding bit rate based on different levels of network congestion. A higher level of network congestion corresponds to a lower encoding bit rate, while a lower level of network congestion corresponds to a higher encoding bit rate. The specific gear ratio and corresponding relationship can be set according to actual needs and are not predetermined by this application.

[0163] Figure 12 This is a flow chart of an exemplary communication method. In this scenario, the scenario of adjusting the network congestion of the network device based on the forwarding rate is described in detail. Please refer to Figure 12 , specifically including but not limited to the following steps:

[0164] S1201: The sending end determines an encoding method based on data statistical information and generates a data packet.

[0165] For example, in this scenario, the data statistics include the forwarding rate of the network device side. The forwarding rate sets the forwarding rate of the network device side for the data packets of the sender, which can also be understood as the forwarding rate of the cache queue corresponding to the sender.

[0166] For example, the transmitting end can predict (or estimate) the network congestion situation on the network device side based on the forwarding rate of the network device. In the embodiment of the present application, the transmitting end can set different network congestion levels corresponding to different forwarding rates, which can be set according to actual needs and is not limited by this application.

[0167] In an embodiment of the present application, the receiving end feeds back the forwarding rate to the receiving end when the forwarding rate of the network device changes (see below for a specific solution). That is, once the forwarding rate on the network device side increases or decreases, the sending end can obtain the change in the forwarding rate of the network device based on the feedback from the receiving end. For example, the sending end can predict whether the network device will experience network congestion and the degree of network congestion based on the change in the forwarding rate of the network device and the actual forwarding rate value. For example, if the forwarding rate obtained by the sending end is forwarding rate A, its value is less than the forwarding rate B obtained last time. The sending end can determine that the forwarding rate of the network device has decreased. If forwarding rate A is greater than or equal to a preset value (which can be set according to actual needs), the sending end may not take any action. If the sending end obtains forwarding rate C again, its value is less than forwarding rate A, the sending end can determine that the forwarding rate on the network device side has continued to decrease, and can predict that the network device may experience network congestion. If forwarding rate C is less than or less than the preset value, it can be determined that the network device may experience slight congestion, and the sending end can reduce the encoding rate. The extent of the reduction can be set according to actual needs and is not limited in this application. For another example, when the sending end has determined that network congestion has occurred on the network device side and is encoding at a lower coding rate, if the forwarding rate obtained by the sending end is forwarding rate A, its value is greater than the forwarding rate B obtained last time. The sending end can determine that the forwarding rate of the network device has increased. If the forwarding rate A is less than or equal to the preset value (which can be set according to actual needs), the sending end may not process it. The sending end obtains the forwarding rate C again, and its value is greater than the forwarding rate A. The sending end can determine that the forwarding rate on the network device side continues to increase, and can predict that the network congestion level of the network device has decreased. The sending end can increase the coding rate.

[0168] Exemplarily, the transmitting end generates a data packet based on the current encoding mode. In this example, the data packet includes forwarding rate acquisition indication information. Optionally, each data packet sent by the transmitting end may include forwarding rate acquisition indication information, or the transmitting end may periodically generate data packets carrying forwarding rate acquisition indication information, which is not limited in this application.

[0169] In an embodiment of the present application, the forwarding rate acquisition indication information is used to indicate the acquisition of the network device side's forwarding rate for the data packets of the sender, and can also be understood as being used to indicate the network device side's feedback of the forwarding rate for the data packets of the sender.

[0170] For example, the forwarding rate acquisition indication information is carried in the option field of the IP field. Figure 13a For an exemplary data structure diagram, please refer to Figure 13a In an embodiment of the present application, the forwarding rate acquisition indication information includes: the value in the Copy field of the IP field is 1, the value of the Class field is 2, the value of the Number field is 0b01111 (it can also be other values, which is not limited in this application), the value of the Length field is 4, and the Value field occupies 16 bits, among which the Value field can be filled with 0 or other meaningless values, which can be set according to actual needs, which is not limited in this application.

[0171] S1202: The sending end sends a data packet to the network device.

[0172] The description can be referred to S902 and will not be repeated here.

[0173] S1203: The network device places the data packet in a designated queue.

[0174] The description can be referred to S903 and will not be repeated here.

[0175] S1204: The network device obtains instruction information based on the forwarding rate and re-encapsulates the data packet.

[0176] Exemplarily, after the network device reads the ECN (01) identifier carried in the data packet, it further reads the value in the option field. In one example, if an agreed value is read, such as the value in the Copy field is 1, the value in the Copy field is 1, the value in the Class field is 2, the value in the Number field is 0b01111 (it may also be other values, which are not limited in this application), the value in the Length field is 4, and the value in the Value field is 0 (or other negotiated default values), the network device determines that the data packet carries forwarding rate acquisition indication information.

[0177] The network device obtains the forwarding rate of the cache queue based on the forwarding rate indication information, which can also be understood as obtaining the forwarding rate of the data packet corresponding to the sender. It can be understood that the forwarding rates of different senders in the system on the network device side can be the same or different, and this application does not limit this.

[0178] Exemplarily, the network device re-encapsulates the data packet based on the acquired forwarding rate. Figure 13b For an exemplary data structure diagram, please refer to Figure 13bIn the option field of the IP field of the re-encapsulated data packet, the value in the Copy field is 1, the value in the Copy field is 1, the value in the Class field is 2, the value in the Number field is 0b01111 (it can also be other values, which are not limited in this application), the value in the Length field is 4, and the value in the Value field is the forwarding rate obtained on the network device side.

[0179] S1205: The network device sends a data packet to the receiving end.

[0180] Exemplarily, the network device sends the data packets in the buffer queue to the receiving end.

[0181] S1206, the receiving end collects statistical information.

[0182] Exemplarily, the receiving end receives a data packet, decapsulates the data packet, and obtains the data carried by the data packet. Furthermore, the receiving end obtains the data packet based on the ECN (01) identifier, further reads the option field, and based on the values ​​in the option field (the value in the Copy field is 1, the value in the Copy field is 1, the value in the Class field is 2, the value in the Number field is 0b01111 (it can also be other values, not limited in this application), and the value in the Length field is 4), determines that the forwarding rate carried in the Value field is the forwarding rate on the network device side. The receiving end obtains the forwarding rate.

[0183] S1207: The receiving end feeds back data statistics information to the sending end.

[0184] Exemplarily, the receiving end counts the forwarding rate obtained each time. After detecting a change in the forwarding rate, data statistical information is sent to the sending end. The data statistical information includes the most recently received forwarding rate, and the step proceeds to S1201, that is, the sending end receives the data statistical information, and based on the forwarding rate in the data statistical information, estimates the degree of network congestion on the network device side, and adjusts the encoding method based on the network congestion level to increase or decrease the data receiving rate on the network device side. This can achieve that before network congestion may occur on the network device, congestion on the network device side can be avoided to a certain extent by adjusting the encoding method (or it can be understood as the data sending rate).

[0185] In one possible implementation, the receiving end may periodically (eg, 100 ms, which may be set according to actual needs and is not limited in this application) feed back data statistical information (including but not limited to forwarding rate) to the sending end.

[0186] In one possible implementation, after the sender determines that a network device is congested based on the forwarding rate, if, based on the acquired forwarding rate, it is determined that the forwarding rate on the network device side is still decreasing, i.e., the congestion level on the network device side is increasing, the sender can increase the reduction in the coding rate to quickly alleviate the congestion level on the network device side. Furthermore, after the sender detects that the forwarding rate on the network device side begins to increase, it can determine that the congestion level on the network device side has been alleviated to a certain extent. The sender can adjust the coding rate based on the degree of network congestion alleviation (i.e., the increase in the forwarding rate), thereby alleviating the network congestion level on the network device side while ensuring the data transmission quality (i.e., the coding rate).

[0187] In the embodiments of this application, Figure 9 and Figure 12 The schemes can be used in combination, that is, the network device can indicate the degree of network congestion on the network device side to the sender through the number of network congestion identifiers and the forwarding rate. The sender can adjust the encoding method, that is, the data sending rate, based on the number of network congestion identifiers and the forwarding rate, to increase or decrease the data receiving rate on the network device side and alleviate the degree of network congestion on the network device side.

[0188] Figure 14 For an exemplary communication method flow chart, please refer to Figure 14 , specifically including but not limited to the following steps:

[0189] S1401: The sending end determines an encoding method based on data statistical information and generates a data packet.

[0190] Exemplarily, the transmitting end receives data statistical information sent by the receiving end. The data statistical information includes, but is not limited to, the number of network congestion indicators and the forwarding rate. The number of network congestion indicators includes, but is not limited to, the total number of data packets received by the receiving end and the number of data packets carrying the congestion indicator.

[0191] The sender can adjust the encoding method based on the data statistical information and generate a data packet. The option field of the IP field of the generated data packet includes but is not limited to: forwarding rate acquisition indication information and network congestion condition parameters.

[0192] Other descriptions can refer to Figure 9 and Figure 12 The relevant description will not be repeated here.

[0193] S1402: The sending end sends a data packet to the network device.

[0194] For detailed description, please refer to Figure 9 , I will not go into details here.

[0195] S1403: The network device places the data packet in a designated queue.

[0196] For detailed description, please refer to Figure 9 , I will not go into details here.

[0197] S1404: The network device determines the degree of network congestion based on the network congestion condition parameter.

[0198] For detailed description, please refer to Figure 9 , I will not go into details here.

[0199] S1405: The network device determines whether to add a network congestion indicator to the data packet based on the degree of network congestion.

[0200] For detailed description, please refer to Figure 9 , I will not go into details here.

[0201] S1406: The network device obtains instruction information based on the forwarding rate and re-encapsulates the data packet.

[0202] Exemplarily, the option field of the IP field of at least one data packet re-encapsulated by the network device includes but is not limited to: forwarding rate and / or network congestion indicator (e.g., ECN (11)).

[0203] S1407: The network device sends a data packet to the receiving end.

[0204] For detailed description, please refer to Figure 9 , I will not go into details here.

[0205] S1408, receiving end statistics statistical information.

[0206] For example, the receiving end counts the total number of received data packets and the number of data packets carrying a network congestion indicator, and also counts the forwarding rate and detects whether the forwarding rate changes.

[0207] S1409: The receiving end feeds back data statistics information to the sending end.

[0208] For example, the receiving end may periodically send data statistics to the sending end, where the data statistics include the number of network congestion indicators and the forwarding rate. Furthermore, after detecting a change in the forwarding rate, the receiving end may send data statistics to the sending end, where the data statistics include the changed forwarding rate (i.e., the forwarding rate most recently received by the receiving end).

[0209] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the interaction between various network elements. It can be understood that in order to realize the above functions, the communication device includes a hardware structure and / or software module corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the embodiments of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software-driven hardware manner depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0210] In the embodiment of the present application, the functional modules of the communication device can be divided according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. In actual implementation, there may be other division methods.

[0211] In the case of dividing each functional module into corresponding functional modules, Figure 15 A possible structural diagram of the communication device 1500 involved in the above embodiment is shown. Figure 15 As shown, the communication device may include: an acquisition module 1501, used to obtain network congestion condition parameters in response to a first data packet sent by a sending end; a determination module 1502, used to determine the degree of network congestion based on the network congestion condition parameters; and a marking module 1503, used to add a network congestion identifier to at least one data packet from the sending end according to the obtained network congestion degree.

[0212] In one possible implementation, the device also includes: a communication module 1504, used to forward a data packet from a sending end to a receiving end; a communication module, further used to receive a second data packet; wherein, a first receiving interval between the first data packet and the second data packet is different from a second receiving interval between the first data packet and the third data packet, the third data packet is the previous data packet of the first data packet, the first receiving interval is adjusted by the sending end based on the number of network congestion identifiers, and the number of network congestion identifiers is obtained by the receiving end based on statistics of received data packets and sent to the sending end.

[0213] In a possible implementation, the network congestion condition parameters include a maximum delay and a minimum delay.

[0214] In a possible implementation, the maximum delay value and the minimum delay value are set by the transmitting end based on the service type.

[0215] In one possible implementation, the determination module is specifically used to: place a first data packet in a target cache queue; obtain a delay value corresponding to the first data packet in the target cache queue, where the delay value is used to indicate the duration between the first data packet being placed in the target cache queue and being removed from the target cache queue; and determine a degree of network congestion based on the delay value, the maximum delay value, and the minimum delay value.

[0216] In a possible implementation, the network congestion condition parameter is carried in a header field of the first data packet.

[0217] In a possible implementation, the network congestion condition is carried in the IP field of the first data packet.

[0218] In one possible implementation, the first data packet also includes forwarding rate acquisition indication information, and the device also includes a communication module for: acquiring the forwarding rate based on the forwarding rate acquisition indication information; increasing the forwarding rate to the first data packet; and sending the first data packet to the receiving end.

[0219] In one possible implementation, the communication module is also used to: receive a fourth data packet; wherein, the third receiving interval between the first data packet and the fourth data packet is different from the second receiving interval between the first data packet and the third data packet, the third data packet is the previous data packet of the first data packet, the third receiving interval is adjusted by the sending end based on the number of network congestion identifiers and the forwarding rate, the number of network congestion identifiers is obtained by the receiving end based on the statistics of the received data packets and sent to the sending end, and the forwarding rate is sent to the sending end when the receiving end detects that the forwarding rate carried by the first data packet is different from the forwarding rate obtained last time.

[0220] In a possible implementation manner, the forwarding rate acquisition indication information is carried in a header field of the first data packet.

[0221] In a possible implementation manner, the forwarding rate acquisition indication information is carried in the IP field of the first data packet.

[0222] Among them, the above modules can all be implemented by software, or by hardware. Among them, the module is an example of a software functional unit, and the above module may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the above computing instance may be one or more. For example, the detection task sending module may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region (region) or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Among them, usually a region may include multiple AZs.

[0223] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0224] As an example of a hardware functional unit, a module may include at least one computing device, such as a server. Alternatively, the module may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0225] The multiple computing devices included in the above modules can be distributed in the same region or in different regions. The multiple computing devices included in the above modules can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the above modules can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0226] It should be noted that, in other embodiments, the above modules can be used to execute Figure 9 、 Figure 12 or Figure 14 Follow the corresponding steps in to realize all the functions of the cloud management platform.

[0227] The present application also provides a computing device 1600. Figure 16 As shown, computing device 1600 includes a bus 1602, a processor 1604, a memory 1606, and a communication interface 16016. Processor 1604, memory 1606, and communication interface 16016 communicate with each other via bus 1602. Computing device 1600 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 1600.

[0228] The bus 1602 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 16 The fact that only one s line is used in the figure does not mean that there is only one bus or only one type of bus. The bus 1602 may include a path for transmitting information between various components of the computing device 1600 (eg, the memory 1606, the processor 1604, and the communication interface 1608).

[0229] The processor 1604 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0230] The memory 1606 may include volatile memory, such as random access memory (RAM). The processor 1604 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0231] The memory 1606 stores executable program codes, and the processor 1604 executes the executable program codes to respectively implement the functions of the aforementioned acquisition module, determination module, identification module, and communication module, or the functions of the transmitting end in the above embodiment, thereby implementing Figure 9 、 Figure 12 or Figure 14 That is, the memory 1606 stores instructions for executing the method of the above embodiment.

[0232] The communication interface 1608 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1600 and other devices or a communication network.

[0233] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0234] like Figure 17 As shown, the computing device cluster includes at least one computing device 1700. The memory 1706 in one or more computing devices 1700 in the computing device cluster may store the same Figure 4 、 Figure 12 or Figure 14 The method shown is an instruction to a sending end or a network device.

[0235] In some possible implementations, the memory 1706 of one or more computing devices 1700 in the computing device cluster may also store some instructions for executing the methods in the above embodiments. In other words, the combination of one or more computing devices 1700 can jointly execute the instructions for executing the methods in the above embodiments.

[0236] It should be noted that the memory 1706 in different computing devices 1700 in the computing device cluster can store different instructions, each for executing a portion of the functions of the cloud management platform apparatus. In other words, the instructions stored in the memory 1706 in different computing devices 1700 can implement the functions of one or more modules of the network device.

[0237] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network, which may be a wide area network or a local area network. Figure 18 A possible implementation is shown. Figure 18 As shown, two computing devices 1800A and 1800B are connected via a network. Specifically, the connection to the network is achieved through a communication interface in each computing device. In this possible implementation, the memory 1806 in computing device 1800A stores instructions for executing the functions of the acquisition module and the determination module. Simultaneously, the memory 1806 in computing device 1800B stores instructions for executing the functions of the identification module and the communication module. Alternatively, this may implement the functions of the transmitting end described in the above embodiments.

[0238] It should be understood that Figure 18 The functionality of the computing device 1800A shown in FIG. 1 may also be implemented by multiple computing devices 1800. Similarly, the functionality of the computing device 1800B may also be implemented by multiple computing devices 1800.

[0239] The present application embodiment also provides another computing device cluster. The connection relationship between the computing devices in the computing device cluster can be similarly referred to as Figure 11 and Figure 18 The connection mode of the computing device cluster is different in that the memory 1806 of one or more computing devices 1800 in the computing device cluster may store the same instructions for executing the measurement method.

[0240] In some possible implementations, the memory 1806 of one or more computing devices 1800 in the computing device cluster may also store some instructions for the methods in the above embodiments. In other words, the combination of one or more computing devices 1800 can jointly execute instructions for performing the methods in the above embodiments.

[0241] It should be noted that the memory 1806 in different computing devices 1800 in the computing device cluster can store different instructions for executing partial functions of the cloud management platform. In other words, the instructions stored in the memory 1806 in different computing devices 1800 can implement the functions of one or more devices in the cloud management platform.

[0242] The present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the communication method described in the above embodiments.

[0243] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the communication method in the above embodiment.

[0244] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A communication method, characterized in that: include: In response to a first data packet sent by the sending end, obtaining a network congestion condition parameter; Determining a network congestion level based on the network congestion condition parameter; According to the network congestion level, a network congestion identifier is added to at least one data packet from the sending end.

2. The method according to claim 1, characterized in that The method further comprises: Forwards data packets from the sender to the receiver; Receive a second data packet; wherein, the first receiving interval between the first data packet and the second data packet is different from the second receiving interval between the first data packet and the third data packet, the third data packet is the previous data packet of the first data packet, the first receiving interval is adjusted by the sending end based on the number of network congestion identifiers, and the number of network congestion identifiers is obtained by the receiving end based on the statistics of the received data packets and sent to the sending end.

3. The method according to claim 1, characterized in that The network congestion condition parameters include a maximum delay and a minimum delay.

4. The method according to claim 3, characterized in that The maximum delay value and the minimum delay value are set by the sending end based on the service type.

5. The method according to claim 3, characterized in that The determining the network congestion degree based on the network congestion condition parameter includes: placing the first data packet in a target cache queue; Obtaining a delay value of the first data packet corresponding to the target cache queue, where the delay value indicates a time duration between when the first data packet is placed in the target cache queue and when it is removed from the target cache queue; The network congestion level is determined based on the delay value, the maximum delay value, and the minimum delay value.

6. The method according to any one of claims 1 to 5, characterized in that The network congestion condition parameter is carried in the header field of the first data packet.

7. The method according to claim 6, characterized in that The network congestion condition is carried in the IP field of the first data packet.

8. The method according to claim 1, characterized in that The first data packet further includes forwarding rate acquisition indication information, and the method further includes: Acquire a forwarding rate based on the forwarding rate acquisition indication information; increasing the forwarding rate for the first data packet; Send the first data packet to the receiving end.

9. The method according to claim 8, characterized in that The method further comprises: Receive a fourth data packet; wherein, the third receiving interval between the first data packet and the fourth data packet is different from the second receiving interval between the first data packet and the third data packet, the third data packet is the previous data packet of the first data packet, the third receiving interval is adjusted by the sending end based on the number of network congestion identifiers and the forwarding rate, the number of network congestion identifiers is obtained by the receiving end based on the statistics of the received data packets and sent to the sending end, and the forwarding rate is sent to the sending end when the receiving end detects that the forwarding rate carried by the first data packet is different from the forwarding rate obtained last time.

10. The method according to claim 8, characterized in that The forwarding rate acquisition indication information is carried in the header field of the first data packet.

11. The method according to claim 10, characterized in that The forwarding rate acquisition indication information is carried in the IP field of the first data packet.

12. A communication device, characterized in that: include: an acquisition module, configured to acquire a network congestion condition parameter in response to a first data packet sent by a sending end; A determination module, configured to determine a degree of network congestion based on the network congestion condition parameter; The marking module is used to add a network congestion mark to at least one data packet from the sending end according to the network congestion level.

13. The device according to claim 12, characterized in that The device further comprises: A communication module, used to forward data packets from the sending end to the receiving end; The communication module is also used to receive a second data packet; wherein, the first receiving interval between the first data packet and the second data packet is different from the second receiving interval between the first data packet and the third data packet, the third data packet is the previous data packet of the first data packet, the first receiving interval is adjusted by the sending end based on the number of network congestion identifiers, and the number of network congestion identifiers is obtained by the receiving end based on the statistics of the received data packets and sent to the sending end.

14. The device according to claim 12, characterized in that The network congestion condition parameters include a maximum delay and a minimum delay.

15. The device according to claim 14, characterized in that The maximum delay value and the minimum delay value are set by the sending end based on the service type.

16. The device according to claim 14, characterized in that The determining module is specifically configured to: placing the first data packet in a target cache queue; Obtaining a delay value of the first data packet corresponding to the target cache queue, where the delay value indicates a time duration between when the first data packet is placed in the target cache queue and when it is removed from the target cache queue; The network congestion level is determined based on the delay value, the maximum delay value, and the minimum delay value.

17. The device according to any one of claims 12 to 16, characterized in that The network congestion condition parameter is carried in the header field of the first data packet.

18. The device according to claim 17, characterized in that The network congestion condition is carried in the IP field of the first data packet.

19. The device according to claim 12, characterized in that The first data packet further includes forwarding rate acquisition indication information, and the apparatus further includes a communication module configured to: Acquire a forwarding rate based on the forwarding rate acquisition indication information; increasing the forwarding rate for the first data packet; Send the first data packet to the receiving end.

20. The device according to claim 19, characterized in that The communication module is further used for: Receive a fourth data packet; wherein, the third receiving interval between the first data packet and the fourth data packet is different from the second receiving interval between the first data packet and the third data packet, the third data packet is the previous data packet of the first data packet, the third receiving interval is adjusted by the sending end based on the number of network congestion identifiers and the forwarding rate, the number of network congestion identifiers is obtained by the receiving end based on the statistics of the received data packets and sent to the sending end, and the forwarding rate is sent to the sending end when the receiving end detects that the forwarding rate carried by the first data packet is different from the forwarding rate obtained last time.

21. The device according to claim 19, characterized in that The forwarding rate acquisition indication information is carried in the header field of the first data packet.

22. The device according to claim 21, characterized in that The forwarding rate acquisition indication information is carried in the IP field of the first data packet.

23. A computer storage medium, characterized in that The method comprises computer instructions, which, when executed on an electronic device, enable the electronic device to execute the method according to any one of claims 1 to 11.

24. A computer program product, characterized in that When the computer program product is run on a computer, the computer is enabled to perform the method according to any one of claims 1 to 11.

25. A chip, characterized in that: The electronic device comprises one or more interface circuits and one or more processors; the interface circuit is used to receive a signal from a memory of the electronic device and send the signal to the processor, wherein the signal includes a computer instruction stored in the memory; when the processor executes the computer instruction, the electronic device executes the method according to any one of claims 1 to 11.