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

Abstract

The present disclosure provides a data transmission method, characterized by comprising: a first node sends a first request frame to a second node, the first request frame comprising 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 ID information; and the first node generates a first orthogonal sequence on the basis of the first orthogonal sequence ID information. The present disclosure further provides a communication device, a storage medium, and a computer program product.

Description

Data transmission method, communication device, storage medium and computer program product 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 occurs. However, the management method for using the OS as the PR to pre-empt TXOP 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] FIG. 1 is a flowchart of a data transmission method according to an embodiment of the present disclosure;

[0012] FIG. 2 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0013] FIG. 3 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0014] FIG. 4 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0015] FIG. 5 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0016] FIG. 6 is a schematic diagram in a multi-link device application scenario according to an embodiment of the present disclosure;

[0017] FIG. 7 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0018] FIG. 8 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0019] FIG. 9 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

[0020] FIG. 10 is another flowchart of a data transmission method according to an embodiment of the present disclosure;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0040] FIG. 30 is another schematic diagram illustrating data transmission when the terminal device and the access device are multi-link devices;

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

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

[0043] FIG. 33 is another schematic diagram illustrating data transmission by a terminal device when roaming between two access devices;

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

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

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

[0047] For those skilled in the art to better understand the technical solutions of the present disclosure, the embodiments of the present disclosure are described in detail below in conjunction with the drawings. In the following, the present disclosure will be described more fully with reference to the drawings, but the embodiments shown can be embodied in different forms and the present disclosure should not be interpreted as limited to the embodiments set forth below. On the contrary, 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. The drawings of the embodiments of the present disclosure are used to provide further understanding of the embodiments of the present disclosure and constitute a part of the specification, which is used to explain the present disclosure together with the detailed embodiments, 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. The present disclosure can be described with reference to plan views and / or sectional views by means of ideal schematic diagrams of the present disclosure. Therefore, the example diagrams can be modified according to manufacturing techniques and / or tolerances. The embodiments of the present disclosure and the features in the embodiments can be combined with each other without conflict.

[0048] 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" and "the" are also intended to include the plural forms unless the context clearly indicates otherwise. As used in the present disclosure, the terms "comprise", "made of" designate the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0049] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art. It will be further 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 overly literal or overly formal sense unless expressly so defined herein.

[0050] The present disclosure is not limited to the embodiments shown in the drawings, but includes modifications of the configuration formed based on the manufacturing process. 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 the region of the element, but is not intended to be restrictive.

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

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

[0053] The FTTR technology is to connect the 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 a high-bandwidth and high-reliability connection between multi-AP networking. The connection between the master control AP and the slave AP can be realized by using a point-to-multipoint optical distribution network.

[0054] TXOP preemption technology

[0055] The TXOP preemption technology is mainly used for low latency guarantee of unpredictable low latency (LL) traffic. An orthogonal sequence (OS) can be used as a preemption request (PR) for TXOP preemption in the frame interval.

[0056] Orthogonal sequence

[0057] OSs are mainly used in code sequences of spread spectrum communication systems and 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 the OS determines the anti-interference performance of the system; in a CDMA system, the construction of an OS set is crucial for implementing regular cellular system communication. In addition, OSs are also applied to eliminate interference in an Orthogonal Frequency Division Multiplexing (OFDM) system and improve system performance. These applications demonstrate the important role of orthogonal sequences in improving the performance and reliability of communication systems.

[0058] Currently, in a Wireless Fidelity (WiFi) system, TXOP technology can be used to ensure low latency of traffic. It has been proposed that OSs can be used as PRs for TXOP preemption in the frame interval to reduce latency to a certain extent. However, the management method for using OSs as PRs for TXOP preemption in the current WiFi standard has not been specified.

[0059] Embodiments of the present disclosure propose a data transmission method for managing the use of OSs in a WiFi environment.

[0060] FIG. 1 is a flowchart of a data transmission method according to an embodiment of the present disclosure.

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

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

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

[0064] In step S130, the first node generates a first OS according to the first OS ID information.

[0065] According to an embodiment of the present disclosure, the first node notifies the second node of 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 carry OS ID information (i.e., first OS ID information) in a 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.

[0066] 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 a first OS according to the extracted OS ID.

[0067] According to an embodiment of the present disclosure, the first request frame can be one of an association request frame (Association request frame), a reassociation request frame (Reassociation request frame), an authentication frame (Authentication frame), or other types of management frames.

[0068] According to an embodiment of the present disclosure, the first response frame can be one of an association response frame (Association response frame), a reassociation response frame (Reassociation response frame), an authentication frame (Authentication frame), or other types of management frames.

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

[0070] 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 in synchronization and channel estimation in communication systems.

[0071] 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 a degree of 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.

[0072] An expression of a ZCS is as follows:

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

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

[0075] 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 ], the sub-sequence Q0 can be obtained when k=0, i.e., Q0=[a1,a2,a3...a Ni.e. the same as the root sequence, and when k = 1, a subsequence Q1 = [a2, a3, a4...a N , a1] can be obtained, when k = 2, a 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 the PR to perform TXOP preemption, the second node can identify which first node sends the PR after receiving the subsequence sent by the first node.

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

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

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

[0079] Where 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, i.e. gcd(r, N) = 1.

[0080] 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 subsequence representing itself. When N and r are known, the root sequence corresponding to r can be calculated. The root sequence is cyclically shifted by k (0 ≤ k ≤ N-1), and the root sequence is generated after being shifted to the left by k, for example, Q1 = [a2, a3, a4...a N , a1] (k = 1).

[0081] According to an embodiment of the present disclosure, the OS ID can include the root index, the length of the sequence and the root sequence cyclic shift number. The second node can assign the same root index (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 Nthereby ensuring the zero cyclic autocorrelation of the orthogonal sequence. In addition, since the root sequence cyclic shift number (i.e., k) assigned by the second node to each first node is different, each first node can obtain a respective sub-sequence (i.e., first OS) from the root sequence according to the respective root sequence cyclic shift number k. For example, for a root sequence Q Glomb = [a1, a2, a3...a N ], k = 0, a sub-sequence Q0= [a1, a2, a3...a N ] can be obtained, which is the same as the original root sequence, for k = 1, a sub-sequence Q1= [a2, a3, a4...a N , a1] can be obtained, for k = 2, a sub-sequence Q2= [a3, a4, a5...a N , a1, a2]... can be obtained, and so on. Thus, when a 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 sub-sequence sent by the first node.

[0082] FIG. 2 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

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

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

[0085] According to an embodiment of the present disclosure, before the first node advertises the OS capability information of the first node to the second node, the first node 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.

[0086] When the OS capability of the second node indicates that the second node supports generating an OS, the first node can advertise 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 second node indicates that the second node supports generating an OS, the first node can know the OS capability of the first node and advertise the OS capability of the first node to the second node. The first node and the second node advertise the OS capability information to each other, which can well accommodate devices that do not support generating an OS, and when the first node and the second node both support generating an OS, the technical solutions of the present disclosure can be executed.

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

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

[0089] In some embodiments, as shown in FIG. 3, the data transmission method according to embodiments of the present disclosure can further include steps S140-S160.

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

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

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

[0093] According to embodiments of the present disclosure, after the first node generates the first OS, the OS enablement state of the first node can change. When the OS enablement state of the first node changes, the first node can re-negotiate with the second node to make the second node aware of the updated OS enablement state of the first node. When the OS enablement 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 enablement state 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 recover the OS ID previously allocated to the first node.

[0094] In the case where the OS enablement 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.

[0095] According to embodiments of the present disclosure, when the first node sends the first request frame to the second node, the OS enablement state of the first node can be enabled by default.

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

[0097] FIG. 4 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

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

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

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

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

[0102] According to an embodiment of the present disclosure, after the first node generates the first OS, the OS of the first node can be updated periodically. Since the OS belongs to the physical layer signal 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.

[0103] FIG. 5 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0104] In some embodiments, as shown in FIG. 5, the data transmission method according to an embodiment of the present disclosure can further include steps S210-S230.

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

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

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

[0108] According to an embodiment of the present disclosure, 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.

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

[0110] According to an embodiment of the present disclosure, 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.

[0111] By re-requesting the updated OS ID information from the second node by the first node, the second node can 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.

[0112] In some embodiments, the first node and the second node are Multi-Link Devices (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.

[0113] The MLD represents a device supporting Multi-Link Operation (MLO) technology, and as a terminal device (STA), the MLD can be associated on each frequency band of the MLD as an access device (AP) at the same time, which can greatly improve the throughput and stability.

[0114] As shown in FIG. 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 appreciated that the connection mode shown in FIG. 6 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.

[0115] FIG. 7 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0116] In some embodiments, as shown in FIG. 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'.

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

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

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

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

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

[0122] 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 sub-node of the first node supports generating an OS. The device-level OS ID information of the first node can represent the OS ID information common to each first sub-node of the first node. In this case, as shown in FIG. 8, the first node generating a first OS according to the first OS ID information (i.e., step S130) includes step S131.

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

[0124] According to other embodiments of the present disclosure, in the case that 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 child 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.

[0125] 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 represent the OS ID information dedicated to each first child node. In this case, as shown in FIG. 9, the first node generating a first OS according to the first OS ID information (i.e., step S130) includes step S132.

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

[0127] According to embodiments 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 includes the OS capability information of the second node, so that the first node knows the OS capability of the second node.

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

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

[0130] In step S100', the plurality of first child nodes receive a first information frame sent by the plurality of second child nodes via a plurality of links, wherein the first information frame includes the OS capability information of the second node.

[0131] When the OS capability of the second node indicates that the second node supports generating an OS, the first node sends a 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 (for example, 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 (that is, first OS ID information) in a 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.

[0132] 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, so as to realize dynamic management of the OS ID.

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

[0134] In some embodiments, after the first node and the second node establish a link connection, the first node can initiate roaming to a third node. As shown in FIG. 11, after the first node and the second node establish a link, the first node can initiate roaming to a third node, so as to realize connection of the first node and the third node.

[0135] In the conventional roaming scheme based on 802.11KV, when the STA roams between different APs, it needs to re-perform 802.11 protocol frame interaction, key exchange and context establishment, and simultaneously needs to perform data path switching operation. This process inevitably causes temporary interruption of services, which seriously affects user experience.

[0136] To solve the above problem, the 802.11R fast switching (Fast Transition, FT) technology is proposed. This technology uses a fast transition mechanism to effectively shorten the connectionless time between the STA and different APs while realizing fast roaming. Specifically, the FT protocol provides two methods for performing switching: 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 uses the FT authentication algorithm to complete the authentication process; in the Over-the-DS mode, the STA can establish a connection with the target AP with the help of the current AP.

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

[0138] For the various roaming modes described above, the various schemes for managing the OS ID are proposed in the embodiments of the present disclosure.

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

[0140] In some embodiments, as shown in FIG. 12, in a roaming scenario, after the first node generates the first OS according to the OS ID information allocated by the second node (i.e., after steps S110-S130 shown in FIG. 1 are completed), steps S240-S270 can also be included.

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

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

[0143] In 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.

[0144] In 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.

[0145] According to the embodiments of the present disclosure, 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.

[0146] The first node can send the request information to the third node to make the third node 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 has the same OS as the device previously connected to the third node, 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, it can be indicated by a status code 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 second OS ID information allocated to the first node by the third 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 previously 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, it can be indicated by a status code 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.

[0147] According to the embodiment of the present disclosure, after the first node successfully roams to the third node, the second node can recover the OS ID allocated to the first node.

[0148] FIG. 13 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

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

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

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

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

[0153] According to the embodiments 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 taken 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 the connection capability, thereby reducing the complexity of the data transmission method.

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

[0155] As shown in FIG. 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 appreciated that the connection mode shown in FIG. 14 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.

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

[0157] FIG. 15 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0158] In some embodiments, as shown in FIG. 15, after each first sub-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 step shown in FIG. 8 is completed), the data transmission method according to the embodiments of the present disclosure can further include steps S240 to S270 shown in FIG. 12.

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

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

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

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

[0163] FIG. 16 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0164] In some embodiments, as shown in FIG. 16, after the multiple first sub-nodes of the first node generate multiple first OSs according to the link-level OS ID information allocated by the second node (i.e., after step shown in FIG. 9 is completed), the data transmission method according to an embodiment of the present disclosure can further include steps S240-S270 shown in FIG. 12.

[0165] Specifically, when the first node, the second node, and the third node are all MLDs, the first node sending the 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 the roaming or through the newly established link after completing the 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] FIG. 17 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0170] In some embodiments, as shown in FIG. 17, after each first sub-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 step shown in FIG. 8 is completed), the data transmission method according to an embodiment of the present disclosure can further include steps S240'-S270 shown in FIG. 13.

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

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

[0173] 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'.

[0174] 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 through which the fourth request frame is sent.

[0175] FIG. 18 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0176] In some embodiments, as shown in FIG. 18, after the plurality of first sub-nodes of the first node generate a plurality of first OSs according to the link-level OS ID information allocated by the second node (i.e., after step shown in FIG. 9 is completed), the data transmission method according to an embodiment of the present disclosure can further include steps S240' to S270 shown in FIG. 13.

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

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

[0179] 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'.

[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 through which the fourth request frame is sent.

[0181] According to an embodiment 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, so as to realize dynamic management of the OS ID and roaming of the MLD.

[0182] The above describes various embodiments of the data transmission method according to the present disclosure in combination with FIG. 1 to FIG. 18. It should be appreciated 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 embodiments of the data transmission method can be applied to a terminal device. In the following, 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.

[0183] FIG. 19 is a flowchart of a data transmission method according to an embodiment of the present disclosure.

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

[0185] At 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.

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

[0187] 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 carry 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.

[0188] 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 as allocating the OS ID for the first node, so that it can be clearly known which OS IDs have been allocated. On the other hand, when the second node receives an OS sent by the first node as a PR, it can know which node is performing TXOP preemption by correlation operation with the root sequence.

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

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

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

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

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

[0194] In some embodiments, as shown in FIG. 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.

[0195] In step S300, 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.

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

[0197] FIG. 21 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0198] In some embodiments, as shown in FIG. 21, the data transmission method according to an embodiment of the present disclosure can further include step S330.

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

[0200] The first node can lose association with the second node for a variety of reasons, for example, the first node roams to another node, 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 recycles the OS ID previously allocated to the first node to achieve dynamic management of the OS ID.

[0201] FIG. 22 is another flowchart of a data transmission method according to an embodiment of the present disclosure.

[0202] In some embodiments, as shown in FIG. 22, the data transmission method according to an embodiment of the present disclosure can further include steps S340-S350.

[0203] In step S340, the second node periodically sends a second information frame to the first node, wherein the second information frame includes updated OS ID information.

[0204] In step S350, the second node recycles the first OS ID information.

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

[0206] As mentioned above, the OS belongs to the signal of the physical layer and cannot be encrypted. The first node can be made to update its own OS by periodically sending the updated OS ID to the first node to improve 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 to achieve dynamic management of the OS ID.

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

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

[0209] In step S360, 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.

[0210] In step S370, in response to the OS enable 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.

[0211] In step S380, in response to the OS enable 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.

[0212] According to the embodiment of the present disclosure, after the first node generates the first OS, the enabling state of the OS of the first node can change. When the enabling state of the OS of the first node changes, the first node can re-negotiate with the second node to make the second node know the updated enabling state of the OS of the first node. When the enabling state of the OS of the first node changes from disabled to enabled, the second node can allocate an updated OS ID for 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 enabling state of the OS of the first node changes from enabled to disabled, i.e., the first node does not support generating the OS due to some reasons, the second node can recover the OS ID previously allocated to the first node.

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

[0214] 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 for the first node according to the enabling state of the OS of the first node, or recover the OS ID previously allocated to the first node, so as to realize dynamic management of the OS ID.

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

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

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

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

[0219] According to the embodiment of the present disclosure, 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 to make the second node know the OS capability of the first node and the reason for requesting to re-allocate the OD ID, for example, the reason can be information loss or other reasons.

[0220] After the second node allocates a new OS ID for the first node, the second node can recycle the OS ID previously allocated to the first node according to actual conditions, to realize dynamic management of the OS ID. For example, if the association relationship between the OS ID information locally reserved by the second node and 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 because it detects that the first node loses the association, the operation of recycling the OS ID does not need to be performed again.

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

[0222] 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, to realize dynamic management of the OS ID. By actively requesting to update the OS ID information, the first node can make the first node recover the OS, so as to ensure that the first node can use the OS as the PR to perform TXOP preemption.

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

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

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

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

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

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

[0229] According to embodiments of the present disclosure, the OS capability information can comprise OS capability information of the first node itself, and the first OS ID information can comprise device-level OS ID information of the first node.

[0230] According to embodiments of the present disclosure, the OS capability information can comprise OS capability information of a plurality of first child nodes, and the first OS ID information can comprise link-level OS ID information of the plurality of first child nodes.

[0231] FIG. 26 is another flowchart of a data transmission method according to embodiments of the present disclosure.

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

[0233] At step S300', the plurality of second child nodes send first information frames to the plurality of first child nodes via the plurality of links, wherein the first information frames comprise OS capability information of the second node.

[0234] FIG. 27 is another flowchart of a data transmission method according to embodiments of the present disclosure.

[0235] In some embodiments, as shown in FIG. 27, after the second node sends the first response frame to the first node (i.e., after steps S310-S320 shown in FIG. 19 are completed) in a roaming scenario, steps S410-S440 can be further included.

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

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

[0238] 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 OS ID information allocated by the third node.

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

[0240] According to the embodiments of the present disclosure, in the process that the first node roams from the second node to the third node, the second node can be taken 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 the connection capability, thereby reducing the complexity of the data transmission method.

[0241] 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 (see FIG. 14). The first node can initiate roaming to the third node to realize the connection of the first node and the third node.

[0242] It should be recognized that the various embodiments of the MLD in the roaming application scenario can be obtained by combining the various embodiments in the MLD application scenario described with reference to FIGS. 25-26 and the embodiment in the roaming application scenario described with reference to FIG. 27, which will not be described here again.

[0243] In order to facilitate the understanding of the technical solutions provided by the present disclosure, the following will be described in detail in conjunction with specific application scenarios.

[0244] FIG. 28 is a schematic diagram showing data transmission between a terminal device and an access device. As shown in FIG. 28, the data transmission process between the terminal device (STA) and the access device (AP) includes steps S5010-S5120.

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

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

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

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

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

[0250] At step S5060, the AP allocates a new OS ID 3 to the STA, and recovers the OS ID 2 previously allocated to the STA, and the STA generates a new OS 3 according to the new OS ID 3.

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

[0252] At step S5080, the AP recovers the OS ID 3 allocated to the STA.

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

[0254] At step S5100, the AP allocates a new OS ID 4 to the STA, and the STA generates a new OS 4 according to the new OS ID 4.

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

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

[0257] It should be appreciated that the illustrated data transmission process is only an example, and the actual order of the various 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.

[0258] FIG. 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. As shown in FIG. 29, a non-AP MLD includes three terminal devices STA1, STA2 and STA3, and an 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. A data transmission process between the non-AP MLD and the AP MLD includes steps S6010 to S6050.

[0259] At steps S6010 to S6030, the AP MLD respectively advertises its OS capability to the non-AP MLD through each link.

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

[0261] At step S6050, the AP MLD allocates device-level OS IDs for the non-AP MLD, and sends the device-level OS IDs 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.

[0262] FIG. 30 is another schematic diagram illustrating data transmission between terminal devices and access devices as multi-link devices. Similar to FIG. 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, and the link 1 is established between STA1 and AP1, the link 2 is established between STA2 and AP2, and the link 3 is established between STA3 and AP3. The data transmission process between the non-AP MLD and the AP MLD includes steps S6010 to S6060.

[0263] At steps S6010 to S6030, the AP MLD advertises its OS capabilities to the non-AP MLD via each link respectively.

[0264] At 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.

[0265] At step S6055, the AP MLD allocates link-level OS IDs for each STA of the non-AP MLD, and sends the link-level OS IDs via the link 1 between STA1 and AP1.

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

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

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

[0269] At step S7020, the STA decides to roam to the AP2.

[0270] At step S7030, the STA reports its own OS capabilities to the AP2, and the OS ID allocated by the AP1 to the STA.

[0271] At step S7040, the AP2 returns the OS configuration information to the STA, the OS configuration information including a status code, 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.

[0272] FIG. 32 is another schematic diagram illustrating data transmission of a terminal device when roaming between two access devices. As shown in FIG. 32, the terminal device (STA) is currently connected with an access device (AP1), and is about to roam to a target access device (AP2). FIG. 32 shows a roaming process in an Over-the-DS manner, including steps S7010 to S7042.

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

[0274] At step S7020, the STA decides to roam to the AP2.

[0275] At steps S7031 and S7032, the STA reports its OS capability to the AP2 via the AP1, and the OS ID allocated to the STA by the AP1.

[0276] At 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, 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.

[0277] FIG. 33 is another schematic diagram illustrating data transmission when a terminal device roams between two access devices. As shown in FIG. 33, the terminal device (STA) is currently connected with an access device (AP1), and is going to roam to a target access device (AP2). FIG. 33 illustrates a roaming process in a seamless roaming mode. In the examples shown in FIGS. 31 and 32, the STA can obtain the OS configuration information by interacting with AP2 (the example shown in FIG. 31) or AP1 (the example shown in FIG. 32) before the roaming starts. In the example shown in FIG. 33, the STA can obtain the OS configuration information by interacting with AP2 after the roaming ends.

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

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

[0280] In step S7035, the STA reports its OS capability to the AP2, and the OS ID allocated by the AP1 to the STA.

[0281] In step S7045, the AP2 returns the OS configuration information to the STA, the OS configuration information including a status code, which is used to indicate 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.

[0282] FIG. 34 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. The example shown in FIG. 34 can be regarded as a combination of the example of data transmission of the MLD shown in FIG. 29 and the example of data transmission in the roaming scenario shown in FIG. 31. The example shown in FIG. 34 is used for illustration only, and the disclosure is not limited thereto. Those skilled in the art can understand that different examples from the example shown in FIG. 34 can be generated by different combinations of the examples shown in FIGS. 29 and 30 and the examples shown in FIGS. 31 to 33. The data transmission process shown in FIG. 34 includes steps S8010 to S8080.

[0283] In steps S8010 to S8030, the AP MLD1 advertises its OS capability to the non-AP MLD through each link respectively.

[0284] At step S8040, the non-AP MLD reports its OS capability via the link between STA1 and AP11, and requests an OS ID.

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

[0286] At step S8060, the non-AP MLD decides to roam to the AP MLD2.

[0287] At step S8070, the non-AP MLD reports its OS capability to the AP MLD2, and the device-level OS ID allocated by the AP MLD1.

[0288] At step S8080, the AP MLD2 returns 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 the 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 the 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 OS; when the status code indicates that the OS ID reported by the non-AP MLD is the 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.

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

[0290] As shown in FIG. 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.

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

[0292] 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, and 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.

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

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

[0295] As shown in FIG. 36, the computer readable storage medium according to an embodiment 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 various embodiments of the present disclosure.

[0296] The present disclosure further provides a computer program product including a computer program, and the computer program is executed by a processor to implement the data transmission method according to the present disclosure.

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

[0298] 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 executed by several physical components in cooperation.

[0299] 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 hardware, or a combination of software and / or hardware. Such software can be distributed on computer readable media, which can comprise computer storage media (or non-transitory media), and communication media (or transitory media). Computer storage media, as used herein, includes volatile and nonvolatile, 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), such as SDRAM, DDR, or other RAM, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), flash memory, or other memory technology, compact disc read only memory (CD-ROM), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by a computer. Further, it should be appreciated by those skilled in the art that computer storage media generally 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 includes any information delivery media. Communication media typically embodies 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 includes any information delivery media. Examples of communication media include, but are not limited to, ionized gases, or other propagation techniques.

[0300] 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 is not intended to be 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. Accordingly, it will be understood that various changes in form and details can be made without departing from the scope of the disclosure as set forth in the appended claims.

Claims

1. A data transmission method, characterized by, Comprising: The first node sends a first request frame to the second node, wherein the first request frame comprises orthogonal sequence (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 (OS) ID information; The first node generates a first OS according to the first OS ID information.

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

3. The data transmission method of claim 1, wherein, The method further comprises: The first node sends a second request frame to the second node, wherein the second request frame comprises OS enabling information of the first node.

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

5. The data transmission method of claim 1, wherein, The method further comprises: The first node periodically receives a second information frame sent by the second node, wherein the second information frame comprises updated OS ID information; The first node generates a third OS according to the updated OS ID information.

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

7. The data transmission method of claim 1, wherein: The first node and the second node are multi-link devices (MLDs), the first node comprises a plurality of first sub-nodes, the second node comprises 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, The first node sending the first request frame to the second node comprises: The first node sends the first request frame to the second node via any one link, And the first node receiving the first response frame sent by the second node comprises: The first node receives the first response frame sent by the second node via the link on which the first request frame is sent.

8. The data transmission method of claim 7, wherein, The OS capability information comprises OS capability information of the first node itself, and the first OS ID information comprises device-level OS ID information of the first node, The first node generating the first OS according to the first OS ID information comprises: Each first sub-node of the first node generates the first OS according to the device-level OS ID information.

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

10. The data transmission method of claim 7, wherein, Before the first node sends the first request frame to the second node via any one of the links, 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 frames include OS capability information of the second node.

11. The data transmission method of claim 1, wherein, After the first node generates the first OS according to the first OS ID information, the method further includes: The first node sends a fourth request frame to a third node, wherein the fourth request frame includes OS capability information of the first node and the first OS ID information; 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 includes a status code and second OS ID information, the status code is used to indicate whether the first OS ID information is the same as 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 allocated 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 according to the second OS ID information.

12. The data transmission method of claim 11, wherein The first node sends the fourth request frame to a third node includes: The first node sends the fourth request frame to the third node via the second node, The first node receives 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 of claim 1, wherein, The OS is a ZC sequence or a Golomb polynomial sequence, and the OS ID information includes a root sequence number, a length of the sequence, and a root sequence cyclic shift number.

14. A data transmission method, characterized by, includes: The second node receives a first request frame sent by a first node, wherein the first request frame includes 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 OS ID information.

15. The data transmission method of claim 14, wherein, 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 of claim 14, wherein, The method further includes: In response to detecting that the first node loses association, the second node recycles the first OS ID information.

17. The data transmission method of claim 14, wherein, The method further includes: The second node periodically sends a second information frame to the first node, where the second information frame comprises updated OS ID information; The second node recycles the first OS ID information.

18. The data transmission method of claim 14, wherein, The method further comprises: The second node receives a second request frame sent by the first node, where the second request frame comprises OS capability information of the first node.

19. The data transmission method of claim 18, wherein, In response to the OS capability information of the first node indicating that the first node is in an OS enabled state, the method further comprises: The second node sends a second response frame to the first node, where the second response frame comprises updated OS ID information, In response to the OS capability information of the first node indicating that the first node is in an OS disabled state, the method further comprises: The second node recycles the first OS ID information.

20. The data transmission method of claim 14, wherein, The method further comprises: The second node receives a third request frame sent by the first node, where the third request frame comprises the OS capability information of the first node and request reason information; The second node sends a third response frame to the first node, where the third response frame comprises updated OS ID information.

21. The data transmission method of claim 14, wherein The second node and the first node are MLDs, the second node comprises a plurality of second sub-nodes, the first node comprises a plurality of first sub-nodes, and a plurality of links are established between the plurality of second sub-nodes and the plurality of first sub-nodes, The second node receives the first request frame sent by the first node comprises: The second node receives the first request frame sent by the first node on one of the plurality of links, And the second node sends the first response frame to the first node comprises: The second node sends the first response frame via the link on which the first request frame is received.

22. The data transmission method of claim 21, wherein, The OS capability information comprises OS capability information of the first node itself, and the first OS ID information comprises device-level OS ID information of the first node.

23. The data transmission method of claim 21, wherein, The OS capability information comprises OS capability information of the plurality of first sub-nodes, and the first OS ID information comprises link-level OS ID information of the plurality of first sub-nodes.

24. The data transmission method of claim 21, wherein, Before the second node receives the first request frame on one of the plurality of links, the method further comprises: The plurality of second sub-nodes send a first information frame to the plurality of first sub-nodes via the plurality of links, where the first information frame comprises OS capability information of the second node.

25. The data transmission method of claim 14, wherein, The method further comprises: The second node receives a fourth request frame sent by the first node, where the fourth request frame comprises OS capability information of the first node and the first OS ID information; The second node forwards the fourth request frame to a third node; 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 state code and second OS ID information, and the state 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 of claim 14, wherein, The OS is a ZC sequence or a Golomb polynomial sequence, and the OS ID information comprises a root sequence number, a length of the sequence, and a root sequence cyclic shift number.

27. A communications device, comprising: The method comprises the following steps: A memory and a processor, wherein the memory stores a computer program, and the processor implements the method in any one of claims 1-13 when executing the computer program.

28. A communications device, comprising: The method comprises the following steps: A memory and a processor, wherein the memory stores a computer program, and the processor implements the method in any one of claims 14-26 when executing the computer program.

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

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

Images