A low-latency, efficient, directional access method for terahertz wireless local area networks

Abstract

The present invention seeks to protect a low-latency, efficient, directional access method for a terahertz wireless local area network, which operates on two types of nodes, PNC and DEV. The method divides network operation time into multiple superframes of variable length but with threshold limits, each superframe consisting of three ordered time periods: Beacon, CAP, and CTAP. When the time difference between the superframe length and the maximum length threshold can support the transmission of data frames and there are data packets sent to the DEV in the network, a CTA is pre-allocated to the PNC so that it forwards the data packets destined for the DEV in the network within the same superframe. Furthermore, when there is a situation in which the data frames are sent and received in opposite directions in the superframe and the PNC sends a frame in the pre-allocated CTA, the CTA sequence is scheduled so that the PNC no longer performs beamforming operations in the pre-allocated CTA. This achieves the effect of reducing the average end-to-end delay of the data packets and reducing the control overhead, and is conducive to improving time slot utilization.

Description

Technical Field

[0001] The present invention belongs to the field of using terahertz wireless local area network (TWLAN) technology, and in particular relates to a terahertz wireless local area network scenario that adopts a directional communication method in the physical layer of the network and a superframe structure and beamforming mechanism in the MAC (Medium Access Control) sublayer. Background Art

[0002] Terahertz (THz) waves are electromagnetic waves with wavelengths between millimeter waves and infrared light waves, with wavelengths ranging from 3mm to 0.03mm and frequencies ranging from 0.1THz to 10THz, respectively. The THz frequency band corresponding to THz waves has an available bandwidth more than twice that of the millimeter wave band. According to the Shannon equation, under a constant signal-to-noise ratio at the receiver, the maximum data rate supported by a wireless link is proportional to the bandwidth. Therefore, the THz band has the conditions to support higher data rates. With the increasing demand for data rates, increasing the bandwidth used by the signal has become a relatively direct approach, and the THz band has gradually attracted attention. However, in actual communications, atmospheric attenuation (especially water vapor absorption) affects the propagation distance of THz waves; therefore, THz band communications are currently being considered more for shorter-distance wireless communications.

[0003] Terahertz wireless networks are a new type of wireless communication network that uses terahertz waves for data transmission. These networks leverage the vast bandwidth available in the terahertz frequency band to guarantee speeds exceeding 10 Gbps for emerging new services. Terahertz wireless networks are self-organizing, self-managing, and high-bandwidth wireless networks. As a key application area for future short-range ultra-high-speed wireless communications, they hold significant research and application value. Currently, typical terahertz wireless network applications are wireless personal area networks (WLANs) and wireless local area networks (WLANs). Nodes in these networks can consist of multiple military or civilian consumer wireless electronic products, such as personal portable electronic devices, high-resolution displays, and laptops. Their communication range is typically limited to tens of meters, making them suitable for public settings with high bandwidth requirements, such as airports, high-speed rail stations, and stadiums. They can also be used for collaborative office work and home entertainment.

[0004] The terahertz wireless local area network described in this application is a type of terahertz wireless network. It is a wireless data communication network composed of a central node and multiple ordinary nodes surrounding the central node, with a star network topology and a physical layer wireless carrier frequency in the terahertz frequency band (0.1THz~10THz). It includes two types of nodes: PNC (PicoNet Coordinator) with central control function and ordinary DEV (DEVice) (see document: IEEE802.15.3. IEEE standard for high data rate wireless multi-media networks[S], New York: IEEE, 2016). The destination of network transmission data can be a node within the network, or it can be transmitted to an external device by the PNC through an external link. In a terahertz wireless local area network, DEVs cannot communicate directly with each other and data forwarding must be carried out through the PNC. Please refer to the attached document of the specification for the composition of the terahertz wireless local area network. Figure 1 .

[0005] Network access methods operate within the MAC sublayer of the network's data link layer, fulfilling crucial functions such as channel access control and channel resource allocation. They play a crucial role in the communications architecture. In recent years, research on access methods for terahertz (THz) wireless networks has begun, and some progress has been made. Furthermore, to increase the range of THz communication, researchers have expanded THz communication from omnidirectional to directional communication. Consequently, research and development of access methods has also expanded from omnidirectional to directional approaches.

[0006] Guan et al. proposed terahertz communication applications in three scenarios (see the literature: Guan K, Li G, Kuerner T, et al. On Millimeter Wave and THz Mobile Radio Channel for SmartRail Mobility [J]. IEEE Transactions on Vehicular Technology, July 2017, 66(7): 5658-5674). The first scenario is the communication between high-speed train carriages and roadside base stations, the second scenario is the mutual communication between roadside terahertz base stations, and the third scenario is the communication between passenger mobile devices in the carriage and the rooftop network access point using the terahertz frequency band. For the first scenario, the literature recommends the use of directional transmission technology with beamforming to reduce interference and energy consumption. In the second scenario, it is recommended that the network topology should be considered to support collaboration and data forwarding between multiple base stations. In the third scenario, it is necessary to design an appropriate network access protocol to connect the mobile devices in the vehicle to the rooftop network access point and achieve high-speed data transmission. The application of terahertz communication in high-speed mobile scenarios is challenging and requires overcoming problems such as channel fading, interference, and multipath effects. The design of terahertz MAC protocol is the key to solving these problems.

[0007] Yao et al. proposed a terahertz MAC protocol based on a 2.4 GHz auxiliary channel (see reference: Yao XW, Jornet J M. TAB-MAC: Assisted beamforming MAC protocol for terahertz communication networks [J]. Nano Communication Networks, 2016, 9(9): 36-42). The protocol aims to simplify the position estimation and channel access between nodes and reduce the complexity of beamforming by utilizing the 2.4 GHz WiFi channel to assist the terahertz channel for communication. The protocol divides the nodes into control nodes and regular nodes. The control nodes are responsible for obtaining the location information of themselves and the nodes in the network and broadcasting it to the regular nodes so that the regular nodes can communicate based on the location information. However, the protocol has some limitations. For example, the 2.4 GHz channel is only used for interactions with a small amount of data, so there is a problem of low channel utilization. In addition, the introduction of two different types of transceivers will also increase additional costs and power consumption.

[0008] Zou Mingrui et al. proposed a high-throughput, low-delay access method for terahertz wireless local area networks, HLMAC (High-throughput low-delay MAC, see reference: Zou Mingrui, Zhou Haidong, Li Guangbin, Ren Zhi, Zhou Xun. Optimization design of media access control protocol for terahertz wireless local area networks [J]. Systems Engineering and Electronics, 2017, 39(12): 2824-2830). The protocol proposes a new superframe structure that swaps the CAP period and the CTAP period, which can reduce data transmission delay. However, there is a problem that the CAP period does not have enough time to prepare the beacon frame of the next superframe. The article also proposed "adaptive dynamic adjustment of the CAP period length", "combining the application amount of pre-allocated time slots without application", and "deleting redundant control fields". Although these mechanisms can reduce the control overhead of the Beacon period and the CAP period to a certain extent, there is a lack of corresponding optimization mechanisms for the beamforming stage, which has the largest control overhead in the LAN network environment.

[0009] Li Weizheng proposed a fair, low-latency directional MAC protocol for terahertz wireless personal area networks (see: Li Weizheng. Research on a directional MAC protocol for terahertz wireless personal area networks and its implementation based on ZYNQ [D]. Master's thesis, Chongqing: Chongqing University of Posts and Telecommunications, 2022, pp. 22-30). To address the unfairness caused by nodes in the rear sectors being allocated fewer time slots, the protocol proposes to allocate time slots evenly to each node that applies for them. For nodes with lower-than-average application volumes, the excess CTAs are evenly distributed to other nodes. To address the situation where a node in a terahertz wireless personal area network both receives and transmits data during the CTAP period of a superframe, a mechanism is proposed to reduce beamforming overhead. This node first performs the first-stage beamforming simultaneously with the source and destination nodes, then performs the second-stage beamforming sequentially, and finally transmits data with both nodes. This mechanism reduces the repeated beamforming of some nodes in the terahertz personal area network, reduces the control overhead, and at the same time ensures the fairness of node time slot allocation to a certain extent, reducing data transmission delay.

[0010] To address the issue of excessive beamforming overhead in terahertz local area networks (THz LANs), Liu Yijun proposed a fair, low-latency directional MAC protocol for THz wireless LANs, TFLL-MAC (see Liu Yijun. Research on Directed MAC Protocol for Terahertz Wireless LANs [D]. Master's Thesis, Chongqing: Chongqing University of Posts and Telecommunications, 2022, pp. 47-56). This protocol uses a PNC to allocate adjacent CTAs to the same nodes on both sides of the communication, avoiding repeated beamforming within the same superframe and reducing some control overhead. However, this mechanism increases control overhead by adding the CTRq control field to the beacon frame to notify nodes to merge CTAs, while still presenting the issue of excessive average data latency. The article also proposes establishing a slot request priority list based on the number of slots previously requested. Nodes with higher priorities receive slots first. This mechanism ensures fairness in slot acquisition for nodes within the network.

[0011] Su et al. proposed a low-latency directional MAC protocol suitable for terahertz wireless networks (Reference: Su X, Wu BY, Guo L, et al. Low Delay and Low Overhead Terahertz Wireless Personal Area Networks Directional MAC Protocols[C]. 2021 6th International Conferenceon Intelligent Computing and Signal Processing(ICSP), Xi'an, China, 2021: 687-691). The protocol is based on historical sector information, shortens the beamforming range, and reduces some data transmission delays. However, for networks with a large node mobility range, this mechanism does not significantly reduce the beam overhead. At the same time, this mechanism has the problem of low utilization of allocated time slots and limited improvement in transmission delay for terahertz wireless local area networks.

[0012] From the above research background and current status, it's clear that research on omnidirectional and directional access methods for terahertz wireless networks (particularly terahertz wireless personal area networks) has been ongoing for some time. (In principle, the access methods used in terahertz wireless personal area networks can be applied to terahertz wireless local area networks with minor modifications.) Some progress has been made in areas such as superframe structures. However, in-depth research has revealed that in existing directional access methods applicable to terahertz wireless local area networks, when the time difference between the superframe length and the maximum length threshold is sufficient to support the transmission of data frames and the PNC has data to send to the network, redundant data packet delays and possibly redundant beamforming operations may occur. This can negatively impact the control overhead performance and data packet delay of the access method, and therefore requires further research and resolution. Summary of the Invention

[0013] The present invention aims to solve the above problems in the prior art. It proposes a method for efficient directional access to a terahertz wireless local area network with low latency. The technical solution of the present invention is as follows:

[0014] A low-latency, efficient, directional access method for a terahertz wireless local area network (THz wireless LAN) is disclosed. The THz wireless LAN includes two types of nodes: PNCs (piconet coordinators) and DEVs (devices). Each node uses a directional communication mode to send and receive any frame. The network operation time is divided into multiple superframes, each superframe consisting of three ordered periods: Beacon, CAP, and CTAP. The CAP period (contention access period) includes an associated CAP subperiod and a regular CAP subperiod, and the CTAP period (channel time allocation period) includes one or more variable-length CTA channel time allocation units. The method comprises the following steps:

[0015] After powering on, the node determines whether its type is PNC or DEV. If it is PNC, it performs operations related to PNC; if it is DEV, it performs operations related to DEV.

[0016] During the Beacon period, the PNC broadcasts beacon frames in each sector in sequence. The beacon frames contain information about the superframe period delimitation and time slot allocation results.

[0017] During the Beacon period, the DEV waits for the reception of beacon frames in each sector in sequence; if received, it extracts the information and processes it accordingly;

[0018] In the associated CAP sub-period of the CAP period, the DEV that has not yet joined the network sends a network application frame to the PNC in its own time slot, and then waits to receive a network application reply frame; if a network application reply frame is received, the information in it is extracted and stored;

[0019] In the associated CAP sub-period of the CAP period, the PNC waits in each sector in sequence to receive the network access application frame sent by the DEV that has not yet joined the network. If received, it extracts the information in the frame to determine whether to approve the network access and sends a network access application reply frame to the DEV.

[0020] During the regular CAP sub-period of the CAP period, a DEV that has data to send but has not obtained a time slot sends a time slot request frame to the PNC in its own time slot. The time slot request frame contains the ID of the destination DEV of the data packet; then it waits to receive a time slot request reply frame sent by the PNC. If a time slot request reply frame is received, the information in the frame is extracted and stored.

[0021] During the regular CAP sub-period of the CAP period, the PNC waits in each sector to receive a timeslot request frame. If a timeslot request frame is received, the PNC determines whether to allocate a timeslot to the DEV requesting the timeslot. Regardless of whether the timeslot is allocated, the PNC responds with a timeslot request reply frame to the DEV requesting the timeslot. If the PNC agrees to allocate the timeslot to the DEV, it extracts the source and destination DEV ID information from the timeslot request frame and stores it in a pre-established "obtained timeslot node information table." The PNC then extracts the data packet destination node ID from the timeslot request frame and stores it in the "obtained timeslot node information table."

[0022] During the CTAP period, the PNC first allocates a CTA for its own data to be sent and the DEV that has applied for the time slot; then it determines whether the time difference between the length of the next superframe and the maximum length threshold can support the sending of data frames. If so, it allocates a CTA for the data packets it will receive in the next superframe and whose destination is the DEV in the network, until no more CTAs can be added in the next superframe; the pre-allocated CTA is placed after the allocated CTA; if the PNC has pre-allocated a CTA for itself, it determines whether there is a situation in which the data frames are sent and received in the opposite direction in the next superframe, and it involves the PNC sending frames in the pre-allocated CTA. If so, it uses the data packet destination node ID to search the "Obtain Time Slot Node Information Table" to obtain the ID of the source DEV of the data packet; then, according to the "Data packet source DEV sends to PNC" The order of the CTA of the frame, the CTA at which the data packet destination DEV sends the frame to the PNC, and the pre-assigned CTA at which the PNC sends the frame to the data packet destination DEV forms an "associated CTA triplet." This triplet is arranged starting from the first CTA of the CTAP period, and the positions of the remaining CTAs in the CTAP period are shifted back in time. If the PNC has a CTA involving itself in the CTAP period, it performs the following operations within that CTA: as a source node, if the sector where the destination node is located is unknown, it first performs beamforming and then transmits the data frame; if the sector where the destination node is located is known in the previous CTA, it uses a simplified CTA scheduling mechanism that only includes the data transmission phase and directly sends the data frame; as a destination node, it first performs beamforming and then waits to receive the data frame, and then performs the corresponding processing after receiving the data frame.

[0023] During the CTAP period, if a DEV has a CTA involving itself, it will perform corresponding operations within the CTA: if it is the source node of the data frame, it will first perform beamforming and then send the data frame; if it is the destination node of the data frame, if the PNC location sector was not known in the previous CTA, it will first perform beamforming and then receive the data frame; if the PNC location sector was known in the previous CTA, it will use the CTA scheduling streamlined mechanism that only includes the data transmission phase, directly wait for the reception of the data frame, and perform corresponding processing after receiving the data frame.

[0024] Furthermore, it also includes a "pre-allocate CTA for PNC on demand" mechanism and a "CTA scheduling simplification" mechanism. The "pre-allocate CTA for PNC on demand" mechanism works in the regular CAP sub-period and CTAP period, and the "CTA scheduling simplification" mechanism works in the CTAP period.

[0025] Furthermore, the "pre-allocation of CTACTA to PNC on demand" mechanism specifically includes:

[0026] If the PNC receives data in the next superframe and the data is to be sent to a node in the network, and the time difference between the length of the next superframe and the maximum length threshold can support the sending of the data frame, the PNC will pre-allocate a CTA in the next superframe for itself to send the data received in the next superframe. CTA represents time slot resources. It is recommended that the CTA pre-allocated to the PNC be placed after the CTA allocated according to the existing relevant methods. In addition, the PNC needs to obtain the ID of the destination node of the data packet from the time slot application frame. The node ID is actually the MAC address of the node in the network. It is preset that each node knows the IDs of other nodes in the network. The address of the data packet also uses the node ID. It is recommended that the node ID use a short address format of 8 bits or 16 bits, so that the data packet sent by the DEV and destined for a node in the network can be forwarded by the PNC within the same superframe, thereby reducing the delay of the data packet.

[0027] Furthermore, the “CTA scheduling streamlining” mechanism specifically includes:

[0028] When a CTA is pre-assigned to the PNC, if the data frame transmission and reception directions are reversed in the next superframe, the order of the CTAs is scheduled: the CTAs are arranged in the order of the data packet source DEV sending frames to the PNC, the data packet destination DEV sending frames to the PNC, and the PNC sending frames to the data packet destination DEV; and the CTAs for the PNC sending frames to the data packet destination DEV are streamlined and no beamforming operation is performed. The advantages and beneficial effects of the present invention are as follows:

[0029] (1) Reduce the average end-to-end delay of data packets

[0030] When the time difference between the length of a superframe and the maximum length threshold is sufficient to support the transmission of data frames, if the PNC receives a data packet destined for a DEV within the network within the superframe (the data packet is assembled in the data frame), the PNC can forward the data packet to the destination DEV within the superframe using the pre-assigned CTA, without having to wait until the next superframe to allocate a time slot for forwarding. This can shorten the waiting time experienced by some data packets on the PNC (usually in the cache of the PNC's MAC sublayer), thereby reducing the average end-to-end delay of the data packets overall.

[0031] (2) Reduce control overhead

[0032] If a CTA is pre-assigned to the PNC, and the PNC transmits data frames in opposite directions within the superframe (for example, DEV_A transmits a data frame to the PNC, and the PNC transmits a data frame to DEV_A in a pre-assigned time slot), scheduling the CTA sequence allows the PNC to transmit the data frame in the pre-assigned time slot without performing beamforming operations because it already knows the sector where the data frame's destination DEV is located. This eliminates the need to send beamforming scan frames and beamforming reply frames, thus reducing overall control overhead. Furthermore, reducing beamforming operations also reduces beamforming time, which helps improve time slot utilization. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Attachment Figure 1 The present invention provides a preferred embodiment of a terahertz wireless local area network composition schematic diagram.

[0034] Attachment Figure 2 It is a regular superframe structure.

[0035] Attachment Figure 3 It is a conventional CTA structure.

[0036] Attachment Figure 4 The superframe structure containing pre-allocated CTAs used by the new method proposed in the present invention.

[0037] Attachment Figure 5 Request a frame core structure for the timeslot.

[0038] Attachment Figure 6 This is the basic structure of the "Obtain Time Slot Node Information Table".

[0039] Attachment Figure 7 Schematic diagram of “associated CTA triples”.

[0040] Attachment Figure 8 To streamline the CTA structure.

[0041] Attachment Figure 9 This is a schematic diagram of the new method proposed in the present invention.

[0042] Attachment Figure 10 This is the flow chart of the CTA sequential scheduling algorithm. DETAILED DESCRIPTION

[0043] The following will describe the technical solutions in the embodiments of the present invention in detail with reference to the accompanying drawings. The described embodiments are only a part of the embodiments of the present invention.

[0044] The technical solution of the present invention to solve the above technical problems is:

[0045] In order to solve the problem of "redundant data packet delay and possible redundant beamforming operations when the time difference between the superframe length and the maximum length threshold can support the transmission of data frames and the PNC has data to send to the network" in the existing directional access method of terahertz wireless local area networks, the present invention proposes a low-latency and efficient directional access method for terahertz wireless local area networks. This method includes two new mechanisms: "pre-allocating CTAs for PNCs on demand" and "streamlining CTA scheduling." When the time difference between the superframe length and the maximum length threshold can support data frame transmission, CTAs (Channel Time Allocation) are pre-allocated to the PNC on demand, CTAs are scheduled sequentially, and CTAs with opposite data frame transmission and reception directions are merged. This allows the PNC to transmit data frames received in a superframe within the same superframe, potentially reducing beamforming operations. This reduces the overall waiting time for data packets in the PNC, lowers the average data packet latency, and overall reduces the control overhead and time of beamforming operations, improving access method efficiency and facilitating increased time slot utilization.

[0046] The basic idea of ​​the new method proposed in this invention

[0047] According to the existing terahertz wireless LAN directional access method, the channel time is composed of several superframes. A superframe includes three periods: Beacon, CAP, and CTAP. The CAP period is subdivided into the associated CAP sub-period and the regular CAP sub-period. The CTAP consists of one or more CTAs, each of which includes a beamforming phase and a data frame transmission phase. The regular superframe structure is as shown in the appendix of the manual. Figure 2 As shown in the attached manual, the conventional CTA structure Figure 3 As shown in the figure, the superframe length is not fixed, but a maximum length threshold is preset. Within a superframe, the lengths of the Beacon and CAP periods are usually fixed. The length of the CTAP period varies because the length and number of the CTAs that make up the CTAP period change with time slot demand. The beacon frames broadcast by the PNC during the Beacon period contain information such as the superframe length and time slot allocation. Changes in the CTAP period length will cause changes in the superframe length. Both the CTAP period and the superframe have their own maximum length thresholds, and their lengths cannot exceed their respective maximum length thresholds.

[0048] According to existing terahertz wireless local area network (TWAN) directional access methods, after receiving a time slot request from another node, the PNC allocates time slots in the next superframe for itself and the other nodes during the CTAP period of the current superframe. The fundamental basis for allocating time slots is the amount of data already received and pending for transmission by itself and the other nodes, while data that the PNC will receive in the next superframe is not considered. Consequently, if the PNC receives data in the next superframe and needs to transmit it to a node within the network, even if the time difference between the next superframe length and the maximum length threshold supports data frame transmission, the PNC cannot transmit the data packet contained in the received data frame in the next superframe due to the lack of pre-assigned time slots. This results in redundant delay for the data packet. Furthermore, if the PNC pre-assigns time slots and data frames are transmitted and received in the opposite direction in the next superframe, one beamforming operation could be reduced through sequential CTA scheduling and CTA simplification. However, because existing access methods do not consider and design this issue, CTA simplification cannot be implemented, resulting in redundant beamforming operations.

[0049] To address the above issues, the present invention proposes a low-latency, efficient, directional access method for terahertz wireless local area networks. This method incorporates two new mechanisms: pre-allocating CTAs to PNCs on demand, and streamlining CTA scheduling. The basic principles of these new mechanisms are as follows:

[0050] (1) Pre-allocate CTA to PNC on demand

[0051] If the PNC receives data (in the form of data packets) in the next superframe and the data is to be sent to a node in the network, and the time difference between the length of the next superframe and the maximum length threshold can support the transmission of the data frame, the PNC will pre-allocate a CTA (CTA stands for time slot resource) in the next superframe for itself to send the data received in the next superframe; it is recommended that the CTA pre-allocated to the PNC be placed after the CTA allocated according to the existing relevant method. The superframe structure containing the pre-allocated CTA is shown in the appendix of the specification. Figure 4 As shown; and, the PNC needs to obtain the ID of the destination node of the data packet from the time slot application frame (the node ID is actually the MAC address of the node in the network; it is preset that each node knows the IDs of other nodes in the network; and in the directional access method proposed in the present invention, the address of the data packet also uses the node ID; it is recommended that the node ID use a short address format of 8 bits or 16 bits). The core structure of the time slot application frame is shown in the appendix of the specification. Figure 5 In this way, data packets sent by the DEV and destined for nodes within the network can be forwarded by the PNC within the same superframe (the next superframe mentioned above), thereby reducing the overall delay of the data packets.

[0052] (2) CTA scheduling streamlining

[0053] If a CTA is pre-assigned to the PNC, and the data frame transmission and reception directions are reversed in the next superframe (for example, DEV_A transmits a data frame to the PNC, and the PNC transmits another data frame to DEV_A in the pre-assigned time slot), the CTAs are scheduled in the order of the source DEV (source DEV) transmitting the frame to the PNC, the destination DEV (destination DEV) transmitting the frame to the PNC, and finally the PNC transmitting the frame to the destination DEV. Furthermore, the CTA where the PNC transmits the frame to the destination DEV is streamlined and beamforming is not performed, because the PNC already knows the sector where the destination DEV is located through beamforming in the previous CTA (the CTA where the destination DEV transmits the frame to the PNC). This reduces the number of beamforming operations overall, lowers control overhead, and reduces the overall time spent on beamforming operations, which also helps improve time slot utilization.

[0054] The basic idea of ​​the low-latency, efficient, directional access method for terahertz wireless local area networks proposed in this invention is as follows:

[0055] (1) During the Beacon period, the PNC broadcasts a beacon frame containing information such as superframe length and time slot allocation results to each sector. The DEV stores the relevant information after receiving it.

[0056] (2) During the associated CAP sub-period, the DEV that has not yet joined the network applies to the PNC for network access.

[0057] (3) In the regular CAP sub-period, a DEV that has data packets to send but has not obtained a time slot applies for a time slot from the PNC. The time slot application frame carries the ID of the destination node of the data packet. After the PNC agrees to grant the DEV a time slot, it stores the source DEV ID and the destination DEV ID of the data frame in a pre-established "obtained time slot node information table". The basic structure of the "obtained time slot node information table" is shown in the appendix of the manual. Figure 6 and, according to the new mechanism of "pre-allocating CTA for PNC on demand", PNC extracts the data packet destination node ID from the time slot application frame and also stores it in the "obtained time slot node information table".

[0058] (4) After the CTAP period begins, the PNC allocates the CTA for the next superframe.

[0059] The allocation strategy is: First, the PNC allocates CTAs to itself and the DEVs that obtain time slots in the order of application. In principle, each node is allocated one CTA. Then, the "pre-allocate CTAs to PNCs on demand" function is executed.

[0060] The new mechanism is that, if the time difference between the length of the next superframe and the maximum length threshold can support the transmission of data frames, the PNC pre-allocates a CTA in the next superframe for itself to send the data packets received in the next superframe. Then, the new "CTA scheduling simplification" mechanism is run. When the CTA in the next superframe is pre-allocated to the PNC, if there are data frames with opposite transmission and reception directions in the next superframe, the PNC schedules the order of the CTAs and forms an "associated CTA triplet" in the order of "CTA of the data packet source DEV sending the frame to the PNC, CTA of the data packet destination DEV sending the frame to the PNC, and pre-allocated CTA of the PNC sending the frame to the data packet destination DEV", as shown in the appendix to the manual. Figure 7 As shown; then based on this scheduling result, the CTA that the PNC sends frames to the destination DEV is simplified to form a new CTA type - simplified CTA. The simplified CTA has fewer beamforming stages than the conventional CTA and only performs data frame transmission operations. Its structure is shown in the appendix of the manual. Figure 8 shown.

[0061] (5) During the CTAP period, if the

[0062] In CTA, the source node and destination node of the data frame first perform beamforming, and after achieving the beam alignment state, the data frame is transmitted. If it is in the "simplified CTA" defined by the directional access method proposed in this invention, the PNC does not perform beamforming operation and directly transmits the data frame to the destination DEV.

[0063] The main operation of the new method proposed by the present invention

[0064] This invention proposes a low-latency, efficient, directional access method for terahertz wireless local area networks. This method divides network nodes into PNCs and DEVs based on their physical structure and logical function. Furthermore, it divides the network's operating time into multiple superframes. Each superframe consists of three sequential time periods: Beacon, CAP (subdivided into associated sub-CAP and regular sub-CAP), and CTAP (composed of one or more CTAs). The number and length of CTAs are variable, as is the length of the CTAP period. The superframe length is also variable within a maximum length threshold.

[0065] The present invention proposes a low-latency terahertz wireless local area network efficient directional access method, which includes two new mechanisms: "pre-allocating CTA for PNC on demand" and "simplified CTA scheduling". Among them, the new mechanism of "pre-allocating CTA for PNC on demand" works in the regular CAP sub-period and CTAP period, and the "simplified CTA scheduling" mechanism works in the CTAP period, as shown in the appendix of the specification. Figure 9As shown below. The following specifically introduces the main operations of the terahertz wireless network directional access method proposed by the present invention in the order of Beacon, CAP, and CTAP periods and according to the differences between PNC and DEV.

[0066] In a specific embodiment, a terahertz wireless local area network contains one PNC and m DEVs (m≥1); the PNC serves as the topological center and logical center of the network, and the PNC allocates data transmission time slots within the network and enables the entire network to operate orderly; the DEV serves as an ordinary node and uses the network for data communication according to the arrangement of the PNC; when data communication is carried out between nodes, both sending and receiving use the directional communication method, and the number of sectors is n (n>1); the destination of the data can be a node within the network or an external device. According to a low-latency terahertz wireless local area network efficient directional access method proposed by the present invention, the operating time of the terahertz wireless local area network consists of consecutive superframes; each superframe is divided into three periods: Beacon, CAP, and CTAP; the CAP period is further divided into an association CAP sub-period and a regular CAP sub-period; the CTAP period consists of one or more CTAs with variable lengths; the length of the basic time slot is t seconds (0<t). A low-latency terahertz wireless local area network efficient directional access method proposed by the present invention includes two new mechanisms: "pre-allocate CTA for PNC on demand" and "CTA scheduling simplification"; among them, the new mechanism of "pre-allocate CTA for PNC on demand" works in the regular CAP sub-period and the CTAP period, and the "CTA scheduling simplification" mechanism works in the CTAP period.

[0067] A specific embodiment of a low-latency terahertz wireless local area network efficient directional access method proposed by the present invention is as follows:

[0068] S1: After the node is powered on, it judges: whether its type is PNC? If so, execute the next step; otherwise, go to S3.

[0069] S2: PNC operation

[0070] S2-1: Main operations of PNC in the Beacon period [[ID=]16]

[0071] The PNC starts from sector 0, broadcasts n beacon frames in each sector, and broadcasts one beacon frame in each basic time slot until all n sectors are traversed; the beacon frame contains information such as superframe period delimitation and time slot allocation results.

[0072] S2-2: Main operations of PNC in the association CAP sub-period

[0073] The PNC rotates the antenna and waits for one basic time slot in each sector in turn to receive a network access application frame sent by a DEV that has not yet joined the network. If a network access application frame is received from a DEV, the PNC will determine whether to allow the DEV to join the network. Regardless of whether the DEV is allowed to join the network, the PNC will reply with a network access application reply frame to the DEV that has applied for network access.

[0074] S2-3: PNC main operations in regular CAP sub-period

[0075] The PNC rotates its antenna and waits for one basic time slot in each sector in turn to receive a time slot request frame sent by the DEV. If it receives a time slot request frame from the DEV, it will determine whether it agrees to allocate the time slot to the DEV. Regardless of whether it agrees to allocate the time slot to the DEV, the PNC will reply with a time slot request reply frame to the DEV that requested the time slot. If the PNC agrees to allocate the time slot to the DEV, it will extract information such as the source and destination DEV IDs from the time slot request frame and store it in the pre-established "obtained time slot node information table." Then, based on the new mechanism of "pre-allocating CTAs to PNCs on demand," the PNC will extract the data packet destination node ID from the time slot request frame and also store it in the "obtained time slot node information table."

[0076] S2-4: PNC main operations during CTAP period

[0077] S2-4-1: PNC allocates CTA for its own data to be sent and DEVs that have applied for time slots.

[0078] S2-4-2: The PNC determines whether the time difference between the length of the next superframe and the maximum length threshold can support the transmission of data frames. If yes, proceed to the next step; if not, go to S2-4-5.

[0079] S2-4-3: The PNC runs the new "on-demand pre-allocation of CTAs for PNCs" mechanism to allocate CTAs for data packets destined for DEVs within the network that it will receive in the next superframe, until no more CTAs can be added in the next superframe; the pre-allocated CTAs are placed after the allocated CTAs.

[0080] S2-4-4: The PNC runs the new "CTA scheduling streamlined" mechanism to schedule the order of CTAs in the next superframe to meet the conditions for CTA streamlining. The main steps of the scheduling algorithm are as follows: SA-1: The PNC checks the first CTA pre-assigned to itself.

[0081] SA-2: PNC determines: In the CTA pre-allocated to itself, the data packet destination DEV

[0082] (It is recommended that nodes use the same address or ID at the network layer and MAC sublayer.) Has a data frame been sent to the PNC? If yes, proceed to the next step; if no, go to SA-4.

[0083] SA-3: The PNC uses the data packet destination node ID to search the "Obtain Time Slot Node Information Table" to obtain the ID of the source DEV of the data frame carrying the data packet (also the source DEV of the data packet); then, an "associated CTA triplet" is formed in the order of "CTA of the data packet source DEV sending the frame to the PNC, CTA of the data packet destination DEV sending the frame to the PNC, and pre-allocated CTA of the PNC sending the frame to the data packet destination DEV". This type of triplet is arranged starting from the first CTA in the CTAP period, and the positions of the remaining CTAs in the CTAP period are moved back in time.

[0084] SA-4: The PNC determines whether all pre-assigned CTAs have been inspected. If so, the algorithm ends. If not, the inspection target is adjusted to the next pre-assigned CTA and the process goes to SA-2.

[0085] S2-4-5: If the PNC has a CTA involving itself, it will perform the corresponding operations in the CTA: when acting as a source node, if the sector where the destination node is located is unknown, it will first perform beamforming and then transmit the data frame; if the sector where the destination node is located has been obtained in the previous CTA, it will perform beamforming according to the

[0086] The new "CTA Scheduling Simplification" mechanism uses the "Simplified CTA" type to directly send data frame transmission operations; when serving as the destination node, beamforming is first performed and then directionally receives data frames.

[0087] Then, the process waits until the current superframe ends and returns to S2-1. If the PNC does not involve its own CTA, the process directly waits until the current superframe ends and returns to S2-1.

[0088] S3: DEV Operations

[0089] S3-1: Beacon period DEV main operations

[0090] The DEV rotates the antenna and waits for receiving beacon frames in each sector in sequence. The DEV stays in each sector for a basic time slot t. If a beacon frame is received, the DEV extracts the information and stores it for future use, and stops waiting for receiving beacon frames.

[0091] S3-2: Associated CAP sub-period DEV main operations

[0092] If the DEV has not yet joined the network, it will send a network access request frame to the PNC when the PNC's antenna rotates to its sector and wait to receive the PNC's reply frame; if it receives the PNC's reply frame, it will extract the information in it and store it for future use; if it has already joined the network, it will not perform any operation in this sub-period.

[0093] S3-3: DEV main operations in regular CAP sub-period

[0094] If the DEV has a data packet to be sent that has not yet obtained a time slot, it will send a time slot request frame to the PNC when the PNC's antenna rotates to its own sector. The time slot request frame contains the ID of the destination DEV of the data packet; then it waits to receive a reply frame from the PNC; if it receives a reply frame from the PNC, it extracts the information in it and stores it for future use; if there is no data packet to be sent that has not yet obtained a time slot, no operation is performed in this sub-period.

[0095] S3-4: DEV main operations during CTAP period

[0096] If a DEV has a CTA involving itself, it performs the following operations within that CTA: If it is the source node of a data frame, it first performs beamforming and then transmits the data frame. If it is the destination node of a data frame and the PNC's sector was not known in the previous CTA, it first performs beamforming and then directionally receives the data frame. If the PNC's sector was known in the previous CTA, it uses the "reduced CTA" type according to the new "CTA scheduling reduction" mechanism and directly receives the data frame. It then waits until the end of the current superframe and returns to S3-1. If the DEV does not have a CTA involving itself, it waits until the end of the current superframe and returns to S3-1.

[0097] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions.

[0098] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0099] The above embodiments should be understood as merely illustrating the present invention and not as limiting the scope of protection of the present invention. After reading the contents of the present invention, technicians may make various changes or modifications to the present invention, and these equivalent changes and modifications also fall within the scope defined by the claims of the present invention.

Claims

1. A method for efficient directional access to a low-latency terahertz wireless local area network, wherein the terahertz wireless local area network includes two types of nodes: a PNC piconet coordinator and a DEV device, and the nodes use a directional communication mode to send and receive any frame; The network operation time is divided into multiple superframes. Each superframe consists of three ordered periods: Beacon, CAP, and CTAP. The CAP period contention access period includes the associated CAP sub-period and the regular CAP sub-period. The CTAP period channel time allocation period includes one or more CTA channel time allocation units of variable length. The characteristics are: The following steps are involved: After powering on, the node determines whether its type is PNC or DEV; During the Beacon period, the PNC broadcasts beacon frames in each sector in sequence. The beacon frames contain information about the superframe period delimitation and time slot allocation results. During the Beacon period, the DEV waits for the reception of the beacon frame in each sector in sequence; if received, it extracts the information contained therein; In the associated CAP sub-period of the CAP period, the DEV that has not yet joined the network sends a network application frame to the PNC in its own time slot, and then waits to receive a network application reply frame; If a network access application reply frame is received, the information in it is extracted and stored; in the associated CAP sub-period of the CAP period, the PNC waits in each sector in sequence to receive a network access application frame sent by a DEV that has not yet joined the network; if received, the information in it is extracted to determine whether the network access is approved, and a network access application reply frame is sent to the DEV; During the regular CAP sub-period of the CAP period, a DEV that has data to send but has not obtained a time slot sends a time slot request frame to the PNC in its own time slot. The time slot request frame contains the ID of the destination DEV of the data packet; then it waits to receive the time slot request reply frame sent by the PNC. If it receives the time slot request reply frame, it extracts the information in it and stores it; during the regular CAP sub-period of the CAP period, the PNC waits to receive the time slot request frame in each sector in turn; if it receives the time slot request frame, it determines whether to agree to allocate a time slot to the DEV that requested the time slot; regardless of whether it agrees to allocate the time slot, the PNC will reply a time slot request reply frame to the DEV that requested the time slot; if the PNC agrees to allocate the time slot to the DEV, it extracts the ID information of the source and destination DEV from the time slot request frame and stores it in the pre-established "obtained time slot node information table"; then, it extracts the data packet destination node ID from the time slot request frame and stores it in the "obtained time slot node information table"; During the CTAP period, the PNC first allocates a CTA for its own data to be sent and for the DEV that has requested a timeslot. It then determines whether the time difference between the next superframe length and the maximum length threshold can support the transmission of data frames. If so, it allocates CTAs for data packets destined for DEVs within the network that it will receive in the next superframe. This continues until no more CTAs can be added in the next superframe. Pre-allocated CTAs are placed after the allocated CTAs. If the PNC has a pre-allocated CTA, it determines whether the next superframe will have data frames sent and received in opposite directions, involving the PNC transmitting in the pre-allocated CTA. If so, it uses the data packet's destination node ID to search the "Obtain Timeslot Node Information Table" to obtain the packet's source DEV ID. Then, an "associated CTA triplet" is formed in the order of "the CTA at which the source DEV sends a frame to the PNC, the CTA at which the destination DEV sends a frame to the PNC, and the pre-assigned CTA at which the PNC sends a frame to the destination DEV." This triplet is arranged starting with the first CTA in the CTAP period, with the remaining CTAs shifted back in time. If the PNC has a CTA involving itself in the CTAP period, it performs the following operations within that CTA: as a source node, if the destination node's sector is unknown, it first performs beamforming and then transmits the data frame. If the destination node's sector is known in the previous CTA, it uses a simplified CTA scheduling mechanism that only includes the data transmission phase and directly sends the data frame. When acting as a destination node, it first performs beamforming and then waits to receive data frames. After receiving the data frames, it performs corresponding processing. During the CTAP period, if a DEV has a CTA involving itself, it will perform corresponding operations within the CTA: if it is a data frame source node, it will first perform beamforming and then send the data frame; If it is the destination node of a data frame and the sector where the PNC is located is not known in the previous CTA, it first performs beamforming and then receives the data frame; If the sector where the PNC is located has been learned in the previous CTA, a simplified CTA scheduling mechanism including only the data transmission phase is used to directly wait for receiving data frames and perform corresponding processing after receiving the data frames.

2. The method for efficient directional access to a low-latency terahertz wireless local area network according to claim 1, characterized in that: It also includes the "pre-allocation of CTAs to PNCs on demand" mechanism and the "streamlining of CTA scheduling" mechanism. The "pre-allocation of CTAs to PNCs on demand" mechanism operates in regular CAP sub-periods and CTAP periods, while the "streamlining of CTA scheduling" mechanism operates in CTAP periods.

3. The method for efficient directional access to a low-latency terahertz wireless local area network according to claim 2, characterized in that: The "pre-allocation of CTAs to PNCs on demand" mechanism specifically includes: If the PNC receives data in the next superframe and the data needs to be sent to a node in the network, and the time difference between the length of the next superframe and the maximum length threshold can support the sending of the data frame, the PNC will pre-allocate the CTA in the next superframe to itself in order to send the data received in the next superframe. CTA represents time slot resources. It is recommended that the CTA pre-allocated to the PNC be placed after the allocated CTA. In addition, the PNC needs to obtain the ID of the destination node of the data packet from the time slot application frame. The node ID is actually the MAC address of the node in the network. It is preset that each node knows the IDs of other nodes in the network. The address of the data packet also uses the node ID. The node ID uses an 8-bit or 16-bit short address format, so that the data packet sent by the DEV and destined for a node in the network can be forwarded by the PNC within the same superframe, thereby reducing the delay of the data packet.

4. The method for efficient directional access to a low-latency terahertz wireless local area network according to claim 2, wherein: The "CTA scheduling streamlining" mechanism specifically includes: When CTAs are pre-allocated to the PNC, if the data frames are sent and received in opposite directions in the next superframe, the order of the CTAs is scheduled: the CTAs are arranged in the order of the source DEV sending frames to the PNC, the destination DEV sending frames to the PNC, and the PNC sending frames to the destination DEV. The CTAs for the PNC to send frames to the destination DEV are streamlined, and no beamforming operation is performed.

Images