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

Abstract

The embodiment of the invention provides a multi-link communication method and device, a computer readable medium and electronic equipment. The multi-link communication method comprises the following steps: generating a first message frame, wherein the first message frame is used for requesting to transmit a data packet of a specified service type by adopting multiple links; and sending the first message frame. According to the technical scheme provided by the embodiment of the invention, the transmission efficiency and reliability of the service data packet with a relatively high real-time requirement can be improved.

Description

Technical Field

[0001] 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. Background Technology

[0002] The next-generation Wireless Local Area Network (WLAN) standard is developing and evolving towards continuously increasing throughput. WLAN system standards are mainly researched and discussed in the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards group. Based on previous standard protocols such as 802.11a / b / g / n / ac / ax, the next-generation standard 802.11be takes Extremely High Throughput (EHT) as its technical goal.

[0003] In related technologies, for certain services with high real-time requirements (such as gaming services), in order to ensure the transmission efficiency and reliability of game data, game data is usually mapped to a high priority level. However, if multiple games are online at the same time, it will inevitably cause data transmission congestion and unreliability. Therefore, how to ensure the transmission reliability of data packets for services with high real-time requirements is a technical problem that urgently needs to be solved. Summary of the Invention

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

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part by practice of this application.

[0006] In a first aspect, embodiments of this application provide a multi-link communication method, comprising: generating a first message frame, the first message frame being used to request that data packets of a specified service type be transmitted using multiple links; and sending the first message frame.

[0007] Secondly, embodiments of this application provide a multi-link communication method, comprising: receiving a first message frame, the first message frame being used to request that data packets of a specified service type be transmitted using multiple links; generating a response message frame for the first message frame, the response message frame being used to indicate whether multi-link transmission of data packets of the specified service type is permitted; and sending the response message frame.

[0008] Thirdly, embodiments of this application provide a multi-link communication device, including: a generation unit configured to generate a first message frame, the first message frame being used to request that data packets of a specified service type be transmitted using multiple links; and a sending unit configured to send the first message frame.

[0009] Fourthly, embodiments of this application provide a multi-link communication device, comprising: a receiving unit configured to receive a first message frame, the first message frame being used to request that data packets of a specified service type be transmitted using multiple links; a generating unit configured to generate a response message frame for the first message frame, the response message frame being used to indicate whether multi-link transmission of data packets of the specified service type is permitted; and a sending unit configured to send the response message frame.

[0010] Fifthly, embodiments of this application provide a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the multi-link communication method as described in the above embodiments.

[0011] Sixthly, embodiments of this application provide 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.

[0012] In a seventh aspect, embodiments of this application provide a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of an electronic device reads from 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.

[0013] In some embodiments of this application, a first message frame is generated to request that data packets of a specified service type be transmitted using multiple links. 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.

[0014] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0015] Figure 1 A schematic diagram of the architecture of a wireless communication system provided in an embodiment of this application is shown.

[0016] Figure 2 A flowchart of a multi-link communication method according to an embodiment of this application is shown.

[0017] Figure 3 A flowchart of a multi-link communication method according to an embodiment of this application is shown.

[0018] Figure 4 A schematic diagram of the header structure of an IP data packet according to an embodiment of this application is shown.

[0019] Figure 5 A schematic diagram of fields included in MAC Capabilities according to an embodiment of this application is shown.

[0020] Figure 6 A schematic diagram of fields included in a GDM Access element according to an embodiment of this application is shown.

[0021] Figure 7 A schematic diagram illustrating the definition of a GDM Access Flag according to an embodiment of this application is shown.

[0022] Figure 8 A schematic diagram of a GDM access process according to an embodiment of this application is shown.

[0023] Figure 9 A schematic diagram of a GDM elimination process according to an embodiment of this application is shown.

[0024] Figure 10 A schematic diagram of the process for establishing multi-link GDMAccess Enable using AP MLD and Non-AP MLD according to an embodiment of this application is shown.

[0025] Figure 11 A schematic diagram of the process for establishing multi-link GDMAccess Teardown using AP MLD and Non-AP MLD according to an embodiment of this application is shown.

[0026] Figure 12 A block diagram of a multi-link communication apparatus according to an embodiment of this application is shown.

[0027] Figure 13 A block diagram of a multi-link communication apparatus according to an embodiment of this application is shown.

[0028] Figure 14 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0029] Exemplary embodiments will now be described in a more comprehensive manner with reference to the accompanying drawings. However, the exemplary embodiments can be implemented in various forms and should not be construed as limited to these examples; rather, these embodiments are provided so that this application will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art.

[0030] Furthermore, the features, structures, or characteristics described in this application can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to provide a full understanding of the embodiments of this application. However, those skilled in the art will recognize that when implementing the technical solutions of this application, not all the detailed features in the embodiments may be used, one or more specific details may be omitted, or other methods, elements, devices, steps, etc., may be employed.

[0031] In this application embodiment, the terms "module" or "unit" refer 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. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

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

[0033] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0034] It should be noted that "multiple" in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

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

[0036] The technical solutions provided in this application can be implemented by a communication device in a communication system or by a chip or processor within that device. This communication device can be a wireless communication device that supports parallel transmission across multiple links; 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.

[0037] In this application embodiment, a next-generation 802.11 standard station device that simultaneously supports multiple links is referred to as a multi-link device, where the internal entity responsible for any one link is called a station (STA). If all STAs within a certain MLD are Access Points (APs), it can be further called an AP MLD; if all STAs within a certain MLD are non-access point stations (non-AP STAs), it can be further called a non-AP MLD. In other words, a multi-link device includes one or more affiliated stations (STAs), which are logical stations that can operate on one link, one frequency band, or one channel. The affiliated station can be an AP or a non-AP STA. 802.11be refers to a multi-link device whose affiliated station is an AP as an AP multi-link device (AP MLD), and a multi-link device whose affiliated station is a non-AP STA as a non-AP multi-link device (non-AP MLD).

[0038] See Figure 1 As shown, in an exemplary wireless communication system, at least one AP (such as...) is included. Figure 1 AP101) and at least one non-AP MLD (such as Figure 1(non-AP MLD 102 and non-AP MLD 103). Optionally, Figure 1 The AP 101 shown can be a single-link AP or an AP within an AP MLD; this embodiment does not limit this. The non-AP MLD can communicate with the AP MLD using multiple links to improve throughput. A STA within a non-AP MLD can also communicate with an AP within the AP MLD or a single-link AP via a single link. Understandably, Figure 1 The number of APs and non-AP MLDs is merely an example; any number of APs and non-AP MLDs can be used depending on implementation needs.

[0039] For example, 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. For example, 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. For example, a non-AP MLD is any user communication device that allows users to communicate with an AP and thus with a WLAN. For example, a non-AP MLD can be a smartphone, tablet, laptop, desktop computer, smart TV, smart home device, in-vehicle terminal, aircraft, or other network-connected user devices, or an IoT node in the Internet of Things (IoT), or an in-vehicle communication device in the Internet of Vehicles (IoV); a non-AP MLD can also be a chip and processing system within these terminals. The AP in the embodiments of this application can be a device providing services to a non-AP MLD and can support the 802.11 series protocols. For example, an AP can be a communication server, router, switch, bridge, or other communication entity. Alternatively, an AP can include various forms of macro base stations, micro base stations, relay stations, etc. Of course, an AP can also be the chip and processing system in these various forms of devices, thereby realizing the methods and functions of the embodiments of this application.

[0040] Understandably, multi-link devices can support high-speed, low-latency transmission. With the continuous evolution of wireless LAN application scenarios, 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.). In this application embodiment, the specific forms of Non-AP MLD and AP are not limited; they are merely illustrative examples. The 802.11 protocol can be a protocol that supports or is compatible with 802.11be.

[0041] Although the embodiments of this application are mainly illustrated using WLAN as an example, especially networks applied to the IEEE 802.11 series of standards, those skilled in the art will readily understand that the various aspects involved in the embodiments of this application can be extended to other networks employing various standards or protocols.

[0042] The implementation details of the technical solutions in the embodiments of this application are described in detail below:

[0043] Figure 2 A flowchart of a multi-link communication method according to an embodiment of this application is shown. This multi-link communication method can be executed by a device with wireless communication capabilities. The device with wireless communication capabilities may be... Figure 1 The AP shown (or AP MLD) can also be a non-AP MLD. See reference. Figure 2 As shown, this multi-link communication method includes at least S210 to S220, which are described in detail below:

[0044] In S210, a first message frame is generated, which is used to request that data packets of a specified service type be transmitted using multiple links.

[0045] In some optional embodiments, the data packet specifying the service type can be a multimedia service data packet, such as 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.

[0046] In some optional embodiments, when a device with wireless communication capabilities receives a service data packet, it can determine whether the service data packet belongs to a specified service type based on the value of a specified flag bit included in the header of the service data packet. Optionally, the specified flag bit can be a flag bit in the Type of Service (TOS) field of the header. Optionally, the device with wireless communication capabilities can be a multi-link device (MLD).

[0047] In some optional embodiments, 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 message frame, the MLD MAC layer can receive an enable request message from the MLD's SME, requesting multi-link transmission of data packets for a specified service type; and then generate the first message frame based on this enable request message.

[0048] In some optional embodiments, if the multilink device is an access point device (i.e., AP MLD), the enable request message contains at least one of the following: the MAC address of the non-access point site device (i.e., non-AP MLD), a dialog token for multilink transmission of data packets of the specified service type, and parameters for multilink transmission of data packets of the specified service type.

[0049] In some alternative embodiments, if the multilink device is a non-access point site device (i.e., non-APMLD), the enable request message contains at least one of the following: the MAC address of the access point device (i.e., AP MLD) associated with the site device, and a session token for multilink transmission of data packets of the specified service type.

[0050] In some optional embodiments, the first message frame may include at least one of the following fields: a field indicating the message frame type (Category), a field indicating that the message 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 data packets of a specified service type.

[0051] In some optional embodiments, when generating the first message frame, the device with wireless communication capabilities may obtain service access permissions from the Subscription Service Provider Network (SSPN) for data packets of a specified service type. If it is determined from the service access permissions that the SSPN allows data packets of the specified service type to be transmitted using multiple links, then the first message frame is generated.

[0052] Continue to refer to Figure 2 As shown, in S220, the first message frame is sent.

[0053] Optionally, if the first message frame is generated by the access point device (i.e., AP MLD), then the access point device can send the first message frame to the non-access point site device (i.e., non-AP MLD); if the first message frame is generated by the non-access point site device (i.e., non-AP MLD), then the site device can send the first message frame to the access point device (i.e., AP MLD), or it can also send it to other site devices.

[0054] In some optional embodiments, after sending the first message frame, the device with wireless communication capabilities may receive a response message frame for the first message frame, which indicates whether multi-link transmission is permitted for data packets of a specified service type.

[0055] Optionally, the response message frame may include at least one of the following fields: a field indicating the message frame type (Category), a field indicating that the message frame adopts Protected EHT Action (Protected EHT Action), a field indicating the session token, a field indicating whether to enable multi-link transmission of data packets of a specified service type, and a status code field indicating the response result (Status Code Field).

[0056] Optionally, the status code field can be used to indicate that multi-link transmission of data packets for a specified service type is permitted; or the status code field can be used to indicate that multi-link transmission of data packets for a specified service type is denied; or the status code field can be used to indicate the reason for denying multi-link transmission of data packets for a specified service type; or the status code field can be used to indicate both the reason for denying multi-link transmission of data packets for a specified service type and the reason for denying multi-link transmission of data packets for a specified service type.

[0057] In some optional embodiments, after receiving a response message frame for the first message frame, the MLD MAC layer of the device with wireless communication capabilities can send an enable confirmation message to the SME for multi-link transmission of data packets of a specified service type. Optionally, the enable confirmation message may include a status code field indicating the response result; wherein the status code field may be used to indicate that multi-link transmission of data packets of the specified service type is allowed; or the status code field may be used to indicate that multi-link transmission of data packets of the specified service type is rejected; or the status code field may be used to indicate the reason for rejecting multi-link transmission of data packets of the specified service type; or the status code field may be used to indicate both rejecting multi-link transmission of data packets of the specified service type and indicating the reason for rejecting multi-link transmission of data packets of the specified service type.

[0058] In some optional embodiments, after a multi-link transmission is established for a data packet of a specified service type, if it is necessary to stop the multi-link transmission, the device with wireless communication capabilities can generate a second message frame to indicate that the multi-link transmission for the data packet of the specified service type should be stopped, and then the second message frame can be sent.

[0059] Optionally, if the second message frame is generated by the access point device (i.e., AP MLD), then the access point device can send the second message frame to the non-access point site device (i.e., non-AP MLD); if the second message frame is generated by the non-access point site device (i.e., non-AP MLD), then the site device can send the second message frame to the access point device (i.e., AP MLD), or it can also send it to other site devices.

[0060] In some optional embodiments, when generating the second message frame, a tear down request message sent by the SME of the multi-link device for multi-link transmission of data packets of a specified service type can be received; then the second message frame can be generated based on the tear down request message.

[0061] In some alternative embodiments, if the multi-link device is an access point device (i.e., AP MLD), the stop request message includes the MAC address of the non-access point site device (i.e., non-AP MLD).

[0062] In some optional embodiments, if the multi-link device is a non-access point site device (i.e., non-APMLD), the enable request message includes the MAC address of the access point device (i.e., AP MLD) associated with the site device. Optionally, when it is necessary to send the stop request message to the associated access point device, the stop request message may not include the MAC address of the access point device (i.e., AP MLD) associated with the site device.

[0063] Figure 3 A flowchart of a multi-link communication method according to an embodiment of this application is shown. This multi-link communication method can be executed by a device with wireless communication capabilities. The device with wireless communication capabilities may be... Figure 1 The AP shown (or AP MLD) can also be a non-AP MLD. See reference. Figure 3 As shown, this multi-link communication method includes at least S310 to S330, which are described in detail below:

[0064] In S310, a first message frame is received, which is used to request that data packets of a specified service type be transmitted using multiple links.

[0065] In some optional embodiments, the first message frame may include at least one of the following fields: a field indicating the message frame type (Category), a field indicating that the message 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 data packets of a specified service type.

[0066] In S320, a response message frame is generated for the first message frame. This response message frame is used to indicate whether multi-link transmission is allowed for data packets of a specified service type.

[0067] In some optional embodiments, the response message frame may include at least one of the following fields: a field indicating the message frame type (Category), a field indicating that the message frame adopts Protected EHT Action (Protected EHT Action), a field indicating the session token, a field indicating whether to enable multi-link transmission of data packets of a specified service type, and a status code field indicating the response result (Status CodeField).

[0068] Optionally, the status code field can be used to indicate that multi-link transmission of data packets for a specified service type is permitted; or the status code field can be used to indicate that multi-link transmission of data packets for a specified service type is denied; or the status code field can be used to indicate the reason for denying multi-link transmission of data packets for a specified service type; or the status code field can be used to indicate both the reason for denying multi-link transmission of data packets for a specified service type and the reason for denying multi-link transmission of data packets for a specified service type.

[0069] In some optional embodiments, after receiving the first message frame, the MLDMAC layer of the device with wireless communication capabilities can send an enable indication message for multi-link transmission of data packets for a specified service type to the SME. If an enable response message for multi-link transmission of data packets for a specified service type is received from the SME, a response message frame for the first message frame is generated.

[0070] In S330, a response message frame is sent.

[0071] Optionally, if the response message frame is generated by the access point device (i.e., AP MLD), the access point device can send the response message frame to the non-access point site device (i.e., non-AP MLD) that sent the first message frame; if the response message frame is generated by the non-access point site device (i.e., non-AP MLD), the site device can send the response message frame to the access point device (i.e., AP MLD) that sent the first message frame, or it can send it to other site devices that sent the first message frame.

[0072] In some optional embodiments, after a multi-link transmission for a data packet of a specified service type is established, if a second message frame is received indicating that the multi-link transmission for the data packet of the specified service type should be stopped, the MLD MAC layer may send a teardown indication message to the SME to stop the multi-link transmission of the data packet of the specified service type.

[0073] It should be noted that in the above embodiments, the first message frame and the second message frame can be management frames or other message frames.

[0074] The following uses a game data packet as an example to illustrate the technical solution of this application embodiment:

[0075] Because games have extremely high real-time requirements—for example, players are most concerned with their shooting results and whether their character survives—and various messages are updated in real time, this places higher demands on the efficiency and reliability of underlying game data transmission. Ensuring the efficiency and reliability of game data transmission is therefore particularly important. The processing methods in related technologies map game data to high priority levels. This means that all game operators map their game data to a high priority level based on Traffic Identifiers (TIDs). If multiple game operators have games online simultaneously, it will inevitably cause data transmission congestion and unreliability.

[0076] Based on the aforementioned problems in related technologies, the technical solution of this application proposes that after establishing a packet-level connection between an AP (such as AP-MLD) and a STA (such as 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.

[0077] like Figure 4 As shown, the IP header of the IP data packet for game services includes the following fields:

[0078] Version: 4 digits. Used to indicate the version of the IP protocol. If it is IPv4, then it is always 4.

[0079] 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).

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

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

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

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

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

[0085] Time To Live (TTL): 8 bits. When an IP packet is sent, this field is initially assigned a specific value. As the IP packet passes through each router along its path, each router decrements the TTL value by 1. If the TTL reaches 0, the IP packet is discarded. This field prevents IP packets from being continuously forwarded through the network due to routing loops.

[0086] 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).

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

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

[0089] IP options: Variable length, up to 40 bytes.

[0090] In the IEEE protocol, 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.

[0091] In some optional embodiments, 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 (GDMAccess 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:

[0092] Values Meaning Time priority …… …… …… 13 (New) GDM Access Enable Request No 14 (New) GDM Access Enable Response No 15 (New) GDM Access Teardown No 16～255

[0093] Table 1

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

[0095] Order Meaning 1 Category 2 Protected EHT Action 3 Dialog Token 4 Game Data Multi-Link Access element

[0096] Table 2

[0097] 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 EHCAction field" section of the standard protocol; this embodiment adds three values: GDM Access Enable Request, GDM AccessEnable 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 AccessRequest / Response frames. The Game Data Multi-Link Access element is used to indicate whether multi-link transmission of game data is enabled.

[0098] Optionally, if the Game Data Multi-Link Access Enable Request frame contains a Game Data Multi-Link Access element, then it can be indicated that game data multi-link transmission is enabled; if the Game Data Multi-Link Access Enable Request frame does not contain a Game Data Multi-Link Access element, then it can be indicated that game data multi-link transmission is disabled. Alternatively, different values ​​can be set to indicate whether game data multi-link transmission is enabled or disabled.

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

[0100] Order Meaning 1 Category 2 Protected EHT Action 3 Dialog Token 4 Status Code 5 Game Data Multi-Link Access element

[0101] Table 3

[0102] 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 EHCAction field" section of the standard protocol. This embodiment adds three new values: GDM Access Enable Request, GDM AccessEnable Response, and GDM Access Teardown. As a response 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 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.

[0103] The Game Data Multi-Link Access element is used to indicate whether game data multi-link transmission is enabled. Optionally, if the Game Data Multi-Link Access Enable Request frame contains the Game Data Multi-Link Access element, it indicates that game data multi-link transmission is enabled; if the Game Data Multi-Link Access Enable Request frame does not contain the Game Data Multi-Link Access element, it indicates that game data multi-link transmission is disabled. Alternatively, different values ​​can be set to indicate whether game data multi-link transmission is enabled.

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

[0105] Order Meaning 1 Category 2 Protected EHT Action

[0106] Table 4

[0107] 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 EHCAction field" section of the standard protocol. In this embodiment, three new values ​​have been added: GDM Access Enable Request, GDM AccessEnable Response, and GDM Access Teardown.

[0108] In some optional embodiments, for status codes, embodiments of this application may add three status code values ​​to support GDM Access, as shown in Table 5 below:

[0109]

[0110] Table 5

[0111] It should be noted that in other embodiments of this application, more Status Code values ​​may be added to support GDM Access.

[0112] In some optional embodiments, additional fields can be added to MAC Capabilities to indicate AP MLD or Non-AP MLD support for GDM Access. Specifically, the fields included in MAC Capabilities are as follows: Figure 5As shown, it specifically includes: Emergency Preparedness Communications Service (EPCS) priority access support, EHT OMControl 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, and GDM Access support. Support and Reserved fields. Among them, 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.

[0113] exist Figure 5Among the fields shown, 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, bit B15 remains reserved.

[0114] In some optional embodiments, additional element IDs supporting GDM Access can be added, as shown in Table 6 below:

[0115]

[0116] Table 6

[0117] In some optional embodiments, the GDM Access element is defined as follows: Figure 6 As shown, it includes: Element ID, Length, Element ID Extension, and GDM Access Flags.

[0118] Optionally, the GDM Access Flag may support multi-link transport definitions such as... Figure 7 As shown, a flag can be used for indication. For example, if the value of the flag is 1, the manual indicates that multi-link transmission is supported; if the value of the flag is 0, it indicates that multi-link transmission is not supported.

[0119] In some optional embodiments, additional types supporting GDM Access can be added to the Multi-Link field of the Multi-Link element, as shown in Table 7 below:

[0120]

[0121] Table 7

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

[0123] In some optional embodiments, 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). Here, MLME refers to the MAC Layer Management Entity. The following describes each primitive.

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

[0125] The primitive parameters are as follows:

[0126] MLME-GDMACCESSENABLE.request(

[0127] PeerSTAAddress

[0128] Dialog Token

[0129] GDMAccessMultiLink )

[0131] The relevant explanations for PeerSTAAddress, Dialog Token, and GDMAccessMultiLink are shown in Table 8 below:

[0132]

[0133] Table 8

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

[0135] In some optional embodiments, the MLME-GDMACCESSENABLE.confirm primitive is used to report a response to a peer MAC entity's GDM Access request.

[0136] The primitive parameters are as follows:

[0137] MLME-GDMACCESSENABLE.confirm(

[0138] PeerSTAAddress

[0139] Dialog Token

[0140] Status Code

[0141] GDMAccessMultiLink )

[0143] The relevant explanations for PeerSTAAddress, Dialog Token, Status Code, and GDMAccessMultiLink are shown in Table 9 below:

[0144]

[0145] Table 9

[0146] The MLME-GDMACCESSENABLE.confirm primitive is generated by the MLME upon receiving GDM Access enabled, resulting in a response frame from the peer MAC entity.

[0147] In some alternative embodiments, the MLME-GDMACCESSENABLE.indication primitive indicates that a GDM Access Enable Request has been received from the peer MAC entity.

[0148] The primitive parameters are as follows:

[0149] MLME-GDMACCESSENABLE.indication(

[0150] PeerSTAAddress

[0151] Dialog Token

[0152] GDMAccessMultiLink )

[0154] The relevant explanations for PeerSTAAddress, Dialog Token, and GDMAccessMultiLink are shown in Table 10 below:

[0155]

[0156] Table 10

[0157] The MLME-GDMACCESSENABLE.indication primitive is generated by the MLME after receiving a GDMAccess Enable Request frame from a peer MAC entity.

[0158] In some optional embodiments, the MLME-GDMACCESSENABLE.response primitive is generated by the MLME and used to send a response enabling GDM Access to the peer MAC entity.

[0159] The primitive parameters are as follows:

[0160] MLME-GDMACCESSENABLE.response(

[0161] PeerSTAAddress

[0162] Dialog Token

[0163] Status Code

[0164] GDMAccessMultiLink )

[0166] The relevant explanations for PeerSTAAddress, Dialog Token, Status Code, and GDMAccessMultiLink are shown in Table 11 below:

[0167]

[0168] Table 11

[0169] The MLME-GDMACCESSENABLE.response primitive is generated by SME as a response to the MLME-GDMACCESSENABLE.indication primitive.

[0170] In some alternative embodiments, the MLME-GDMACCESSTEARDOWN.request primitive is used to instruct a peer MAC entity to torrent down GDM Access.

[0171] The primitive parameters are as follows:

[0172] MLME-GDMACCESSTEARDOWN.request(

[0173] PeerSTAAddress )

[0175] The relevant information about PeerSTAAddress is shown in Table 12 below:

[0176]

[0177] Table 12

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

[0179] In some optional embodiments, the MLME-GDMACCESSTEARDOWN.indication primitive is used to instruct a peer MAC entity to release GDM Access.

[0180] The primitive parameters are as follows:

[0181] MLME-GDMACCESSTEARDOWN.indication(

[0182] PeerSTAAddress )

[0184] The relevant information about PeerSTAAddress is shown in Table 13 below:

[0185]

[0186] Table 13

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

[0188] In some optional embodiments, to support GDM Access, an Abstract Syntax Notation One (ASN.1) message can be added to this embodiment. Specifically, an ASN.1 message `dot11EHTGDMAccessActivated` (meaning EHT GDM access is activated) can be added to the `Dot11EHTStationConfigEntry` (i.e., the EHT site configuration entry), and this message can be set to an object type. Optionally, `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.

[0189] Additionally, an ASN.1 message `dot11GDMAccessAuthorized` (GDM access authorization) can be added to the `Dot11InterworkingEntry` (interactive working entry), and this message can be set to an object type. Optionally, `dot11GDMAccessAuthorized` can be a control variable written by the SME after the AP receives permission from the SSPN interface for a non-APSTA to use GDM access. When this attribute is true, it indicates that non-AP STAs are allowed to invoke and use GDM access capabilities; if this attribute is false, non-AP STAs are not allowed to invoke and use GDM access capabilities.

[0190] In some optional embodiments, GDM access is initiated by the SME and established on the MAC. GDM access between the GDM AP-MLD and its associated GDM Non-AP MLD can be in two states: enabled or torn down. Optionally, both the AP-MLD and the Non-AP MLD can have dot11EHTGDMAccessActivated set to true.

[0191] 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. During the (re)association process, the AP MLD obtains the information required to verify that the Non-AP MLD uses GDM Access. It can also set dot11SSPNInterfaceActivated 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.

[0192] The AP MLD that successfully obtains GDM access permission from the Non-AP MLD should update the value of dot11GDMAccessAuthorized in the dot11InterworkingEntry 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 the other to initiate GDM access.

[0193] Based on the descriptions in the above embodiments, in one embodiment of this application, such as Figure 8 The GDM access process is as follows: When 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. After receiving this primitive, the MLD MAC sends a GDM AccessEnable 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.

[0194] 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 EnableResponse frame to the initiating MLD MAC, which then sends MLME-GDMACCESSENABLE.confirm to its MLD SME. In this scenario, if the responding party agrees 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.

[0195] In one embodiment of this application, such as Figure 9 The GDM teardown process is as follows: When the initiating party (such as AP MLD or Non-AP MLD) needs to tear down GDM access, its MLD SME sends an MLME-GDMACCESSTEARDOWN.request to its MLD MAC. After receiving this primitive, the MLD MAC sends a GDM Access Enable Teardown frame to the responding party's (such as AP MLD or Non-AP MLD) MLD MAC. Then, the responding party's MLD MAC can send an MLME-GDMACCESSTEARDOWN.indication to the responding party's MLD SME to remove the GDM access.

[0196] In one embodiment of this application, 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 will set the GDM access state to the torn down state and apply it to all enabled links between MLDs.

[0197] In one embodiment of this application, the process for establishing multi-link GDM Access Enable between AP MLD and Non-AP MLD is as follows: Figure 10As shown: When the initiator (such as an AP MLD or Non-AP MLD) detects game data packets and determines that multi-link access is allowed, it sends a GDM Access EnableResponse frame to the responder (such as an AP MLD or Non-AP MLD). In this case, if the responder's response frame indicates agreement to GDM access, the GDM access process is completed between the initiator and the responder, and game service data packets can then be transmitted via multiple links.

[0198] In one embodiment of this application, the multi-link GDM AccessTeardown process established by the AP MLD and Non-AP MLD is as follows: Figure 11 As shown: When the initiator (such as AP MLD or Non-AP MLD) needs to tear down GDM access, it sends a GDM Access Enable Teardown frame to the responder (such as AP MLD or Non-AP MLD) to eliminate GDM access.

[0199] In summary, 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. Specifically, in this embodiment, 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. Additionally, GDM Access support is added to MAC capabilities and set to `true`. In this embodiment, the STA or AP sends a GDM Access Enable Request frame to 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 desired by the STA or AP, even in situations with weak network coverage or network congestion.

[0200] Through the optimizations of the embodiments of this application, especially in the low-latency service transmission process, 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. Especially in scenarios with weak wireless network coverage or in scenarios where ongoing services are congested, the reliability of low-latency data service packet transmission can be improved, thereby enhancing the user experience.

[0201] It should be noted that the technical solutions of this application embodiment 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, CR services, etc.

[0202] The following describes an apparatus embodiment of this application, which can be used to execute the multi-link communication method described above in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the multi-link communication method described above in this application.

[0203] Figure 12 A block diagram of a multi-link communication device according to an embodiment of this application is shown. This multi-link communication device can be disposed within a device having wireless communication functionality. The device having wireless communication functionality can be... Figure 1 The AP shown (or AP MLD) can be either a non-AP MLD or an AP MLD.

[0204] Reference Figure 12 As shown, a multi-link communication device 1200 according to an embodiment of this application includes: a generation unit 1202 and a transmission unit 1204.

[0205] The generation unit 1202 is configured to generate a first message frame, which is used to request that data packets of a specified service type be transmitted using multiple links; the sending unit 1204 is configured to send the first message frame.

[0206] In some embodiments of this application, based on the foregoing scheme, the generation unit 1202 is configured to: receive an enable request message sent by the site management entity (SME) of the multi-link device for multi-link transmission of data packets of the specified service type; and generate the first message frame based on the enable request message.

[0207] In some embodiments of this application, based on the foregoing scheme, if the multi-link device is an access point device, the enable request message contains at least one of the following: the Media Access Control (MAC) address of the non-access point site device, a session token for multi-link transmission of data packets of the specified service type, and parameters for multi-link transmission of data packets of the specified service type; if the multi-link device is a non-access point site device, the enable request message contains at least one of the following: the MAC address of the access point device associated with the site device, and a session token for multi-link transmission of data packets of the specified service type.

[0208] In some embodiments of this application, based on the foregoing scheme, the first message frame includes at least one of the following fields: a field indicating the message frame type, a field indicating that the message frame adopts protected ultra-high throughput operation, a field indicating a session token, and a field indicating whether to enable multi-link transmission of data packets of a specified service type.

[0209] In some embodiments of this application, based on the foregoing scheme, the multi-link communication device further includes: a receiving unit configured to receive a response message frame for the first message frame, the response message frame being used to indicate whether data packets for the specified service type are allowed to be transmitted using multiple links.

[0210] In some embodiments of this application, based on the foregoing scheme, the sending unit 1204 is further configured to: after receiving a response message frame for the first message frame, send an enable confirmation message for multi-link transmission of data packets for the specified service type to the SME of the multi-link device.

[0211] In some embodiments of this application, based on the foregoing scheme, the enable confirmation message includes a status code field for indicating the response result; wherein, the status code field is used to indicate one of the following: allowing multi-link transmission of data packets for the specified service type, refusing multi-link transmission of data packets for the specified service type, or the reason for refusing multi-link transmission of data packets for the specified service type.

[0212] In some embodiments of this application, based on the foregoing scheme, the response message frame includes at least one of the following fields: a field indicating the message frame type, a field indicating that the message frame uses protected ultra-high throughput operation, a field indicating the session token, a field indicating whether to enable multi-link transmission of data packets of a specified service type, and a status code field indicating the response result.

[0213] The status code field is used to indicate one of the following: allowing multi-link transmission of data packets for the specified service type, refusing multi-link transmission of data packets for the specified service type, or the reason for refusing multi-link transmission of data packets for the specified service type.

[0214] In some embodiments of this application, based on the foregoing scheme, the generating unit 1202 is further configured to: generate a second message frame, the second message frame being used to indicate that multi-link transmission should be stopped for data packets of a specified service type; the sending unit 1204 is further configured to: send the second message frame.

[0215] In some embodiments of this application, based on the foregoing scheme, the generation unit 1202 is configured to: receive a stop request message sent by the SME of the multi-link device for multi-link transmission of data packets of the specified service type; and generate the second message frame based on the stop request message.

[0216] In some embodiments of this application, based on the foregoing scheme, the multi-link communication device further includes: a determining unit, configured to determine whether the service data packet is a data packet of the specified service type based on the value of a specified flag bit contained in the header of the service data packet when a service data packet is received; wherein the specified flag bit includes a flag bit in the service type field of the header.

[0217] In some embodiments of this application, based on the foregoing scheme, the generation unit 1202 is configured to: obtain the service access permissions of the Subscription Service Provider Network (SSPN) for the specified service type of data packets; if it is determined from the service access permissions that the SSPN allows the data packets for the specified service type to be transmitted using multiple links, then generate the first message frame.

[0218] Figure 13 A block diagram of a multi-link communication device according to an embodiment of this application is shown. This multi-link communication device can be disposed within a device having wireless communication functionality. The device having wireless communication functionality can be... Figure 1 The AP shown (or AP MLD) can be either a non-AP MLD or an AP MLD.

[0219] Reference Figure 13 As shown, a multi-link communication device 1300 according to an embodiment of this application includes: a receiving unit 1302, a generating unit 1304, and a transmitting unit 1306.

[0220] The receiving unit 1302 is configured to receive a first message frame, which is used to request that data packets of a specified service type be transmitted using multiple links; the generating unit 1304 is configured to generate a response message frame for the first message frame, which is used to indicate whether data packets of the specified service type are allowed to be transmitted using multiple links; and the sending unit 1306 is configured to send the response message frame.

[0221] In some embodiments of this application, based on the foregoing scheme, the generation unit 1304 is configured to: after receiving the first message frame, send an enable indication message for multi-link transmission of data packets of the specified service type to the SME of the multi-link device; if an enable response message for multi-link transmission of data packets of the specified service type sent by the SME is received, then a response message frame for the first message frame is generated.

[0222] In some embodiments of this application, based on the foregoing scheme, the receiving unit 1302 is further configured to: receive a second message frame, the second message frame being used to indicate that multi-link transmission of data packets for a specified service type should be stopped; the sending unit 1306 is further configured to: send a stop indication message for multi-link transmission of data packets for the specified service type to the SME.

[0223] Figure 14 A schematic diagram of a computer system suitable for implementing an electronic device according to the embodiments of this application is shown. The electronic device may be a device with wireless communication function as described in the foregoing embodiments.

[0224] It should be noted that, Figure 14 The computer system 1400 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0225] like Figure 14 As shown, the computer system 1400 may include a Central Processing Unit (CPU) 1401, which can perform various appropriate actions and processes based on a program stored in Read-Only Memory (ROM) 1402 or a program loaded from storage portion 1408 into Random Access Memory (RAM) 1403, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1403. The CPU 1401, ROM 1402, and RAM 1403 are interconnected via bus 1404. An Input / Output (I / O) interface 1405 is also connected to bus 1404.

[0226] The following components can be connected to I / O interface 1405: input section 1406 including keyboard, mouse, etc.; output section 1407 including cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; storage section 1408 including hard disk, etc.; and communication section 1409 including network interface card, modem, etc. Communication section 1409 performs communication processing via a network such as the Internet. Drive 1410 is also connected to I / O interface 1405 as needed. Removable media 1411, such as 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.

[0227] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, 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. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1409, and / or installed from removable medium 1411. When the computer program is executed by central processing unit (CPU) 1401, it performs various functions defined in the system of this application.

[0228] It should be noted that 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. In this application, 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. In this application, 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.

[0229] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. 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. It should also be noted that in some alternative implementations, 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. It should also be noted that 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.

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

[0231] In another aspect, 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.

[0232] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0233] From the above description of the embodiments, those skilled in the art will readily understand that 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.

[0234] For example, an electronic device can be a device with wireless communication capabilities, and a device with wireless communication capabilities can perform... Figure 2 or Figure 3 The multi-link communication method shown.

[0235] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0236] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method of multi-link communication, the method comprising: The method comprises: generating a first message frame for requesting to transmit data packets of a specified service type by multi-link; sending the first message frame.

2. The multi-link communication method of claim 1, wherein, The generating of the first message frame comprises: receiving an enabling request message for multi-link transmission of the data packets of the specified service type sent by a station management entity (SME) of a multi-link device; generating the first message frame based on the enabling request message.

3. The multi-link communication method according to claim 2, wherein if the multi-link device is an access point device, the enabling request message comprises at least one of the following information: a medium access control (MAC) address of a non-access point station device, a session token for multi-link transmission of the data packets of the specified service type, and parameters for multi-link transmission of the data packets of the specified service type; if the multi-link device is a non-access point station device, the enabling request message comprises at least one of the following information: a MAC address of an access point device associated with the station device, and a session token for multi-link transmission of the data packets of the specified service type.

4. The multi-link communication method of claim 1, wherein, The first message frame comprises at least one of the following field information: a field for indicating a message frame type, a field for indicating that the message frame adopts a protected ultra-high throughput operation, a field for indicating a session token, and a field for indicating whether to enable multi-link transmission of the data packets of the specified service type.

5. The multi-link communication method of claim 1, wherein, The method further comprises: receiving a response message frame for the first message frame, the response message frame being used to indicate whether to allow the data packets of the specified service type to be transmitted by multi-link.

6. The multi-link communication method of claim 5, wherein, After receiving the response message frame for the first message frame, the method further comprises: sending an enabling confirmation message for multi-link transmission of the data packets of the specified service type to an SME of the multi-link device.

7. The multi-link communication method of claim 6, wherein, The enabling confirmation message comprises a status code field for indicating a response result; wherein the status code field is used to indicate one of the following information: allowing multi-link transmission of the data packets of the specified service type, rejecting multi-link transmission of the data packets of the specified service type, and a reason for rejecting multi-link transmission of the data packets of the specified service type.

8. The multi-link communication method of claim 5, wherein, The response message frame comprises at least one of the following field information: a field for indicating a message frame type, a field for indicating that the message frame adopts a protected ultra-high throughput operation, a field for indicating a session token, a field for indicating whether to enable multi-link transmission of the data packets of the specified service type, 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 multi-link transmission of the data packets of the specified service type, rejecting multi-link transmission of the data packets of the specified service type, and a reason for rejecting multi-link transmission of the data packets of the specified service type.

9. The multi-link communication method of claim 1, wherein, The method further comprises: generating a second message frame, the second message frame being used to indicate to stop multi-link transmission for data packets of a specified service type; sending the second message frame.

10. The multi-link communication method of claim 9, wherein, The generating the second message frame comprises: receiving a stop request message for multi-link transmission of data packets of the specified service type sent by an SME of a multi-link device; generating the second message frame based on the stop request message.

11. The multi-link communication method of claim 1, wherein, The multi-link communication method further comprises: upon receiving a service data packet, determining whether the service data packet is a data packet of the specified service type according to a value of a specified flag bit contained in a packet header of the service data packet; wherein the specified flag bit comprises a flag bit in a service type field in the packet header.

12. The multi-link communication method according to any of claims 1 to 11, wherein, The generating the first message frame comprises: obtaining service access authority of a subscription service provider network (SSPN) for data packets of the specified service type; if it is determined according to the service access authority that the SSPN allows multi-link transmission for data packets of the specified service type, generating the first message frame.

13. A method of multi-link communication, the method comprising: comprises: receiving a first message frame, the first message frame being used to request multi-link transmission for data packets of a specified service type; generating a response message frame for the first message frame, the response message frame being used to indicate whether multi-link transmission is allowed for data packets of the specified service type; sending the response message frame.

14. The multi-link communication method of claim 13, wherein, The generating the response message frame for the first message frame comprises: after receiving the first message frame, sending an enable indication message for multi-link transmission of data packets of the specified service type to an SME of a multi-link device; if an enable response message for multi-link transmission of data packets of the specified service type sent by the SME is received, generating the response message frame for the first message frame.

15. The multi-link communication method of claim 13, wherein, The multi-link communication method further comprises: receiving a second message frame, the second message frame being used to indicate to stop multi-link transmission for data packets of a specified service type; sending a stop indication message for multi-link transmission of data packets of the specified service type to the SME.

16. A multi-link communication device, comprising: comprises: a generating unit, configured to generate a first message frame, the first message frame being used to request multi-link transmission for data packets of a specified service type; a sending unit, configured to send the first message frame.

17. A multi-link communication device, comprising: comprises: a receiving unit, configured to receive a first message frame, the first message frame being used to request multi-link transmission for data packets of a specified service type; a generating unit, configured to generate a response message frame for the first message frame, the response message frame being used to indicate whether multi-link transmission is allowed for data packets of the specified service type; a sending unit, configured to send the response message frame.

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

19. An electronic device, comprising: comprises: one or more processors; A memory for storing one or more computer programs that, 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-15.

20. A computer program product, characterised in that, The computer program product includes a computer program stored in a computer readable storage medium, and 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 of any one of claims 1-15.

Images