Multi-link communication method and apparatus, and computer-readable medium and electronic device

Abstract

Provided in the embodiments of the present application are a multi-link communication method and apparatus, and a computer-readable medium and an electronic device. The multi-link communication method comprises: a medium access control (MAC) layer of a multi-link device generating a first request frame, wherein the first request frame is used for requesting the initiation of multi-link transmission for a data packet of a specified type between the multi-link device and a peer multi-link device; and the MAC layer of the multi-link device sending the first request frame to the peer multi-link device.

Description

Multi-link communication method, device, computer readable medium and electronic device

[0001] The present application claims priority from the Chinese patent application No. 202410895734.4 filed on July 4, 2024, and entitled "Multi-link communication method, device, computer readable medium and electronic device", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the field of computer and communication technology, in particular, to a multi-link communication method, device, computer readable medium and electronic device. BACKGROUND

[0003] The next generation of wireless local area network (WLAN) standards are developing and evolving towards higher throughput, and the WLAN system standards are mainly researched and discussed in the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard group. Based on previous standard protocols such as 802.11a / b / g / n / ac / ax, the next generation standard 802.11be will take extremely high throughput (EHT) as the technical target.

[0004] TECHNICAL CONTENT

[0005] Embodiments of the present application provide a multi-link communication method, device, computer readable medium and electronic device, which can improve the transmission efficiency and reliability of service data packets with higher real-time requirements.

[0006] Other characteristics and advantages of the present application will become apparent from the following detailed description, or will be learned by practice of the present application.

[0007] Embodiments of the present application provide a multi-link communication method, which is executed by a multi-link device, comprising: generating, by a medium access control (MAC) layer of the multi-link device, a first request frame, the first request frame being used to request to open multi-link transmission for a specified type of data packet between the multi-link device and a peer multi-link device; and sending, by the MAC layer of the multi-link device, the first request frame to the peer multi-link device.

[0008] The embodiment of the present application provides a multi-link communication method, which is executed by a multi-link device, and comprises the following steps: a first request frame sent by a peer multi-link device is received by a medium access control (MAC) layer of the multi-link device, wherein the first request frame is used for requesting to start multi-link transmission for a specified type of data packet between the peer multi-link device and the multi-link device; a response frame for the first request frame is generated by the MAC layer of the multi-link device, wherein the response frame is used for indicating whether the multi-link device allows to start the multi-link transmission for the specified type of data packet; and the response frame is sent to the peer multi-link device by the MAC layer of the multi-link device.

[0009] The embodiment of the present application provides a multi-link communication device, comprising: a generating unit configured to generate a first request frame at a medium access control (MAC) layer of the multi-link communication device, wherein the first request frame is used for requesting to start 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 by the MAC layer of the multi-link communication device.

[0010] The embodiment of the present application provides a multi-link communication device, comprising: a receiving unit configured to receive a first request frame sent by a peer multi-link communication device at a medium access control (MAC) layer of the multi-link communication device, wherein the first request frame is used for requesting to start 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, wherein the response frame is used for indicating whether the multi-link communication device allows to start the 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 by the MAC layer of the multi-link communication device.

[0011] The embodiment of the present application provides a computer readable medium, which stores a computer program, and the computer program is executed by a processor to realize the multi-link communication method in the above embodiment.

[0012] The embodiment of the present application provides an electronic device, comprising: one or more processors; and a storage device configured to store one or more computer programs, wherein the one or more computer programs are executed by the one or more processors to enable the electronic device to realize the multi-link communication method in the above embodiment.

[0013] The embodiment of the present application provides a computer program product, which comprises a computer program stored in a computer readable storage medium. A processor of an electronic device reads and executes the computer program from the computer readable storage medium, so that the electronic device executes the multi-link communication method provided in various optional embodiments.

[0014] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application.

[0015] BRIEF DESCRIPTION OF DRAWINGS

[0016] FIG. 1 shows an architecture diagram of a wireless communication system provided by the embodiment of the present application.

[0017] FIG. 2 shows a flowchart of a multi-link communication method according to some embodiments of the present application.

[0018] FIG. 3 shows a flowchart of a multi-link communication method according to some embodiments of the present application.

[0019] FIG. 4 shows a packet header structure diagram of an IP packet according to some embodiments of the present application.

[0020] FIG. 5 shows a field diagram included in MAC Capabilities according to some embodiments of the present application.

[0021] FIG. 6 shows a field diagram included in GDM Access element according to some embodiments of the present application.

[0022] FIG. 7 shows a definition diagram of GDM Access Flag according to some embodiments of the present application.

[0023] FIG. 8 shows a GDM access flow diagram according to some embodiments of the present application.

[0024] FIG. 9 shows a GDM elimination flow diagram according to some embodiments of the present application.

[0025] FIG. 10 shows a flow diagram of establishing multi-link GDM Access Enable by an AP MLD and a Non-AP MLD according to some embodiments of the present application.

[0026] FIG. 11 shows a flow diagram of establishing multi-link GDM Access Teardown by an AP MLD and a Non-AP MLD according to some embodiments of the present application.

[0027] FIG. 12 shows a block diagram of a multi-link communication device according to some embodiments of the present application.

[0028] FIG. 13 shows a block diagram of a multi-link communication device according to some embodiments of the present application.

[0029] FIG. 14 shows a structural schematic diagram of a computer system of an electronic device suitable for implementing embodiments of the present application. DETAILED DESCRIPTION

[0030] Example implementations are now described with reference to the drawings; however, these descriptions are not intended to limit the scope of the application, but are merely intended to provide example examples of implementations. Examples of implementations can be implemented in various forms and should not be construed as limited to the examples set forth herein; rather, these examples are provided as a full and enabling disclosure of the examples of implementations, and to fully convey their scope to those skilled in the art.

[0031] Furthermore, the features, structures or characteristics of the application described can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are recited in order to provide a thorough understanding of the embodiments of the application. However, one skilled in the art will recognize that the embodiments of the application can be practiced without the specific details given herein, can be practiced with some other elements, components, arrangements and steps, or using other methods, materials and devices.

[0032] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined target, and can be implemented entirely or partially by using software, hardware (such as a processing circuit or a memory) or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an overall module or unit that includes the functions of the module or unit.

[0033] The block diagrams shown in the drawings are merely functional entities, and do not necessarily have to correspond to physically independent entities. That is, these functional entities can be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0034] The flowcharts shown in the drawings are merely exemplary illustrations, and do not necessarily include all contents and operations / steps, nor do they have to be executed in the order described. For example, some operations / steps can be further divided, and some operations / steps can be combined or partially combined, so the actual execution order can be changed according to the actual situation.

[0035] It should be noted that "multiple" referred to in the present document refers to two or more than two. The association relationship of "and / or" describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can represent the following three cases: A exists alone, A and B exist together, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects before and after it.

[0036] The technical solutions provided by the embodiments of the present application can be applied to a WLAN system, and can be applicable to IEEE 802.11 series protocols, such as 802.11a / b / g protocols, 802.11n protocols, 802.11ac protocols, 802.11ax protocols, 802.11be protocols, or next-generation protocols, and the like, which will not be listed one by one here. The technical solutions provided by the embodiments of the present application can also be applied to other types of communication systems, such as Internet of Things (IoT) systems, Vehicle to X (V2X) systems, and the like.

[0037] In the related art, for some services with higher real-time requirements (such as game services), in order to guarantee the transmission efficiency and reliability of game data, the game data is usually mapped to a high priority level, and if multiple games are online at the same time, data transmission congestion and unreliability will inevitably occur. Therefore, how to guarantee the transmission reliability of service data packets with higher real-time requirements is a technical problem to be solved.

[0038] The technical solutions provided by the embodiments of the present application can be implemented by a communication device in a communication system or a chip or processor in a communication device. The communication device can be a wireless communication device supporting parallel transmission of multiple links (i.e., a wireless communication device supporting multi-link operation (MLO)), which can be referred to as a multi-link device (MLD) or a multi-band device. Compared with a communication device supporting only single-link transmission, a multi-link device has higher transmission efficiency and larger throughput.

[0039] In the technical solutions provided by some embodiments of the present application, a first request frame is generated to request that the specified type of data packet is transmitted by multiple links, so that for services with higher real-time requirements, the reliability of data transmission can be guaranteed by transmitting through multiple links, thereby improving the efficiency and reliability of service data packet transmission in the case of poor network environment or transmission link congestion.

[0040] The next-generation 802.11 standard station device that supports multiple links in the embodiments of the present application is referred to as a multi-link device (MLD), which can be an access point multi-link device (AP MLD) or a non-access point multi-link device (non-AP MLD). An internal entity responsible for any one link is referred to as a station (STA). If all STAs inside an MLD are access points (APs), the MLD can be further referred to as an AP MLD; if all STAs inside an MLD are non-access point stations (non-AP STAs), the MLD can be further referred to as a non-AP MLD. In other words, a multi-link device includes one or more affiliated STAs, which is a logical station and can work on one link or one frequency band or one channel. The affiliated STAs can be APs or non-AP STAs. The 802.11be refers to the multi-link device with affiliated APs as an AP multi-link device (AP MLD), and the multi-link device with affiliated non-AP STAs as a non-AP multi-link device (non-AP MLD).

[0041] Referring to FIG. 1, in an exemplary wireless communication system, at least one AP MLD (such as the AP MLD 101 in FIG. 1) and at least one non-AP MLD (such as the non-AP MLD 102 and the non-AP MLD 103 in FIG. 1) are included. The non-AP MLD can communicate with the AP MLD using multiple links, thereby achieving the effect of improving the throughput. A STA in the non-AP MLD can also communicate with an AP in the AP MLD through a link. It can be understood that the number of AP MLDs and non-AP MLDs in FIG. 1 is only exemplary, and any number of AP MLDs and non-AP MLDs can be provided according to the implementation needs.

[0042] For example, the multi-link device is a device with wireless communication function, which can be a whole device, or a chip or processing system installed in a whole device, and the device installed with the chip or processing system can realize the method and function of the embodiments of the present application under the control of the chip or processing system. For example, the non-AP MLD in the embodiments of the present application has wireless transceiving function and can support 802.11 series protocol and can communicate with single-link AP, AP MLD or other non-AP MLD. For example, the non-AP MLD is any user communication device that allows users to communicate with AP and then communicate with WLAN. For example, the non-AP MLD can be a user device that can be connected to the network, such as a smartphone, a tablet computer, a notebook computer, a desktop computer, a smart television, a smart home, a vehicle terminal, an aircraft, etc., or an Internet of Things node in the Internet of Things, or a vehicle communication device in the Internet of Vehicles, etc.; the non-AP MLD can also be a chip and a processing system in the above terminals. The AP MLD in the embodiments of the present application can provide services for the non-AP MLD and can support 802.11 series protocol. For example, the AP MLD can be a communication server, a router, a switch, a bridge, etc., or the AP can include various forms of macro base stations, micro base stations, relay stations, etc., and of course the AP can also be a chip and a processing system in the above various forms of devices, so as to realize the method and function of the embodiments of the present application.

[0043] It can be understood that the multi-link device can support high-rate low-latency transmission, and as the application scenarios of wireless local area networks continue to evolve, the multi-link device can also be applied to more scenarios, such as sensor nodes in smart cities (such as smart water meters, smart electricity meters, and smart air detection nodes); smart devices in smart homes (such as smart cameras, projectors, display screens, televisions, sound systems, refrigerators, washing machines, etc.); smart devices in smart offices (such as printers, projectors, etc.); some infrastructure in daily life (such as vending machines, self-service navigation stations in supermarkets, self-service checkout devices, self-service ordering machines, etc.). The specific forms of the non-AP MLD and the AP in the embodiments of the present application are not limited, and are only exemplarily described herein. The 802.11 protocol can be a protocol supporting 802.11be or compatible with 802.11be.

[0044] Although the embodiments of the present application mainly take WLAN as an example, especially the network applying to IEEE 802.11 series standards. Those skilled in the art can easily understand that the various aspects involved in the embodiments of the present application can be extended to other networks adopting various standards or protocols.

[0045] The implementation details of the technical solutions of the embodiments of the present application are described in detail as follows:

[0046] FIG. 2 shows a flow chart of a multi-link communication method according to some embodiments of the present application, which can be performed by a wireless communication enabled device, which can be an AP MLD or a non-AP MLD shown in FIG. 1. Referring to FIG. 2, the multi-link communication method includes at least S210-S220, which are described in detail as follows:

[0047] In S210, a first request frame is generated by a Medium Access Control (MAC) layer of the multi-link device, which is used to request to open a multi-link transmission for a specified type of data packet between the multi-link device and a peer multi-link device.

[0048] In some embodiments, the specified type of data packet can be a low-latency data packet, such as a multimedia service data packet, e.g., a game service data packet, a Virtual Reality (VR) service data packet, an Augmented Reality (AR) service data packet, a Mixed Reality (MR) service data packet, an Extended Reality (XR) service data packet, an XR and Media Services (XRM) service data packet, a Cinematic Reality (CR) service data packet, etc.

[0049] In some embodiments, upon receiving a current service data packet, the wireless communication enabled device can determine whether the current service data packet is a specified type of data packet according to a value of a specified flag bit contained in a packet header of the current service data packet. In some embodiments, the specified flag bit can be a flag bit in a Type of Service (TOS) field in the packet header. In some embodiments, the wireless communication enabled device can be a multi-link device (MLD).

[0050] In some embodiments, the wireless communication enabled device 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 for multi-link transmission for the specified type of data packet sent by the SME of the MLD, and then generate the first request frame based on the enable request.

[0051] In some embodiments, if the multi-link device initiating the enable request is an access point device (i.e., AP MLD), the enable request contains at least one of the following information: the MAC address of the opposite multi-link device (i.e., a non-AP MLD station device associated with an access point device (i.e., AP MLD)), a dialog token for multi-link transmission of a specified type of data packet, and parameters for multi-link transmission of the specified type of data packet.

[0052] In some embodiments, if the multi-link device initiating the enable request is a non-AP MLD station device, the enable request contains at least one of the following information: the MAC address of the opposite multi-link device (i.e., an access point device (i.e., AP MLD) associated with the station device), a dialog token for multi-link transmission of a specified type of data packet.

[0053] In some embodiments, the first request frame can contain at least one of the following field information: a category field for indicating the type of the first request frame, a protected EHT action field for indicating that the first request frame adopts a protected EHT operation, a dialog token field, and a field for indicating whether to enable multi-link transmission of a specified type of data packet.

[0054] In some embodiments, when generating the first request frame, the device with wireless communication function can obtain a service access right of a subscription service provider network (SSPN) for a specified type of data packet, and if it is determined according to the service access right that the SSPP allows multi-link transmission for the specified type of data packet, the first request frame is generated.

[0055] Continuing to refer to FIG. 2, in S220, the first request frame is sent by the medium access control (MAC) layer of the multi-link device to the opposite multi-link device.

[0056] In some embodiments, if the first request frame is generated by an access point device (i.e., AP MLD), the access point device can send the first request frame to a non-AP MLD station device; if the first request frame is generated by a non-AP MLD station device, the station device can send the first request frame to an access point device (i.e., AP MLD) or to other station devices.

[0057] In some embodiments, after sending the first request frame, the device with wireless communication function can receive, by the MAC layer of the multi-link device, a response frame sent by the peer multi-link device for the first request frame, the response frame being used to indicate whether the peer multi-link device allows to start the multi-link transmission for the specified type of data packet.

[0058] In some embodiments, at least one of the following field information can be contained in the response frame: a field (Category) used to indicate the response frame type, a field (Protected EHT Action) used to indicate that the response frame adopts protected EHT operation, a field used to indicate the conversation token, a field used to indicate whether to start the multi-link transmission for the specified type of data packet, and a status code field (Status Code Field) used to indicate the response result.

[0059] In some embodiments, the status code field can be used to indicate that the multi-link transmission for the specified type of data packet is allowed to be started; or the status code field can be used to indicate that the multi-link transmission for the specified type of data packet is refused to be started; or the status code field can be used to indicate the reason why the multi-link transmission for the specified type of data packet is refused to be started; or the status code field can be used to indicate that the multi-link transmission for the specified type of data packet is refused to be started and the reason why the multi-link transmission for the specified type of data packet is refused to be started.

[0060] In some embodiments, after receiving the response frame for the first request frame, the MLD MAC layer can send an enable confirmation for the multi-link transmission for the specified type of data packet to the SME. In some embodiments, the enable confirmation can contain a status code field used to indicate the response result; wherein the status code field can be used to indicate that the multi-link transmission for the specified type of data packet is allowed to be started; or the status code field can be used to indicate that the multi-link transmission for the specified type of data packet is refused to be started; or the status code field can be used to indicate the reason why the multi-link transmission for the specified type of data packet is refused to be started; or the status code field can be used to indicate that the multi-link transmission for the specified type of data packet is refused to be started and the reason why the multi-link transmission for the specified type of data packet is refused to be started.

[0061] In some embodiments, after the multi-link transmission for the specified type (e.g., low latency) of data packet is established, when the multi-link device receives a service data packet, the MAC layer of the multi-link device determines whether the service data packet is the specified type of data packet according to the value of the specified flag bit contained in the packet header of the service data packet.

[0062] The service data packet is subjected to multi-link transmission based on the determination of the specified type of data packet at the time of the service data packet; wherein the specified flag comprises a flag in a type of service (TOS) field in the packet header.

[0063] In the method provided by the embodiments of the present application, by identifying the flag in the packet header (such as the TOS field), the MAC layer can quickly distinguish low-latency class data packets and automatically trigger multi-link parallel transmission, reducing queuing and link switching delay. Moreover, only the specified type (such as high priority) data packet enables multi-link transmission, avoiding ordinary data packets occupying additional link resources, improving overall bandwidth utilization. In addition, the classification decision is implemented at the MAC layer, without repeated intervention of the upper layer protocol, reducing processing overhead. The mechanism realizes low-latency and high-reliability transmission of key service data, while maintaining reasonable allocation of network resources.

[0064] In some embodiments, after the multi-link transmission is established for the specified type of data packet, if it is necessary to stop the multi-link transmission, the wireless communication enabled device can generate a second request frame for requesting to release the multi-link transmission for the specified type of data packet that has been established between the multi-link device and the opposite multi-link device, and then can send the second request frame.

[0065] In the embodiments of the present application, the multi-link transmission of the specified service is actively terminated by the second request frame, avoiding continuous occupation of redundant links and releasing bandwidth resources for use by other services. Moreover, only the specific service type (such as the end of a low-latency session) triggers the release process, maintaining the multi-link connection of other services, and realizing fine-grained resource management. In addition, the MAC layer generates a standardized control frame (second request frame), ensuring that the opposite device synchronously releases the multi-link binding, preventing data packet out-of-order or packet loss. The scheme of the embodiments of the present application improves the dynamic adaptability and overall resource utilization of the multi-link system while ensuring the transmission of key services.

[0066] In some embodiments, if the second request frame is generated by an access point device (i.e., AP MLD), the access point device can send the second request frame to a non-access point station device (i.e., non-AP MLD); if the second request frame is generated by a non-access point station device (i.e., non-AP MLD), the station device can send the second request frame to an access point device (i.e., AP MLD) or to other station devices.

[0067] In some embodiments, when the second request frame is generated, a stop request (tear down request) for the multi-link transmission of the specified type of data packet sent by the SME of the multi-link device can be received; and then the second request frame is generated based on the stop request.

[0068] In some embodiments, if the multi-link device sending the second request frame is an access point device (i.e., AP MLD), the stop request contains the MAC address of a non-access point station device (i.e., non-AP MLD).

[0069] In some embodiments, if the multi-link device sending the second request frame is a non-access point station device (i.e., non-AP MLD), the stop request contains the MAC address of the access point device (i.e., AP MLD) to which the station device is associated. In some embodiments, in some scenarios, such as when a session identifier has been established, the MAC address of the access point device (i.e., AP MLD) to which the station device is associated can not be included in the stop request when it is necessary to send the stop request to the associated access point device, thereby reducing signaling load and reducing frame overhead.

[0070] FIG. 3 shows a flowchart of a multi-link communication method according to some embodiments of the present application, which can be performed by a device with wireless communication function, which can be an AP MLD or a non-AP MLD shown in FIG. 1. Referring to FIG. 3, the multi-link communication method includes at least S310 to S330, which are described in detail as follows:

[0071] In S310, a first request frame is received by the MAC layer of a multi-link device, the first request frame being used to request to open multi-link transmission for a specified type of data packet between a peer multi-link device and the multi-link device.

[0072] In some embodiments, the first request frame can contain at least one of the following field information: a field (Category) indicating the type of the first request frame, a field (Protected EHT Action) indicating that the first request frame adopts protected extremely high throughput operation, a field indicating a session token, and a field indicating whether to open multi-link transmission for the specified type of data packet.

[0073] In S320, a response frame for the first request frame is generated by the MAC layer of the multi-link device, the response frame being used to indicate whether the multi-link device allows to open multi-link transmission for the specified type of data packet.

[0074] In some embodiments, at least one of the following field information can be contained in the response frame: a field (Category) for indicating the type of the response frame, a field (Protected EHT Action) for indicating that the response frame adopts protected EHT operation, a field for indicating the conversation token, a field for indicating whether to start the multi-link transmission of the data packets of the specified type, and a status code field (Status Code Field) for indicating the response result.

[0075] In some embodiments, the status code field can be used to indicate that the multi-link transmission of the data packets of the specified type is allowed to be started; or the status code field can be used to indicate that the multi-link transmission of the data packets of the specified type is refused to be started; or the status code field can be used to indicate the reason why the multi-link transmission of the data packets of the specified type is refused to be started; or the status code field can be used to indicate that the multi-link transmission of the data packets of the specified type is refused to be started and the reason why the multi-link transmission of the data packets of the specified type is refused to be started.

[0076] In some embodiments, after receiving the first request frame, the MLD MAC layer of the device with wireless communication function can send an enable indication of the multi-link transmission of the data packets of the specified type to the SME. If an enable response of the multi-link transmission of the data packets of the specified type sent by the SME is received, a response frame for the first request frame is generated.

[0077] In S330, a response frame is sent by the MAC layer of the multi-link device to the opposite multi-link device.

[0078] In some embodiments, if the response frame is generated by an access point device (i.e., an AP MLD), the access point device can send the response frame to a non-access point station device (i.e., a non-AP MLD) that sends the first request frame; if the response frame is generated by a non-access point station device (i.e., a non-AP MLD), the station device can send the response frame to an access point device (i.e., an AP MLD) that sends the first request frame, or also to other station devices that send the first request frame.

[0079] In some embodiments, after the multi-link transmission for the data packets of the specified type is established, if a second request frame for indicating that the multi-link transmission for the data packets of the specified type is stopped is received, the MLD MAC layer can send a tear down indication of the multi-link transmission for the data packets of the specified type to the SME.

[0080] It should be noted that in the above embodiments, the first request frame and the second request frame can be management frames, or can also be other types of frames.

[0081] The technical solutions of the embodiments of the present application are described in detail below taking a game data packet of a specified type as an example, which is a low-latency game data packet:

[0082] Since games have very high real-time requirements, for example, in games, the player is most concerned about the shooting results and the survival of the character, and various messages are updated in real time, which puts higher requirements on the transmission efficiency and reliability of underlying game data, and it is particularly important to ensure the transmission efficiency and reliability of game data. The processing method in the related art is to map game data to a high priority level, that is, all game operators map their own game data to a high priority level based on a traffic identifier (Traffic Identifier, TID). If multiple game operators have games online at the same time, data transmission congestion and unreliability will inevitably occur.

[0083] Based on the above problems existing in the related art, the technical solutions of the embodiments of the present application propose that after establishing a data 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 the data packet of a low-latency service (such as a game service) according to the wireless environment or service bearing condition in which it is located. That is, the technical solutions of the embodiments of the present application can realize more fine-grained multi-link transmission at the data packet level, and the technical solutions of the embodiments of the present application can be applied in the 802.11be and subsequent standards.

[0084] As shown in FIG. 4, the IP packet header of the game service IP data packet includes the following fields:

[0085] Version: 4 bits. Used to indicate the version of the IP protocol, which is fixed to 4 if it is IPv4.

[0086] Header length: 4 bits. Used to indicate the length of the IP header, in units of words (i.e., 4 bytes). Since the maximum value is 15, the maximum length of the IP header is 60 bytes (15x4).

[0087] Service type (TOS): 8 bits. Used to define different service types, which can provide different services for IP data packets.

[0088] Total length: 16 bits. Used to indicate the length of the entire IP data packet, including data and the IP header, so the maximum length of the IP data packet is 65535 bytes.

[0089] 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.

[0090] Flags: 3 bits. The first bit of this field is not used, the second bit is the DF (Don't Fragment) bit, which is set to 1 to indicate that the router cannot fragment the packet. The third bit is the MF (More Fragments) bit, which indicates 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.

[0091] Fragment Offset: 13 bits. Used to indicate the position of the current fragment in the IP packet fragment group, which is used by the receiving end to assemble and restore the IP packet.

[0092] Time To Live (TTL): 8 bits. When the IP packet is sent, it is first assigned a certain value. When the IP packet passes through each router along the way, each router along the way will reduce the TTL value of the IP packet by 1. If the TTL is reduced to 0, the IP packet will be discarded. This field can prevent IP packets from being continuously forwarded in the network due to routing loops.

[0093] Upper Layer Protocol: 8 bits. Identifies the protocol used by the upper layer, such as the commonly used Transmission Control Protocol (TCP), User Datagram Protocol (UDP), etc.

[0094] Checksum: 16 bits. Used to detect the correctness of the IP header, but does not include the data part, because each router changes the value of TTL, so the router will recalculate this value for each passing IP packet.

[0095] Source IP Address and Destination IP Address: Both fields occupy 32 bits. Identify the source IP address and destination IP address of the IP packet.

[0096] IP Options: variable length, up to 40 bytes.

[0097] In the IEEE protocol, the mapping of the Differentiated Services Code Point (DSCP) and the TID only occupies the high 6 bits of the Type of Service (TOS) in the IP header, and the remaining low 2 bits are reserved and not used for other purposes, so the first bit can be used as a flag to identify low-latency data packets. Then the AP MLD and the Non-AP MLD establish a low-latency data packet level multi-link transmission through a signaling message. 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 on the business data packet.

[0098] In some embodiments, establishing AP MLD and Non-AP MLD data packet level multi-link requires adding three messages of 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), and adding 3 values in the Protected Action field, as shown in Table 1 below:

[0099] Table 1

[0100] In some embodiments, the definition of the Game Data Multi-Link Access Enable Request frame can be as shown in Table 2 below:

[0101] Table 2

[0102] The Category field in Table 2 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, and the embodiments of the present application add three values of 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 the GDM Enable Access Request / Response frame. The Game Data Multi-Link Access element is used to indicate whether to enable game data multi-link transmission.

[0103] In some embodiments, if the Game Data Multi-Link Access element exists in the Game Data Multi-Link Access Enable Request frame, it can be indicated that the game data multi-link transmission is enabled; if the Game Data Multi-Link Access element does not exist in the Game Data Multi-Link Access Enable Request frame, it can be indicated that the game data multi-link transmission is not enabled. Alternatively, different values can be set to indicate whether to enable game data multi-link transmission.

[0104] In some embodiments, the definition of the Game Data Multi-Link Access Enable Response frame can be as shown in Table 3:

[0105] Table 3

[0106] 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, and the embodiments of the present application add three values of GDM Access Enable Request, GDM Access Enable Response, and GDM Access Teardown. As a response corresponding to the GDM Access Enable Request frame, the Dialog Token field is set to the value in the Game Data Multi-Link Access Enable Request frame. When the GDM Access Enable Response frame is sent in the unsolicited mode, the Dialog Token field can be set to 0. The status code (Status Code) is defined in the Status Code field section of the standard protocol, and can be set to 0 when the GDM response frame is sent in the unsolicited mode.

[0107] The Game Data Multi-Link Access element is used to indicate whether to enable game data multi-link transmission. In some embodiments, if the Game Data Multi-Link Access element exists in the Game Data Multi-Link Access Enable Request frame, it can be indicated that the game data multi-link transmission is enabled; if the Game Data Multi-Link Access element does not exist in the Game Data Multi-Link Access Enable Request frame, it can be indicated that the game data multi-link transmission is not enabled. Alternatively, whether to enable the game data multi-link transmission can also be indicated by setting different values.

[0108] In some embodiments, the definition of the Game Data Multi-Link Access Teardown frame can be as shown in Table 4:

[0109] Table 4

[0110] Among them, the Category field in Table 4 is defined in the “Action field” chapter in the standard protocol. The Protected EHT Action field is defined in the “Protected EHC Action field” chapter in the standard protocol, and three values of GDM Access Enable Request, GDM Access Enable Response and GDM Access Teardown are newly added in the embodiments of the present application.

[0111] In some embodiments, three Status Code values are newly added in the embodiments of the present application for the Status Code to support the GDM Access, as shown in the following Table 5:

[0112] Table 5

[0113] It should be noted that more Status Code values can also be newly added in other embodiments of the present application to support the GDM Access.

[0114] In some embodiments, a new field can be added in the MAC Capabilities to indicate the support of GDM Access by the AP MLD or Non-AP MLD. Specifically, the fields contained in the MAC Capabilities are shown in FIG. 5. Specifically, they include: Emergency Preparedness Communications Service (EPCS) priority Access Support, EHT Operation Mode Control Support, Triggered TXOP Sharing Mode 1 Support, Triggered TXOP Sharing Mode 2 Support, Restricted Target Wake Time Support, Sub-Carrier Space Traffic Description 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. Wherein, BQR refers to Bandwidth Query Report; TXOP refers to Transmission Opportunity; MPDU refers to MAC Protocol Data Unit; and A-MPDU refers to Aggregation MAC Protocol Data Unit.

[0115] In the fields shown in FIG. 5, GDM Access Support is a newly added field in the embodiments of the present application. That is, in the embodiments of the present application, support for GDM Access can be added in B14. After adding GDM Access Support in B14, the remaining B15 is a reserved bit.

[0116] In some embodiments, an element ID for supporting GDM Access can be added, as shown in Table 6 below:

[0117] Table 6

[0118] In some embodiments, the definition of the GDM Access element is shown in FIG. 6, including: Element ID, Length, Element ID Extension, and GDM Access Flags.

[0119] In some embodiments, whether the GDM Access Flag supports multi-link transmission is defined as shown in FIG. 7, which can be indicated by a flag bit. For example, if the value of the flag bit is 1, it means that multi-link transmission is supported; if the value of the flag bit is 0, it means that multi-link transmission is not supported.

[0120] In some embodiments, the type of support for GDM Access can be added in the Multi-Link field in the Multi-Link element, as shown in Table 7 below:

[0121] Table 7

[0122] Based on the information added in the above embodiments, the GDM Access element can be carried in the Multi-Link element.

[0123] In some embodiments, 6 primitives can be added in this application 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 Confirm primitive (MLME-GDMACCESSENABLE.confirm), GDM Access Tear Down Request primitive (MLME-GDMACCESSTEARDOWN.request), GDM Access Tear Down Indication primitive (MLME-GDMACCESSTEARDOWN.indication). Wherein, MLME refers to MAC layer management entity (MAC Layer Management Entity), the following describes each primitive.

[0124] In some embodiments, the MLME-GDMACCESSENABLE.request primitive is used to initiate a request to the peer MAC entity to enable GDM Access.

[0125] Primitive parameters are as follows:

[0126] Wherein, the related explanations of PeerSTAAddress, Dialog Token and GDMAccessMultiLink refer to the following table 8:

[0127] Table 8

[0128] The MLME-GDMACCESSENABLE.request primitive is generated by the SME, and is used to send a request to the peer MAC entity to enable GDM Access.

[0129] In some embodiments, the MLME-GDMACCESSENABLE.confirm primitive is used to report the response of the GDM Access request of the peer MAC entity.

[0130] Primitive parameters are as follows:

[0131] Wherein, the related explanations of PeerSTAAddress, Dialog Token, Status Code and GDMAccessMultiLink refer to the following table 9:

[0132] Table 9

[0133] The MLME-GDM ACCESS ENABLE.confirm primitive is generated by the MLME in response to the GDM Access Enable from the peer MAC entity after it is received.

[0134] In some embodiments, the MLME-GDM ACCESS ENABLE.indication primitive indicates that a request for GDM Access Enable Request has been received from the peer MAC entity.

[0135] The primitive parameters are as follows:

[0136] Wherein, the related explanations of PeerSTAAddress, Dialog Token and GDMAccessMultiLink refer to the following Table 10:

[0137] Table 10

[0138] The MLME-GDM ACCESS ENABLE.indication primitive is generated by the MLME after receiving the GDM Access Enable Request frame from the peer MAC entity.

[0139] In some embodiments, the MLME-GDM ACCESS ENABLE.response primitive is generated by the MLME to send a response to the peer MAC entity to enable GDM Access.

[0140] The primitive parameters are as follows:

[0141] Wherein, the related explanations of PeerSTAAddress, Dialog Token, Status Code and GDMAccessMultiLink refer to the following Table 11:

[0142] Table 11

[0143] The MLME-GDM ACCESS ENABLE.response primitive is generated by the SME as a response to the MLME-GDM ACCESS ENABLE.indication primitive.

[0144] In some embodiments, the MLME-GDMACCESSTEARDOWN.request primitive is used to indicate to the peer MAC entity torn down GDM Access.

[0145] The primitive parameters are as follows:

[0146] MLME-GDMACCESSTEARDOWN.request (

[0147] PeerSTAAddress (peer STA address),

[0148] )

[0149] Wherein, the related description of PeerSTAAddress refers to the following table 12:

[0150] Table 12

[0151] The MLME-GDMACCESSENABLE.response primitive is generated by the SME when the STA wants to torn down GDM Access.

[0152] In some embodiments, the MLME-GDMACCESSTEARDOWN.indication primitive is used to indicate to the peer MAC entity torn down GDM Access.

[0153] The primitive parameters are as follows:

[0154] MLME-GDMACCESSTEARDOWN.indication (

[0155] PeerSTAAddress (peer STA address),

[0156] )

[0157] Wherein, the related description of PeerSTAAddress refers to the following table 13:

[0158] Table 13

[0159] The MLME-GDMACCESSTEARDOWN.indication primitive is generated by the MLME after receiving the GDM Access Enable Teardown frame from the peer MAC entity.

[0160] In some embodiments, in order to support GDM Access, an Abstract Syntax Notation One (ASN.1) message can be added in the embodiments of the present application. Specifically, the ASN.1 message dot11EHTGDMAccessActivated (i.e., EHT GDM Access Activated) can be added in Dot11EHTStationConfigEntry (i.e., EHT Station Configuration Entry) and can be set as an object type. In some embodiments, dot11EHTGDMAccessActivated can be a control variable, which is written by an external management entity or an SME. In the actual process, 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 the attribute is false, the MLD does not support GDM Access capability.

[0161] At the same time, the ASN.1 message dot11GDMAccessAuthorized (i.e., GDM Access Authorized) can also be added in Dot11InterworkingEntry (i.e., Interworking Entry) and can be set as an object type. In some embodiments, dot11GDMAccessAuthorized can be a control variable, which is written by the SME after the AP receives permission from the SSPN interface for the non-AP STA to use GDM Access. When the attribute value is true, it indicates that the non-AP STA is allowed to invoke and use GDM Access capability; if the attribute value is false, the non-AP STA is not allowed to invoke and use GDM Access capability.

[0162] In some embodiments, GDM Access is initiated by the SME to establish 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. In some embodiments, both the AP MLD and the None-AP MLD can set dot11EHTGDMAccessActivated to true.

[0163] The STA affiliated to the GDM MLD sets the subfield GDM Access Support in the MAC Capabilities Information field sent by it to 1, indicating that GDM access can be supported, otherwise 0. In the (re) association process, the AP MLD obtains the information required to verify the use of GDM access by the Non-AP MLD. And can set dot11SSPNInterfaceActivated to true to support retrieving the GDM service access provider corresponding to the None-AP MLD through the SSPN interface during the association of the None-AP MLD.

[0164] The AP MLD that successfully obtains the permission of the Non-AP MLD to use GDM access should update the value of dot11InterworkingEntry about Non-AP MLD dot11GDMAccessAuthorized. If the robust security network association (RSNA) with management frame protection is not successfully negotiated and GDM access is allowed, neither the AP MLD nor the Non-AP MLD can send the GDM Access Enable Request frame to the other party to initiate GDM access.

[0165] Based on the description in the above embodiments, in some embodiments of the present application, the GDM access process is as shown in FIG. 8: When the initiating party (such as the AP MLD or the Non-AP MLD) detects the game data packet (Game Data) and determines to allow multi-link access, the MLD SME of the initiating party sends MLME-GDMACCESSENABLE.request to the MLD MAC of the initiating party. After receiving the primitive, the MLD MAC of the initiating party sends the GDM Access Enable Request frame to the MLD MAC of the responding party (such as the AP MLD or the 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.

[0166] The responder's MLD SME sends MLME-GDMACCESSENABLE.response to the responder's MLD MAC after receiving the MLME-GDMACCESSENABLE.indication. The responder's MLD MAC can send a GDM Access Enable Response frame to the initiator's MLD MAC after receiving the MLME-GDMACCESSENABLE.response, and then the initiator's MLD MAC sends MLME-GDMACCESSENABLE.confirm to the initiator's MLD SME. In this case, if the response frame fed back by the responder is that the GDM access is agreed, then the GDM access procedure between the initiator and the responder is completed, and the game service data packets can be transmitted through the multi-link.

[0167] In some embodiments of the present application, the GDM Teardown procedure is shown in FIG. 9, which is specifically: the MLD SME of the initiator (such as an AP MLD or a Non-AP MLD) sends MLME-GDMACCESSTEARDOWN.request to the MLD MAC of the initiator when it is necessary to Teardown the GDM access. The MLD MAC sends a GDM Access Enable Teardown frame to the MLD MAC of the responder (such as an AP MLD or a Non-AP MLD) after receiving the primitive, and then the MLD MAC of the responder can send MLME-GDMACCESSTEARDOWN.indication to the MLD SME of the responder to Teardown the GDM access.

[0168] In some embodiments of the present application, the GDM access state can be torn down when the MLD high layer issues an indication. Both the initiator and the responder set the GDM access state to the torn down state and apply it to all enabled links between the MLDs.

[0169] In some embodiments of the present application, the AP MLD and the Non-AP MLD establish a multi-link GDM Access Enable procedure as shown in FIG. 10: the initiator (such as the AP MLD or the Non-AP MLD) sends a GDM Access Enable Response frame to the responder (such as the AP MLD or the Non-AP MLD) when detecting game data packets (Game Data) and determining that multi-link access is allowed. In this case, if the response of the responder is agreed to GDM access in the Response frame, the GDM access process between the initiator and the responder is completed, and the game service data packets can be transmitted through multi-link.

[0170] In some embodiments of the present application, the AP MLD and the Non-AP MLD establish a multi-link GDM Access Teardown procedure as shown in FIG. 11: the initiator (such as the AP MLD or the Non-AP MLD) sends a GDM Access Enable Teardown frame to the responder (such as the AP MLD or the Non-AP MLD) when needing to Teardown GDM access.

[0171] In summary, the technical scheme of the embodiment of the present application is mainly in the field of wireless communication technology, especially relates to the scenario of service congestion or weak communication link coverage when multiple wireless terminals perform low-latency service in a Wi-Fi wireless network. The STA and the AP establish multi-link transmission based on data packet level through management messages, so that the low-latency service can select better links or copies for transmission on multiple links, thereby improving the transmission reliability and efficiency of the service. Specifically, in the embodiment of the present application, three management messages are newly created to establish multi-link transmission links based on data packet level between the STA and the AP, and six new primitives are added to support the creation of the three management messages. In the embodiment of the present application, a configuration field dot11EHTGDMAccessActivated is newly added to indicate that the STA and the AP both have the capability of supporting multi-link transmission based on data packet level, and GDM Access support is added to MAC capabilities and set to true. In the embodiment of the present application, the STA or the AP sends a GDM Access Enable Request frame to the other party. After receiving the frame, the other party sends a GDM Access Enable Response frame to the sender to tell the other party whether to accept the mapping of the latency service to two or more links for data transmission. Thus, in the case of weak network coverage or network congestion, the low-latency service can be transmitted on two or more links or better links according to the STA or the AP's expectation.

[0172] Through the optimization of the embodiment of the present application, especially in the low-latency service transmission process, the service data packet can be adaptively optimized for transmission on two or more links according to the network coverage and service congestion, instead of all data packets being transmitted on multiple links. Especially in the scenario of weak wireless network coverage or congestion of the ongoing service, the reliability of low-latency data service packet transmission can be improved, and the user experience can be improved.

[0173] It should be noted that the technical scheme of the embodiment of the present application can be applied not only to game services but also to other multimedia services such as VR services, AR services, MR services, XR services, XRM services, and CR services.

[0174] The device embodiment of the present application is introduced below and can be used to perform the multi-link communication method in the above-mentioned embodiments of the present application. For details not disclosed in the device embodiment of the present application, refer to the above-mentioned embodiments of the multi-link communication method.

[0175] FIG. 12 shows a block diagram of a multi-link communication device according to some embodiments of the present application, which can be arranged in a device with wireless communication function, which can be an AP MLD or a non-AP MLD shown in FIG. 1.

[0176] Referring to FIG. 12, a multi-link communication device 1200 according to some embodiments of the present application includes a generating unit 1202 and a sending unit 1204.

[0177] The generating unit 1202 is configured to generate, at a MAC layer of the multi-link communication device, a first request frame for requesting to start multi-link transmission for a specified type of data packet between the multi-link communication device and a peer multi-link communication device; and the sending unit 1204 is configured to send, by the MAC layer of the multi-link communication device, the first request frame to the peer multi-link communication device.

[0178] FIG. 13 shows a block diagram of a multi-link communication device according to some embodiments of the present application, which can be arranged in a device with wireless communication function, which can be an AP MLD or a non-AP MLD shown in FIG. 1.

[0179] Referring to FIG. 13, a multi-link communication device 1300 according to some embodiments of the present application includes a receiving unit 1302, a generating unit 1304 and a sending unit 1306.

[0180] The receiving unit 1302 is configured to receive, at a MAC layer of the multi-link communication device, a first request frame sent by a peer multi-link communication device, the first request frame being used for requesting to start multi-link transmission for a specified type of data packet between the peer multi-link communication device and the multi-link communication device; the generating unit 1304 is configured to generate, at the MAC layer of the multi-link communication device, a response frame for the first request frame, the response frame being used for indicating whether the multi-link communication device allows to start multi-link transmission for the specified type of data packet; and the sending unit 1306 is configured to send, by the MAC layer of the multi-link communication device, the response frame to the peer multi-link communication device.

[0181] The specific function implementation of each functional unit of the multi-link communication device 1200 and 1300 provided by the above embodiments of the present application can refer to the foregoing various embodiments, which will not be described here again. FIG. 14 shows a structural schematic diagram of a computer system of an electronic device suitable for implementing the embodiments of the present application, which can be the device with wireless communication function in the foregoing embodiments.

[0182] It should be noted that the computer system 1400 of the electronic device shown in FIG. 14 is merely one example. It should not be understood to limit the scope of the application embodiments in any way.

[0183] As shown in FIG. 14, the computer system 1400 can include a central processing unit (CPU) 1401 which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 1402 or loaded into a random access memory (RAM) 1403 from a storage section 1408, such as performing the methods described in the above embodiments. Various programs and data required for the operation of the system are also stored in the RAM 1403. The CPU 1401, the ROM 1402, and the RAM 1403 are connected to each other through a bus 1404. An input / output (I / O) interface 1405 is also connected to the bus 1404.

[0184] The following components can be connected to the I / O interface 1405: an input section 1406 including a keyboard, a mouse, etc.; an output section 1407 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), etc., and a speaker, 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, a modem, etc. The communication section 1409 performs communication processing via a network such as the Internet. A drive 1410 is also connected to the I / O interface 1405 as necessary. A removable recording medium 1411 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 1410 as necessary, so that a computer program read therefrom is installed into the storage section 1408 as necessary.

[0185] In particular, according to the embodiments of the present application, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, the embodiments of the present application include a computer program product comprising a computer program for performing the methods shown in the flowcharts carried on a computer readable medium. In such embodiments, the computer program can be downloaded and installed from a network via the communication section 1409, and / or installed from the removable recording medium 1411. When the computer program is executed by the central processing unit (CPU) 1401, various functions defined in the system of the present application are performed.

[0186] It should be noted that the computer-readable medium in the embodiments of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination thereof. The computer-readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination thereof. More specific examples of the computer-readable storage medium can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (Compact Disc Read-Only Memory, CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this application, the 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, device or apparatus. In this application, the computer-readable signal medium can include a data signal carrying computer-readable computer programs in a baseband or as a part of a carrier wave. Such a propagated data signal can take on various forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium that can transmit, propagate or transport a program for use by or in connection with an instruction execution system, device or apparatus. The computer program contained in the computer-readable medium can be transmitted by any suitable medium, including but not limited to wireless, wired, or the like, or any suitable combination thereof.

[0187] The flowcharts and block diagrams in the drawings illustrate the possible implementation architectures, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In the flowcharts or block diagrams, each block can represent a module, a program segment or a part of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur in different orders than that shown in the drawings. For example, two blocks that are shown in succession can actually be executed substantially in parallel, and sometimes in reverse order, depending on the involved functions. It should also be noted that each block in the block diagrams or flowcharts, and the combination of blocks in the block diagrams or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer programs.

[0188] The units described in the embodiments of the present application can be implemented by software, or by hardware, or by a combination of software and hardware. The units described can also be located in a single processor. In some cases, the names of the units do not limit the units themselves.

[0189] As another aspect, the present application also provides a computer readable medium, which can be included in the electronic device described in the above embodiments, or can exist separately without being 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 implement the method described in the above embodiments.

[0190] It should be noted that although several modules or units for performing actions are mentioned in the above detailed description, the division into the modules or units is not mandatory. In fact, according to the embodiments of the present application, features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, features and functions of one module or unit described above can be further divided into a plurality of modules or units.

[0191] From the above description of the embodiments, those skilled in the art will readily appreciate that the example embodiments described herein can be implemented by software and / or by hardware coupled with software. Accordingly, the technical solutions of the embodiments of the present application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, or the like) or on a network, and includes a number of instructions for causing an electronic device to perform the methods according to the embodiments of the present application.

[0192] For example, the electronic device can be a device with wireless communication function, and the device with wireless communication function can perform the multi-link communication method shown in FIG. 2 or FIG. 3.

[0193] Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. The present application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice in the art to which the application pertains.

[0194] It should be understood that the present application is not limited to the precise construction that has been described above and illustrated in the accompanying drawings, and that various modifications and changes can be made by those skilled in the art without departing from the scope of the present application. The scope of the present application is limited only by the appended claims.

Claims

1. A method of multi-link communication, performed by a multi-link device, the method comprising: generating, by a medium access control (MAC) layer of the multi-link device, a first request frame for requesting to start multi-link transmission for a specified type of data packet between the multi-link device and a peer multi-link device; and transmitting, by the MAC layer of the multi-link device, the first request frame to the peer multi-link device. the generating the first request frame comprises: receiving, by the MAC layer of the multi-link device, an enabling request for multi-link transmission for the specified type of data packet sent by a station management entity (SME) of the multi-link device; and generating the first request frame based on the enabling request. 3.The method of claim 1 or 2, wherein if the multi-link device is an access point device, the enabling request comprises at least one of the following information: a MAC address of a non-access point station device, a session token for multi-link transmission of the specified type of data packet, parameters for multi-link transmission of the specified type of data packet; if the multi-link device is a non-access point station device, the enabling request comprises at least one of the following information: a MAC address of an access point device to which the station device is associated, a session token for multi-link transmission of the specified type of data packet; the first request frame comprises at least one of the following field information: a field for indicating a type of the first request frame, a field for indicating that the first request frame adopts a protected high throughput operation, a field for indicating a session token, a field for indicating whether to start multi-link transmission of the specified type of data packet. 5.The method of any one of claims 1 to 4, further comprising: receiving a response frame sent by the peer multi-link device in response to the first request frame, the response frame being used to indicate whether the peer multi-link device allows to start multi-link transmission for the specified type of data packet; the response frame comprises at least one of the following field information: a field for indicating a type of the response frame, a field for indicating that the response frame adopts a protected high throughput operation, a field for indicating a session token, a field for indicating whether to start multi-link transmission of the specified type of data packet, and a status code field for indicating a response result; wherein the status code field is used to indicate one of the following information: allowing to start multi-link transmission for the specified type of data packet, refusing to start multi-link transmission for the specified type of data packet, and a reason for refusing to start multi-link transmission for the specified type of data packet.

2. The multi-link communication method of claim 1, wherein, after receiving the response frame in response to the first request frame, the method further comprises: transmitting, by the MAC layer of the multi-link device, an enabling confirmation for multi-link transmission for the specified type of data packet to the SME of the multi-link device; the enabling confirmation comprises a status code field for indicating a response result. ​ ​ ​ ​ ​ 4. The multi-link communication method according to any one of claims 1 to 3, wherein, ​ ​ ​ ​ 6. The multi-link communication method of claim 5, wherein, ​ ​ ​ 7. The multi-link communication method of claim 5 or 6, wherein, ​ ​ 8. The multi-link communication method of claim 7, wherein, ​ The status code field is used to indicate one of the following information: allowing to start the multi-link transmission for the specified type of data packet, rejecting to start the multi-link transmission for the specified type of data packet, and the reason for rejecting to start the multi-link transmission for the specified type of data packet. 9.The multi-link communication method of any of claims 1-8, further comprising: generating, by a medium access control (MAC) layer of the multi-link device, a second request frame for requesting to release the established multi-link transmission for the specified type of data packet between the multi-link device and the peer multi-link device; sending, to the peer multi-link device, the second request frame.

10. The multi-link communication method of claim 9, wherein, The generating the second request frame comprises: receiving, by the MAC layer of the multi-link device, a stop request for the multi-link transmission for the specified type of data packet sent by an SME of the multi-link device; generating the second request frame based on the stop request. 11.The multi-link communication method of any of claims 1-10, further comprising: upon receiving a service data packet, determining, by a MAC layer of the multi-link device, whether the service data packet is of the specified type based on a value of a specified flag bit included in a packet header of the service data packet; based on determining that the service data packet is of the specified type, performing multi-link transmission on the service data packet. The specified flag bit comprises a flag bit in a service type field in the packet header.

12. The multi-link communication method of any one of claims 1 to 11, wherein, The generating the first request frame comprises: obtaining a service access right of a subscription service provider network (SSPN) for the specified type of data packet; generating the first request frame if it is determined, based on the service access right, that the SSPN allows the multi-link transmission for the specified type of data packet. 13.A multi-link communication method performed by a multi-link device, comprising: receiving, by a MAC layer of the multi-link device, a first request frame sent by a peer multi-link device, the first request frame being used to request to start the multi-link transmission for a specified type of data packet between the peer multi-link device and the multi-link device; generating, by the MAC layer of the multi-link device, a response frame for the first request frame, the response frame being used to indicate whether the multi-link device allows to start the multi-link transmission for the specified type of data packet; sending, by the MAC layer of the multi-link device, the response frame to the peer multi-link device.

14. The multi-link communication method of claim 13, wherein, The generating the response frame for the first request frame comprises: after receiving the first request frame, sending, by the MAC layer of the multi-link device, an enabling indication for the multi-link transmission for the specified type of data packet to an SME of the multi-link device; if receiving an enabling response for the multi-link transmission for the specified type of data packet sent by the SME, generating, by the MAC layer of the multi-link device, the response frame for the first request frame.

15. The multi-link communication method of claim 13 or 14, further comprising: receiving, by a medium access control (MAC) layer of the multi-link device, a second request frame transmitted by the peer multi-link device, the second request frame being used to request to release a multi-link transmission for a specified type of data packet that has been established between the peer multi-link device and the multi-link device; sending, to the SME, a stop indication of the multi-link transmission for the specified type of data packet.

16. A multi-link communication apparatus, comprising: a generating unit configured to generate, at a medium access control (MAC) layer of the multi-link communication apparatus, a first request frame, the first request frame being used to request to start a multi-link transmission for a specified type of data packet between the multi-link communication apparatus and a peer multi-link communication apparatus; a sending unit configured to send, by the medium access control (MAC) layer of the multi-link communication apparatus, the first request frame to the peer multi-link communication apparatus.

17. A multi-link communication apparatus, comprising: a receiving unit configured to receive, at a medium access control (MAC) layer of the multi-link communication apparatus, a first request frame transmitted by a peer multi-link communication apparatus, the first request frame being used to request to start a multi-link transmission for a specified type of data packet between the peer multi-link communication apparatus and the multi-link communication apparatus; a generating unit configured to generate, at the medium access control (MAC) layer of the multi-link communication apparatus, a response frame for the first request frame, the response frame being used to indicate whether the multi-link communication apparatus allows to start the multi-link transmission for the specified type of data packet; a sending unit configured to send, by the medium access control (MAC) layer of the multi-link communication apparatus, the response frame to the peer multi-link communication apparatus.

18. A computer readable medium having stored thereon a computer program which, when executed by a processor, implements the multi-link communication method of any one of claims 1 to 15.

19. An electronic device, comprising: one or more processors; a memory for storing one or more computer programs which, when executed by the one or more processors, cause the electronic device to implement the multi-link communication method of any one of claims 1 to 15.

20. A computer program product, the computer program product comprising a computer program stored in a computer readable storage medium, the computer program being readable by a processor of an electronic device from the computer readable storage medium and configured to cause the electronic device to perform the multi-link communication method of any one of claims 1 to 15.

Images