WO2026007613A1 - 多链路通信方法、装置、计算机可读介质及电子设备 - Google Patents

多链路通信方法、装置、计算机可读介质及电子设备

Info

Publication number
WO2026007613A1
WO2026007613A1 PCT/CN2025/099513 CN2025099513W WO2026007613A1 WO 2026007613 A1 WO2026007613 A1 WO 2026007613A1 CN 2025099513 W CN2025099513 W CN 2025099513W WO 2026007613 A1 WO2026007613 A1 WO 2026007613A1
Authority
WO
WIPO (PCT)
Prior art keywords
link
data packet
request frame
request
specified type
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2025/099513
Other languages
English (en)
French (fr)
Inventor
谢强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology (Shenzhen) Co Ltd
Original Assignee
Tencent Technology (Shenzhen) Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology (Shenzhen) Co Ltd filed Critical Tencent Technology (Shenzhen) Co Ltd
Priority to EP25831967.2A priority Critical patent/EP4794444A1/en
Publication of WO2026007613A1 publication Critical patent/WO2026007613A1/zh
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/15—Setup of multiple wireless link connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols

Definitions

  • This application relates to the fields of computer and communication technology, and more specifically, to a multi-link communication method, apparatus, computer-readable medium, and electronic device.
  • WLAN Wireless Local Area Network
  • IEEE Institute of Electrical and Electronics Engineers
  • Embodiments of this application provide a multi-link communication method, apparatus, computer-readable medium, and electronic device that can improve the transmission efficiency and reliability of service data packets with high real-time requirements.
  • This application provides a multi-link communication method executed by a multi-link device, comprising: generating a first request frame by the media access control (MAC) layer of the multi-link device, the first request frame being used to request the initiation of multi-link transmission for a specified type of data packet between the multi-link device and a peer multi-link device; and sending the first request frame to the peer multi-link device by the MAC layer of the multi-link device.
  • MAC media access control
  • This application provides a multi-link communication method executed by a multi-link device, comprising: receiving a first request frame sent by a peer multi-link device by the media access control (MAC) layer of the multi-link device, the first request frame being used to request the initiation of multi-link transmission for a specified type of data packet between the peer multi-link device and the multi-link device; generating a response frame for the first request frame by the MAC layer of the multi-link device, the response frame being used to indicate whether the multi-link device allows the initiation of multi-link transmission for the specified type of data packet; and sending the response frame to the peer multi-link device by the MAC layer of the multi-link device.
  • MAC media access control
  • This application provides a multi-link communication device, including: a generation unit configured to generate a first request frame at the Media Access Control (MAC) layer of the multi-link communication device, the first request frame being used to request the initiation of multi-link transmission for a specified type of data packet between the multi-link communication device and a peer multi-link communication device; and a sending unit configured to send the first request frame to the peer multi-link communication device through the MAC layer of the multi-link communication device.
  • MAC Media Access Control
  • This application provides a multi-link communication device, including: a receiving unit configured to receive a first request frame sent by a peer multi-link communication device at the Media Access Control (MAC) layer of the multi-link communication device, the first request frame being used to request the initiation of multi-link transmission for a specified type of data packet between the peer multi-link communication device and the multi-link communication device; a generating unit configured to generate a response frame for the first request frame at the MAC layer of the multi-link communication device, the response frame being used to indicate whether the multi-link communication device allows the initiation of multi-link transmission for the specified type of data packet; and a sending unit configured to send the response frame to the multi-link communication device from the MAC layer of the multi-link communication device.
  • MAC Media Access Control
  • This application provides a computer-readable medium storing a computer program thereon, which, when executed by a processor, implements the multi-link communication method as described in the above embodiments.
  • This application provides an electronic device, including: one or more processors; and a storage device for storing one or more computer programs, wherein when the one or more computer programs are executed by the one or more processors, the electronic device enables the multi-link communication method as described in the above embodiments.
  • This application provides a computer program product comprising a computer program stored in a computer-readable storage medium.
  • An electronic device's processor reads and executes the computer program from the computer-readable storage medium, causing the electronic device to perform the multi-link communication methods provided in the various alternative embodiments described above.
  • Figure 1 shows a schematic diagram of the architecture of the wireless communication system provided in an embodiment of this application.
  • Figure 2 shows a flowchart of a multi-link communication method according to some embodiments of this application.
  • Figure 3 shows a flowchart of a multi-link communication method according to some embodiments of this application.
  • Figure 4 shows a schematic diagram of the header structure of an IP data packet according to some embodiments of this application.
  • Figure 5 illustrates a schematic diagram of the fields included in MAC Capabilities according to some embodiments of this application.
  • Figure 6 shows a schematic diagram of fields included in a GDM Access element according to some embodiments of this application.
  • Figure 7 shows a schematic diagram illustrating the definition of the GDM Access Flag according to some embodiments of this application.
  • Figure 8 shows a schematic diagram of the GDM access process according to some embodiments of this application.
  • FIG. 9 shows a schematic diagram of the GDM elimination process according to some embodiments of this application.
  • Figure 10 illustrates a flowchart of establishing multi-link GDM Access Enable using AP MLD and Non-AP MLD according to some embodiments of this application.
  • Figure 11 illustrates a flowchart of establishing a multi-link GDM Access Teardown using AP MLD and Non-AP MLD according to some embodiments of this application.
  • Figure 12 shows a block diagram of a multi-link communication apparatus according to some embodiments of this application.
  • Figure 13 shows a block diagram of a multi-link communication apparatus according to some embodiments of this application.
  • Figure 14 shows a schematic diagram of the structure of a computer system suitable for implementing an electronic device according to the embodiments of this application.
  • module refers to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof.
  • a processor or multiple processors or memory
  • each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.
  • This communication device can be a wireless communication device that supports parallel transmission across multiple links (i.e., supports multi-link operation (MLO)). For example, it can be called a multi-link device (MLD) or a multi-band device. Compared to communication devices that only support single-link transmission, multi-link devices have higher transmission efficiency and greater throughput.
  • MLO multi-link operation
  • a first request frame is generated to request the use of multiple links for the transmission of data packets of a specified type. This allows services with high real-time requirements to be transmitted through multiple links to ensure the reliability of data transmission. In turn, this can improve the efficiency and reliability of service data packet transmission in poor network environments or when transmission links are congested.
  • a multi-link device can be an access point multi-link device (AP MLD) or a non-access point multi-link device (Non-AP MLD).
  • the internal entity responsible for any one link is called a station (STA). If all STAs within an MLD are access points (APs), it can be further called an AP MLD; if all STAs within an MLD are non-access point stations (non-AP STAs), it can be further called a non-AP MLD.
  • a multi-link device includes one or more affiliated STAs.
  • An affiliated STA is a logical station that can operate on one link, one frequency band, or one channel.
  • the affiliated STA can be an AP or a non-AP STA.
  • 802.11be refers to multi-link devices belonging to AP sites as AP multi-link devices (AP MLD), and multi-link devices belonging to non-AP STA sites as non-AP multi-link devices (non-AP MLD).
  • an exemplary wireless communication system includes at least one AP MLD (AP MLD 101 in Figure 1) and at least one non-AP MLD (non-AP MLD 102 and non-AP MLD 103 in Figure 1).
  • the non-AP MLDs can communicate with the AP MLDs via multiple links, thereby improving throughput.
  • a STA in a non-AP MLD can also communicate with an AP in an AP MLD via a single link. It is understood that the number of AP MLDs and non-AP MLDs in Figure 1 is merely exemplary; any number of AP MLDs and non-AP MLDs can be used depending on implementation requirements.
  • a multi-link device is a device with wireless communication capabilities.
  • This device can be a complete machine or a chip or processing system installed within a complete machine. Devices with these chips or processing systems installed can implement the methods and functions of the embodiments of this application under the control of these chips or processing systems.
  • the non-AP MLD in the embodiments of this application has wireless transceiver capabilities, supports the 802.11 series protocols, and can communicate with a single-link AP, AP MLD, or other non-AP MLDs.
  • a non-AP MLD is any user communication device that allows users to communicate with an AP and thus with a WLAN.
  • multi-link devices can support high-speed, low-latency transmission.
  • multi-link devices can be applied to more scenarios, such as sensor nodes in smart cities (e.g., smart water meters, smart electricity meters, smart air quality monitoring nodes); smart devices in smart homes (e.g., smart cameras, projectors, displays, televisions, speakers, refrigerators, washing machines, etc.); smart devices in smart offices (e.g., printers, projectors, etc.); and some infrastructure in daily life scenarios (e.g., vending machines, supermarket self-service navigation kiosks, self-checkout machines, self-ordering machines, etc.).
  • the specific forms of non-AP MLDs and APs are not limited; they are merely illustrative examples.
  • the 802.11 protocol can be a protocol that supports or is compatible with 802.11be.
  • FIG. 2 shows a flowchart of a multi-link communication method according to some embodiments of this application.
  • This multi-link communication method can be executed by a device with wireless communication capabilities.
  • the device with wireless communication capabilities can be an AP MLD as shown in Figure 1, or a non-AP MLD.
  • the multi-link communication method includes at least S210 to S220, which are described in detail below:
  • the Media Access Control (MAC) layer of the multi-link device generates a first request frame, which is used to request the initiation of multi-link transmission for a specified type of data packet between the multi-link device and the peer multi-link device.
  • MAC Media Access Control
  • the specified type of data packet can be a low-latency data packet, such as a multimedia service data packet, including game service data packets, virtual reality (VR) service data packets, augmented reality (AR) service data packets, mixed reality (MR) service data packets, extended reality (XR) service data packets, XR and Media Services (XRM) service data packets, and Cinematic Reality (CR) service data packets, etc.
  • a multimedia service data packet including game service data packets, virtual reality (VR) service data packets, augmented reality (AR) service data packets, mixed reality (MR) service data packets, extended reality (XR) service data packets, XR and Media Services (XRM) service data packets, and Cinematic Reality (CR) service data packets, etc.
  • a device with wireless communication capabilities when a device with wireless communication capabilities receives a current service data packet, it can determine whether the current service data packet is a data packet of a specified type based on the value of a specified flag bit included in the header of the current service data packet.
  • the specified flag bit may be a flag bit in the Type of Service (TOS) field of the header.
  • the device with wireless communication capabilities may be a multi-link device (MLD).
  • a device with wireless communication capabilities generally includes a Station Management Entity (SME) layer, a Medium Access Control (MAC) layer, and a Physical (PHY) layer. Therefore, when generating the first request frame, the MLD MAC layer can receive an enable request from the MLD's SME for multi-link transmission of a specified type of data packet; and then generate the first request frame based on this enable request.
  • SME Station Management Entity
  • MAC Medium Access Control
  • PHY Physical
  • the enable request includes at least one of the following: the MAC address of the peer multilink device (i.e., the target non-access point site device (i.e., non-AP MLD)), a dialog token for multilink transmission of a specified type of data packet, and parameters for multilink transmission of a specified type of data packet.
  • the enable request includes at least one of the following: the MAC address of the peer multilink device (i.e., the access point device (i.e., the AP MLD) associated with the site device), and a session token for multilink transmission of a specified type of data packet.
  • the first request frame may include at least one of the following fields: a field indicating the type of the first request frame (Category), a field indicating that the first request frame adopts Protected EHT Action (Protected EHT Action), a field indicating the session token, and a field indicating whether to enable multi-link transmission of a specified type of data packet.
  • a device with wireless communication capabilities may obtain service access permissions from a Subscription Service Provider Network (SSPN) for a specified type of data packet. If the SSPN is determined to allow multi-link transmission for the specified type of data packet based on the service access permissions, then the first request frame is generated.
  • SSPN Subscription Service Provider Network
  • the Media Access Control (MAC) layer of the multi-link device sends a first request frame to the peer multi-link device.
  • MAC Media Access Control
  • the access point device may send the first request frame to a non-access point site device (i.e., non-AP MLD); if the first request frame is generated by a non-access point site device (i.e., non-AP MLD), the site device may send the first request frame to an access point device (i.e., AP MLD), or it may send it to other site devices.
  • a non-access point site device i.e., non-AP MLD
  • the site device may send the first request frame to an access point device (i.e., AP MLD), or it may send it to other site devices.
  • the MAC layer of the multilink device may receive a response frame sent by the peer multilink device in response to the first request frame.
  • the response frame is used to indicate whether the peer multilink device allows multilink transmission for a specified type of data packet.
  • the response frame may include at least one of the following fields: a field indicating the type of response frame (Category), a field indicating that the response frame uses Protected EHT Action (Protected EHT Action), a field indicating the session token, a field indicating whether multi-link transmission of a specified type of data packet is enabled, and a status code field indicating the response result (Status Code Field).
  • the MLD MAC layer of the device with wireless communication capabilities can send an enable confirmation to the SME for multilink transmission of a specified type of data packet.
  • the enable confirmation may include a status code field indicating the response result; wherein the status code field may be used to indicate that multilink transmission for the specified type of data packet is permitted; or the status code field may be used to indicate that multilink transmission for the specified type of data packet is refused; or the status code field may be used to indicate the reason for refusing to enable multilink transmission for the specified type of data packet; or the status code field may be used to indicate both the reason for refusing to enable multilink transmission for the specified type of data packet and the reason for refusing to enable multilink transmission for the specified type of data packet.
  • the MAC layer of the multi-link device determines whether the service data packet is a data packet of a specified type based on the value of a specified flag bit contained in the header of the service data packet.
  • the service data packet is transmitted via multiple links; wherein, the specified flag bit includes the flag bit in the Type of Service (TOS) field in the packet header.
  • TOS Type of Service
  • the MAC layer can quickly distinguish low-latency packets and automatically trigger multi-link parallel transmission, reducing queuing and link switching delays. Furthermore, multi-link transmission is only enabled for specified types of packets (such as high-priority packets), avoiding ordinary packets occupying additional link resources and improving overall bandwidth utilization. In addition, classification decisions are implemented at the MAC layer, eliminating the need for repeated intervention from upper-layer protocols and reducing processing overhead. This mechanism achieves low-latency, high-reliability transmission of critical business data while maintaining a reasonable allocation of network resources.
  • a device with wireless communication capabilities can generate a second request frame to request the termination of the multilink transmission for the specified type of data packet established between the multilink device and the peer multilink device, and then send the second request frame.
  • the multi-link transmission of a specified service is actively terminated via a second request frame, avoiding continuous occupation of redundant links and freeing up bandwidth resources for other services. Furthermore, the termination process is triggered only for specific service types (such as the end of a low-latency session), maintaining multi-link connections for other services and achieving fine-grained resource management.
  • the MAC layer generates a standardized control frame (second request frame) to ensure that the peer device synchronously unbinds from the multi-link connection, preventing out-of-order packet loss or packet corruption. This embodiment of the application improves the dynamic adaptability and overall resource utilization of the multi-link system while ensuring the transmission of critical services.
  • the access point device may send the second request frame to a non-access point site device (i.e., non-AP MLD); if the second request frame is generated by a non-access point site device (i.e., non-AP MLD), the site device may send the second request frame to an access point device (i.e., AP MLD), or it may send it to other site devices.
  • a non-access point site device i.e., non-AP MLD
  • the site device may send the second request frame to an access point device (i.e., AP MLD), or it may send it to other site devices.
  • a tear down request for multi-link transmission of a specified type of data packet sent by the SME of the multi-link device can be received; then the second request frame is generated based on the tear down request.
  • the stop request includes the MAC address of a non-access point site device (i.e., a non-AP MLD).
  • the stop request includes the MAC address of the access point device (i.e., AP MLD) associated with the site device.
  • the stop request may not include the MAC address of the access point device (i.e., AP MLD) associated with the site device when it needs to be sent to the associated access point device, thereby reducing signaling load and frame overhead.
  • FIG. 3 shows a flowchart of a multi-link communication method according to some embodiments of this application.
  • This multi-link communication method can be executed by a device with wireless communication capabilities.
  • the device with wireless communication capabilities can be an AP MLD as shown in Figure 1, or a non-AP MLD.
  • the multi-link communication method includes at least steps S310 to S330, which are described in detail below:
  • the MAC layer of the multilink device receives a first request frame, which is used to request the initiation of multilink transmission for a specified type of data packet between the peer multilink device and the multilink device.
  • the first request frame may include at least one of the following fields: a field indicating the type of the first request frame (Category), a field indicating that the first request frame adopts Protected EHT Action (Protected EHT Action), a field indicating a session token, and a field indicating whether multi-link transmission of a specified type of data packet is enabled.
  • the MAC layer of the multi-link device generates a response frame for the first request frame, which is used to indicate whether the multi-link device allows multi-link transmission for a specified type of data packet.
  • the response frame may include at least one of the following fields: a field indicating the type of response frame (Category), a field indicating that the response frame uses Protected EHT Action (Protected EHT Action), a field indicating the session token, a field indicating whether multi-link transmission of a specified type of data packet is enabled, and a status code field indicating the response result (Status Code Field).
  • the status code field can be used to indicate that multi-link transmission for a specified type of data packet is permitted; or the status code field can be used to indicate that multi-link transmission for a specified type of data packet is refused; or the status code field can be used to indicate the reason for refusing to enable multi-link transmission for a specified type of data packet; or the status code field can be used to indicate that multi-link transmission for a specified type of data packet is refused, and to indicate the reason for refusing to enable multi-link transmission for a specified type of data packet.
  • the MLD MAC layer of the device with wireless communication capabilities can send an enable indication for multi-link transmission of a specified type of data packet to the SME. If an enable response for multi-link transmission of the specified type of data packet is received from the SME, a response frame is generated for the first request frame.
  • the MAC layer of the multi-link device sends a response frame to the peer multi-link device.
  • the access point device may send the response frame to a non-access point site device (i.e., a non-AP MLD) that sent the first request frame; if the response frame is generated by a non-access point site device (i.e., a non-AP MLD), the site device may send the response frame to the access point device (i.e., the AP MLD) that sent the first request frame, or it may send it to another site device that sent the first request frame.
  • a non-access point site device i.e., a non-AP MLD
  • the site device may send the response frame to the access point device (i.e., the AP MLD) that sent the first request frame, or it may send it to another site device that sent the first request frame.
  • the MLD MAC layer may send a tear down indication to the SME for the multilink transmission of the specified service type of data packet.
  • the first request frame and the second request frame can be management frames, or they can be other types of frames.
  • the technical solution of this application proposes that after establishing a packet-level connection between an AP (such as an AP-MLD) and a STA (such as a Non-AP MLD), each can perform multi-link transmission or select another link transmission for low-latency service (such as gaming service) data packets according to its own wireless environment or service carrying conditions. That is, the technical solution of this application can achieve more refined multi-link transmission at the packet level, and the technical solution of this application can be applied to 802.11be and later standards.
  • an AP such as an AP-MLD
  • STA such as a Non-AP MLD
  • the IP header of the IP data packet for game services includes the following fields:
  • Version 4 digits. Used to indicate the version of the IP protocol. If it is IPv4, then it is always 4.
  • Header length 4 bits. Used to indicate the length of the IP header, in words (i.e., 4 bytes). Since its maximum value is 15, the maximum IP header size is 60 bytes (15 ⁇ 4).
  • Type of Service 8 bits. Used to define different service types, which can provide different services for IP packets.
  • Total length 16 bits. Used to indicate the length of the entire IP packet, including the data and IP header, so the maximum length of an IP packet is 65535 bytes.
  • ID 16 bits. Used to identify different IP packets. This field is used in conjunction with the Flags and Fragment Offset fields to fragment larger IP packets.
  • Flags 3 bits. The first bit is unused. The second bit is the DF (Don't Fragment) bit, which indicates that the router cannot fragment this packet. The third bit is the MF (More Fragments) bit, indicating whether the current fragment is the last fragment of the IP packet. If it is the last fragment, it is set to 0; otherwise, it is set to 1.
  • Fragment offset 13 bits. Used to indicate the current position of the fragment within the IP packet fragment group. The receiving end uses this to reassemble the IP packet.
  • Time To Live 8 bits.
  • TTL Time To Live
  • Upper-layer protocol occupies 8 bits. Identifies the protocol used at the upper layer, such as the commonly used Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • Checksum 16 bits. Used to check the correctness of the IP header, but does not include the data portion, because each router changes the TTL value, so the router recalculates this value for each passing IP packet.
  • Source IP address and destination IP address Both fields are 32 bits long. They identify the source IP address and destination IP address of this IP packet.
  • IP options Variable length, up to 40 bytes.
  • the Differentiated Services Code Point (DSC) and TID mapping only occupy the high 6 bits of the Type of Service (TOS) in the IP header. The remaining low 2 bits are reserved and not used for other purposes. Therefore, the first bit can be used as a flag to identify low-latency data packets. Then, the AP MLD and Non-AP MLD establish multi-link transmission at the low-latency data packet level through signaling messages. After the MAC layer receives the IP packet, it parses the TOS field in the IP header to obtain the flag value, and then performs multi-link transmission or selects a better link for transmission of the service data packet.
  • the MAC layer After the MAC layer receives the IP packet, it parses the TOS field in the IP header to obtain the flag value, and then performs multi-link transmission or selects a better link for transmission of the service data packet.
  • establishing multi-link access at the AP MLD and Non-AP MLD packet level requires adding three messages: Game Data Multi-Link Access Enable Request (GDM Access Enable Request), Game Data Multi-Link Access Enable Response (GDM Access Enable Response), and Game Data Multi-Link Access Teardown (GDM Access Teardown). Additionally, three new values need to be added to the Protected Action field, as shown in Table 1 below:
  • Game Data Multi-Link Access Enable Request frame can be as shown in Table 2 below:
  • the Category field is defined in the "Action field” section of the standard protocol.
  • the Protected EHT Action field is defined in the "Protected EHC Action field” section of the standard protocol; this embodiment adds three new values: GDM Access Enable Request, GDM Access Enable Response, and GDM Access Teardown.
  • the Dialog Token field is defined in the "Dialog Token field” section of the standard protocol and can be set to a non-zero value to distinguish between GDM Enable Access Request/Response frames.
  • the Game Data Multi-Link Access element indicates whether multi-link transmission of game data is enabled.
  • a Game Data Multi-Link Access element if a Game Data Multi-Link Access element is present in the Game Data Multi-Link Access Enable Request frame, then enabling game data multi-link transmission can be indicated; if a Game Data Multi-Link Access element is not present in the Game Data Multi-Link Access Enable Request frame, then disabling game data multi-link transmission can be indicated.
  • different values can be set to indicate whether game data multi-link transmission is enabled or disabled.
  • Game Data Multi-Link Access Enable Response frame can be as shown in Table 3 below:
  • the Category field in Table 3 is defined in the "Action field” section of the standard protocol.
  • the Protected EHT Action field is defined in the "Protected EHC Action field” section of the standard protocol. This embodiment adds three new values: GDM Access Enable Request, GDM Access Enable Response, and GDM Access Teardown.
  • the Dialog Token field is set to the value found in the Game Data Multi-Link Access Enable Request frame.
  • the GDM Access Enable Response frame is sent in active mode, the Dialog Token field can be set to 0.
  • the Status Code is defined in the "Status Code field” section of the standard protocol. When the GDM response frame is sent in unsolicited mode, it can be set to 0.
  • the Game Data Multi-Link Access element is used to indicate whether game data multi-link transmission is enabled. In some embodiments, if the Game Data Multi-Link Access Enable Request frame contains the Game Data Multi-Link Access element, then game data multi-link transmission can be enabled; if the Game Data Multi-Link Access Enable Request frame does not contain the Game Data Multi-Link Access element, then game data multi-link transmission can be disabled. Alternatively, different values can be set to indicate whether game data multi-link transmission is enabled.
  • Game Data Multi-Link Access Teardown frame can be as shown in Table 4 below:
  • the Category field in Table 4 is defined in the "Action field” section of the standard protocol.
  • the Protected EHT Action field is defined in the "Protected EHC Action field” section of the standard protocol. In this embodiment, three new values have been added: GDM Access Enable Request, GDM Access Enable Response, and GDM Access Teardown.
  • the embodiments of this application may add three status code values to support GDM Access, as shown in Table 5 below:
  • additional fields can be added to MAC Capabilities to indicate AP MLD or Non-AP MLD support for GDM Access.
  • MAC Capabilities are shown in Figure 5. These include: Emergency Preparedness Communications Service (EPCS) priority access support, EHT OM Control support, Triggered TXOP Sharing Mode 1 support, Triggered TXOP Sharing Mode 2 support, Restricted Target Wake Time support, and Sub-Carrier Space Traffic Description support.
  • EPCS Emergency Preparedness Communications Service
  • EHT OM Control support Triggered TXOP Sharing Mode 1 support
  • Triggered TXOP Sharing Mode 2 support Triggered TXOP Sharing Mode 2 support
  • Restricted Target Wake Time support and Sub-Carrier Space Traffic Description support.
  • the system supports the following functions: Ption Support, Maximum MPDU Length, Maximum A-MPDU Length Exponent Extension, EHT Tracking Reference Signal Support, TXOP Return Support in Triggered TXOP Sharing Mode, Two BQRs Support, EHT Link Adaptation Support, GDM Access Support, and Reserved fields.
  • BQR refers to Bandwidth Query Report
  • TXOP refers to Transmission Opportunity
  • MPDU refers to MAC Protocol Data Unit
  • A-MPDU refers to Aggregation MAC Protocol Data Unit.
  • GDM Access Support is a newly added field in this application embodiment. That is, in this application embodiment, support for GDM Access can be added to bit B14. After adding GDM Access Support to B14, the remaining bit B15 is reserved.
  • additional element IDs that support GDM Access can be added, as shown in Table 6 below:
  • GDM Access element the definition of a GDM Access element is shown in Figure 6, including: Element ID, Length, Element ID Extension, and GDM Access Flags.
  • whether the GDM Access Flag supports multi-link transmission is defined as shown in Figure 7, and can be indicated by a flag bit. For example, if the value of the flag bit is 1, then multi-link transmission is supported; if the value of the flag bit is 0, then multi-link transmission is not supported.
  • the types that support GDM Access can be added to the Multi-Link field in the Multi-Link element, as shown in Table 7 below:
  • the GDM Access element can be carried in the Multi-Link element.
  • this application may add six primitives to support GDM Access: GDM Access Enable Request Primitive (MLME-GDMACCESSENABLE.request), GDM Access Enable Indication Primitive (MLME-GDMACCESSENABLE.indication), GDM Access Enable Response Primitive (MLME-GDMACCESSENABLE.response), GDM Access Enable Confirmation Primitive (MLME-GDMACCESSENABLE.confirm), GDM Access Deactivation Request Primitive (MLME-GDMACCESSTEARDOWN.request), and GDM Access Deactivation Indication Primitive (MLME-GDMACCESSTEARDOWN.indication).
  • MLME refers to the MAC Layer Management Entity. The following describes each primitive.
  • the MLME-GDMACCESSENABLE.request primitive is used to send a request to the peer MAC entity to enable GDM Access.
  • PeerSTAAddress The relevant explanations for PeerSTAAddress, Dialog Token, and GDMAccessMultiLink are shown in Table 8 below:
  • the MLME-GDMACCESSENABLE.request primitive is generated by SME and is used to send a request to the peer MAC entity to enable GDM Access.
  • the MLME-GDMACCESSENABLE.confirm primitive is used to report a response to a GDM Access request from a peer MAC entity.
  • PeerSTAAddress The relevant explanations for PeerSTAAddress, Dialog Token, Status Code, and GDMAccessMultiLink are shown in Table 9 below:
  • the MLME-GDMACCESSENABLE.confirm primitive is generated by the MLME upon receiving GDM Access Enable from the peer MAC entity.
  • the MLME-GDMACCESSENABLE.indication primitive indicates that a request for a GDM Access Enable Request has been received from the peer MAC entity.
  • PeerSTAAddress The relevant explanations for PeerSTAAddress, Dialog Token, and GDMAccessMultiLink are shown in Table 10 below:
  • the MLME-GDMACCESSENABLE.indication primitive is generated by the MLME after receiving a GDM Access Enable Request frame from the peer MAC entity.
  • the MLME-GDMACCESSENABLE.response primitive is generated by the MLME and used to send a response enabling GDM Access to the peer MAC entity.
  • PeerSTAAddress The relevant explanations for PeerSTAAddress, Dialog Token, Status Code, and GDMAccessMultiLink are shown in Table 11 below:
  • the MLME-GDMACCESSENABLE.response primitive is generated by SME as a response to the MLME-GDMACCESSENABLE.indication primitive.
  • the MLME-GDMACCESSTEARDOWN.request primitive is used to instruct the peer MAC entity to torrent down GDM Access.
  • PeerSTAAddress (Peer STA Address)
  • PeerSTAAddress The relevant information about PeerSTAAddress is shown in Table 12 below:
  • the MLME-GDMACCESSENABLE.response primitive is generated by the SME when the STA wants to torrent down GDM Access.
  • the MLME-GDMACCESSTEARDOWN.indication primitive is used to instruct the peer MAC entity to release GDM Access.
  • PeerSTAAddress (Peer STA Address)
  • PeerSTAAddress The relevant information about PeerSTAAddress is shown in Table 13 below:
  • the MLME-GDMACCESSTEARDOWN.indication primitive is generated by the MLME after receiving a GDM Access Enable Teardown frame from the peer MAC entity.
  • an Abstract Syntax Notation One (ASN.1) message can be added to this application.
  • an ASN.1 message ⁇ dot11EHTGDMAccessActivated ⁇ meaning EHT GDM access is activated
  • ⁇ Dot11EHTStationConfigEntry ⁇ i.e., EHT site configuration entry
  • this message can be set to an object type.
  • ⁇ dot11EHTGDMAccessActivated ⁇ can be a control variable, written by an external management entity or SME. In practice, changes to it will take effect as soon as possible. When this attribute is true, it indicates that the MLD supports GDM access capability; if this attribute is false, the MLD does not support GDM access capability.
  • an ASN.1 message ⁇ dot11GDMAccessAuthorized ⁇ (i.e., GDM access authorization) can be added to the ⁇ Dot11InterworkingEntry ⁇ (i.e., interactive working entry), and this message can be set to an object type.
  • ⁇ dot11GDMAccessAuthorized ⁇ can be a control variable written by the SME after the AP receives permission from the SSPN interface for a non-AP STA to use GDM access. When this attribute is true, it indicates that the non-AP STA is allowed to invoke and use the GDM access capability; if the attribute is false, the non-AP STA is not allowed to invoke and use the GDM access capability.
  • GDM access is initiated by the SME and established on the MAC.
  • GDM access between a GDM AP-MLD and its associated GDM Non-AP MLD can be in two states: enabled or torn down.
  • both the AP MLD and the Non-AP MLD can have dot11EHTGDMAccessActivated set to true.
  • the STA attached to the GDM MLD will set the GDM Access Support subfield in the MAC Capabilities Information field it sends to 1, indicating that GDM access is supported; otherwise, it will be set to 0.
  • the AP MLD obtains the information required to verify that the Non-AP MLD uses GDM Access.
  • dot11SSPNInterfaceActivated can be set to true to support retrieving the GDM service access provider corresponding to the Non-AP MLD via the SSPN interface during Non-AP MLD association.
  • An AP MLD that successfully obtains GDM access permission from a Non-AP MLD should update the value of ⁇ dot11GDMAccessAuthorized ⁇ in the ⁇ dot11Inter workingEntry ⁇ for the Non-AP MLD. If a Robust Security Network Association (RSNA) with management frame protection is not successfully negotiated and allows GDM access, neither the AP MLD nor the Non-AP MLD can send a GDM Access Enable Request frame to each other to initiate GDM access.
  • RSNA Robust Security Network Association
  • the GDM access process is as follows:
  • the MLD SME of the initiating party such as AP MLD or Non-AP MLD
  • detects game data packets and determines that multi-link access is allowed it sends MLME-GDMACCESSENABLE.request to the MLD MAC of the initiating party.
  • the MLD MAC After receiving this primitive, the MLD MAC sends a GDM Access Enable Request frame to the MLD MAC of the responding party (such as AP MLD or Non-AP MLD), and then the MLD MAC of the responding party can send MLME-GDMACCESSENABLE.indication to the MLD SME of the responding party.
  • the responding MLD SME After receiving MLME-GDMACCESSENABLE.indication, the responding MLD SME sends MLME-GDMACCESSENABLE.response to its MLD MAC. Upon receiving MLME-GDMACCESSENABLE.response, the responding MLD MAC can send a GDM Access Enable Response frame to the initiating MLD MAC, which then sends MLME-GDMACCESSENABLE.confirm to its MLD SME. In this scenario, if the responding party's response frame indicates agreement to GDM access, the GDM access process is complete between the initiating and responding parties, allowing for the transmission of game service data packets via multiple links.
  • the GDM teardown process is as follows:
  • the MLD SME of the initiating party such as an AP MLD or a Non-AP MLD
  • the MLD SME sends MLME-GDMACCESSTEARDOWN.request to the initiating party's MLD MAC.
  • the MLD MAC sends a GDM Access Enable Teardown frame to the MLD MAC of the responding party (such as an AP MLD or a Non-AP MLD).
  • the responding party's MLD MAC can send MLME-GDMACCESSTEARDOWN.indication to the responding party's MLD SME to remove GDM access.
  • the GDM access state can be torn down when an instruction is issued by the higher layer of the MLD with GDM access. Both the initiator and the responder set the GDM access state to torn down and apply it to all enabled links between MLDs.
  • the process for establishing a multi-link GDM Access Enable between the AP MLD and Non-AP MLD is shown in Figure 10:
  • the initiator such as the AP MLD or Non-AP MLD
  • the responder such as the AP MLD or Non-AP MLD
  • the GDM access process is completed between the initiator and the responder, and game service data packets can then be transmitted via multiple links.
  • the process of establishing a multi-link GDM Access Teardown between AP MLD and Non-AP MLD is shown in Figure 11:
  • the initiator such as AP MLD or Non-AP MLD
  • the responder such as AP MLD or Non-AP MLD
  • the technical solutions of this application mainly lie in the field of wireless communication technology, particularly in scenarios where multiple wireless terminals in a Wi-Fi wireless network experience service congestion or weak communication link coverage.
  • the STA and AP establish multi-link transmission based on data packets through management messages, so that the low-latency service can select better links or copies to transmit on multiple links, thereby improving the transmission reliability and efficiency of the service.
  • three new management messages are created to establish a packet-level multi-link transmission link between the STA and AP.
  • Six new primitives are added to support the creation of these three management messages.
  • the embodiment also adds a configuration field ⁇ dot11EHTGDMAccessActivated ⁇ to indicate that both the STA and AP have packet-level multi-link transmission capabilities.
  • GDM Access support is added to MAC capabilities and set to ⁇ true ⁇ .
  • the STA or AP sends a GDM Access Enable Request frame to the other party.
  • the other party Upon receiving this frame, the other party sends a GDM Access Enable Response frame to the sender to indicate whether it accepts the mapping of the latency service to two or more links for data transmission. This allows low-latency services to be transmitted on two or more links or on better links, as expected by the STA or AP, even in situations with weak network coverage or network congestion.
  • the transmission of the service data packet can be adaptively optimized according to the network coverage and service congestion, so that the service data packet is transmitted on two or more links, instead of all data packets being transmitted on multiple links.
  • the reliability of low-latency data service packet transmission can be improved, thereby enhancing the user experience.
  • FIG 12 shows a block diagram of a multi-link communication device according to some embodiments of the present application.
  • the multi-link communication device can be disposed in a device with wireless communication function, which can be the AP MLD shown in Figure 1 or a non-AP MLD.
  • a multi-link communication device 1200 includes: a generation unit 1202 and a transmission unit 1204.
  • the generation unit 1202 is configured to generate a first request frame at the MAC layer of the multi-link communication device.
  • the first request frame is used to request the initiation of multi-link transmission for a specified type of data packet between the multi-link communication device and the peer multi-link communication device.
  • the sending unit 1204 is configured to send the first request frame to the peer multi-link communication device through the MAC layer of the multi-link communication device.
  • FIG 13 shows a block diagram of a multi-link communication device according to some embodiments of the present application.
  • the multi-link communication device can be disposed in a device with wireless communication function, which can be the AP MLD shown in Figure 1 or a non-AP MLD.
  • a multi-link communication device 1300 includes: a receiving unit 1302, a generating unit 1304, and a transmitting unit 1306.
  • the receiving unit 1302 is configured to receive a first request frame sent by the peer multilink communication device at the MAC layer of the multilink communication device.
  • the first request frame is used to request the initiation of multilink transmission for a specified type of data packet between the peer multilink communication device and the multilink communication device.
  • the generating unit 1304 is configured to generate a response frame for the first request frame at the MAC layer of the multilink communication device.
  • the response frame is used to indicate whether the multilink communication device allows the initiation of multilink transmission for the specified type of data packet.
  • the sending unit 1306 is configured to send the response frame from the MAC layer of the multilink communication device to the peer multilink communication device.
  • Figure 14 shows a schematic diagram of the structure of a computer system suitable for implementing the electronic device of the embodiments of this application.
  • the electronic device may be a device with wireless communication function as described in the foregoing embodiments.
  • the computer system 1400 may include a Central Processing Unit (CPU) 1401, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1402 or programs loaded from storage portion 1408 into Random Access Memory (RAM) 1403, such as performing the methods described in the above embodiments.
  • the RAM 1403 also stores various programs and data required for system operation.
  • the CPU 1401, ROM 1402, and RAM 1403 are interconnected via a bus 1404.
  • An Input/Output (I/O) interface 1405 is also connected to the bus 1404.
  • I/O interface 1405 The following components can be connected to I/O interface 1405: an input section 1406 including a keyboard, mouse, etc.; an output section 1407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1408 including a hard disk, etc.; and a communication section 1409 including a network interface card such as a LAN (Local Area Network) card, modem, etc.
  • the communication section 1409 performs communication processing via a network such as the Internet.
  • a drive 1410 is also connected to I/O interface 1405 as needed.
  • Removable media 1411 such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1410 as needed so that computer programs read from them can be installed into storage section 1408 as needed.
  • embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium for performing the methods shown in the flowcharts.
  • the computer program can be downloaded and installed from a network via communication section 1409, and/or installed from removable medium 1411.
  • CPU central processing unit
  • the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two.
  • a computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.
  • a computer-readable storage medium can be any tangible medium containing or storing a computer program that can be used by or in conjunction with an instruction execution system, apparatus, or device.
  • a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program.
  • the transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof.
  • the computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device.
  • the computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.
  • each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function.
  • the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved.
  • each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and a computer program.
  • the units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor.
  • the names of these units do not necessarily limit the specific unit itself.
  • this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device.
  • the computer-readable medium carries one or more computer programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.
  • the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, and includes several instructions to cause an electronic device to execute the method according to the embodiments of this application.
  • a non-volatile storage medium such as a CD-ROM, USB flash drive, external hard drive, etc.
  • an electronic device can be a device with wireless communication capabilities, and such a device can execute the multi-link communication method shown in Figure 2 or Figure 3.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请的实施例提供了一种多链路通信方法、装置、计算机可读介质及电子设备。该多链路通信方法包括：由多链路设备的介质访问控制MAC层生成第一请求帧，所述第一请求帧用于请求在所述多链路设备和对端多链路设备之间开启针对指定类型的数据包的多链路传输；由所述多链路设备的介质访问控制MAC层向所述对端多链路设备发送所述第一请求帧。

Description

多链路通信方法、装置、计算机可读介质及电子设备
本申请要求于2024年7月4日提交中国专利局、申请号为202410895734.4，发明名称为“多链路通信方法、装置、计算机可读介质及电子设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机及通信技术领域，具体而言，涉及一种多链路通信方法、装置、计算机可读介质及电子设备。
背景技术
下一代无线局域网(Wireless Local Area Network，WLAN)标准朝着不断提高吞吐量的方向进行发展和演进，WLAN系统标准主要在电气与电子工程师协会(Institute of Electrical and Electronics Engineers，IEEE)802.11标准组中进行研究和讨论，基于之前的标准协议如802.11a/b/g/n/ac/ax等，下一代标准802.11be将极高吞吐量(Extremely High Throughput，EHT)作为技术目标。
技术内容
本申请的实施例提供了一种多链路通信方法、装置、计算机可读介质及电子设备，可以提高实时性要求较高的业务数据包的传输效率和可靠性。
本申请的其它特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。
本申请实施例提供了一种多链路通信方法，由多链路设备执行，包括：由所述多链路设备的介质访问控制MAC层生成第一请求帧，所述第一请求帧用于请求在所述多链路设备和对端多链路设备之间开启针对指定类型的数据包的多链路传输；由所述多链路设备的MAC层向所述对端多链路设备发送所述第一请求帧。
本申请实施例提供了一种多链路通信方法，由多链路设备执行，包括：由所述多链路设备的介质访问控制MAC层接收对端多链路设备发送的第一请求帧，所述第一请求帧用于请求在所述对端多链路设备和所述多链路设备之间开启针对指定类型的数据包的多链路传输；由所述多链路设备的MAC层生成针对所述第一请求帧的响应帧，所述响应帧用于指示所述多链路设备是否允许开启针对所述指定类型的数据包的多链路传输；由所述多链路设备的MAC层向所述对端多链路设备发送所述响应帧。
本申请实施例提供了一种多链路通信装置，包括：生成单元，配置为在所述多链路通信装置的介质访问控制MAC层生成第一请求帧，所述第一请求帧用于请求在所述多链路通信装置和对端多链路通信装置之间开启针对指定类型的数据包的多链路传输；发送单元，配置为通过所述多链路通信装置的MAC层向所述对端多链路通信装置发送所述第一请求帧。
本申请实施例提供了一种多链路通信装置，包括：接收单元，配置为在所述多链路通信装置的介质访问控制MAC层接收对端多链路通信装置发送的第一请求帧，所述第一请求帧用于请求在所述对端多链路通信装置和所述多链路通信装置之间开启针对指定类型的数据包的多链路传输；生成单元，配置为在所述多链路通信装置的MAC层生成针对所述第一请求帧的响应帧，所述响应帧用于指示所述多链路通信装置是否允许开启针对所述指定类型的数据包的多链路传输；发送单元，配置为由上述多链路通信装置的MAC层向所述多链路通信装置发送所述响应帧。
本申请实施例提供了一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述实施例中所述的多链路通信方法。
本申请实施例提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个计算机程序，当所述一个或多个计算机程序被所述一个或多个处理器执行时，使得所述电子设备实现如上述实施例中所述的多链路通信方法。
本申请实施例提供了一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取并执行该计算机程序，使得该电子设备执行上述各种可选实施例中提供的多链路通信方法。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。
附图简要说明
图1示出了本申请实施例提供的无线通信系统的架构示意图。
图2示出了根据本申请的一些实施例的多链路通信方法的流程图。
图3示出了根据本申请的一些实施例的多链路通信方法的流程图。
图4示出了根据本申请的一些实施例的IP数据包的包头结构示意图。
图5示出了根据本申请的一些实施例的MAC Capabilities中包含的字段示意图。
图6示出了根据本申请的一些实施例的GDM Access element中包含的字段示意图。
图7示出了根据本申请的一些实施例的GDM Access Flag的定义示意图。
图8示出了根据本申请的一些实施例的GDM接入流程示意图。
图9示出了根据本申请的一些实施例的GDM消除流程示意图。
图10示出了根据本申请的一些实施例的AP MLD和Non-AP MLD建立多链路GDM Access Enable的流程示意图。
图11示出了根据本申请的一些实施例的AP MLD和Non-AP MLD建立多链路GDM Access Teardown的流程示意图。
图12示出了根据本申请的一些实施例的多链路通信装置的框图。
图13示出了根据本申请的一些实施例的多链路通信装置的框图。
图14示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。
具体实施方式
现在参考附图以更全面的方式描述示例实施方式。然而，示例的实施方式能够以各种形式实施，且不应被理解为仅限于这些范例；相反，提供这些实施方式的目的是使得本申请更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。
此外，本申请所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，有许多具体细节从而可以充分理解本申请的实施例。然而，本领域技术人员应意识到，在实施本申请的技术方案时可以不需用到实施例中的所有细节特征，可以省略一个或更多特定细节，或者可以采用其它的方法、元件、装置、步骤等。
本申请实施例中，术语“模块”或“单元”是指有预定功能的计算机程序或计算机程序的一部分，并与其他相关部分一起工作以实现预定目标，并且可以通过使用软件、硬件(如处理电路或存储器)或其组合来全部或部分实现。同样的，一个处理器(或多个处理器或存储器)可以用来实现一个或多个模块或单元。此外，每个模块或单元都可以是包含该模块或单元功能的整体模块或单元的一部分。
附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
需要说明的是：在本文中提及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
本申请实施例提供的技术方案可以应用于WLAN系统，并且可以适用于IEEE 802.11系列协议，例如802.11a/b/g协议、802.11n协议、802.11ac协议、802.11ax协议、802.11be协议或下一代的协议等，这里不再一一列举。本申请实施例提供的技术方案还可以应用于其它各类通信系统，例如，物联网(Internet of Things，IoT)系统、车联网(Vehicle to X，V2X)系统等。
在相关技术中，对于某些实时性要求较高的业务(比如游戏业务)，为了保障游戏数据的传输效率和可靠性，通常是将游戏数据映射到高优先等级，那么如果同时有多个游戏在线，则必然会引起数据传输拥塞和不可靠，因此如何能够保证实时性要求较高的业务数据包的传输可靠性是亟待解决的技术问题。
本申请实施例提供的技术方案可以由通信系统中的通信设备或通信设备中的芯片或处理器实现。该通信设备可以是一种支持多条链路并行传输(即，支持多链路操作(MLO)的无线通信设备，例如，该通信设备可以称为多链路设备(Multi-Link Device，MLD)或多频段设备。相比于仅支持单条链路传输的通信设备来说，多链路设备具有更高的传输效率和更大的吞吐率。
在本申请的一些实施例所提供的技术方案中，通过生成第一请求帧，以请求针对指定类型的数据包采用多链路进行传输，使得对于实时性要求较高的业务，可以通过多条链路进行传输来保证数据传输的可靠性，进而可以在网络环境较差或者传输链路拥塞的情况下，提高业务数据包传输的效率和可靠性。
本申请实施例中将同时支持多条链路的下一代802.11标准站设备称为多链路设备，多链路设备可以为接入点多链路设备(AP MLD)或者非接入点多链路设备(Non-AP MLD)。其中负责任何一条链路的内部实体称为站点(STA)。如果某MLD内部的所有STA是接入点(Access Point，AP)，则可以进一步称其为AP MLD；如果某MLD内部的所有STA是非接入点站点(non-access point station，non-AP STA)，则可以进一步称其为non-AP MLD。换句话说，多链路设备包括一个或多个隶属的站点(affiliated STA)，隶属的站点是一个逻辑上的站点，可以工作在一条链路或一个频段或一个信道上。其中，隶属的站点可以为AP或non-AP STA。802.11be将隶属的站点为AP的多链路设备称为AP多链路设备(AP multi-link device，AP MLD)，隶属的站点为non-AP STA的多链路设备称为non-AP多链路设备(non-AP multi-link device，non-AP MLD)。
参见图1所示，在一个示例性的无线通信系统中，包括至少一个AP MLD(如图1中的AP MLD 101)和至少一个non-AP MLD(如图1中的non-AP MLD 102和non-AP MLD 103)。其中，non-AP MLD可以与AP MLD之间采用多条链路进行通信，从而达到提升吞吐率的效果。non-AP MLD中的一个STA也可以与AP MLD中的一个AP通过一条链路进行通信。可理解的，图1中AP MLD和non-AP MLD的个数，仅是示例性的，根据实现需要，可以具有任意数目的AP MLD和non-AP MLD。
示例性的，多链路设备为具有无线通信功能的装置，该装置可以为一个整机的设备，还可以是安装在整机设备中的芯片或处理系统等，安装这些芯片或处理系统的设备可以在这些芯片或处理系统的控制下，实现本申请实施例的方法和功能。例如，本申请实施例中的non-AP MLD具有无线收发功能，可以支持802.11系列协议，可以与单链路AP，AP MLD或其他non-AP MLD进行通信。例如，non-AP MLD是允许用户与AP通信进而与WLAN通信的任何用户通信设备。例如，non-AP MLD可以为智能手机、平板电脑、笔记本电脑、台式计算机、智能电视、智能家居、车载终端、飞行器等可以联网的用户设备，或物联网中的物联网节点，或车联网中的车载通信装置等；non-AP MLD还可以为上述这些终端中的芯片和处理系统。本申请实施例中的AP MLD可以为non-AP MLD提供服务的装置，可以支持802.11系列协议。例如，AP MLD可以为通信服务器、路由器、交换机、网桥等通信实体，或，AP可以包括各种形式的宏基站，微基站，中继站等，当然AP还可以为这些各种形式的设备中的芯片和处理系统，从而实现本申请实施例的方法和功能。
可理解的，多链路设备可以支持高速率低时延的传输，随着无线局域网应用场景的不断演进，多链路设备还可以应用于更多场景中，比如为智慧城市中的传感器节点(如智能水表、智能电表、智能空气检测节点)；智慧家居中的智能设备(如智能摄像头、投影仪、显示屏、电视机、音响、电冰箱、洗衣机等)；智能办公中智能设备(如打印机、投影仪等)；日常生活场景中的一些基础设施(如自动售货机、商超的自助导航台、自助收银设备、自助点餐机等)。本申请实施例中对于non-AP MLD和AP的具体形式不做限定，在此仅是示例性说明。其中，802.11协议可以为支持802.11be或兼容802.11be的协议。
虽然本申请实施例主要以WLAN为例，尤其是应用于IEEE 802.11系列标准的网络为例进行说明。本领域技术人员容易理解，本申请实施例涉及的各个方面可以扩展到采用各种标准或协议的其它网络。
以下对本申请实施例的技术方案的实现细节进行详细阐述：
图2示出了根据本申请的一些实施例的多链路通信方法的流程图，该多链路通信方法可以由具有无线通信功能的装置来执行，该具有无线通信功能的装置可以是图1中所示的AP MLD，也可以是non-AP MLD。参照图2所示，该多链路通信方法至少包括S210至S220，详细介绍如下：
在S210中，由所述多链路设备的介质访问控制MAC层生成第一请求帧，该第一请求帧用于请求在所述多链路设备和对端多链路设备之间开启针对指定类型的数据包的多链路传输。
在一些实施例中，指定类型的数据包可以是低时延数据包，例如多媒体业务数据包，比如游戏业务数据包、虚拟现实(Virtual Reality，VR)业务数据包、增强现实(Augmented Reality，AR)业务数据包、混合现实(Mixed Reality，MR)业务数据包、扩展现实(Extended Reality，XR)业务数据包、XR和媒体服务(XR and Media Services，XRM)业务数据包、影像现实(Cinematic Reality，CR)业务数据包等。
在一些实施例中，具有无线通信功能的装置在接收到当前业务数据包时，可以根据当前业务数据包的包头中所包含的指定标志位的值来确定当前业务数据包是否为指定类型的数据包。在一些实施例中，指定标志位可以是包头中服务类型(TOS)字段中的标志位。在一些实施例中，具有无线通信功能的装置可以是多链路设备MLD。
在一些实施例中，具有无线通信功能的装置一般包含有站点管理实体(Station Management Entity，SME)层、介质访问控制(Medium Access Control，MAC)层和物理(Physical，PHY)层。因此在生成第一请求帧时，MLD MAC层可以接收MLD的SME发送的针对指定类型的数据包进行多链路传输的使能(enable)请求(request)；然后基于该使能请求生成第一请求帧。
在一些实施例中，如果发起使能请求的所述多链路设备为接入点设备(即AP MLD)，则该使能请求中包含有以下信息中的至少一个：对端多链路设备(即目标非接入点的站点设备(即non-AP MLD))的MAC地址、用于对指定类型的数据包进行多链路传输的对话令牌(Dialog Token)、对指定类型的数据包进行多链路传输的参数。
在一些实施例中，如果发起使能请求的所述多链路设备为非接入点的站点设备(即non-AP MLD)，则该使能请求中包含有以下信息中的至少一个：对端多链路设备(即站点设备关联的接入点设备(即AP MLD))的MAC地址、用于对指定类型的数据包进行多链路传输的对话令牌。
在一些实施例中，第一请求帧中可以包含有以下字段信息中的至少一个：用于指示第一请求帧类型的字段(Category)、用于指示第一请求帧采用受保护的超高吞吐量操作的字段(Protected EHT Action)、用于指示对话令牌的字段、用于指示是否开启指定类型的数据包进行多链路传输的字段。
在一些实施例中，具有无线通信功能的装置在生成第一请求帧时，可以获取订阅服务提供商网络(Subscription Service Provider Network，SSPN)针对指定类型的数据包的服务访问权限，如果根据该服务访问权限确定SSPN允许针对指定类型的数据包采用多链路进行传输，则生成第一请求帧。
继续参照图2所示，在S220中，由所述多链路设备的介质访问控制MAC层向所述对端多链路设备发送第一请求帧。
在一些实施例中，如果第一请求帧是由接入点设备(即AP MLD)生成的，那么接入点设备可以将第一请求帧发送给非接入点的站点设备(即non-AP MLD)；如果第一请求帧是由非接入点的站点设备(即non-AP MLD)生成的，那么站点设备可以将第一请求帧发送给接入点设备(即AP MLD)，或者也可以发送给其它站点设备。
在一些实施例中，具有无线通信功能的装置在发送第一请求帧之后，可以由所述多链路设备的MAC层接收所述对端多链路设备发送的、针对第一请求帧的响应帧，该响应帧用于指示所述对端多链路设备是否允许开启针对指定类型的数据包的多链路传输。
在一些实施例中，响应帧中可以包含有以下字段信息中的至少一个：用于指示响应帧类型的字段(Category)、用于指示响应帧采用受保护的超高吞吐量操作的字段(Protected EHT Action)、用于指示对话令牌的字段、用于指示是否开启指定类型的数据包的多链路传输的字段，以及用于指示响应结果的状态码字段(Status Code Field)。
在一些实施例中，状态码字段可以用于指示允许开启针对指定类型的数据包的多链路传输；或者状态码字段可以用于指示拒绝开启针对指定类型的数据包的多链路传输；或者状态码字段可以用于指示拒绝开启针对指定类型的数据包的多链路传输的原因；或者状态码字段可以用于指示拒绝开启针对指定类型的数据包的多链路传输，以及指示拒绝开启针对指定类型的数据包的多链路传输的原因。
在一些实施例中，具有无线通信功能的装置在接收针对第一请求帧的响应帧之后，MLD MAC层可以向SME发送针对指定类型的数据包进行多链路传输的使能(enable)确认(confirm)。在一些实施例中，该使能确认中可以包含有用于指示响应结果的状态码字段；其中，状态码字段可以用于指示允许开启针对指定类型的数据包的多链路传输；或者状态码字段可以用于指示拒绝开启针对指定类型的数据包的多链路传输；或者状态码字段可以用于指示拒绝开启针对指定类型的数据包的多链路传输的原因；或者状态码字段可以用于指示拒绝开启针对指定类型的数据包的多链路传输，以及指示拒绝开启针对指定类型的数据包的多链路传输的原因。
在一些实施例中，在针对指定类型(例如，低时延)的数据包建立了多链路传输之后，当多链路设备收到业务数据包时，由所述多链路设备的MAC层根据所述业务数据包的包头中所包含的指定标志位的值，确定所述业务数据包是否为指定类型的数据包。
基于确定所述业务数据包时所述指定类型的数据包，对所述业务数据包进行多链路传输；其中，所述指定标志位包括所述包头中服务类型(TOS)字段中的标志位。
在本申请实施例提供的方法中，通过识别数据包包头(如TOS字段)中的标志位，MAC层可快速区分低时延类数据包，并自动触发多链路并行传输，减少排队和链路切换延迟。而且，仅对指定类型(如高优先级)数据包启用多链路传输，避免普通数据包占用额外链路资源，提升整体带宽利用率。此外，在MAC层实现分类决策，无需上层协议反复介入，降低了处理开销。该机制实现了关键业务数据的低时延、高可靠传输，同时维持了网络资源的合理分配。
在一些实施例中，在针对指定类型的数据包建立了多链路传输之后，如果需要停止进行多链路传输，那么具有无线通信功能的装置可以生成第二请求帧，该第二请求帧用于请求解除所述多链路设备和所述对端多链路设备之间已建立的针对指定类型的数据包的多链路传输，然后可以发送第二请求帧。
在本申请实施例中，通过第二请求帧主动终止指定业务的多链路传输，避免持续占用冗余链路，释放带宽资源供其他业务使用。而且，仅针对特定业务类型(如低时延会话结束)触发解除流程，维持其他业务的多链路连接，实现细粒度资源管理。此外，MAC层生成标准化的控制帧(第二请求帧)，确保对端设备同步解除多链路绑定，防止数据包乱序或丢包。本申请实施例的方案在保障关键业务传输的同时，提升了多链路系统的动态适应性和整体资源利用率。
在一些实施例中，如果第二请求帧是由接入点设备(即AP MLD)生成的，那么接入点设备可以将第二请求帧发送给非接入点的站点设备(即non-AP MLD)；如果第二请求帧是由非接入点的站点设备(即non-AP MLD)生成的，那么站点设备可以将第二请求帧发送给接入点设备(即AP MLD)，或者也可以发送给其它站点设备。
在一些实施例中，在生成第二请求帧时，可以接收多链路设备的SME发送的针对指定类型的数据包的多链路传输的停止请求(tear down request)；然后基于停止请求生成第二请求帧。
在一些实施例中，如果发送第二请求帧的多链路设备为接入点设备(即AP MLD)，则该停止请求中包含有：非接入点的站点设备(即non-AP MLD)的MAC地址。
在一些实施例中，如果发送第二请求帧的多链路设备为非接入点的站点设备(即non-AP MLD)，则该停止请求中包含有站点设备关联的接入点设备(即AP MLD)的MAC地址。在一些实施例中，在一些场景下，例如已建立会话标识符，在需要向关联的接入点设备发送该停止请求时，停止请求中也可以不包含站点设备关联的接入点设备(即AP MLD)的MAC地址，从而降低信令负荷，减少帧开销。
图3示出了根据本申请的一些实施例的多链路通信方法的流程图，该多链路通信方法可以由具有无线通信功能的装置来执行，该具有无线通信功能的装置可以是图1中所示的AP MLD，也可以是non-AP MLD。参照图3所示，该多链路通信方法至少包括S310至S330，详细介绍如下：
在S310中，由多链路设备的MAC层接收第一请求帧，该第一请求帧用于请求在对端多链路设备和所述多链路设备之间开启针对指定类型的数据包的多链路传输。
在一些实施例中，第一请求帧中可以包含有以下字段信息中的至少一个：用于指示所述第一请求帧类型的字段(Category)、用于指示所述第一请求帧采用受保护的超高吞吐量操作的字段(Protected EHT Action)、用于指示对话令牌的字段、用于指示是否开启指定类型的数据包的多链路传输的字段。
在S320中，由所述多链路设备的MAC层生成针对第一请求帧的响应帧，该响应帧用于指示所述多链路设备是否允许开启针对指定类型的数据包的多链路传输。
在一些实施例中，响应帧中可以包含有以下字段信息中的至少一个：用于指示响应帧类型的字段(Category)、用于指示响应帧采用受保护的超高吞吐量操作的字段(Protected EHT Action)、用于指示对话令牌的字段、用于指示是否开启指定类型的数据包的多链路传输的字段，以及用于指示响应结果的状态码字段(Status Code Field)。
在一些实施例中，状态码字段可以用于指示允许开启针对指定类型的数据包的多链路传输；或者状态码字段可以用于指示拒绝开启针对指定类型的数据包的多链路传输；或者状态码字段可以用于指示拒绝开启针对指定类型的数据包的多链路传输的原因；或者状态码字段可以用于指示拒绝开启针对指定类型的数据包的多链路传输，以及指示拒绝开启针对指定类型的数据包的多链路传输的原因。
在一些实施例中，具有无线通信功能的装置在接收到第一请求帧之后，MLD MAC层可以向SME发送针对指定类型的数据包进行多链路传输的使能(enable)指示(indication)。如果接收到SME发送的针对指定类型的数据包进行多链路传输的使能(enable)响应(response)，则生成针对第一请求帧的响应帧。
在S330中，由所述多链路设备的MAC层向所述对端多链路设备发送响应帧。
在一些实施例中，如果响应帧是由接入点设备(即AP MLD)生成的，那么接入点设备可以将响应帧发送给发送第一请求帧的非接入点的站点设备(即non-AP MLD)；如果响应帧是由非接入点的站点设备(即non-AP MLD)生成的，那么站点设备可以将响应帧发送给发送第一请求帧的接入点设备(即AP MLD)，或者也可以发送给发送第一请求帧的其它站点设备。
在一些实施例中，在针对指定类型的数据包建立了多链路传输之后，如果接收到用于指示针对指定业务类型的数据包停止进行多链路传输的第二请求帧，那么MLD MAC层可以向SME发送针对指定业务类型的数据包的多链路传输的停止指示(tear down indication)。
需要说明的是，在上述实施例中，第一请求帧和第二请求帧可以是管理帧，或者也可以是其它类型的帧。
以下以指定类型的数据包是低时延的游戏数据包为例，对本申请实施例的技术方案进行详细阐述：
由于游戏对实时性要求非常高，比如在游戏中玩家最关心的是自己的射击结果和角色的存活与否，各类消息实时性更新，这对底层游戏数据的传输效率和可靠性提出了更高的要求，保障游戏数据传输效率和可靠性显得尤为重要。而相关技术中的处理方式都是将游戏数据映射到高优先等级，也就是所有的游戏运营商基于流量标识符(Traffic Identifier，TID)将自己的游戏数据映射到高优先等级，如果同时有多个游戏运营商游戏在线，必然会引起数据传输拥塞和不可靠性。
基于相关技术中存在的上述问题，本申请实施例的技术方案提出了在AP(如AP-MLD)和STA(如Non-AP MLD)之间建立数据包级别的连接后，各自都能够根据自身所处的无线环境或者业务承载情况来对低时延业务(如游戏业务)的数据包进行多链路传输或者选择另外的链路传输，即本申请实施例的技术方案可以实现数据包级别的更精细的多链路传输，本申请实施例的技术方案可以应用在802.11be及以后的标准中。
如图4所示，游戏业务的IP数据包的IP包头包括如下的字段：
版本：占4位。用于表示IP协议的版本，如果是IPv4的话，那么固定为4。
头部长度：占4位。用于表示IP头部的长度，单位为字(即4个字节)。由于其最大值为15，所以IP头部最长为60字节(15×4)。
服务类型(TOS)：占8位。用于定义不同的服务类型，可以为IP数据包提供不同的服务。
总长度：占16位。用于表示整个IP数据包的长度，包括数据与IP头部，所以IP数据包的最大长度为65535字节。
ID：占16位。用于标识不同的IP数据包。该字段和Flags、分片偏移量字段配合使用，对较大的IP数据包进行分片操作。
标记(Flags)：占3位。该字段第一位不使用，第二位是DF(Don't Fragment)位，DF位设为1时表明路由器不能对该数据包分段。第三位是MF(More Fragments)位，表示当前分片是否为IP数据包的最后一个分片，如果是最后一个分片，就设置为0，否则设置为1。
分片偏移量：占13位。用于表示当前分片位于IP数据包分片组中的位置，接收端靠此来组装还原IP数据包。
生存期(Time To Live，TTL)：占8位。当IP数据包进行发送时，先会对该字段赋予某个特定的值。当IP数据包经过沿途每一个路由器时，每个沿途的路由器会将该IP数据包的TTL值减少1。如果TTL减少至0，则该IP数据包会被丢弃。这个字段可以防止由于路由环路而导致IP数据包在网络中不停被转发。
上层协议：占8位。标识了上层所使用的协议，例如常用的传输控制协议(Transmission Control Protocol，TCP)、用户数据报协议(User Datagram Protocol，UDP)等。
校验和：占16位。用于对IP头部的正确性进行检测，但不包含数据部分，因为每个路由器要改变TTL的值，所以路由器会为每个通过的IP数据包重新计算这个值。
源IP地址与目标IP地址：这两个字段都占32位。标识了这个IP数据包的源IP地址和目标IP地址。
IP选项：长度可变，最多包含40字节。
在IEEE协议中，差分服务代码点(Differentiated Services Code Point)与TID映射只占用了IP头中服务类型(TOS)中的高6bit，剩下的低位2bit是保留的，没有作为其它用途，因此可以用第一个bit作为flag来标识低时延数据包，然后AP MLD与Non-AP MLD通过信令消息建立低时延数据包级别的多链路传输，MAC层收到IP包后，解析IP头中的TOS字段，获得flag值，然后对该业务数据包进行多链路传输或者选择更好的链路进行传输。
在一些实施例中，建立AP MLD与Non-AP MLD数据包级别的多链路需新增游戏数据多链路接入使能请求(Game Data Multi-Link Access Enable Request，GDM Access Enable Request)、游戏数据多链路接入使能响应(Game Data Multi-Link Access Enable Response，GDM Access Enable Response)、游戏数据多链路接入消除(Game Data Multi-Link Access Teardown，GDM Access Teardown)三条消息，同时需要在受保护的操作字段(Protected Action field)中新增3个values，如下表1所示：

表1
在一些实施例中，Game Data Multi-Link Access Enable Request帧的定义可以如下表2所示：
表2
其中，表2中的类型(Category)字段定义在标准协议中的“Action field”章节。受保护的EHT操作(Protected EHT Action)字段定义在标准协议中的“Protected EHC Action field”章节，本申请实施例中新增了GDM Access Enable Request、GDM Access Enable Response、GDM Access Teardown三种值。对话令牌(Dialog Token)字段定义在标准协议中的“Dialog Token field”章节，可以设置为非零值来区分GDM Enable Access Request/Response帧。Game Data Multi-Link Access element用于指示是否开启游戏数据多link传输。
在一些实施例中，如果Game Data Multi-Link Access Enable Request帧中存在Game Data Multi-Link Access element，那么可以指示开启游戏数据多link传输；如果Game Data Multi-Link Access Enable Request帧中不存在Game Data Multi-Link Access element，那么可以指示不开启游戏数据多link传输。或者也可以通过设置不同的值来指示是否开启游戏数据多link传输。
在一些实施例中，Game Data Multi-Link Access Enable Response帧的定义可以如下表3所示：
表3
其中，表3中的类型(Category)字段定义在标准协议中的“Action field”章节。受保护的EHT操作(Protected EHT Action)字段定义在标准协议中的“Protected EHC Action field”章节，本申请实施例中新增了GDM Access Enable Request、GDM Access Enable Response、GDM Access Teardown三种值。作为对应于GDM Access Enable Request帧的响应，Dialog Token field设置成Game Data Multi-Link Access Enable Request帧里的值，当GDM Access Enable Response帧以主动模式发送时，Dialog Token field可以设置为0。状态码(Status Code)定义在标准协议中的“Status Code field”章节，当GDM响应帧是以unsolicited(未经请求的)模式发送时，可以设置为0。
Game Data Multi-Link Access element用于指示是否开启游戏数据多link传输。在一些实施例中，如果Game Data Multi-Link Access Enable Request帧中存在Game Data Multi-Link Access element，那么可以指示开启游戏数据多link传输；如果Game Data Multi-Link Access Enable Request帧中不存在Game Data Multi-Link Access element，那么可以指示不开启游戏数据多link传输。或者也可以通过设置不同的值来指示是否开启游戏数据多link传输。
在一些实施例中，Game Data Multi-Link Access Teardown帧的定义可以如下表4所示：
表4
其中，表4中的类型(Category)字段定义在标准协议中的“Action field”章节。受保护的EHT操作(Protected EHT Action)字段定义在标准协议中的“Protected EHC Action field”章节，本申请实施例中新增了GDM Access Enable Request、GDM Access Enable Response、GDM Access Teardown三种值。
在一些实施例中，针对状态码(Status Code)，本申请的实施例可以新增三个Status Code值以对GDM Access支持，如下表5所示：
表5
需要说明的是，在本申请的其它实施例中，也可以新增更多的Status Code值以对GDM Access进行支持。
在一些实施例中，可以在MAC Capabilities中新增字段以指示AP MLD或者Non-AP MLD对GDM Access的支持，具体而言，MAC Capabilities中包含的字段如图5所示。具体包含了：应急准备通信服务(Emergency Preparedness Communications Service，EPCS)优先接入支持(EPCS priority Access Support)、EHT操作模式控制支持(EHT OM Control Support)、触发传输机会分享模式1支持(Triggered TXOP Sharing Mode 1Support)、触发传输机会分享模式2支持(Triggered TXOP Sharing Mode 2Support)、受限制的目标唤醒时间支持(Restricted Target Wake Time Support)、子载波间隔业务描述支持(Sub–Carrier Space Traffic Description Support)、最大MPDU长度(Maximum MPDU Length)、最大A-MPDU长度指数扩展(Maximum A-MPDU Length Exponent Extension)、EHT跟随参考信号支持(EHT Tracking Reference Signal Support)、触发TXOP共享模式下的TXOP返回支持(TXOP Return Support In Triggered TXOP Sharing Mode)、两个带宽询问报告支持(Two BQRs Support)、支持EHT链路适配(EHT Link Adaptation Support)、GDM接入支持(GDM Access Support)和保留字段(Reserved)。其中，BQR指的是带宽询问报告(Bandwidth Query Report)；TXOP指的是传输机会(Transmission Opportunity)；MPDU指的是MAC协议数据单元(MAC Protocol Data Unit)；A-MPDU指的是聚合的MAC协议数据单元(Aggregation MAC Protocol Data Unit)。
在图5所示的字段中，GDM接入支持(GDM Access Support)为本申请实施例中新增加的字段。即在本申请的实施例中，可以在B14位新增对GDM Access的支持，新增B14为GDM Access Support后，剩下B15为保留位。
在一些实施例中，可以新增对GDM Access支持的element ID，如下表6所示：
表6
在一些实施例中，GDM Access element的定义如图6所示，包括：元素ID(Element ID)、长度(Length)、元素ID扩展(Element ID Extension)、GDM接入标志(GDM Access Flags)。
在一些实施例中，GDM Access Flag是否支持多链路传输定义如图7所示，可以通过一个标志位来进行指示。比如，若该标志位的值为1，则说明书支持多链路传输；如果该标志位的值为0，则说明不支持多链路传输。
在一些实施例中，可以在Multi-Link element中的Multi-Link域中新增对GDM Access支持的类型，如下表7所示：
表7
基于上述实施例中新增的信息，就可以在Multi-Link element中携带GDM Access element元素。
在一些实施例中，本申请中可以新增6条原语对GDM Access进行支持：GDM接入使能请求原语(MLME-GDMACCESSENABLE.request)、GDM接入使能指示原语(MLME-GDMACCESSENABLE.indication)、GDM接入使能响应原语(MLME-GDMACCESSENABLE.response)、GDM接入使能确认原语(MLME-GDMACCESSENABLE.confirm)、GDM接入消除请求原语(MLME-GDMACCESSTEARDOWN.request)、GDM接入消除指示原语(MLME-GDMACCESSTEARDOWN.indication)。其中，MLME指的是MAC层管理实体(MAC Layer Management Entity)，以下对各个原语进行说明。
在一些实施例中，MLME-GDMACCESSENABLE.request原语用于向对端MAC实体发起请求以启用GDM Access。
原语参数如下：
其中，PeerSTAAddress、Dialog Token和GDMAccessMultiLink的相关说明参照下表8所示：

表8
MLME-GDMACCESSENABLE.request原语由SME生成，用于向对端MAC实体发送请求以启用GDM Access。
在一些实施例中，MLME-GDMACCESSENABLE.confirm原语用于报告对端MAC实体的GDM Access请求的响应。
原语参数如下：
其中，PeerSTAAddress、Dialog Token、Status Code和GDMAccessMultiLink的相关说明参照下表9所示：

表9
MLME-GDMACCESSENABLE.confirm原语由MLME在收到GDM Access启用后生成来自对端MAC实体的响应帧。
在一些实施例中，MLME-GDMACCESSENABLE.indication原语指示已从对端MAC实体接收到GDM Access Enable Request的请求。
原语参数如下：
其中，PeerSTAAddress、Dialog Token和GDMAccessMultiLink的相关说明参照下表10所示：

表10
MLME-GDMACCESSENABLE.indication原语由MLME在收到来自对端MAC实体的GDM Access Enable Request帧后生成。
在一些实施例中，MLME-GDMACCESSENABLE.response原语由MLME生成，用于向对端MAC实体发送启用GDM Access的响应。
原语参数如下：
其中，PeerSTAAddress、Dialog Token、Status Code和GDMAccessMultiLink的相关说明参照下表11所示：

表11
MLME-GDMACCESSENABLE.response原语由SME生成，作为对MLME-GDMACCESSENABLE.indication原语的响应。
在一些实施例中，MLME-GDMACCESSTEARDOWN.request原语用于指示对端MAC实体torn down GDM Access接入。
原语参数如下：
MLME-GDMACCESSTEARDOWN.request(
PeerSTAAddress(对端STA地址),
)
其中，PeerSTAAddress的相关说明参照下表12所示：
表12
MLME-GDMACCESSENABLE.response原语是在STA想要torn down GDM Access接入时，由SME生成的。
在一些实施例中，MLME-GDMACCESSTEARDOWN.indication原语用于指示对端MAC实体解除GDM Access接入。
原语参数如下：
MLME-GDMACCESSTEARDOWN.indication(
PeerSTAAddress(对端STA地址),
)
其中，PeerSTAAddress的相关说明参照下表13所示：

表13
MLME-GDMACCESSTEARDOWN.indication原语是由MLME在收到来自对端MAC实体的GDM Access Enable Teardown帧后生成。
在一些实施例中，为了支持GDM Access，本申请实施例中可以增加抽象语法标记(Abstract Syntax Notation One，ASN.1)消息。具体地，可以在Dot11EHTStationConfigEntry(即EHT站点配置条目)中增加ASN.1消息dot11EHTGDMAccessActivated(即EHT GDM接入已激活)，并且可以将该消息设置为对象类型。在一些实施例中，dot11EHTGDMAccessActivated可以是一个控制变量，它由外部管理实体或SME编写。在实际过程中，对其更改会尽快生效。此属性为true时，表示MLD支持GDM接入能力；如果该属性为false，则MLD不支持GDM接入能力。
同时，也可以在Dot11InterworkingEntry(即交互工作条目)中增加ASN.1消息dot11GDMAccessAuthorized(即GDM接入授权)，并且可以将该消息设置为对象类型。在一些实施例中，dot11GDMAccessAuthorized可以是一个控制变量，它是在AP从SSPN接口接收到非AP STA使用GDM接入的许可之后由SME编写的。当该属性值为true时，表示允许非AP STA调用和使用GDM访问能力；如果该属性值为假，则不允许非AP STA调用和使用GDM接入能力。
在一些实施例中，GDM接入是由SME发起在MAC上建立的。GDM AP-MLD与其关联的GDM Non-AP MLD之间的GDM接入可以处于两种状态：enabled或torn down。在一些实施例中，AP MLD和None-AP MLD都可以将dot11EHTGDMAccessActivated设置为true。
附属于GDM MLD的STA会将其发送的MAC Capabilities Information field中的子字段GDM Access Support设置为1，表示可以支持GDM接入，否则设置为0。在(重)关联过程中，AP MLD获取验证Non-AP MLD使用GDM Access所需的信息。并且可以将dot11SSPNInterfaceActivated设置为true以支持在None-AP MLD关联期间通过SSPN接口检索None-AP MLD所对应的GDM服务访问权限提供商。
成功获得Non-AP MLD使用GDM接入许可的AP MLD应更新dot11Inter workingEntry中关于Non-AP MLD dot11GDMAccessAuthorized的值。如果没有获得具有管理帧保护的健壮安全网络关联(Robust Security Network Association，RSNA)成功协商并允许GDM接入，AP MLD和Non-AP MLD都不能向对方发送GDM Access Enable Request帧来发起GDM接入。
基于上述实施例中的说明，在本申请的一些实施例中，如图8所示GDM接入流程具体为：发起方(如AP MLD或者Non-AP MLD)的MLD SME在检测到游戏数据包(Game Data)且确定允许多链路接入时，向发起方的MLD MAC发送MLME-GDMACCESSENABLE.request。MLD MAC在接收到该原语之后，向响应方(如AP MLD或者Non-AP MLD)的MLD MAC发送GDM Access Enable Request frame，然后响应方的MLD MAC可以向响应方的MLD SME发送MLME-GDMACCESSENABLE.indication。
响应方的MLD SME在接收到MLME-GDMACCESSENABLE.indication之后，向响应方的MLD MAC发送MLME-GDMACCESSENABLE.response。响应方的MLD MAC在接收到MLME-GDMACCESSENABLE.response之后，可以向发起方的MLD MAC发送GDM Access Enable Response frame，然后发起方的MLD MAC向发起方的MLD SME发送MLME-GDMACCESSENABLE.confirm。在这种情况下，如果响应方反馈的响应帧中是同意进行GDM接入，那么发起方与响应方之间完成了GDM接入过程，进而可以通过多链路来传输游戏业务的数据包。
在本申请的一些实施例中，如图9所示GDM消除(Teardown)流程具体为：发起方(如AP MLD或者Non-AP MLD)的MLD SME在需要Teardown GDM接入时，向发起方的MLD MAC发送MLME-GDMACCESSTEARDOWN.request。MLD MAC在接收到该原语之后，向响应方(如AP MLD或者Non-AP MLD)的MLD MAC发送GDM Access Enable Teardown frame，然后响应方的MLD MAC可以向响应方的MLD SME发送MLME-GDMACCESSTEARDOWN.indication，以消除GDM接入。
在本申请的一些实施例中，当GDM接入的MLD高层发出指示时，可以torn down GDM接入状态。发起方和响应方都会设置GDM接入状态为torn down状态并应用于MLD之间所有启用的链路。
在本申请的一些实施例中，AP MLD和Non-AP MLD建立多链路GDM Access Enable流程如图10所示：发起方(如AP MLD或者Non-AP MLD)在检测到游戏数据包(Game Data)且确定允许多链路接入时，向响应方(如AP MLD或者Non-AP MLD)发送GDM Access Enable Response frame。在这种情况下，如果响应方反馈的Response frame中是同意进行GDM接入，那么发起方与响应方之间完成了GDM接入过程，进而可以通过多链路来传输游戏业务的数据包。
在本申请的一些实施例中，AP MLD和Non-AP MLD建立多链路GDM Access Teardown流程如图11所示：发起方(如AP MLD或者Non-AP MLD)在需要Teardown GDM接入时，向响应方(如AP MLD或者Non-AP MLD)发送GDM Access Enable Teardown frame，以消除GDM接入。
综上，本申请实施例的技术方案主要是在无线通信技术领域，尤其涉及到在Wi-Fi无线网络中多个无线终端进行低时延业务时出现的业务拥塞或者通信链路覆盖弱的场景，STA和AP通过管理消息建立基于数据包级的多链路传输，这样该低时延业务就能够选择更好的链路或者副本在多条链路传输，提高该业务的传输可靠性，提高传输效率。具体而言，本申请实施例中通过新建三条管理消息来建立STA与AP基于数据包级别的多链路传输链路，同时新增6条原语来支持创建三条管理消息；本申请实施例中新增配置字段dot11EHTGDMAccessActivated来指示STA和AP都具备支持数据包级别的多链路传输能力，同时在MAC capabilities新增GDM Access支持并设置为true；本申请实施例中的STA或者AP会向对方发送GDM Access Enable Request帧，对方收到该帧后，会向发送方发送GDM Access Enable Response帧来告诉对方是否接受该时延业务映射到两条或者更多链路来进行数据传输，进而可以在网络覆盖弱或者网络拥塞的情况下，低时延业务能够按照STA或者AP期望的数据包在两条或者多条链路传输或者选择更好的链路传输。
通过本申请实施例的优化，特别是低时延业务传输过程中能够根据网络覆盖状况和业务拥塞情况自适应优化该业务数据包在两条或者多条链路传输，而不是所有数据包在多条链路传输，尤其在无线网络覆盖弱的场景下，或者正在进行的业务存在拥塞场景下，能够提高低时延数据业务包传输的可靠性，提升用户的体验。
需要说明的是，本申请实施例的技术方案除了可以应用于游戏业务之外，也可以应用于其它多媒体业务，比如VR业务、AR业务、MR业务、XR业务、XRM业务、CR业务等。
以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的多链路通信方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的多链路通信方法的实施例。
图12示出了根据本申请的一些实施例的多链路通信装置的框图，该多链路通信装置可以设置在具有无线通信功能的装置内，该具有无线通信功能的装置可以是图1中所示的AP MLD，也可以是non-AP MLD。
参照图12所示，根据本申请的一些实施例的多链路通信装置1200，包括：生成单元1202和发送单元1204。
其中，生成单元1202配置为在所述多链路通信装置的MAC层生成第一请求帧，所述第一请求帧用于请求在所述多链路通信装置和对端多链路通信装置之间开启针对指定类型的数据包的多链路传输；发送单元1204配置为通过所述多链路通信装置的MAC层向所述对端多链路通信装置发送所述第一请求帧。
图13示出了根据本申请的一些实施例的多链路通信装置的框图，该多链路通信装置可以设置在具有无线通信功能的装置内，该具有无线通信功能的装置可以是图1中所示的AP MLD，也可以是non-AP MLD。
参照图13所示，根据本申请的一些实施例的多链路通信装置1300，包括：接收单元1302、生成单元1304和发送单元1306。
其中，接收单元1302配置为在所述多链路通信装置的MAC层接收对端多链路通信装置发送的第一请求帧，所述第一请求帧用于请求在所述对端多链路通信装置和所述多链路通信装置之间开启针对指定类型的数据包的多链路传输；生成单元1304配置为在所述多链路通信装置的MAC层生成针对所述第一请求帧的响应帧，所述响应帧用于指示所述多链路通信装置是否允许开启针对所述指定类型的数据包的多链路传输；发送单元1306配置为由所述多链路通信装置的MAC层向所述对端多链路通信装置发送所述响应帧。
本申请上述实施例提供的多链路通信装置1200和1300的各个功能单元的具体功能实现可以参考前面的各个实施例，在此不再赘述。图14示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图，该电子设备可以是前述实施例中的具有无线通信功能的装置。
需要说明的是，图14示出的电子设备的计算机系统1400仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
如图14所示，计算机系统1400可以包括中央处理单元(Central Processing Unit，CPU)1401，其可以根据存储在只读存储器(Read-Only Memory，ROM)1402中的程序或者从存储部分1408加载到随机访问存储器(Random Access Memory，RAM)1403中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 1403中，还存储有系统操作所需的各种程序和数据。CPU 1401、ROM 1402以及RAM 1403通过总线1404彼此相连。输入/输出(Input/Output，I/O)接口1405也连接至总线1404。
以下部件可以连接至I/O接口1405：包括键盘、鼠标等的输入部分1406；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1407；包括硬盘等的存储部分1408；以及包括诸如LAN(Local Area Network，局域网)卡、调制解调器等的网络接口卡的通信部分1409。通信部分1409经由诸如因特网的网络执行通信处理。驱动器1410也根据需要连接至I/O接口1405。可拆卸介质1411，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1410上，以便于从其上读出的计算机程序根据需要被安装入存储部分1408。
特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序用于执行流程图所示的方法。在这样的实施例中，该计算机程序可以通过通信部分1409从网络上被下载和安装，和/或从可拆卸介质1411被安装。在该计算机程序被中央处理单元(CPU)1401执行时，执行本申请的系统中限定的各种功能。
需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储计算机程序的有形介质，该计算机程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机程序的组合来实现。
描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。
作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个计算机程序，当上述一个或者多个计算机程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台电子设备执行根据本申请实施方式的方法。
比如，电子设备可以是具有无线通信功能的装置，那么具有无线通信功能的装置可以执行图2或者图3所示的多链路通信方法。
本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (20)

  1. 一种多链路通信方法，由多链路设备执行，所述方法包括：
    由所述多链路设备的介质访问控制MAC层生成第一请求帧，所述第一请求帧用于请求在所述多链路设备和对端多链路设备之间开启针对指定类型的数据包的多链路传输；
    由所述多链路设备的介质访问控制MAC层向所述对端多链路设备发送所述第一请求帧。
  2. 根据权利要求1所述的多链路通信方法，其中，所述生成第一请求帧，包括：
    由所述多链路设备的介质访问控制MAC层接收所述多链路设备的站点管理实体SME发送的针对所述指定类型的数据包进行多链路传输的使能请求；
    基于所述使能请求生成所述第一请求帧。
  3. 根据权利要求1或2所述的多链路通信方法，其中
    若所述多链路设备为接入点设备，则所述使能请求中包含有以下信息中的至少一个：非接入点的站点设备的介质访问控制MAC地址、用于对所述指定类型的数据包进行多链路传输的对话令牌、对所述指定类型的数据包进行多链路传输的参数；
    若所述多链路设备为非接入点的站点设备，则所述使能请求中包含有以下信息中的至少一个：所述站点设备关联的接入点设备的MAC地址、用于对所述指定类型的数据包进行多链路传输的对话令牌。
  4. 根据权利要求1至3任一项所述的多链路通信方法，其中，所述第一请求帧中包含有以下字段信息中的至少一个：
    用于指示所述第一请求帧类型的字段、用于指示所述第一请求帧采用受保护的超高吞吐量操作的字段、用于指示对话令牌的字段、用于指示是否开启指定类型的数据包进行多链路传输的字段。
  5. 根据权利要求1至4任一项所述的多链路通信方法，还包括：
    接收所述对端多链路设备发送的针对所述第一请求帧的响应帧，所述响应帧用于指示所述对端多链路设备是否允许开启针对所述指定类型的数据包的多链路传输。
  6. 根据权利要求5所述的多链路通信方法，其中，所述响应帧中包含有以下字段信息中的至少一个：
    用于指示所述响应帧类型的字段、用于指示所述响应帧采用受保护的超高吞吐量操作的字段、用于指示对话令牌的字段、用于指示是否开启指定类型的数据包的多链路传输的字段，以及用于指示响应结果的状态码字段；
    其中，所述状态码字段用于指示以下信息中的一个：允许开启针对所述指定类型的数据包的多链路传输、拒绝开启针对所述指定类型的数据包的多链路传输、拒绝开启针对所述指定类型的数据包的多链路传输的原因。
  7. 根据权利要求5或6所述的多链路通信方法，其中，在接收针对所述第一请求帧的响应帧之后，所述多链路通信方法还包括：
    由所述多链路设备的介质访问控制MAC层向所述多链路设备的SME发送针对所述指定类型的数据包进行多链路传输的使能确认。
  8. 根据权利要求7所述的多链路通信方法，其中，所述使能确认中包含有用于指示响应结果的状态码字段；
    其中，所述状态码字段用于指示以下信息中的一个：允许开启针对所述指定类型的数据包的多链路传输、拒绝开启针对所述指定类型的数据包的多链路传输、拒绝开启针对所述指定类型的数据包的多链路传输的原因。
  9. 根据权利要求1至8任一项所述的多链路通信方法，还包括：
    由所述多链路设备的介质访问控制MAC层生成第二请求帧，所述第二请求帧用于请求解除所述多链路设备和所述对端多链路设备之间已建立的针对指定类型的数据包的多链路传输；
    向所述对端多链路设备发送所述第二请求帧。
  10. 根据权利要求9所述的多链路通信方法，其中，所述生成第二请求帧，包括：
    由所述多链路设备的介质访问控制MAC层接收所述多链路设备的SME发送的针对所述指定类型的数据包的多链路传输的停止请求；
    基于所述停止请求生成所述第二请求帧。
  11. 根据权利要求1至10任一项所述的多链路通信方法，还包括：
    在接收到业务数据包时，由所述多链路设备的介质访问控制MAC层根据所述业务数据包的包头中所包含的指定标志位的值确定所述业务数据包是否为指定类型的数据包；
    基于确定所述业务数据包为所述指定类型的数据包，对所述业务数据包进行多链路传输；
    其中，所述指定标志位包括所述包头中服务类型字段中的标志位。
  12. 根据权利要求1至11中任一项所述的多链路通信方法，其中，所述生成第一请求帧，包括：
    获取订阅服务提供商网络SSPN针对所述指定类型的数据包的服务访问权限；
    若根据所述服务访问权限确定SSPN允许针对所述指定类型的数据包采用多链路进行传输，则生成所述第一请求帧。
  13. 一种多链路通信方法，由多链路设备执行，包括：
    由所述多链路设备的介质访问控制MAC层接收对端多链路设备发送的第一请求帧，所述第一请求帧用于请求在所述对端多链路设备和所述多链路设备之间开启针对指定类型的数据包的多链路传输；
    由所述多链路设备的介质访问控制MAC层生成针对所述第一请求帧的响应帧，所述响应帧用于指示所述多链路设备是否允许开启针对所述指定类型的数据包的多链路传输；
    由所述多链路设备的介质访问控制MAC层向所述对端多链路设备发送所述响应帧。
  14. 根据权利要求13所述的多链路通信方法，其中，生成针对所述第一请求帧的响应帧，包括：
    在接收到所述第一请求帧之后，由所述多链路设备的介质访问控制MAC层向所述多链路设备的SME发送针对所述指定类型的数据包进行多链路传输的使能指示；
    若接收到所述SME发送的针对所述指定类型的数据包进行多链路传输的使能响应，则由所述多链路设备的介质访问控制MAC层生成针对所述第一请求帧的响应帧。
  15. 根据权利要求13或14所述的多链路通信方法，还包括：
    由所述多链路设备的介质访问控制MAC层接收所述对端多链路设备发送的第二请求帧，所述第二请求帧用于请求解除所述对端多链路设备和所述多链路设备之间已建立的针对指定类型的数据包的多链路传输；
    向所述SME发送针对所述指定类型的数据包进行多链路传输的停止指示。
  16. 一种多链路通信装置，包括：
    生成单元，配置为在所述多链路通信装置的介质访问控制MAC层生成第一请求帧，所述第一请求帧用于请求在所述多链路通信装置和对端多链路通信装置之间开启针对指定类型的数据包的多链路传输；
    发送单元，配置为通过所述多链路通信装置的介质访问控制MAC层向所述对端多链路通信装置发送所述第一请求帧。
  17. 一种多链路通信装置，包括：
    接收单元，配置为在所述多链路通信装置的介质访问控制MAC层接收对端多链路通信装置发送的第一请求帧，所述第一请求帧用于请求在所述对端多链路通信装置和所述多链路通信装置之间开启针对指定类型的数据包的多链路传输；
    生成单元，配置为在所述多链路通信装置的介质访问控制MAC层生成针对所述第一请求帧的响应帧，所述响应帧用于指示所述多链路通信装置是否允许开启针对所述指定类型的数据包的多链路传输；
    发送单元，配置为由所述多链路通信装置的介质访问控制MAC层向所述对端多链路通信装置发送所述响应帧。
  18. 一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1至15中任一项所述的多链路通信方法。
  19. 一种电子设备，包括：
    一个或多个处理器；
    存储器，用于存储一个或多个计算机程序，当所述一个或多个计算机程序被所述一个或多个处理器执行时，使得所述电子设备实现权利要求1至15中任一项所述的多链路通信方法。
  20. 一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序存储在计算机可读存储介质中，电子设备的处理器从所述计算机可读存储介质读取并执行所述计算机程序，使得所述电子设备执行权利要求1至15中任一项所述的多链路通信方法。
PCT/CN2025/099513 2024-07-04 2025-06-06 多链路通信方法、装置、计算机可读介质及电子设备 Pending WO2026007613A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP25831967.2A EP4794444A1 (en) 2024-07-04 2025-06-06 Multi-link communication method and apparatus, and computer-readable medium and electronic device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410895734.4 2024-07-04
CN202410895734.4A CN121284764A (zh) 2024-07-04 2024-07-04 多链路通信方法、装置、计算机可读介质及电子设备

Publications (1)

Publication Number Publication Date
WO2026007613A1 true WO2026007613A1 (zh) 2026-01-08

Family

ID=98237695

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2025/099513 Pending WO2026007613A1 (zh) 2024-07-04 2025-06-06 多链路通信方法、装置、计算机可读介质及电子设备

Country Status (3)

Country Link
EP (1) EP4794444A1 (zh)
CN (1) CN121284764A (zh)
WO (1) WO2026007613A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114679795A (zh) * 2020-12-24 2022-06-28 华为技术有限公司 无线局域网中的通信方法、装置及系统
US20230262786A1 (en) * 2022-02-15 2023-08-17 Huawei Technologies Co., Ltd. System and methods for providing priority network access for a multi-link wlan entity
CN116803170A (zh) * 2021-02-01 2023-09-22 佳能株式会社 通信装置、用于通信装置的控制方法、以及程序
CN116980968A (zh) * 2023-09-18 2023-10-31 荣耀终端有限公司 一种多链路的数据传输方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114679795A (zh) * 2020-12-24 2022-06-28 华为技术有限公司 无线局域网中的通信方法、装置及系统
CN116803170A (zh) * 2021-02-01 2023-09-22 佳能株式会社 通信装置、用于通信装置的控制方法、以及程序
US20230262786A1 (en) * 2022-02-15 2023-08-17 Huawei Technologies Co., Ltd. System and methods for providing priority network access for a multi-link wlan entity
CN116980968A (zh) * 2023-09-18 2023-10-31 荣耀终端有限公司 一种多链路的数据传输方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HUAWEI, HISILICON: "Discussion on performance requirements for NR V2X multi-link test", 3GPP DRAFT; R4-2015642, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG4, no. Electronic Meeting; 20201102 - 20201113, 23 October 2020 (2020-10-23), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051944617 *

Also Published As

Publication number Publication date
EP4794444A1 (en) 2026-08-19
CN121284764A (zh) 2026-01-06

Similar Documents

Publication Publication Date Title
US20220418013A1 (en) Communication method and apparatus
US12219381B2 (en) Quality of service information notification method, device, and system
CN111586860B (zh) 一种通信方法及装置
US11792676B2 (en) Charging rule binding method, device, and system
US20220418012A1 (en) Communication Method and Apparatus
CN111432440B (zh) 实现业务连续性的方法、装置及系统
US11277313B2 (en) Data transmission method and corresponding device
EP4124104A1 (en) Communication method and apparatus
US10880369B2 (en) Session persistence method, device, and storage medium
EP4138439A1 (en) Communication method, apparatus, and system
US12363702B2 (en) Communication method, apparatus, and system
US20080083013A1 (en) Methods and apparatus for policy enforcement in a wireless communication system
WO2021254001A1 (zh) 会话建立方法、装置、系统及计算机存储介质
US12568042B2 (en) Application-aware BGP path selection and forwarding
US11212230B2 (en) Quality of service control method, device, and system
WO2020083269A1 (zh) 一种建立多路径连接的子流的方法、装置和系统
WO2023185286A1 (zh) 一种通信方法及装置
CN115174401A (zh) 数据冗余传输方法、装置、电子设备及存储介质
WO2025241654A1 (zh) 一种确定服务质量QoS参数的方法及通信装置
CN114982284B (zh) 通信方法及装置
WO2025152514A1 (zh) 基于远程直接内存访问的通信方法及装置
JP7379476B2 (ja) ワイヤレスメッシュネットワークにおけるマルチバンド通信
CN121284764A (zh) 多链路通信方法、装置、计算机可读介质及电子设备
WO2023098704A1 (zh) 设备到设备通信方法、装置、设备、介质及程序产品
WO2025251985A1 (zh) 辅助计算的方法、通信装置、芯片和计算机可读存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25831967

Country of ref document: EP

Kind code of ref document: A1