Congestion management method, communication device and storage medium

Abstract

The invention provides a congestion management method, communication equipment and a storage medium. The congestion management method applied to a transmitting end comprises the following steps: adding congestion indication information to data to be transmitted; wherein the congestion indication information is used for indicating the congestion condition of data to be transmitted; and sending the congestion indication information to a receiving end.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a congestion management method, communication device, and storage medium. Background Technology

[0002] To improve the Quality of Service (QoS) of end-to-end transmission, when data buffering increases at a node in the transmission path, the Active Queue Management (AQM) algorithm can be used for congestion assessment and handling. Combined with congestion control algorithms for Transmission Control Protocol (TCP) / User Datagram Protocol (UDP) and Quick UDP Internet Connections (QUIC), this approach can effectively solve congestion problems in end-to-end transmission, reducing latency and packet loss.

[0003] In the field of Wi-Fi technology, due to the randomness of channel access and the susceptibility of the wireless air interface to interference, the wireless link becomes a bottleneck node in end-to-end transmission. Therefore, when the wireless link transmission quality deteriorates, and the access point (AP) or station (STA) experiences increased data buffering leading to queue congestion, newly enqueued data or data already in the queue may be intentionally dropped, ultimately resulting in packet loss or increased latency in end-to-end transmission. Therefore, a congestion awareness and notification method at the Media Access Control (MAC) layer is urgently needed to address the congestion problem of wireless links. Summary of the Invention

[0004] In view of this, embodiments of this application provide a congestion management method, a communication device, and a storage medium, which solve the congestion problem of wireless links.

[0005] This application provides a congestion management method applied at a transmitter, including:

[0006] Add congestion indication information to the data to be transmitted; wherein, the congestion indication information is used to indicate the congestion status of the data to be transmitted;

[0007] The congestion indication information is sent to the receiving end.

[0008] This application provides a congestion management method applied at a receiving end, including:

[0009] Receive congestion indication information sent by the transmitter; wherein the congestion indication information is used to indicate the congestion status of the data to be transmitted.

[0010] This application provides a congestion management device applied at a transmitter, comprising:

[0011] Add a module and configure it to add congestion indication information to the data to be transmitted; wherein, the congestion indication information is used to indicate the congestion status of the data to be transmitted.

[0012] The transmitter is configured to send the congestion indication information to the receiver.

[0013] This application provides a congestion management device applied at a receiving end, comprising:

[0014] The receiver is configured to receive congestion indication information sent by the transmitter; wherein the congestion indication information is used to indicate the congestion status of the data to be transmitted.

[0015] This application provides a communication device, including: a memory, and one or more processors;

[0016] The memory is configured to store one or more programs;

[0017] When the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any of the above embodiments.

[0018] This application provides a storage medium storing a computer program, which, when executed by a processor, implements the methods described in any of the above embodiments. Attached Figure Description

[0019] Figure 1 This is a schematic diagram illustrating the implementation of the ECN mechanism in L4S provided by existing technology;

[0020] Figure 2 This is a schematic diagram of the configuration of an IP frame structure provided by existing technology;

[0021] Figure 3 This is a schematic diagram illustrating the implementation of an L4S workflow provided by existing technology;

[0022] Figure 4 This is a schematic diagram of the configuration of flow classification information based on IPv4 provided by existing technology;

[0023] Figure 5 This is a schematic diagram of the configuration of flow classification information based on IPv6 provided by existing technology;

[0024] Figure 6This is a configuration diagram of a stream feature recognition frame format provided by existing technology;

[0025] Figure 7 This is a flowchart of a congestion management method provided in an embodiment of this application;

[0026] Figure 8 This is a schematic diagram illustrating the configuration of IPv4-based flow classification information provided in an embodiment of this application;

[0027] Figure 9 This is a schematic diagram illustrating the configuration of flow classification information based on IPv6, provided in an embodiment of this application.

[0028] Figure 10 This is a schematic diagram of the frame structure configuration of a QoS feature element provided in an embodiment of this application;

[0029] Figure 11 This is a schematic diagram of the frame structure configuration of an A-control field provided in an embodiment of this application;

[0030] Figure 12 This is a flowchart of another congestion management method provided in the embodiments of this application;

[0031] Figure 13 This is an interactive diagram illustrating downlink congestion negotiation and notification provided in an embodiment of this application;

[0032] Figure 14 This is a flowchart illustrating the implementation of congestion management according to an embodiment of this application;

[0033] Figure 15 This is an interactive schematic diagram of uplink congestion negotiation and notification provided in an embodiment of this application;

[0034] Figure 16 This is another flowchart illustrating the implementation of congestion management provided in this application embodiment;

[0035] Figure 17 This is a flowchart illustrating the implementation of congestion negotiation provided in an embodiment of this application;

[0036] Figure 18 This is a structural block diagram of a congestion management device provided in an embodiment of this application;

[0037] Figure 19 This is a structural block diagram of another congestion management device provided in the embodiments of this application;

[0038] Figure 20 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0039] The embodiments of this application will be described below with reference to the accompanying drawings. The examples given are for illustrative purposes only and are not intended to limit the scope of this application.

[0040] Figure 1 This is a schematic diagram illustrating the implementation of an Explicit Congestion Notification (ECN) mechanism in L4S provided by existing technology. Figure 1 As shown, the L4S sending application transmits IP packets that support ECT1 in L4S; in the event of congestion, the bottleneck node sets the IP packets to CE|ECT1; the receiving application obtains the IP packets and reports the congestion notification to the TCP layer; the receiving application sends a TCP response with a congestion flag in the TCP header; the sending application adjusts its congestion window to reduce queuing delay.

[0041] Figure 2 This is a configuration diagram of an IP frame structure provided by existing technology. When sending IP data, the transmitting application supporting L4S functionality indicates support for ECN capability (ECT(1)) in the IP header, i.e., 01, as shown below. Figure 2 As shown.

[0042] When the IP data passes through the bottleneck node, the data cache at that node increases. The AQM algorithm determines that congestion has occurred, so it modifies the identification information in the corresponding IP header to CE, i.e., 11.

[0043] When the IP packet is sent to the L4S receiver, the receiver learns from the IP header that congestion has occurred in the end-to-end transmission. In the higher-level response feedback, such as the TCP response message, the CE information is marked in the TCP header. Specifically, it is divided into ECN-Echo feedback (through the seventh bit of the TCP header) and CE code point feedback (through the sixth bit of the TCP header).

[0044] After receiving a TCP acknowledgment message carrying congestion information, the L4S sender adjusts the congestion window through a congestion control algorithm, i.e., shrinks the congestion window and reduces the packet sending rate, thereby reducing the amount of subsequent data buffered at the bottleneck node and ultimately alleviating congestion.

[0045] The congestion handling scheme described above detects and marks congestion at the IP layer, feeds the congestion information back to the upper layer, such as the TCP / QUIC layer, and finally the application at the TCP / QUIC layer adjusts the congestion window and reduces the packet sending rate to alleviate the congestion problem at the bottleneck node in end-to-end transmission.

[0046] In the field of Wi-Fi technology, due to the randomness of channel access and the susceptibility of the wireless air interface to interference, the wireless link naturally becomes a bottleneck node in end-to-end transmission. Therefore, when the transmission quality of the wireless link deteriorates and the AP or STA buffers more data, leading to queue congestion, newly enqueued data or data already in the queue may be actively dropped, ultimately resulting in packet loss or increased latency in end-to-end transmission. Therefore, a congestion awareness and notification method at the MAC layer is urgently needed to solve the congestion problem of the wireless link. The specific problem is as follows:

[0047] Problem 1: Lack of negotiated congestion assessment parameters

[0048] The AQM algorithm typically uses one or more of queue length, latency, and transmission bandwidth as indicators of congestion, and these parameters are usually defined internally by the device. In Wi-Fi technology, the QoS characteristics defined in the EHT SCS procedure for QoS requirement negotiation provide MAC layer transmission requirements, such as transmission rate, latency, and jitter. Taking latency as an example, the latency mentioned above is the time from when data arrives at the MAC layer to when the corresponding acknowledgment frame is received by the MAC layer. However, the AQM algorithm focuses on the latency from when data arrives at the MAC layer to when the data is ready to compete for air interface resources (i.e., dequeue time - enqueue time). Therefore, the queue congestion parameter is currently missing in the QoS requirement negotiation of Wi-Fi.

[0049] Question 2: Lack of indication methods to support multiple congestion negotiation modes

[0050] Typically, in the downlink direction, the AP needs to segment traffic using Traffic Classification (TCLAS) and provide QoS guarantees for flows that conform to TCLAS. However, SCS and ETH SCS are optional features, and the AP may not support TCLAS flow classification. Therefore, at least two congestion negotiation modes are required: first, supporting congestion control for specific flow classifications; second, supporting congestion control for all flows.

[0051] Question 3: Lack of congestion notification mechanism at the MAC layer

[0052] In L4S ECN technology, when congestion occurs, a congestion flag (CE) is set in the IP header of congested data packets. The receiving end parses this information and reports it to the upper layer, ultimately feeding back to the sending end to adjust the congestion window and reduce the transmission rate, thereby alleviating congestion at the bottleneck node. Similarly, when AP congestion occurs, the MAC layer needs to support similar congestion marking and notification methods to ensure that the receiving end can successfully receive congestion information and report it to the upper layer.

[0053] To facilitate understanding of the solution, the technologies involved in this solution are explained as follows.

[0054] Firstly, regarding Fiber-to-The-Room (FTTR) technology, FTTR connects wireless routers (APs) in different rooms or locations in homes or small and medium-sized enterprises via fiber optic cables, thereby providing high-bandwidth and high-reliability connections between multiple APs. It can utilize point-to-multipoint optical distribution networks to achieve connections between master control APs and slave APs.

[0055] Secondly, regarding latency: end-to-end latency is the sum of three different factors: propagation, interface, and queuing latency. The need to reduce interaction latency is becoming increasingly common for any user application: interactive web pages, web services, voice, conversational video, interactive video, interactive telepresence, instant messaging, online games, remote desktops, cloud computing applications, and video-assisted remote control of machinery and industrial processes. Propagation latency can be reduced by placing caches or servers closer together. However, queuing-related latency remains the primary factor, although it is an intermittent component. For example, peaks of hundreds of milliseconds are very common. During long-running data streams, even with state-of-the-art AQM, path latency based on light-speed propagation roughly doubles. Reducing losses along the propagation path is also important because for interactive applications, these losses translate into packet retransmissions, leading to even longer retransmission delays.

[0056] For L4S: L4S stands for Low Latency, Low Loss, and Scalable Throughput. It significantly reduces the latency experienced by data packets traveling over the Internet. L4S addresses one of the biggest—and most often overlooked—sources of latency and latency variation or jitter: queuing latency.

[0057] Queuing delays occur when data packets are idle and waiting in network buffers before being forwarded, such as in routers and modems. As users and bandwidth-intensive applications send increasing traffic across the network, these queued packets cause network links to become "congested." Packets in the congested pipe take longer to reach their destination.

[0058] Data can be transmitted over a network at a rate that congestion control algorithms adjust based on the number of dropped packets and observed latency in the network. These classic congestion control algorithms require large buffers and network latency to operate smoothly. L4S eliminates the need for large buffers. When congestion occurs, L4S informs the user application by including a congestion signal in the data packets sent from the sender. Upon receiving the congestion signal, the user application promptly adjusts the packet transmission rate from the server application layer to the access layer, thereby reducing the amount of data queuing on the server side per unit time and achieving the goal of low latency.

[0059] Figure 3 This is a schematic diagram illustrating an implementation of an L4S workflow provided by existing technology. For example... Figure 3 As shown, the entire L4S workflow includes the following four steps:

[0060] Step 1: Application data, including both traditional data and L4S data, is sent to the Wi-Fi system;

[0061] Step 2: The Wi-Fi MAC layer divides the data into traditional data and L4S data according to the IP protocol packet identifier, and puts them into different data queues respectively;

[0062] Step 3: When congestion occurs, the ECN field of L4S data will be set to Congestion Experienced (CE); while traditional data will be dropped directly (or a drop flag will be set and the scheduler will decide how to drop the packet).

[0063] Step 4: After receiving L4S data with the CE tag set, the receiving end adjusts the packet sending rate of the server through the application to reduce the packet sending rate of L4S data, thereby reducing the latency of L4S data.

[0064] in, Figure 3 In this context, (1) represents isolation in an independent network queue; (2) represents a packet identification protocol; and (3) represents a scalable sending host.

[0065] For commonly used AQM algorithms: In network nodes, the AQM active queue management algorithm is often used for early congestion prediction and congestion handling. Common AQM algorithms include:

[0066] Firstly, the Random Early Detection (RED) algorithm is used to help alleviate network congestion and reduce packet loss. It monitors the number of packets queued in the router's queue and begins randomly dropping some packets when the queue length reaches a certain threshold to avoid queue overflow and network congestion; a judgment is made when each packet is enqueued.

[0067] Secondly, the Proportional Integral (PI) controller makes judgments at fixed time intervals. Like RED, it calculates the drop probability based on the current queue length. When the drop probability is greater than a preset value, the data packet is dropped. The difference is that the PI algorithm calculates the current drop probability based on historical packet loss probabilities.

[0068] Third, Proportional Integral Enhancement (PIE) differs from PI in that it uses queue delay as a congestion metric. There are two schemes for queue delay: 1. queue length / average rate; 2. dequeue timestamp of the current dequeue packet minus enqueue timestamp.

[0069] Thirdly, regarding stream information recognition technology and stream feature recognition technology:

[0070] 1) Stream information recognition technology

[0071] To optimize the scheduling of audio and video stream data at the Wi-Fi MAC layer and meet multimedia latency requirements, existing protocols have proposed Stream Classification Service (SCS) technology. For IPv4 packets, this means that before the service stream is transmitted, the STA (Station) informs the AP (Access Point) of the service stream's five-tuple information (source IP address, source port, destination IP address, destination port, and transport layer protocol). For IPv6 packets, the STA informs the AP of the service stream's three-tuple information (source IP address, destination IP address, and flow label) in advance.

[0072] After receiving data packets, the AP matches the data packets with the service flow information based on their characteristics. Once the identification is successful, the corresponding data packets are placed in a high-priority queue and scheduled accordingly to meet the latency requirements of these services.

[0073] Figure 4 This is a configuration diagram of IPv4-based flow classification information provided by existing technology, such as... Figure 4 As shown, an IPv4 packet flow includes the following fields: Classifier Type, Classifier Mask, Version, Source IP address, Destination IP Address, Source Port, Destination Port, DSCP, Protocol, and Reserved, occupying 1, 1, 1, 4, 4, 2, 2, 1, 1, and 1 byte respectively. Detailed explanations of these fields are shown in Table 1.

[0074] Table 1 Explanation of IPv4 Flow Information

[0075] Field Name explain Classifier Type Category type identifier Classifier Mask Classification mask Version Version information Souce IP address Source IP address Destination IP Address Destination IP address Souce Port Source port number Destination Port Destination port number DSCP Differential service code point Protocol Protocol type

[0076] Figure 5 This is a configuration diagram of flow classification information based on IPv6 provided by existing technology, such as... Figure 5 As shown, the IPv6 packet flow includes the following fields: Classifier Type, Classifier Mask, Version, Source IP address, Destination IP Address, Source Port, Destination Port, and Flow Lab, occupying 1, 1, 1, 16, 16, 2, 2, and 3 bytes respectively. Detailed explanations of these fields are shown in Table 2.

[0077] Table 2 Explanation of IPv6 Flow Information

[0078] Field Name explain Classifier Type Category type identifier Classifier Mask Classification mask Version Version information Souce IP address Source IP address Destination IP Address Destination IP address Souce Port Source port number Destination Port Destination port number Flow Label Stream tag information

[0079] 2) Flow Feature Technology

[0080] Building upon existing flow information identification technologies, Wi-Fi 7 defines a flow characteristic-based technology: the STA (Station) sends a flow characteristic identification request to the AP (Access Point) using an action frame. This request includes parameters such as minimum service interval, maximum service interval, minimum rate, maximum latency, maximum MSDU (Maximum Service Demand) length, service start time, MSDU transmission success rate, and average access time. Upon receiving the flow characteristic identification request, the AP locally records the flow information characteristics and schedules uplink, downlink, and point-to-point data based on these flow characteristics.

[0081] Figure 6 This is a configuration diagram of a stream feature identification frame format provided by existing technology. The STA sends an action frame to the AP in the following format: Figure 6 As shown in Table 3. The second row contains optional fields, indicated by the control information fields in the first row, which indicate whether the stream feature identification request frame contains optional fields. Each field is described in Table 3.

[0082] Table 3 Definitions and descriptions of frame fields for stream feature identification

[0083]

[0084] Fourth, regarding the Ultra High Reliability (UHR) in (Wi-Fi 8):

[0085] In the Wi-Fi 8 protocol, UHR mainly aims to improve transmission stability, including reducing latency, increasing throughput, and reducing packet loss rate.

[0086] In one embodiment, Figure 7 This is a flowchart of a congestion management method provided in an embodiment of this application. This embodiment is applied to situations where congestion is detected and notified at the MAC layer. This embodiment can be executed by a transmitting end. In one example, the transmitting end can be either an AP or a STA. For example, if the process of adding congestion indication information is performed by an AP, the transmitting end can be an AP; if the process of adding congestion indication information is performed by an STA, the transmitting end can be an STA. In one example, if the transmitting end is an AP, the corresponding receiving end is an STA. In another example, if the transmitting end is an STA, the corresponding receiving end is an AP.

[0087] like Figure 7 As shown, this embodiment includes: S710-S720.

[0088] S710. Add congestion indication information to the data to be transmitted; wherein, the congestion indication information is used to indicate the congestion status of the data to be transmitted.

[0089] The data to be transmitted refers to the data that needs to be transmitted from the transmitter to the receiver. In one example, congestion indication information is used to indicate whether the data to be transmitted from the transmitter to the receiver is causing queue congestion due to excessive buffering. In one example, the transmitter can determine whether congestion is caused by excessive buffering based on its own congestion judgment parameters. If congestion occurs, the transmitter can add congestion indication information to the message containing the data to be transmitted. In one example, if the transmitter is an AP and the receiver is a STA, the corresponding message containing the data to be transmitted is a downlink message. In another example, if the transmitter is a STA and the receiver is an AP, the corresponding message containing the data to be transmitted is an uplink message.

[0090] S720: Send congestion indication information to the receiving end.

[0091] In one embodiment, the transmitting end sends the data to be transmitted and congestion indication information to the receiving end via wireless transmission. In one example, if the transmitting end is an Access Point (AP) and the receiving end is a Station (STA), both the congestion indication information and the data to be transmitted are carried in the downlink message. In another example, if the transmitting end is a STA and the receiving end is an AP, both the congestion indication information and the data to be transmitted are carried in the uplink message. In this embodiment, the transmitting end notifies the receiving end of the congestion situation by adding congestion indication information to the data to be transmitted, thereby enabling the receiving end to negotiate and notify the transmitting end about congestion management based on the congestion indication information.

[0092] In one embodiment, the congestion management method applied to the transmitting end further includes: sending first congestion management capability information to the receiving end; wherein the first congestion management capability information is used to indicate the congestion management capabilities supported by the transmitting end. In one example, when the transmitting end is an AP, the first congestion management capability information is used to indicate the congestion management capabilities supported by the AP. In one example, if the transmitting end is a STA, the first congestion management capability information is used to indicate the congestion management capabilities supported by the STA.

[0093] In one embodiment, the congestion management method applied to the transmitting end further includes: receiving second congestion management capability information sent by the receiving end; wherein the second congestion management capability information is used to indicate the congestion management capabilities supported by the receiving end. In one example, when the receiving end is an AP, the second congestion management capability information is used to indicate the congestion management capabilities supported by the AP. In one example, if the receiving end is a STA, the second congestion management capability information is used to indicate the congestion management capabilities supported by the STA.

[0094] In one embodiment, the management frame for the first congestion management capability information includes at least one of the following: a beacon frame; a probe response frame; an authentication frame; and an association response frame.

[0095] The management frame for the second congestion management capability information includes at least one of the following: a probe request frame; an authentication frame; and an association request frame. In one example, if the AP acts as the transmitter and the STA acts as the receiver, the first congestion management capability information is used to indicate the congestion management capabilities supported by the AP, and the second congestion management capability information is used to indicate the congestion management capabilities supported by the STA. Correspondingly, the management frame for the AP to declare its own congestion management capabilities may include at least one of the following: a beacon frame, a probe response frame, an authentication frame, and an association response frame; the management frame for the STA to declare its own congestion management capabilities may include at least one of the following: a probe request frame; an authentication frame; and an association request frame.

[0096] In one embodiment, the management frame for the second congestion management capability information includes at least one of the following: a beacon frame; a probe response frame; an authentication frame; and an association response frame.

[0097] The management frame for the first congestion management capability information includes at least one of the following: a probe request frame; an authentication frame; and an association request frame. In one example, if the AP acts as the receiver and the STA acts as the transmitter, the second congestion management capability information is used to indicate the congestion management capabilities supported by the AP, and the first congestion management capability information is used to indicate the congestion management capabilities supported by the STA. Correspondingly, the management frame for the AP to declare its own congestion management capabilities may include at least one of the following: a beacon frame, a probe response frame, an authentication frame, and an association response frame; the management frame for the STA to declare its own congestion management capabilities may include at least one of the following: a probe request frame; an authentication frame; and an association request frame.

[0098] In one embodiment, the congestion management capability includes one of the following: a congestion management mode that supports flow classification; or a congestion management mode that does not support flow classification. In one example, the congestion management mode that supports flow classification can be a mode that supports congestion control for specific flow categories, or a mode that supports congestion control for all flows. In one example, the congestion management mode that supports flow classification needs to support flow classification functionality.

[0099] In one embodiment, if the transmitting end adopts a congestion management mode that supports flow classification, adding congestion indication information to the data to be transmitted includes: adding congestion indication information to the data to be transmitted that matches the flow classification information. In one example, a five-tuple matching method can be used to determine the matching between the flow classification information and the data to be transmitted. For example, if the source IP address, source port, destination IP address, destination port, and transport layer protocol are the same, then the flow classification information and the data to be transmitted are matched. In one example, if the communication between the transmitting end and the receiving end is in the uplink direction, and the transmitting end adopts a congestion management mode that supports flow classification, the transmitting end, based on congestion judgment parameters, can add congestion indication information to the data to be transmitted in the queue that matches the flow classification information when congestion occurs. That is, it adds congestion indication information to the uplink message and sends the congestion indication information to the receiving end. In one example, if the transmission and reception are in the downlink direction and the transmitter uses a congestion management mode that supports flow classification, the transmitter can add congestion indication information to the data to be transmitted in the queue that matches the flow classification information when it determines that congestion has occurred based on the congestion judgment parameters. That is, it adds congestion indication information to the downlink message and sends the congestion indication information to the receiver.

[0100] In one embodiment, if the transmitter adopts a congestion management mode that does not support flow classification, adding congestion indication information to the data to be transmitted includes adding congestion indication information to all data to be transmitted. In one example, if the transmitter adopts a congestion management mode that does not support flow classification, the transmitter directly adds congestion indication information to all data to be transmitted.

[0101] In one embodiment, the transmission between the transmitter and receiver is downlink. The congestion management method applied to the transmitter further includes: receiving a congestion management negotiation request sent by the receiver; wherein the congestion management negotiation request is used to request negotiation of congestion management information; and sending a corresponding congestion management negotiation response to the receiver. In one example, if the transmission between the transmitter and receiver is downlink, after the transmitter and receiver each declare their own congestion management capabilities in the management frame, the receiver can initiate a congestion management negotiation request to the transmitter to request negotiation of congestion management information; then the transmitter can reply to the receiver with a congestion management negotiation response to complete the negotiation process between the congestion management information.

[0102] In one embodiment, the transmission between the transmitter and the receiver is uplink; the congestion management method applied to the transmitter further includes: determining congestion management information. In one example, if the transmission between the transmitter and the receiver is uplink, the AP acting as the receiver does not need to initiate a congestion management negotiation request to the transmitter, and the STA acting as the transmitter can directly determine the congestion management information.

[0103] In one embodiment, the congestion management information includes at least one of the following: flow classification information; congestion assessment parameter information. In one example, the flow classification information may include IPv4 flow classification information or IPv6 flow classification information.

[0104] In one example, Figure 8 This is a schematic diagram illustrating the configuration of IPv4-based flow classification information according to an embodiment of this application. Figure 8 As shown, an L4S field is added to the IPv4 frame classification within the TCLAS element to distinguish between data that supports L4S and data that does not. The L4S field corresponds to the ECT field in the TOS field of the IPv4 header.

[0105] In one example, Figure 9 This is a schematic diagram illustrating the configuration of flow classification information based on IPv6, provided in an embodiment of this application. For example... Figure 9 As shown, an L4S field is added to the IPv6 frame classification within the TCLAS element to distinguish between data that supports L4S and data that does not. The L4S field corresponds to the ECT field in the Traffic Class section of the IPv6 header.

[0106] In one embodiment, the bearer frame of the congestion management negotiation request includes: a Flow Classification Service (SCS) request frame; and other management frames;

[0107] The bearer frames for congestion management negotiation responses include: SCS response frames; and other management frames.

[0108] In one embodiment, the congestion assessment parameter information includes at least one of the following: congestion queue delay information; congestion queue length information; congestion queue occupancy percentage information; and congestion queue rate. In one example, the congestion queue delay information is used to represent the target delay for congestion assessment; the congestion queue length information is used to characterize the length of the queue occupied for congestion assessment; the congestion queue occupancy percentage information is used to characterize the percentage of the queue occupied for congestion assessment; and the congestion queue rate is used to characterize the transmission rate of the target queue for congestion assessment.

[0109] In one embodiment, the bearer information of the congestion assessment parameter information includes: Quality of Service (QoS) feature elements. In one example, Figure 10 This is a schematic diagram of the frame structure configuration of a QoS feature element provided in an embodiment of this application. For example... Figure 10 As shown, assuming the QoS feature element is denoted as QoS characteristic element, the QoS characteristic elements are supplemented with the following fields: congestion queue delay, congestion queue size, and congestion queue data rate. Here, congestion queue delay represents the target delay for congestion assessment (e.g., 3ms); congestion queue size represents the queue occupancy length or percentage for congestion assessment; and congestion queue data rate represents the target queue transmission rate for congestion assessment. In one example, congestion assessment parameter information can be carried within the QoS characteristic elements or in other elements or fields.

[0110] In one embodiment, flow classification information is carried in the flow classification type based on IPv4 frames or the flow classification type based on IPv6 of the flow classification element.

[0111] In one embodiment, the flow classification information includes at least: a congestion handling capability indication field; wherein the congestion handling capability indication field is used to indicate whether congestion handling capability is supported.

[0112] In one embodiment, the frame carrying the congestion indication information includes at least one of the following: a data frame; a management frame; and a control frame.

[0113] In one embodiment, congestion indication information is carried in the MAC header portion of the data frame;

[0114] The MAC frame header includes one of the following: a QoS control field, an A-control field, other fields, or other control fields. In one example, Figure 11 This is a schematic diagram of the frame structure configuration of an A-control field provided in an embodiment of this application. For example... Figure 11 As shown, the frame structure includes a Control ID field and a congestion flag field. The congestion flag field is used to indicate whether congestion has occurred; for example, a value of 1 indicates that congestion occurred in the MSDU of this information frame, and a value of 0 indicates otherwise.

[0115] In one embodiment, the transmitting end includes one of the following: a single-link access point; a multi-link access point; a distributed multi-link access point; a relay access point; or a relay multi-link access point.

[0116] The receiving end includes one of the following: a single-link site; or a multi-link site device. In one example, when the transmitting end is an AP, the corresponding receiving end is a STA.

[0117] In one embodiment, the transmitting end includes one of the following: a single-link site; a multi-link site device;

[0118] The receiving end includes one of the following: a single-link access point; a multi-link access point; a distributed multi-link access point; a relay access point; or a relay multi-link access point. In one example, when the transmitting end is a STA, the corresponding receiving end is an AP.

[0119] In one embodiment, Figure 12 This is a flowchart of another congestion management method provided in this application embodiment. This embodiment is applied to the situation where congestion is perceived and notified at the MAC layer. This embodiment can be executed by the receiving end. In one example, the receiving end can be either an AP or a STA. For example, if the process of adding congestion indication information is executed by the AP, the transmitting end can be the AP, and the corresponding receiving end is the STA; if the process of adding congestion indication information is executed by the STA, the transmitting end can be the STA, and the corresponding receiving end is the AP.

[0120] like Figure 12 As shown, this embodiment includes: S1210.

[0121] S1210, Receive congestion indication information sent by the transmitter; wherein, the congestion indication information is used to indicate the congestion status of the data to be transmitted.

[0122] In one embodiment, the congestion management method applied to the receiving end further includes: receiving first congestion management capability information sent by the transmitting end; wherein the first congestion management capability information is used to indicate the congestion management capabilities supported by the transmitting end.

[0123] In one embodiment, the congestion management method applied to the receiving end further includes: sending second congestion management capability information to the transmitting end; wherein the second congestion management capability information is used to indicate the congestion management capabilities supported by the receiving end.

[0124] In one embodiment, the management frame for the first congestion management capability information includes at least one of the following: a beacon frame; a probe response frame; an authentication frame; and an association response frame.

[0125] The management frame for the second congestion management capability information includes at least one of the following: a probe request frame; an authentication frame; or an association request frame.

[0126] In one embodiment, the management frame for the second congestion management capability information includes at least one of the following: a beacon frame; a probe response frame; an authentication frame; and an association response frame.

[0127] The management frame for the first congestion management capability information includes at least one of the following: a probe request frame; an authentication frame; or an association request frame.

[0128] In one embodiment, the congestion management capability includes one of the following: a congestion management mode that supports flow classification; or a congestion management mode that does not support flow classification.

[0129] In one embodiment, the transmission between the transmitter and receiver is downlink; the congestion management method applied to the receiver further includes:

[0130] Send a congestion management negotiation request to the transmitting end; the congestion management negotiation request is used to request negotiation of congestion management information;

[0131] Receive the congestion management negotiation response sent by the transmitter.

[0132] In one embodiment, the transmission between the transmitter and receiver is uplink; the congestion management method applied to the receiver further includes:

[0133] Receive congestion management information determined by the transmitter.

[0134] In one embodiment, the congestion management information includes at least one of the following: flow classification information; congestion judgment parameter information.

[0135] In one embodiment, the bearer frame of the congestion management negotiation request includes: a Flow Classification Service (SCS) request frame; and other management frames;

[0136] The bearer frames for congestion management negotiation responses include: SCS response frames; and other management frames.

[0137] In one embodiment, the congestion assessment parameters include at least one of the following: congestion queue delay information; congestion queue length information; congestion queue occupancy percentage information; and congestion queue rate.

[0138] In one embodiment, the congestion assessment parameter information includes: Quality of Service (QoS) feature elements.

[0139] In one embodiment, flow classification information is carried in the flow classification type based on IPv4 frames or the flow classification type based on IPv6 of the flow classification element.

[0140] In one embodiment, the flow classification information includes at least: a congestion handling capability indication field; wherein the congestion handling capability indication field is used to indicate whether congestion handling capability is supported.

[0141] In one embodiment, the frame carrying the congestion indication information includes at least one of the following: a data frame; a management frame; and a control frame.

[0142] In one embodiment, congestion indication information is carried in the MAC header portion of the data frame;

[0143] The MAC frame header includes one of the following: QoS control field, A- control field, other fields or other control fields.

[0144] In one embodiment, the transmitting end includes one of the following: a single-link access point; a multi-link access point; a distributed multi-link access point; a relay access point; or a relay multi-link access point.

[0145] The receiving end includes one of the following: a single-link site; or a multi-link site device.

[0146] In one embodiment, the transmitting end includes one of the following: a single-link site; a multi-link site device;

[0147] The receiving end includes one of the following: single-link access point; multi-link access point; distributed multi-link access point; relay access point; relay multi-link access point.

[0148] It should be noted that the explanations of parameters such as congestion indication information, first congestion management capability information, second congestion management capability information, congestion management capability, and congestion management information involved in the congestion management method applied to the receiving end can be found in the descriptions of the corresponding parameters in the congestion management method applied to the transmitting end, and will not be repeated here.

[0149] The following example, using AP and STA as examples, illustrates the process of congestion management negotiation and notification. The congestion management mode and congestion assessment parameters are determined through negotiation between AP and STA; when congestion occurs, congestion information can be notified to each other by adding congestion flags.

[0150] In one example, Figure 13 This is a schematic diagram illustrating the interaction between downlink congestion negotiation and notification provided in an embodiment of this application. For example... Figure 13 As shown in this example, the downlink congestion negotiation and notification process includes the following steps:

[0151] S1310. The station carries its own supported congestion management capabilities in the management frame.

[0152] In one example, during the implementation of S1310, from a downlink perspective, the station, as the receiver, sends its supported congestion management capabilities to the access point, which is the transmitter. In another example, from a downlink perspective, the station sends second congestion management capability information to the access point to indicate the congestion management capabilities supported by the receiving station.

[0153] S1320. The access point carries its own supported congestion management capabilities in the management frame.

[0154] In one example, during the implementation of S1320, from a downlink perspective, the access point, acting as the transmitter, sends its supported congestion management capabilities to the site, acting as the receiver. In another example, from a downlink perspective, the access point sends first congestion management capability information to the site to indicate the congestion management capabilities supported by the access point as the transmitter.

[0155] S1330, The site initiates a congestion management negotiation request, requesting to negotiate congestion management information.

[0156] S1340, The access point responds to the congestion management negotiation response, completing the negotiation of congestion management information.

[0157] S1350. If congestion occurs, the access point will perform congestion management based on the negotiated congestion management information.

[0158] S1360, the access point sends a congestion notification to the site.

[0159] In one example, congestion notification can also be called congestion indication information.

[0160] In one example, Figure 14 This is a flowchart illustrating an implementation of congestion management provided in an embodiment of this application. This example is based on the above... Figure 13 The congestion management process corresponding to S1350 is explained in detail. In this embodiment, it is executed by the AP acting as the transmitting end. Figure 14 As shown, the congestion management process includes the following steps:

[0161] S1401, Receive downlink messages.

[0162] S1402. Determine whether the congestion management negotiation was successful. If yes, proceed to S1403; otherwise, proceed to S1410.

[0163] S1403. Determine whether the access point supports the congestion management mode of flow classification. If yes, proceed to S1404; otherwise, proceed to S1408.

[0164] S1404. Determine whether the stream classification information matches the downlink message. If yes, proceed to S1405; otherwise, proceed to S1410.

[0165] S1405. Determine whether congestion has occurred based on the congestion judgment parameters. If yes, proceed to S1406; otherwise, proceed to S1410.

[0166] S1406. Add congestion indication information to downlink messages in the queue that match the flow classification information.

[0167] S1407. When a downlink message carrying congestion indication information is transmitted wirelessly, a downlink information frame carrying congestion indication information is sent.

[0168] S1408. Determine whether congestion has occurred based on the congestion judgment parameters. If yes, proceed to S1409; otherwise, proceed to S1410.

[0169] S1409. Add congestion indication information to downlink messages in the queue.

[0170] S1410, Downlink data not processed.

[0171] In one example, Figure 15 This is a schematic diagram illustrating the interaction between uplink congestion negotiation and notification provided in an embodiment of this application. For example... Figure 15 As shown in this example, the congestion negotiation and notification process in the uplink direction includes the following steps:

[0172] S1510. The station carries its own supported congestion management capabilities in the management frame.

[0173] In one example, during the implementation of S1510, from the uplink perspective, the station, acting as the transmitter, sends its supported congestion management capabilities to the access point, which is acting as the receiver. In another example, from the uplink perspective, the station sends first congestion management capability information to the access point to indicate the congestion management capabilities supported by the transmitting station.

[0174] S1520. The access point carries its own supported congestion management capabilities in the management frame.

[0175] In one example, during the implementation of S1520, from the uplink perspective, the access point, acting as the receiving end, sends its supported congestion management capabilities to the site, acting as the transmitting end. In another example, from the uplink perspective, the access point sends second congestion management capability information to the site to indicate the congestion management capabilities supported by the receiving access point.

[0176] S1530. If congestion occurs, the site shall perform congestion management based on its own determined congestion management information.

[0177] S1540, The site sends a congestion notification to the access point.

[0178] In one example, Figure 16 This is another implementation flowchart of congestion management provided in the embodiments of this application. This example is based on the above... Figure 15 The congestion management process corresponding to S1530 is explained in detail. In this embodiment, it is executed by the STA acting as the transmitter. Figure 16 As shown, the congestion management process includes the following steps:

[0179] S1601, Receive uplink message.

[0180] S1602. Determine whether the site supports flow classification congestion management mode. If yes, proceed to S1603; otherwise, proceed to S1607.

[0181] S1603. Determine whether the stream classification information matches the uplink message. If yes, proceed to S1604; otherwise, proceed to S1609.

[0182] S1604. Determine whether congestion has occurred based on the congestion judgment parameters. If yes, proceed to S1605; otherwise, proceed to S1609.

[0183] S1605. Add congestion indication information to the uplink messages in the queue that match the stream classification information.

[0184] S1606. When an uplink message carrying congestion indication information is transmitted wirelessly, an uplink information frame carrying congestion indication information is sent.

[0185] S1607. Determine whether congestion has occurred based on the congestion judgment parameters. If yes, proceed to S1608; otherwise, proceed to S1609.

[0186] S1608. Add congestion indication information to the uplink data messages in the queue.

[0187] S1609, Uplink data not processed.

[0188] In one example, Figure 17 This is a flowchart illustrating an implementation of congestion negotiation provided in an embodiment of this application. For example... Figure 17 As shown, the congestion negotiation process includes the following steps:

[0189] S1710, The access point receives a congestion management negotiation request from the site.

[0190] S1720. Does the access point support congestion management mode for flow classification? If yes, proceed to S1730; otherwise, proceed to S1750.

[0191] S1730: Check if the flow classification and congestion judgment parameters were successfully negotiated. If yes, proceed to S1740; otherwise, proceed to S1760.

[0192] S1740, The access point accepts the site's congestion management negotiation request.

[0193] S1750: Does the congestion management negotiation request carry flow classification information? If yes, proceed to S1760; otherwise, proceed to S1770.

[0194] S1760, The access point rejects the site's congestion management negotiation request.

[0195] S1770: Check if the congestion assessment parameter negotiation was successful. If yes, proceed to S1740; otherwise, proceed to S1760.

[0196] In one embodiment, Figure 18 This is a structural block diagram of a congestion management device provided in an embodiment of this application. This embodiment is applied to the transmitting end. Figure 18 As shown, the congestion management device in this embodiment includes an addition module 1810 and a transmitter 1820.

[0197] Add module 1810 and configure it to add congestion indication information to the data to be transmitted; the congestion indication information is used to indicate the congestion status of the data to be transmitted.

[0198] Transmitter 1820 is configured to send congestion indication information to the receiver.

[0199] In one embodiment, the transmitter in the congestion management device applied to the transmitter is further configured to send first congestion management capability information to the receiver; wherein the first congestion management capability information is used to indicate the congestion management capabilities supported by the transmitter.

[0200] In one embodiment, the congestion management device applied to the transmitting end further includes: a receiver configured to receive second congestion management capability information sent by the receiving end; wherein the second congestion management capability information is used to indicate the congestion management capabilities supported by the receiving end.

[0201] In one embodiment, the management frame for the first congestion management capability information includes at least one of the following: a beacon frame; a probe response frame; an authentication frame; and an association response frame.

[0202] The management frame for the second congestion management capability information includes at least one of the following: a probe request frame; an authentication frame; or an association request frame.

[0203] In one embodiment, the management frame for the second congestion management capability information includes at least one of the following: a beacon frame; a probe response frame; an authentication frame; and an association response frame.

[0204] The management frame for the first congestion management capability information includes at least one of the following: a probe request frame; an authentication frame; or an association request frame.

[0205] In one embodiment, the congestion management capability includes one of the following: a congestion management mode that supports flow classification; or a congestion management mode that does not support flow classification.

[0206] In one embodiment, if the transmitter adopts a congestion management mode that supports flow classification, adding congestion indication information to the data to be transmitted includes: adding congestion indication information to the data to be transmitted that matches the flow classification information.

[0207] In one embodiment, if the transmitter adopts a congestion management mode that does not support flow classification, adding congestion indication information to the data to be transmitted includes adding congestion indication information to all data to be transmitted.

[0208] In one embodiment, the transmission between the transmitter and receiver is downlink; the congestion management device applied to the transmitter further includes:

[0209] The receiver is configured to receive congestion management negotiation requests sent by the receiving end; wherein, the congestion management negotiation request is used to request negotiation of congestion management information;

[0210] The transmitter is also configured to send a corresponding congestion management negotiation response to the receiver.

[0211] In one embodiment, the transmission between the transmitter and the receiver is an uplink transmission; the congestion management device applied to the transmitter further includes: a determination module configured to determine congestion management information.

[0212] In one embodiment, the congestion management information includes at least one of the following: flow classification information; congestion judgment parameter information.

[0213] In one embodiment, the bearer frame of the congestion management negotiation request includes: a Flow Classification Service (SCS) request frame; and other management frames;

[0214] The bearer frames for congestion management negotiation responses include: SCS response frames; and other management frames.

[0215] In one embodiment, the congestion assessment parameters include at least one of the following: congestion queue delay information; congestion queue length information; congestion queue occupancy percentage information; and congestion queue rate.

[0216] In one embodiment, the congestion assessment parameter information includes: Quality of Service (QoS) feature elements.

[0217] In one embodiment, flow classification information is carried in the flow classification type based on IPv4 frames or the flow classification type based on IPv6 of the flow classification element.

[0218] In one embodiment, the flow classification information includes at least: a congestion handling capability indication field; wherein the congestion handling capability indication field is used to indicate whether congestion handling capability is supported.

[0219] In one embodiment, the frame carrying the congestion indication information includes at least one of the following: a data frame; a management frame; and a control frame.

[0220] In one embodiment, congestion indication information is carried in the MAC header portion of the data frame;

[0221] The MAC frame header includes one of the following: QoS control field, A-control field, other fields or other control fields.

[0222] In one embodiment, the transmitting end includes one of the following: a single-link access point; a multi-link access point; a distributed multi-link access point; a relay access point; or a relay multi-link access point.

[0223] The receiving end includes one of the following: a single-link site; or a multi-link site device.

[0224] In one embodiment, the transmitting end includes one of the following: a single-link site; a multi-link site device;

[0225] The receiving end includes one of the following: single-link access point; multi-link access point; distributed multi-link access point; relay access point; relay multi-link access point.

[0226] The congestion management device provided in this embodiment is configured to implement... Figure 7 The congestion management method applied to the transmitter in the illustrated embodiment is similar in principle and technical effect to the congestion management device provided in this embodiment, and will not be described again here.

[0227] In one embodiment, Figure 19 This is a structural block diagram of another congestion management device provided in an embodiment of this application. This embodiment is applied to the receiving end. Figure 19 As shown, the congestion management device in this embodiment includes a receiver 1910.

[0228] Receiver 1910 is configured to receive congestion indication information sent by the transmitter; wherein the congestion indication information is used to indicate the congestion status of the data to be transmitted.

[0229] In one embodiment, the receiver in the congestion management device applied to the receiving end is further configured to receive first congestion management capability information sent by the transmitting end; wherein the first congestion management capability information is used to indicate the congestion management capabilities supported by the transmitting end.

[0230] In one embodiment, the congestion management device applied to the receiving end further includes a transmitter configured to send second congestion management capability information to the transmitting end; wherein the second congestion management capability information is used to indicate the congestion management capabilities supported by the receiving end.

[0231] In one embodiment, the management frame for the first congestion management capability information includes at least one of the following: a beacon frame; a probe response frame; an authentication frame; and an association response frame.

[0232] The management frame for the second congestion management capability information includes at least one of the following: a probe request frame; an authentication frame; or an association request frame.

[0233] In one embodiment, the management frame for the second congestion management capability information includes at least one of the following: a beacon frame; a probe response frame; an authentication frame; and an association response frame.

[0234] The management frame for the first congestion management capability information includes at least one of the following: a probe request frame; an authentication frame; or an association request frame.

[0235] In one embodiment, the congestion management capability includes one of the following: a congestion management mode that supports flow classification; or a congestion management mode that does not support flow classification.

[0236] In one embodiment, the transmission between the transmitter and receiver is downlink; the congestion management device applied to the receiver further includes:

[0237] The transmitter is configured to send a congestion management negotiation request to the transmitting end; wherein, the congestion management negotiation request is used to request negotiation of congestion management information;

[0238] The receiver is also configured to receive congestion management negotiation responses sent by the transmitter.

[0239] In one embodiment, the transmission between the transmitter and receiver is uplink; the congestion management device applied to the receiver further includes:

[0240] The receiver is also configured to receive congestion management information determined by the transmitter.

[0241] In one embodiment, the congestion management information includes at least one of the following: flow classification information; congestion judgment parameter information.

[0242] In one embodiment, the bearer frame of the congestion management negotiation request includes: a Flow Classification Service (SCS) request frame; and other management frames;

[0243] The bearer frames for congestion management negotiation responses include: SCS response frames; and other management frames.

[0244] In one embodiment, the congestion assessment parameters include at least one of the following: congestion queue delay information; congestion queue length information; congestion queue occupancy percentage information; and congestion queue rate.

[0245] In one embodiment, the congestion assessment parameter information includes: Quality of Service (QoS) feature elements.

[0246] In one embodiment, flow classification information is carried in the flow classification type based on IPv4 frames or the flow classification type based on IPv6 of the flow classification element.

[0247] In one embodiment, the flow classification information includes at least: a congestion handling capability indication field; wherein the congestion handling capability indication field is used to indicate whether congestion handling capability is supported.

[0248] In one embodiment, the frame carrying the congestion indication information includes at least one of the following: a data frame; a management frame; and a control frame.

[0249] In one embodiment, congestion indication information is carried in the MAC header portion of the data frame;

[0250] The MAC frame header includes one of the following: QoS control field, A- control field, other fields or other control fields.

[0251] In one embodiment, the transmitting end includes one of the following: a single-link access point; a multi-link access point; a distributed multi-link access point; a relay access point; or a relay multi-link access point.

[0252] The receiving end includes one of the following: a single-link site; or a multi-link site device.

[0253] In one embodiment, the transmitting end includes one of the following: a single-link site; a multi-link site device;

[0254] The receiving end includes one of the following: single-link access point; multi-link access point; distributed multi-link access point; relay access point; relay multi-link access point.

[0255] The congestion management device provided in this embodiment is configured to implement... Figure 12 The congestion management method applied to the receiving end in the illustrated embodiment is similar in principle and technical effect to the congestion management device provided in this embodiment, and will not be described again here.

[0256] In one embodiment, Figure 20 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Figure 20 As shown, the device provided in this application includes: a processor 2010, a memory 2020, and a communication module 2030. The device may contain one or more processors 2010. Figure 20 Taking a processor 2010 as an example, the number of memory units 2020 in this device can be one or more. Figure 20 Taking a memory module 2020 as an example, the processor 2010, memory 2020, and communication module 2030 of this device can be connected via a bus or other means. Figure 20Taking a bus connection as an example, in this embodiment, the device can function as both a transmitter and a receiver.

[0257] The memory 2020, as a computer-readable storage medium, can be configured to store software programs, computer-executable programs, and modules, such as program instructions / modules corresponding to the device in any embodiment of this application (e.g., the addition module 1810 and transmitter 1820 in the congestion management device). The memory 2020 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application program required for at least one function; the data storage area may store data created based on the use of the device, etc. Furthermore, the memory 2020 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 2020 may further include memory remotely located relative to the processor 2010, and these remote memories can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0258] When the communication device is used as the transmitter, the device provided above can be configured to execute the congestion management method for the transmitter provided in any of the above embodiments, and has the corresponding functions and effects.

[0259] When the communication device acts as the receiving end, the device provided above can be configured to execute the congestion management method for the receiving end provided in any of the above embodiments, and has the corresponding functions and effects.

[0260] This application also provides a storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are used to perform a congestion management method applied to a transmitting end. The method includes: adding congestion indication information to data to be transmitted; wherein the congestion indication information is used to indicate the congestion status of the data to be transmitted; and sending the congestion indication information to a receiving end.

[0261] This application also provides a storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are used to perform a congestion management method applied to a receiving end. The method includes: receiving congestion indication information sent by a transmitting end; wherein the congestion indication information is used to indicate the congestion status of data to be transmitted.

[0262] Those skilled in the art will understand that the term user equipment covers any suitable type of wireless user equipment, such as mobile phones, portable data processing devices, portable web browsers, or vehicle-mounted mobile stations.

[0263] Generally, the various embodiments of this application can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. For example, some aspects can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device, although this application is not limited thereto.

[0264] Embodiments of this application can be implemented by executing computer program instructions through the data processor of a mobile device, for example, in a processor entity, or through hardware, or through a combination of software and hardware. The computer program instructions can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages.

[0265] Any block diagram of logical flow in the accompanying drawings of this application may represent program steps, or may represent interconnected logic circuits, modules, and functions, or may represent a combination of program steps and logic circuits, modules, and functions. The computer program may be stored on memory. Memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as, but not limited to, read-only memory (ROM), random access memory (RAM), optical storage devices and systems (Digital Video Disc (DVD) or Compact Disc (CD)), etc. Computer-readable media may include non-transitory storage media. The data processor may be of any type suitable to the local technical environment, such as, but not limited to, general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and processors based on multi-core processor architectures.

[0266] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the congestion management method provided in any embodiment of this application.

[0267] In the implementation of the computer program product, computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smallport, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0268] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A congestion management method, characterized in that, Applications to the transmitting end include: Add congestion indication information to the data to be transmitted; wherein, the congestion indication information is used to indicate the congestion status of the data to be transmitted; The congestion indication information is sent to the receiving end.

2. The method according to claim 1, characterized in that, The method further includes: Send first congestion management capability information to the receiving end; wherein the first congestion management capability information is used to indicate the congestion management capabilities supported by the transmitting end.

3. The method according to claim 2, characterized in that, The method further includes: The receiver receives second congestion management capability information sent by the receiving end; wherein the second congestion management capability information is used to indicate the congestion management capabilities supported by the receiving end.

4. The method according to claim 3, characterized in that, The management frame for the first congestion management capability information includes at least one of the following: a beacon frame; a probe response frame; an authentication frame; and an association response frame. The management frame for the second congestion management capability information includes at least one of the following: a probe request frame; an authentication frame; or an association request frame.

5. The method according to claim 3, characterized in that, The management frame for the second congestion management capability information includes at least one of the following: a beacon frame; a probe response frame; an authentication frame; and an association response frame. The management frame for the first congestion management capability information includes at least one of the following: a probe request frame; an authentication frame; or an association request frame.

6. The method according to any one of claims 2-5, characterized in that, The congestion management capability includes one of the following: a congestion management mode that supports flow classification; or a congestion management mode that does not support flow classification.

7. The method according to claim 6, characterized in that, If the transmitting end adopts a congestion management mode that supports flow classification, adding congestion indication information to the data to be transmitted includes: Add congestion indication information to the data to be transmitted that matches the flow classification information.

8. The method according to claim 6, characterized in that, If the transmitting end adopts a congestion management mode that does not support flow classification, the addition of congestion indication information to the data to be transmitted includes: Add congestion indication information to all data to be transmitted.

9. The method according to claim 1, characterized in that, The transmission between the transmitter and the receiver is downlink; the method further includes: Receive a congestion management negotiation request sent by the receiving end; wherein the congestion management negotiation request is used to request negotiation of congestion management information; Send the corresponding congestion management negotiation response to the receiving end.

10. The method according to claim 1, characterized in that, The transmission between the transmitter and the receiver is an uplink transmission; the method further includes: Determine congestion management information.

11. The method according to claim 9 or 10, characterized in that, The congestion management information includes at least one of the following: flow classification information; congestion judgment parameter information.

12. The method according to claim 9, characterized in that, The bearer frame of the congestion management negotiation request includes: a Flow Classification Service (SCS) request frame; and other management frames. The bearer frames for the congestion management negotiation response include: SCS response frames; and other management frames.

13. The method according to claim 11, characterized in that, The congestion assessment parameters include at least one of the following: congestion queue delay information; congestion queue length information; congestion queue occupancy percentage information; and congestion queue rate.

14. The method according to claim 11, characterized in that, The congestion assessment parameter information includes the following: Quality of Service (QoS) feature elements.

15. The method according to claim 11, characterized in that, The flow classification information is carried in the flow classification type based on IPv4 frames or the flow classification type based on IPv6 of the flow classification element.

16. The method according to claim 11, characterized in that, The flow classification information includes at least: a congestion handling capability indication field; wherein the congestion handling capability indication field is used to indicate whether congestion handling capability is supported.

17. The method according to claim 1, characterized in that, The congestion indication information carrier frame includes at least one of the following: a data frame; a management frame; a control frame.

18. The method according to claim 17, characterized in that, The congestion indication information is carried in the MAC header portion of the data frame; The MAC frame header includes one of the following: QoS control field, A- control field, other fields or other control fields.

19. The method according to claim 1, characterized in that, The transmitting end includes one of the following: a single-link access point; a multi-link access point; a distributed multi-link access point; a relay access point; or a relay multi-link access point. The receiving end includes one of the following: a single-link site; or a multi-link site device.

20. The method according to claim 1, characterized in that, The transmitting end includes one of the following: a single-link site; a multi-link site device; The receiving end includes one of the following: a single-link access point; a multi-link access point; a distributed multi-link access point; a relay access point; or a relay multi-link access point.

21. A congestion management method, characterized in that, Applied to the receiving end, including: Receive congestion indication information sent by the transmitter; wherein the congestion indication information is used to indicate the congestion status of the data to be transmitted.

22. A communication device, characterized in that, include: Memory, and one or more processors; The memory is configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors perform the method as described in any one of claims 1-20 or 21 above.

23. A storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-20 or 21.

Images