Data transmission method, communication device, storage medium and computer program product

Abstract

The invention provides a data transmission method, which is characterized by comprising the following steps that: a first node sends a first request frame to a second node, and the first request frame comprises orthogonal sequence capability information of the first node; the first node receives a first response frame sent by the second node, the first response frame comprising first orthogonal sequence number information; and the first node generates a first orthogonal sequence according to the first orthogonal sequence number information. The invention further provides a communication device, a storage medium and a computer program product.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of communication, and in particular, to a data transmission method, an electronic device and a computer readable storage medium. BACKGROUND

[0002] Currently in a wireless fidelity (WiFi) system, a transmission opportunity (TXOP) preemption technology can be used to guarantee low latency of traffic. In addition, it is proposed to use an orthogonal sequence (OS) as a preemption request (PR) when preemption of TXOP. However, the management method of using the OS as the PR for TXOP preemption has not been specified in the current WiFi standard. SUMMARY

[0003] The present disclosure provides a data transmission method, a communication device, a storage medium and a computer program product.

[0004] In a first aspect, an embodiment of the present disclosure provides a data transmission method, characterized in that comprising: a first node sends a first request frame to a second node, wherein the first request frame comprises OS capability information of the first node; the first node receives a first response frame sent by the second node, wherein the first response frame comprises first orthogonal sequence number (OS ID) information; and the first node generates a first OS according to the first OS ID information.

[0005] In a second aspect, an embodiment of the present disclosure further provides a data transmission method, characterized in that comprising: a second node receives a first request frame sent by a first node, wherein the first request frame comprises OS capability information of the first node; and the second node sends a first response frame to the first node, wherein the first response frame comprises first OS ID information.

[0006] In a third aspect, an embodiment of the present disclosure further provides a communication device, characterized in that comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the data transmission method according to the present disclosure when executing the computer program.

[0007] In a fourth aspect, an embodiment of the present disclosure further provides a storage medium, characterized in that the storage medium stores a computer program, and the computer program is executed by a processor to implement the data transmission method according to the present disclosure.

[0008] In a fifth aspect, the present disclosure also provides a computer program product comprising a computer program which, when executed by a processor, implements the data transmission method according to the present disclosure.

[0009] According to the data transmission method, the communication device, the storage medium and the computer program product of the embodiments of the present disclosure, the first node notifies the second node of the OS capability information of the first node, and generates an OS according to the OS ID allocated to the first node by the second node, so that the first node can use the OS as a PR to perform TXOP preemption, thereby achieving management of the OS. BRIEF DESCRIPTION OF DRAWINGS

[0010] In the drawings of the embodiments of the present disclosure:

[0011] Figure 1 is a flowchart of the data transmission method according to the embodiments of the present disclosure;

[0012] Figure 2 is another flowchart of the data transmission method according to the embodiments of the present disclosure;

[0013] Figure 3 is another flowchart of the data transmission method according to the embodiments of the present disclosure;

[0014] Figure 4 is another flowchart of the data transmission method according to the embodiments of the present disclosure;

[0015] Figure 5 is another flowchart of the data transmission method according to the embodiments of the present disclosure;

[0016] Figure 6 is a schematic diagram in a multi-link device application scenario according to the embodiments of the present disclosure;

[0017] Figure 7 is another flowchart of the data transmission method according to the embodiments of the present disclosure;

[0018] Figure 8 is another flowchart of the data transmission method according to the embodiments of the present disclosure;

[0019] Figure 9 is another flowchart of the data transmission method according to the embodiments of the present disclosure;

[0020] Figure 10 is another flowchart of the data transmission method according to the embodiments of the present disclosure;

[0021] Figure 11 is a schematic diagram in a roaming application scenario according to the embodiments of the present disclosure;

[0022] Figure 12is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0023] Figure 13 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0024] Figure 14 is a schematic diagram of a multi-link device in a roaming application scenario according to an embodiment of the present disclosure;

[0025] Figure 15 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0026] Figure 16 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0027] Figure 17 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0028] Figure 18 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0029] Figure 19 is a flowchart of a data transmission method according to an embodiment of the present disclosure;

[0030] Figure 20 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0031] Figure 21 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0032] Figure 22 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0033] Figure 23 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0034] Figure 24 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0035] Figure 25 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0036] Figure 26 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0037] Figure 27 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0038] Figure 28is a schematic diagram illustrating data transmission between a terminal device and an access device;

[0039] Figure 29 is a schematic diagram illustrating data transmission between a terminal device and an access device when the terminal device and the access device are multi-link devices;

[0040] Figure 30 is another schematic diagram illustrating data transmission between a terminal device and an access device when the terminal device and the access device are multi-link devices;

[0041] Figure 31 is a schematic diagram illustrating data transmission when a terminal device roams between two access devices;

[0042] Figure 32 is another schematic diagram illustrating data transmission when a terminal device roams between two access devices;

[0043] Figure 33 is another schematic diagram illustrating data transmission when a terminal device roams between two access devices;

[0044] Figure 34 is a schematic diagram illustrating data transmission when a terminal device is a multi-link device with two access devices and roams between the two access devices;

[0045] Figure 35 is a constituent block diagram of a communication device according to an embodiment of the present disclosure; and

[0046] Figure 36 is a constituent block diagram of a computer readable storage medium according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0047] In order for those skilled in the art to better understand the technical solutions of the present disclosure, the embodiments of the present disclosure will be described in detail below with reference to the drawings.

[0048] The embodiments shown will be described in the following with reference to the drawings, but the embodiments shown can be embodied in various forms, and the present disclosure should not be interpreted as being limited to the embodiments set forth below. Rather, the purpose of providing these embodiments is to make the present disclosure thorough and complete, and to enable those skilled in the art to fully understand the scope of the present disclosure.

[0049] The drawings of the embodiments of the present disclosure serve to provide further understanding of the embodiments of the present disclosure, and form a part of the specification, together with the detailed embodiments, to explain the present disclosure, and do not constitute a limitation of the present disclosure. The above and other features and advantages will become more apparent to those skilled in the art by describing the detailed embodiments with reference to the drawings.

[0050] The present disclosure can be described with reference to plan views and / or cross-sectional views by virtue of the idealized illustrative representations of the present disclosure. Accordingly, the example illustrations can be modified according to manufacturing techniques and / or tolerances.

[0051] The embodiments of the present disclosure and the features in the embodiments can be combined with each other in the case of no conflict.

[0052] The terms used in the present disclosure are only used to describe specific embodiments, and are not intended to limit the present disclosure. As used in the present disclosure, the term "and / or" includes any and all combinations of one or more of the associated listed items. As used in the present disclosure, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises," "comprising," "includes," "including," "contains," "containing," "has," "having," or the like are intended to be inclusive, and specify the presence of stated features, integers, steps, operations, elements, components, or the like, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof.

[0053] Unless otherwise defined, all terms used in the present disclosure, including technical and scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and the present disclosure, and will not be interpreted in an idealized or overly formal sense unless expressly so defined in the present disclosure.

[0054] The present disclosure is not limited to the embodiments shown in the drawings, but includes modifications of configurations formed based on manufacturing processes. Therefore, the regions exemplified in the drawings have a schematic property, and the shape of the regions shown in the drawings exemplifies a specific shape of a region of an element, but is not intended to be restrictive.

[0055] In order to facilitate understanding of the technical solutions of the present disclosure, some technical contents related to the present disclosure are briefly described below.

[0056] Fiber-To-The-Room (FTTR) technology

[0057] The FTTR technology is to connect wireless routers access points (APs) in different rooms or positions in a home or a small and medium-sized enterprise through an optical fiber, thereby providing high bandwidth and high reliability of connection between multi-AP networking, and the connection between master and slave APs can be realized by using a point-to-multipoint optical distribution network.

[0058] TXOP preemption technology

[0059] The TXOP preemption technique is mainly used for low latency guarantee of unpredictable low latency (LL) traffic. Orthogonal sequences (OS) can be used as preemption requests (PR) for TXOP preemption in the frame interval.

[0060] Orthogonal sequences

[0061] OS are mainly used for code sequences in spread spectrum communication systems and in code division multiple access (CDMA) systems. These sequences have good cross-correlation properties, which are crucial for improving the anti-interference performance of the system. For example, in spread spectrum communication, the correlation value of OS determines the anti-interference performance of the system; in CDMA systems, the construction of OS sets is crucial for implementing regular cellular system communication. In addition, OS are also applied to eliminate interference in orthogonal frequency division multiplexing (OFDM) systems to improve system performance. These applications demonstrate the important role of orthogonal sequences in improving the performance and reliability of communication systems.

[0062] Currently, in a wireless fidelity (WiFi) system, TXOP technology can be used to guarantee the low latency of traffic. It has been proposed that OS can be used as PR for TXOP preemption in the frame interval to reduce latency to some extent. However, the management method for using OS as PR for TXOP preemption in the current WiFi standard has not been specified.

[0063] The embodiments of the present disclosure propose a data transmission method for managing the use of OS in a WiFi environment.

[0064] Figure 1 is a flowchart of the data transmission method according to the embodiments of the present disclosure.

[0065] As shown in the figure, the data transmission method according to the embodiments of the present disclosure includes the following steps S110-S130.

[0066] In step S110, the first node sends a first request frame to the second node, wherein the first request frame includes OS capability information of the first node.

[0067] In step S120, the first node receives a first response frame sent by the second node, wherein the first response frame includes first orthogonal sequence number OS ID information.

[0068] At step S130, the first node generates the first OS according to the first OS ID information.

[0069] According to an embodiment of the present disclosure, the first node advertises the OS capability information of the first node to the second node, so that the second node knows the OS capability of the first node. When the OS capability of the first node indicates that the first node supports generating an OS, the second node can allocate an OS ID for the first node, and carries the OS ID information (i.e., the first OS ID information) in the first response frame fed back to the first node. On the other hand, when the OS capability of the first node indicates that the first node does not support generating an OS, the second node does not allocate an OS ID for the first node. For example, the first OS ID information in the first response frame fed back by the second node to the first node can be empty.

[0070] In the case where the first node supports generating an OS, after receiving the first response frame fed back by the second node, the first node can extract the OS ID allocated by the second node for the first node from the first response frame, and generate the first OS according to the extracted OS ID.

[0071] According to an embodiment of the present disclosure, the first request frame can be one of an association request frame, a reassociation request frame, an authentication frame, or other types of management frames.

[0072] According to an embodiment of the present disclosure, the first response frame can be one of an association response frame, a reassociation response frame, an authentication frame, or other types of management frames.

[0073] According to an embodiment of the present disclosure, the OS can be a Zadoff-Chu sequence (ZCS).

[0074] The ZCS is a discrete sequence with good properties, and is a complex sequence, which is widely used in communication systems. It was proposed by Zadoff and Chu in 1964, and is a special linear frequency modulation pulse compression sequence. The ZCS is often used for synchronization and channel estimation in communication systems.

[0075] The autocorrelation of a ZCS refers to a result of a correlation operation of the sequence on itself. The autocorrelation can reflect periodicity and repetition of the sequence, and is very important for synchronization and channel estimation. The cross-correlation of a ZCS refers to a result of a correlation operation of the sequence on other sequences. The cross-correlation can reflect similarity between sequences, and plays an important role in channel estimation and multi-user detection, and the like. ZCSs are commonly used in various wireless communication systems, and are widely applied in the fields of signal processing and communication to improve system performance and reliability.

[0076] The expression of a ZCS is as follows:

[0077]

[0078] wherein, N ZC is a root sequence length, which defines a number of discrete points in the sequence, q is a root index of the sequence, n represents an index value of a certain discrete point in the sequence, and 0≤n≤N ZC -1.

[0079] Due to the zero cyclic autocorrelation of an orthogonal sequence, the cyclic autocorrelation of a ZCS is optimal. For all non-zero shift sequences, the autocorrelation with the original sequence is equal to 0. Therefore, after N ZC and q are known, the root sequence corresponding to q can be calculated. The root sequence is cyclically shifted by k (0≤k≤N ZC -1), and the root sequence (i.e., a sequence calculated by using the root sequence length N ZC and the root index q) generates a sub-sequence after being shifted by k bits to the left.

[0080] According to embodiments of the present disclosure, the OS ID can include a root index, a length of the sequence, and a root sequence cyclic shift number. The second node can assign the same root index (i.e., q) and sequence length (i.e., N ZC ) to each first node connected thereto, and assign different root sequence cyclic shift numbers (i.e., k) to different first nodes. When N ZC and q are fixed, each first node can obtain the same root sequence according to the same N ZC and q, for example, the root sequence is Q ZC =[a1,a2,a3...a N ], thereby guaranteeing the zero cyclic autocorrelation of the orthogonal sequence. In addition, since the second node assigns different root sequence cyclic shift numbers (i.e., k) to each first node, each first node can obtain a respective sub-sequence (i.e., a first OS) from the root sequence according to the respective root sequence cyclic shift number k. For example, for the root sequence Q ZC =[a1,a2,a3...a N] and k = 0, a sub-sequence Q0= [a1, a2, a3...a N ] can be obtained, that is, the same as the primitive root sequence, and k = 1, a sub-sequence Q1= [a2, a3, a4...a N ,a1] can be obtained, and k = 2, a sub-sequence Q2= [a3, a4, a5...a N ,a1, a2]…, and so on. Therefore, when the first node uses its first OS as the PR to preempt the TXOP, the second node can identify which first node sends the PR after receiving the sub-sequence sent by the first node.

[0081] Those skilled in the art should appreciate that, although in the above example, the example of ZCS as the OS is described, the present disclosure is not limited thereto, for example, the OS can also be a Golomb polynomial sequence.

[0082] The expression of the Golomb sequence is as follows:

[0083] Given a positive integer N, let Then the term a n of the Golomb polynomial sequence is calculated according to the following formula:

[0084] 1≤n≤N

[0085] Wherein, N is the length of the sequence, which defines the number of discrete points in the sequence, r is a positive integer, which is the root index of the sequence, n represents the index value of a discrete point in the sequence, and the greatest common divisor of r and N is 1, that is, gcd(r, N) = 1.

[0086] When N and r are fixed values, the generated root sequence is Q Glomb = [a1, a2, a3...a N ]. After the second node informs the first node of N, r and the cyclic shift number k, the first node can generate a unique sub-sequence representing itself. After N and r are known, the root sequence corresponding to r can be calculated. The cyclic shift number of the root sequence is k (0≤k≤N-1), and the root sequence generates a sub-sequence after being shifted to the left by k positions, for example, Q1= [a2, a3, a4...a N ,a1] (k = 1).

[0087] According to the embodiments of the present disclosure, the OS ID can include a root sequence number, a length of a sequence, and a root sequence cyclic shift number. The second node can assign the same root sequence number (i.e., r) and sequence length (i.e., N) to each first node connected thereto, and assign different root sequence cyclic shift numbers (i.e., k) to different first nodes. When the values of N and r are fixed, each first node can obtain the same root sequence according to the same N and r, for example, the root sequence is Q Glomb = [a1, a2, a3...a N ], thereby guaranteeing the zero cyclic autocorrelation of the orthogonal sequence. In addition, since the second node assigns different root sequence cyclic shift numbers (i.e., k) to each first node, each first node can obtain a respective subsequence (i.e., first OS) from the root sequence according to the respective root sequence cyclic shift number k. For example, for the root sequence Q Glomb = [a1, a2, a3...a N ], when k = 0, the subsequence Q0= [a1, a2, a3...a N ] can be obtained, which is the same as the original root sequence, when k = 1, the subsequence Q1= [a2, a3, a4...a N ,a1] can be obtained, when k = 2, the subsequence Q2= [a3, a4, a5...a N ,a1,a2]…… can be obtained, and so on. Therefore, when the first node uses its first OS as a PR to perform TXOP preemption, the second node can identify which first node sent the PR after receiving the subsequence sent by the first node.

[0088] Figure 2 is another flowchart of a data transmission method according to the embodiments of the present disclosure.

[0089] In some embodiments, as shown in Figure 2 , before the first node sends a first request frame to the second node (i.e., step S110), the method further includes step S100.

[0090] In step S100, the first node receives a first information frame sent by the second node, wherein the first information frame includes OS capability information of the second node.

[0091] According to the embodiments of the present disclosure, before the first node advertises the OS capability information of the first node to the second node, the first node first receives a first information frame sent by the second node, and the first information frame includes the OS capability information of the second node, so that the first node knows the OS capability of the second node.

[0092] When the OS capability of the second node indicates that the second node supports generating an OS, the first node can notify the second node of the OS capability information of the first node, so that the second node knows the OS capability of the first node. When the OS capability of the second node indicates that the second node supports generating an OS, the first node can know the OS capability of the first node, and notify the second node of the OS capability of the first node. The first node and the second node can notify each other of the OS capability information, can be well compatible with devices that do not support generating an OS, and when the first node and the second node both support generating an OS, can execute the technical solutions of the present disclosure.

[0093] According to an embodiment of the present disclosure, the first information frame can be a Beacon frame or a Probe Response frame, but the present disclosure is not limited thereto, and the first information frame can also be other types of management frames.

[0094] Figure 3 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0095] In some embodiments, as shown in Figure 3 The data transmission method according to an embodiment of the present disclosure can further include steps S140-S160.

[0096] In step S140, the first node sends a second request frame to the second node, wherein the second request frame includes OS enabling information of the first node.

[0097] In step S150, the first node receives a second response frame sent by the second node, wherein the second response frame includes updated OS ID information.

[0098] In step S160, the first node generates a second OS according to the updated OS ID information.

[0099] According to an embodiment of the present disclosure, after the first node generates the first OS, the OS enabling state of the first node can change. When the OS enabling state of the first node changes, the first node can re-negotiate with the second node, so that the second node knows the updated OS enabling state of the first node. When the OS enabling state of the first node changes from disabled to enabled, the second node can allocate an updated OS ID to the first node, and carry the updated OS ID information in the second response frame fed back to the first node. On the other hand, when the OS enabling state of the first node changes from enabled to disabled, that is, the first node does not support generating an OS due to some reasons, the second node can recover the OS ID previously allocated to the first node.

[0100] In a case that the OS enable state of the first node changes from disabled to enabled, after the first node receives the second response frame fed back by the second node, the first node can extract the updated OS ID allocated to the first node by the second node from the second response frame, and generate a second OS according to the extracted updated OS ID.

[0101] According to the embodiment disclosed, when the first node sends the first request frame to the second node, the OS enable state of the first node can be enabled by default.

[0102] By informing the second node of the OS enable state of the first node, the second node can be aware of the change of the OS enable state of the first node, and allocate an updated OS ID to the first node according to the OS enable state of the first node, or recycle the OS ID previously allocated to the first node, so as to realize dynamic management of the OS ID.

[0103] Figure 4 is another flowchart of the data transmission method according to the embodiment of the disclosure.

[0104] In some embodiments, as shown in Figure 4 the data transmission method according to the embodiment of the disclosure can further include steps S170-S180.

[0105] In step S170, the first node periodically receives a second information frame sent by the second node, wherein the second information frame includes updated OS ID information.

[0106] In step S180, the first node generates a third OS according to the updated OS ID information.

[0107] According to the embodiment of the disclosure, the second information frame can be an update message or other types of management frames.

[0108] According to the embodiment disclosed, after the first node generates the first OS, the OS of the first node can be updated periodically. Since the OS belongs to the signal of the physical layer and cannot be encrypted, the first node can obtain the updated OS ID by periodically receiving the second information frame from the second node, and then update the OS of the first node, so as to improve the security. After the second node allocates a new OS ID to the first node, the second node can recycle the OS ID previously allocated to the first node, so as to realize dynamic management of the OS ID.

[0109] Figure 5 is another flowchart of the data transmission method according to the embodiment of the disclosure.

[0110] In some embodiments, as shown in Figure 5As shown, the data transmission method according to the embodiment of the present disclosure can further include steps S210 to S230.

[0111] In step S210, the first node sends a third request frame to the second node, wherein the third request frame includes the OS capability information of the first node and the request reason information.

[0112] In step S220, the first node receives a third response frame sent by the second node, wherein the third response frame includes updated OS ID information.

[0113] In step S230, the first node generates a fourth OS according to the updated OS ID information.

[0114] According to the embodiment disclosed herein, after the first node generates the first OS, the first node can request the second node to re-allocate the OS ID information. The first node can send the request information to the second node, so that the second node knows the OS capability of the first node and the reason for requesting the re-allocation of the OD ID, for example, the reason can be information loss or other reasons.

[0115] After the first node receives the third response frame fed back by the second node, the first node can extract the updated OS ID allocated by the second node for the first node from the third response frame, and generate a fourth OS according to the extracted updated OS ID. After the second node allocates a new OS ID for the first node, according to actual conditions, the second node can recycle the OS ID previously allocated to the first node, so as to realize dynamic management of the OS ID.

[0116] According to the embodiment disclosed herein, the second node can also determine whether to send the updated OS ID information to the first node according to the reason for requesting the update of the OS ID information contained in the third request frame.

[0117] By re-requesting the updated OS ID information from the second node, the first node can make the second node know the reason for the loss of the OS ID information of the first node, and re-allocate the updated OS ID information to the first node when the first node has the OS capability, and recycle the OS ID previously allocated to the first node, so as to realize dynamic management of the OS ID. By actively requesting the update of the OS ID information, the first node can restore the OS, so as to ensure that the first node can use the OS as the PR to perform TXOP preemption.

[0118] In some embodiments, the first node and the second node are multi-link devices (MLD), the first node includes a plurality of first sub-nodes, the second node includes a plurality of second sub-nodes, and a plurality of links are established between the plurality of first sub-nodes and the plurality of second sub-nodes.

[0119] MLD represents a device supporting a multi-link operation (MLO) technology, and as a terminal device (STA), the MLD can be simultaneously associated on each frequency band of the MLD as an access device (AP), which can greatly improve the throughput and stability.

[0120] As shown in Figure 6 The first node can include a plurality of first sub-nodes, for example, the first node can include a first sub-node 1, a first sub-node 2 and a first sub-node 3, and the second node can include a plurality of second sub-nodes, for example, the second node can include a second sub-node 1, a second sub-node 2 and a second sub-node 3. A plurality of links are established between the first sub-node 1, the first sub-node 2 and the first sub-node 3 and the second sub-node 1, the second sub-node 2 and the second sub-node 3. It should be recognized that Figure 6 The connection mode shown is only an example, and the number of sub-nodes and the connection relationship between the sub-nodes are not limited to the number and connection relationship shown in the figure.

[0121] Figure 7 Another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0122] In some embodiments, as shown in Figure 7 In the case where the first node and the second node are MLDs, the first node sending a first request frame to the second node (i.e., step S110) can include step S110'.

[0123] In step S110', the first node sends the first request frame to the second node via any one of the links.

[0124] Correspondingly, the first node receiving the first response frame sent by the second node (i.e., step S120) can include step S120'.

[0125] In step S120', the first node receives the first response frame sent by the second node via the link on which the first request frame is sent.

[0126] According to an embodiment of the present disclosure, when the first node and the second node are both MLDs, a plurality of links can be established between the first node and the second node. The first node can send its own OS capability information to the second node via any one of the plurality of links, and receive the first response frame sent by the second node via the link.

[0127] According to an embodiment of the present disclosure, in the case where the first node and the second node are MLDs, the OS capability information notified by the first node to the second node can include the OS capability information of the first node itself, and the first OS ID information sent by the second node to the first node can include the device-level OS ID information of the first node.

[0128] When the OS capability information of the first node itself indicates that the first node supports generating an OS, it can mean that each first child node of the first node supports generating an OS. The device-level OS ID information of the first node can mean the OS ID information common to each first child node of the first node. In this case, as shown in Figure 8 Generating the first OS by the first node according to the first OS ID information (i.e., step S130) includes step S131.

[0129] In step S131, each first child node of the first node generates a first OS according to the device-level OS ID information.

[0130] According to another embodiment of the present disclosure, in the case where the first node and the second node are MLDs, the OS capability information notified by the first node to the second node can include the OS capability information of the plurality of first nodes, and the first OS ID information sent by the second node to the first node can include the link-level OS ID information of the plurality of first child nodes.

[0131] The OS capability information sent by the first node to the second node can include the OS capability information of each first child node. The link-level OS ID information of each first child node can mean the OS ID information dedicated to each first child node. In this case, as shown in Figure 9 Generating the first OS by the first node according to the first OS ID information (i.e., step S130) includes step S132.

[0132] In step S132, the plurality of first child nodes of the first node generate a plurality of first OSs according to the link-level OS ID information.

[0133] According to an embodiment of the present disclosure, before the first node advertises the OS capability information to the second node, the first node can first receive a first information frame sent by the second node via a plurality of links, and the first information frame contains the OS capability information of the second node, so that the first node knows the OS capability of the second node.

[0134] Figure 10 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0135] In some embodiments, as Figure 10As shown, before the first node sends the first request frame to the second node via any one of the links (i.e., step S110'), the method further includes step S100'.

[0136] At step S100', the plurality of first sub-nodes receive, via the plurality of links, the first information frames sent by the plurality of second sub-nodes, wherein the first information frames include the OS capability information of the second node.

[0137] When the OS capability of the second node indicates that the second node supports generating an OS, the first node sends the first request frame to the second node via any one of the links, so that the second node is aware of the OS capability of the first node (e.g., the OS capability of the first node itself or the OS capability of each first sub-node). When the OS capability of the first node indicates that the first node supports generating an OS or indicates that each first sub-node supports generating an OS, the second node can allocate a device-level OS ID or a link-level OS ID for the first node, and carry device-level OS ID information or link-level OS ID information (i.e., first OS ID information) in the first response frame fed back to the first node. On the other hand, when the OS capability of the first node indicates that the first node does not support generating an OS or a certain first sub-node does not support generating an OS, the second node does not allocate a device-level OS ID for the first node or a link-level OS ID for the first sub-node.

[0138] According to the embodiments of the present disclosure, in the case that the first node and the second node are MLDs, the OS ID can be allocated at the device level or the link level to achieve dynamic management of the OS ID.

[0139] Figure 11 is a schematic diagram in a roaming application scenario according to an embodiment of the present disclosure.

[0140] In some embodiments, after the first node and the second node establish a link connection, the first node can initiate roaming to the third node. As shown in Figure 11 As shown, after the first node and the second node establish a link, the first node can initiate roaming to the third node to achieve connection of the first node and the third node.

[0141] In the conventional 802.11KV-based roaming scheme, when the STA roams between different APs, it needs to re-perform 802.11 protocol frame interaction, key exchange and context establishment, and at the same time needs to perform data path switching operation. This process inevitably causes temporary interruption of service, seriously affecting user experience.

[0142] To solve the above problems, the 802.11R fast transition (FT) technology is proposed. The technology uses a fast transition mechanism to effectively shorten the connection time between the STA and different APs while realizing fast roaming. Specifically, the FT protocol provides two methods for performing handover: Over-the-Air and Over-the-DS. In the Over-the-Air mode, the STA directly communicates with the target AP over the air and completes the authentication process using the FT authentication algorithm; in the Over-the-DS mode, the STA can establish a connection with the target AP for roaming with the help of the current AP.

[0143] On the other hand, even if the 802.11R FT technology is used, the cumbersome interaction process during roaming cannot be completely avoided, including the Authentication-Reassociation protocol interaction. The scheme for seamless roaming (Seamless Roaming) using an ultra-high reliability (UHR) AP MLD proposed in 802.11bn is expected to further simplify the roaming process and provide a smoother experience for users.

[0144] For the various roaming modes described above, the embodiments of the present disclosure propose various schemes for managing the OS ID.

[0145] Figure 12 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0146] In some embodiments, as shown in Figure 12 In the roaming scenario, after the first node generates the first OS according to the OS ID information allocated by the second node (i.e., after completing the steps S110-S130 shown in the figure), the method can further include steps S240-S270. Figure 1

[0147] In step S240, the first node sends a fourth request frame to the third node, where the fourth request frame includes the OS capability information of the first node and the first OS ID information.

[0148] In step S250, the first node receives a fourth response frame sent by the third node, where the fourth response frame includes OS configuration information, and the OS configuration information includes a status code and second OS ID information, and the status code is used to indicate whether the first OS ID information is the same as the OS ID information allocated by the third node.

[0149] ​At step S260, in response to the status code indicating that the first OS ID information is different from the OS ID information allocated by the third node, the first node retains the first OS.

[0150] At step S270, in response to the status code indicating that the first OS ID information is the same as the OS ID information allocated by the third node, the first node generates a fourth OS according to the second OS ID information.

[0151] According to the disclosure of the present embodiment, after the first node establishes a connection with the second node, the first node can roam to the third node. Before the first node roams to the third node in an Over-the-air manner or after the first node roams to the third node in a seamless roaming manner, the first node can request the third node to configure an OS ID for the first node.

[0152] The first node can send the request information to the third node, so that the third node is aware of the OS capability information of the first node and the first OS ID information allocated to the first node by the second node. If the first OS ID information is the same as the OS ID information already allocated by the third node, it indicates that the third node has allocated the same OS ID information to another device, that is, after the first node connects to the third node, the first node and the device connected to the third node have the same OS, and thus a conflict occurs. In order to avoid the conflict, the third node needs to configure another OS ID for the first node, that is, allocate new OS ID information to the first node. In the OS configuration information sent by the third node to the first node, the status code can indicate that the first OS ID information is the same as the OS ID information already allocated by the third node, and the OS configuration information also carries the second OS ID information allocated by the third node to the first node, and the second OS ID information is different from the first OS ID information. The first node can generate a fourth OS according to the second OS ID information. If the first OS ID information is different from the OS ID information already allocated by the third node, it indicates that the third node has not allocated the same OS ID information to another device, that is, after the first node connects to the third node, the OS generated by the first node according to the first OS ID information allocated by the second node will not be the same as the OS of the device connected to the third node, and thus no conflict occurs. The third node does not need to allocate new OS ID information to the first node, but can locally associate the first OS ID information with the first node, and take the first OS ID information as the OS ID information already allocated by the third node. In the OS configuration information sent by the third node to the first node, the status code can indicate that the first OS ID information is different from the OS ID information already allocated by the third node, and the first node can continue to retain the first OS.

[0153] According to the embodiments of the present disclosure, after the first node successfully roams to the third node, the second node can reclaim the OS ID allocated to the first node.

[0154] Figure 13 is another flowchart of a data transmission method according to the embodiments of the present disclosure.

[0155] In some embodiments, as shown in Figure 13 In the roaming scenario, after the first node generates the first OS according to the OS ID information allocated by the second node (i.e., after completing the steps S110-S130 shown in Figure 1 , the first node sends a fourth request frame to the third node (i.e., step S240) can include step S240'.

[0156] In step S240', the first node sends the fourth request frame to the third node via the second node.

[0157] Correspondingly, the first node receives the fourth response frame sent by the third node (i.e., step S250) can include step S250'.

[0158] In step S250', the first node receives the fourth response frame sent by the third node via the second node.

[0159] According to the embodiments of the present disclosure, in the process of roaming from the second node to the third node by the first node, the second node can be used as an intermediate node to realize the forwarding of the interaction information between the first node and the third node in an Over-the-DS manner, so as to ensure that the communication step is performed only when the first node and the third node have connection capability, thereby reducing the complexity of the data transmission method.

[0160] In some embodiments, the first node, the second node and the third node are MLDs, the first node includes a plurality of first sub-nodes, the second node includes a plurality of second sub-nodes, the third node includes a plurality of third sub-nodes, and a plurality of links are established between the plurality of first sub-nodes and the plurality of second sub-nodes. The first node can initiate roaming to the third node to realize the connection of the first node and the third node.

[0161] As shown in Figure 14 , the first node can include a plurality of first sub-nodes, for example, the first node can include first sub-node 1, first sub-node 2 and first sub-node 3, the second node can include a plurality of second sub-nodes, and the third node can include a plurality of third sub-nodes, for example, the second node can include second sub-node 1, second sub-node 2 and second sub-node 3, and for another example, the third node can include third sub-node 1, third sub-node 2 and third sub-node 3. It should be recognized that Figure 14The connection manners shown are merely examples, and the number of child nodes and the connection relationship between the child nodes are not limited to the number and connection relationship shown.

[0162] It should be appreciated that the various embodiments of the MLD in the roaming application scenario can be obtained by combining the various embodiments of the MLD application scenario described above with reference to Figures 6 to 9 the various embodiments of the MLD application scenario described above with reference to Figures 11 to 13 the various embodiments of the roaming application scenario described above.

[0163] Figure 15 is another flowchart of the data transmission method according to an embodiment of the present disclosure.

[0164] In some embodiments, as Figure 15 shown, after each first child node of the first node generates a first OS according to the device-level OS ID information allocated by the second node (i.e., after the steps shown are completed) Figure 8 shown, the data transmission method according to an embodiment of the present disclosure can further include Figure 12 steps S240 to S270 shown.

[0165] Specifically, when the first node, the second node, and the third node are all MLDs, the first node sending a fourth request frame to the third node (i.e., step S240) can include step S241.

[0166] In step S241, the first node sends the fourth request frame to the third node through the air interface before completing roaming or through a newly established link after completing roaming.

[0167] Correspondingly, the first node receiving the fourth response frame sent by the third node (i.e., step S250) can include step S251.

[0168] In step S251, the first node receives the fourth response frame sent by the third node via the channel through which the fourth request frame is sent.

[0169] Figure 16 is another flowchart of the data transmission method according to an embodiment of the present disclosure.

[0170] In some embodiments, as Figure 16 shown, after each first child node of the first node generates a first OS according to the device-level OS ID information allocated by the second node (i.e., after the steps shown are completed) Figure 9 shown, the data transmission method according to an embodiment of the present disclosure can further include Figure 12 steps S240 to S270 shown.

[0171] Specifically, when the first node, the second node, and the third node are all MLDs, the first node sending a fourth request frame to the third node (i.e., step S240) may include step S241.

[0172] In step S241, the first node sends a fourth request frame to the third node via the air interface before completing roaming or via the newly established link after completing roaming.

[0173] Accordingly, the first node receiving the fourth response frame sent by the third node (i.e., step S250) may include step S251.

[0174] In step S251, the first node receives the fourth response frame sent by the third node via the channel for sending the fourth request frame.

[0175] Figure 17 This is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0176] In some embodiments, such as Figure 17 As shown, after each of the first child nodes of the first node generates the first OS based on the device-level OS ID information allocated by the second node (i.e., the process is complete), Figure 8 Following the steps shown, the data transmission method according to embodiments of this disclosure may further include... Figure 13 Steps S240' to S270 are shown.

[0177] Specifically, when the first node, the second node, and the third node are all MLDs, the first node sending a fourth request frame to the third node via the second node (i.e., step S240') may include step S241'.

[0178] In step S241', the first node sends a fourth request frame to the third node via any link through the second node.

[0179] Accordingly, the first node receiving the fourth response frame sent by the third node via the second node (i.e., step S250') may include step S251'.

[0180] In step S251', the first node receives the fourth response frame sent by the third node and forwarded by the second node via the link that sent the fourth request frame.

[0181] Figure 18 This is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0182] In some embodiments, such as Figure 18 As shown, after the first node's multiple first child nodes generate multiple first OSs based on the link-level OS ID information allocated by the second node (i.e., the process is completed), the process is complete. Figure 9After the steps shown), the data transmission method according to the embodiments of the present disclosure can further include Figure 13 The steps S240' to S270 shown.

[0183] Specifically, when the first node, the second node and the third node are all MLDs, the first node sending a fourth request frame to the third node via the second node (i.e., step S240') can include step S241'.

[0184] In step S241', the first node sends the fourth request frame to the third node via the second node through any one of the links.

[0185] Correspondingly, the first node receiving the fourth response frame sent by the third node via the second node (i.e., step S250') can include step S251'.

[0186] In step S251', the first node receives the fourth response frame sent by the third node and forwarded by the second node via the link on which the fourth request frame is sent.

[0187] According to the embodiments of the present disclosure, in the case where the first node, the second node and the third node are all MLDs, the OS ID can be allocated at the device level or the link level to achieve dynamic management of the OS ID and realize roaming of the MLD.

[0188] The above, in combination with Figures 1 to 18 Various embodiments of the data transmission method according to the present disclosure are described. It should be recognized that the first node in each of the above embodiments can be a terminal device (STA), and the second node and the third node can be an access device (AP), and each of the described data transmission method embodiments can be applied to a terminal device. In the following, various embodiments of the data transmission method applied to an access device (i.e., the second node) will be described. For brevity, repetitive descriptions will be omitted.

[0189] Figure 19 is a flowchart of the data transmission method according to the embodiments of the present disclosure.

[0190] As shown in the figure, the data transmission method according to the embodiments of the present disclosure includes the following steps S310 to S320.

[0191] In step S310, the second node receives a first request frame sent by the first node, wherein the first request frame includes OS capability information of the first node.

[0192] In step S320, the second node sends a first response frame to the first node, wherein the first response frame includes first OS ID information.

[0193] According to an embodiment of the present disclosure, the first node notifies the second node of the OS capability information of the first node, so that the second node knows the OS capability of the first node. When the OS capability of the first node indicates that the first node supports generating an OS, the second node can allocate an OS ID for the first node, and carries the OS ID information (i.e., first OS ID information) in the first response frame fed back to the first node. On the other hand, when the OS capability of the first node indicates that the first node does not support generating an OS, the second node does not allocate an OS ID for the first node. For example, the first OS ID information in the first response frame fed back by the second node to the first node can be empty.

[0194] In the above manner, the management of the OS ID can be implemented by the second node. The second node can associate the first OS ID information with the first node locally after or at the same time when allocating the OS ID for the first node, so that it can be known clearly which OS IDs have been allocated. On the other hand, when the second node receives the OS sent by the first node as PR, it can be known which node is performing TXOP preemption by correlation operation with the root sequence.

[0195] According to an embodiment of the present disclosure, the first request frame can be one of an association request frame, a reassociation request frame, an authentication frame, or other types of management frames.

[0196] According to an embodiment of the present disclosure, the first response frame can be one of an association response frame, a reassociation response frame, an authentication frame, or other types of management frames.

[0197] According to an embodiment of the present disclosure, the OS can be a ZCS or a Golomb polynomial sequence.

[0198] According to an embodiment of the present disclosure, the OS ID can include a root sequence number, a length of the sequence, and a root sequence cyclic shift number.

[0199] Figure 20 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0200] In some embodiments, as shown in Figure 20 Before the second node receives the first request frame sent by the first node (i.e., step S310), the method further includes step S300.

[0201] At step S300, the second node sends a first information frame to the first node, wherein the first information frame comprises the OS capability information of the second node.

[0202] According to embodiments of the present disclosure, the first information frame can be a Beacon frame or a Probe Response frame, but the present disclosure is not limited thereto, and the first information frame can also be other types of management frames.

[0203] Figure 21 is another flowchart of the data transmission method according to embodiments of the present disclosure.

[0204] In some embodiments, as shown in Figure 21 The data transmission method according to embodiments of the present disclosure can further comprise step S330.

[0205] At step S330, in response to detecting that the first node loses association, the second node recovers the first OS ID information.

[0206] The first node can lose association with the second node for a variety of reasons, for example, the first node roams to other nodes, or the first node suddenly drops offline. Regardless of the reason, when the second node detects that the first node loses association, the second node recovers the OS ID previously allocated to the first node, to achieve dynamic management of the OS ID.

[0207] Figure 22 is another flowchart of the data transmission method according to embodiments of the present disclosure.

[0208] In some embodiments, as shown in Figure 22 The data transmission method according to embodiments of the present disclosure can further comprise steps S340 to S350.

[0209] At step S340, the second node periodically sends a second information frame to the first node, wherein the second information frame comprises updated OS ID information.

[0210] At step S350, the second node recovers the first OS ID information.

[0211] According to embodiments of the present disclosure, the second information frame can be an update message or other types of management frames.

[0212] As mentioned above, the OS belongs to the signal of the physical layer and cannot be encrypted. To improve security, the first node can be caused to update its own OS by periodically sending an updated OS ID to the first node. After the second node allocates a new OS ID to the first node, the second node can recycle the OS ID previously allocated to the first node, so as to realize dynamic management of the OS ID.

[0213] Figure 23 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0214] In some embodiments, as shown in Figure 23 the data transmission method according to an embodiment of the present disclosure can further include steps S360 to S380.

[0215] In step S360, the second node receives a second request frame sent by the first node, wherein the second request frame includes OS enablement information of the first node.

[0216] In step S370, in response to the OS enablement information of the first node indicating that the first node is in an OS enabled state, the second node sends a second response frame to the first node, wherein the second response frame includes updated OS ID information.

[0217] In step S380, in response to the OS enablement information of the first node indicating that the first node is in an OS disabled state, the second node recycles the first OS ID information.

[0218] According to an embodiment of the present disclosure, after the first node generates the first OS, the state of whether the OS of the first node is enabled can change. When the enabled state of the OS of the first node changes, the first node can re-negotiate with the second node to enable the second node to know the updated OS enabled state of the first node. When the enabled state of the OS of the first node changes from disabled to enabled, the second node can allocate an updated OS ID to the first node, and carry the updated OS ID information in the second response frame fed back to the first node; on the other hand, when the enabled state of the OS of the first node changes from enabled to disabled, i.e., the first node does not support generating an OS due to some reasons, the second node can recycle the OS ID previously allocated to the first node.

[0219] According to the embodiment disclosed in the present embodiment, when the first node sends the first request frame to the second node, the enabled state of the OS of the first node can be enabled by default.

[0220] By informing the second node of the enabling state of the OS of the first node, the second node can know the change of the enabling state of the OS of the first node, and allocate an updated OS ID to the first node according to the enabling state of the OS of the first node, or recycle the OS ID previously allocated to the first node, so as to realize dynamic management of the OS ID.

[0221] Figure 24 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0222] In some embodiments, as shown in Figure 24 The data transmission method according to an embodiment of the present disclosure can further include steps S390-S400.

[0223] In step S390, the second node receives a third request frame sent by the first node, wherein the third request frame includes OS capability information of the first node and request reason information.

[0224] In step S400, the second node sends a third response frame to the first node, wherein the third response frame includes updated OS ID information.

[0225] According to the present embodiment, after the first node generates the first OS, the first node can request the second node to re-allocate the OS ID information. The first node can send request information to the second node, so that the second node knows the OS capability of the first node and the reason for requesting re-allocation of the OD ID, for example, the reason can be information loss, or other reasons.

[0226] After the second node allocates a new OS ID to the first node, according to actual conditions, the second node can recycle the OS ID previously allocated to the first node, so as to realize dynamic management of the OS ID. For example, if the second node locally retains OS ID information associated with the node indicates that the OS ID has been previously allocated to the first node, the second node can recycle the OS ID previously allocated to the first node. For another example, if the second node has recycled the OS ID allocated to the first node due to loss of association with the first node, there is no need to perform the operation of recycling the OS ID again.

[0227] According to the present embodiment, the second node can also determine whether to send the updated OS ID information to the first node according to the reason for requesting the updated OS ID information contained in the third request frame.

[0228] By re-requesting the updated OS ID information from the second node to the first node, the second node can know the reason why the OS ID information of the first node is lost, and re-allocate the updated OS ID information to the first node when the first node has the OS capability, and recover the previously allocated OS ID to the first node, so as to realize the dynamic management of the OS ID. By actively requesting the updated OS ID information, the first node can recover the OS, so as to ensure that the first node can use the OS as the PR to perform TXOP preemption.

[0229] In some embodiments, the first node and the second node are MLDs, the first node includes a plurality of first sub-nodes, the second node includes a plurality of second sub-nodes, and a plurality of links are established between the plurality of first sub-nodes and the plurality of second sub-nodes.

[0230] Figure 25 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0231] In some embodiments, as shown in Figure 25 , when the first node and the second node are MLDs (see Figure 6 ), the second node receiving the first request frame sent by the first node (i.e., step S310) can include step S310'.

[0232] In step S310', the second node receives the first request frame sent by the first node on one of the plurality of links.

[0233] Correspondingly, the second node sending the first response frame to the first node (i.e., step S320) can include step S320'.

[0234] In step S320', the second node sends the first response frame via the link on which the first request frame is received.

[0235] According to an embodiment of the present disclosure, the OS capability information can include the OS capability information of the first node itself, and the first OS ID information can include the device-level OS ID information of the first node.

[0236] According to an embodiment of the present disclosure, the OS capability information can include the OS capability information of the plurality of first sub-nodes, and the first OS ID information can include the link-level OS ID information of the plurality of first sub-nodes.

[0237] Figure 26 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0238] In some embodiments, as shown in Figure 26As shown, before the second node receives the first request frame on one of the plurality of links (i.e., step S310'), the method further includes step S300'.

[0239] At step S300', the plurality of second sub-nodes sends first information frames to the plurality of first sub-nodes via the plurality of links, wherein the first information frames comprise the OS capability information of the second node.

[0240] Figure 27 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0241] In some embodiments, as Figure 27 As shown, after the second node sends the first response frame to the first node (i.e., completes steps S310-S320), steps S410-S440 can also be included. Figure 19

[0242] At step S410, the second node receives a fourth request frame sent by the first node, wherein the fourth request frame comprises the OS capability information and the first OS ID information of the first node.

[0243] At step S420, the second node forwards the fourth request frame to the third node.

[0244] At step S430, the second node receives a fourth response frame sent by the third node, wherein the fourth response frame comprises OS configuration information, and the OS configuration information comprises a status code and second OS ID information, the status code being used to indicate whether the first OS ID information is the same as the OS ID information allocated by the third node.

[0245] At step S440, the second node forwards the fourth response frame to the first node.

[0246] According to an embodiment of the present disclosure, in the process of the first node roaming from the second node to the third node, the second node can be used as an intermediate node to forward the interaction information between the first node and the third node in an Over-the-DS manner, so as to ensure that the communication step is performed only when the first node and the third node have a connection capability, thereby reducing the complexity of the data transmission method.

[0247] In some embodiments, the first node, the second node, and the third node are MLDs, the first node comprises a plurality of first sub-nodes, the second node comprises a plurality of second sub-nodes, the third node comprises a plurality of third sub-nodes, and the plurality of first sub-nodes and the plurality of second sub-nodes are connected by a plurality of links (see Figure 14 ). The first node can initiate roaming to the third node to realize the connection between the first node and the third node.

[0248] ​It should be appreciated that various embodiments of the MLD in the roaming application scenario can be obtained by combining the embodiments of the MLD in the application scenarios described with reference to Figures 25 to 26 Figure 27 The embodiments of the MLD in the roaming application scenario will not be described here again.

[0249] For the purpose of understanding the technical solutions provided by the present disclosure, the following will be described in detail with reference to specific examples of application scenarios.

[0250] Figure 28 is a schematic diagram showing data transmission between a terminal device and an access device. As Figure 28 indicated, the data transmission process between the terminal device (STA) and the access device (AP) includes steps S5010 to S5120.

[0251] In step S5010, the AP announces its OS capability to the STA.

[0252] In step S5020, the STA reports its OS capability to the AP and requests an OS ID.

[0253] In step S5030, the AP allocates an OS ID1 to the STA and sends the OS ID1 to the STA, and the STA generates an OS1 according to the received OS ID1.

[0254] In step S5040, the AP periodically allocates a new OS ID2 to the STA and recovers the previously allocated OS ID1 to the STA, and the STA generates a new OS2 according to the new OS ID2.

[0255] In step S5050, the STA requests a new OS ID from the AP.

[0256] In step S5060, the AP allocates a new OS ID3 to the STA and recovers the previously allocated OS ID2 to the STA, and the STA generates a new OS3 according to the new OS ID3.

[0257] In step S5070, the STA reports to the AP that the OS capability is disabled (OS enable = 0).

[0258] In step S5080, the AP recovers the OS ID3 allocated to the STA.

[0259] In step S5090, the STA reports to the AP that the OS capability is enabled (OS enable = 1).

[0260] In step S5100, the AP allocates a new OS ID4 to the STA, and the STA generates a new OS4 according to the new OS ID4. ​

[0261] At step S5110, the AP detects that the STA loses association.

[0262] At step S5120, the AP recovers the OS ID 4 allocated to the STA.

[0263] It should be appreciated that the illustrated data transmission procedure is merely an example, and the actual order of the individual steps is not limited to the illustrated order, for example, steps S5050 and S5060 can be performed before step S5040, and in addition, the number of executions of the illustrated steps is also not limited to the illustrated number, for example, step S5040 can be executed multiple times.

[0264] Figure 29 is a schematic diagram illustrating data transmission when the terminal device and the access device are multi-link devices. As shown in Figure 29 , the non-AP MLD includes three terminal devices STA1, STA2 and STA3, and the AP MLD includes three access devices AP1, AP2 and AP3, a link is established between STA1 and AP1, a link is established between STA2 and AP2, and a link is established between STA3 and AP3. The data transmission procedure between the non-AP MLD and the AP MLD includes steps S6010 to S6050.

[0265] At steps S6010 to S6030, the AP MLD respectively advertises its OS capabilities to the non-AP MLD through the respective links.

[0266] At step S6040, the non-AP MLD reports its OS capabilities via the link between STA1 and AP1 and requests an OS ID.

[0267] At step S6050, the AP MLD allocates a device-level OS ID for the non-AP MLD and sends the device-level OS ID via the link between STA1 and AP1, and each STA of the non-AP MLD generates an OS according to the device-level OS ID.

[0268] Figure 30 is another schematic diagram illustrating data transmission when the terminal device and the access device are multi-link devices. Similar to Figure 29 , the non-AP MLD includes three terminal devices STA1, STA2 and STA3, and the AP MLD includes three access devices AP1, AP2 and AP3, a link 1 is established between STA1 and AP1, a link 2 is established between STA2 and AP2, and a link 3 is established between STA3 and AP3. The data transmission procedure between the non-AP MLD and the AP MLD includes steps S6010 to S6060.

[0269] In steps S6010 to S6030, the AP MLD advertises its OS capabilities to the non-AP MLD over each link respectively.

[0270] In step S6045, the non-AP MLD reports the OS capabilities of each STA via the link 1 between STA1 and AP1, and requests three OS IDs.

[0271] In step S6055, the AP MLD allocates a link-level OS ID for each STA of the non-AP MLD, and sends the link-level OS ID via the link 1 between STA1 and AP1.

[0272] In step S6060, STA1 extracts each link-level OS ID, and informs other links that each STA generates its own OS according to its own link-level OS ID.

[0273] Figure 31 is a schematic diagram illustrating data transmission when a terminal device roams between two access devices. As shown in Figure 31 , the terminal device (STA) is currently connected with an access device (AP1), and is about to roam to a target access device (AP2). Figure 31 The roaming process in the Over-the-Air mode is shown, including steps S7010 to S7040.

[0274] In step S7010, the STA and the AP1 perform uplink / downlink data interaction.

[0275] In step S7020, the STA decides to roam to the AP2.

[0276] In step S7030, the STA reports its OS capabilities to the AP2, and the OS ID allocated by the AP1 to the STA.

[0277] In step S7040, the AP2 returns OS configuration information to the STA, the OS configuration information including a status code, for indicating whether the OS ID reported by the STA is the same as the OS ID allocated by the AP2, when the status code indicates that the OS ID reported by the STA is not the same as the OS ID allocated by the AP2 (for example, the status code is 1), the STA retains the current OS ID and OS; when the status code indicates that the OS ID reported by the STA is the same as the OS ID allocated by the AP2 (for example, the status code is 0), the STA generates a new OS according to the OS ID carried in the OS configuration information.

[0278] Figure 32 is another schematic diagram illustrating data transmission when a terminal device roams between two access devices. As shown in Figure 32As shown, the terminal device (STA) is currently connected with the access device (AP1), and is going to roam to the target access device (AP2). Figure 32 The roaming process in the Over-the-DS mode is shown, including steps S7010 to S7042.

[0279] In step S7010, the STA and the AP1 perform uplink / downlink data interaction.

[0280] In step S7020, the STA decides to roam to the AP2.

[0281] In steps S7031 and S7032, the STA reports its OS capability to the AP2 via the AP1, and the AP1 allocates an OS ID to the STA.

[0282] In steps S7041 and S7042, the AP2 returns the OS configuration information to the STA via the AP1, the OS configuration information including a status code, for indicating whether the OS ID reported by the STA is the same as the OS ID allocated by the AP2, when the status code indicates that the OS ID reported by the STA is not the same as the OS ID allocated by the AP2 (for example, the status code is 1), the STA retains the current OS ID and the OS; when the status code indicates that the OS ID reported by the STA is the same as the OS ID allocated by the AP2 (for example, the status code is 0), the STA generates a new OS according to the OS ID carried in the OS configuration information.

[0283] Figure 33 is another schematic diagram showing data transmission of a terminal device when roaming between two access devices. As shown, Figure 33 As shown, the terminal device (STA) is currently connected with the access device (AP1), and is going to roam to the target access device (AP2). Figure 33 The roaming process in the Seamless Roaming mode is shown. In Figure 31 and Figure 32 In the example shown, the STA can obtain the OS configuration information by interacting with the AP2 (the example shown) or the AP1 (the example shown) before the roaming starts. Figure 31 In the example shown, the STA can obtain the OS configuration information by interacting with the AP2 after the roaming ends. Figure 32 Figure 33 In step S7010, the STA and the AP1 perform uplink / downlink data interaction.

[0284] In step S7025, the STA roams to the AP2.

[0285] In step S7025, the STA roams to the AP2.

[0286] ​In step S7035, the STA reports its own OS capabilities and the OS ID assigned to the STA by AP1 to AP2.

[0287] In step S7045, AP2 returns OS configuration information to STA. The OS configuration information includes a status code to indicate whether the OS ID reported by STA is the same as the OS ID assigned by AP2. When the status code indicates that the OS ID reported by STA is not the same as the OS ID assigned by AP2 (for example, status code 1), STA retains the current OS ID and OS. When the status code indicates that the OS ID reported by STA is the same as the OS ID assigned by AP2 (for example, status code 0), STA generates a new OS based on the OS ID carried in the OS configuration information.

[0288] Figure 34 This is a schematic diagram illustrating data transmission when a terminal device and two access devices are multi-link devices and the terminal device roams between the two access devices. Figure 34 The example shown can be seen as Figure 29 The example shown is of MLD performing data transmission. Figure 31 This example combines data transmission within a roaming scenario. Figure 34 The examples shown are for illustrative purposes only and are not intended to limit this disclosure. Those skilled in the art will understand that different combinations... Figure 29 and Figure 30 The example shown and Figures 31 to 33 The example shown can produce the same result as Figure 34 The examples shown are different from the examples shown. Figure 34 The data transmission process shown includes steps S8010 to S8080.

[0289] In steps S8010 to S8030, AP MLD1 advertises its OS capabilities to non-AP MLDs through each link.

[0290] In step S8040, the non-AP MLD reports its own OS capabilities and requests an OSID via the link between STA1 and AP11.

[0291] In step S8050, AP MLD1 assigns a device-level OS ID to the non-AP MLD and sends the device-level OS ID via the link between STA1 and AP11. Each STA of the non-AP MLD generates an OS based on the device-level OS ID.

[0292] In step S8060, the non-AP MLD decides to roam to AP MLD2.

[0293] At step S8070, the non-AP MLD reports its OS capability to the AP MLD2, and the AP MLD1 allocates a device-level OS ID to the non-AP MLD.

[0294] At step S8080, the AP MLD2 returns the OS configuration information to the non-AP MLD, the OS configuration information including a status code, for indicating whether the OS ID reported by the non-AP MLD is same as the OS ID allocated by the AP MLD2, when the status code indicates that the OS ID reported by the non-AP MLD is not same as the OS ID allocated by the AP MLD2 (for example, the status code is 1), each STA of the non-AP MLD retains the current OS ID and the OS; when the status code indicates that the OS ID reported by the non-AP MLD is same as the OS ID allocated by the AP MLD2 (for example, the status code is 0), each STA of the non-AP MLD generates a new OS according to the OS ID carried in the OS configuration information.

[0295] Figure 35 is a constituent block diagram of a communication device according to an embodiment of the present disclosure.

[0296] As shown in Figure 35 , the communication device according to an embodiment of the present disclosure includes a memory 102 and a processor 101. The memory 102 stores a computer program executable by the processor 101. The computer program is executed by the processor 101 to implement the data transmission method according to various embodiments of the present disclosure.

[0297] The processor 101 is a device with data processing capability, including but not limited to a central processing unit (CPU) and the like; the memory 102 is a device with data storage capability, including but not limited to a random access memory (RAM, more specifically SDRAM, DDR, etc.), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory (FLASH), and the like.

[0298] In addition, the electronic device according to the present disclosure can further include an I / O interface (read-write interface) 103 connected between the processor 101 and the memory 102, capable of realizing information interaction between the memory 102 and the processor 101, including but not limited to a data bus (Bus) and the like.

[0299] In some embodiments, the processor 101, the memory 102 and the I / O interface 103 are connected to each other through a bus 104, and further connected to other components of the computing device.

[0300] Figure 36 is a constituent block diagram of a computer readable storage medium according to an embodiment of the present disclosure.

[0301] As shown in Figure 36As shown, the computer readable storage medium according to the embodiments of the present disclosure has a computer program stored thereon, and the computer program is executed by a processor to implement the data transmission method according to the embodiments of the present disclosure.

[0302] The embodiments of the present disclosure also provide a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the data transmission method according to the present disclosure.

[0303] Those skilled in the art can understand that all or some of the functional modules / units in the above disclosed steps, systems and devices can be implemented as software, firmware, hardware and appropriate combinations thereof.

[0304] In the hardware implementation, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components, for example, one physical component can have multiple functions, or one function or step can be performed by several physical components in cooperation.

[0305] Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit (CPU), a digital signal processor or a microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software can be distributed on computer readable media, which can include computer storage media (or non-transitory media) and communication media (or transitory media). As is well known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, random access memory (RAM, more specifically SDRAM, DDR, etc.), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), FLASH or other memory technologies; compact disc read only memory (CD-ROM), digital versatile discs (DVD) or other optical disk storage; magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices; any other medium that can be used to store the desired information and that can be accessed by a computer. In addition, it is well known to those skilled in the art that communication media typically includes computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and can include any information delivery medium. Thus, the aforementioned computer readable medium or media should be interpreted in broad sense based on the teachings herein.

[0306] The present disclosure has disclosed example embodiments, and while specific terminology has been employed, it is merely in the nature of a general description and should not be construed as limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics or / and elements described in connection with a particular embodiment can be used in conjunction with other embodiments unless otherwise explicitly stated. As such, those skilled in the art will appreciate that modifications can be made in form and detail without departing from the scope of the disclosure as set forth in the appended claims.

Claims

1. A data transmission method, characterized in that, include: The first node sends a first request frame to the second node, wherein the first request frame includes the first node's orthogonal sequence OS capability information; The first node receives a first response frame sent by the second node, wherein the first response frame includes a first orthogonal sequence number (OS ID) information; The first node generates the first OS based on the first OS ID information.

2. The data transmission method according to claim 1, characterized in that, Before the first node sends the first request frame to the second node, the method further includes: The first node receives a first information frame sent by the second node, wherein the first information frame includes OS capability information of the second node.

3. The data transmission method according to claim 1, characterized in that, The method further includes: The first node sends a second request frame to the second node, wherein the second request frame includes OS enable information of the first node.

4. The data transmission method according to claim 3, characterized in that, The OS enable information of the first node indicates that the first node is in an OS enabled state, and the method further includes: The first node receives a second response frame sent by the second node, wherein the second response frame includes updated OS ID information; The first node generates a second OS based on the updated OS ID information.

5. The data transmission method according to claim 1, characterized in that, The method further includes: The first node periodically receives a second information frame sent by the second node, wherein the second information frame includes updated OS ID information; The first node generates a third OS based on the updated OS ID information.

6. The data transmission method according to claim 1, characterized in that, The method further includes: The first node sends a third request frame to the second node, wherein the third request frame includes the OS capability information and request reason information of the first node; The first node receives a third response frame sent by the second node, wherein the third response frame includes updated OS ID information; The first node generates a fourth OS based on the updated OS ID information.

7. The data transmission method according to claim 1, characterized in that, The first node and the second node are multi-link devices (MLDs). The first node includes multiple first child nodes, and the second node includes multiple second child nodes. Multiple links are established between the multiple first child nodes and the multiple second child nodes. The first node sending the first request frame to the second node includes: The first node sends the first request frame to the second node via any link. And the first node receiving the first response frame sent by the second node includes: The first node receives the first response frame sent by the second node via the link that sent the first request frame.

8. The data transmission method according to claim 7, characterized in that, The OS capability information includes the OS capability information of the first node itself, and the first OS ID information includes the device-level OS ID information of the first node. The first node generates the first OS based on the first OS ID information, including: Each of the first child nodes of the first node generates the first OS based on the device-level OS ID information.

9. The data transmission method according to claim 7, characterized in that, The OS capability information includes the OS capability information of the plurality of first child nodes, and the first OS ID information includes the link-level OS ID information of the plurality of first child nodes. The first node generates the first OS based on the first OS ID information, including: The plurality of first child nodes of the first node generate a plurality of first OSs based on the link-level OS ID information.

10. The data transmission method according to claim 7, characterized in that, Before the first node sends the first request frame to the second node via any link, the method further includes: The plurality of first child nodes receive first information frames sent by the plurality of second child nodes via the plurality of links, wherein the first information frame includes OS capability information of the second node.

11. The data transmission method according to claim 1, characterized in that, After the first node generates the first OS based on the first OS ID information, the method further includes: The first node sends a fourth request frame to the third node, wherein the fourth request frame includes the OS capability information and the first OS ID information of the first node; The first node receives a fourth response frame sent by the third node, wherein the fourth response frame includes OS configuration information, the OS configuration information including a status code and second OS ID information, the status code being used to indicate whether the first OS ID information is the same as the OS ID information allocated by the third node. In response to the status code indicating that the first OS ID information is different from the OS ID information assigned by the third node, the first node retains the first OS; In response to the status code indicating that the first OS ID information is the same as the OS ID information allocated by the third node, the first node generates a fourth OS based on the second OS ID information.

12. The data transmission method according to claim 11, characterized in that, The first node sending the fourth request frame to the third node includes: The first node sends the fourth request frame to the third node via the second node. The first node receiving the fourth response frame sent by the third node includes: The first node receives the fourth response frame sent by the third node via the second node.

13. The data transmission method according to claim 1, characterized in that, The OS is a ZC sequence or a Golomb multinomial sequence, and the OS ID information includes the root ordinal number, the length of the sequence, and the cyclic shift number of the root sequence.

14. A data transmission method, characterized in that, include: The second node receives a first request frame sent by the first node, wherein the first request frame includes the OS capability information of the first node; The second node sends a first response frame to the first node, wherein the first response frame includes first OSID information.

15. The data transmission method according to claim 14, characterized in that, Before the second node receives the first request frame sent by the first node, the method further includes: The second node sends a first information frame to the first node, wherein the first information frame includes OS capability information of the second node.

16. The data transmission method according to claim 14, characterized in that, The method further includes: In response to the detection that the first node has lost its connection, the second node reclaims the first OS ID information.

17. The data transmission method according to claim 14, characterized in that, The method further includes: The second node periodically sends a second information frame to the first node, wherein the second information frame includes updated OS ID information; The second node reclaims the first OS ID information.

18. The data transmission method according to claim 14, characterized in that, The method further includes: The second node receives a second request frame sent by the first node, wherein the second request frame includes OS enable information of the first node.

19. The data transmission method according to claim 18, characterized in that, In response to the OS enable information of the first node indicating that the first node is in an OS enabled state, the method further includes: The second node sends a second response frame to the first node, wherein the second response frame includes updated OSID information. In response to the OS enable information of the first node indicating that the first node is in an OS disabled state, the method further includes: The second node reclaims the first OS ID information.

20. The data transmission method according to claim 14, characterized in that, The method further includes: The second node receives a third request frame sent by the first node, wherein the third request frame includes the OS capability information and request reason information of the first node; The second node sends a third response frame to the first node, wherein the third response frame includes updated OSID information.

21. The data transmission method according to claim 14, characterized in that, The second node and the first node are MLDs. The second node includes multiple second child nodes, and the first node includes multiple first child nodes. Multiple links are established between the multiple second child nodes and the multiple first child nodes. The second node receives the first request frame sent by the first node, including: The second node receives the first request frame sent by the first node on one of the multiple links. And the second node sends the first response frame to the first node, including: The second node sends the first response frame via the link that received the first request frame.

22. The data transmission method according to claim 21, characterized in that, The OS capability information includes the OS capability information of the first node itself, and the first OS ID information includes the device-level OS ID information of the first node.

23. The data transmission method according to claim 21, characterized in that, The OS capability information includes the OS capability information of the plurality of first child nodes, and the first OS ID information includes the link-level OS ID information of the plurality of first child nodes.

24. The data transmission method according to claim 21, characterized in that, Before the second node receives the first request frame on one of the multiple links, the method further includes: The plurality of second child nodes send a first information frame to the plurality of first child nodes via the plurality of links, wherein the first information frame includes OS capability information of the second node.

25. The data transmission method according to claim 14, characterized in that, The method further includes: The second node receives a fourth request frame sent by the first node, wherein the fourth request frame includes the OS capability information and the first OS ID information of the first node; The second node forwards the fourth request frame to the third node; The second node receives a fourth response frame sent by the third node, wherein the fourth response frame includes OS configuration information, the OS configuration information includes a status code and second OS ID information, and the status code is used to indicate whether the first OS ID information is the same as the OS ID information allocated by the third node; The second node forwards the fourth response frame to the first node.

26. The data transmission method according to claim 14, characterized in that, The OS is a ZC sequence or a Golomb multinomial sequence, and the OS ID information includes the root ordinal number, the length of the sequence, and the cyclic shift number of the root sequence.

27. A communication device, characterized in that, include: A memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the method of any one of claims 1-13.

28. A communication device, characterized in that, include: A memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the method of any one of claims 14-26.

29. A storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1-26.

30. A computer program product comprising a computer program that, when executed by a processor, implements the method of any one of claims 1-26.

Images