Communication method and apparatus

By receiving the SCS request frame containing QoS parameters and device identification information, the first device can directly schedule the service flow between the second device and the third device, solving the problem of large signaling overhead, and achieving efficient QoS guarantee and user experience improvement.

WO2025124366A1PCT designated stage expired Publication Date: 2025-06-19HUAWEI TECH CO LTD
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
PCT/CN2024/138011
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-12-12
Filing Date
2024-12-10
Publication Date
2025-06-19

AI Technical Summary

Technical Problem

The prior art has high signaling overhead when ensuring end-to-end quality of service (QoS), especially in multi-device negotiation, resulting in inefficiency.

Method used

By receiving a SCS request frame from the second device in the communication method, the frame includes QoS parameters of the service stream, identification information of the second device and identification information of the third device, the first device may schedule the service flow between the second device and the third device based on the frame, reducing multiple negotiation and signaling overhead.

Benefits of technology

It realizes reducing signaling overhead, ensuring end-to-end QoS, improving user experience, and improving the efficiency of the communication system.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN2024138011_19062025_PF_FP_ABST
    Figure CN2024138011_19062025_PF_FP_ABST
Patent Text Reader

Abstract

The present application relates to a communication method and apparatus. In the method, a first device can schedule a service stream between a second device and a third device on the basis of an SCS request frame from the second device, so that the first device does not need to receive SCS request frames from the second device and the third device multiple times in order to respectively schedule the transmission of the service stream on the second device and the transmission thereof on the third device on the basis of multiple SCS request frames. Thus, signaling overhead can be reduced. In addition, end-to-end QoS is ensured, and user experience is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Communication method and device

[0001] This application claims priority to the Chinese patent application with application number 202311705396.5 filed with the State Intellectual Property Office of China on December 12, 2023, and priority to the Chinese patent application with the invention name “A Communication Method and Device”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a communication method and device. Background Art

[0003] In order to respond to users' demand for quality of service (QoS), a stream classification service (SCS) mechanism has been proposed. That is, a station (STA) can negotiate QoS parameters of the SCS flow with its associated access point (AP) through the SCS mechanism, such as QoS parameters for scheduling uplink transmission and / or QoS parameters for scheduling downlink transmission.

[0004] Generally speaking, to ensure end-to-end QoS, STAs at both ends of a service flow associated with the same AP need to negotiate QoS parameters for the SCS flow with the AP separately, which results in high signaling overhead. Summary of the Invention

[0005] The present application provides a communication method and apparatus that can save signaling overhead.

[0006] In a first aspect, a communication method is provided. The method can be performed by a first device, or by a module (e.g., a processor, chip, or chip system) applied to the first device, or by a logical node, logical module, or software that can implement all or part of the functions of the first device. In this communication method, an SCS request frame can be received from a second device. The SCS request frame includes QoS parameters for a service flow, and the SCS request frame also includes identification information of the second device and identification information of a third device. Thus, the service flow between the second device and the third device can be scheduled based on the SCS request frame.

[0007] It can be seen that in the above embodiment, the first device can schedule the service flow between the second device and the third device based on the SCS request frame from the second device, so that the first device does not need to receive SCS request frames from the second device and the third device multiple times to schedule the transmission of the service flow on the second device and the third device respectively based on multiple SCS request frames. For example, the first device first receives an SCS request frame from the second device (the SCS request frame is used to schedule the uplink transmission of the service flow on the second device), and then receives another SCS request frame from the third device (the SCS request frame is used to schedule the downlink transmission of the service flow on the third device). Then, the first device receives an SCS request frame from the second device (the SCS request frame is used to schedule the downlink transmission of the service flow on the second device), and finally receives another SCS request frame from the third device (the SCS request frame is used to schedule the uplink transmission of the service flow on the third device). In this way, signaling overhead can be saved. At the same time, end-to-end QoS is guaranteed and user experience is improved.

[0008] In combination with the first aspect, in a possible implementation, the SCS request frame also includes indication information, and scheduling the service flow between the second device and the third device based on the SCS request frame includes: scheduling the service flow between the second device and the third device based on the indication information and the QoS parameters of the service flow.

[0009] It can be seen that in the above embodiment, by carrying indication information in the SCS request frame, it is achieved that the first device is explicitly instructed to schedule the service flow between the second device and the third device based on the QoS parameters of the service flow, which is more flexible.

[0010] In combination with the first aspect, in a possible implementation, scheduling the service flow between the second device and the third device based on the SCS request frame includes: the QoS parameters of the service flow include the uplink QoS parameters of the service flow, and scheduling the uplink transmission of the service flow on the second device and the downlink transmission of the third device based on the SCS request frame; and / or, the QoS parameters of the service flow include the downlink QoS parameters of the service flow, and scheduling the downlink transmission of the service flow on the second device and the uplink transmission of the third device based on the SCS request frame.

[0011] As can be seen, in the above embodiment, the first device does not need to receive SCS request frames from the second and third devices multiple times in order to schedule the service flow for uplink transmission on the second device and downlink transmission on the third device based on the multiple SCS request frames, thereby saving signaling overhead. Similarly, the first device does not need to receive SCS request frames from the second and third devices multiple times in order to schedule the service flow for downlink transmission on the second device and uplink transmission on the third device based on the multiple SCS request frames, thereby saving signaling overhead. In addition, this can also ensure end-to-end QoS and improve the user experience.

[0012] In combination with the first aspect, in a possible implementation, the method further includes: determining, based on the identification information of the second device and the identification information of the third device, that both the second device and the third device are associated with the first device.

[0013] As can be seen, in the above embodiment, the first device can learn that both the second device and the third device are associated with the first device through the identification information of the second device and the identification information of the third device. This allows the first device to learn, through implicit indication, that the first device can schedule the service flow between the second device and the third device based on the QoS parameters of the service flow, thereby saving signaling overhead. At the same time, the first device can also identify the service flow through the identification information of the second device and the identification information of the third device.

[0014] With reference to the first aspect, in a possible implementation, the first device is an access point multi-link device, the second device is a non-access point multi-link device, and the third device is a non-access point multi-link device or a device that does not support QoS parameter reporting.

[0015] It can be seen that in the above embodiment, when the first device is an access point multi-link device, the second device is a non-access point multi-link device, and the third device is a non-access point multi-link device, the first device can still schedule the service flow between the second device and the third device based on the SCS request frame from the second device, thereby saving signaling overhead. When the first device is an access point multi-link device, the second device is a non-access point multi-link device, and the third device is a device that does not support QoS parameter reporting, when one end of the service flow (such as the third device) does not support QoS parameter reporting, the first device can still schedule the service flow between the second device and the third device based on the SCS request frame from the second device, thereby ensuring end-to-end QoS and improving user experience.

[0016] In combination with the first aspect, in one possible implementation, the identification information of the second device is the media access control MAC address of the second device, and the identification information of the third device is the MAC address of the third device; the source address information of the service flow is the identification information of the second device, and the destination address information of the service flow is the identification information of the third device; or, the source address information of the service flow is the identification information of the third device, and the destination address information of the service flow is the identification information of the second device.

[0017] In combination with the first aspect, in a possible implementation, the indication information is carried in a QoS feature element of the SCS request frame.

[0018] In combination with the first aspect, in a possible implementation, the identification information of the second device and the identification information of the third device are carried in a flow classification element of the SCS request frame.

[0019] It can be seen that in the above embodiment, the identification information of the second device and the identification information of the third device can be carried in the flow classification element of the SCS request frame, which helps the first device to ensure that the service is directed to the corresponding traffic identifier (traffic identifier, TID), thereby ensuring the consistency of the QoS management policy of all sites within the basic service set (BSS), so as to better manage and schedule the service transmission of the entire BSS.

[0020] With reference to the first aspect, in a possible implementation manner, the QoS parameters of the service flow include a minimum service interval and / or a maximum service interval.

[0021] In combination with the first aspect, in a possible implementation, the method further includes: sending an SCS response frame to the second device, where the SCS response frame is used to indicate that the service flow is accepted.

[0022] In a second aspect, a communication method is provided. The method can be performed by a second device, or by a module (e.g., a processor, chip, or chip system) applied to the second device. It can also be implemented by a logical node, logical module, or software that can implement all or part of the functions of the second device. In this communication method, an SCS request frame is generated. The SCS request frame includes QoS parameters for the service flow, and the SCS request frame also includes identification information of the second device and identification information of the third device. Thus, the SCS request frame can be sent to the first device, and the SCS request frame is used by the first device to schedule the service flow between the second device and the third device.

[0023] It can be seen that in the above embodiment, the second device can send an SCS request frame to the first device, so that the first device can schedule the service flow between the second device and the third device based on the SCS request frame from the second device, so that the first device does not need to receive SCS request frames from the second device and the third device multiple times to schedule the transmission of the service flow on the second device and the third device respectively based on multiple SCS request frames. For example, the first device first receives an SCS request frame from the second device (the SCS request frame is used to schedule the uplink transmission of the service flow on the second device), and then receives another SCS request frame from the third device (the SCS request frame is used to schedule the downlink transmission of the service flow on the third device). Then, the first device receives an SCS request frame from the second device (the SCS request frame is used to schedule the uplink transmission of the service flow on the second device), and finally receives another SCS request frame from the third device (the SCS request frame is used to schedule the downlink transmission of the service flow on the third device). In this way, signaling overhead can be saved. At the same time, end-to-end QoS is guaranteed and user experience is improved.

[0024] In combination with the second aspect, in a possible implementation, the SCS request frame further includes indication information, and the indication information and the QoS parameters of the service flow are used by the first device to schedule the service flow between the second device and the third device.

[0025] It can be seen that in the above embodiment, by carrying indication information in the SCS request frame, it is achieved that the first device is explicitly instructed to schedule the service flow between the second device and the third device based on the QoS parameters of the service flow, which is more flexible.

[0026] In combination with the second aspect, in one possible implementation, the QoS parameters of the service flow include uplink QoS parameters of the service flow, and the QoS parameters of the service flow are used by the first device to schedule the uplink transmission of the service flow on the second device and the downlink transmission on the third device; and / or, the QoS parameters of the service flow include downlink QoS parameters of the service flow, and the QoS parameters of the service flow are used by the first device to schedule the downlink transmission of the service flow on the second device and the uplink transmission on the third device.

[0027] As can be seen, in the above embodiment, the second device does not need to send SCS request frames to the first device multiple times, so that the first device can schedule the service flow for uplink and downlink transmission on the second device based on multiple SCS request frames, thereby saving signaling overhead. Similarly, the third device does not need to send SCS request frames to the first device multiple times, so that the first device can schedule the service flow for downlink and uplink transmission on the third device based on multiple SCS request frames, thereby saving signaling overhead. In addition, this can also ensure end-to-end QoS and improve the user experience.

[0028] In conjunction with the second aspect, in a possible implementation, the first device is an access point multi-link device, the second device is a non-access point multi-link device, and the third device is a non-access point multi-link device or a device that does not support QoS parameter reporting.

[0029] It can be seen that in the above embodiment, when the first device is an access point multi-link device, the second device is a non-access point multi-link device, and the third device is a non-access point multi-link device, the SCS request frame can still be used to schedule the service flow between the second device and the third device, thereby saving signaling overhead. When the first device is an access point multi-link device, the second device is a non-access point multi-link device, and the third device is a device that does not support QoS parameter reporting, the SCS request frame can still be used to schedule the service flow between the second device and the third device when one end of the service flow (such as the third device) does not support QoS parameter reporting, thereby ensuring end-to-end QoS and improving user experience.

[0030] In combination with the second aspect, in one possible implementation, the identification information of the second device is the media access control MAC address of the second device, and the identification information of the third device is the MAC address of the third device; the source address information of the service flow is the identification information of the second device, and the destination address information of the service flow is the identification information of the third device; or, the source address information of the service flow is the identification information of the third device, and the destination address information of the service flow is the identification information of the second device.

[0031] In combination with the second aspect, in a possible implementation, the indication information is carried in a QoS feature element of the SCS request frame.

[0032] In combination with the second aspect, in a possible implementation, the identification information of the second device and the identification information of the third device are carried in a flow classification element of the SCS request frame.

[0033] It can be seen that in the above embodiment, the identification information of the second device and the identification information of the third device can be carried in the flow classification element of the SCS request frame, which helps the first device to ensure that the service is projected to the corresponding TID, thereby ensuring the consistency of the QoS management policy of all sites within the BSS range, thereby better managing and scheduling the service transmission of the entire BSS.

[0034] In conjunction with the second aspect, in a possible implementation manner, the QoS parameters of the service flow include a minimum service interval and / or a maximum service interval.

[0035] In combination with the second aspect, in a possible implementation, the method further includes: receiving an SCS response frame from the first device, where the SCS response frame is used to indicate that the service flow is accepted.

[0036] In a third aspect, a communication device is provided, comprising a unit or module for implementing the method described in any one of aspects 1 to 2. The communication device may be a first device or a second device, or a module of the first device or the second device (e.g., a processor, a chip, or a chip system), or a logical node, a logical module, or software that can implement all or part of the functions of the first device or the second device.

[0037] In a fourth aspect, a communication device is provided, comprising at least one processor; wherein the at least one processor is configured to execute any of the methods described in any one of the first to second aspects. The communication device may be a first device or a second device, or a module of the first device or the second device (e.g., a processor, a chip, or a chip system), or a logical node, a logical module, or software that can implement all or part of the functions of the first device or the second device. At least one processor may execute a computer program or instruction in a memory so that the above method is executed. The memory may be included in the communication device or may be located outside the communication device. In addition, the communication device may further include an interface.

[0038] In a fifth aspect, a communication system is provided, the communication system comprising a first device and a second device; the first device is used to execute the method as described in any one of the first aspects; the second device is used to execute the method as described in any one of the second aspects.

[0039] In a sixth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and when the computer instructions are executed, the computer executes any one of the methods described in any one of the first to second aspects.

[0040] In a seventh aspect, a computer program product is provided, the computer program product comprising: a computer program code, and when the computer program code is executed by a computer, the computer executes any one of the methods described in any one of the first to second aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] FIG1 is a schematic diagram of a connection between an AP MLD and a non-AP MLD according to an embodiment of the present application;

[0042] FIG2 is a frame format of an SCS request frame;

[0043] FIG3 shows a format of an SCS descriptor;

[0044] FIG4 is a format of an internal access class priority element;

[0045] Figure 5 shows the format of a flow classification element;

[0046] FIG6 is a format of a frame classifier type field;

[0047] FIG7 is a format of yet another frame classifier type field;

[0048] FIG8 is a format of yet another frame classifier type field;

[0049] FIG9 shows a format of a QoS feature element;

[0050] FIG10 is a format of a control information field;

[0051] FIG11 is a format of an SCS response frame;

[0052] FIG12 is a schematic diagram of the architecture of a communication system provided in an embodiment of the present application;

[0053] FIG13 is a flow chart of a communication method provided in an embodiment of the present application;

[0054] FIG14 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0055] FIG15 is a schematic structural diagram of another communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0056] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings in the embodiments of the present application. In the embodiments of the present application, the terms "system" and "network" can be used interchangeably. Unless otherwise specified, " / " indicates that the objects associated before and after are in an "or" relationship. For example, A / B can represent A or B. "And / or" in this application is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. A and B can be singular or plural. In addition, in the description of this application, unless otherwise specified, "multiple" refers to two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, c can be one or more. In addition, to facilitate a clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, terms such as "first" and "second" are used to distinguish between network elements and identical or similar items with substantially the same functions. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and terms such as "first" and "second" do not necessarily limit differences.

[0057] References to "one embodiment" or "some embodiments" in the embodiments of the present application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the phrases "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0058] The following specific implementation methods further describe in detail the objectives, technical solutions and beneficial effects of the present application. It should be understood that the following are only specific implementation methods of the present application and are not intended to limit the scope of protection of the present application. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the present application should be included in the scope of protection of the present application.

[0059] In the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0060] In order to facilitate understanding of the contents of this solution, some of the terms involved in the embodiments of this application are explained below to facilitate understanding by those skilled in the art. This part is only for ease of understanding and cannot be regarded as a specific limitation of this application.

[0061] 1. STA

[0062] The STA involved in the embodiments of the present application may be a STA applicable to the 802.11 standard, such as 802.11a / b / g, 802.11n, 802.11ac, 802.11ax, or its next generation, such as 802.11be or a later generation standard. Among them, 802.11n may also be referred to as high throughput (HT). 802.11ac may also be referred to as very high throughput (VHT). 802.11ax may also be referred to as high efficiency (HE) or Wi-Fi 6. 802.11be may also be referred to as extremely high throughput (EHT) or Wi-Fi 7. Standards before HT, such as 802.11a / b / g, may be collectively referred to as non-HT.

[0063] The STA involved in the embodiments of the present application may be a terminal product that supports the medium access control (MAC) and physical layer (PHY) of the 802.11 standard, for example, various user terminals, user devices, access devices, subscriber stations, subscriber units, mobile stations, user agents, user equipment, or other names with wireless communication functions. The user terminals may include various handheld devices, vehicle-mounted devices, wearable devices, computing devices, or other processing devices connected to a wireless modem with wireless communication functions, as well as various forms of user equipment (UE), mobile stations (MS), terminals, terminal equipment, portable communication devices, handheld devices, portable computing devices, entertainment devices, gaming devices or systems, global positioning system devices, or any other suitable devices configured to communicate over a wireless medium. For example, a STA may be a router, a switch, a bridge, etc. Here, for the convenience of description, the above-mentioned devices are collectively referred to as stations or STAs.

[0064] In the embodiments of this application, the form of a STA is not limited. The device used to implement the functions of an STA can be a STA, or it can be a device that supports the STA in implementing the functions, such as a chip system. This device can be installed in the STA or used in conjunction with the STA. In the embodiments of this application, the chip system can be composed of a chip or include a chip and other discrete components.

[0065] In addition, a STA may also correspond to a MAC address.

[0066] 2. AP

[0067] The AP involved in the embodiments of the present application may be an AP applicable to the 802.11 standard, and may be a device deployed in a wireless communication network to provide wireless communication functions for its associated STAs. The AP may serve as the hub of the communication system and is typically a network-side product that supports the MAC and PHY of the 802.11 standard, such as a base station, router, gateway, repeater, communication server, switch, or bridge, etc. Among them, the base station may include various forms of macro base stations, micro base stations, relay stations, etc. Here, for the convenience of description, the above-mentioned devices are collectively referred to as APs.

[0068] In the embodiments of the present application, the form of the AP is not limited. The device for implementing the functions of the AP can be an AP; it can also be a device that can support the AP to implement the functions, such as a chip system. The device can be installed in the AP or used in conjunction with the AP.

[0069] In addition, the AP may also correspond to a MAC address.

[0070] 3. Multi-link device (MLD)

[0071] This application refers to an 802.11 standard station device that supports multiple link communications simultaneously as an MLD. A multi-link device includes one or more affiliated stations (affiliated STAs). An affiliated station is a logical station that can operate on a link, a frequency band, or a channel. Among them, the affiliated stations can be APs or STAs. If all stations within a certain MLD are APs, it can be further called an AP multi-link device (AP multi-link device, AP MLD). If all stations within a certain MLD are STAs, it can be further called a non-AP multi-link device (non-AP multi-link device, non-AP MLD).

[0072] The MLD is a device with wireless communication capabilities. The device can be a complete device or a chip or processing system installed in the complete device. The device installed with these chips or processing systems can implement the methods and functions of the embodiments of the present application under the control of these chips or processing systems. The MLD can implement wireless communication according to the 802.11 series of protocols, for example, a station that follows extremely high throughput (EHT), a station based on 802.11be or compatible with 802.11be, or a station based on the next generation protocol of 802.11be, to achieve communication with other devices. Of course, other devices can be multi-link devices or not.

[0073] Illustratively, a non-AP MLD has wireless transceiver capabilities, supports the 802.11 series of protocols, and can communicate with an AP MLD, a single-link device, or another non-AP MLD. For example, a non-AP MLD is any user communication device that allows a user to communicate with an AP and, in turn, a wireless local area network (WLAN). For example, a non-AP MLD can be a tablet computer, desktop, laptop, notebook computer, ultra-mobile personal computer (UMPC), handheld computer, netbook, personal digital assistant (PDA), mobile phone, or other network-capable user device; an IoT node in the Internet of Things (IoT); or an in-vehicle communication device in the Internet of Vehicles (IoV). A non-AP MLD can also be the chip and processing system in these aforementioned terminals.

[0074] Exemplarily, an AP MLD can be a device that provides services to a non-AP MLD and can support the 802.11 series of protocols. For example, the AP MLD can be a communication entity such as a communication server, router, switch, or bridge. Alternatively, the AP MLD can include various forms of macro base stations, micro base stations, and relay stations. Of course, the AP MLD can also be a chip or processing system within these various forms of devices, thereby implementing the methods and functions of the embodiments of the present application. The 802.11 protocol can be a protocol that supports or is compatible with 802.11be.

[0075] In addition, MLD can support high-speed and low-latency transmission. With the continuous evolution of wireless LAN application scenarios, MLD can also be applied to more scenarios, such as sensor nodes in smart cities (for example, smart water meters, smart electricity meters, smart air detection nodes), smart devices in smart homes (for example, smart cameras, projectors, display screens, TVs, speakers, refrigerators, washing machines, etc.), nodes in the Internet of Things, entertainment terminals (for example, wearable devices such as AR and VR), smart devices in smart offices (for example, printers, projectors, etc.), Internet of Vehicles devices in the Internet of Vehicles, and some infrastructure in daily life scenarios (for example, vending machines, self-service navigation counters in supermarkets, self-service cash registers, self-service ordering machines, etc.). The specific forms of non-AP MLD and AP MLD are not limited in the embodiments of this application and are only illustrative.

[0076] In one possible implementation, an MLD may include multiple logical sites, each operating on a link. However, multiple logical sites are permitted to operate on the same link. The MLD may operate in one or more frequency bands, including sub-1 GHz, 2.4 GHz, 5 GHz, 6 GHz, and high-frequency 60 GHz. Furthermore, the MLD may be a single-antenna device or a multi-antenna device. For example, it may be a device with two or more antennas. The embodiments of this application do not limit the number of antennas included in the MLD.

[0077] Generally, before an AP MLD and a non-AP MLD establish multi-link communication, the non-AP MLD can establish associations with multiple links simultaneously by performing a multi-link setup operation on a single link. The link over which association request / response frames are exchanged is called a transmitted link, while the other links are called non-transmitted links. Association request and response frames carry information about multiple links using a multi-link element to enable simultaneous association.

[0078] For example, see Figure 1, which is a schematic diagram of a connection between an AP MLD and a non-AP MLD provided in an embodiment of the present application. As shown in Figure 1, both the non-AP MLD and the AP MLD use a common structure at the high MAC layer. Multiple STAs (such as STA1 and STA2, etc.) in the non-AP MLD are independent of each other at the low MAC layer and the PHY layer, respectively. Multiple APs (such as AP1 and AP2, etc.) in the AP MLD are independent of each other at the low MAC layer and the PHY layer, respectively. In one possible implementation, the high MAC layer primarily performs operations such as the allocation of sequence numbers (SN) and packet numbers (PN) of MSDUs, as well as encryption and decryption. The low MAC layer primarily performs operations such as MPDU assembly, channel access, packet sending, and reception confirmation for each link.

[0079] With reference to Figure 1 , the multi-link establishment process is as follows: the non-AP MLD sends an association request frame carrying a multi-link element on link 1. Link 1 is a transmission link, and link 2 is a non-transmission link. After receiving the association request frame, the AP MLD replies to the non-AP MLD on link 1 with an association response frame carrying a multi-link element. The AP MLD can indicate the success or failure of each link establishment request in the association response frame. The association between the non-AP MLD and the AP MLD is successful only when the transmission link is accepted. For example, as shown in Figure 1 , transmission link 1 is accepted, the non-AP MLD successfully associates with the AP MLD, and link 2 is successfully established. That is, AP1 and STA1 are connected via link 1, and AP2 and STA2 are connected via link 2.

[0080] Generally speaking, an MLD corresponds to a MAC address, and each MLD link corresponds to its own link address. Taking an AP MLD as an example, the MLD address can be the AP MLD's MLD MAC address. Taking a non-AP MLD as an example, the MLD address can be the non-AP MLD's MLD MAC address. The link address between an AP MLD and a non-AP MLD can include the affiliated AP MAC address and affiliated STA MAC address corresponding to both ends of the link. As shown in Figure 1, the link address of link 1 between an AP MLD and a non-AP MLD can include the MAC address of AP1 and the MAC address of STA1; the link address of link 2 can include the MAC address of AP2 and the MAC address of STA2, and so on.

[0081] In a possible implementation, the MLD address may belong to the upper MAC sublayer, and the link address may belong to the lower MAC sublayer.

[0082] 4. SCS Mechanism

[0083] Low latency is an important feature of 802.11be. STA can report a low-latency service flow to AP through the SCS mechanism. This service flow can also be called an SCS flow. The service flow and SCS flow of this application can be used with each other. Specifically, STA can send an SCS request frame (SCS request frame) to the associated AP to report a low-latency service flow and indicate the QoS parameters of the service flow. After receiving the SCS request frame, the AP replies with an SCS response frame (SCS response frame). The SCS response frame can be used to inform the STA: whether the AP accepts the low-latency service flow reported by the STA. The frame structures of the SCS request frame and the SCS response frame are introduced below.

[0084] The frame format of the SCS request frame can be seen in Figure 2. As shown in Figure 2, the SCS request frame includes a category field, a robust action field, a dialog token field, and an SCS descriptor list. The category field indicates the category to which an action frame (such as an SCS request frame) belongs, the robust action field indicates which frame within the category, the dialog token field is used to match corresponding SCS request frames and SCS response frames, and the SCS descriptor list contains one or more SCS descriptors.

[0085] The format of the SCS descriptor can be seen in Figure 3. As shown in Figure 3, the SCS descriptor includes an element identifier (element ID) field, a length (length) field, an SCS identifier (SCS ID) field, a request type (requesttype) field, an intra-access category priority element (optional), a flow classification element (TCLAS element) (optional), a flow allocation processing element (TCLAS Processing element) (optional), a QoS characteristics element (QoS characteristics element) and optional subelements. Specifically:

[0086] 1. The 1-byte element identifier field is used to identify the SCS descriptor element.

[0087] 2. The 1-byte length field is used to indicate the length of the SCS descriptor element.

[0088] 3. The 1-byte SCS identifier field is used to indicate the identifier assigned to the service flow.

[0089] 4. The 1-byte Request Type field indicates the type of request. For example, a Request Type field of 0 indicates an add (ADD), such as adding or requesting to create a service flow; a Request Type field of 1 indicates a remove (remove), such as requesting to remove a service flow; and a Request Type field of 2 indicates a change (change), such as requesting to modify a service flow.

[0090] 5. The format of the internal access category priority element can be seen in Figure 4. As shown in Figure 4, the internal access category priority element includes an element identifier (element ID) field, a length field, and an intra-access priority field. The 1-byte element identifier field is used to identify the internal access category priority element. The 1-byte length field is used to indicate the length of the internal access category priority element. The 1-byte intra-access priority field includes a user priority field, an alternate queue field, a drop eligibility field, and a reserved field. The 3-bit user priority field indicates the user's priority. The 1-bit alternate queue field indicates whether a new alternate queue is established for the service flow. The 1-bit drop eligibility field indicates whether packets of the service flow can be dropped when there are insufficient resources. In Figure 4, bits 0 to 2 are the user priority field, bit 3 is the alternate queue field, bit 4 is the drop eligibility field, and bits 5 to 7 are the reserved field.

[0091] 6. The flow classification element is used to indicate how to identify the service flow. The flow classification element carries the criteria for determining the service flow. The SCS descriptor can carry one or more flow classification elements.

[0092] The format of the flow classification element can be seen in Figure 5. As shown in Figure 5, the flow classification element includes an element identifier (element ID) field, a length (length) field, a user priority (user priority) field, and a frame classifier type (frameclassifier) ​​field. Specifically:

[0093] (1) The 1-byte element identifier field is used to identify the flow classification element.

[0094] (2) The 1-byte length field is used to indicate the length of the flow classification element.

[0095] (3) The 1-byte user priority field is used to indicate the user priority. When multiple elements include the user priority field, the stream classification element generally prevails. The value of the user priority field can be 0 to 11. For example, in Table 1, the value of the user priority field is 0-7, indicating the priority of an MSDU (the user priority value of an MDSU). The value of the user priority field is 8, indicating that the MSDU access category (AC) is AC_VO (the AC value of an MDSU is AC_VO). The value of the user priority field is 9, indicating that the MSDU access category is AC_VI (the AC value of an MDSU is AC_VI). The value of the user priority field is 10, indicating that the MSDU access category is AC_BE (the AC value of an MDSU is AC_BE). The value of the user priority field is 11, indicating that the MSDU access category is AC_BK (the AC value of an MDSU is AC_BK). AC_VO indicates that the access type is voice flow, AC_VI indicates that the access type is video flow, AC_BE indicates that the access type is best effort flow, and AC_BK indicates that the access type is background flow.

[0096] Table 1 User priority field in the flow classification element

[0097] (4) The byte length of the frame classifier type field is variable. The format of the frame classifier type field can be seen in Figure 6. As shown in Figure 6, the frame classifier type field includes the classifier type subfield, the classifier mask subfield, and the classifier parameters subfield. Specifically:

[0098] ①. The value of the 1-byte classifier type subfield can be 0-255. Different values ​​result in different contents indicated by the classifier parameters subfield. For example, in Table 2, the value of the classifier type subfield is 0, indicating Ethernet parameters. The value of the classifier type subfield is 1, indicating Transmission Control Protocol (TCP) / User Datagram Protocol (UDP) Internet Protocol (IP) parameters (TCP / UDP IP parameters). The value of the classifier type subfield is 2, indicating Institute of Electrical and Electronics Engineers (IEEE) 802.1Q-2003 parameters (IEEE802.1Q-2003 parameters) (deprecated). The value of the classifier type subfield is 3, indicating filter offset parameters. The value of the classifier type subfield is 4, indicating IP and higher layer parameters. A Classifier Type subfield value of 5 indicates IEEE 802.1Q parameters. A Classifier Type subfield value of 6 indicates IEEE 802.11 MAC header parameters. A Classifier Type subfield value of 7 indicates IEEE Standard 802.11 downlink PV1 MPDU MAC header parameters, e.g., a value of 1 for the From DS field of the frame control field indicates IEEE Standard 802.11 downlink PV1 MPDU MAC header parameters. A Classifier Type subfield value of 8 indicates IEEE Standard 802.11 nondownlink PV1 MPDU MAC header parameters.For example, a value equal to 0 in the From DS field of the frame control field indicates IEEE Standard 802.11 non-downstream PV1 MPDU MAC header parameters. A value equal to 9 in the Classifier Type subfield indicates IEEE Standard 802.11 PV1 MDSU full address MAC header parameters. A value equal to 10 in the Classifier Type subfield indicates IP extensions and higher layer parameters. Bits 11-255 are reserved.

[0099] Table 2 Frame Classifier Type (frameclassifiertype) field

[0100] ②. The 1-byte or 3-byte classifier mask subfield contains a string of 2-bit classifier mask control subfields. The first bit (i.e., the leftmost bit or the least significant bit (LSB)) is used to indicate whether the corresponding field is used for comparison and matching; the second bit (i.e., the rightmost bit or the most significant bit (MSB)) is used to indicate whether the corresponding matching rule appears.

[0101] ③. The byte length of the classifier parameter subfield is variable. The following is a detailed description of the classifier parameter subfield when the value of the classifier type subfield is 6. Specifically, the contents of byte indexes 0 to 2 in the classifier mask subfield are shown in Table 3. For ease of understanding, the byte index of 0 in the classifier mask subfield is used as an example. Assume that the byte with byte index 0 is called the first byte. When the bit index in the first byte is B1B0, it indicates frame control; when the bit index in the first byte is B3B2, it indicates duration or identification; when the bit index in the first byte is B5B4, it indicates address 1; when the bit index in the first byte is B7B6, it indicates address 2.

[0102] Table 3 Classifier Mask Subfield when the Classifier Type Subfield Value is 6 (classifiermaskforclassifiertype 6)

[0103] In a possible implementation, when the value of the classifier type subfield is 0 or 6, the format of the frame classifier type field may be different from that in FIG6 . Specifically:

[0104] First, when the value of the classifier type subfield is 0, the format of the frame classifier type field can refer to Figure 7. As shown in Figure 7, the frame classifier type field includes a 1-byte classifier type subfield (the value of the classifier type subfield is 0), a 1-byte classifier mask subfield, a 6-byte source address subfield, a 6-byte destination address subfield, and a 2-byte type subfield.

[0105] The source address subfield is used to indicate the source address of the service flow, the destination address subfield is used to indicate the destination address of the service flow, and the type subfield is used to indicate the type of the upper layer protocol carried.

[0106] Second, when the value of the classifier type subfield is 6, the format of the frame classifier type field can refer to Figure 8. As shown in FIG8 , the frame classifier type field includes a 1-byte classifier type subfield (the value of the classifier type subfield is 6), a 3-byte classifier mask subfield, a 0-byte, 2-byte, or 4-byte frame control match specification subfield, a 0-byte, 2-byte, or 4-byte duration match specification subfield, a 0-byte, 6-byte, or 12-byte address 1 match specification subfield, a 0-byte, 6-byte, or 12-byte address 2 match specification subfield, a 0-byte, 6-byte, or 12-byte address 3 match specification subfield, a 0-byte, 2-byte, or 4-byte sequence match specification subfield, a 0-byte, 6-byte, or 12-byte address 4 specification subfield, a 0-byte, 2-byte, or 4-byte QoS control specification subfield, and a 0-byte, 4-byte, or 8-byte high throughput control rule (HT control) subfield. specification) subfield.

[0107] A byte of 0 indicates that there is no corresponding field. For example, if the byte of the Frame Control Matching Rule subfield is 0, it means that the Frame Classifier Type field does not carry the Frame Control Matching Rule subfield.

[0108] 7. The flow classification processing element is used to indicate how to process multiple flow classification elements when there are multiple flow classification elements.

[0109] 8. The QoS feature element indicates the TID mapped to the corresponding service flow and the corresponding QoS parameters. The two most important QoS parameters are the delay bound, which indicates the maximum delay allowed for low-latency packets, and the packet delivery ratio, which indicates the required packet delivery ratio under a given delay bound.

[0110] The format of the QoS feature element can be seen in Figure 9. As shown in Figure 9, the QoS feature element includes an element identifier (element ID) field, a length field, an element ID extension field, a control information field, a minimum service interval field, a maximum service interval field, a minimum data rate field, a latency limit field, a maximum MAC service data unit size field, a service start time field, a mean data rate field, a burst size field, a MAC service data unit lifetime field, a MAC service data unit delivery rate field, a MAC service data unit count exponent field, a medium time field, and a bandwidth field. Specifically:

[0111] (1) The 1-byte element identifier field and the 1-byte extended element identifier field are used to identify the QoS feature element.

[0112] (2) The 1-byte length field is used to indicate the length of the QoS feature element.

[0113] (3) The format of the 4-byte control information field can be seen in Figure 10. As shown in Figure 10, the control information field includes a direction field, a service identifier (TID) field, a user priority field, a presence bitmap of additional parameters field, a link identifier (link ID) field, and a reserved field. The 2-byte direction field is used to indicate the transmission direction. For example, the direction field is set to 00 for uplink; the direction field is set to 10 for downlink; the direction field is set to 01 for a direct link (peertopeer, P2P); and 11 is a reserved value. The value of the 4-byte service identifier field can be 0 to 7, and 8 to 15 are reserved values. The value of the 3-byte user priority field can be 0 to 7, and is set to the same value as the service identifier field. The presence bitmap of additional parameters field is used to indicate whether other parameters appear starting from the maximum MSDU length field. The link identifier field is used to indicate the link identifier corresponding to the direct link transmission.

[0114] (4) The 4-byte minimum service interval field is used to indicate the minimum interval between two consecutive service periods.

[0115] (5) The 4-byte Maximum Service Interval field is used to indicate the maximum interval between two consecutive service periods.

[0116] (6) The 3-byte minimum data rate field is used to indicate the minimum data rate required by the described service flow.

[0117] (7) The 3-byte delay limit field is used to indicate the maximum delay allowed for the data packets of the described service flow.

[0118] (8) The maximum MSDU length field of 0 bytes or 2 bytes is used to indicate the maximum MSDU length of the data packet of the described service flow.

[0119] (9) The service start time field of 0 bytes or 4 bytes is used to indicate the start time of the first service period of the described service flow.

[0120] (10), 0 bytes or 3 bytes of the average data rate field is used to indicate the average data rate required by the described service flow.

[0121] (11) The burst size field of 0 or 4 bytes is used to indicate the maximum possible peak traffic volume of the described traffic flow.

[0122] (12) The MSDU lifetime field of 0 or 2 bytes is used to indicate the lifetime of the data packet of the described service flow.

[0123] (13) The MSDU delivery rate field of 0 or 1 byte is used to indicate the required MSDU delivery rate under the given delay upper limit requirement.

[0124] (14) The MSDU Number Index field of 0 or 1 byte is used to indicate the number of reference MSDUs used to calculate the MSDU delivery rate.

[0125] (15) The media time field of 0 or 1 byte is used to indicate the media time requested by the described service flow.

[0126] (16) The bandwidth field of 0 or 1 byte is used to indicate the bandwidth size requested by the described service flow.

[0127] The frame format of the SCS response frame can be seen in Figure 11. As shown in Figure 11, the SCS response frame includes a category field, a robust action field, a dialog token field, a count field, an SCS status list, and an SCS descriptor list. The category field indicates the category to which the action frame (e.g., the SCS response frame) belongs, and the robust action field indicates which frame within that category. The dialog token field in the SCS response frame must be consistent with the dialog token field in the corresponding SCS request frame. The count field indicates the number of SCSID subfields and status code subfields in the SCS status list. The SCS status list contains one or more SCS status groups, each of which is indicated by two subfields: a SCSID subfield indicating the service flow identifier; and a status code subfield indicating whether the request corresponding to the SCSID is accepted. The SCS descriptor list contains one or more SCS descriptors.

[0128] The following describes the system architecture and business scenarios of the embodiment of the present application using Figure 12 as an example. It should be noted that the system architecture and business scenarios described in this application are intended to more clearly illustrate the technical solutions of this application and do not constitute a limitation on the technical solutions provided by this application. It is known to those skilled in the art that with the evolution of the system architecture and the emergence of new business scenarios, the technical solutions provided by this application are also applicable to similar technical problems.

[0129] As shown in Figure 12, the communication system includes a first device 1200, and a second device 1201 and a third device 1202 that communicate with the first device 1200. In one possible implementation, the second device 1201 can also communicate with the third device 1202. In this embodiment of the present application, the term "communication" can also be described as "data transmission," "information transmission," or "transmission." The term "transmission" can generally refer to both sending and receiving.

[0130] It should be noted that the number of each device in Figure 12 is only for illustration and should not be considered as a specific limitation of the present application.

[0131] 1. First Equipment

[0132] The first device may be a device that supports a QoS parameter reporting mechanism. In one possible implementation, the QoS parameter reporting mechanism mentioned in this application may refer to, for example, a non-APMLD or STA reporting QoS parameters to an APMLD. Furthermore, the first device may also support an SCS mechanism.

[0133] For example, the first device may be an AP MLD or the like.

[0134] This application does not limit the form of the first device. The device used to implement the function of the first device can be the first device; it can also be a device that supports the first device to implement the function, such as a chip system. The device can be installed in the first device or used in conjunction with the first device.

[0135] 2. Second Device

[0136] The second device may support QoS parameter reporting. This may also be described as: the second device supports proxy QoS parameter reporting, the second device supports a QoS parameter reporting mechanism, or the second device supports a proxy QoS parameter reporting mechanism. Furthermore, the second device may support the SCS mechanism. For example, the second device may be a non-APMLD. In this case, the non-APMLD may also be referred to as an ultra-high reliability (UHR) non-APMLD.

[0137] This application does not limit the form of the second device. The device used to implement the function of the second device can be the second device; it can also be a device that supports the second device to implement the function, such as a chip system. The device can be installed in the second device or used in conjunction with the second device.

[0138] 3. Third Equipment

[0139] The third device may or may not support QoS parameter reporting. Alternatively, the third device may support or not support the QoS parameter reporting mechanism. Furthermore, the third device may support the SCS mechanism. For example, the third device may be a non-APMLD or a STA. The STA may be a legacy STA or a pre-EHT STA.

[0140] In a possible implementation, when the third device is a device that supports QoS parameter reporting, the third device may be a non-APMLD. For example, the non-APMLD may be called an EHT non-APMLD or a UHR non-APMLD.

[0141] In a possible implementation, when the third device is a device that does not support QoS parameter reporting, the third device may be a legacy STA or a Pre-EHT STA.

[0142] This application does not limit the form of the third device. The device used to implement the function of the third device can be the third device; it can also be a device that supports the third device to implement the function, such as a chip system. The device can be installed in the third device or used in conjunction with the third device.

[0143] The following is a detailed description of the specific solutions involved in the embodiments of the present application. It should be noted that the message names between the devices or the names of the parameters in the messages in the following embodiments are only examples, and other names can also be used in specific implementations. The embodiments of the present application do not specifically limit this.

[0144] As shown in FIG13 , a communication method is provided in an embodiment of the present application, which includes but is not limited to the following steps:

[0145] 1301. The second device generates an SCS request frame, where the SCS request frame includes QoS parameters of the service flow and identification information of the second device and identification information of the third device.

[0146] Among them, the frame format of the SCS request frame can refer to the description of Figures 2 to 10 above, and will not be repeated here.

[0147] 1302. The second device sends an SCS request frame to the first device.

[0148] Accordingly, the first device receives the SCS request frame from the second device. In one possible implementation, the first device may also send an SCS response frame to the second device, where the SCS response frame is used to indicate that the service flow has been accepted. The frame format of the SCS response frame can be found in the description of FIG. 11 above and will not be repeated here.

[0149] 1303. The first device schedules the service flow between the second device and the third device based on the SCS request frame.

[0150] The specific implementation of steps 1301 to 1303 is described below.

[0151] The SCS request frame includes the QoS parameters of the service flow. One possible implementation may be that the QoS characteristics element in the SCS request frame includes the QoS parameters of the service flow. In one possible implementation, the QoS parameters of the service flow may include a minimum serving interval and / or a maximum serving interval. For example, the minimum serving interval field and the maximum serving interval field in the QoS characteristics element are used to indicate the minimum serving interval and the maximum serving interval, respectively.

[0152] In one possible implementation, the QoS parameters of a service flow may include an uplink QoS parameter of the service flow or a downlink QoS parameter of the service flow. In one possible implementation, the service flow may meet the uplink QoS parameter or the downlink QoS parameter. In another possible implementation, the service flow may not meet the uplink QoS parameter or the downlink QoS parameter. In this case, it can be considered that there is a deviation between the QoS parameter met by the service flow and the uplink QoS parameter or the downlink QoS parameter. This application does not limit the specific size of the deviation.

[0153] The uplink QoS parameters of the service flow can refer to the uplink QoS parameters of the service flow on the second device. Alternatively, they can be described as the QoS parameters of the second device for the uplink transmission of the service flow. For example, the Direction field in the QoS Feature element is set to 00, indicating uplink. Thus, the Direction field indicates that the QoS parameters of the service flow are uplink QoS parameters.

[0154] The downlink QoS parameters of a service flow can refer to the downlink QoS parameters of the service flow on the second device. Alternatively, they can be described as the QoS parameters of the second device for the downlink transmission of the service flow. For example, the Direction field in the QoS Features element is set to 10, indicating downlink. Thus, the Direction field indicates that the QoS parameters of the service flow are downlink QoS parameters.

[0155] The SCS request frame includes the identification information of the second device and the identification information of the third device. This can be understood as follows: the flow classification element in the SCS request frame includes the identification information of the second device and the identification information of the third device. In one possible embodiment, the identification information of the second device and the identification information of the third device can be used by the first device to determine that the second device and the third device are both associated with the first device. Furthermore, the identification information of the second device and the identification information of the third device can also be used by the first device to determine that the aforementioned service flow is a service flow between the second device and the third device.

[0156] In the present application, when the first device is an APMLD and the third device is a Pre-EHT STA, the third device associating with the first device can be understood as: the third device associating with the subordinate AP of the first device.

[0157] In one possible implementation, the identification information of the second device may be the MAC address of the second device, such as the MLD MAC address of a non-APMLD. The identification information of the third device may be the MAC address of the third device, such as the MAC address of a pre-EHT STA, the MAC address of a legacy STA, or the MLD MAC address of a non-APMLD.

[0158] In one possible implementation, the source address information of the service flow may be the identification information of the second device, and the destination address information of the service flow may be the identification information of the third device. For example, when the second device performs uplink transmission for the service flow, the source address information of the service flow may be the identification information of the second device, and the destination address information of the service flow may be the identification information of the third device.

[0159] In another possible implementation, the source address information of the service flow may be identification information of a third device, and the destination address information of the service flow may be identification information of a second device. For example, when the second device performs downlink transmission for the service flow, the source address information of the service flow may be identification information of the second device, and the destination address information of the service flow may be identification information of the third device.

[0160] The source address information of the service flow may be indicated by, for example, the source address subfield in FIG. 7 , and the destination address information of the service flow may be indicated by, for example, the destination address subfield in FIG. 7 .

[0161] In a possible implementation, the SCS request frame may further include indication information, or the SCS request frame may not include the indication information. The indication information is used to instruct the first device to schedule the service flow between the second device and the third device based on the QoS parameters of the service flow. Specifically:

[0162] 1. The QoS parameters of the service flow include uplink QoS parameters of the service flow. The indication information is used to instruct the first device to schedule uplink transmission of the service flow on the second device and downlink transmission on the third device based on the uplink QoS parameters of the service flow.

[0163] In a possible implementation, the deviation between the uplink QoS parameters of the service flow (i.e., the uplink QoS parameters of the service flow on the second device) and the downlink QoS parameters of the service flow on the third device is within a certain range, such as the interval deviation between the minimum service interval of the service flow on the second device and the minimum service interval of the service flow on the third device is within the first interval range, and / or the interval deviation between the maximum service interval of the service flow on the second device and the maximum service interval of the service flow on the third device is within the second interval range. The second device may consider that the uplink QoS parameters of the service flow on the second device are the same as the downlink QoS parameters of the service flow on the third device. In this case, the uplink QoS parameters of the service flow can also be understood as: end-to-end QoS parameters. For example, including the uplink QoS parameters of the service flow on the second device and the downlink QoS parameters of the service flow on the third device. That is to say, the second device does not need to report the uplink QoS parameters of the service flow on the second device and the downlink QoS parameters of the service flow on the third device separately in two reports.

[0164] In a possible implementation, the second device may obtain the downlink QoS parameters of the service flow on the third device through the application layer and / or the network layer, and the specific process is not limited here.

[0165] The first interval range and the second interval range may be the same or different. It should be noted that the interval range mentioned in this application may be predefined or preconfigured, or indicated by the first device to the second device, or by the third device to the second device. Optionally, the interval range may include an interval determined by a maximum interval and a minimum interval, and the interval range may also include or exclude boundary points, such as the maximum interval and / or the minimum interval.

[0166] 2. The QoS parameters of the service flow include downlink QoS parameters of the service flow. The indication information is used to instruct the first device to schedule downlink transmission of the service flow on the second device and uplink transmission on the third device based on the downlink QoS parameters of the service flow.

[0167] In a possible implementation, the deviation between the downlink QoS parameters of the service flow (i.e., the downlink QoS parameters of the service flow on the second device) and the uplink QoS parameters of the service flow on the third device is within a certain range, such as, the interval deviation between the minimum service interval of the service flow on the second device and the minimum service interval of the service flow on the third device is within the third interval range, and / or, the interval deviation between the maximum service interval of the service flow on the second device and the maximum service interval of the service flow on the third device is within the fourth interval range. The second device may consider that the downlink QoS parameters of the service flow on the second device are the same as the uplink QoS parameters of the service flow on the third device. In this case, the downlink QoS parameters of the service flow can also be understood as: end-to-end QoS parameters. For example, including the downlink QoS parameters of the service flow on the second device and the uplink QoS parameters of the service flow on the third device. That is to say, the second device does not need to report the downlink QoS parameters of the service flow on the second device and the uplink QoS parameters of the service flow on the third device separately in two reports.

[0168] In a possible implementation, the second device may obtain the uplink QoS parameters of the service flow on the third device through the application layer and / or the network layer, and the specific process is not limited here.

[0169] The third interval range and the fourth interval range may be the same or different.

[0170] It should be pointed out that, in addition to the above-mentioned scheme 1 in which "the second device considers that the uplink QoS parameters of the service flow on the second device are the same as the downlink QoS parameters of the service flow on the third device" and the scheme 2 in which "the second device considers that the downlink QoS parameters of the service flow on the second device are the same as the uplink QoS parameters of the service flow on the third device", the second device can also learn through other methods that the uplink QoS parameters of the service flow on the second device are the same as the downlink QoS parameters of the service flow on the third device, and / or, the downlink QoS parameters of the service flow on the second device are the same as the uplink QoS parameters of the service flow on the third device. For example, if the time deviation between the service start time of the second device and the service start time of the third device is within a certain time range, the second device can also consider that the uplink QoS parameters of the service flow on the second device are the same as the downlink QoS parameters of the service flow on the third device, and / or, the downlink QoS parameters of the service flow on the second device are the same as the uplink QoS parameters of the service flow on the third device.

[0171] In one possible implementation, the indication information may be carried in the control information field of the QoS feature element. The indication information may be a newly added bit, a newly added field, or a reserved field in the control information field, and is not limited here. For example, the indication information may be at least one bit, and the specific number of bits is not limited. For example, the indication information may be 1 bit, with a value of 0 or 1, and the indication information is used to instruct the first device to schedule the service flow between the second device and the third device based on the QoS parameters of the service flow.

[0172] In one possible implementation, the present application may refer to the indication information as proxy QoS enable. In this case, the indication information is used to instruct the first device to schedule the service flow between the second device and the third device based on the QoS parameters of the service flow, which can also be described as enabling QoS proxy, etc. For example, when the second device learns that it and the third device are both associated with the first device, QoS proxy can be enabled. The specific process by which the second device learns that the third device is also associated with the first device is not detailed here.

[0173] In the case where the SCS request frame includes indication information, step 1303 may include: the first device scheduling the service flow between the second device and the third device based on the indication information and the QoS parameters of the service flow. For example, the QoS parameters of the service flow include the uplink QoS parameters of the service flow, and the first device can schedule the uplink transmission of the service flow on the second device and the downlink transmission of the third device based on the uplink QoS parameters of the service flow. For example, the QoS parameters of the service flow include the downlink QoS parameters of the service flow, and the first device can schedule the downlink transmission of the service flow on the second device and the uplink transmission of the third device based on the downlink QoS parameters of the service flow. This method of displaying indications is more flexible.

[0174] In the case where the SCS request frame does not include indication information, step 1303 may include: the first device schedules the service flow between the second device and the third device based on the QoS parameters of the service flow. For example, in the case where the first device knows that the second device and the third device are both associated with the first device through the identification information of the second device and the identification information of the third device, the first device may schedule the service flow between the second device and the third device based on the QoS parameters of the service flow. For example, the QoS parameters of the service flow include the uplink QoS parameters of the service flow, and the first device may schedule the uplink transmission of the service flow on the second device and the downlink transmission of the third device based on the uplink QoS parameters of the service flow. For example, the QoS parameters of the service flow include the downlink QoS parameters of the service flow, and the first device may schedule the downlink transmission of the service flow on the second device and the uplink transmission of the third device based on the downlink QoS parameters of the service flow. This implicit indication method can save signaling overhead.

[0175] It can be seen that in the above embodiment, the first device can schedule the service flow between the second device and the third device based on the SCS request frame from the second device, so that the first device does not need to receive SCS request frames from the second device and the third device multiple times to schedule the transmission of the service flow on the second device and the third device respectively based on multiple SCS request frames. For example, the first device first receives an SCS request frame from the second device (the SCS request frame is used to schedule the uplink transmission of the service flow on the second device), and then receives another SCS request frame from the third device (the SCS request frame is used to schedule the downlink transmission of the service flow on the third device). Then, the first device receives an SCS request frame from the second device (the SCS request frame is used to schedule the uplink transmission of the service flow on the second device), and finally receives another SCS request frame from the third device (the SCS request frame is used to schedule the downlink transmission of the service flow on the third device). In this way, signaling overhead can be saved. At the same time, end-to-end QoS is guaranteed and user experience is improved.

[0176] It is understood that in the embodiment shown in FIG. 13 , when the QoS parameters of the service flow included in the SCS request frame are uplink QoS parameters, the SCS request frame may still include a flow classification element. This simplifies signaling, helps the first device ensure that the service is directed to the corresponding TID, and ensures consistency in QoS management policies across all sites within the BSS, thereby enabling better management and scheduling of service transmission across the entire BSS.

[0177] In one possible implementation, the address field corresponding to the frame classifier type field in the ADD of the MPDU in a multi-link scenario may be the corresponding MLD address. For example, the source address subfield and the destination address subfield in FIG7 may be the MLD MAC addresses of two non-AP MLDs, respectively.

[0178] Among them, ADD can be indicated by the request type field in Figure 3.

[0179] In one possible implementation, when the value of the frame classifier type field is 6 in a multi-link scenario, the corresponding address field can be a corresponding MLD address. For example, at least one of the address 1 matching rule subfield, the address 2 matching rule subfield, and the address 3 matching rule subfield in Figure 8 can be an MLD address. Furthermore, in this case, the frame classifier can be deployed on a low MAC address.

[0180] It is understandable that, in order to realize the above functions, the above-mentioned devices include hardware structures and / or software modules 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 present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware 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.

[0181] In the embodiments of the present application, the first device or the second device can be divided into functional modules according to the above method examples. 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 software functional modules. It should be noted that the division of modules in the embodiments of the present application is schematic and is only a logical functional division. In actual implementation, other division methods may be used.

[0182] Refer to Figure 14, which is a structural diagram of a communication device provided in an embodiment of the present application. The communication device 1400 can be applied to the method shown in any of the embodiments in Figure 13 above. As shown in Figure 14, the communication device 1400 includes: a processing module 1401 and a transceiver module 1402. The processing module 1401 can be one or more processors, and the transceiver module 1402 can be a transceiver or a communication interface. The communication device can be used to implement the first device or the second device involved in any of the above method embodiments, or to implement the functions of the network element involved in any of the above method embodiments. The network element or network function can be a network element in a hardware device, a software function running on dedicated hardware, or a virtualization function instantiated on a platform (for example, a cloud platform). Optionally, the communication device 1400 can also include a storage module 1403 for storing program code and data of the communication device 1400.

[0183] In one embodiment, when the communication device serves as a first device or a chip used in a first device, and executes the steps performed by the first device in the above-described method embodiments, the transceiver module 1402 is configured to specifically execute the sending and / or receiving actions performed by the first device in any embodiment of FIG. 13 , for example, to support the first device in executing other processes of the technology described herein. The processing module 1401 may be configured to support the communication device 1400 in executing the processing actions in the above-described method embodiments, for example, to support the first device in executing other processes of the technology described herein.

[0184] Exemplarily, the transceiver module 1402 is used to receive an SCS request frame from the second device, where the SCS request frame includes QoS parameters of the service flow, and the SCS request frame also includes identification information of the second device and identification information of the third device; the processing module 1401 is used to schedule the service flow between the second device and the third device based on the SCS request frame.

[0185] In one possible implementation, the SCS request frame also includes indication information. When scheduling the service flow between the second device and the third device based on the SCS request frame, the processing module 1401 is used to schedule the service flow between the second device and the third device based on the indication information and the QoS parameters of the service flow.

[0186] In one possible embodiment, when scheduling a service flow between a second device and a third device based on an SCS request frame, the processing module 1401 is used to: the QoS parameters of the service flow include the uplink QoS parameters of the service flow, and the service flow is scheduled for uplink transmission on the second device and downlink transmission on the third device based on the SCS request frame; and / or, the QoS parameters of the service flow include the downlink QoS parameters of the service flow, and the service flow is scheduled for downlink transmission on the second device and uplink transmission on the third device based on the SCS request frame.

[0187] In a possible implementation, the processing module 1401 is further configured to determine, based on the identification information of the second device and the identification information of the third device, that both the second device and the third device are associated with the first device.

[0188] In a possible implementation, the transceiver module 1402 is further configured to send an SCS response frame to the second device, where the SCS response frame is used to indicate that the service flow is accepted.

[0189] In one embodiment, when the communication device serves as a second device or a chip used in a second device, and executes the steps performed by the second device in the above-mentioned method embodiments, the transceiver module 1402 is used to specifically execute the sending and / or receiving actions performed by the second device in any embodiment of Figure 13, for example, to support the second device in executing other processes of the technology described herein. The processing module 1401 can be used to support the communication device 1400 in executing the processing actions in the above-mentioned method embodiments, for example, to support the second device in executing other processes of the technology described herein.

[0190] Exemplarily, the processing module 1401 is used to generate an SCS request frame, which includes QoS parameters of the service flow, and the SCS request frame also includes identification information of the second device and identification information of the third device; the transceiver module 1402 is used to send the SCS request frame to the first device, and the SCS request frame is used by the first device to schedule the service flow between the second device and the third device.

[0191] In a possible implementation, the transceiver module 1402 is further configured to receive an SCS response frame from the first device, where the SCS response frame is used to indicate that the service flow is accepted.

[0192] In one possible embodiment, when the first device or the second device is a chip, the transceiver module 1402 can be a communication interface, a pin, or a circuit. The communication interface can be used to input data to be processed into the processor and can output the processing results of the processor. In a specific implementation, the communication interface can be a general purpose input and output (GPIO) interface that can be connected to multiple peripheral devices (such as a display (LCD), a camera, a radio frequency (RF) module, an antenna, etc.). The communication interface is connected to the processor via a bus.

[0193] Processing module 1401 may be a processor that can execute computer-executable instructions stored in the storage module to cause the chip to perform the method described in any of the embodiments shown in FIG13 . Furthermore, the processor may include a controller, an arithmetic unit, and registers. For example, the controller is primarily responsible for decoding instructions and issuing control signals for operations corresponding to the instructions. The arithmetic unit is primarily responsible for performing fixed-point or floating-point arithmetic operations, shift operations, and logical operations, and may also perform address operations and conversions. The registers are primarily responsible for storing register operands and intermediate operation results temporarily stored during instruction execution. In a specific implementation, the processor's hardware architecture may be an ASIC architecture, a microprocessor without interlocked piped stages architecture (MIPS) architecture, an advanced RISC machine (ARM) architecture, or a network processor (NP) architecture, among others. The processor may be single-core or multi-core. The storage module may be a memory module within the chip, such as a register or cache. The storage module may also be a storage module located outside the chip, such as a ROM or other types of static storage devices that can store static information and instructions, RAM, etc.

[0194] It should be noted that the functions corresponding to the processor and the interface can be implemented through hardware design, software design, or a combination of hardware and software, and there is no limitation here.

[0195] Figure 15 is a schematic diagram of the structure of another communication device provided in an embodiment of the present application. It is understandable that the communication device 1510 includes necessary means such as modules, units, elements, circuits, or interfaces, which are appropriately configured together to implement this solution. The communication device 1510 can be the above-mentioned first device or second device, or a component (such as a chip) in these devices, used to implement the method described in the above-mentioned method embodiment. The communication device 1510 includes one or more processors 1511. The processor 1511 can be a general-purpose processor or a dedicated processor, etc. For example, it can be a baseband processor or a central processing unit. The baseband processor can be used to process communication protocols and communication data, and the central processing unit can be used to control the communication device (such as the first device, the second device, or the chip, etc.), execute software programs, and process data of software programs.

[0196] Optionally, in one design, the processor 1511 may include a program 1513 (sometimes also referred to as code or instructions), which may be executed on the processor 1511 so that the communication device 1510 performs the method described in the above embodiment. In another possible design, the communication device 1510 includes a circuit (not shown in FIG15 ), which is used to implement the functions of the first device, the second device, and the like in the above embodiment. Optionally, the communication device 1510 may include one or more memories 1512 on which a program 1514 (sometimes also referred to as code or instructions) is stored, which may be executed on the processor 1511 so that the communication device 1510 performs the method described in the above method embodiment.

[0197] Optionally, data may also be stored in the processor 1511 and / or the memory 1512. The processor and the memory may be provided separately or integrated together.

[0198] Optionally, the communication device 1510 may further include a transceiver 1515 and / or an antenna 1516. The processor 1511 may also be sometimes referred to as a processing unit, and controls the communication device (e.g., the first device or the second device). The transceiver 1515 may also be sometimes referred to as a transceiver unit, a transceiver, a transceiver circuit, or a transceiver, and is configured to implement the transceiver function of the communication device through the antenna 1516.

[0199] An embodiment of the present application further provides a communication device, comprising at least one processor; wherein the at least one processor is configured to execute any of the methods described in any of the embodiments in FIG. 13 .

[0200] An embodiment of the present application further provides a computer-readable storage medium, which stores computer instructions. When the computer instructions are executed, the computer executes any method as described in any embodiment of FIG. 13 .

[0201] An embodiment of the present application further provides a computer program product, which includes: a computer program code, and when the computer program code is executed by a computer, the computer executes any of the methods described in any of the embodiments in FIG13 .

[0202] An embodiment of the present application also provides a chip, which includes at least one processor and an interface. The processor is used to read and execute instructions stored in a memory. When the instructions are executed, the chip executes any method as described in any embodiment of Figure 13.

[0203] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed across multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the embodiments of the present application. In addition, the network element units in the various embodiments of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated units may be implemented in the form of hardware or in the form of software network element units.

[0204] If the above-mentioned integrated unit is implemented in the form of a software network element unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the part that essentially contributes to the technical solution of the present application, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a first device, a cloud server, or a second device, etc.) to execute all or part of the steps of the above-mentioned methods of each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program code.

Claims

1. A communication method, characterized in that: include: The first device receives a flow classification service SCS request frame from the second device, where the SCS request frame includes a quality of service QoS parameter of the service flow, and the SCS request frame also includes identification information of the second device and identification information of the third device; The first device schedules the service flow between the second device and the third device based on the SCS request frame.

2. The method according to claim 1, characterized in that The SCS request frame further includes indication information, and the first device schedules the service flow between the second device and the third device based on the SCS request frame, including: The first device schedules the service flow between the second device and the third device based on the indication information and the QoS parameter of the service flow.

3. The method according to claim 1 or 2, characterized in that: The first device scheduling the service flow between the second device and the third device based on the SCS request frame, comprising: The QoS parameters of the service flow include uplink QoS parameters of the service flow, and the first device schedules uplink transmission of the service flow on the second device and downlink transmission of the third device based on the SCS request frame; and / or, The QoS parameters of the service flow include downlink QoS parameters of the service flow, and the first device schedules downlink transmission of the service flow on the second device and uplink transmission on the third device based on the SCS request frame.

4. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: The first device determines, based on the identification information of the second device and the identification information of the third device, that the second device and the third device are both associated with the first device.

5. The method according to any one of claims 1 to 4, characterized in that: The first device is an access point multi-link device, the second device is a non-access point multi-link device, and the third device is a non-access point multi-link device or a device that does not support QoS parameter reporting.

6. The method according to any one of claims 1 to 5, characterized in that: The identification information of the second device is a media access control MAC address of the second device, and the identification information of the third device is a MAC address of the third device; The source address information of the service flow is the identification information of the second device, and the destination address information of the service flow is the identification information of the third device; or, The source address information of the service flow is the identification information of the third device, and the destination address information of the service flow is the identification information of the second device.

7. The method according to claim 2, characterized in that The indication information is carried in the QoS feature element of the SCS request frame.

8. The method according to any one of claims 1 to 7, characterized in that: The identification information of the second device and the identification information of the third device are carried in the flow classification element of the SCS request frame.

9. The method according to any one of claims 1 to 8, characterized in that: The QoS parameters of the service flow include a minimum service interval and / or a maximum service interval.

10. The method according to any one of claims 1 to 9, characterized in that: The method further comprises: The first device sends an SCS response frame to the second device, where the SCS response frame is used to indicate that the service flow is accepted.

11. A communication method, characterized in that: include: The second device generates a flow classification service SCS request frame, wherein the SCS request frame includes a quality of service QoS parameter of the service flow, and the SCS request frame also includes identification information of the second device and identification information of the third device; The second device sends the SCS request frame to the first device, where the SCS request frame is used by the first device to schedule the service flow between the second device and the third device.

12. The method according to claim 11, characterized in that The SCS request frame also includes indication information, and the indication information and the QoS parameters of the service flow are used by the first device to schedule the service flow between the second device and the third device.

13. The method according to claim 11 or 12, characterized in that: The QoS parameters of the service flow include uplink QoS parameters of the service flow, and the QoS parameters of the service flow are used by the first device to schedule uplink transmission of the service flow on the second device and downlink transmission on the third device; and / or, The QoS parameters of the service flow include downlink QoS parameters of the service flow, and the QoS parameters of the service flow are used by the first device to schedule downlink transmission of the service flow on the second device and uplink transmission on the third device.

14. The method according to any one of claims 11 to 13, characterized in that: The first device is an access point multi-link device, the second device is a non-access point multi-link device, and the third device is a non-access point multi-link device or a device that does not support QoS parameter reporting.

15. The method according to any one of claims 11 to 14, characterized in that: The identification information of the second device is a media access control MAC address of the second device, and the identification information of the third device is a MAC address of the third device; The source address information of the service flow is the identification information of the second device, and the destination address information of the service flow is the identification information of the third device; or, The source address information of the service flow is the identification information of the third device, and the destination address information of the service flow is the identification information of the second device.

16. The method according to claim 12, characterized in that The indication information is carried in the QoS feature element of the SCS request frame.

17. The method according to any one of claims 11 to 16, characterized in that: The identification information of the second device and the identification information of the third device are carried in the flow classification element of the SCS request frame.

18. The method according to any one of claims 11 to 17, characterized in that: The QoS parameters of the service flow include a minimum service interval and / or a maximum service interval.

19. The method according to any one of claims 11 to 18, characterized in that: The method further comprises: The second device receives an SCS response frame from the first device, where the SCS response frame is used to indicate that the service flow is accepted.

20. A communication device, characterized in that: The method comprises a unit or a module for implementing the method according to any one of claims 1 to 19.

21. A communication device, characterized in that: The communication device comprises at least one processor; wherein the at least one processor is configured to execute the method according to any one of claims 1 to 19.

22. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, which, when executed, cause the computer to perform the method according to any one of claims 1 to 19.

23. A computer program product, characterized in that The computer program product comprises: a computer program code, and when the computer program code is executed by a computer, the computer is caused to perform the method according to any one of claims 1 to 19.

24. A chip, characterized in that: The chip includes at least one processor and an interface, wherein the processor is used to read and execute instructions stored in a memory, and when the instructions are executed, the chip executes the method according to any one of claims 1 to 19.

Citation Information

Patent Citations

  • Communication method and device

    CN120152026A

  • Communication method and communication device for flow classification service

    CN116455513A

  • Flow classification service (SCS) with restricted target latency (R-TWT) settings

    CN116830650A

  • IMPROVED r-TWT-BASED COMMUNICATION METHODS FOR P2P STREAM

    WO2023203064A1

  • Systems and methods of QOS management of WLAN devices

    WO2023211798A1