WO2025048116A1 - Data transmission of station in wireless lan system - Google Patents

Abstract

The technical features of the present disclosure can relate to a method performed in a wireless local area network (WLAN) system. One embodiment of the present disclosure can relate to a method performed in a WLAN system. According to the described method, a station (STA) can set a network allocation vector (NAV) on the basis of an intra basic service set (BSS) physical protocol data unit (PPDU). For example: the STA can determine whether to consider the NAV on the basis of a packet to be transmitted by the STA and whether the STA is either a transmission opportunity (TXOP) holder or a TXOP responder; and, if the STA is neither the TXOP holder nor the TXOP responder and the packet to be transmitted is related to a low latency packet, the STA may not consider the NAV.

Description

Data transmission from a station on a wireless LAN system

The present specification relates to a wireless LAN system, and more specifically, to a method and device for a station of a wireless LAN system to transmit data within a TXOP (transmission opportunity).

Wireless LAN or WLAN (wireless local area network) has been improved in various ways. For example, the EHT (Extreme high throughput) standard can use newly proposed increased bandwidth, improved PPDU (PHY layer protocol data unit) structure, improved sequence, and HARQ (Hybrid automatic repeat request) technique. The EHT standard can be called the IEEE 802.11be standard.

The EHT specification supports high throughput and high data rates, which may include wide bandwidth (e.g., 160/320 MHz), 16 streams, and/or multi-link (or multi-band) operation.

In the EHT specification, wide bandwidth (e.g., 160/240/320MHz) can be used for high throughput. In addition, preamble puncturing and multiple RU transmission can be used to efficiently use bandwidth.

WLAN systems can be further improved through the UHR (Ultra High Reliability) standard. The UHR system can be called the IEEE 802.11bn standard. The UHR system aims to support ultra-high reliability when transmitting signals to STAs. For this purpose, various technologies are being considered for the UHR system, such as high throughput, low latency, and extended range support.

In a WLAN system, communication can be initiated from an STA (station) that has acquired a TXOP. That is, in a conventional WLAN system, a TXOP holder/responder defined in a conventional standard can transmit data until the TXOP ends, and data transmission by other STAs is restricted.

In conventional WLAN systems, the TXOP holder/responder defined in the conventional standard can transmit data until the TXOP ends, and data transmission by other STAs is restricted. However, there may be cases where data/packets/signals must be transmitted quickly before the TXOP ends. In such cases, if the technical features of conventional TXOPs are used, the problem of increased data latency may occur.

This specification improves the operation of conventional TXOP and/or NAV (network allocation vector). This can solve the technical problem of not being able to transmit low latency data during the existing configured TXOP.

This specification proposes various technical features. Various technical features of this specification may be related to specific STAs (Stations), processors, instructions, etc.

For example, the technical features of the present specification may relate to a method performed in a specific STA. For example, an example of the present specification may relate to a method performed in a Wireless Local Area Network (WLAN) system. According to the above-described method, a station (STA) may set a network allocation vector (NAV) based on an intra BSS (basic service set) PPDU (Physical Protocol Data Unit). For example, based on whether the STA is one of a TXOP (transmission opportunity) holder and a TXOP responder and a packet to be transmitted by the STA, the STA may determine whether to consider the NAV. For example, if the STA is neither the TXOP holder nor the TXOP responder and the packet to be transmitted is related to a low latency packet, the STA may not consider the NAV.

The technical features described in this specification can bring about various advantageous effects. According to the conventional WLAN standard, after a TXOP is acquired, the TXOP holder/responder can transmit data within the TXOP, and data transmission by other STAs is restricted. However, there may be cases where data/packets/signals must be transmitted quickly before the TXOP ends. Even in such cases, if the technical features related to the conventional TXOP are used, the problem of increased data latency may occur.

This specification improves the operation of conventional TXOP and/or NAV. This can solve the technical problem of not being able to transmit data satisfying specific requirements during a previously set TXOP. For example, if it is possible to transmit data even during a TXOP through this specification, unnecessary delay in the transmission of low-latency data can be prevented.

Figure 1 illustrates an example of a transmitter and/or receiver device of the present specification.

Figure 2 is a conceptual diagram showing the structure of a wireless local area network (WLAN).

Figure 3 is a diagram illustrating a general link setup process.

Figure 4 illustrates one embodiment of multi-link (ML).

Figure 5 describes a PPDU transmitted/received by an STA of this specification.

Figure 6 is a diagram showing the layout of resource units (RUs) used for 20MHz PPDU.

Figure 7 is a diagram showing the layout of resource units (RUs) used for 40MHz PPDU.

Figure 8 is a diagram showing the layout of resource units (RUs) used for 80MHz PPDU.

Figure 9 shows the operation according to UL-MU.

Figure 10 shows an example of channels used/supported/defined within the 2.4 GHz band.

Figure 11 illustrates an example of channels used/supported/defined within the 5 GHz band.

Figure 12 illustrates an example of channels used/supported/defined within the 6 GHz band.

Figure 13 shows an example of a MAC frame header.

FIG. 14 illustrates a modified example of a transmitter and/or receiver of the present specification.

Figure 15 relates to operations performed in the device proposed in this specification.

Fig. 16 relates to another operation performed in the device proposed in the present specification.

Figure 17 is an example of a procedure flow diagram of this specification.

As used herein, “A or B” can mean “only A,” “only B,” or “both A and B.” In other words, as used herein, “A or B” can be interpreted as “A and/or B.” For example, as used herein, “A, B or C” can mean “only A,” “only B,” “only C,” or “any combination of A, B and C.”

As used herein, a slash (/) or a comma can mean “and/or.” For example, “A/B” can mean “A and/or B.” Accordingly, “A/B” can mean “only A,” “only B,” or “both A and B.” For example, “A, B, C” can mean “A, B, or C.”

As used herein, “at least one of A and B” can mean “only A”, “only B” or “both A and B”. Additionally, as used herein, the expressions “at least one of A or B” or “at least one of A and/or B” can be interpreted identically to “at least one of A and B”.

In addition, the parentheses used in this specification may mean “for example”. Specifically, when it is indicated as “control information (UHR-Signal field)”, the “UHR-Signal field” may be proposed as an example of the “control information”. In other words, the “control information” in this specification is not limited to the “UHR -Signal field”, and the “UHR -Signal field” may be proposed as an example of the “control information”. In addition, even when it is indicated as “control information (UHR-Signal field)”, the “UHR-Signal field” may be proposed as an example of the “control information”.

Additionally, as used herein, “a/an” can mean “at least one” or “one or more.” Additionally, a term ending with “(s)” can mean “at least one” or “one or more.”

Additionally, the expressions “based on” or “on the basis of” or “according to” as used herein mean “based at least in part on” and not “based sonly on.”

Technical features individually described in a single drawing in this specification may be implemented individually or simultaneously.

The following examples of this specification can be applied to various wireless communication systems. For example, the following examples of this specification can be applied to a wireless local area network (WLAN) system. For example, the present specification can be applied to the standards of IEEE 802.11a/g/n/ac/ax/be/bn. In addition, the examples of this specification can be applied to the UHR (Ultra High Reliability) standard or the next-generation wireless LAN standard that enhances IEEE 802.11bn. In addition, the examples of this specification can be applied to a mobile communication system. For example, the examples of this specification can be applied to a mobile communication system based on the LTE (Long Term Evolution) and its evolution based on the 3GPP (3rd Generation Partnership Project) standard.

In order to explain the technical features of this specification, the technical features to which this specification can be applied are described below.

Figure 1 illustrates an example of a transmitter and/or receiver device of the present specification.

An example of FIG. 1 can perform various technical features described below. FIG. 1 relates to at least one STA (station). For example, the STA (110, 120) of the present specification may also be called by various names such as a mobile terminal, a wireless device, a Wireless Transmit/Receive Unit (WTRU), a User Equipment (UE), a Mobile Station (MS), a Mobile Subscriber Unit, or simply a user. The STA (110, 120) of the present specification may also be called by various names such as a network, a base station, a Node-B, an Access Point (AP), a repeater, a router, and a relay. The STA (110, 120) of the present specification may also be called by various names such as a receiving apparatus, a transmitting apparatus, a receiving STA, a transmitting STA, a receiving device, and a transmitting device.

For example, STA (110, 120) may perform an AP (access point) role or a non-AP role. That is, STA (110, 120) of this specification may perform functions of AP and/or non-AP. In this specification, AP may also be indicated as AP STA.

The STA (110, 120) of this specification can support various communication standards other than the IEEE 802.11 standard. For example, it can support communication standards according to the 3GPP standard (e.g., LTE, LTE-A, 5G NR standard). In addition, the STA of this specification can be implemented as various devices such as a mobile phone, a vehicle, a personal computer, etc. In addition, the STA of this specification can support communication for various communication services such as voice call, video call, data communication, and autonomous driving (Self-Driving, Autonomous-Driving).

In this specification, STA (110, 120) may include a medium access control (MAC) and a physical layer interface for a wireless medium that follows the regulations of the IEEE 802.11 standard.

Based on the sub-drawing (a) of Fig. 1, STA (110, 120) is explained as follows.

The first STA (110) may include a processor (111), a memory (112), and a transceiver (113). The illustrated processor, memory, and transceiver may each be implemented as separate chips, or at least two blocks/functions may be implemented through one chip.

The transceiver (113) of the first STA performs signal transmission and reception operations. Specifically, it can transmit and receive IEEE 802.11 packets (e.g., IEEE 802.11a/b/g/n/ac/ax/be, etc.).

For example, the first STA (110) can perform the intended operation of the AP. For example, the processor (111) of the AP can receive a signal through the transceiver (113), process the received signal, generate a transmission signal, and perform control for signal transmission. The memory (112) of the AP can store a signal received through the transceiver (113) (i.e., a reception signal) and store a signal to be transmitted through the transceiver (i.e., a transmission signal).

For example, the second STA (120) can perform the intended operation of the Non-AP STA. For example, the transceiver (123) of the non-AP performs a signal transmission and reception operation. Specifically, it can transmit and receive IEEE 802.11 packets (e.g., IEEE 802.11a/b/g/n/ac/ax/be, etc.).

For example, the processor (121) of the Non-AP STA can receive a signal through the transceiver (123), process the received signal, generate a transmission signal, and perform control for signal transmission. The memory (122) of the Non-AP STA can store a signal received through the transceiver (123) (i.e., a reception signal) and store a signal to be transmitted through the transceiver (i.e., a transmission signal).

For example, in the specification below, the operation of a device indicated as AP may be performed in the first STA (110) or the second STA (120). For example, when the first STA (110) is an AP, the operation of the device indicated as AP may be controlled by the processor (111) of the first STA (110), and a related signal may be transmitted or received through a transceiver (113) controlled by the processor (111) of the first STA (110). In addition, control information related to the operation of the AP or a transmission/reception signal of the AP may be stored in the memory (112) of the first STA (110). In addition, when the second STA (110) is an AP, the operation of the device indicated as an AP is controlled by the processor (121) of the second STA (120), and a related signal may be transmitted or received through a transceiver (123) controlled by the processor (121) of the second STA (120). In addition, control information related to the operation of the AP or a transmission/reception signal of the AP may be stored in the memory (122) of the second STA (110).

For example, in the specification below, the operation of a device indicated as a non-AP (or User-STA) may be performed in the first STA (110) or the second STA (120). For example, if the second STA (120) is a non-AP, the operation of the device indicated as a non-AP may be controlled by the processor (121) of the second STA (120), and a related signal may be transmitted or received through the transceiver (123) controlled by the processor (121) of the second STA (120). In addition, control information related to the operation of the non-AP or the transmission/reception signal of the AP may be stored in the memory (122) of the second STA (120). For example, if the first STA (110) is a non-AP, the operation of a device indicated as a non-AP is controlled by the processor (111) of the first STA (110), and a related signal may be transmitted or received through a transceiver (113) controlled by the processor (111) of the first STA (120). In addition, control information related to the operation of the non-AP or the transmission/reception signal of the AP may be stored in the memory (112) of the first STA (110).

In the following specification, devices called (transmitting/receiving) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmitting/receiving) Terminal, (transmitting/receiving) device, (transmitting/receiving) apparatus, network, etc. may refer to the STA (110, 120) of FIG. 1. For example, devices indicated as (transmitting/receiving) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmitting/receiving) Terminal, (transmitting/receiving) device, (transmitting/receiving) apparatus, network, etc. without specific drawing symbols may also refer to the STA (110, 120) of FIG. 1. For example, in the example below, the operation of various STAs transmitting and receiving signals (e.g., PPPDUs) may be performed by the transceiver (113, 123) of Fig. 1. In addition, in the example below, the operation of various STAs generating transmission and reception signals or performing data processing or calculations in advance for transmission and reception signals may be performed by the processor (111, 121) of Fig. 1. For example, an example of an operation for generating a transmit/receive signal or performing data processing or calculation in advance for a transmit/receive signal may include: 1) an operation for determining/acquiring/configuring/computing/decoding/encoding bit information of a subfield (SIG, STF, LTF, Data) field included in a PPDU, 2) an operation for determining/configuring/acquiring time resources or frequency resources (e.g., subcarrier resources) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 3) an operation for determining/configuring/acquiring specific sequences (e.g., pilot sequences, STF/LTF sequences, extra sequences applied to SIG) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 4) a power control operation and/or a power saving operation applied to an STA, 5) an operation related to determining/acquiring/configuring/computing/decoding/encoding an ACK signal, etc. In addition, in the examples below, various information (e.g., information related to fields/subfields/control fields/parameters/power, etc.) used by various STAs for determining/acquiring/configuring/computing/decoding/encoding transmission/reception signals can be stored in the memory (112, 122) of Fig. 1.

The device/STA of the sub-drawing (a) of the above-described Fig. 1 can be modified as in the sub-drawing (b) of Fig. 1. Hereinafter, the STA (110, 120) of the present specification will be described based on the sub-drawing (b) of Fig. 1.

For example, the transceiver (113, 123) illustrated in sub-drawing (b) of FIG. 1 may perform the same function as the transceiver illustrated in sub-drawing (a) of FIG. 1 described above. For example, the processing chip (114, 124) illustrated in sub-drawing (b) of FIG. 1 may include a processor (111, 121) and a memory (112, 122). The processor (111, 121) and the memory (112, 122) illustrated in sub-drawing (b) of FIG. 1 may perform the same function as the processor (111, 121) and the memory (112, 122) illustrated in sub-drawing (a) of FIG. 1 described above.

The mobile terminal, the wireless device, the Wireless Transmit/Receive Unit (WTRU), the User Equipment (UE), the Mobile Station (MS), the Mobile Subscriber Unit, the user, the user STA, the network, the Base Station, the Node-B, the Access Point (AP), the repeater, the router, the relay, the receiving device, the transmitting device, the receiving STA, the transmitting STA, the receiving Device, the transmitting Device, the receiving Apparatus, and/or the transmitting Apparatus described below may refer to the STA (110, 120) illustrated in the sub-drawings (a)/(b) of FIG. 1, or may refer to the processing chip (114, 124) illustrated in the sub-drawing (b) of FIG. 1. That is, the technical feature of the present specification may be performed in the STA (110, 120) illustrated in the sub-drawings (a)/(b) of FIG. 1, or may be performed only in the processing chip (114, 124) illustrated in the sub-drawings (b) of FIG. 1. For example, the technical feature that the transmitting STA transmits a control signal may be understood as a technical feature that the control signal generated in the processor (111, 121) illustrated in the sub-drawings (a)/(b) of FIG. 1 is transmitted through the transceiver (113, 123) illustrated in the sub-drawings (a)/(b) of FIG. 1. Alternatively, the technical feature that the transmitting STA transmits a control signal may be understood as a technical feature that the control signal to be transmitted to the transceiver (113, 123) is generated in the processing chip (114, 124) illustrated in the sub-drawings (b) of FIG. 1.

For example, a technical feature of a receiving STA receiving a control signal may be understood as a technical feature of a control signal being received by a transceiver (113, 123) illustrated in a sub-drawing (a) of FIG. 1. Alternatively, a technical feature of a receiving STA receiving a control signal may be understood as a technical feature of a control signal received by a transceiver (113, 123) illustrated in a sub-drawing (a) of FIG. 1 being acquired by a processor (111, 121) illustrated in a sub-drawing (a) of FIG. 1. Alternatively, a technical feature of a receiving STA receiving a control signal may be understood as a technical feature of a control signal received by a transceiver (113, 123) illustrated in a sub-drawing (b) of FIG. 1 being acquired by a processing chip (114, 124) illustrated in a sub-drawing (b) of FIG.

Referring to the sub-drawing (b) of FIG. 1, software code (115, 125) may be included in the memory (112, 122). The software code (115, 125) may include instructions that control the operation of the processor (111, 121). The software code (115, 125) may be included in various programming languages.

The processor (111, 121) or the processing chip (114, 124) illustrated in FIG. 1 may include an application-specific integrated circuit (ASIC), another chipset, a logic circuit, and/or a data processing device. The processor may be an application processor (AP). For example, the processor (111, 121) or the processing chip (114, 124) illustrated in FIG. 1 may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modem (modulator and demodulator). For example, the processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may be a SNAPDRAGON® series processor manufactured by Qualcomm®, an EXYNOS® series processor manufactured by Samsung®, an A series processor manufactured by Apple®, a HELIO® series processor manufactured by MediaTek®, an ATOM® series processor manufactured by INTEL®, or a processor that enhances these.

In this specification, uplink may mean a link for communication from a non-AP STA to an AP STA, and uplink PPDU/packet/signal, etc. may be transmitted through the uplink. In addition, in this specification, downlink may mean a link for communication from an AP STA to a non-AP STA, and downlink PPDU/packet/signal, etc. may be transmitted through the downlink.

Figure 2 is a conceptual diagram showing the structure of a wireless local area network (WLAN).

The upper part of Figure 2 shows the structure of the infrastructure BSS (basic service set) of IEEE (institute of electrical and electronic engineers) 802.11.

Referring to the top of FIG. 2, the wireless LAN system may include one or more infrastructure BSS (200, 205) (hereinafter, BSS). The BSS (200, 205) is a set of APs and STAs, such as an access point (AP) 225 and a station (STA1, 200-1), which are successfully synchronized and can communicate with each other, and is not a concept referring to a specific area. The BSS (205) may include one or more STAs (205-1, 205-2) that can be associated with one AP (230).

A BSS may include at least one STA, an AP (225, 230) providing a distribution service, and a distribution system (DS, 210) connecting multiple APs.

The distributed system (210) can implement an extended service set (ESS, 240) by connecting multiple BSSs (200, 205). The ESS (240) can be used as a term to indicate a network formed by connecting one or more APs through the distributed system (210). APs included in one ESS (240) can have the same SSID (service set identification).

The portal (portal, 220) can act as a bridge to connect a wireless LAN network (IEEE 802.11) to another network (e.g., 802.X).

In a BSS such as the upper part of Fig. 2, a network between APs (225, 230) and a network between APs (225, 230) and STAs (200-1, 205-1, 205-2) can be implemented. However, it may also be possible to establish a network and perform communication between STAs without an AP (225, 230). A network that establishes a network and performs communication between STAs without an AP (225, 230) is defined as an ad-hoc network or an independent basic service set (IBSS).

The bottom of Figure 2 is a conceptual diagram showing IBSS.

Referring to the bottom of Fig. 2, IBSS is a BSS operating in ad-hoc mode. Since IBSS does not include AP, there is no centralized management entity. That is, in IBSS, STAs (250-1, 250-2, 250-3, 255-4, 255-5) are managed in a distributed manner. In IBSS, all STAs (250-1, 250-2, 250-3, 255-4, 255-5) can be mobile STAs, and access to the distributed system is not permitted, forming a self-contained network.

Figure 3 is a diagram illustrating a general link setup process.

In the illustrated S310 step, the STA may perform a network discovery operation. The network discovery operation may include a scanning operation of the STA. That is, in order for the STA to access the network, it must find a network that it can participate in. The STA must identify a compatible network before participating in the wireless network, and the process of identifying networks existing in a specific area is called scanning. There are two types of scanning methods: active scanning and passive scanning.

FIG. 3 illustrates a network discovery operation including an active scanning process as an example. In active scanning, an STA performing scanning transmits a probe request frame to search for any APs in the vicinity while moving between channels and waits for a response thereto. A responder transmits a probe response frame to an STA that transmitted the probe request frame as a response to the probe request frame. Here, the responder may be an STA that last transmitted a beacon frame in a BSS of the channel being scanned. In a BSS, an AP transmits a beacon frame, so the AP becomes the responder, and in an IBSS, STAs within an IBSS take turns transmitting beacon frames, so the responder is not constant. For example, an STA that transmits a probe request frame on channel 1 and receives a probe response frame on channel 1 can store BSS-related information included in the received probe response frame and move to the next channel (e.g., channel 2) to perform scanning (i.e., transmitting and receiving probe requests/responses on channel 2) in the same manner.

Although not shown in the example of FIG. 3, the scanning operation may also be performed in a passive scanning manner. An STA performing scanning based on passive scanning may wait for a beacon frame while moving between channels. A beacon frame is one of the management frames in IEEE 802.11, and is periodically transmitted to notify the existence of a wireless network and to enable an STA performing scanning to find a wireless network and participate in the wireless network. In a BSS, an AP periodically transmits a beacon frame, and in an IBSS, STAs in the IBSS take turns transmitting beacon frames. When an STA performing scanning receives a beacon frame, it stores information about the BSS included in the beacon frame and moves to another channel, recording beacon frame information in each channel. An STA receiving a beacon frame may store information related to the BSS included in the received beacon frame, move to the next channel, and perform scanning on the next channel in the same manner.

An STA that has discovered a network may perform an authentication process through step S320. This authentication process may be referred to as a first authentication process in order to clearly distinguish it from the security setup operation of step S340 described below. The authentication process of S320 may include a process in which the STA transmits an authentication request frame to the AP, and in response, the AP transmits an authentication response frame to the STA. The authentication frame used for the authentication request/response corresponds to a management frame.

The authentication frame may include information such as an authentication algorithm number, an authentication transaction sequence number, a status code, a challenge text, a Robust Security Network (RSN), and a Finite Cyclic Group.

The STA may transmit an authentication request frame to the AP. The AP may determine whether to allow authentication for the STA based on the information included in the received authentication request frame. The AP may provide the result of the authentication processing to the STA through an authentication response frame.

A successfully authenticated STA may perform an association process based on step S330. The association process includes a process in which the STA transmits an association request frame to the AP, and in response, the AP transmits an association response frame to the STA. For example, the association request frame may include information related to various capabilities, a beacon listen interval, a service set identifier (SSID), supported rates, supported channels, RSN, mobility domain, supported operating classes, TIM broadcast request, interworking service capabilities, and the like. For example, the association response frame may contain information related to various capabilities, status codes, Association ID (AID), supported rates, Enhanced Distributed Channel Access (EDCA) parameter sets, Received Channel Power Indicator (RCPI), Received Signal to Noise Indicator (RSNI), mobility domains, timeout interval (association comeback time), overlapping BSS scan parameters, TIM broadcast response, QoS maps, etc.

In step S340, the STA may perform a security setup process. The security setup process of step S340 may include a process of performing private key setup, for example, through 4-way handshaking via an Extensible Authentication Protocol over LAN (EAPOL) frame.

Figure 4 illustrates one embodiment of multi-link (ML).

As illustrated in FIG. 4, a plurality of multi-link devices (MLDs) can perform communication over a remote link. The MLDs can be classified into an AP MLD including a plurality of AP STAs and a non-AP MLD including a plurality of non-AP STAs. That is, the AP MLD can include affiliated APs (i.e., AP STAs), and the non-AP MLD can include affiliated STAs (i.e., non-AP STAs, or user-STAs).

A multilink may include a first link and a second link, and different channels/subchannels/frequency resources may be allocated to the first and second links. The first and second multilinks may be identified through a link ID of 4 bits in length (or other n bits in length). The first and second links may be configured in the same 2.4 GHz, 5 GHz, or 6 GHz band. Alternatively, the first link and the link may be configured in different bands.

The AP MLD of FIG. 4 includes three affiliated APs. In the example of FIG. 4, AP1 may operate in a 2.4 GHz band, AP2 may operate in a 5 GHz band, and AP3 may operate in a 6 GHz band. In the example of FIG. 4, a first link in which AP1 and non-AP1 operate may be defined by channel/subchannel/frequency resources within the 2.4 GHz band. In addition, a second link in the example of FIG. 4 in which AP2 and non-AP2 operate may be defined by channel/subchannel/frequency resources within the 5 GHz band. In addition, a third link in the example of FIG. 4 in which AP3 and non-AP3 operate may be defined by channel/subchannel/frequency resources within the 6 GHz band.

In the example of FIG. 4, AP1 can start a multilink setup procedure (ML setup procedure) by transmitting an Association Request frame to non-AP STA1. In the example of FIG. 4, non-AP STA1 can transmit an Association Response frame in response to the Association Request frame. Each AP (e.g., AP1/2/3) illustrated in FIG. 4 may be identical to the AP illustrated in FIG. 1 and/or FIG. 2, and each non-AP (e.g., non-AP1/2/3) illustrated in FIG. 4 may be identical to a STA (i.e., user-STA or non-AP STA) illustrated in FIG. 1 and/or FIG. 2.

The specific features of this specification are not limited to the specific features of Fig. 4. That is, the number of links can be variously defined, and multiple links can be variously defined within at least one band.

Figure 5 illustrates a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted/received by an STA of this specification.

The STA (e.g., AP STA, non-AP STA, AP MLD, non-AP MLD) of the present specification can transmit and/or receive the PPDU of FIG. 5. The PPDU described in the present specification can have, for example, the structure of FIG. 5. In addition, the PPDU described in the present specification can be called by various names such as UHR (Ultra High Reliability) PPDU, transmission PPDU, reception PPDU, first type or Nth type PPDU, etc. The PPDU described in the present specification can be used in a WLAN system defined according to IEEE 802.11bn and/or a next-generation WLAN system that improves IEEE 802.11bn.

The PPDU of FIG. 5 may relate to various PPDU types used in a UHR system. For example, the example of FIG. 5 may be used for at least one of a SU (single-user) mode/type/transmission, a MU (multi-user) mode/type/transmission, and a NDP (null data packet) mode/type/transmission related to channel sounding. For example, if the example of FIG. 5 relates to NDP, the Data field illustrated may be omitted. If the PPDU of FIG. 5 is used for a TB (Trigger-based) mode, the UHR-SIG of FIG. 5 may be omitted. In other words, an STA that has received a Trigger frame for UL-MU (Uplink-MU) communication may transmit a PPDU with the UHR-SIG omitted in the example of FIG. 5.

In Fig. 5, L-STF to UHR-LTF may be called a preamble or a physical preamble, and may be generated/transmitted/received/acquired/decoded in the physical layer (included in the transmitting/receiving STA).

Each block illustrated in FIG. 5 may be called a field/subfield/signal, etc. The names of these fields/subfields/signals may be, as illustrated in FIG. 5, L-STF (legacy short training field), L-LTF (legacy long training field), L-SIG (legacy signal), RL-SIG (repeated L-SIG), U-SIG (Universal Signal), UHR-SIG (UHR-signal), etc.

The subcarrier spacing of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields of FIG. 5 may be set to 312.5 kHz, and the subcarrier spacing of the UHR-STF, UHR-LTF, and Data fields may be set to 78.125 kHz. That is, the tone index (or subcarrier index) of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields may be expressed in units of 312.5 kHz, and the tone index (or subcarrier index) of the UHR-STF, UHR-LTF, and Data fields may be expressed in units of 78.125 kHz.

In the PPDU of Fig. 5, L-LTF and L-STF can be identical to conventional fields (e.g., non-HT LTF and non-HT STF defined in conventional WLAN standards).

The L-SIG field of FIG. 5 may include, for example, 24 bits of bit information. For example, the 24 bits of information may include a 4 bit Rate field, a 1 bit Reserved bit, a 12 bit Length field, a 1 bit Parity bit, and a 6 bit Tail bit. For example, the 12 bit Length field may include information about the length or time duration of the PPDU. For example, the value of the 12 bit Length field may be determined based on the type of the PPDU. For example, if the PPDU is a non-HT (non-High Throughput), HT (High Throughput), VHT (Very High Throughput) PPDU, or an EHT (extremely high throughput) PPDU, a UHR PPDU, the value of the Length field may be determined as a multiple of 3. For example, if the PPDU is a HE PPDU, the value of the Length field may be determined as "a multiple of 3 + 1" or "a multiple of 3 + 2". In other words, for non-HT, HT, VHT PPDU, EHT PPDU, UHR PPDU, the value of the Length field can be determined as a multiple of 3, and for HE (High Efficiency) PPDU, the value of the Length field can be determined as "a multiple of 3 + 1" or "a multiple of 3 + 2". In other words, the LENGTH field in an UHR PPDU is set to a value satisfying the condition that the remainder is zero when LENGTH is divided by 3.

For example, the (non-AP and AP) STA can apply BCC encoding based on a code rate of 1/2 to the 24 bits of information in the L-SIG field. Then, the transmitting STA can obtain 48 bits of BCC coding bits. BPSK modulation can be applied to the 48 bits of coding bits to generate 48 BPSK symbols. The transmitting STA can map the 48 BPSK symbols to positions excluding the pilot subcarriers {subcarrier index -21, -7, +7, +21} and the DC subcarrier {subcarrier index 0}. As a result, the 48 BPSK symbols can be mapped to subcarrier indices -26 to -22, -20 to -8, -6 to -1, +1 to +6, +8 to +20, and +22 to +26. The transmitting STA can additionally map the signal of {-1, -1, -1, 1} to the subcarrier indices {-28, -27, +27, +28}. The above signal can be used for channel estimation for the frequency domain corresponding to {-28, -27, +27, +28}.

For example, (non-AP and AP) STA can generate RL-SIG, which is generated in the same manner as L-SIG. BPSK modulation can be applied to RL-SIG. The receiving (non-AP and AP) STA can determine that the received PPDU is a HE PPDU, an EHT PPDU, or a UHR PPDU based on the presence of RL-SIG. In other words, the receiving (non-AP and AP) STA can determine that the received PPDU is one of the HE PPDU, EHT PPDU, or UHR PPDU if RL-SIG is present. In other words, the receiving (non-AP and AP) STA can determine that the received PPDU is one of the non-HT PPDU, HT PPDU, or VHT PPDU if RL-SIG is not present. In other words, the RL-SIG field is a repeat of the L-SIG field and is used to differentiate an UHR PPDU from a non-HT PPDU, HT PPDU, and VHT PPDU.

After RL-SIG in Fig. 5, U-SIG (Universal SIG) may be inserted. U-SIG may be called by various names such as first SIG field, first SIG, first type SIG, control signal, control signal field, first (type) control signal, common control field, common control signal, etc.

The U-SIG can contain N bits of information and can contain information for identifying the type of the EHT PPDU. For example, the U-SIG can be formed based on two symbols (e.g., two consecutive OFDM symbols). Each symbol (e.g., OFDM symbol) for the U-SIG can have a duration of 4 us. Each symbol of the U-SIG can be used to transmit 26 bits of information. For example, each symbol of the U-SIG can be transmitted and received based on 52 data tones and 4 pilot tones.

Through U-SIG, for example, A bit information (e.g., 52 un-coded bits) can be transmitted, and the first symbol of U-SIG can transmit the first X bits of information (e.g., 26 un-coded bits) out of the total A bit information, and the second symbol of U-SIG can transmit the remaining Y bits of information (e.g., 26 un-coded bits) out of the total A bit information. For example, the transmitting STA can obtain 26 un-coded bits included in each U-SIG symbol. The transmitting STA can perform convolutional encoding (i.e., BCC encoding) based on a rate of R=1/2 to generate 52-coded bits, and perform interleaving on the 52-coded bits. The transmitting STA can perform BPSK modulation on the interleaved 52-coded bits to generate 52 BPSK symbols allocated to each U-SIG symbol. A single U-SIG symbol can be transmitted based on 56 tones (subcarriers) from subcarrier index -28 to subcarrier index +28, excluding DC index 0. The 52 BPSK symbols generated by the transmitting STA can be transmitted based on the remaining tones (subcarriers) excluding the pilot tones -21, -7, +7, and +21.

For example, A bit information (e.g., 52 un-coded bits) transmitted by U-SIG may include a CRC field (e.g., a 4-bit long field) and a tail field (e.g., a 6-bit long field). The CRC field and the tail field may be transmitted through a second symbol of the U-SIG. The CRC field may be generated based on 26 bits allocated to the first symbol of the U-SIG and the remaining 16 bits excluding the CRC/tail field within the second symbol, and may be generated based on a conventional CRC calculation algorithm. In addition, the tail field may be used to terminate a trellis of a convolutional decoder and may be set to, for example, "000000".

A bit information (e.g., 52 uncoded bits) transmitted by U-SIG (or U-SIG field) can be divided into version-independent bits and version-dependent bits. For example, the size of version-independent bits can be fixed or variable. For example, version-independent bits can be assigned only to the first symbol of U-SIG, or version-independent bits can be assigned to both the first symbol and the second symbol of U-SIG. For example, version-independent bits and version-dependent bits can be called by various names, such as first control bit and second control bit.

For example, the version-independent bits of U-SIG may include a 3-bit PHY version identifier. For example, the 3-bit PHY version identifier may include information related to the PHY version of a transmitted/received PPDU. For example, a first value (e.g., a value of 000) of the 3-bit PHY version identifier may indicate that the transmitted/received PPDU is an EHT PPDU. Additionally, a second value (e.g., a value of 001) of the 3-bit PHY version identifier may indicate that the transmitted/received PPDU is a UHR PPDU.

In other words, when the (AP/non-AP) STA transmits an EHT PPDU, the 3-bit PHY version identifier can be set to the first value. In other words, the receiving (AP/non-AP) STA can determine that the received PPDU is an EHT PPDU based on the PHY version identifier having the first value, and can determine that the received PPDU is a UHR PPDU based on the PHY version identifier having the second value.

For example, the version-independent bits of U-SIG may include a 1-bit UL/DL flag field. The first value of the 1-bit UL/DL flag field relates to UL communication, and the second value of the UL/DL flag field relates to DL communication.

For example, the version-independent bits of U-SIG may include information about the length of the TXOP and information about the BSS color ID.

For example, if a UHR PPDU is classified into various types (e.g., type related to SU transmission (performed based on UL or DL), type related to DL transmission, type related to NDP transmission, type related to DL non-MU-MIMO, type related to DL MU-MIMO, type related to Multi-AP operation, type related to CBF (Coordinated beamforming), SR (Spatial Reuse), type related to C-OFDMA (Coordinated OFDMA), type related to C-TDMA (Coordinated TDMA)), information about the type of the EHT PPDU (e.g., 2-bit or 3-bit information) can be included in the version-dependent bits of the U-SIG.

For example, U-SIG may include 1) a bandwidth field including information about bandwidth, 2) a field including information about a Modulation and Coding Scheme (MCS) technique applied to UHR-SIG, 3) an indication field including information about whether a dual subcarrier modulation (DCM) technique is applied to UHR-SIG, 4) a field including information about the number of symbols used for UHR-SIG, 5) a field including information about whether UHR-SIG is generated over the full band, 6) a field including information about the type of UHR-LTF/STF, and 7) a field indicating the length of UHR-LTF and the CP length.

Preamble puncturing can be applied to the PPDU of FIG. 5. Preamble puncturing means applying puncturing to a portion of the entire band of the PPDU (e.g., the secondary 20 MHz band). For example, when an 80 MHz PPDU is transmitted, the STA can apply puncturing to the secondary 20 MHz band among the 80 MHz band, and transmit the PPDU only through the primary 20 MHz band and the secondary 40 MHz band.

For example, the pattern of preamble puncturing can be set in advance. For example, when the first puncturing pattern is applied, puncturing can be applied only to a secondary 20 MHz band within an 80 MHz band. For example, when the second puncturing pattern is applied, puncturing can be applied only to one of two secondary 20 MHz bands included in a secondary 40 MHz band within an 80 MHz band. For example, when the third puncturing pattern is applied, puncturing can be applied only to a secondary 20 MHz band included in a primary 80 MHz band within a 160 MHz band (or 80+80 MHz band). For example, when the fourth puncturing pattern is applied, a primary 40 MHz band included in the primary 80 MHz band within the 160 MHz band (or 80+80 MHz band) is present, and puncturing can be applied to at least one 20 MHz channel that does not belong to the primary 40 MHz band.

Information about preamble puncturing applied to the PPDU may be included in the U-SIG and/or UHR-SIG. For example, a first field of the U-SIG may include information about a contiguous bandwidth of the PPDU, and a second field of the U-SIG may include information about preamble puncturing applied to the PPDU.

For example, U-SIG and UHR-SIG may include information regarding preamble puncturing based on the following method. If the bandwidth of the PPDU exceeds 80 MHz, U-SIGs may be individually configured in units of 80 MHz. For example, if the bandwidth of the PPDU is 160 MHz, the PPDU may include a first U-SIG for a first 80 MHz band and a second U-SIG for a second 80 MHz band. In this case, the first field of the first U-SIG may include information regarding the 160 MHz bandwidth, and the second field of the first U-SIG may include information regarding preamble puncturing applied to the first 80 MHz band (i.e., information regarding a preamble puncturing pattern). Additionally, the first field of the second U-SIG may include information about a 160 MHz bandwidth, and the second field of the second U-SIG may include information about preamble puncturing applied to the second 80 MHz band (i.e., information about a preamble puncturing pattern). Meanwhile, the UHR-SIG continuous to the first U-SIG may include information about preamble puncturing applied to the second 80 MHz band (i.e., information about a preamble puncturing pattern), and the UHR-SIG continuous to the second U-SIG may include information about preamble puncturing applied to the first 80 MHz band (i.e., information about a preamble puncturing pattern).

Additionally or alternatively, U-SIG and UHR-SIG may include information about preamble puncturing based on the following methods. U-SIG may include information about preamble puncturing for all bands (i.e., information about preamble puncturing pattern). That is, UHR-SIG does not include information about preamble puncturing, and only U-SIG may include information about preamble puncturing (i.e., information about preamble puncturing pattern).

U-SIG can be configured in 20 MHz units. For example, if an 80 MHz PPDU is configured, U-SIG can be duplicated. That is, four identical U-SIGs can be included in an 80 MHz PPDU. PPDUs exceeding 80 MHz bandwidth can contain different U-SIGs.

The UHR-SIG of FIG. 5 may include control information for a receiving STA. The UHR-SIG may be transmitted through at least one symbol, and one symbol may have a length of 4 us. Information about the number of symbols used for the UHR-SIG may be included in the U-SIG.

UHR-SIG provides additional signals to the U-SIG field to enable STAs to interpret/decode UHR PPDUs. The UHR-SIG field may contain U-SIG overflow bits that are common to all users. The UHR-SIG field also contains resource allocation information, allowing STAs to look up resources used in fields containing data fields/UHR-STF/UHR-LTF (i.e., UHR modulated fields of an UHR PPDU).

The frequency resources of the UHR-LTF, UHR-STF, and data fields illustrated in Fig. 5 can be determined based on RUs (resource units) defined by multiple subcarriers/tones. That is, the UHR-LTF, UHR-STF, and data fields of this specification can be transmitted/received through RUs (resource units) defined by multiple subcarriers/tones.

FIG. 6 is a diagram showing the layout of resource units (RUs) used for a 20 MHz PPDU. That is, UHR-LTF, UHR-STF and/or data fields included in a 20 MHz PPDU can be transmitted/received through at least one of various RUs defined in FIG. 6.

As shown in the top of Fig. 6, 26 units (i.e., units corresponding to 26 tones) can be arranged. Six tones can be used as a guard band in the leftmost band of the 20MHz band, and five tones can be used as a guard band in the rightmost band of the 20MHz band. In addition, seven DC tones can be inserted in the center band, i.e., the DC band, and 26 units corresponding to 13 tones can exist on the left and right sides of the DC band, respectively. In addition, 26 units, 52 units, and 106 units can be allocated to other bands. Each unit can be allocated for a receiving station, i.e., a user.

Meanwhile, the RU arrangement of Fig. 6 is utilized not only in a situation for multiple users (MUs) but also in a situation for a single user (SU), in which case it is possible to use one 242-unit as shown at the bottom of Fig. 4, in which case three DC tones can be inserted.

In the example of Fig. 6, RUs of various sizes, i.e., 26-RU, 52-RU, 106-RU, 242-RU, etc., are proposed, and since the specific sizes of these RUs can be expanded or increased, the present embodiment is not limited to the specific size of each RU (i.e., the number of corresponding tones). In this specification, N-RU may be represented as N-tone RU, etc. For example, 26-RU may be represented as 26-tone RU.

Figure 7 is a diagram showing the layout of resource units (RUs) used for 40MHz PPDU.

As in the example of FIG. 6 where RUs of various sizes were used, the example of FIG. 7 can also use 26-RU, 52-RU, 106-RU, 242-RU, 484-RU, etc. In addition, 5 DC tones can be inserted at the center frequency, 12 tones can be used as a guard band in the leftmost band of the 40 MHz band, and 11 tones can be used as a guard band in the rightmost band of the 40 MHz band.

Also, as illustrated, 484-RU can be used when used for a single user. Meanwhile, the specific number of RUs can be changed, which is the same as the example in Fig. 6.

Figure 8 is a diagram showing the layout of resource units (RUs) used for 80MHz PPDU. The layout of resource units (RUs) used in this specification may be changed in various ways. For example, the layout of resource units (RUs) used on an 80MHz band may be changed in various ways.

Fig. 9 shows an operation according to UL-MU. As illustrated, a transmitting STA (e.g., AP) can obtain a TXOP (925) by performing channel access through contending (i.e., Backoff operation) and transmit a Trigger frame (930). That is, the transmitting STA (e.g., AP) can transmit a PPDU including a Trigger Frame (930). When a PPDU including a Trigger frame is received, a TB (trigger-based) PPDU is transmitted after a delay of SIFS.

TB PPDU (941, 942) can be transmitted at the same time zone and can be transmitted from multiple STAs (e.g., User STAs) whose AIDs are indicated in the Trigger frame (930). The ACK frame (950) for TB PPDU can be implemented in various forms. For example, the ACK frame (950) for TB PPDU can be implemented in the form of BA (block ACK).

In FIG. 9, transmission(s) of Trigger Frame (930), TB PPDU (941, 942) and/or ACK frame (950) can be performed within TXOP (925).

Figure 10 shows an example of channels used/supported/defined within the 2.4 GHz band.

The 2.4 GHz band may be referred to by other names, such as the first band (band), etc. In addition, the 2.4 GHz band may refer to a frequency range in which channels with center frequencies adjacent to 2.4 GHz (e.g., channels with center frequencies located within 2.4 to 2.5 GHz) are used/supported/defined.

A 2.4 GHz band may include multiple 20 MHz channels. The 20 MHz within the 2.4 GHz band may have multiple channel indices (e.g., indices 1 to 14). For example, a 20 MHz channel to which channel index 1 is assigned may have a center frequency of 2.412 GHz, a 20 MHz channel to which channel index 2 is assigned may have a center frequency of 2.417 GHz, and a 20 MHz channel to which channel index N is assigned may have a center frequency of (2.407 + 0.005*N) GHz. The channel indices may be referred to by various names, such as channel numbers. The specific numerical values of the channel indices and center frequencies may change.

FIG. 10 exemplarily shows four channels within a 2.4 GHz band. The illustrated first frequency domain (1010) to fourth frequency domain (1040) may each include one channel. For example, the first frequency domain (1010) may include channel 1 (a 20 MHz channel having an index of 1). In this case, the center frequency of channel 1 may be set to 2412 MHz. The second frequency domain (1020) may include channel 6. In this case, the center frequency of channel 6 may be set to 2437 MHz. The third frequency domain (1030) may include channel 11. In this case, the center frequency of channel 11 may be set to 2462 MHz. The fourth frequency domain (1040) may include channel 14. In this case, the center frequency of channel 14 may be set to 2484 MHz.

Figure 11 illustrates an example of channels used/supported/defined within the 5 GHz band.

The 5 GHz band may be referred to by other names such as second band/band, etc. The 5 GHz band may refer to a frequency range in which channels having a center frequency of 5 GHz or more but less than 6 GHz (or less than 5.9 GHz) are used/supported/defined. Alternatively, the 5 GHz band may include multiple channels between 4.5 GHz and 5.5 GHz. The specific figures shown in FIG. 11 may be subject to change.

Multiple channels within the 5 GHz band include Unlicensed National Information Infrastructure (UNII)-1, UNII-2, UNII-3, and ISM. UNII-1 may be referred to as UNII Low. UNII-2 may include frequency ranges referred to as UNII Mid and UNII-2Extended. UNII-3 may be referred to as UNII-Upper.

Within the 5 GHz band, multiple channels can be set, and the bandwidth of each channel can be variously set to 20 MHz, 40 MHz, 80 MHz, or 160 MHz. For example, the 5170 MHz to 5330 MHz frequency domain/range within UNII-1 and UNII-2 can be divided into eight 20 MHz channels. The 5170 MHz to 5330 MHz frequency domain/range can be divided into four channels through a 40 MHz frequency domain. The 5170 MHz to 5330 MHz frequency domain/range can be divided into two channels through an 80 MHz frequency domain. Alternatively, the 5170 MHz to 5330 MHz frequency domain/range can be divided into one channel through a 160 MHz frequency domain.

Figure 12 illustrates an example of channels used/supported/defined within the 6 GHz band.

The 6 GHz band may be referred to by other names such as the third band/band, etc. The 6 GHz band may refer to a frequency range in which channels with center frequencies higher than 5.9 GHz are used/supported/defined. The specific figures shown in Fig. 12 may be subject to change.

For example, the 20 MHz channel of Fig. 12 can be defined from 5.940 GHz. Specifically, the leftmost channel among the 20 MHz channels of Fig. 12 can have an index of 1 (or channel index, channel number, etc.), and a center frequency of 5.945 GHz can be assigned. That is, the center frequency of the index N channel can be determined as (5.940 + 0.005*N) GHz.

Accordingly, the indices (or channel numbers) of the 20 MHz channels of FIG. 12 are 1, 5, 9, 13, 17, 21, 25, 29, 33, 37, 41, 45, 49, 53, 57, 61, 65, 69, 73, 77, 81, 85, 89, 93, 97, 101, 105, 109, 113, 117, 121, 125, 129, 133, 137, 141, 145, 149, 153, 157, 161, 165, 169, 173, 177, 181, 185, 189, 193, It can be 197, 201, 205, 209, 213, 217, 221, 225, 229, 233. Also, according to the above-mentioned (5.940 + 0.005*N) GHz rule, the indices of the 40 MHz channel in Fig. 12 can be 3, 11, 19, 27, 35, 43, 51, 59, 67, 75, 83, 91, 99, 107, 115, 123, 131, 139, 147, 155, 163, 171, 179, 187, 195, 203, 211, 219, 227.

Below, the structure and types/subtypes of MAC frames are described.

Fig. 13 shows an example of a header of a MAC frame. As illustrated, the MAC frame may include a frame control field/information of 2 octets in length, a duration field/information of 2 octets in length, a RA (Receiver Address) field/information of 6 octets in length, and a TA (Transmitter Address) field/information of 6 octets in length. As illustrated in Fig. 13, the four fields may be consecutive to each other. The MAC header of Fig. 13 may be modified in various ways, and a new field may be inserted between the four illustrated fields, or at least one of the illustrated fields may be omitted.

The MAC header illustrated in Fig. 13 may be located at the very front of the MAC frame. That is, the MAC frame may include a MAC header as illustrated in Fig. 13 and MAC body fields/information consecutive to the MAC header. The MAC frame including the MAC header of Fig. 13 is inserted/included in the data field of the PPDU (e.g., UHR PPDU) illustrated in Fig. 5.

The MAC frames included in the data field of the PPDU of this specification can be classified into various types. For example, the MAC frames of this specification can be classified into a control frame, a management frame, and a data frame.

For example, the management frame includes Association Request, Association Response, Reassociation Request, Reassociation Response, Probe Request, Probe Response, Beacon, Disassociation, Authentication, and Deauthentication frames/signals defined in conventional WLAN. For the management frame, the values of the type fields (B3 and B2) of FIG. 13 are set to 00. In addition, the values of the subtype fields (B7, B6, B5, B4) of FIG. 13 are as follows: Association Request (0000), Association Response (0001), Reassociation Request (0010), Reassociation Response (0011), Probe Request (0100), Probe Response (0101), Beacon (1000), Disassociation (1010), Authentication (1011), Deauthentication (1100).

For example, the control frame includes Trigger Beamforming Report Poll, NDP Announcement (NDPA), Control Frame Extension, Control Wrapper, Block Ack Request (BlockAckReq), Block Ack (BlockAck), PS-Poll, RTS, CTS, Ack, CF-End frames/signals defined in conventional WLAN. For the control frame, the values of the type fields (B3 and B2) in Fig. 13 are set to 01. Also, the values of the subtype fields (B7, B6, B5, B4) in Fig. 13 are as follows: Trigger (0010), Beamforming Report Poll (0100), NDP Announcement (0101), Control Frame Extension (0110), Control Wrapper (0111), BlockAckReq (1000), BlockAck (1001), PS-Poll (1010), RTS (1011), CTS (1100), Ack (1101), CF-End (1110).

For example, the data frame includes (QoS) Data, (QoS) Null, etc. defined in conventional WLAN. For the management frame, the value of the type field (B3 and B2) of Fig. 13 is set to 10.

The MAC frame/signal used in this specification can be identified through the type field/information and subtype field/information described above. For example, the “trigger frame” in this specification can mean a MAC frame in which the type bits B3 and B2 bits in the frame control field of the MAC header are set to 01, and the subtype bits B7, B6, B5, B4 bits in the frame control field are set to 0010. Various MAC frames described in this specification are inserted/included in the data fields of various PPDUs (e.g., HE/VHT/HE/EHT/UHR PPDUs).

FIG. 14 illustrates a modified example of a transmitter and/or receiver of the present specification.

The devices (e.g., AP STA, non-AP STA) illustrated in FIGS. 1 to 4 may be modified as illustrated in FIG. 14. The transceiver (630) of FIG. 14 may be identical to the transceiver (113, 123) of FIG. 1. The transceiver (630) of FIG. 14 may include a receiver and a transmitter.

The processor (610) of FIG. 14 may be identical to the processor (111, 121) of FIG. 1. Alternatively, the processor (610) of FIG. 14 may be identical to the processing chip (114, 124) of FIG. 1.

The memory (150) of Fig. 14 may be the same as the memory (112, 122) of Fig. 1. Alternatively, the memory (150) of Fig. 14 may be a separate external memory different from the memory (112, 122) of Fig. 1.

Referring to FIG. 14, the power management module (611) manages power for the processor (610) and/or the transceiver (630). The battery (612) supplies power to the power management module (611). The display (613) outputs results processed by the processor (610). The keypad (614) receives input to be used by the processor (610). The keypad (614) may be displayed on the display (613). The SIM card (615) may be an integrated circuit used to securely store an international mobile subscriber identity (IMSI) and an associated key used to identify and authenticate a subscriber in a mobile phone device, such as a mobile phone and a computer.

Referring to FIG. 14, the speaker (640) can output sound-related results processed by the processor (610). The microphone (641) can receive sound-related input to be used by the processor (610).

The technical features of this specification are described in more detail below.

The maximum Duration of a PPDU based on HT/VHT/HE/EHT/UHR can be up to 5.484ms. For example, in the IEEE 802.11 standard, the maximum duration of a PPDU can be determined based on a parameter called aPPDUmaxtime.

This specification may relate to a new type/format/category of PPDU which improves the conventional PPDU. For example, the new type/format/category of PPDU related to the operation of this specification may be called by various names. For example, the PPDU related to the operation of this specification may be used by various names such as Small PPDU, Short PPDU, Low latency PPDU, TX PPDU, RX PPDU, 1st/2nd PPDU, etc. In the following, the name Small PPDU is used for convenience of explanation, but the technical features of this specification are not limited to this name Small PPDU.

The small PPDU related to the present specification may have a maximum duration set shorter than that of a conventional PPDU. Additionally or alternatively, the small PPDU may have the same aPPDUmaxtime parameter as that of a conventional PPDU, but its duration may be set shorter than that of a conventional PPDU based on a parameter/field/subfield newly defined in the WIFI standard or a conventional parameter/field/subfield. Additionally or alternatively, the small PPDU may be a PPDU that does not include a Low latency PPDU. For example, the Low latency PPDU may be a PPDU that carries Low latency traffic. The Low latency traffic may be identified based on at least one of QoS/AC (Access category)/TID (Traffic ID)/Delay/latency assigned to the corresponding traffic. Additionally or alternatively, the small PPDU may mean a set of a plurality of PPDUs for which immediate ACK is not required and delayed ACK is allowed. Additionally or alternatively, the small PPDU may mean a PPDU configured based on a new structured preamble presented in the present specification (for example, a preamble in which the Legacy preamble is omitted as described below, or a preamble including only HE/EHT/UHR-LTF, or a preamble including only HE/EHT/UHR-STF and HE/EHT/UHR-LTF). The small PPDU of the present specification may include a preamble and a data field consecutive to the preamble, and the data field may include a PSDU (Physical Service Data Unit). The small PPDU related to the present specification may be distinguished from a conventional PPDU based on at least one criterion/definition presented above. Conventional PPDUs, which are distinct from the newly proposed PPDUs in this specification (e.g., small PPDUs), may be called by various names. For example, various names such as long/large/legacy/HT/VHT/HE/EHT/UHR-PPDU may be used.

Additionally or alternatively, the small PPDU may be determined independently of the length of the duration of the PPDU. For example, whether it is a small PPDU may be determined based on the physical version of the PPDU, or whether it is a small PPDU may be determined based on the type of the PPDU. In this case, information about the type of the PPDU may be included in the U-SIG field of the PPDU, and/or the EHT/UHR-SIG field.

Figure 15 relates to operations performed in the device proposed in this specification.

The illustrated TXOP holder (1500) acquires a TXOP. The method of acquiring the TXOP may be based on a method of exchanging an RTS frame and a CTS frame according to a conventional wireless LAN standard, or may be based on transmitting a conventional CTS-to-self frame, or may be based on a conventional TWT (target wake time) setting. That is, the definition of the TXOP holder of the present specification may be the same as that of the conventional wireless LAN standard. In addition, in the example of FIG. 15, STA1 (1501) may be a TXOP responder. That is, the definition of the TXOP responder of the present specification may be the same as that of the conventional wireless LAN standard. For example, the TXOP responder (e.g., STA1 (1501)) of the present specification may mean an STA that can receive a response frame for a frame received from a TXOP holder during a frame exchange sequence, but does not acquire a TXOP in a related processor. The above TXOP holder can be a non-AP, an AP, and the TXOP responder can be an AP, a non-AP. An example of Fig. 15 is a case where the TXOP holder is an AP, and accordingly, the TXOP obtained in Fig. 15 can be expressed by various names such as DL-TXOP.

For example, Small PPDUs may be transmitted sequentially within one TXOP according to an example of FIG. 15. However, other PPDUs, such as Low Latency (LL) PPDUs or responses thereto (e.g., ACK/Block ACK), may be transmitted and received between small PPDUs. Specifically, as illustrated in FIG. 15, an LL PPDU (1540) and an ACK/BA (1550) for the corresponding LL PPDU may be transmitted and received between multiple small PPDUs (1510, 1520, 1560). A signal referred to as LL PPDU in this specification may include not only an LL PPDU but also a response (e.g., Ack/BA) to the LL PPDU.

The example of FIG. 15 relates to an example in which an LL PPDU is transmitted to a third STA (i.e., STA2 (1520)) that is not a TXOP responder or TXOP holder via downlink. That is, the example relates to an example in which a transmitting transmitting STA (e.g., TXOP holder (1500)) preempts an on-going transmission within an already acquired TXOP and transmits an LL PPDU via downlink. That is, the example of FIG. 15 relates to an example in which DL-preemption is applied in a situation in which a DL-TXOP is acquired. In case of transmitting an LL PPDU (1540) via downlink based on DL-preemption as in FIG. 15, it may be difficult for STA2 (1502) to transmit a response (1550) to the LL PPDU (1540) because it is not a TXOP responder. That is, the TXOP holder (1500) In the process of acquiring DL-TXOP, various frames (e.g., RTS/CTS/CTS-to-self frame, intra-BSS frame/PPDU, etc.) may be transmitted to STA2 (1502), and STA2 (1502) may set NAV (e.g., intra-BSS NAV) due to the received frame. As a result, STA2 (1502) may not transmit LL-PPDU and/or its response during the already acquired TXOP. This technical feature can be solved by various technical features proposed in this specification.

For example, if the TXOP holder (1500) transmits an LL PPDU at any point in time, the TXOP holder can transmit the LL PPDU after xIFS (e.g., after SIFS has elapsed) of the PPDU (e.g., small PPDU (1520)) transmitted by the TXOP holder. For example, an STA other than the TXOP holder (e.g., an STA that is neither a TXOP holder nor a TXOP responder) may require permission from the TXOP holder to transmit an LL PPDU (or its response). Here, permission from the TXOP holder may include signaling such as an indication from the TXOP holder that it may use frequency resources within the corresponding TXOP and/or allocation of frequency resources. For example, to allow LL PPDU transmission (including transmission of ACK/BA for LL PPDU) of an STA that is not a TXOP holder (e.g., STA2 (1502) that is neither a TXOP holder nor a TXOP responder), it can be indicated in each Small PPDU whether transmission and reception of the LL PPDU is allowed or not after xIFS (e.g., after SIFS has elapsed) after the end of transmission of the corresponding Small PPDU.

For example, the U-SIG (and/or UHR-SIG) of at least one Small PPDU (or all Small PPDUs) may include a Preemption flag (PF) subfield. For example, the PF subfield may have a length of 1 bit. For example, if the value of the PF subfield is the first value (e.g., 0), Preemption may not be allowed as in the conventional manner. That is, an STA (e.g., STA2 (1502)) that is neither a TXOP holder nor a TXOP responder cannot transmit an LL PPDU (e.g., including an ACK/BA for the LL PPDU) during the previously acquired TXOP. For example, if the value of the PF subfield is the second value (e.g., 0), Preemption may be allowed. For example, an STA that is neither a TXOP holder nor a TXOP responder (e.g., STA2 (1502)) can transmit an LL PPDU (e.g., including an ACK/BA for the LL PPDU) during the previously acquired TXOP.

The technical features described above are not limited to the example of FIG. 15. In addition, the example of FIG. 15 can be modified in various ways. The example of FIG. 15 is a situation in which an LL PPDU is transmitted to a third STA other than a TX-holder/responder through a downlink in a DL-TXOP, that is, a situation in which DL-TXOP and DL-preemption are applied. The technical features described above can be applied to a situation in which DL-TXOP and UL-preemption are applied, a situation in which UL-TXOP and DL-preemption are applied, and a situation in which UL-TXOP and UL-preemption are applied. The situation in which DL-TXOP and UL-preemption are applied can be related to the example of FIG. 16. A situation in which UL-TXOP and DL-preemption are applied may be a situation in which a non-AP operates as a TXOP holder and an AP operates as a TXOP responder, and the AP transmits an LL PPDU to a third-party STA (i.e., a STA that is not a TXOP holder/responder) through downlink. A situation in which UL-TXOP and UL-preemption are applied may be a situation in which a non-AP operates as a TXOP holder and an AP operates as a TXOP responder, and a third-party STA (i.e., a STA that is not a TXOP holder/responder) transmits an LL PPDU to the AP through uplink.

Fig. 16 relates to another operation performed in the device proposed in the present specification. As described above, the example of Fig. 16 can be expressed as a situation in which DL-TXOP and UL-preemption are applied. In the example of Fig. 16, similar to Fig. 15, the situation is that at least one small PPDU and LL PPDU are exchanged in a situation in which one DL-TXOP (not shown) is acquired by a TXOP holder (1600).

As illustrated, a third STA (e.g., STA2 (1602)) that is not a TXOP holder/responder can receive Small PPDUs (1610 and/or 1620) with PF=1. STA2 (1602) may, for example, have a PF subfield of U-SIG (and/or UHR-SIG) included in the Small PPDUs (1610 and/or 1620) have a preset value (e.g., “1”), and the value of the corresponding PF subfield may mean that DL-preemption is allowed, as in the example of FIG. 15. Accordingly, STA2 (1602) may transmit a Tx request frame (1640) after xIFS (e.g., SIFS) has elapsed from the Small PPDU (1620). The above TX request frame (1640) is a frame used to request transmission of an LL PPDU (or a PPDU that satisfies a specific condition or transmits traffic related to a specific QoS/AC(Access category)/TID(Traffic ID)/Delay/latency) of a third-party STA other than the TXOP holder/responder, and can be defined in various ways and called by various names. For example, the TX request frame (1640) can be transmitted to a TXOP holder.

As described above, the Tx request frame (1640) can be transmitted for the permission of an STA having data to transmit (or data to transmit that satisfies a specific condition). For example, the Tx request frame (1640) can mean a frame that notifies the TXOP holder (1600) of a request to transmit low latency traffic, as shown in FIG. 16. As described above, the Tx request frame (1640) can be defined in various ways. For example, the Tx request frame (1640) can include part/all of the structure of a conventional CTS frame. That is, the TX request frame (1640) can be defined as a frame transmitted in response to a conventional RTS frame, and can be defined as a control frame in the same manner as a conventional CTS frame. In addition, the TX request frame (1640) may include a 2-octet frame control field, a duration field (2 octets long) continuous to the field, and a RA (receiver address) field (6 octets long) continuous to the field, and the RA field may be set to a value of a TA (transmitter address) field of the RTS frame. In addition or alternatively, the Tx request frame (1640) may include a newly defined frame structure. In addition or alternatively, the Tx request frame (1640) may be transmitted based on a SFN (single frequency network) in the same way as a conventional CTS frame.

In response to the above Tx request frame (1640), the TXOP holder (1600) can transmit an indication. An example of the indication may be the polling (1650) illustrated in FIG. 16. Additionally, alternatively, an example of the indication may be a trigger frame of a conventional wireless LAN standard. In addition, an example of the indication may include sequential transmission of an NFRP (NDP feedback report poll), an NFR (NDP feedback report), and a Trigger frame of a conventional wireless LAN standard.

When the indication is received from the TXOP holder (1600), a third STA (e.g., STA2 (1602)) that is not the TXOP holder/responder can transmit an LL PPDU (1660).

Between each PPDU/frame mentioned in Fig. 15/16, there is an xIFS defined in the wireless LAN standard. For example, an example of xIFS may be SIFS/PIFS defined in the wireless LAN standard. The IFS between each PPDU/frame may be set to different values depending on the situation and PPDU type. In addition, in the example of Fig. 15/16, the TXOP holder is AP, but as described above, the technical features of this specification may also be applied to UL-TXOP.

The technical features of the present specification relate to a technique for setting (or updating) NAV in an STA (e.g., an AP and/or a non-AP). As described above, a specific STA (e.g., a third-party STA that is not a TXOP holder/responder) can receive various frames (e.g., intra-BSS PPDU, RTS frame, CTS frame, CTS-to-self frame/PPDU) used in a DL-TXOP and/or UL-TXOP acquisition process, and set (or update) NAV (e.g., intra-BSS NAV). Such STA may not transmit specific packets (e.g., LL-PPDU described above, or PPDU carrying traffic satisfying specific conditions or related to specific QoS/AC(Access category)/TID(Traffic ID)/Delay/latency) due to the set/updated NAV during the DL-TXOP and/or UL-TXOP. In order to solve the problem of not being able to transmit the above-described packet, a NAV setting/update technique performed in an STA when preemption is allowed within the DL/UL-TXOP (for example, when the LL-PPDU, etc. can be transmitted by the third STA) is proposed in the following example. In addition, a NAV setting/update technique performed in an STA that has received a small PPDU allowing the above-described preemption (for example, a small PPDU including the PF subfield) is proposed in the following example.

The existing behavior within a TXOP (e.g., UL/DL-TXOP) is as follows: i.e., the behavior of an STA within a TXOP where preemption is not allowed, and/or the behavior of an STA that receives a small PPDU that does not include signaling allowing preemption is described below.

Technical Features-1A.

First, the existing operation of the TXOP holder can be as follows.

A TXOP holder can transmit a PPDU (without contention within the TXOP it has acquired), and can indicate information about the length (or duration) of the TXOP and the length (or duration) of the PPDU through the PPDU. For example, the length of the PPDU can be indicated through the Length information (e.g., conventional 12-bit length information) of the L-SIG field included in the PPDU. For example, the remaining length (or duration) of the TXOP can be roughly indicated through the control bit of the U-SIG field included in the PPDU. (For example, if the remaining duration of the TXOP is less than 512 μs, the remaining duration can be indicated in units of 4 μs, and if the remaining duration of the TXOP is 512 μs or more, the remaining duration can be indicated in units of 64 μs). For example, the Duration field of the MAC header can indicate the remaining TXOP duration in units of μs.

Technical Features-1B.

Second, the existing behavior of the TXOP responder could be as follows:

A TXOP responder can receive and decode a PPDU, and if it contains its own STA-ID (e.g., included in EHT/UHR-SIG) and/or Address (e.g., included in MAC header), it can receive data assigned to it. After the corresponding PPDU is finished, it can prepare to receive PPDU again. Here, preparation for reception can include energy detection, preamble detection, and decoding.

Technical features-1C.

Third, the existing behavior of a third STA that is not a TXOP holder/responder may be as follows:

Third-party STAs (e.g., BSS/OBSS STAs) that are not TXOP holders and responders set NAVs for the corresponding TXOP. For example, transmission may not be performed during the time corresponding to the corresponding NAV, and only PPDU reception may be performed. The NAV may be an intra-BSS NAV or a basic NAV.

Below, TXOP/small PPDU where preemption is allowed is described. Below, the operation of TXOP holder, TXOP responder, and a third STA that is not a TXOP holder/responder are described individually.

Technical Features-2A.

Below, the technical characteristics of a TXOP holder within a TXOP where preemption is allowed (or for a small PPDU where preemption is allowed) are described.

The TXOP holder performs the same operation as described in the “Technical Feature-1A” described above. However, after a Small PPDU with Preemption allowed is transmitted and received, the TXOP holder’s PPDU may be transmitted, but the TXOP holder must recognize that the Tx request frame described above may be received from STAs. For example, it is possible to prepare for reception considering that a Tx request frame may be received from STAs after SIFS elapsed from the Small PPDU, and to transmit the TXOP holder’s PPDU after PIFS elapsed if the frame is not received.

Technical Features-2B.

Below, the technical features of a TXOP responder within a TXOP where preemption is allowed (or for a small PPDU where preemption is allowed) are described.

The TXOP responder performs the same operations as those described in the “Technical Feature-1B” described above. However, after a Small PPDU for which Preemption is allowed, the Tx request frame described above may be transmitted to request transmission of the PPDU of the TXOP responder as well as reception of the next PPDU. For example, the Tx request frame described above may be transmitted after SIFS has elapsed from the Small PPDU, and if there is no Tx request frame to be transmitted, the PPDU may be prepared for reception after PIFS has elapsed.

Technical features-2C.

Below, the technical characteristics are described for a third-party STA (e.g., BSS STA and/or OBSS STA) that is not a TXOP holder/responder within a TXOP where preemption is allowed (or for a small PPDU where preemption is allowed).

Below we propose several examples of ignoring NAV in STA in various ways.

As a first example of ignoring NAV, a BSS STA that is not a TXOP holder/responder may not perform NAV setting/update after receiving a Small PPDU with preemption allowed (e.g., a small PPDU including a U-SIG including the PF subfield with a preset value) (or within a TXOP with preemption allowed). The methods of not performing NAV setting/update may be implemented in various ways. For example, even if there is a previously set/updated NAV (e.g., an intra-BSS NAV) within the STA, the STA may ignore (or not consider) the NAV when receiving a Small PPDU with preemption allowed. For example, if the NAV is not set/updated, the STA (i.e., a BSS STA that is not a TXOP holder/responder) may ignore the NAV because it does not need to consider the NAV. As a result, the STA can ignore the NAV and transmit specific PPDUs (e.g., LL PPDU, TX request frame for transmission of LL PPDU, ACK/BA for LL PPDU, PPDU carrying traffic satisfying specific conditions or related to specific QoS/AC(Access category)/TID(Traffic ID)/Delay/latency, etc.) to the TXOP holder within the TXOP acquired by the TXOP holder (e.g., within the DL/UL TXOP where preemption is allowed).

As a second example of ignoring NAV, a BSS STA that is not a TXOP holder/responder can set a NAV during a duration indicated by a small PPDU (e.g., duration information included in an L-SIG field in the small PPDU or duration information indicated by an A-MPDU in the small PPDU), and release the NAV after the corresponding NAV ends. In other words, a BSS STA that is not a TXOP holder/responder can set the NAV based on the small PPDU, rather than setting the NAV based on a signal received during acquisition of the TXOP (e.g., RTS/CTS/CTS-to-self frame, intra-BSS frame/PPDU, etc.). Specifically, a BSS STA that is not a TXOP holder/responder may ignore the NAV even if the NAV is set based on a signal (e.g., RTS/CTS/CTS-to-self frame, intra-BSS frame/PPDU, etc.) received in the process of acquiring a TXOP, and may set the NAV based on the small PPDU. If the NAV is set based on a signal (e.g., RTS/CTS/CTS-to-self frame, intra-BSS frame/PPDU, etc.) received in the process of acquiring a TXOP, the duration of the NAV may become very long, and thus a problem may occur in which a BSS STA that is not a TXOP holder/responder cannot transmit LL PPDU, etc. for a long period of time. In summary, a BSS STA that is not a TXOP holder/responder may set a NAV based on the duration indicated by the Small PPDU (e.g., a small PPDU including a U-SIG including the PF subfield with a preset value) after receiving a Small PPDU for which preemption is allowed (or within a TXOP for which preemption is allowed) (e.g., a small PPDU including a U-SIG including the PF subfield with a preset value). In this case, a BSS STA that is not a TXOP holder/responder may ignore (or may not consider) the NAV set based on a signal (e.g., RTS/CTS/CTS-to-self frame, intra-BSS frame/PPDU, etc.) received during the process of acquiring a TXOP.

Additionally or alternatively, the various actions of ignoring the NAV described above may not be applied to STAs that cannot determine whether Preemption is allowed and/or STAs that do not recognize the Type of Small PPDU (e.g. EHT STAs and STAs of earlier versions, or UHR STAs that do not allow Preemption, etc.).

According to the third example of ignoring NAV, the various operations of ignoring NAV described above can be applied only to STAs that are not TXOP holder/responders but have PPDUs to transmit. In other words, the operation of ignoring NAV may not be applied to all BSS STAs that are not TXOP holder/responders. For example, among BSS STAs that are not TXOP holder/responders, only STAs that transmit traffic/PPDUs that meet specific conditions (e.g., LL PPDUs, TX request frames for transmitting LL PPDUs, ACK/BAs for LL PPDUs, PPDUs that convey traffic that meets specific conditions or is related to specific QoS/AC(Access category)/TID(Traffic ID)/Delay/latency, etc.) can ignore NAV. More specifically, BSS STAs that are not TXOP holder/responders can determine whether to ignore NAVs that have been previously set/updated. That is, a BSS STA that is not a TXOP holder/responder can i) set a NAV (e.g., intra-BSS NAV) based on a signal (e.g., RTS/CTS/CTS-to-self frame, intra-BSS frame/PPDU, etc.) received during the process of acquiring a TXOP, and ii) ignore (or do not consider) the NAV if a specific condition is satisfied. The “specific condition” is determined based on a) whether the BSS STA is not a TXOP holder/responder; and b) whether the BSS STA transmits traffic/PPDU satisfying a specific condition (e.g., LL PPDU, TX request frame for transmission of LL PPDU, ACK/BA for LL PPDU, PPDU conveying traffic satisfying a specific condition or related to specific QoS/AC(access category)/TID(Traffic ID)/Delay/latency, etc.). That is, the NAV can be ignored (or not considered) only when the BSS STA is not a TXOP holder/responder and the BSS STA transmits traffic/PPDU that meets certain conditions. In other cases, the NAV may not be ignored.

As described above, specific examples of ignoring NAV can be implemented in various ways. For example, even if NAV is set according to a conventional technique (for example, intra-BSS NAV is set/updated according to a conventional technique based on RTS/CTS/CTS-to-self frame, intra-BSS frame/PPDU, etc.), the corresponding NAV can be ignored when transmitting the Tx request frame for LL PPDU. In this way, even if the NAV is set/updated, transmitting without considering the corresponding NAV can be considered ignoring the NAV.

Technical features-2D.

Additionally or alternatively, the technical feature of ignoring (or not considering) NAV as described above may be used only in certain cases. For example, in a situation where a TXOP holder is a Non-AP STA and a TXOP responder is an AP and a BSS STA that does not correspond to the TXOP holder/responder has a PPDU to transmit, the technical feature described above (i.e., the technical feature of ignoring NAV) may not be applied. That is, in a situation where a TXOP holder is a Non-AP STA and a TXOP responder is an AP and a BSS STA that does not correspond to the TXOP holder/responder has a PPDU to transmit, it is also possible that the transmission of the Tx request frame described above may be restricted. To implement this behavior, if the Small PPDU is composed of a UL PPDU (i.e., the DL/UL subfield, which is a 1-bit subfield of the U-SIG field included in the Small PPDU, indicates ‘UL’), the Tx request frames of Non-AP STAs may not be permitted regardless of the value of the PF subfield included in the U-SIG field.

Technical Features-2E.

The above-described “Technical Feature-2C” and “Technical Feature-2D” may be applied to all STAs that are not TXOP holder/responders, or may be applied only to BSS STAs that are not TXOP holder/responders. For example, if the above-described “Technical Feature-2C” and “Technical Feature-2D” are not applied to an OBSS STA, even if the OBSS STA receives a Small PPDU of an Inter-BSS with Preemption allowed, it may set a basic NAV as in the prior art (i.e., set a NAV for the inter-BSS based on the received small PPDU) and may not transmit the above-described Tx request frame. The basic NAV set as above may be ignored when SR (spatial reuse) is considered.

Additionally or alternatively, an OBSS STA may transmit and receive with STAs (including APs) within the OBSS by using the Spatial reuse technique without transmitting the aforementioned Tx request frame to the TXOP holder. For example, by increasing the OBSS PD (Power Detection) level within the OBSS, a packet/PPDU may be transmitted within the OBSS if the interference level of the STA (including AP) is lower than or equal to the OBSS PD level. The OBSS PD level may be set in advance between the AP and STAs within the OBSS, and may also be shared (negotiated or announced) in advance with the BSS AP. The SR technique described above is further described as follows. For example, an OBSS STA may determine whether a surrounding wireless channel is busy or idle based on the OBSS PD level. The OBSS PD level related to the SR technique may have a threshold set higher than a normal PD level (for example, a threshold set 10 dBm higher than the conventional one). Through this, the OBSS STA can determine a wireless channel, which is determined to be busy if it were a conventional PD level, as idle. The OBSS STA applying the OBSS PD level as described above can transmit a PPDU within the OBSS based on the transmission power set based on the threshold value of the increased PD level. For example, according to the SR technique described above, if the threshold value of the PD level increases by 10 dBm, the maximum value of the transmission power applied to the corresponding OBSS STA can be reduced by 10 dBm. In this way, the OBSS STA can transmit a PPDU based on the increased PD Level (i.e., OBSS PD level) and the maximum value of the reduced transmission power within the OBSS even while the basic NAV is being set (i.e., while the BSS TXOP is being set).

Technical features-3.

Methods for allowing Preemption in this specification can be implemented in various ways. That is, methods for allowing an STA that is not a TXOP holder/responder to transmit traffic/PPDU satisfying specific conditions (e.g., LL PPDU, TX request frame for transmission of LL PPDU, ACK/BA for LL PPDU, PPDU conveying traffic satisfying specific conditions or related to specific QoS/AC(access category)/TID(Traffic ID)/Delay/latency, etc.) to the TXOP holder during an existing acquired TXOP can be implemented in various ways. For example, at least one of the technical features described in the above-mentioned “Technical Feature-2A” to “Technical Feature-2E” can be used.

Additionally or alternatively, Preemption may be permitted in the following manner:

For example, the AP/STA (e.g., TXOP holder) of the present specification can set a short TXOP multiple times in order to allow preemption. For example, the TXOP holder can set a short TXOP while transmitting a conventional RTS frame or PPDU (e.g., Small PPDU). That is, the value of the duration information included in the corresponding RTS frame or PPDU can be set short. After xIFS (e.g., SIFS) has elapsed since the corresponding RTS frame or PPDU is transmitted, the TXOP holder can immediately retransmit the RTS frame or PPDU (e.g. Small PPDU) (without performing contention for channel access). The value of the duration information of the retransmitted RTS/PPDU is set short. The TXOP holder can perform the above operations as many times as necessary to obtain a number of consecutive short TXOPs, which can achieve the same effect as setting a long TXOP. At this time, in order to prevent the length of channel occupancy from becoming excessively long, the maximum length of the sum of a number of consecutive short TXOPs that the TXOP holder can acquire can be limited. The maximum length of the sum of the number of short TXOPs can be set based on the maximum length of an existing single TXOP.

For example, an example of a specific method for setting a short TXOP is as follows. For example, when acquiring/setting a TXOP based on the exchange of an RTS frame and a CTS frame, the TXOP holder can set the Duration/ID field of the MAC header of the RTS frame to ‘0’ to set the length of the TXOP short. Additionally or alternatively, the TXOP holder can set the value of the Duration/ID field of the MAC header of the RTS frame based on the start or end of the Small PPDU transmitted and received after the exchange of the RTS/CTS frames. That is, the TXOP holder can set the value of the Duration/ID field of the MAC header of the RTS frame short so as to cover only the Small PPDU (and ACK/BA for the small PPDU) transmitted and received after the exchange of the RTS/CTS frames. Additionally or alternatively, when acquiring/setting TXOP based on Small PPDU, the TXOP holder may set the Duration/ID field of A-MPDU constituting the corresponding PPDU to ‘0’. Additionally or alternatively, when acquiring/setting TXOP based on Small PPDU, the TXOP holder may set the Duration/ID field of A-MPDU constituting the corresponding PPDU to be short enough to cover only until the end of the corresponding PPDU.

According to the above technique, when the TXOP is set relatively short, the STAs that require preemption (e.g., STAs that transmit specific traffic among BSS/OBSS STAs that are not TXOP holder/responders) can transmit the above-described Tx request frame after the short TXOP ends and the NAV that they set/updated themselves is released. In other words, the above-described Tx request frame can be transmitted at the right time without performing the technical feature of ignoring the NAV (e.g., the feature described in “Technical Feature-2C” to “Technical Feature-2E” described above). However, in this case, since other STAs can also attempt to transmit their data after the short TXOP ends and the NAV is released, a collision may occur between the STAs that require preemption and those that do not. As an example of a method to minimize such collisions, among STAs that can identify preemption information, STAs that do not require preemption (i.e., STAs that are not TXOP holders/responders but are BSS/OBSS STAs that do not transmit specific traffic such as LL PPDUs) can be configured not to attempt to transmit their PPDUs (e.g., uplink PPDU transmissions) for a preset period of time even if their NAVs are released.

The above-described technical features can be explained based on the following flowchart.

Figure 17 is an example of a procedure flow diagram of this specification.

Each step of FIG. 17 can be performed by various STAs (AP-STA, Relay STA, non-AP STA) of the WLAN system. The STA performing each step of FIG. 17 may be a BSS STA (and/or OBSS STA) that is not a TXOP holder/responder. Additionally or alternatively, the STA performing each step of FIG. 17 may be an STA that transmits traffic/PPDU satisfying a specific condition (e.g., LL PPDU, TX request frame for transmission of LL PPDU, ACK/BA for LL PPDU, PPDU conveying traffic satisfying a specific condition or related to a specific QoS/AC(access category)/TID(Traffic ID)/Delay/latency, etc.) to the TXOP holder, among the BSS STAs (and/or OBSS STAs) that are not a TXOP holder/responder.

As illustrated in step S1710, the STA can set a network allocation vector (NAV). The expression of setting a NAV can be replaced with the expression of updating a NAV. The STA can acquire various signals (e.g., RTS/CTS/CTS-to-self frame, intra-BSS frame/PPDU, etc.) transmitted and received during the process of acquiring a DL/UL-TXOP by the TXOP holder, and set the NAV based on the signals acquired in this way. For example, the NAV set in step S1710 can correspond to the length of one TXOP acquired by the TXOP holder.

In step S1710, the STA can set NAV based on intra-BSS PPDU. The intra-BSS PPDU can include RTS/CTS/CTS-to-self frame related to TXOP acquisition. For example, the intra-BSS PPDU can include PPDU transmitted by TXOP holder/responder. For example, the intra-BSS PPDU can include common control field (e.g., U-SIG field), and the common control field can include BSS color field of, for example, 6 bits. The STA can identify whether the received PPDU is intra-BSS PPDU or inter-BSS PPDU based on the BSS color field. If the received PPDU is intra-BSS PPDU, the STA can set/update NAV (e.g., intra-BSS NAV) based on the received PPDU. Specifically, the STA may set/update the NAV (e.g., intra-BSS NAV) based on a TXOP field (e.g., 7-bit information) included in a common control field (e.g., U-SIG field) of a received intra-BSS PPDU and/or based on duration/ID information included in a MAC header within the intra-BSS PPDU.

As illustrated in step S1720, the STA determines whether to ignore the set NAV. For example, the STA may determine whether to ignore the NAV set/updated based on step S1710 within one TXOP acquired by the TXOP holder. The operation of ignoring the set NAV may be implemented in various ways. Accordingly, the expression of ignoring the set NAV may be replaced with another expression. For example, ignoring the set NAV may mean not considering the set NAV, changing the set NAV value to a preset value (e.g., ‘0’), or releasing the set NAV value.

The step of determining whether to ignore NAV according to step S1720 may be based on the contents of “Technical Feature-2C”, “Technical Feature-2D”, and “Technical Feature-2E” described above.

For example, as described in “Technical Feature-2C”, a BSS STA that is not a TXOP holder/responder may not perform NAV setting/update after receiving a Small PPDU with preemption allowed (e.g., a small PPDU including a U-SIG including the PF subfield with a preset value) (or within a TXOP with preemption allowed). In other words, the STA may a) determine whether it is a BSS STA that is not a TXOP holder/responder, and b) determine whether it has received a Small PPDU with preemption allowed. That is, step S1720 may include a) determining whether it is a BSS STA that is not a TXOP holder/responder, and b) determining whether it has received a Small PPDU with preemption allowed. For example, if the conditions/determinations of “a)” and “b)” described above are not satisfied, the STA cannot ignore the previously set NAV.

Additionally or alternatively, as described in “Technical Feature-2C”, a BSS STA that is not a TXOP holder/responder may ignore the NAV even if the NAV is set based on a signal received during the process of acquiring a TXOP (e.g., RTS/CTS/CTS-to-self frame, intra-BSS frame/PPDU, etc.) and set the NAV based on the duration indicated by the Small PPDU (e.g., duration information included in the L-SIG field of the small PPDU or duration information indicated by the A-MPDU of the small PPDU). In other words, the STA can a) determine whether it is a BSS STA that is not a TXOP holder/responder, and b) determine whether the Small PPDU includes a duration indicating a NAV (e.g., duration information included in the L-SIG field of the small PPDU or duration information indicated by the A-MPDU of the small PPDU). That is, step S1720 may include a) determining whether it is a BSS STA that is not a TXOP holder/responder, and b) determining whether a Small PPDU with preemption allowed is received and the Small PPDU includes a duration indicating NAV. For example, if the conditions/judgments of “a)” and “b)” described above are not satisfied, the STA cannot ignore the previously set NAV.

Additionally or alternatively, as described in “Technical Feature-2C”, only a STA that is not a TXOP holder/responder and transmits traffic/PPDU that meets specific conditions (e.g., LL PPDU, TX request frame for transmission of LL PPDU, ACK/BA for LL PPDU, PPDU that carries traffic that meets specific conditions or is related to specific QoS/AC(Access category)/TID(Traffic ID)/Delay/latency, etc.) may ignore NAV. In other words, a STA can a) determine whether it is a BSS STA that is not a TXOP holder/responder, b) determine whether it has received a Small PPDU with Preemption allowed, and c) determine whether it transmits traffic/PPDU that meets specific conditions. That is, step S1720 may include a) determining whether the STA is a BSS STA that is not a TXOP holder/responder, b) determining whether the STA has received a Small PPDU for which Preemption is allowed, and c) determining whether the STA transmits traffic/PPDU that meets a specific condition. For example, if the conditions/judgments of “a)”, “b)”, and “c)” described above are not satisfied, the STA cannot ignore the previously set NAV. Not all of the above conditions/judgments are essential components, and some of the conditions/judgments may be omitted. For example, since various methods of signaling whether preemption is allowed can be implemented, the judgment/judgment of “b)” described above may be omitted.

As described in step S1730, a transmission operation is performed based on whether to ignore the NAV. That is, an STA that determines to ignore the NAV in step S1720 can ignore the previously set NAV and transmit traffic/PPDU (e.g., LL PPDU, TX request frame for transmission of LL PPDU, ACK/BA for LL PPDU, PPDU conveying traffic satisfying a specific condition or related to a specific QoS/AC(access category)/TID(Traffic ID)/Delay/latency, etc.) (to the TXOP holder). For example, an STA that determines to ignore the NAV can perform an operation of ignoring the previously set NAV and transmitting the above-described TX request frame, transmitting the LL PPDU, or transmitting the ACK/BA for the LL PPDU, etc., during a TXOP acquired by the TXOP holder. In other words, during the TXOP acquired by the TXOP holder, the STA can ignore the previously set NAV and transmit a request signal related to the low latency packet (i.e., the TX request frame described above). The step of transmitting the TX request frame described above is not a mandatory step. For example, if it is not determined by step S1720 that the NAV is to be ignored, the step of transmitting the TX request frame may be omitted.

An STA that determines not to ignore the NAV at step S1720 performs subsequent operations according to the previously set NAV (S1730). That is, since subsequent operations are performed according to the NAV set at step S1710, transmission is not started until the corresponding NAV is released. In other words, during the TXOP acquired by the TXOP holder, only a reception operation can be performed without performing a transmission operation.

The technical features of the present specification (for example, the technical features described in at least one of FIGS. 15 to 17) may be performed by various devices. The device of the present specification may be the device described in FIG. 1/FIG. 14. The device of the present specification may include at least one processor; and at least one computer memory operably connectable to the at least one processor, storing instructions for performing operations based on being executed by the at least one processor.

For example, the processor may be the processor described in FIG. 1 and/or FIG. 14. That is, as described above, the processor of the present specification may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modem (modulator and demodulator). The processor may include not only computers having various architectures such as single/multiprocessor architecture, sequential (Von Neumann)/parallel architecture, but also specialized circuits such as FPGAs, ASICs, signal processing devices, and other devices. For example, the processor of the present specification may be a SNAPDRAGON® series processor manufactured by Qualcomm®, an EXYNOS® series processor manufactured by Samsung®, an A series processor manufactured by Apple®, a HELIO® series processor manufactured by MediaTek®, an ATOM® series processor manufactured by INTEL®, or a processor that enhances these.

For example, the instructions may mean computer program instructions executed by the at least one processor. The (computer program) instructions provide logic and/or routines that enable the technical features of the present specification (the technical features described in at least one of FIGS. 15 to 17) to be performed by the processor. The at least one processor can load and execute the computer program by reading the at least one memory.

The computer program(s) defined by the above instructions can arrive at the device (e.g., STA) of the present specification via a suitable delivery mechanism. The delivery mechanism can be, for example, a computer-readable storage medium, a computer program product, a memory device, a recording medium such as a CD-ROM or DVD, or a product tangibly embodying a computer program. The delivery mechanism can be a signal configured to reliably transmit the computer program via a wireless or electrical connection.

The above (computer program) instructions may include software or firmware for a programmable processor (e.g., programmable content of a hardware device whether instructions for a processor, or configuration settings for a fixed-function device, gate array or programmable logic device, etc.).

For example, the memory may be the memory described in FIG. 1 and/or FIG. 14. That is, as described above, the memory of the present specification may store control information related to the operation of the STA of the present specification or information about a signal transmitted and received by the STA (e.g., a PPDU including a management/control/data frame).

The technical features of the present specification may be implemented as at least one computer readable medium (CRM). The CRM includes instructions that are based on execution by at least one processor as described above. The instructions stored in the CRM may be the computer program instructions as described above.

The device of the present disclosure may further include a transceiver. The transceiver may be operably connectable to the memory/processor, etc. The transceiver may be the transceiver illustrated in FIG. 1 and/or FIG. 14.

The technical features of the present specification described above can be applied to various applications or business models. For example, the technical features described above can be applied to wireless communication in devices that support artificial intelligence (AI).

Artificial intelligence refers to a field that studies artificial intelligence or the methodologies for creating it, and machine learning refers to a field that defines various problems in the field of artificial intelligence and studies the methodologies for solving them. Machine learning is also defined as an algorithm that improves the performance of a task through constant experience with that task.

An artificial neural network (ANN) is a model used in machine learning, and can refer to a model with problem-solving capabilities that consists of artificial neurons (nodes) that form a network by combining synapses. An artificial neural network can be defined by the connection pattern between neurons in different layers, the learning process that updates model parameters, and the activation function that generates the output value.

An artificial neural network may include an input layer, an output layer, and optionally one or more hidden layers. Each layer may include one or more neurons, and the artificial neural network may include synapses connecting neurons. In an artificial neural network, each neuron may output a function value of an activation function for input signals, weights, and biases input through synapses.

Model parameters refer to parameters that are determined through learning, including the weights of synaptic connections and the biases of neurons. Hyperparameters refer to parameters that must be set before learning in machine learning algorithms, including learning rate, number of iterations, mini-batch size, and initialization functions.

The goal of learning an artificial neural network can be seen as determining model parameters that minimize the loss function. The loss function can be used as an indicator for determining optimal model parameters during the learning process of an artificial neural network.

Machine learning can be classified into supervised learning, unsupervised learning, and reinforcement learning depending on the learning method.

Supervised learning refers to a method of training an artificial neural network when labels for training data are given. The labels can refer to the correct answer (or result value) that the artificial neural network should infer when training data is input to the artificial neural network. Unsupervised learning can refer to a method of training an artificial neural network when labels for training data are not given. Reinforcement learning can refer to a learning method that trains an agent defined in a certain environment to select actions or action sequences that maximize cumulative rewards in each state.

Among artificial neural networks, machine learning implemented with a deep neural network (DNN: Deep Neural Network) that includes multiple hidden layers is also called deep learning, and deep learning is a part of machine learning. Hereinafter, machine learning is used to mean including deep learning.

Additionally, the above-described technical features can be applied to wireless communication of robots.

A robot can mean a machine that automatically processes or operates a given task by its own abilities. In particular, a robot that has the ability to recognize the environment, make judgments, and perform actions on its own can be called an intelligent robot.

Robots can be classified into industrial, medical, household, and military types depending on their intended use or field. Robots can perform various physical actions, such as moving robot joints, by having a drive unit that includes an actuator or motor. In addition, mobile robots have a drive unit that includes wheels, brakes, and propellers, and can drive on the ground or fly in the air through the drive unit.

Additionally, the above-described technical features can be applied to devices supporting extended reality.

Extended reality is a general term for virtual reality (VR), augmented reality (AR), and mixed reality (MR). VR technology provides real-world objects and backgrounds only as CG images, AR technology provides virtual CG images on top of real-world object images, and MR technology is a computer graphics technology that mixes and combines virtual objects in the real world.

MR technology is similar to AR technology in that it shows real objects and virtual objects together. However, there is a difference in that while AR technology uses virtual objects to complement real objects, MR technology uses virtual and real objects with equal characteristics.

XR technology can be applied to HMD (Head-Mount Display), HUD (Head-Up Display), mobile phones, tablet PCs, laptops, desktops, TVs, digital signage, etc., and devices to which XR technology is applied can be called XR devices.

Claims (16)

In a method performed in a wireless local area network (WLAN) system, A step of setting a network allocation vector (NAV) based on an intra BSS (basic service set) PPDU (Physical Protocol Data Unit) by a STA (station); Whether the STA is one of a TXOP (transmission opportunity) holder and a TXOP responder and whether the STA considers the NAV based on a packet to be transmitted by the STA is determined. A step in which the STA does not consider the NAV if the packet to be transmitted is related to a low latency packet and the STA is not the TXOP holder and not the TXOP responder; and A step of transmitting a request signal regarding the packet by the STA Including method In the first paragraph, the intra PPDU is received from an AP (access point) within a BSS (Basic Service Set) to which the STA belongs, and the NAV is an intra-BSS NAV. method. In the first paragraph, the STA includes a basic NAV, and the basic NAV is set by an inter BSS PPDU. method. In the first paragraph, the request signal regarding the packet is transmitted to the TXOP holder. method. In the first paragraph, the STA transmits a request signal regarding the packet during the TXOP acquired by the TXOP holder. method. In the first paragraph, the STA determines that a subfield in the received PPDU has a preset value, wherein the subfield is a flag field included in the U-SIG field of the received PPDU, If the above flag field has a preset value, the STA does not consider the NAV. method. In the first paragraph, the intra BSS PPDU includes an RTS (Ready To Transmit) frame received from the TXOP holder or a CTS (Clear To Transmit) frame received from the TXOP responder. method. In a STA (station) of a wireless local area network (WLAN) system, at least one processor; and At least one computer memory operably connectable to said at least one processor, said computer memory storing instructions for performing operations based on being executed by said at least one processor, The instructions of at least one computer memory, A step of setting a network allocation vector (NAV) based on an intra BSS (basic service set) PPDU (Physical Protocol Data Unit) by the above STA (station); Whether the STA is one of a TXOP (transmission opportunity) holder and a TXOP responder and whether the STA considers the NAV based on a packet to be transmitted by the STA is determined. A step in which the STA does not consider the NAV if the packet to be transmitted is related to a low latency packet and the STA is neither the TXOP holder nor the TXOP responder; and A step of transmitting a request signal regarding the packet by the STA To perform STA. In the 8th paragraph, the intra PPDU is received from an AP (access point) within a BSS (Basic Service Set) to which the STA belongs, and the NAV is an intra-BSS NAV. STA. In the 8th paragraph, the STA includes a basic NAV, and the basic NAV is set by an inter BSS PPDU. STA. In the 8th paragraph, the request signal regarding the packet is transmitted to the TXOP holder. STA. In the 8th paragraph, the STA transmits a request signal regarding the packet during the TXOP acquired by the TXOP holder. STA. In the 8th paragraph, the STA determines that a subfield in the received PPDU has a preset value, wherein the subfield is a flag field included in the U-SIG field of the received PPDU, If the above flag field has a preset value, the STA does not consider the NAV. STA. In the 8th paragraph, the intra BSS PPDU includes an RTS (Ready To Transmit) frame received from the TXOP holder or a CTS (Clear To Transmit) frame received from the TXOP responder. STA. In a wireless local area network (WLAN) system, at least one computer readable medium including instructions based on being executed by at least one processor, A step of setting a network allocation vector (NAV) based on an intra BSS (basic service set) PPDU (Physical Protocol Data Unit) by a STA (station); Whether the STA is one of a TXOP (transmission opportunity) holder and a TXOP responder and whether the STA considers the NAV based on a packet to be transmitted by the STA is determined. A step in which the STA does not consider the NAV if the packet to be transmitted is related to a low latency packet and the STA is neither the TXOP holder nor the TXOP responder; and A step of transmitting a request signal regarding the packet by the STA A device that performs an operation including: In a wireless local area network (WLAN) system, At least one transceiver; at least one processor; and At least one computer memory operably connectable to said at least one transceiver and said at least one processor, said computer memory storing instructions for performing operations based on being executed by said at least one processor, The instructions of at least one computer memory, A step of setting a network allocation vector (NAV) based on an intra BSS (basic service set) PPDU (Physical Protocol Data Unit) by a STA (station); Whether the STA is one of a TXOP (transmission opportunity) holder and a TXOP responder and whether the STA considers the NAV based on a packet to be transmitted by the STA is determined. A step in which the STA does not consider the NAV if the packet to be transmitted is related to a low latency packet and the STA is not the TXOP holder and not the TXOP responder; and A step of transmitting a request signal regarding the packet by the STA To perform Device.

Images