WO2016186469A1 - 무선랜 시스템에서 nav를 관리하는 방법 및 이를 위한 장치 - Google Patents

무선랜 시스템에서 nav를 관리하는 방법 및 이를 위한 장치 Download PDF

Info

Publication number
WO2016186469A1
WO2016186469A1 PCT/KR2016/005341 KR2016005341W WO2016186469A1 WO 2016186469 A1 WO2016186469 A1 WO 2016186469A1 KR 2016005341 W KR2016005341 W KR 2016005341W WO 2016186469 A1 WO2016186469 A1 WO 2016186469A1
Authority
WO
WIPO (PCT)
Prior art keywords
nav
sta
frame
bss
txop
Prior art date
Application number
PCT/KR2016/005341
Other languages
English (en)
French (fr)
Inventor
김정기
류기선
조한규
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to US15/508,076 priority Critical patent/US10524231B2/en
Priority to JP2017560613A priority patent/JP6849607B2/ja
Priority to EP16796796.7A priority patent/EP3300445B1/en
Publication of WO2016186469A1 publication Critical patent/WO2016186469A1/ko
Priority to US16/704,815 priority patent/US11564204B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/02—Selection of wireless resources by user or terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055—Physical resource allocation for ACK/NACK
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/0446—Resources in time domain, e.g. slots or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access, e.g. scheduled or random access
    • H04W74/08—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access]
    • H04W74/0833—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using a random access procedure
    • H04W74/0841—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using a random access procedure with collision treatment
    • H04W74/085—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using a random access procedure with collision treatment collision avoidance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/0001—Arrangements for dividing the transmission path
    • H04L5/0003—Two-dimensional division
    • H04L5/0005—Time-frequency
    • H04L5/0007—Time-frequency the frequencies being orthogonal, e.g. OFDM(A), DMT
    • H04L5/001—Time-frequency the frequencies being orthogonal, e.g. OFDM(A), DMT the frequencies being arranged in component carriers

Definitions

  • the present invention relates to a method and apparatus for managing a network allocation vector (NAV) in a WLAN system, and more particularly, to a method and apparatus for managing the NAV based on a received frame.
  • NAV network allocation vector
  • IEEE 802.11a and b are described in 2.4. Using unlicensed band at GHz or 5 GHz, IEEE 802.11b provides a transmission rate of 11 Mbps and IEEE 802.11a provides a transmission rate of 54 Mbps.
  • IEEE 802.11g applies orthogonal frequency-division multiplexing (OFDM) at 2.4 GHz to provide a transmission rate of 54 Mbps.
  • IEEE 802.11n applies multiple input multiple output OFDM (MIMO-OFDM) to provide a transmission rate of 300 Mbps for four spatial streams. IEEE 802.11n supports channel bandwidths up to 40 MHz, in this case providing a transmission rate of 600 Mbps.
  • the WLAN standard uses a maximum of 160MHz bandwidth, supports eight spatial streams, and supports IEEE 802.11ax standard through an IEEE 802.11ac standard supporting a speed of up to 1Gbit / s.
  • An object of the present invention is to provide a method and apparatus for managing an NAV in consideration of a BSS transmitting a frame in a WLAN system supporting HE PPDU.
  • the present invention is not limited to the above-described technical problem and other technical problems can be inferred from the embodiments of the present invention.
  • a method for managing a network allocation vector (NAV) by a station (STA) in a WLAN system supporting HE PPDU (high efficiency physical layer protocol data unit) includes: receiving a frame including duration information; Selecting a predetermined NAV among a plurality of NAVs of the STA; And managing the predetermined NAV based on interval information of the frame, wherein the predetermined NAV is selected based on whether the frame is received from a basic service set (BSS) to which the STA belongs.
  • BSS basic service set
  • a station (STA) for managing a network allocation vector (NAV) in a wireless LAN system supporting a high efficiency physical layer protocol data unit (HE PPDU) for achieving the above-described technical problem, a receiver for receiving a frame including duration) information; And a processor for selecting a predetermined NAV among a plurality of NAVs of the STA and managing the predetermined NAV based on the section information of the frame, wherein the predetermined NAV includes: the frame to which the STA belongs. It may be selected based on whether it is received from a basic service set (BSS).
  • BSS basic service set
  • the STA may select a first NAV if it is determined that the frame is received from a BSS to which the STA belongs, and select a second NAV if it is determined that the frame is received from a BSS to which the STA does not belong. have. More preferably, the STA may select the second NAV if it is unable to determine from which BSS the frame is received.
  • said plurality of NAVs comprise intra BSS NAV and non-intra BSS NAV, and said non-intra BSS NAV may be for an OBSS frame. More preferably, the non-intra BSS NAV may be for a frame that cannot specify the BSS. More preferably, the frame that cannot specify the BSS may be an acknowledgment (ACK) frame or a clear-to-send (CTS) frame.
  • ACK acknowledgment
  • CTS clear-to-send
  • the STA may withhold channel access.
  • the STA may set a plurality of NAV timers corresponding to the plurality of NAVs.
  • the plurality of NAVs may be managed through a difference value between the plurality of NAVs and one NAV timer.
  • the difference value between the plurality of NAVs may be updated.
  • the STA may determine the validity of the second NAV by using a difference value between the plurality of NAVs and a current value of the first NAV mapped to the one NAV timer.
  • the STA in the WLAN system supporting the HE PPDU, the STA considers the BSS that transmitted the frame in managing a plurality of NAVs, so that the NAVs can be managed accurately and efficiently.
  • FIG. 1 is a diagram illustrating an example of a configuration of a WLAN system.
  • FIG. 2 is a diagram illustrating another example of a configuration of a WLAN system.
  • FIG. 3 is a diagram illustrating a general link setup process.
  • FIG. 4 is a diagram for describing a backoff process.
  • 5 is a diagram for explaining hidden nodes and exposed nodes.
  • FIG. 6 is a diagram for explaining an RTS and a CTS.
  • 7 to 9 are diagrams for explaining the operation of the STA receiving the TIM.
  • FIG. 10 is a diagram for explaining an example of a frame structure used in an IEEE 802.11 system.
  • FIG. 11 illustrates a content free (CF) -END frame.
  • FIG. 12 shows an example of a HE PPDU.
  • FIG. 13 shows another example of an HE PPDU.
  • FIG. 14 shows another example of an HE PPDU.
  • 15 shows another example of an HE PPDU.
  • 16 shows another example of an HE PPDU.
  • 17 and 18 illustrate a padding scheme for HE-SIG B.
  • FIG 19 illustrates an uplink multi-user transmission situation according to an embodiment of the present invention.
  • FIG. 20 illustrates a trigger frame format according to an embodiment of the present invention.
  • 26 illustrates NAV management according to another embodiment of the present invention.
  • FIG 30 illustrates NAV management according to another embodiment of the present invention.
  • 35 illustrates two NAV timers according to an embodiment of the present invention.
  • FIG. 36 illustrates a flow of a NAV management method according to an embodiment of the present invention.
  • FIG. 37 is a diagram for explaining an apparatus according to an embodiment of the present invention.
  • the following description relates to a method and an apparatus therefor for efficiently utilizing a channel having a wide band in a WLAN system.
  • a WLAN system to which the present invention is applied will be described in detail.
  • FIG. 1 is a diagram illustrating an example of a configuration of a WLAN system.
  • the WLAN system includes one or more basic service sets (BSSs).
  • BSS is a set of stations (STAs) that can successfully synchronize and communicate with each other.
  • An STA is a logical entity that includes a medium access control (MAC) and a physical layer interface to a wireless medium.
  • the STA is an access point (AP) and a non-AP STA (Non-AP Station). Include.
  • the portable terminal operated by the user among the STAs is a non-AP STA, and when referred to simply as an STA, it may also refer to a non-AP STA.
  • a non-AP STA is a terminal, a wireless transmit / receive unit (WTRU), a user equipment (UE), a mobile station (MS), a mobile terminal, or a mobile subscriber. It may also be called another name such as a mobile subscriber unit.
  • the AP is an entity that provides an associated station (STA) coupled to the AP to access a distribution system (DS) through a wireless medium.
  • STA station
  • DS distribution system
  • the AP may be called a centralized controller, a base station (BS), a Node-B, a base transceiver system (BTS), or a site controller.
  • BS base station
  • BTS base transceiver system
  • BSS can be divided into infrastructure BSS and Independent BSS (IBSS).
  • IBSS Independent BSS
  • the BBS shown in FIG. 1 is an IBSS.
  • the IBSS means a BSS that does not include an AP. Since the IBSS does not include an AP, access to the DS is not allowed, thereby forming a self-contained network.
  • FIG. 2 is a diagram illustrating another example of a configuration of a WLAN system.
  • the BSS shown in FIG. 2 is an infrastructure BSS.
  • Infrastructure BSS includes one or more STAs and APs.
  • communication between non-AP STAs is performed via an AP.
  • AP access point
  • a plurality of infrastructure BSSs may be interconnected through a DS.
  • a plurality of BSSs connected through a DS is called an extended service set (ESS).
  • STAs included in the ESS may communicate with each other, and a non-AP STA may move from one BSS to another BSS while seamlessly communicating within the same ESS.
  • the DS is a mechanism for connecting a plurality of APs.
  • the DS is not necessarily a network, and there is no limitation on the form if it can provide a predetermined distribution service.
  • the DS may be a wireless network such as a mesh network or a physical structure that connects APs to each other.
  • the operation of the STA operating in the WLAN system may be described in terms of a layer structure.
  • the hierarchy may be implemented by a processor.
  • the STA may have a plurality of hierarchical structures.
  • the hierarchical structure covered by the 802.11 standard document is mainly the MAC sublayer and physical (PHY) layer on the DLL (Data Link Layer).
  • the PHY may include a Physical Layer Convergence Procedure (PLCP) entity, a Physical Medium Dependent (PMD) entity, and the like.
  • PLCP Physical Layer Convergence Procedure
  • PMD Physical Medium Dependent
  • the MAC sublayer and PHY conceptually contain management entities called MAC sublayer management entities (MLMEs) and physical layer management entities (PLMEs), respectively.These entities provide a layer management service interface on which layer management functions operate. .
  • SME Station Management Entity
  • An SME is a layer-independent entity that can appear to be in a separate management plane or appear to be off to the side. While the exact features of the SME are not described in detail in this document, they generally do not include the ability to collect layer-dependent states from various Layer Management Entities (LMEs), and to set similar values for layer-specific parameters. You may seem to be in charge. SMEs can generally perform these functions on behalf of general system management entities and implement standard management protocols.
  • LMEs Layer Management Entities
  • the aforementioned entities interact in a variety of ways.
  • entities can interact by exchanging GET / SET primitives.
  • a primitive means a set of elements or parameters related to a particular purpose.
  • the XX-GET.request primitive is used to request the value of a given MIB attribute (management information based attribute information).
  • the XX-GET.confirm primitive is used to return the appropriate MIB attribute information value if the Status is "Success", otherwise it is used to return an error indication in the Status field.
  • the XX-SET.request primitive is used to request that the indicated MIB attribute be set to a given value. If the MIB attribute means a specific operation, this is to request that the operation be performed.
  • the XX-SET.confirm primitive confirms that the indicated MIB attribute is set to the requested value when status is "success", otherwise it is used to return an error condition in the status field. If the MIB attribute means a specific operation, this confirms that the operation has been performed.
  • the MLME and SME may exchange various MLME_GET / SET primitives through a MLME_SAP (Service Access Point).
  • various PLME_GET / SET primitives may be exchanged between PLME and SME through PLME_SAP and may be exchanged between MLME and PLME through MLME-PLME_SAP.
  • FIG. 3 is a diagram illustrating a general link setup process.
  • an STA In order for an STA to set up a link and transmit / receive data with respect to a network, an STA first discovers the network, performs authentication, establishes an association, and authenticates for security. It must go through the back.
  • the link setup process may also be referred to as session initiation process and session setup process.
  • a process of discovery, authentication, association, and security establishment of a link setup process may be collectively referred to as association process.
  • 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, the STA must find a network that can participate. The STA must identify a compatible network before joining the wireless network. A network identification process existing in a specific area is called scanning.
  • the STA performing scanning transmits a probe request frame and waits for a response to discover which AP exists in the vicinity while moving channels.
  • the responder transmits a probe response frame to the STA that transmits the probe request frame in response to the probe request frame.
  • the responder may be an STA that last transmitted a beacon frame in the BSS of the channel being scanned.
  • the AP transmits a beacon frame, so the AP becomes a responder.
  • the responder is not constant.
  • an STA that transmits a probe request frame on channel 1 and receives a probe response frame on channel 1 stores the BSS-related information included in the received probe response frame and stores the next channel (eg, number 2).
  • Channel to perform scanning (i.e., probe request / response transmission and reception on channel 2) in the same manner.
  • the scanning operation may be performed by a passive scanning method.
  • passive scanning the STA performing scanning waits for a beacon frame while moving channels.
  • the beacon frame is one of management frames in IEEE 802.11.
  • the beacon frame is notified of the existence of a wireless network and is periodically transmitted to allow the STA performing scanning to find the wireless network and participate in the wireless network.
  • the AP periodically transmits a beacon frame
  • the IBSS STAs in the IBSS rotate and transmit a beacon frame.
  • the STA that performs the scanning receives the beacon frame, the STA stores the information on the BSS included in the beacon frame and records beacon frame information in each channel while moving to another channel.
  • the STA may store BSS related information included in the received beacon frame, move to the next channel, and perform scanning on the next channel in the same manner.
  • active scanning has the advantage of less delay and power consumption than passive scanning.
  • step S520 After the STA discovers the network, an authentication process may be performed in step S520.
  • This authentication process may be referred to as a first authentication process in order to clearly distinguish from the security setup operation of step S540 described later.
  • the authentication process includes a process in which the STA transmits an authentication request frame to the AP, and in response thereto, the AP transmits an authentication response frame to the STA.
  • An authentication frame used for authentication request / response corresponds to a management frame.
  • the authentication frame includes an authentication algorithm number, an authentication transaction sequence number, a status code, a challenge text, a Robust Security Network, and a finite cyclic group. Group) and the like. This corresponds to some examples of information that may be included in the authentication request / response frame, and may be replaced with other information or further include additional information.
  • the STA may send an authentication request frame to the AP.
  • the AP may determine whether to allow authentication for the corresponding STA based on the information included in the received authentication request frame.
  • the AP may provide a result of the authentication process to the STA through an authentication response frame.
  • the association process includes a process in which the STA transmits an association request frame to the AP, and in response thereto, the AP transmits an association response frame to the STA.
  • the association request frame may include information related to various capabilities, beacon listening interval, service set identifier (SSID), supported rates, supported channels, RSN, mobility domain. Information about supported operating classes, TIM Broadcast Indication Map Broadcast request, interworking service capability, and the like.
  • an association response frame may include information related to various capabilities, status codes, association IDs (AIDs), support rates, Enhanced Distributed Channel Access (EDCA) parameter sets, Received Channel Power Indicators (RCPI), Received Signal to Noise Information, such as an indicator, a mobility domain, a timeout interval (association comeback time), an overlapping BSS scan parameter, a TIM broadcast response, and a QoS map.
  • AIDs association IDs
  • EDCA Enhanced Distributed Channel Access
  • RCPI Received Channel Power Indicators
  • Received Signal to Noise Information such as an indicator, a mobility domain, a timeout interval (association comeback time), an overlapping BSS scan parameter, a TIM broadcast response, and a QoS map.
  • a security setup process may be performed at step S540.
  • the security setup process of step S540 may be referred to as an authentication process through a Robust Security Network Association (RSNA) request / response.
  • the authentication process of step S520 is called a first authentication process, and the security setup process of step S540 is performed. It may also be referred to simply as the authentication process.
  • RSNA Robust Security Network Association
  • the security setup process of step S540 may include, for example, performing a private key setup through 4-way handshaking through an Extensible Authentication Protocol over LAN (EAPOL) frame. .
  • the security setup process may be performed according to a security scheme not defined in the IEEE 802.11 standard.
  • a basic access mechanism of MAC is a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism.
  • the CSMA / CA mechanism is also called the Distributed Coordination Function (DCF) of the IEEE 802.11 MAC. It basically employs a "listen before talk" access mechanism.
  • the AP and / or STA may sense a radio channel or medium during a predetermined time period (e.g., during a DCF Inter-Frame Space (DIFS), before starting transmission.
  • DIFS DCF Inter-Frame Space
  • a delay period for example, a random backoff period
  • HCF hybrid coordination function
  • the PCF refers to a polling-based synchronous access scheme in which polling is performed periodically so that all receiving APs and / or STAs can receive data frames.
  • the HCF has an Enhanced Distributed Channel Access (EDCA) and an HCF Controlled Channel Access (HCCA).
  • EDCA is a competition based approach for providers to provide data frames to multiple users, and HCCA uses a non-competition based channel access scheme using a polling mechanism.
  • the HCF includes a media access mechanism for improving the quality of service (QoS) of the WLAN, and can transmit QoS data in both a contention period (CP) and a contention free period (CFP).
  • QoS quality of service
  • FIG. 4 is a diagram for describing a backoff process.
  • the random backoff count has a packet number value and may be determined as one of values ranging from 0 to CW.
  • CW is a contention window parameter value.
  • the CW parameter is given CWmin as an initial value, but may take a double value in case of transmission failure (eg, when an ACK for a transmitted frame is not received).
  • the STA continues to monitor the medium while counting down the backoff slots according to the determined backoff count value. If the medium is monitored as occupied, the countdown stops and waits; if the medium is idle, it resumes the remaining countdown.
  • the STA3 may confirm that the medium is idle as much as DIFS and transmit the frame immediately. Meanwhile, the remaining STAs monitor and wait for the medium to be busy. In the meantime, data may also be transmitted in each of STA1, STA2, and STA5, and each STA waits for DIFS when the medium is monitored idle, and then counts down the backoff slot according to a random backoff count value selected by the STA. Can be performed. In the example of FIG. 4, STA2 selects the smallest backoff count value, and STA1 selects the largest backoff count value.
  • the remaining backoff time of the STA5 is shorter than the remaining backoff time of the STA1 at the time when the STA2 finishes the backoff count and starts the frame transmission.
  • STA1 and STA5 stop counting for a while and wait for STA2 to occupy the medium.
  • the STA1 and the STA5 resume the stopped backoff count after waiting for DIFS. That is, the frame transmission can be started after counting down the remaining backoff slots by the remaining backoff time. Since the remaining backoff time of the STA5 is shorter than that of the STA1, the STA5 starts frame transmission. Meanwhile, while STA2 occupies the medium, data to be transmitted may also occur in STA4.
  • the STA4 waits for DIFS, performs a countdown according to a random backoff count value selected by the STA4, and starts frame transmission.
  • the remaining backoff time of STA5 coincides with an arbitrary backoff count value of STA4.
  • a collision may occur between STA4 and STA5. If a collision occurs, neither STA4 nor STA5 receive an ACK, and thus data transmission fails. In this case, STA4 and STA5 may double the CW value, select a random backoff count value, and perform a countdown.
  • the STA1 waits while the medium is occupied due to transmission of the STA4 and STA5, waits for DIFS when the medium is idle, and starts frame transmission after the remaining backoff time passes.
  • the CSMA / CA mechanism includes virtual carrier sensing in addition to physical carrier sensing in which the AP and / or STA directly sense the medium.
  • Virtual carrier sensing is intended to compensate for problems that may occur in media access, such as a hidden node problem.
  • the MAC of the WLAN system may use a network allocation vector (NAV).
  • the NAV is a value in which an AP and / or STA currently using or authorized to use a medium instructs another AP and / or STA how long to remain until the medium becomes available.
  • the value set to NAV corresponds to a period in which the medium is scheduled to be used by the AP and / or STA transmitting the corresponding frame, and the STA receiving the NAV value is prohibited from accessing the medium during the period.
  • the NAV may be set, for example, according to the value of the "duration" field of the MAC header of the frame.
  • 5 is a diagram for explaining hidden nodes and exposed nodes.
  • 5A illustrates an example of a hidden node, in which STA A and STA B are in communication and STA C has information to transmit.
  • STA A may be transmitting information to STA B, it may be determined that the medium is idle when STA C performs carrier sensing before sending data to STA B. This is because transmission of STA A (ie, media occupation) may not be sensed at the location of STA C.
  • STA B since STA B receives the information of STA A and STA C at the same time, a collision occurs.
  • STA A may be referred to as a hidden node of STA C.
  • FIG. 5B is an example of an exposed node
  • STA B is a case in which STA C has information to be transmitted from STA D while transmitting data to STA A.
  • FIG. 5B is an example of an exposed node
  • STA C is a case in which STA C has information to be transmitted from STA D while transmitting data to STA A.
  • FIG. 5B when STA C performs carrier sensing, it may be determined that the medium is occupied by the transmission of STA B. Accordingly, since STA C is sensed as a medium occupancy state even if there is information to be transmitted to STA D, it must wait until the medium becomes idle. However, since STA A is actually outside the transmission range of STA C, transmission from STA C and transmission from STA B may not collide with STA A's point of view, so STA C is unnecessary until STA B stops transmitting. To wait. At this time, STA C may be referred to as an exposed node of STA B.
  • FIG. 6 is a diagram for explaining an RTS and a CTS.
  • a short signaling packet such as a request to send (RTS) and a clear to send (CTS) may be used.
  • RTS request to send
  • CTS clear to send
  • the RTS / CTS between the two STAs may allow the surrounding STA (s) to overhear, allowing the surrounding STA (s) to consider whether to transmit information between the two STAs. For example, when an STA to transmit data transmits an RTS frame to an STA receiving the data, the STA receiving the data may inform the neighboring STAs that they will receive the data by transmitting the CTS frame.
  • FIG. 6A illustrates an example of a method for solving a hidden node problem, and assumes that both STA A and STA C try to transmit data to STA B.
  • FIG. 6A When STA A sends the RTS to STA B, STA B transmits the CTS to both STA A and STA C around it. As a result, STA C waits until data transmission between STA A and STA B is completed, thereby avoiding collision.
  • FIG. 6 (b) illustrates an example of a method for solving an exposed node problem
  • STA C overhears RTS / CTS transmission between STA A and STA B so that STA C may use another STA (eg, STA). It may be determined that no collision will occur even if data is transmitted to D). That is, STA B transmits the RTS to all neighboring STAs, and only STA A having the data to actually transmit the CTS. Since STA C receives only RTS and not STA A's CTS, it can be seen that STA A is out of STC C's carrier sensing.
  • the WLAN system channel sensing must be performed before the STA performs transmission and reception, and always sensing the channel causes continuous power consumption of the STA.
  • the power consumption in the receive state is not significantly different from the power consumption in the transmit state, and maintaining the receive state is also a great burden for the power limited STA (ie, operated by a battery). Therefore, if the STA maintains a reception standby state in order to continuously sense the channel, it inefficiently consumes power without any particular advantage in terms of WLAN throughput.
  • the WLAN system supports a power management (PM) mode of the STA.
  • PM power management
  • the power management mode of the STA is divided into an active mode and a power save (PS) mode.
  • the STA basically operates in the active mode.
  • the STA operating in the active mode maintains an awake state.
  • the awake state is a state in which normal operation such as frame transmission and reception or channel scanning is possible.
  • the STA operating in the PS mode operates by switching between a sleep state (or a doze state) and an awake state.
  • the STA operating in the sleep state operates at the minimum power, and does not perform frame scanning as well as channel scanning.
  • the STA operates in the sleep state for as long as possible, power consumption is reduced, so the STA has an increased operation period. However, it is impossible to operate unconditionally long because frame transmission and reception are impossible in the sleep state. If there is a frame to be transmitted to the AP, the STA operating in the sleep state may transmit the frame by switching to the awake state. On the other hand, when the AP has a frame to transmit to the STA, the STA in the sleep state may not receive it and may not know that there is a frame to receive. Accordingly, the STA may need to switch to the awake state according to a specific period in order to know whether or not the frame to be transmitted to (or, if there is, receive it) exists.
  • the AP may transmit a beacon frame to STAs in the BSS at regular intervals.
  • the beacon frame may include a traffic indication map (TIM) information element.
  • the TIM information element may include information indicating that the AP has buffered traffic for STAs associated with the AP and transmits a frame.
  • the TIM element includes a TIM used to inform unicast frames and a delivery traffic indication map (DTIM) used to inform multicast or broadcast frames.
  • DTIM delivery traffic indication map
  • 7 to 9 are diagrams for explaining in detail the operation of the STA receiving the TIM.
  • the STA may switch from the sleep state to the awake state to receive a beacon frame including the TIM from the AP, interpret the received TIM element, and know that there is buffered traffic to be transmitted to the AP. .
  • the STA may transmit a PS-Poll frame to request an AP to transmit a data frame.
  • the AP may transmit the frame to the STA.
  • the STA may receive a data frame and transmit an acknowledgment (ACK) frame thereto to the AP.
  • the STA may then go back to sleep.
  • ACK acknowledgment
  • the AP may operate according to an immediate response method of transmitting a data frame after a predetermined time (for example, a short inter-frame space (SIFS)) after receiving a PS-Poll frame from an STA. Can be. Meanwhile, when the AP fails to prepare a data frame to be transmitted to the STA during the SIFS time after receiving the PS-Poll frame, the AP may operate according to a deferred response method, which will be described with reference to FIG. 8.
  • a predetermined time for example, a short inter-frame space (SIFS)
  • SIFS short inter-frame space
  • the STA switches from the sleep state to the awake state to receive the TIM from the AP and transmits the PS-Poll frame to the AP through contention as in the example of FIG. 7. If the AP does not prepare a data frame during SIFS even after receiving the PS-Poll frame, the AP may transmit an ACK frame to the STA instead of transmitting the data frame. When the data frame is prepared after transmitting the ACK frame, the AP may transmit the data frame to the STA after performing contention. The STA may transmit an ACK frame indicating that the data frame was successfully received to the AP and go to sleep.
  • STAs may transition from a sleep state to an awake state to receive a beacon frame containing a DTIM element from the AP. STAs may know that a multicast / broadcast frame will be transmitted through the received DTIM.
  • the AP may transmit data (ie, multicast / broadcast frame) immediately after the beacon frame including the DTIM without transmitting and receiving the PS-Poll frame.
  • the STAs may receive data while continuously awake after receiving the beacon frame including the DTIM, and may switch back to the sleep state after the data reception is completed.
  • FIG. 10 is a diagram for explaining an example of a frame structure used in an IEEE 802.11 system.
  • the Physical Layer Protocol Data Unit (PPDU) frame format may include a Short Training Field (STF), a Long Training Field (LTF), a SIG (SIGNAL) field, and a Data field.
  • STF Short Training Field
  • LTF Long Training Field
  • SIGNAL SIGNAL
  • Data field a Data field.
  • the most basic (eg, non-HT) PPDU frame format may include only a legacy-STF (L-STF), a legacy-LTF (L-LTF), a SIG field, and a data field.
  • the STF is a signal for signal detection, automatic gain control (AGC), diversity selection, precise time synchronization, etc.
  • the LTF is a signal for channel estimation, frequency error estimation, and the like.
  • the STF and LTF may be referred to as a PLCP preamble, and the PLCP preamble may be referred to as a signal for synchronization and channel estimation of an OFDM physical layer.
  • the SIG field may include a RATE field and a LENGTH field.
  • the RATE field may include information about modulation and coding rate of data.
  • the LENGTH field may include information about the length of data.
  • the SIG field may include a parity bit, a SIG TAIL bit, and the like.
  • the data field may include a SERVICE field, a physical layer service data unit (PSDU), a PPDU TAIL bit, and may also include a padding bit if necessary.
  • Some bits of the SERVICE field may be used for synchronization of the descrambler at the receiving end.
  • the PSDU corresponds to an MPDU (MAC Protocol Data Unit) defined in the MAC layer and may include data generated / used in an upper layer.
  • the PPDU TAIL bit can be used to return the encoder to zero.
  • the padding bit may be used to adjust the length of the data field in a predetermined unit.
  • the MPDU is defined according to various MAC frame formats, and the basic MAC frame is composed of a MAC header, a frame body, and a frame check sequence (FCS).
  • the MAC frame may be composed of MPDUs and may be transmitted / received through the PSDU of the data portion of the PPDU frame format.
  • the MAC header includes a frame control field, a duration / ID field, an address field, and the like.
  • the frame control field may include control information required for frame transmission / reception.
  • the duration / ID field may be set to a time for transmitting the corresponding frame.
  • the duration / ID field included in the MAC header may be set to 16 bits long (e.b., B0 to B15).
  • the content included in the period / ID field may vary depending on the frame type and subtype, whether the content is transmitted during the CFP (contention free period), the QoS capability of the transmitting STA, and the like.
  • the duration / ID field may include the AID of the transmitting STA (e.g., via 14 LSB bits) and the 2 MSB bits may be set to one.
  • the period / ID field may be set to a fixed value (e.g., 32768).
  • the duration / ID field may include a duration value defined for each frame type.
  • Sequence Control, QoS Control, and HT Control subfields of the MAC header refer to the IEEE 802.11 standard document.
  • the frame control field of the MAC header may include Protocol Version, Type, Subtype, To DS, From DS, More Fragment, Retry, Power Management, More Data, Protected Frame, Order subfields.
  • the content of each subfield of the frame control field may refer to an IEEE 802.11 standard document.
  • FIG. 11 illustrates a content free (CF) -END frame.
  • a CF-END frame is transmitted by a non-directional multi-gigabit (11ad) STA.
  • the CF-END frame may be sent to truncate the TXOP duration. Therefore, the duration field in the CF-END frame is set to zero.
  • the RA (Receiver Address) field may be set to a broadcast group address.
  • the BSSID field may be set to the address of the STA included in the AP.
  • the Individual / Group bit of the BSSID field may be set to 1.
  • HE PPDU High Efficiency Physical layer Protocol Data Unit
  • the HE-SIG A (or HE-SIG1) field is located after an L-Part (eg, L-STF, L-LTF, L-SIG), and repeats in 20 MHz units as in the L-Part. (duplication).
  • L-Part eg, L-STF, L-LTF, L-SIG
  • HE-SIG A includes common control information (e.g., BW, GI length, BSS index, CRC, Tail, etc.) for STAs.
  • the HE-SIG A field contains information for interpreting the HE PPDU, so the information contained in the HE-SIG A field may vary depending on the format of the HE PPDU (eg, SU PPDU, MU PPDU, or trigger-based PPDU).
  • the HE-SIG A field may include a DL / UL indicator, an HE PPDU format indicator, BSS Color, TXOP Duration, BW (bandwidth), MCS, CP + LTF length, coding information, number of streams, STBC (eg, use of STBC), transmission beamforming (TxBF) information, CRC, and Tail.
  • the HE-SIG B field may be omitted.
  • the HE-SIG A field may include a DL / UL indicator, a BSS Color, a TXOP Duration, a bandwidth (BW), MCS information of the SIG B field, a symbol number of the SIG B field, a HE LTF symbol number, and a full band. It may include at least one of the MU-MIMO usage indicator, CP + LTF length, transmission beamforming (TxBF) information, CRC and Tail.
  • the HE-SIG A field may include at least one of a format indicator (e.g., SU PPDU or trigger based PPDU), BSS Color, TXOP Duration, BW, CRC, and Tail.
  • the HE-SIG A may include user allocation information such as STA identifiers such as PAID or GID, allocated resource information, and number of streams (Nsts). At least one may be included.
  • the HE-SIG B (or HE-SIG2) may be transmitted for each OFDMA allocation.
  • the HE-SIG B is distinguished by the STA through the SDM.
  • the HE-SIG B may include additional user allocation information, for example, MCS, Coding information, Space Time Block code (STBC) information, TX Beamforming (TXBF) information, and the like.
  • HE-SIG B is sent after HE-SIG A.
  • the HE-SIG B may be transmitted through a full band based on the information (numerology) of the HE-SIG A.
  • the HE-SIG B may include user allocation information, for example, STA AID, resource allocation information (e.g., allocation size), MCS, stream number (Nsts), Coding, STBC, transmission beamforming (TXBF), and the like.
  • the HE-SIG B may be repeatedly transmitted for every unit channel.
  • the HE-SIG B may be repeatedly transmitted in units of 20 MHz.
  • the HE-SIG B may be transmitted by copying the same information per 20 MHz on an 80 MHz bandwidth.
  • the STA / AP that receives the HE-SIGB repeatedly transmitted per 20MHz channel may accumulate the HE-SIG B received per 20MHz channel to improve reliability of HE-SIG B reception.
  • the gain of the accumulated signal may be improved in proportion to the number of channels through which the signal is repeatedly transmitted.
  • a signal that is repeatedly transmitted may have a gain of 3 dB X number of channels compared to a signal before being repeatedly transmitted. Therefore, the HE-SIG B repeatedly transmitted may be transmitted by increasing the MCS level according to the number of repeatedly transmitted channels. For example, assuming that MCS0 is used for HE-SIG B when there is no repetitive transmission, MCS1 may be used for HE-SIG B repeatedly transmitted using 40 MHz. As the number of channels for repetitive transmission increases, the HE-SIG B can be transmitted through a higher MCS level, so the overhead of HE-SIG B per unit channel can be reduced.
  • the HE-SIG B may include independent information for each 20 MHz channel unit.
  • the HE-SIG B may be transmitted in a 1x symbol structure in the same manner as the legacy parts (e.g., L-STF, L-LTF, L-SIG) and HE-SIG A.
  • the length of “L-STF + L-LTF + L-SIG + HE-SIGA + HE-SIGB” should be the same in all channels.
  • the HE-SIG B transmitted per 20 MHz may include allocation information for the corresponding band, for example, allocation information for each user using the corresponding band, a user identifier, and the like.
  • the length of the HE-SIG B may be different from each other for each channel.
  • FIG. 17 illustrates a padding scheme for HE-SIG B in order to configure the length before the HE-STF (e.g., the length up to HE-SIG B) for each channel.
  • the HE-SIG B length may be aligned by repeating the HE-SIG B by a padding length.
  • the HE-SIG B may be padded to the HE-SIG B by the required padding length from the beginning (or the last) of the HE-SIG B.
  • one HE-SIG B field may be transmitted.
  • channels of 20 MHz size are each type 1 HE-SIG B (hereafter HE-SIG B [1]) or type 2 HE-SIG B (hereafter HE-SIG B [2]).
  • HE-SIG B [1] and the HE-SIG B [2] may be alternately transmitted.
  • the odd 20 MHz channel may transmit HE-SIG B [1] and the even 20 MHz channel may transmit HE-SIG B [2].
  • HE-SIG B [1] is transmitted on the first 20 MHz channel and HE-SIG B [2] is transmitted on the second 20 MHz channel.
  • HE-SIG B [1] is transmitted on the first 20 MHz channel
  • HE-SIG B [2] is transmitted on the second 20 MHz channel
  • the same HE-SIG B [1] is transmitted on the third
  • the same HE-SIG B [2] is repeated on the fourth 20 MHz channel. Similar transmission in the 160 MHz bandwidth.
  • the HE-SIG B may be repeatedly transmitted as the size of the bandwidth increases, and the HE-SIG B repeatedly transmitted is 20 MHz in size from the 20 MHz channel to which the same type of HE-SIG B is transmitted. It can be hopped and sent.
  • contents of the HE-SIG B [1] and the HE-SIG B [2] may be different.
  • the HE-SIG-Bs [1] all have the same content.
  • HE-SIG B [2] all have the same content.
  • HE-SIG B [1] includes only resource allocation information for odd 20 MHz channels, and HE-SIG B [2] contains only resource allocation information for even 20 MHz channels. It can be set to.
  • the HE-SIG B [1] includes resource allocation information for at least some of the even 20 MHz channels, or the HE-SIG B [2] is the odd 20 MHz channels. It may include resource allocation information for at least some of the.
  • the HE-SIG B may include a common field and a user specific field.
  • the common field may precede the user specific field.
  • the common field and the user specific field may be distinguished in bit units, not in OFDM symbol units.
  • the common field of the HE-SIG B includes information on all of the STAs designated to receive the PPDU in the corresponding bandwidth.
  • the common field may include resource unit (RU) allocation information.
  • the content is the same between the HE-SIG B [1], and the content is the same between the HE-SIG B [2]. For example, when dividing four 20 MHz channels constituting 80 MHz into [LL, LR, RL, RR], a common block for LL and RL is included in a common field of HE-SIG B [1], and HE- A common block for LR and RR may be included in a common field of SIG B [2].
  • the user specific field of the HE-SIG B may include a plurality of user fields, and each user field may include information specific to an individual STA designated to receive a PPDU.
  • the user field may include, but is not limited to, at least one of a station ID, an MCS for each STA, a stream number (Nsts), a coding (e.g., an indication for using an LDPC), a DCM indicator, and transmission beamforming information.
  • FIG 19 illustrates an uplink multi-user transmission situation according to an embodiment of the present invention.
  • a UL MU transmission scheme may be used, which means that the AP transmits a trigger frame to a plurality of STAs (eg, STA 1 to STA 4) as illustrated in FIG. 19. Can be started by.
  • the trigger frame may include UL MU allocation information.
  • the UL MU allocation information may include, for example, at least one of resource location and size, STA IDs or receiving STA addresses, MCS, and MU type (MIMO, OFDMA, etc.).
  • the trigger frame may include at least one of (i) a duration for the UL MU frame, (ii) the number of allocations (N), and (iii) information of each allocation.
  • the information of each allocation may include per user information.
  • the information of each allocation is, for example, AID (in addition, in the case of MU, additionally included by the number of STAs), power adjustment, resource (or tone) allocation information (eg, bitmap), MCS, number of streams (Nsts), It may include at least one of information on STBC, coding, and transmission beamforming.
  • the AP may acquire a TXOP for transmitting a trigger frame through a competition process to access a medium.
  • the STAs may transmit the UL data frame in the format indicated by the AP after SIFS of the trigger frame.
  • an AP performs an acknowledgment on a UL MU data frame through a block ACK (BA) frame.
  • BA block ACK
  • FIG. 20 illustrates a trigger frame format according to an embodiment.
  • a trigger frame includes a frame control field, a duration field, a recipient STA address field, a transmitting STA address field, a common information field, and one or two. It may include at least one of the above Per User Info fields and the Frame Check Sum (FCS).
  • the RA field indicates an address or ID of a receiving STA and may be omitted according to an embodiment.
  • the TA field indicates the address of the transmitting STA.
  • the common information field may include a length subfield, a cascade indication, a HE-SIG A information subfield, a CP / LTF type subfield, a trigger type subfield, and a trigger-dependent common information.
  • Common Info may include at least one of the subfields.
  • the length subfield indicates the L-SIG length of the UL MU PPDU.
  • the cascade indicator indicates whether there is a transmission of a subsequent trigger frame after the current trigger frame.
  • the HE-SIG A information subfield indicates content included in HE-SIG A of the UL MU PPDU.
  • the CP / LTF type subfield indicates the CP and the HE LTF type included in the UL MU PPDU.
  • the trigger type subfield indicates the type of trigger frame.
  • the trigger frame may include type-specific common information and type-specific individual user information (Per User Info).
  • the trigger type may include, for example, a basic trigger type (eg, type 0), a beamforming report poll trigger type (eg, type 1), and a multi-user block ack request (MU-BAR) type (eg, Type 2) or multi-user ready to send (MU-RTS) type (eg, type 3) may be set, but is not limited thereto.
  • MU-BAR multi-user block ack request
  • MU-RTS multi-user ready to send
  • the trigger dependent common information subfield may include a GCR (Groupcast with Retries) indicator and a GCR address.
  • the Per User Info field includes a user identifier subfield, a resource unit (RU) allocation subfield, a coding type subfield, an MCS field, a dual sub-carrier modulation (DCM) subfield, and a spatial stream (SS) assignment. It may include at least one of a subfield and a trigger dependent per user info subfield.
  • the user identifier subfield indicates the AID of the STA that will use the corresponding resource unit in order to transmit the MPDU of the UL MU PPDU.
  • the RU allocation subfield indicates a resource unit for transmitting the UL MU PPDU by the corresponding STA.
  • the coding type subfield indicates the coding type of the UL MU PPDU transmitted by the corresponding STA.
  • the MCS subfield indicates the MCS of the UL MU PPDU transmitted by the corresponding STA.
  • the DCM subfield indicates information about dual carrier modulation of the UL MU PPDU transmitted by the corresponding STA.
  • the SS assignment subfield indicates information about spatial streams of the UL MU PPDU transmitted by the corresponding STA. If the trigger type is MU-BAR, the trigger dependent individual user information subfield may include BAR control and BAR information.
  • the NAV may be understood as a kind of timer for protecting a transmitting STA (e.g., TXOP holder) TXOP.
  • the STA may protect the TXOP of another STA by not performing channel access while the NAV configured for the STA is valid.
  • a non-DMG STA supports one NAV.
  • the STA may update the NAV through a duration field (e.g., a duration field of the MAC header) of the PSDU.
  • a duration field e.g., a duration field of the MAC header
  • the STA does not update the NAV.
  • the duration indicated by the duration field of the received frame is greater than the current NAV value of the STA, the STA updates the NAV through the duration of the received frame.
  • a Source STA transmits an RTS frame and a Destination transmits a CTS frame.
  • the destination STA designated as the receiver through the RTS frame does not set the NAV.
  • Some of the remaining STAs may receive the RTS frame to set up the NAV, and others may receive the CTS frame to set up the NAV.
  • the RTS STAs that set or update the NAV through the frame may reset (eg, 0) the NAV.
  • the period of time may be (2 * aSIFSTime + CTS_Time + aRxPHYStartDelay + 2 * aSlotTime).
  • the CTS_Time may be calculated based on the length and data rate of the CTS frame indicated by the RTS frame.
  • the NAV is set or updated through an RTS frame or a CTS frame.
  • the NAV setting / resetting / update is performed by using various other frames such as non-HT PPDU, HT PPDU, VHT PPDU, or HE PPDU. It may be performed based on a duration field (eg, a duration field in the MAC header of the MAC frame). For example, if the RA field in the received MAC frame does not match its address (e.g., MAC address), the STA may set / reset / update the NAV.
  • the TXOP holder STA may truncate the TXOP by transmitting a CF-END frame.
  • the STA receiving the CF-END frame or the CF-END + CF-ACK frame may reset (e.g., 0) the NAV.
  • the STA When the STA, which has obtained channel access through the EDCA, has emptied its transmission queue, it may transmit a CF-END frame.
  • the STA may explicitly indicate the completion of its TXOP through the transmission of the CF-END frame.
  • the CF-END frame can be transmitted by the TXOP holder. Non-AP STAs other than the TXOP holder cannot transmit CF-END frames.
  • the STA receiving the CF-END frame resets the NAV at the end of the PPDU including the CF-END frame.
  • an STA accessing a medium through EDCA transmits a sequence (e.g., RTS / CTS, etc.) for NAV configuration.
  • a sequence e.g., RTS / CTS, etc.
  • the TXOP holder (or TXOP initiator) and the TXOP responder send and receive PPDUs (e.g., initiator sequence).
  • the TXOP holder truncates the TXOP by sending a CF-END frame when there is no more data to transmit within the TXOP limit.
  • the STAs Upon receiving the CF-END frame, the STAs can reset their NAV and start contending for media access without further delay.
  • the TXOP duration is set through the Duration field of the MAC header. That is, the TXOP holder (e.g., Tx STA) and the TXOP Responder (e.g., Rx STA) transmit all the TXOP information necessary for the transmission and reception of frames in the Duration field of frames transmitted and received therebetween.
  • Third party STAs ie, third party STAs that are not TXOP holders or TXOP Responders defer channel usage until the NAV period by checking the Duration field of the frame that is exchanged between the TXOP holder and the TXOP Responder and setting / updating the NAV. .
  • the third STAs cannot decode the MPDU included in the UL MU PPDU even if the UL MU PPDU is received. If the third STAs cannot decode the MPDU, the third STAs cannot obtain TXOP Duration information (e.g., Duration field) included in the MAC header of the MPDU. Therefore, there is a problem that NAV setting / update is difficult to be performed correctly.
  • TXOP Duration information e.g., Duration field
  • the third STAs cannot decode MAC frames transmitted and received by other STAs (eg, MPDUs of other STAs in the HE PPDU). Therefore, even in this case, there is a problem that the third STAs cannot obtain TXOP information.
  • a method for transmitting an STA by including TXOP duration information in the HE-SIG A is proposed.
  • 15 bits (e.g., B0 to 14) of the duration field of the MAC header may indicate duration information and may indicate a maximum of about 32.7 ms (0 to 32767 us). If the 15-bit duration information included in the duration field of the MAC header is transmitted to HE-SIG A as it is, the 11ax third party STA may correctly set / update NAV, but signaling over HE-SIG A There is a problem that the head is excessively increased.
  • HE-SIG A is a compactly designed field for transmitting common control information in the physical layer. The increase of corresponds to a relatively large signaling overhead.
  • an efficient indication method of TXOP duration to minimize overhead of HE-SIG A is proposed.
  • a frame transmission / reception operation based on a newly defined TXOP duration in HE-SIG A is proposed.
  • the included duration field of the MAC header may be referred to as MAC duration for convenience.
  • TXOP duration information is included in HE SIG A and transmitted.
  • the scope of the present invention is not limited thereto, and other parts (eg, L-SIG, HE-SIG B, and HE-SIG C) may be used. ,..., A-MPDU or part of the MPDU).
  • the common information eg, common part
  • SIG B contents transmitted to the first (or last) part of HE-SIG B can be sent from part (eg, Per user Info).
  • the value set in the NAV of the third STA may be interpreted as the TXOP Duration for the TXOP holder / Responder.
  • the Duration field value means TXOP for frame transmission / reception from the viewpoint of the TXOP holder / Responder, or NAV value from the viewpoint of the third STA. Therefore, since the operation of setting / updating the NAV by the third STAs sets the NAV as much as the TXOP of the TXOP holder / Responder, the operation of setting / updating the NAV by the third STAs is referred to as setting / updating the TXOP for convenience.
  • TXOP Duration may be referred to simply as Duration or may be referred to simply as TXOP.
  • TXOP Duration may optionally be used to refer to a field (e.g., TXOP Duration field in HE-SIG A) within a frame or may refer to an actual TXOP Duration value.
  • the TXOP duration may be set to 2 N ⁇ 1 (or 2 N ). For convenience, assume that TXOP duration is set to 2 N -1. N value may be transmitted in the TXOP duration field of HE-SIG A
  • N when N is 4 bits in size, N has a value of 0-15. Accordingly, the TXOP duration indicated through N of 4 bits may have a value of 0 ⁇ 32767 us.
  • This embodiment X * Y 2 -1 manner by the method of one example of indicating a TXOP duration and (in the case of eg, X 1), X and / or Y may be variously changed. In addition, X and Y values may be transmitted through the HE-SIG A field.
  • the TXOP duration may be set to X Y ⁇ 1 (or X Y ). For convenience, it is assumed to be set to X Y -1.
  • the STA may transmit X and Y values through a TXOP duration field (eg, in HE-SIG A).
  • n bits eg, the first n bits
  • m bits eg, the m bits after It can indicate the value of Y.
  • the n bits may be MSB n bits or LSB m bits
  • the m bits may be LSB m bits or MSB m bits.
  • K, m, n values can be set variously.
  • the TXOP duration value may have 0 to 279963us.
  • This embodiment is an example of one of the methods of indicating the TXOP duration in a Z * X Y -1 manner, and X, Y and / or Z can be variously changed.
  • TXOP duration it may be set to 2 * X -1 Y (or X * Y 2).
  • X and Y values may be transmitted through the TXOP duration field.
  • the TXOP duration field transmitted in HE-SIG A is a total of K bits
  • n bits eg, the first n bits
  • m bits eg, the m bits after It can indicate the value of Y.
  • the n bits may be MSB n bits or LSB m bits
  • the m bits may be LSB m bits or MSB m bits.
  • K, m, n values can be set variously.
  • TXOP duration value will be 0-7680us.
  • This embodiment is an example of one of the methods for indicating the TXOP duration in the X * Z Y -1 manner, and X, Y and / or Z can be variously changed.
  • the TXOP Duration may be set in another unit (e.g., larger unit or symbol unit) instead of 1 microsecond (us). For example, 4us, 8us, 10 us, 16us, 32us, 50us, 64us, 100us, 128us, 256us, 500us, 512us, 1024us,... Larger units may be used.
  • TXOP Duration is preferably to have a maximum value up to 8ms. Therefore, when a single unit is used, the following TXOP Duration field options may be considered.
  • Option 1 32 us units are used, and an 8-bit TXOP Duration field is defined.
  • the maximum TXOP duration value may be 8192us.
  • Option 2 64us units are used, and a 7-bit TXOP Duration field is defined.
  • the maximum TXOP duration value may be 8192us.
  • the size of the TXOP field is set to be larger than 8 bits (e.g, 9 to 11 bits)
  • the following TXOP Duration field structure may be used.
  • Option A-1 16us unit, ⁇ 32ms, 11 bits
  • Option A-2 16us unit, ⁇ 16ms, 10 bits
  • Option A-3 16us unit, ⁇ 8ms, 9 bits
  • Option B-1 32us unit, ⁇ 32ms, 10 bits
  • Option B-2 32us unit, ⁇ 16ms, 9 bits
  • Option C-1 64us unit, ⁇ 16ms, 9 bits
  • N * 1x symbol, N * 4x symbol units N may be a natural number
  • Table 1 illustrates the TXOP Duration indicated in units of 4x symbols.
  • the TXOP duration may be indicated through a combination of Embodiment 4 and one of Embodiments 1/2/3 described above.
  • the TXOP Duration field may have a predefined value.
  • a table that maps a value (e.g., TXOP duration index) set in a TXOP duration field and an actual TXOP duration value may be predefined.
  • Table 2 illustrates the TXOP duration index.
  • some ranges of the TXOP Duration may be expressed in the form of a first function, and other ranges may be expressed / configured in the form of a second function.
  • the TXOP Duration may be set to increase in the form of an exponential function up to a specific value, and increase in the form of a uniform distribution function after the specific value.
  • Table 3 exemplifies a case where the TXOP Duration field is set to 4 bits. Referring to Table 3, TXOP Duration increases exponentially from 32us to 512us (or 1024us), and increases by 512us (about 0.5ms) from 512us (1024us).
  • Table 4 illustrates a case where the TXOP Duration field is set to 5 bits. Referring to Table 4, the TXOP Duration increases exponentially from 32us to 256us (or 512us), and increases from 256us (512us) to 256us (0.25ms).
  • the TXOP Duration may be set through a scaling factor of X bits and a duration value of Y bits.
  • the TXOP duration may be set based on a Scaling factor (X bits) * Duration (Y bits).
  • TXOP duration Scaling factor (X bits) * Duration (Y bits).
  • the size of the TXOP duration field may be set to X + Y bits.
  • the unit of the duration value may be set to one of 1 us, 4 us, and 16 us by the scaling factor.
  • the length of the Y bits may be variously set.
  • Case A and Case B of Table 5 show examples of scaling factors each having a size of 2 bits.
  • Table 6 shows an example of a scaling factor of 3 bits.
  • the Duration value may be expressed in the form of 2 Y.
  • the TXOP Duration may be indicated through a scaling factor of X bits, a duration value of Y bits, and duration unit information of Z bits.
  • TXOP duration may be 'Scaling factor (X bits) * (Duration (Y bits) us * Duration unit (Z bits) us)'.
  • the size of the TXOP duration field may be set to (X + Y + Z) bits.
  • a duration unit having a Z bit size indicates a unit of duration information to be transmitted. For example, when the Z bit size is 1 bit, 0 may indicate 4us unit and 1 may indicate 16us unit, but is not limited thereto.
  • the TXOP duration field of the HE-SIG A may be set based on relatively large granularity.
  • the Duration field included in the MAC header may be indicated based on 1 us granularity
  • the TXOP duration field of HE-SIG A may be configured to indicate a TXOP duration value based on a larger granularity.
  • the TXOP duration is set based on relatively large granularity by the TXOP duration field of HE-SIG A
  • a longer time than that used for actual frame transmission may be set as the TXOP duration. Therefore, other STAs may set a wrong NAV based on HE-SIG A to prevent channel use for a specific time, and channel efficiency may be degraded.
  • TXOP early termination may be expressed as TXOP truncation or may be represented as early termination / truncation.
  • the TXOP holder / responder may terminate the TXOP by transmitting the CF-END frame after transmitting the last frame during the TXOP period.
  • a portion of the frame e.g., HE-SIG A, common part of HE-SIG B, etc.
  • the MD (More data) field or the ESOP field may be reused as a TXOP early termination indicator.
  • the early termination indicator may be transmitted through the last frame of the configured TXOP.
  • the TXOP Duration may be updated and transmitted along with the early termination indicator in the last frame.
  • TXOP Duration is set to a value smaller than the existing TXOP Duration, the termination of the TXOP may be indicated by the early termination indicator.
  • STA When updating TXOP information is required, STA (e.g., TXOP holder / responder) sets the TXOP to be updated when transmitting the frame and transmits the frame.
  • an early termination indicator is used as a TXOP update indicator. For example, whenever the TXOP is updated, the early termination indicator may be set to 1 and transmitted.
  • the TXOP duration may be set to the size of ACK / BA.
  • TXOP duration may be set for multiple frames and ACK / BA transmission.
  • (v) UL MU transmission If the trigger frame is transmitted in a non-HT PPDU (eg, 11a format), even if it is a legacy STA (eg, STA that does not support 11ax), the TXOP duration is indicated by the exact TXOP duration in the content of the trigger frame. Can be set correctly (eg, NAV settings / updates). In addition, since the UL MU frame indicates the TXOP duration by the transmission length of the ACK / BA frame, NAV setting / update is not a problem.
  • a non-HT PPDU eg, 11a format
  • the TXOP duration is indicated by the exact TXOP duration in the content of the trigger frame. Can be set correctly (eg, NAV settings / updates).
  • NAV setting / update is not a problem.
  • the 11ax format is used, and the TXOP duration set in the HE-SIG A is different from the TXOP duration information (e.g. TXOP duration of the MAC header) included in the content of the frame.
  • some STAs e.g., third party
  • other STAs e.g., third party
  • STAs that read both set the TXOP through the Duration information of the frame content (e.g., MAC header). For example, STAs that read both have duration information included in HE-SIG A, and after reading the Duration (or duration of Contents) of the MAC header, the STAs display the duration of the MAC header instead of the duration of HE-SIG A. Update the NAV by determining the final TXOP duration based on (or the duration of the contents).
  • the STAs that read only HE-SIG A update the NAV based on the TXOP duration included in HE-SIG A. Even in this case, the TXOP duration setting problem may be longer than the TXOP duration of the actual MAC header. For example, when the ACK / BA / M-BA frame for the UL MU frame is transmitted, the STA updates the TXOP through the TXOP duration information included in the HE-SIG A / B or MAC header (eg, NAV update). If the end instruction (or TXOP update indicator) is set to 1, the TXOP can be terminated at that time.
  • the end instruction or TXOP update indicator
  • termination of TXOP may be performed based on BSS color.
  • the STA e.g., third party
  • the STA may be configured to terminate TXOP only when TXOP termination is indicated through a frame corresponding to its BSS color.
  • STA e.g., third party
  • TXOP termination e.g., an explicit indicator or an implicit indication in which the duration is set to 0.
  • a loss of access opportunity of the corresponding STA for the Other BSS may occur.
  • the STA when the STA (e.g., TXOP holder / responder) transmits an 11ax frame in the TXOP, the STA may always include TXOP termination / truncation information in the last frame. Meanwhile, in the case of 11a frame, since TXOP is set through the duration of the MAC header, the correct TXOP may be set. According to an embodiment, the duration of the MAC header may be overwritten with the TXOP duration of the HE-SIG A.
  • the NAV update is performed only when the TXOP Duration value of the received frame is larger than the NAV value currently set in the STA (e.g., third party).
  • the STA may update the NAV with a TXOP duration smaller than the NAV value currently set in the STA, based on the above-described TXOP termination / update indicator.
  • updating the NAV with a TXOP duration smaller than the currently set NAV value may be set to be performed only based on the TXOP end / update indicator included in my BSS (my BSS) frame.
  • the STA maintains one NAV.
  • the STA receives a frame (e.g., a frame that does not indicate itself as a receiver)
  • the STA determines whether the NAV calculated by the duration field (e.g., MAC duration) in the MAC header of the frame is larger than the current NAV set in the STA. If the NAV calculated by the MAC duration is larger than the current NAV, the STA updates the NAV through the MAC duration.
  • the duration field e.g., MAC duration
  • the STA when the STA receives the CF-END frame when the current NAV of the STA managing only one NAV is not 0, the STA resets the NAV (e.g., sets the NAV timer to 0). However, if the NAV has been updated by multiple frames before the NAV reset, NAV reset by CF-END may affect other frame transmissions.
  • AP2 and STA 3 transmit and receive mutual frames, and for this purpose, NAV is configured in STA 2. Also, AP 2 and STA 3 are considered to have no influence on AP 1 and STA 1 in exchanging frames with each other. For example, assume that there is no influence between the channel access of (AP2, STA 3) and the channel access of (AP1, STA 1).
  • AP 1 and STA 1 may exchange RTS and CTS frames.
  • AP 1 designates STA 1 as a receiver and transmits an RTS frame.
  • STA 1 sends a CTS frame to AP 1 in response to the RTS.
  • the RA field of the CTS frame is set to be the same as the TA field of the RTS frame, the Duration of the CTS frame may be obtained from the Duration of the RTS frame, and the TA field may be omitted in the CTS frame.
  • STA 2 Although STA 2 has not received the RTS frame of AP 1, it is assumed that STA 2 has received the CTS frame of STA 1. Upon receiving the CTS frame of the STA 1, the STA 2 recognizes that it is not designated as the receiver of the CTS frame, and updates the NAV based on the Duration indicated by the CTS frame. For example, if the Duration indicated by the CTS frame is greater than the current NAV value of STA 2, STA 2 updates the NAV.
  • the AP 2 When the AP 2 receives the ACK from the STA 3, the AP 2 transmits a CF-END frame for TXOP truncation.
  • the AP 2 transmitting the CF-END frame cannot know that the NAV of the STA 2 has been updated by the CTS frame of the STA 1.
  • STA 2 resets the NAV based on the CF-END frame received from AP 2. For example, in case of STA 2, even though the NAV is updated for TXOP protection of AP 1 / STA 1, NAV reset is performed when a CF-END frame is received from AP 2.
  • the STA determines the identity between a receiver address (RA) and its address of the control frame. For frames that do not match the address of the STA, the STA manages one NAV regardless of the TXOP holder / responder.
  • RA receiver address
  • STA 2 that resets the NAV can access the channel, and thus can transmit data to the AP 2. However, transmission of the data frame of STA 2 affects data / ACK transmission and reception between AP1 and STA1.
  • NAV reset May affect the data transmission and reception of the TXOP holder / responder 1.
  • the following describes the NAV management (e.g., setting, updating and / or resetting) methods for solving the above-described problems of the NAV management operation.
  • the STA may manage the NAV in consideration of the BSS.
  • the STA may set and maintain the NAV for each BSS color.
  • the STA may truncate the TXOP of the NAV corresponding to the BSS Color indicated by the received frame.
  • the STA sets and sets two NAVs as My BSS (my BSS) NAV and Other BSS NAV (eg, a frame not indicating BSS or my BSS that is not my BSS). You can keep it.
  • the term internal BSS NAV may be referred to as intra BSS NAV.
  • the term Other BSS NAV may also be referred to as inter BSS NAV or regular NAV, or non-intra BSS NAV, but is not limited thereto.
  • the STA may maintain / manage the NAV through a combination of ⁇ RA (Receiver Address), TA (Transmitter Address) ⁇ or ⁇ SA (Source Address), DA (Destination Address) ⁇ .
  • each NAV is indexed by a combination of ⁇ RA, TA ⁇ .
  • the STA may maintain / manage the NAV for each BSS (eg, for each BSSID or BSS Color).
  • an STA that maintains / manages a NAV for each BSSID receives different frames having the same BSSID, and a duration indicated by a later received frame among those frames (eg, TXOP duration and / or MAC duration). Assume this is longer than the current NAV (eg, the current NAV for that BSSID).
  • the STA updates the NAV for the corresponding BSSID using the duration of the received frame.
  • a separate NAV may be set for a frame (e.g., ACK or CTS) that does not have a BSSID.
  • the STA may manage the NAV using a specific BSSID value (e.g., a virtual BSSID having a BSSID format rather than an actual BSSID).
  • a specific BSSID value may correspond to a CTS frame, an ACK frame, or a (CTS & ACK) frame. Therefore, even when the STA receives the CF-END, the NAV corresponding to CTS / ACK / (CTS & ACK) is maintained.
  • the STA may reset only the NAV corresponding to the BSSID included in the CF-END.
  • Table 8 illustrates a NAV set based on a BSSID.
  • NAV e.g., L
  • BSSID e.g., Z
  • NAV J / K for BSSID X / BSSID Y may not be set separately.
  • TXOPs of CTS & ACK, CTS and ACK frames may be integrated through NAV L indexed with BSSID Z.
  • the present invention is not limited thereto, and a BSSID and / or a NAV corresponding to another control frame or a management frame may be set.
  • the STA updates the NAV for the corresponding BSSID to the duration of the received ACK / CTS frame and updates the CTS / ACK-only NAV. You may not update it. For example, if a NAV exists for a BSS having a BSSID value set in the RA field, the STA preferentially performs an update on the corresponding NAV. However, if there is no NAV for the BSS having the BSSID value set in the RA field, the CTS / ACK-only NAV may be updated.
  • the STA may add or update the NAV using the mapped BSSID. If there is no BSSID mapped for the corresponding BSS Color, the STA may allocate and maintain one BSSID for the corresponding BSS Color. If the STA can read both the BSS Color and the BSSID in the frame, it can update the NAV corresponding to the BSSID.
  • Table 9 exemplifies NAV set for each BSS color.
  • the STA If the STA knows the BSSID information mapped for each BSS Color, and the BSSID information is included in a frame (eg, legacy frame such as 11a / b / g / n / 11ac (DL)) that does not include the BSS Color, Using the duration of the frame, the STA adds or updates the NAV for the BSS Color mapped to the BSSID.
  • a frame that does not include BSS Color and BSSID such as ACK / CTS
  • the STA maintains and manages the NAV by mapping a specific BSS Color value to the corresponding frames (eg, adding and updating). can do.
  • the NAV may be managed through a combination of ⁇ BSSID, BSS Color ⁇ .
  • Table 10 illustrates a NAV identified by a combination of ⁇ BSSID, BSS Color ⁇ .
  • the STA may maintain and manage one NAV (e.g., one NAV timer).
  • the STA may maintain information about which NAV was updated.
  • Table 11 illustrates the ID used for the last update of the NAV according to one embodiment of the present invention.
  • An identification used for updating the latest NAV may be mapped to the NAV.
  • the ID used for the last update of the NAV is, for example, BSS Color, BSSID, ⁇ BSSID, BSS Color ⁇ , RA, TA, SA, DA, ⁇ RA, TA ⁇ , ⁇ RA, SA ⁇ , ⁇ DA, SA ⁇ and ⁇ DA, TA ⁇ , but is not limited thereto.
  • Table 12 illustrates the case where the ⁇ RA, TA ⁇ combination is used.
  • Table 13 illustrates the case where the BSSID is used.
  • the STA updates the NAV by frames not including corresponding ID information
  • one of the methods mentioned in the above-described NAV management embodiment 2 may be used. For example, if a BSSID is used as shown in Table 13 and there is no BSSID (or information mapped to the BSSID) in the ACK / CTS frame, the STA maps a specific BSSID (eg, a virtual BSSID) to the ACK / CTS frame to update the NAV. Can be performed. For example, if the BSSID for the ACK / CTS is X, and the STA receives the ACK or the CTS, the ID (e.g., BSSID item) used for the last update of the NAV in the NAV table may be updated to X.
  • the ID e.g., BSSID item
  • the STA when the ID corresponding to the NAV is maintained together with the NAV, and the STA receives the frame indicating the TXOP truncation (eg, CF-END), the STA identifies IDs of the frame (eg, RA, TA, BSS Color, and BSSID). Etc.), the TXOP can be truncated only when one of the " For example, when the NAV is managed based on the BSSID as shown in Table 13, the STA may truncate the TXOP only when the CF-END frame includes information corresponding to the BSSID of the current NAV. If information corresponding to the current BSSID of the NAV is not included in the CF-END frame, the STA may not truncate the TXOP.
  • IDs of the frame eg, RA, TA, BSS Color, and BSSID.
  • the STA may maintain a list of ⁇ BSS Color, BSSID ⁇ by overhearing the transmitted frames.
  • the STA may acquire BSSID corresponding to the BSS Color or BSS Color information corresponding to the BSSID using the ⁇ BSS Color, BSSID ⁇ list.
  • Table 14 illustrates the case where a combination of ⁇ BSSID, BSS Color ⁇ is used.
  • the STA may obtain the BSS Color for the BSSID through various methods (e.g., management frame such as beacon, probe response, etc.). Therefore, when the STA receives a frame transmitted from the BSS, the STA may update the BSS Color and the BSSID together regardless of whether the frame is a legacy PPDU or a HE (i.e., 11ax) PPDU. For example, when the STA receives the 11ax PPDU including the BSS Color, the BSS Color and the BSSID may be updated together when updating the NAV. When the STA receives the legacy PPDU including the BSSID information, the BSSID and the BSS Color may be updated together when updating the NAV.
  • management frame such as beacon, probe response, etc.
  • the STA may truncate the NAV. If the information included in the frame and the BSSID / BSS color mapped to the current NAV do not match, the STA may not truncate the corresponding NAV.
  • the STA may set the BSSID mapped to NAV to 0.
  • the BSS Color mapped to the NAV may be set to 0.
  • the STA may update ⁇ BSSID, BSS Color ⁇ information mapped to the NAV, such as NAV.
  • the STA may map the ⁇ RA, TA ⁇ combination to the NAV for the control frame. Can be. After that, a frame indicating TXOP Truncation is received, and if the frame includes ID information corresponding to ID information (eg, ⁇ BSS Color, BSSID ⁇ or ⁇ RA, TA ⁇ ) mapped to the NAV, the STA indicates TXOP. If the received frame does not include ID information mapped to the NAV, the STA may not truncate the TXOP.
  • ID information eg, ⁇ BSS Color, BSSID ⁇ or ⁇ RA, TA ⁇
  • the STA may map ID Type information indicating whether the ID mapped to the NAV is a ⁇ BSS Color, BSSID ⁇ combination or a ⁇ RA, TA ⁇ combination to the corresponding NAV.
  • the STA can determine which ID is mapped to the NAV through the ID Type.
  • Table 15 illustrates ID type information according to an embodiment.
  • STAs when STAs receive a frame initiating TXOP, they may store a TXOP holder address.
  • TA Address 2, Transmitter address
  • RA Address 1, Receiver address
  • the STA may store the TXOP holder address together while updating the NAV based on the frames. Thereafter, when a CF-END frame indicating TXOP truncation is received, the STA compares the TA of the CF-End with the TXOP holder address mapped to the NAV. If the TA of the CF-END frame matches the TXOP holder address mapped to the NAV, the STA performs TXOP truncation. However, if the TA of the F-END frame does not match the TXOP holder address mapped to the NAV, the STA may maintain the NAV.
  • the STA may maintain NAV information before NAV update.
  • the NAV information may include, for example, at least one of a NAV value before updating and a TXOP holder information before updating.
  • the STA may not only maintain the TXOP Holder address for the current NAV but also maintain the previous NAV value and the TXOP Holder address for the previous NAV.
  • the STA may store the previous NAV timer at the time of NAV update, or may store a NAV difference value (NAV difference value) as information for calculating the previous NAV value.
  • NAV difference value NAV difference value
  • the STA may store ⁇ Duration-current NAV value indicated in the frame ⁇ as a NAV difference value.
  • the STA After receiving the CF-End frame and matching the TA of the CF-End frame with the TXOP holder address of the current NAV, the STA compares the TXOP holder address of the previous NAV with the TA of the CF-End frame instead of resetting the NAV. . If the TXOP holder address of the previous NAV and the TA of the CF-End frame match, the STA resets the NAV. However, if the TXOP holder address of the previous NAV and the TA of the CF-End frame do not match, the previous NAV value is restored without resetting the current NAV (e.g., using the NAV difference value). If the TA of the CF-End frame does not match the TXOP holder address of the current NAV, the STA maintains the current NAV.
  • the STA receiving the frame initiating the TXOP and storing the TXOP holder address may be limited to the address of the TXOP holder of the BSS to which the STA is associated.
  • the STA may be limited to storing only the address of the AP with which it associates as a TXOP holder address.
  • the TXOP holder address is TA (Address 2).
  • RA Address 1, AP address
  • TXOP holder address is a TXOP holder address.
  • the STA eg, AP or non-AP STA
  • the TXOP holder address (or the address of the TXOP holder to which the STA is associated) and / or the BSS color (the color of the BSS to which the STA is associated) ) can be stored.
  • the STA may store ⁇ TXOP holder address, BSS Color ⁇ of the corresponding BSS.
  • the TXOP holder address included in the frame is owned. If the MAC address of the associated AP matches, the STA may store the BSS Color for the AP as known in advance as the TXOP holder address.
  • the STA is accompanied by a NAV value. TXOP holder address, BSS color ⁇ .
  • the STA may perform NAV reset by checking the BSS Color.
  • the existing NAV update method after the NAV is set by the OBSS (other BSS) frame, my BSS frame is received, if the NAV value of my BSS frame is larger than the current NAV value (eg, the NAV set by the OBSS frame) , STA updates the NAV based on my BSS frame. For example, if a STA receives a frame (eg, CF-End / trigger frame / CTS / ACK / BA, etc.) requesting a NAV update (eg, change, reset, cancellation, etc.) from the STA / AP of my BSS, the STA The NAV is updated by receiving the frame.
  • a frame eg, CF-End / trigger frame / CTS / ACK / BA, etc.
  • a NAV update eg, change, reset, cancellation, etc.
  • STAs 1, 2, and 3 are associated with an AP, and STA3 receives a trigger frame (TF) 1 transmitted by my AP while receiving an OBSS frame and setting an NAV.
  • TF trigger frame
  • STA 3 since there is no resource allocation information for STA3 in TF1, if the duration value of TF1 is greater than the current NAV set in STA 3, STA 3 updates the NAV through the duration value of TF1.
  • STA3 may ignore the NAV and perform UL transmission. However, such UL transmission of STA 3 may affect OBSS.
  • OBSS NAV difference values may be referred to simply as NAV difference values.
  • the STA maintains one NAV timer, but when updating the NAV set by the OBSS frame based on the BSS frame, the STA may calculate and store the OBSS NAV difference value.
  • the OBSS NAV difference value may be calculated as ⁇ NAV Timer of Received BSS Frame-Current NAV Timer (e.g., NAV Timer most recently updated by OBSS) ⁇ .
  • the STA storing the OBSS NAV difference value is updated when the NAV is updated by my BSS frame (eg, when the current NAV is reset or the current NAV is ignored or not considered according to the indication of the trigger frame received from my AP).
  • the NAV difference value may be used to determine whether the OBSS NAV is valid at the present time.
  • the STA If the OBSS NAV is valid, the STA considers the OBSS NAV (e.g., withholding channel access until the OBSS NAV is terminated). The STA may check whether the OBSS NAV is valid by calculating ⁇ current NAV timer-NAV difference value ⁇ at the present time. For example, if ⁇ current NAV timer-NAV difference value ⁇ is greater than the OBSS NAV validity threshold (e.g., 0), the STA may determine that the OBSS NAV is valid. If ⁇ current NAV timer-NAV difference value ⁇ is less than or equal to 0, the STA may determine that the OBSS NAV is not valid.
  • the OBSS NAV validity threshold e.g., 0
  • the STA may no longer maintain the NAV difference value or set it to zero. In addition, if there is no NAV difference value or is set to 0, the STA may perform channel access without considering the OBSS NAV. If the STA considers the NAV, it may mean that the channel is busy and does not attempt to transmit the frame.
  • the NAV difference value stored in the STA may be used to determine whether the OBSS NAV timer, which would have been maintained in the STA if there was no NAV update by my BSS frame, expired at the present time or there is a remaining time.
  • 25 illustrates a method of managing NAV using NAV difference values.
  • STA3 maintains the NAV set by the OBSS, and then receives TF1 from the AP, which is an internal BSS (or intra BSS) STA.
  • STA 3 updates its NAV based on TF1 if the NAV (e.g., duration) of TF1 is greater than the current NAV (e.g., OBSS NAV).
  • the STA3 may calculate and store a NAV difference value (e.g., duration value of TF 1-current NAV timer).
  • STA3 checks whether the OBSS NAV is valid before performing transmission based on TF2. For example, if ⁇ current NAV timer-NAV difference value ⁇ exceeds the OBSS NAV validity threshold (e.g., 0), STA 3 may consider the OBSS NAV valid. STA3 may withhold frame transmission based on TF 2 while the OBSS NAV is valid.
  • the OBSS NAV validity threshold e.g., 0
  • the OBSS NAV difference value may not be valid when the NAV is updated by a frame of my BSS (e.g., an intra BSS frame).
  • 26 illustrates a NAV update based on a frame of my BSS.
  • the STA3 updates a NAV set through an OBSS frame through TF1 (e.g., received from an AP to which STA 3 is associated).
  • the STA 3 may calculate and store a NAV difference value (e.g., a NAV value based on a duration of a received frame-a current NAV value).
  • STA 3 receives TF2 and updates the NAV.
  • STA3 When STA 3 receives UL resource allocation through TF3, STA3 checks whether the OBSS NAV is valid using the NAV difference value. However, since the NAV difference value was calculated based on the previous NAV (eg, TF 1), the NAV difference value stored in STA3 may be inaccurate when TF 3 is received, and is suitable for OBSS NAV validation. You can't.
  • the STA may also update the NAV difference value.
  • the STA checks whether the OBSS NAV is valid using the NAV difference value. For example, if the result of calculating ⁇ current NAV value -NAV difference value ⁇ exceeds the OBSS NAV validity threshold (e.g., the default value is 0), the STA considers the OBSS NAV valid.
  • the OBSS NAV validity threshold e.g., the default value is 0
  • the STA may set the NAV difference value to zero.
  • an OBSS NAV difference value 0 may indicate that the OBSS NAV is not valid.
  • the STA can update the NAV difference value.
  • the STA may update the NAV difference value through the duration of the corresponding frame used for the NAV update. For example, the STA may update the NAV difference value with the value ⁇ NAV value (e.g., duration) by the corresponding frame)-(the current NAV value -NAV difference value) ⁇ , and may update its own NAV.
  • ⁇ NAV value e.g., duration
  • STA 3 receives TF1 from its AP and updates the NAV. Before STA 3 updates the NAV using the duration of TF1, STA3 calculates and stores a NAV difference value.
  • the STA 3 checks whether the OBSS NAV is valid in receiving the TF2 and performing the NAV update. If the OBSS NAV is valid, the STA 3 may update the NAV difference value based on the duration of the currently received frame (e.g., TF2). For example, the NAV difference value can be updated to ⁇ NAV value by received frame-(current NAV value-stored NAV difference value) ⁇ . STA 3 can then update the NAV via TF 2.
  • STA3 checks whether the OBSS NAV is valid using the NAV difference value. For convenience, assume that OBSS NAV is not valid. Accordingly, STA3 transmits a UL MU frame in response to TF 3.
  • the STA updates the NAV difference value to ⁇ current NAV value-NAV value by the received OBSS frame ⁇ .
  • the STA may maintain its NAV (e.g., current NAV value) as it is.
  • the NAV difference value update is for updating the OBSS NAV without updating the current NAV through the received OBSS frame.
  • STA 3 updates the NAV by OBSS frame 1, and then assumes that the NAV is updated by receiving TF1 from its AP.
  • the STA 3 calculates the NAV difference value before updating the NAV using the duration of TF1.
  • the NAV difference value may be ⁇ NAV by received frame (i.e., duration value of frame) -current NAV timer ⁇ .
  • the STA stores the calculated NAV difference value.
  • STA 3 receives TF2 but assumes that NAV update is not performed and therefore the current NAV timer is maintained.
  • the STA 3 receives the OBSS frame 2 from the OBSS STA, and checks whether the OBSS NAV is valid. Assume that OBSS NAV is valid. The STA3 checks whether the NAV (e.g., duration) due to the received OBSS frame 2 is greater than the OBSS NAV.
  • NAV e.g., duration
  • STA 3 recalculates the NAV difference value using the duration of the OBSS frame (e.g., update). For example, STA 3 may calculate the NAV difference value as ⁇ OBSS NAV by current NAV timer -OBSS frame 2 ⁇ , and STA3 may store the calculated NAV difference value.
  • STA 3 receives TF3 and is allocated UL resources through TF 3.
  • STA3 checks whether the OBSS NAV is valid using the NAV difference value before performing the UL transmission. For convenience, it is assumed that OBSS NAV is valid. Therefore, STA3 does not transmit the UL MU frame until the OBSS NAV expires.
  • the STA may maintain / manage internal BSS (e.g., intra BSS) NAV timers and OBSS (e.g., inter BSS) NAV timers, respectively. If NAV update is required by my BSS frame, the STA may update my BSS NAV timer. If NAV update is required by the OBSS frame, the STA may update the OBSS NAV timer.
  • BSS e.g., intra BSS
  • OBSS e.g., inter BSS
  • the STA 3 when the STA 3 receives the OBSS frame, the STA 3 updates the OBSS NAV timer (eg, update may mean one of setting, changing, and minimum / reset), and does not update my BSS NAV timer. Do not.
  • update may mean one of setting, changing, and minimum / reset
  • the STA3 When the STA3 receives my BSS frame, it sets or updates my BSS NAV timer and does not update the OBSS NAV timer.
  • the STA does not perform channel access.
  • the STA may maintain the same NAV timer instead of my BSS NAV timer.
  • the STA may maintain the NAV timer and the OBSS NAV timer operating in the same manner as before.
  • the existing NAV timer may be updated without distinguishing between intra BSS / inter BSS frames (e.g., as before), and the OBSS NAV timer may be updated only by OBSS (inter BSS) frames.
  • the STA may not transmit the UL MU frame in consideration of the OBSS NAV.
  • the STA may determine that the OBSS NAV is valid when the OBSS NAV timer is greater than the OBSS NAV validity threshold (e.g., the default value is 0).
  • the OBSS NAV validity threshold may be determined by the system and may be delivered to the STA through a broadcast / multicast frame or a unicast frame such as a beacon.
  • the STA maintains one NAV timer as before, but when the NAV set by the OBSS frame is updated by the BSS frame, the STA may calculate and store the OBSS NAV difference value.
  • the OBSS NAV difference value may be calculated as ⁇ NAV timer of received frame-current NAV timer ⁇ .
  • the NAV timer of the received frame may be calculated through the duration of the received frame, and the current NAV timer may be the NAV timer most recently updated by the OBSS.
  • OBSS NAV difference values may be referred to simply as NAV difference values.
  • the STA When the STA resets the current NAV (eg, CF-End reception) or attempts to transmit a frame without considering the current NAV (eg, when transmitting a UL frame based on a trigger frame), the STA receives the stored NAV difference value. Can be used to check if the OBSS NAV is valid.
  • the STA may check whether the OBSS NAV is valid by calculating a value of ⁇ current NAV timer-OBSS NAV difference value ⁇ at that time. For example, if the value of ⁇ current NAV timer-NAV difference value ⁇ is greater than the OBSS NAV validity threshold (eg, the default may be set to a value greater than 0), the STA determines that the OBSS NAV is valid. do. If ⁇ current NAV timer-NAV difference value ⁇ is less than or equal to 0, the STA may not maintain or set the OBSS NAV difference value to zero. If there is no NAV difference value or is set to 0, it may indicate that the OBSS NAV is invalid, and the STA may not consider the OBSS NAV.
  • the OBSS NAV validity threshold eg, the default may be set to a value greater than 0
  • the STA may operate in consideration of the OBSS NAV. For example, if the OBSS NAV is valid, the STA may not reset the NAV at the NAV reset time or may not transmit the frame at the time of frame transmission.
  • the fact that the STA considers the NAV may indicate that the channel is busy and does not attempt to transmit the frame, or may mean not to reset the OBSS NAV.
  • FIG. 30 illustrates a NAV management method according to an embodiment of the present invention.
  • STA 3 receives TF1 from the AP of my BSS. Assume that the NAV of TF 1 is greater than the current NAV. STA 3 updates the NAV based on TF1. At this time, the STA3 calculates and stores the NAV difference value ⁇ NAV timer of the TF 1-current NAV timer ⁇ .
  • STA 3 receives TF 2.
  • TF 3 includes scheduling information of STA3.
  • STA 3 further checks whether the OBSS NAV is valid before attempting UL transmission based on TF 2. On the other hand, since the current NAV of STA 3 is set by the intra BSS STA, STA 3 may not consider the current NAV.
  • STA3 may consider the OBSS NAV valid. STA 3 does not transmit the UL frame while the OBSS NAV is valid.
  • the STA may perform an operation of calculating and storing a NAV difference value even when the NAV set by MyBSS (or intra BSS) is updated by the OBSS (or intra BSS). For example, later, when the NAV is updated (e.g., reset / cancel) by the inter BSS frame, the STA checks whether the MyBSS NAV is valid. If MyBSS NAV is valid, the STA may operate in consideration of MyBSS NAV. Since the method of calculating the NAV difference value and checking the validity is redundant with the above description, description thereof is omitted.
  • the STA may update the current NAV to the OBSS NAV according to the reception of the CF-End frame from the intra BSS STA.
  • the STA can check whether the OBSS NAV is valid by checking the OBSS NAV timer value. If the OBSS NAV is valid, the STA sets the current NAV to the OBSS NAV timer value.
  • the STA may know whether the OBSS NAV is valid using the OBSS NAV difference value. If the OBSS NAV is valid, the STA may set the current NAV as the OBSS NAV using the OBSS NAV difference value. As described in Example 6-2 of NAV management, when the current NAV is updated by the OBSS frame, the STA may calculate the OBSS NAV difference value ⁇ NAV timer of the received frame-current NAV timer ⁇ .
  • the STA may consider the NAV or reset the NAV, depending on whether the current NAV is updated from the past NAV value or newly set.
  • whether to reset the NAV may be determined according to whether the NAV immediately before the current NAV was zero or non-zero.
  • an intra BSS STA e.g., AP
  • the methods described above can also be used when updating from an intra BSS (or My BSS) NAV to an inter BSS (or OBSS) NAV.
  • the value calculated and stored by the STA may be referred to as an intra BSS NAV difference value or an internal BSS NAV difference value instead of the NAV update indicator, but is not limited thereto.
  • a BSS NAV difference value For convenience, it will be referred to as a BSS NAV difference value.
  • the STA calculates a BSS NAV difference value of the STA.
  • the BSS NAV difference value may be calculated in a similar manner to the OBSS NAV difference value described above.
  • the my BSS NAV difference value may be calculated as ⁇ NAV value calculated by the currently received OBSS frame minus the current NAV value (e.g., my BSS NAV value) ⁇ .
  • NAV update my NAV is changed to OBSS NAV.
  • the STA may check whether the MyBSS NAV is valid using the stored My BSS NAV difference value.
  • the STA may check whether my BSS NAV is valid. If my BSS NAV is valid, the STA updates the current NAV (e.g., OBSS NAV) with my BSS NAV.
  • a frame e.g., CF-End
  • the STA may check whether my BSS NAV is valid. If my BSS NAV is valid, the STA updates the current NAV (e.g., OBSS NAV) with my BSS NAV.
  • the STA may determine that if the BSS NAV difference value is more than a certain threshold (e.g., the default value is 0), it is necessary to check whether the BSS NAV is valid.
  • a certain threshold e.g., the default value is 0
  • the STA may consider that my BSS NAV is valid if ⁇ current NAV value-my BSS NAV difference value ⁇ is greater than or equal to a certain threshold (e.g., the default value is 0).
  • a certain threshold e.g., the default value is 0
  • my BSS NAV may be ⁇ current NAV value-my BSS NAV difference value ⁇ .
  • the STA when the STA receives a CF-END frame from the OBSS STA, the STA must consider whether the current NAV (e.g., the most recent NAV update / set) is due to an intra BSS frame. If the most recent NAV update is due to an intra BSS frame, the STA does not reset the NAV based on the CF-END frame from the OBSS (e.g., protection of the intra BSS NAV).
  • the current NAV e.g., the most recent NAV update / set
  • intra BSS NAV not only intra BSS NAV but also inter BSS NAV need to be protected.
  • the STA must consider whether the current NAV (e.g., the most recent NAV update / configuration) is due to an inter BSS frame. If the most recent NAV update is due to an inter BSS frame, the STA may not reset the NAV based on the CF-END frame from my BSS (e.g., protection of the inter BSS NAV).
  • TXOP truncation by the intra BSS frame needs to be considered.
  • the method available for the TXOP truncation method and / or the UL MU frame response (e.g., trigger frame based transmission) by the intra BSS frame will be further described.
  • the NAV of the STA is set by the OBSS.
  • the STA receives a frame (e.g., TF or CTS, etc.) from its AP, it updates the NAV. Thereafter, when the AP transmits the CF-END frame, the STA resets the NAV. If the STA transmits a UL frame after NAV reset, there is a problem that the NAV of the OBSS cannot be protected.
  • a frame e.g., TF or CTS, etc.
  • FIG. 32 illustrates an NAV management scheme according to an embodiment of the present invention for solving the problem of FIG. 31. Description overlapping with FIG. 31 is omitted.
  • the STA when the STA receives a CF-END frame from its AP, the STA must first determine whether the OBSS NAV is valid before resetting the NAV. If the OBSS NAV is valid, the STA may not reset the NAV. For example, if the OBSS NAV is valid, the STA may update (e.g., restore) the current NAV with the OBSS NAV.
  • the STA may calculate and store the NAV difference value.
  • the NAV difference value may be ⁇ NAV value by received frame (e.g., intra BSS frame)-current NAV value ⁇ .
  • the STA receives a CF-END frame from its AP.
  • the STA checks whether the OBSS NAV is valid before resetting the NAV.
  • the validity of the OBSS NAV can be calculated based on the NAV difference value. For example, when ⁇ current (e.g., OBSS NAV validity check time) NAV value X-NAV difference value Y ⁇ is greater than 0, the STA may determine that the OBSS NAV is valid. For example, if there is a residual OBSS NAV under the assumption that there was no NAV update by an intra BSS frame, the STA may determine that the OBSS NAV is still valid.
  • the STA can update the current NAV with a valid OBSS NAV value (e.g., when my BSS NAV no longer needs to be protected due to CF-END frame reception, etc.).
  • NAV update via OBSS NAV value may be understood to restore the OBSS NAV value, which would have continued if the NAV was not updated by the intra BSS frame.
  • the STA can reset the NAV (e.g., when both the OBSS NAV and my BSS NAV need not be protected).
  • STA 5 calculates and stores the NAV difference value when updating the NAV (e.g., OBSS NAV) through TF1 (e.g., intra BSS frame).
  • NAV e.g., OBSS NAV
  • TF1 e.g., intra BSS frame
  • STA 5 receives TF 2. There is no NAV update by TF 2, and it is assumed that TF 2 includes resource allocation information for STA 5.
  • STA 5 checks whether the OBSS NAV is valid using the NAV difference value before transmitting the UL frame based on TF 2. For example, if ⁇ current (e.g., OBSS NAV check time) NAV value-NAV difference value ⁇ is greater than 0, STA 5 may assume that OBSS NAV is valid.
  • ⁇ current e.g., OBSS NAV check time
  • STA 5 does not perform UL frame transmission based on TF 2 while OBSS NAV is valid (e.g., consider OBSSS NAV).
  • the STA may manage a plurality of NAVs (e.g., two NAVs) through one NAV timer.
  • Multiple NAVs can include intra BSS NAV and non-intra BSS NAV.
  • the intra BSS NAV may be a NAV updated by an intra BSS frame.
  • Non-Intra BSS NAV is a frame that cannot be determined as a frame that is not an intra BSS frame or an intra BSS frame (eg, a frame that cannot distinguish whether it is an inter BSS frame or an intra BSS frame such as an inter BSS frame or a CTS / ACK). It may be a NAV updated by.
  • Non-intra BSS NAV may be referred to as regular NAV.
  • the STA may calculate and store the NAV difference value.
  • the NAV difference value may be ⁇ NAV value by received frame minus intra BSS NAV ⁇ or ⁇ NAV value by received frame minus inter BSS NAV ⁇ .
  • the STA may update its NAV (e.g., one NAV timer) through the duration of the inter BSS frame.
  • NAV e.g., one NAV timer
  • NAV difference value is 0, it may be that both NAVs are invalid or only the current NAV is valid.
  • the STA can check whether the two NAVs are valid. For example, if the values of the two NAVs are not all zeros, it is determined that both NAVs are valid. A NAV with a NAV value of 0 is determined to be invalid.
  • the NAV difference value may be used to determine the validity of two NAVs. For example, if ⁇ current NAV value (e.g., one NAV timer)-NAV difference value ⁇ is greater than zero, two NAVs are determined to be valid (e.g., since the current NAV value is not zero). However, if ⁇ the current NAV value-NAV difference value ⁇ is not greater than zero, only one NAV (e.g. intra BSS NAV or inter BSS NAV) is determined to be valid.
  • ⁇ current NAV value e.g., one NAV timer
  • the current NAV value-NAV difference value ⁇ is not greater than zero, only one NAV (e.g. intra BSS NAV or inter BSS NAV) is determined to be
  • the STA operates by considering both NAVs. If only the current NAV (e.g., intra BSS NAV or inter BSS NAV) is valid, the STA may operate by considering only the corresponding NAV.
  • the current NAV e.g., intra BSS NAV or inter BSS NAV
  • the STA receives a CF-END frame from the intra BSS STA. If both NAVs are valid, the STA updates the current NAV (e.g., one NAV timer) with a non-intra NAV (e.g., current NAV value-NAV difference value). If both NAVs are invalid, the STA resets the current NAV (e.g. one NAV timer) based on the CF-END frame.
  • the current NAV e.g., one NAV timer
  • a non-intra NAV e.g., current NAV value-NAV difference value
  • a current NAV (e.g., one NAV timer) is an intra BSS NAV
  • the STA receives a CF-END frame from an inter BSS STA. If both NAVs are valid, the STA does not reset the current NAV (e.g. one NAV timer) corresponding to the intra BSS. However, the STA can reset the non-intra NAV. Resetting the non-intra NAV may mean setting the NAV difference value to zero.
  • the STA receives a CF-END frame from an inter BSS STA. If both NAVs are valid, the STA updates the current NAV (e.g., one NAV timer) corresponding to the non-intra BSS with an intra NAV (e.g., current NAV value-NAV difference value). If both NAVs are invalid, the STA resets the current NAV (e.g. one NAV timer) based on the CF-END frame.
  • the current NAV e.g., one NAV timer
  • the STA receives a CF-END frame from the intra BSS STA. If both NAVs are valid, the STA does not reset the current NAV (e.g., one NAV timer) corresponding to the non-intra BSS. However, the STA may reset the intra NAV. Resetting the intra NAV may mean setting the NAV difference value to zero.
  • the STA may consider the NAV in transmitting the UL MU frame and the like, and in particular, the STA may manage a plurality of NAVs (e.g., intra BSS NAV / non-intra BSS NAV).
  • the STA may set multiple NAV timers in addition to the method of setting one NAV timer (e.g., using the NAV difference value). For example, separate NAV timers may be set for each of the intra BSS NAV and the non-intra BSS NAV.
  • the intra BSS NAV timer may be a NAV timer updated by an intra BSS frame / PPDU.
  • the non-intra BSS NAV timer may be an NAV timer that is not an intra BSS frame or is updated by a frame that cannot distinguish whether it is an intra BSS or an inter BSS.
  • the STA must consider the non-intra BSS NAV timer before transmitting the UL MU frame in response to the trigger frame.
  • the STA may reset the intra BSS NAV when the CF-END frame is received from the intra BSS, and may reset the non-intra BSS NAV when the CF-END frame is received from the inter BSS.
  • 35 illustrates two NAV timers according to an embodiment of the present invention.
  • the STA receives a frame such as a TF or CTS from an OBSS STA and sets a non-intra BSS NAV timer.
  • the STA receives a TF or CTS frame from its AP and starts an intra BSS NAV timer.
  • the STA resets the intra BSS NAV timer upon receiving the CE-END frame from its AP.
  • the STA may calculate and store a NAV difference value whenever the current NAV timer is changed from one NAV to another NAV.
  • the STA In an embodiment of managing two NAVs through two NAV timers, the STA must consider the non-intra BSS NAV before the UL MU frame transmission, and reset the corresponding NAV timer when a CF-END frame is received.
  • the STA receives a frame including duration information (S3605).
  • the interval information may be a TXOP duration value indicated by the TXOP duration field included in the HE-SIG A field or a MAC duration value indicated by the duration field included in the MAC header, but is not limited thereto.
  • the frame may be a control frame such as an RTS or CTS, a management frame, a trigger frame, a frame based on HE-PPDU, or a frame based on Non-HE PPDU, but is not limited thereto.
  • the STA selects a predetermined NAV among the plurality of NAVs (S3610).
  • a STA can have multiple NAVs. Multiple NAVs may include intra BSS NAV and non-intra BSS NAV.
  • the non-intra BSS NAV may be for another BSS (OBSS) frame.
  • the non-intra BSS NAV may be for a frame that cannot specify a BSS.
  • the frame for which the BSS cannot be specified may be, for example, a frame having no BSSID information in the RA field or the TA field (e.g., ACK, CTS, etc.).
  • the predetermined NAV may be selected based on whether the frame is received from a basic service set (BSS) to which the STA belongs. For example, the STA can determine whether a frame has been received from my BSS.
  • BSS basic service set
  • the STA selects the first NAV (eg, intra BSS NAV) if the frame is determined to be received from the BSS to which the STA belongs, and selects the second NAV if the frame is determined to be received from a BSS to which the STA does not belong (eg, non-). Intra BSS NAV). Additionally, the STA may select the second NAV (e.g., non-intra BSS NAV) even if it cannot determine from which BSS the frame is received.
  • the first NAV eg, intra BSS NAV
  • a BSS to which the STA does not belong eg, non-.
  • Intra BSS NAV Intra BSS NAV
  • the STA may select the second NAV (e.g., non-intra BSS NAV) even if it cannot determine from which BSS the frame is received.
  • the STA may manage a predetermined NAV based on the section information of the frame (S3615).
  • the NAV management may be any one of NAV initial setting, NAV update, or NAV reset, but is not limited thereto.
  • the STA may withhold channel access.
  • the STA may set a plurality of NAV timers corresponding to the plurality of NAVs.
  • the STA may set only one NAV timer. For example, multiple NAVs may be managed through a difference value between multiple NAVs and one NAV timer. When the value of one NAV timer is changed from the first NAV to the second NAV or from the second NAV to the first NAV, the difference value between the plurality of NAVs may be updated. In addition, the STA may determine the validity of the other NAV by using a difference value between a current value of one NAV and a plurality of NAVs mapped to one NAV timer.
  • the wireless device 800 of FIG. 37 may correspond to a specific STA of the above description, and the wireless device 850 may correspond to an AP of the above-described description.
  • the STA 800 may include a processor 810, a memory 820, a transceiver 830, and the AP 850 may include a processor 860, a memory 870, and a transceiver 880.
  • the transceivers 830 and 880 may transmit / receive wireless signals and may be executed at a physical layer, such as IEEE 802.11 / 3GPP.
  • Processors 810 and 860 run at the physical and / or MAC layers and are coupled to transceivers 830 and 880.
  • Processors 810 and 860 may perform the aforementioned UL MU scheduling procedure.
  • Processors 810 and 860 and / or transceivers 830 and 880 may include application-specific integrated circuits (ASICs), other chipsets, logic circuits and / or data processors.
  • the memories 820 and 870 may include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media and / or other storage units.
  • ROM read-only memory
  • RAM random access memory
  • flash memory memory cards
  • the method described above can be executed as a module (eg, process, function) that performs the functions described above.
  • the module may be stored in the memory 820, 870 and executed by the processors 810, 860.
  • the memories 820 and 870 may be disposed inside or outside the processes 810 and 860 and may be connected to the processes 810 and 860 by well-known means.
  • the present invention as described above has been described on the assumption that it is applied to a wireless LAN system supporting HE PPDU, it need not be limited thereto.
  • the present invention can be applied to various wireless communication systems including IEEE 802.11.

Abstract

본 발명의 일 실시예에 따라서 HE PPDU(high efficiency physical layer protocol data unit)를 지원하는 무선랜 시스템에서 스테이션(STA)이 NAV(network allocation vector)를 관리하는 방법은, 구간(duration) 정보를 포함하는 프레임을 수신하는 단계; 상기 STA이 갖는 다수의 NAV들 중에서 소정의 NAV를 선택하는 단계; 및 상기 프레임의 구간 정보에 기초하여 상기 소정의 NAV를 관리하는 단계를 포함하고, 상기 소정의 NAV는, 상기 프레임이 상기 STA이 속하는 BSS(basic service set)로부터 수신된 것인지 여부에 기초하여 선택될 수 있다.

Description

무선랜 시스템에서 NAV를 관리하는 방법 및 이를 위한 장치
본 발명은 무선랜 시스템에서 NAV(network allocation vector)를 관리하는 방법 및 장치에 관한 것으로, 보다 구체적으로는, 수신된 프레임에 기초하여 NAV를 관리하는 방법 및 이를 위한 장치에 대한 것이다.
무선랜 기술에 대한 표준은 IEEE(Institute of Electrical and Electronics Engineers) 802.11 표준으로서 개발되고 있다. IEEE 802.11a 및 b는 2.4. GHz 또는 5 GHz에서 비면허 대역(unlicensed band)을 이용하고, IEEE 802.11b는 11 Mbps의 전송 속도를 제공하고, IEEE 802.11a는 54 Mbps의 전송 속도를 제공한다. IEEE 802.11g는 2.4 GHz에서 직교 주파수 분할 다중화(Orthogonal frequency-division multiplexing, OFDM)를 적용하여, 54 Mbps의 전송 속도를 제공한다. IEEE 802.11n은 다중입출력 OFDM(multiple input multiple output-OFDM, MIMO-OFDM)을 적용하여, 4 개의 공간적인 스트림(spatial stream)에 대해서 300 Mbps의 전송 속도를 제공한다. IEEE 802.11n에서는 채널 대역폭(channel bandwidth)을 40 MHz까지 지원하며, 이 경우에는 600 Mbps의 전송 속도를 제공한다.
상술한 무선랜 표준은 최대 160MHz 대역폭을 사용하고, 8개의 공간 스트림을 지원하여 최대 1Gbit/s의 속도를 지원하는 IEEE 802.11ac 표준을 거쳐, IEEE 802.11ax 표준화에 대한 논의가 이루어지고 있다.
본 발명이 이루고자 하는 기술적 과제는, HE PPDU를 지원하는 무선랜 시스템에서 프레임을 전송한 BSS를 고려하여 NAV를 관리하는 방법 및 장치를 제공하는데 있다.
본 발명은 상술된 기술적 과제에 한정되지 않으며 다른 기술적 과제들이 본 발명의 실시예들로부터 유추될 수 있다.
상술된 기술적 과제를 이루기 위한 본 발명의 일 측면에 따른 HE PPDU(high efficiency physical layer protocol data unit)를 지원하는 무선랜 시스템에서 스테이션(STA)이 NAV(network allocation vector)를 관리하는 방법은, 구간(duration) 정보를 포함하는 프레임을 수신하는 단계; 상기 STA이 갖는 다수의 NAV들 중에서 소정의 NAV를 선택하는 단계; 및 상기 프레임의 구간 정보에 기초하여 상기 소정의 NAV를 관리하는 단계를 포함하고, 상기 소정의 NAV는, 상기 프레임이 상기 STA이 속하는 BSS(basic service set)로부터 수신된 것인지 여부에 기초하여 선택될 수 있다.
상술된 기술적 과제를 이루기 위한 본 발명의 다른 일 측면에 따른 HE PPDU(high efficiency physical layer protocol data unit)를 지원하는 무선랜 시스템에서 NAV(network allocation vector)를 관리하는 스테이션(STA)은, 구간(duration) 정보를 포함하는 프레임을 수신하는 수신기; 및 상기 STA이 갖는 다수의 NAV들 중에서 소정의 NAV를 선택하고, 상기 프레임의 구간 정보에 기초하여 상기 소정의 NAV를 관리하는 프로세서를 포함하고, 상기 소정의 NAV는, 상기 프레임이 상기 STA이 속하는 BSS(basic service set)로부터 수신된 것인지 여부에 기초하여 선택될 수 있다.
바람직하게는, 상기 STA은, 상기 프레임이 상기 STA이 속한 BSS로부터 수신된 것으로 결정되면 제1 NAV를 선택하고, 상기 프레임이 상기 STA이 속하지 않은 BSS로부터 수신된 것으로 결정되면 제2 NAV를 선택할 수 있다. 보다 바람직하게는, 상기 STA은, 상기 프레임이 어느 BSS로부터 수신된 것인지를 결정할 수 없는 경우 상기 제2 NAV를 선택할 수 있다.
바람직하게는, 상기 다수의 NAV들은, 인트라 BSS NAV 및 비-인트라 BSS NAV를 포함하고, 상기 비-인트라 BSS NAV는, OBSS(other BSS) 프레임을 위한 것일 수 있다. 보다 바람직하게는, 상기 비-인트라 BSS NAV는, BSS를 특정 할 수 없는 프레임을 위한 것일 수 있다. 보다 바람직하게는, 상기 BSS를 특정 할 수 없는 프레임은 ACK (acknowledgement) 프레임이거나 또는 CTS (clear-to-send) 프레임 일 수 있다.
바람직하게는, 상기 다수의 NAV들 중 어느 하나라도 0 보다 큰 값을 갖는 경우, 상기 STA은 채널 엑세스를 보류할 수 있다.
바람직하게는, 상기 STA은 상기 다수의 NAV들에 대응되는 다수의 NAV 타이머들을 설정할 수 있다.
바람직하게는, 상기 다수의 NAV들은, 상기 다수의 NAV들 간의 차이 값과 하나의 NAV 타이머를 통해서 관리될 수 있다.
보다 바람직하게는, 상기 하나의 NAV 타이머의 값이 상기 다수의 NAV들 중 제1 NAV로부터 제2 NAV로 변경되는 경우, 상기 다수의 NAV들 간의 차이 값이 업데이트될 수 있다.
보다 바람직하게는, 상기 STA은, 상기 다수의 NAV들 간의 차이 값 및 상기 하나의 NAV 타이머에 맵핑된 제1 NAV의 현재 값을 이용하여 제2 NAV의 유효성을 판단할 수 있다.
본 발명의 일 실시예에 따르면 HE PPDU를 지원하는 무선랜 시스템에서 STA은 다수의 NAV를 관리하는데 있어서 프레임을 전송한 BSS를 고려하므로, NAV들이 정확하고 효율적으로 관리될 수 있다.
상술된 기술적 효과외에 다른 기술적 효과들이 본 발명의 실시예들로부터 유추될 수 있다.
도 1은 무선랜 시스템의 구성의 일례를 나타낸 도면이다.
도 2는 무선랜 시스템의 구성의 다른 예를 나타낸 도면이다.
도 3은 일반적인 링크 셋업(link setup) 과정을 설명하기 위한 도면이다.
도 4는 백오프 과정을 설명하기 위한 도면이다.
도 5는 숨겨진 노드 및 노출된 노드에 대한 설명을 위한 도면이다.
도 6은 RTS와 CTS를 설명하기 위한 도면이다.
도 7 내지 9는 TIM을 수신한 STA의 동작을 설명하기 위한 도면이다.
도 10은 IEEE 802.11 시스템에서 사용되는 프레임 구조의 일례를 설명하기 위한 도면이다.
도 11은 CF(contention free)-END 프레임을 예시한다.
도 12는 HE PPDU의 일 예를 도시한다.
도 13은 HE PPDU의 다른 일 예를 도시한다.
도 14는 HE PPDU의 또 다른 일 예를 도시한다.
도 15는 HE PPDU의 또 다른 일 예를 도시한다.
도 16은 HE PPDU의 또 다른 일 예를 도시한다.
도 17 및 도 18은 HE-SIG B에 대한 페딩 방안을 설명한다.
도 19는 본 발명의 일 실시예에 따른 상향링크 다중 사용자 전송 상황을 설명하기 위한 도면이다.
도 20은 본 발명의 일 실시예에 따른 트리거 프레임 포맷을 도시한다.
도 21은 NAV 설정(setting)의 일 예를 도시한다.
도 22는 TXOP truncation의 일 예를 도시한다.
도 23은 기존 NAV 관리 방법에 따른 문제점을 예시한다.
도 24는 UL MU 전송에 관련된 기존의 NAV 관리를 예시한다.
도 25는 본 발명의 일 실시예에 따른 NAV 관리를 예시한다.
도 26는 본 발명의 다른 일 실시예에 따른 NAV 관리를 예시한다.
도 27은 본 발명의 일 실시예에 따른 NAV 차이 값의 업데이트를 예시한다.
도 28은 본 발명의 다른 일 실시예에 따른 NAV 차이 값 업데이트를 예시한다.
도 29는 본 발명의 또 다른 일 실시예에 따른 NAV 관리를 예시한다.
도 30은 본 발명의 또 다른 일 실시예에 따른 NAV 관리를 예시한다.
도 31은 인트라 BSS 프레임에 의한 TXOP truncation을 예시한다.
도 32는 본 발명의 또 다른 일 실시예에 따른 NAV 관리를 예시한다.
도 33은 본 발명의 일 실시예에 따른 NAV 차이 값을 예시한다.
도 34는 본 발명의 또 다른 일 실시예에 따른 NAV 관리를 예시한다.
도 35는 본 발명의 일 실시예에 따른 2개의 NAV 타이머들을 예시한다.
도 36은 본 발명의 일 실시예에 따른 NAV 관리 방법의 흐름을 예시한다.
도 37은 본 발명의 일 실시예에 따른 장치를 설명하기 위한 도면이다.
이하, 본 발명에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시형태를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시형태를 나타내고자 하는 것이 아니다.
이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 당업자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다. 몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시된다.
상술한 바와 같이 이하의 설명은 무선랜 시스템에서 넓은 대역을 가지는 채널을 효율적으로 활용하기 위한 방법 및 이를 위한 장치에 대한 것이다. 이를 위해 먼저 본 발명이 적용되는 무선랜 시스템에 대해 구체적으로 설명한다.
도 1은 무선랜 시스템의 구성의 일례를 나타낸 도면이다.
도 1에 도시된 바와 같이, 무선랜 시스템은 하나 이상의 기본 서비스 세트(Basic Service Set, BSS)를 포함한다. BSS는 성공적으로 동기화를 이루어서 서로 통신할 수 있는 스테이션(Station, STA)의 집합이다.
STA는 매체 접속 제어(Medium Access Control, MAC)와 무선 매체에 대한 물리계층(Physical Layer) 인터페이스를 포함하는 논리 개체로서, 액세스 포인트(access point, AP)와 비AP STA(Non-AP Station)을 포함한다. STA 중에서 사용자가 조작하는 휴대용 단말은 Non-AP STA로써, 단순히 STA이라고 할 때는 Non-AP STA을 가리키기도 한다. Non-AP STA은 단말(terminal), 무선 송수신 유닛(Wireless Transmit/Receive Unit, WTRU), 사용자 장비(User Equipment, UE), 이동국(Mobile Station, MS), 휴대용 단말(Mobile Terminal), 또는 이동 가입자 유닛(Mobile Subscriber Unit) 등의 다른 명칭으로도 불릴 수 있다.
그리고, AP는 자신에게 결합된 STA(Associated Station)에게 무선 매체를 통해 분배 시스템(Distribution System, DS)으로의 접속을 제공하는 개체이다. AP는 집중 제어기, 기지국(Base Station, BS), Node-B, BTS(Base Transceiver System), 또는 사이트 제어기 등으로 불릴 수도 있다.
BSS는 인프라스트럭처(infrastructure) BSS와 독립적인(Independent) BSS(IBSS)로 구분할 수 있다.
도 1에 도시된 BBS는 IBSS이다. IBSS는 AP를 포함하지 않는 BSS를 의미하고, AP를 포함하지 않으므로, DS로의 접속이 허용되지 않아서 자기 완비적 네트워크(self-contained network)를 이룬다.
도 2는 무선랜 시스템의 구성의 다른 예를 나타낸 도면이다.
도 2에 도시된 BSS는 인프라스트럭처 BSS이다. 인프라스트럭처 BSS는 하나 이상의 STA 및 AP를 포함한다. 인프라스트럭처 BSS에서 비AP STA들 사이의 통신은 AP를 경유하여 이루어지는 것이 원칙이나, 비AP STA 간에 직접 링크(link)가 설정된 경우에는 비AP STA들 사이에서 직접 통신도 가능하다.
도 2에 도시된 바와 같이, 복수의 인프라스트럭처 BSS는 DS를 통해 상호 연결될 수 있다. DS를 통하여 연결된 복수의 BSS를 확장 서비스 세트(Extended Service Set, ESS)라 한다. ESS에 포함되는 STA들은 서로 통신할 수 있으며, 동일한 ESS 내에서 비AP STA은 끊김 없이 통신하면서 하나의 BSS에서 다른 BSS로 이동할 수 있다.
DS는 복수의 AP들을 연결하는 메커니즘(mechanism)으로서, 반드시 네트워크일 필요는 없으며, 소정의 분배 서비스를 제공할 수 있다면 그 형태에 대해서는 아무런 제한이 없다. 예컨대, DS는 메쉬(mesh) 네트워크와 같은 무선 네트워크일 수도 있고, AP들을 서로 연결시켜 주는 물리적인 구조물일 수도 있다.
계층 구조
무선랜 시스템에서 동작하는 STA의 동작은 계층(layer) 구조의 관점에서 설명할 수 있다. 장치 구성의 측면에서 계층 구조는 프로세서에 의해서 구현될 수 있다. STA는 복수개의 계층 구조를 가질 수 있다. 예를 들어, 802.11 표준문서에서 다루는 계층 구조는 주로 DLL(Data Link Layer) 상의 MAC 서브계층(sublayer) 및 물리(PHY) 계층이다. PHY은 PLCP(Physical Layer Convergence Procedure) 개체, PMD(Physical Medium Dependent) 개체 등을 포함할 수 있다. MAC 서브계층 및 PHY은 각각 MLME(MAC sublayer Management Entity) 및 PLME((Physical Layer Management Entity)라고 칭하여지는 관리 개체들을 개념적으로 포함한다. 이러한 개체들은 계층 관리 기능이 작동하는 계층 관리 서비스 인터페이스를 제공한다.
정확한 MAC 동작을 제공하기 위해서, SME(Station Management Entity) 가 각각의 STA 내에 존재한다. SME는, 별도의 관리 플레인 내에 존재하거나 또는 따로 떨어져(off to the side) 있는 것으로 보일 수 있는, 계층 독립적인 개체이다. SME의 정확한 기능들은 본 문서에서 구체적으로 설명하지 않지만, 일반적으로는 다양한 계층 관리 개체(LME)들로부터 계층-종속적인 상태를 수집하고, 계층-특정 파라미터들의 값을 유사하게 설정하는 등의 기능을 담당하는 것으로 보일 수 있다. SME는 일반적으로 일반 시스템 관리 개체를 대표하여(on behalf of) 이러한 기능들을 수행하고, 표준 관리 프로토콜을 구현할 수 있다.
전술한 개체들은 다양한 방식으로 상호작용한다. 예를 들어, 개체들 간에는 GET/SET 프리머티브(primitive)들을 교환(exchange)함으로써 상호작용할 수 있다. 프리머티브는 특정 목적에 관련된 요소(element)나 파라미터들의 세트를 의미한다. XX-GET.request 프리머티브는 주어진 MIB attribute(관리 정보 기반 속성 정보)의 값을 요청하기 위해 사용된다. XX-GET.confirm 프리머티브는, Status가 "성공"인 경우에는 적절한 MIB 속성 정보 값을 리턴하고, 그렇지 않으면 Status 필드에서 에러 지시를 리턴하기 위해 사용된다. XX-SET.request 프리머티브는 지시된 MIB 속성이 주어진 값으로 설정되도록 요청하기 위해 사용된다. 상기 MIB 속성이 특정 동작을 의미하는 경우, 이는 해당 동작이 수행되는 것을 요청하는 것이다. 그리고, XX-SET.confirm 프리머티브는 status가 "성공"인 경우에 지시된 MIB 속성이 요청된 값으로 설정되었음을 확인하여 주고, 그렇지 않으면 status 필드에 에러 조건을 리턴하기 위해 사용된다. MIB 속성이 특정 동작을 의미하는 경우, 이는 해당 동작이 수행되었음을 확인하여 준다.
또한, MLME 및 SME는 다양한 MLME_GET/SET 프리머티브들을 MLME_SAP(Service Access Point)을 통하여 교환할 수 있다. 또한, 다양한 PLME_GET/SET 프리머티브들이, PLME_SAP을 통해서 PLME와 SME 사이에서 교환될 수 있고, MLME-PLME_SAP을 통해서 MLME와 PLME 사이에서 교환될 수 있다.
링크 셋업 과정
도 3은 일반적인 링크 셋업(link setup) 과정을 설명하기 위한 도면이다.
STA이 네트워크에 대해서 링크를 셋업하고 데이터를 송수신하기 위해서는, 먼저 네트워크를 발견(discovery)하고, 인증(authentication)을 수행하고, 연관(association)을 맺고(establish), 보안(security)을 위한 인증 절차 등을 거쳐야 한다. 링크 셋업 과정을 세션 개시 과정, 세션 셋업 과정이라고도 칭할 수 있다. 또한, 링크 셋업 과정의 발견, 인증, 연관, 보안 설정의 과정을 통칭하여 연관 과정이라고 칭할 수도 있다.
도 3을 참조하여 예시적인 링크 셋업 과정에 대해서 설명한다.
단계 S510에서 STA은 네트워크 발견 동작을 수행할 수 있다. 네트워크 발견 동작은 STA의 스캐닝(scanning) 동작을 포함할 수 있다. 즉, STA이 네트워크에 액세스하기 위해서는 참여 가능한 네트워크를 찾아야 한다. STA은 무선 네트워크에 참여하기 전에 호환 가능한 네트워크를 식별하여야 하는데, 특정 영역에 존재하는 네트워크 식별과정을 스캐닝이라고 한다.
스캐닝 방식에는 능동적 스캐닝(active scanning)과 수동적 스캐닝(passive scanning)이 있다.
도 3에서는 예시적으로 능동적 스캐닝 과정을 포함하는 네트워크 발견 동작을 도시한다. 능동적 스캐닝에서 스캐닝을 수행하는 STA은 채널들을 옮기면서 주변에 어떤 AP가 존재하는지 탐색하기 위해 프로브 요청 프레임(probe request frame)을 전송하고 이에 대한 응답을 기다린다. 응답자(responder)는 프로브 요청 프레임을 전송한 STA에게 프로브 요청 프레임에 대한 응답으로 프로브 응답 프레임(probe response frame)을 전송한다. 여기에서, 응답자는 스캐닝되고 있는 채널의 BSS에서 마지막으로 비콘 프레임(beacon frame)을 전송한 STA일 수 있다. BSS에서는 AP가 비콘 프레임을 전송하므로 AP가 응답자가 되며, IBSS에서는 IBSS 내의 STA들이 돌아가면서 비콘 프레임을 전송하므로 응답자가 일정하지 않다. 예를 들어, 1번 채널에서 프로브 요청 프레임을 전송하고 1번 채널에서 프로브 응답 프레임을 수신한 STA은, 수신한 프로브 응답 프레임에 포함된 BSS 관련 정보를 저장하고 다음 채널(예를 들어, 2번 채널)로 이동하여 동일한 방법으로 스캐닝(즉, 2번 채널 상에서 프로브 요청/응답 송수신)을 수행할 수 있다.
도 3에서 도시하고 있지 않지만, 스캐닝 동작은 수동적 스캐닝 방식으로 수행될 수도 있다. 수동적 스캐닝에서 스캐닝을 수행하는 STA은 채널들을 옮기면서 비콘 프레임을 기다린다. 비콘 프레임은 IEEE 802.11에서 관리 프레임(management frame) 중 하나로서, 무선 네트워크의 존재를 알리고, 스캐닝을 수행하는 STA으로 하여금 무선 네트워크를 찾아서, 무선 네트워크에 참여할 수 있도록 주기적으로 전송된다. BSS에서 AP가 비콘 프레임을 주기적으로 전송하는 역할을 수행하고, IBSS에서는 IBSS 내의 STA들이 돌아가면서 비콘 프레임을 전송한다. 스캐닝을 수행하는 STA은 비콘 프레임을 수신하면 비콘 프레임에 포함된 BSS에 대한 정보를 저장하고 다른 채널로 이동하면서 각 채널에서 비콘 프레임 정보를 기록한다. 비콘 프레임을 수신한 STA은, 수신한 비콘 프레임에 포함된 BSS 관련 정보를 저장하고 다음 채널로 이동하여 동일한 방법으로 다음 채널에서 스캐닝을 수행할 수 있다.
능동적 스캐닝과 수동적 스캐닝을 비교하면, 능동적 스캐닝이 수동적 스캐닝보다 딜레이(delay) 및 전력 소모가 작은 장점이 있다.
STA이 네트워크를 발견한 후에, 단계 S520에서 인증 과정이 수행될 수 있다. 이러한 인증 과정은 후술하는 단계 S540의 보안 셋업 동작과 명확하게 구분하기 위해서 첫 번째 인증(first authentication) 과정이라고 칭할 수 있다.
인증 과정은 STA이 인증 요청 프레임(authentication request frame)을 AP에게 전송하고, 이에 응답하여 AP가 인증 응답 프레임(authentication response frame)을 STA에게 전송하는 과정을 포함한다. 인증 요청/응답에 사용되는 인증 프레임(authentication frame)은 관리 프레임에 해당한다.
인증 프레임은 인증 알고리즘 번호(authentication algorithm number), 인증 트랜잭션 시퀀스 번호(authentication transaction sequence number), 상태 코드(status code), 검문 텍스트(challenge text), RSN(Robust Security Network), 유한 순환 그룹(Finite Cyclic Group) 등에 대한 정보를 포함할 수 있다. 이는 인증 요청/응답 프레임에 포함될 수 있는 정보들의 일부 예시에 해당하며, 다른 정보로 대체되거나, 추가적인 정보가 더 포함될 수 있다.
STA은 인증 요청 프레임을 AP에게 전송할 수 있다. AP는 수신된 인증 요청 프레임에 포함된 정보에 기초하여, 해당 STA에 대한 인증을 허용할지 여부를 결정할 수 있다. AP는 인증 처리의 결과를 인증 응답 프레임을 통하여 STA에게 제공할 수 있다.
STA이 성공적으로 인증된 후에, 단계 S530에서 연관 과정이 수행될 수 있다. 연관 과정은 STA이 연관 요청 프레임(association request frame)을 AP에게 전송하고, 이에 응답하여 AP가 연관 응답 프레임(association response frame)을 STA에게 전송하는 과정을 포함한다.
예를 들어, 연관 요청 프레임은 다양한 능력(capability)에 관련된 정보, 비콘 청취 간격(listen interval), SSID(service set identifier), 지원 레이트(supported rates), 지원 채널(supported channels), RSN, 이동성 도메인, 지원 오퍼레이팅 클래스(supported operating classes), TIM 방송 요청(Traffic Indication Map Broadcast request), 상호동작(interworking) 서비스 능력 등에 대한 정보를 포함할 수 있다.
예를 들어, 연관 응답 프레임은 다양한 능력에 관련된 정보, 상태 코드, AID(Association ID), 지원 레이트, EDCA(Enhanced Distributed Channel Access) 파라미터 세트, RCPI(Received Channel Power Indicator), RSNI(Received Signal to Noise Indicator), 이동성 도메인, 타임아웃 간격(연관 컴백 시간(association comeback time)), 중첩(overlapping) BSS 스캔 파라미터, TIM 방송 응답, QoS 맵 등의 정보를 포함할 수 있다.
이는 연관 요청/응답 프레임에 포함될 수 있는 정보들의 일부 예시에 해당하며, 다른 정보로 대체되거나, 추가적인 정보가 더 포함될 수 있다.
STA이 네트워크에 성공적으로 연관된 후에, 단계 S540에서 보안 셋업 과정이 수행될 수 있다. 단계 S540의 보안 셋업 과정은 RSNA(Robust Security Network Association) 요청/응답을 통한 인증 과정이라고 할 수도 있고, 상기 단계 S520의 인증 과정을 첫 번째 인증(first authentication) 과정이라고 하고, 단계 S540의 보안 셋업 과정을 단순히 인증 과정이라고도 칭할 수도 있다.
단계 S540의 보안 셋업 과정은, 예를 들어, EAPOL(Extensible Authentication Protocol over LAN) 프레임을 통한 4-웨이(way) 핸드쉐이킹을 통해서, 프라이빗 키 셋업(private key setup)을 하는 과정을 포함할 수 있다. 또한, 보안 셋업 과정은 IEEE 802.11 표준에서 정의하지 않는 보안 방식에 따라 수행될 수도 있다.
매체 액세스 메커니즘
IEEE 802.11에 따른 무선랜 시스템에서, MAC(Medium Access Control)의 기본 액세스 메커니즘은 CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance) 메커니즘이다. CSMA/CA 메커니즘은 IEEE 802.11 MAC의 분배 조정 기능(Distributed Coordination Function, DCF)이라고도 불리는데, 기본적으로 "listen before talk" 액세스 메커니즘을 채용하고 있다. 이러한 유형의 액세스 메커니즘 따르면, AP 및/또는 STA은 전송을 시작하기에 앞서, 소정의 시간구간(예를 들어, DIFS(DCF Inter-Frame Space) 동안 무선 채널 또는 매체(medium)를 센싱(sensing)하는 CCA(Clear Channel Assessment)를 수행할 수 있다. 센싱 결과, 만일 매체가 유휴 상태(idle status)인 것으로 판단 되면, 해당 매체를 통하여 프레임 전송을 시작한다. 반면, 매체가 점유 상태(occupied status)인 것으로 감지되면, 해당 AP 및/또는 STA은 자기 자신의 전송을 시작하지 않고 매체 액세스를 위한 지연 기간(예를 들어, 임의 백오프 주기(random backoff period))을 설정하여 기다린 후에 프레임 전송을 시도할 수 있다. 임의 백오프 주기의 적용으로, 여러 STA들은 서로 다른 시간 동안 대기한 후에 프레임 전송을 시도할 것이 기대되므로, 충돌(collision)을 최소화시킬 수 있다.
또한, IEEE 802.11 MAC 프로토콜은 HCF(Hybrid Coordination Function)를 제공한다. HCF는 상기 DCF와 PCF(Point Coordination Function)를 기반으로 한다. PCF는 폴링(polling) 기반의 동기식 액세스 방식으로 모든 수신 AP 및/또는 STA이 데이터 프레임을 수신할 수 있도록 주기적으로 폴링하는 방식을 일컫는다. 또한, HCF는 EDCA(Enhanced Distributed Channel Access)와 HCCA(HCF Controlled Channel Access)를 가진다. EDCA는 제공자가 다수의 사용자에게 데이터 프레임을 제공하기 위한 액세스 방식을 경쟁 기반으로 하는 것이고, HCCA는 폴링(polling) 메커니즘을 이용한 비경쟁 기반의 채널 액세스 방식을 사용하는 것이다. 또한, HCF는 WLAN의 QoS(Quality of Service)를 향상시키기 위한 매체 액세스 메커니즘을 포함하며, 경쟁 주기(Contention Period; CP)와 비경쟁 주기(Contention Free Period; CFP) 모두에서 QoS 데이터를 전송할 수 있다.
도 4는 백오프 과정을 설명하기 위한 도면이다.
도 4를 참조하여 임의 백오프 주기에 기반한 동작에 대해서 설명한다. 점유(occupy 또는 busy) 상태이던 매체가 유휴(idle) 상태로 변경되면, 여러 STA들은 데이터(또는 프레임) 전송을 시도할 수 있다. 이 때, 충돌을 최소화하기 위한 방안으로서, STA들은 각각 임의 백오프 카운트를 선택하고 그에 해당하는 슬롯 시간만큼 대기한 후에, 전송을 시도할 수 있다. 임의 백오프 카운트는 패킷 번호(Packet Number) 값을 가지며, 0 내지 CW 범위의 값 중에서 하나로 결정될 수 있다. 여기서, CW는 경쟁 윈도우(Contention Window) 파라미터 값이다. CW 파라미터는 초기값으로 CWmin이 주어지지만, 전송 실패의 경우(예를 들어, 전송된 프레임에 대한 ACK을 수신하지 못한 경우)에 2 배의 값을 취할 수 있다. CW 파라미터 값이 CWmax가 되면 데이터 전송이 성공할 때까지 CWmax 값을 유지하면서 데이터 전송을 시도할 수 있고, 데이터 전송이 성공하는 경우에는 CWmin 값으로 리셋된다. CW, CWmin 및 CWmax 값은 2n-1 (n=0, 1, 2, ...)로 설정되는 것이 바람직하다.
임의 백오프 과정이 시작되면 STA은 결정된 백오프 카운트 값에 따라서 백오프 슬롯을 카운트 다운하는 동안에 계속하여 매체를 모니터링한다. 매체가 점유상태로 모니터링되면 카운트 다운을 멈추고 대기하고, 매체가 유휴 상태가 되면 나머지 카운트 다운을 재개한다.
도 4의 예시에서 STA3의 MAC에 전송할 패킷이 도달한 경우에, STA3는 DIFS 만큼 매체가 유휴 상태인 것을 확인하고 바로 프레임을 전송할 수 있다. 한편, 나머지 STA들은 매체가 점유(busy) 상태인 것을 모니터링하고 대기한다. 그 동안 STA1, STA2 및 STA5의 각각에서도 전송할 데이터가 발생할 수 있고, 각각의 STA은 매체가 유휴상태로 모니터링되면 DIFS만큼 대기한 후에, 각자가 선택한 임의 백오프 카운트 값에 따라 백오프 슬롯의 카운트 다운을 수행할 수 있다. 도 4의 예시에서는 STA2가 가장 작은 백오프 카운트 값을 선택하고, STA1이 가장 큰 백오프 카운트 값을 선택한 경우를 나타낸다. 즉, STA2가 백오프 카운트를 마치고 프레임 전송을 시작하는 시점에서 STA5의 잔여 백오프 시간은 STA1의 잔여 백오프 시간보다 짧은 경우를 예시한다. STA1 및 STA5는 STA2가 매체를 점유하는 동안에 잠시 카운트 다운을 멈추고 대기한다. STA2의 점유가 종료되어 매체가 다시 유휴 상태가 되면, STA1 및 STA5는 DIFS만큼 대기한 후에, 멈추었던 백오프 카운트를 재개한다. 즉, 잔여 백오프 시간만큼의 나머지 백오프 슬롯을 카운트 다운한 후에 프레임 전송을 시작할 수 있다. STA5의 잔여 백오프 시간이 STA1보다 짧았으므로 STA5이 프레임 전송을 시작하게 된다. 한편, STA2가 매체를 점유하는 동안에 STA4에서도 전송할 데이터가 발생할 수 있다. 이 때, STA4의 입장에서는 매체가 유휴 상태가 되면 DIFS만큼 대기한 후, 자신이 선택한 임의 백오프 카운트 값에 따른 카운트 다운을 수행하고 프레임 전송을 시작할 수 있다. 도 6의 예시에서는 STA5의 잔여 백오프 시간이 STA4의 임의 백오프 카운트 값과 우연히 일치하는 경우를 나타내며, 이 경우, STA4와 STA5 간에 충돌이 발생할 수 있다. 충돌이 발생하는 경우에는 STA4와 STA5 모두 ACK을 받지 못하여, 데이터 전송을 실패하게 된다. 이 경우, STA4와 STA5는 CW 값을 2배로 늘린 후에 임의 백오프 카운트 값을 선택하고 카운트 다운을 수행할 수 있다. 한편, STA1은 STA4와 STA5의 전송으로 인해 매체가 점유 상태인 동안에 대기하고 있다가, 매체가 유휴 상태가 되면 DIFS만큼 대기한 후, 잔여 백오프 시간이 지나면 프레임 전송을 시작할 수 있다.
STA의 센싱 동작
전술한 바와 같이 CSMA/CA 메커니즘은 AP 및/또는 STA이 매체를 직접 센싱하는 물리적 캐리어 센싱(physical carrier sensing) 외에 가상 캐리어 센싱(virtual carrier sensing)도 포함한다. 가상 캐리어 센싱은 숨겨진 노드 문제(hidden node problem) 등과 같이 매체 액세스에서 발생할 수 있는 문제를 보완하기 위한 것이다. 가상 캐리어 센싱을 위하여, 무선랜 시스템의 MAC은 네트워크 할당 벡터(Network Allocation Vector; NAV)를 이용할 수 있다. NAV는 현재 매체를 사용하고 있거나 또는 사용할 권한이 있는 AP 및/또는 STA이, 매체가 이용 가능한 상태로 되기까지 남아 있는 시간을 다른 AP 및/또는 STA에게 지시(indicate)하는 값이다. 따라서 NAV로 설정된 값은 해당 프레임을 전송하는 AP및/또는 STA에 의하여 매체의 사용이 예정되어 있는 기간에 해당하고, NAV 값을 수신하는 STA은 해당 기간동안 매체 액세스가 금지된다. NAV는, 예를 들어, 프레임의 MAC 헤더(header)의 "duration" 필드의 값에 따라 설정될 수 있다.
또한, 충돌 가능성을 감소시키기 위해서 강인한 충돌 검출(robust collision detect) 메커니즘이 도입되었다. 이에 대해서 도 5 및 도 7을 참조하여 설명한다. 실제 캐리어 센싱 범위와 전송 범위는 동일하지 않을 수도 있지만, 설명의 편의를 위해서 동일한 것으로 가정한다.
도 5는 숨겨진 노드 및 노출된 노드에 대한 설명을 위한 도면이다.
도 5(a)는 숨겨진 노드에 대한 예시이며, STA A와 STA B는 통신 중에 있고 STA C가 전송할 정보를 가지고 있는 경우이다. 구체적으로 STA A가 STA B에 정보를 전송하고 있는 상황이지만, STA C가 STA B로 데이터를 보내기 전에 캐리어 센싱을 수행할 때에 매체가 유휴 상태인 것으로 판단할 수 있다. 이는 STA A의 전송(즉, 매체 점유)을 STA C의 위치에서는 센싱하지 못할 수도 있기 때문이다. 이러한 경우에, STA B는 STA A와 STA C의 정보를 동시에 받기 때문에 충돌이 발생하게 된다. 이 때 STA A는 STA C의 숨겨진 노드라고 할 수 있다.
도 5(b)는 노출된 노드(exposed node)에 대한 예시이며, STA B는 STA A에 데이터를 전송하고 있는 상황에서, STA C가 STA D에서 전송할 정보를 가지고 있는 경우이다. 이 경우에 STA C가 캐리어 센싱을 수행하면, STA B의 전송으로 인하여 매체가 점유된 상태라고 판단할 수 있다. 이에 따라, STA C가 STA D에 전송할 정보가 있더라도 매체 점유 상태라고 센싱되기 때문에 매체가 유휴 상태가 될 때까지 기다려야 한다. 그러나, 실제로는 STA A는 STA C의 전송 범위 밖에 있으므로, STA C로부터의 전송과 STA B로부터의 전송은 STA A의 입장에서는 충돌하지 않을 수도 있으므로, STA C는 STA B가 전송을 멈출 때까지 불필요하게 대기하는 것이 된다. 이 때 STA C를 STA B의 노출된 노드라고 할 수 있다.
도 6은 RTS와 CTS를 설명하기 위한 도면이다.
도 5와 같은 예시적인 상황에서 충돌 회피(collision avoidance) 메커니즘을 효율적으로 이용하기 위해서, RTS(request to send)와 CTS(clear to send)등의 짧은 시그널링 패킷(short signaling packet)을 이용할 수 있다. 두 STA 간의 RTS/CTS는 주위의 STA(들)이 오버히어링(overhearing)할 수 있도록 하여, 상기 주위의 STA(들)이 상기 두 STA 간의 정보 전송 여부를 고려하도록 할 수 있다. 예를 들어, 데이터를 전송하려는 STA이 데이터를 받는 STA에 RTS 프레임을 전송하면, 데이터를 받는 STA은 CTS 프레임을 주위의 STA들에게 전송함으로써 자신이 데이터를 받을 것임을 알릴 수 있다.
도 6(a)는 숨겨진 노드 문제를 해결하는 방법에 대한 예시이며, STA A와 STA C가 모두 STA B에 데이터를 전송하려고 하는 경우를 가정한다. STA A가 RTS를 STA B에 보내면 STA B는 CTS를 자신의 주위에 있는 STA A와 STA C에 모두 전송을 한다. 그 결과 STA C는 STA A와 STA B의 데이터 전송이 끝날 때까지 기다리게 되어 충돌을 피할 수 있게 된다.
도 6(b)는 노출된 노드 문제를 해결하는 방법에 대한 예시이며, STA A와 STA B 간의 RTS/CTS 전송을 STA C가 오버히어링함으로써, STA C는 자신이 다른 STA(예를 들어, STA D)에게 데이터를 전송하더라도 충돌이 발생하지 않을 것으로 판단할 수 있다. 즉, STA B는 주위의 모든 STA들에게 RTS를 전송하고, 실제로 보낼 데이터가 있는 STA A만 CTS를 전송하게 된다. STA C는 RTS만을 받고 STA A의 CTS를 받지 못했기 때문에 STA A는 STC C의 캐리어 센싱 밖에 있다는 것을 알 수 있다.
전력 관리
전술한 바와 같이 무선랜 시스템에서는 STA이 송수신을 수행하기 전에 채널 센싱을 수행해야 하는데, 채널을 항상 센싱하는 것은 STA의 지속적인 전력 소모를 야기한다. 수신 상태에서의 전력 소모는 송신 상태에서의 전력 소모에 비하여 크게 차이가 나지 않으며, 수신 상태를 계속 유지하는 것도 전력이 제한된(즉, 배터리에 의해 동작하는) STA에게 큰 부담이 된다. 따라서, STA이 지속적으로 채널을 센싱하기 위해서 수신 대기 상태를 유지하면, 무선랜 처리율 측면에서 특별한 이점 없이 전력을 비효율적으로 소모하게 된다. 이러한 문제점을 해결하기 위해서, 무선랜 시스템에서는 STA의 전력 관리(power management; PM) 모드를 지원한다.
STA의 전력 관리 모드는 액티브(active) 모드 및 전력 절약(power save; PS) 모드로 나뉘어 진다. STA은 기본적으로 액티브 모드로 동작한다. 액티브 모드로 동작하는 STA은 어웨이크 상태(awake state)를 유지한다. 어웨이크 상태는, 프레임 송수신이나 채널 스캐닝 등 정상적인 동작이 가능한 상태이다. 한편, PS 모드로 동작하는 STA은 슬립 상태(sleep state) (또는 도즈(doze) 상태)와 어웨이크 상태(awake state)를 전환(switch)해가며 동작한다. 슬립 상태로 동작하는 STA은 최소한의 전력으로 동작하며, 프레임 송수신은 물론 채널 스캐닝도 수행하지 않는다.
STA이 슬립 상태로 가능한 오래 동작할수록 전력 소모가 줄어들기 때문에, STA은 동작 기간이 증가한다. 하지만 슬립 상태에서는 프레임 송수신이 불가능하기 때문에 무조건적으로 오래 동작할 수는 없다. 슬립 상태로 동작하는 STA이 AP에게 전송할 프레임이 존재하는 경우 어웨이크 상태로 전환하여 프레임을 송신할 수 있다. 한편, AP가 STA에게 전송할 프레임이 있는 경우, 슬립 상태의 STA은 이를 수신할 수 없으며 수신할 프레임이 존재하는 것도 알 수 없다. 따라서, STA은 자신에게 전송될 프레임의 존재 여부를 알기 위해(또한 존재한다면 이를 수신하기 위해) 특정 주기에 따라 어웨이크 상태로 전환하는 동작이 필요할 수 있다.
AP는 일정한 주기로 비콘 프레임(beacon frame)을 BSS 내의 STA들에게 전송할 수 있다. 비콘 프레임에는 TIM(Traffic Indication Map) 정보 요소(Information Element)가 포함될 수 있다. TIM 정보 요소는 AP가 자신과 연관된 STA들에 대한 버퍼된 트래픽이 존재하며, 프레임을 전송할 것임을 알려주는 정보를 포함할 수 있다. TIM 요소에는 유니캐스트(unicast) 프레임을 알려주는데 사용되는 TIM과 멀티캐스트(multicast) 또는 브로드캐스트(broadcast) 프레임을 알려주는데 사용되는 DTIM(delivery traffic indication map)이 있다.
도 7 내지 9는 TIM을 수신한 STA의 동작을 상세하게 설명하기 위한 도면이다.
도 7을 참조하면, STA은 AP로부터 TIM을 포함하는 비콘 프레임을 수신하기 위해 슬립 상태에서 어웨이크 상태로 전환하고, 수신한 TIM 요소를 해석하여 자신에게 전송될 버퍼된 트래픽이 있음을 알 수 있다. STA은 PS-Poll 프레임 전송을 위한 매체 액세스를 위해 다른 STA들과 경쟁(contending)을 수행한 후에, AP에게 데이터 프레임 전송을 요청하기 위하여 PS-Poll 프레임을 전송할 수 있다. STA에 의해 전송된 PS-Poll 프레임을 수신한 AP는 STA에게 프레임을 전송할 수 있다. STA은 데이터 프레임을 수신하고 이에 대한 확인응답(ACK) 프레임을 AP에게 전송할 수 있다. 이후 STA은 다시 슬립 상태로 전환될 수 있다.
도 7과 같이 AP는 STA으로부터 PS-Poll 프레임을 수신한 다음 소정의 시간(예를 들어, SIFS(Short Inter-Frame Space)) 후에 데이터 프레임을 전송하는 즉시 응답(immediate response) 방식에 따라 동작할 수 있다. 한편, AP가 PS-Poll 프레임을 수신한 후에 STA에게 전송할 데이터 프레임을 SIFS 시간 동안에 준비하지 못한 경우에는 지연된 응답(deferred response) 방식에 따라 동작할 수 있으며, 이에 대해서 도 8를 참조하여 설명한다.
도 8의 예시에서 STA이 슬립 상태에서 어웨이크 상태로 전환하여 AP로부터 TIM을 수신하고 경쟁을 거쳐 PS-Poll 프레임을 AP로 전송하는 동작은 도 7의 예시와 동일하다. AP가 PS-Poll 프레임을 수신하고도 SIFS 동안 데이터 프레임을 준비하지 못한 경우, 데이터 프레임을 전송하는 대신 ACK 프레임을 STA에게 전송할 수 있다. AP는 ACK 프레임 전송 후 데이터 프레임이 준비되면, 컨텐딩을 수행한 후 데이터 프레임을 STA에게 전송할 수 있다. STA은 데이터 프레임을 성공적으로 수신하였음을 나타내는 ACK 프레임을 AP에게 전송하고, 슬립 상태로 전환될 수 있다.
도 9는 AP가 DTIM을 전송하는 예시에 대한 것이다. STA들은 AP로부터 DTIM 요소를 포함하는 비콘 프레임을 수신하기 위해 슬립 상태에서 어웨이크 상태로 전환할 수 있다. STA들은 수신한 DTIM을 통해 멀티캐스트/브로드캐스트 프레임이 전송될 것임을 알 수 있다. AP는 DTIM을 포함하는 비콘 프레임 전송 후 PS-Poll 프레임의 송수신 동작 없이 바로 데이터(즉, 멀티캐스트/브로드캐스트 프레임)를 전송할 수 있다. STA들은 DTIM을 포함하는 비콘 프레임을 받은 후에 계속하여 어웨이크 상태를 유지하는 중에 데이터를 수신하고, 데이터 수신이 완료된 후에 다시 슬립 상태로 전환할 수 있다.
프레임 구조
도 10은 IEEE 802.11 시스템에서 사용되는 프레임 구조의 일례를 설명하기 위한 도면이다.
PPDU(Physical Layer Protocol Data Unit) 프레임 포맷은, STF(Short Training Field), LTF(Long Training Field), SIG(SIGNAL) 필드, 및 데이터(Data) 필드를 포함하여 구성될 수 있다. 가장 기본적인(예를 들어, non-HT(High Throughput)) PPDU 프레임 포맷은 L-STF(Legacy-STF), L-LTF(Legacy-LTF), SIG 필드 및 데이터 필드만으로 구성될 수 있다.
STF는 신호 검출, AGC(Automatic Gain Control), 다이버시티 선택, 정밀한 시간 동기 등을 위한 신호이고, LTF는 채널 추정, 주파수 오차 추정 등을 위한 신호이다. STF와 LTF를 합쳐서 PLCP 프리앰블(preamble)이라고 칭할 수 있고, PLCP 프리앰블은 OFDM 물리계층의 동기화 및 채널 추정을 위한 신호라고 할 수 있다.
SIG 필드는 RATE 필드 및 LENGTH 필드 등을 포함할 수 있다. RATE 필드는 데이터의 변조 및 코딩 레이트에 대한 정보를 포함할 수 있다. LENGTH 필드는 데이터의 길이에 대한 정보를 포함할 수 있다. 추가적으로, SIG 필드는 패리티(parity) 비트, SIG TAIL 비트 등을 포함할 수 있다.
데이터 필드는 SERVICE 필드, PSDU(Physical layer Service Data Unit), PPDU TAIL 비트를 포함할 수 있고, 필요한 경우에는 패딩 비트도 포함할 수 있다. SERVICE 필드의 일부 비트는 수신단에서의 디스크램블러의 동기화를 위해 사용될 수 있다. PSDU는 MAC 계층에서 정의되는 MPDU(MAC Protocol Data Unit)에 대응하며, 상위 계층에서 생성/이용되는 데이터를 포함할 수 있다. PPDU TAIL 비트는 인코더를 0 상태로 리턴하기 위해서 이용될 수 있다. 패딩 비트는 데이터 필드의 길이를 소정의 단위로 맞추기 위해서 이용될 수 있다.
MPDU는 다양한 MAC 프레임 포맷에 따라서 정의되며, 기본적인 MAC 프레임은 MAC 헤더, 프레임 바디, 및 FCS(Frame Check Sequence)로 구성된다. MAC 프레임은 MPDU로 구성되어 PPDU 프레임 포맷의 데이터 부분의 PSDU를 통하여 송신/수신될 수 있다.
MAC 헤더는 프레임 제어(Frame Control) 필드, 기간(Duration)/ID 필드, 주소(Address) 필드 등을 포함한다. 프레임 제어 필드는 프레임 송신/수신에 필요한 제어 정보들을 포함할 수 있다. 기간/ID 필드는 해당 프레임 등을 전송하기 위한 시간으로 설정될 수 있다.
MAC 헤더에 포함된 기간/ID 필드는 16 비트 길이(e.b., B0~B15)로 설정될 수 있다. 기간/ID 필드에 포함되는 콘텐츠는 프레임 타입 및 서브타입, CFP(contention free period) 동안 전송되는지, 송신 STA의 QoS 캐퍼빌리티 등에 따라서 달라질 수 있다. (i) 서브타입이 PS-Poll인 제어 프레임에서, 기간/ID 필드는 송신 STA의 AID를 포함할 수 있으며(e.g., 14 LSB 비트들을 통해), 2 MSB 비트들은 1로 설정될 수 있다. (ii) PC(point coordinator) 또는 non-QoS STA에 의해 CFP 동안 전송되는 프레임들에서, 기간/ID 필드는 고정된 값(e.g., 32768)로 설정될 수 있다. (iii) 그 밖에 non-QoS STA에 의해 전송되는 다른 프레임들 또는 QoS STA에 의해 전송되는 제어 프레임들에서, 기간/ID 필드는 각 프레임 타입별로 정의된 duration 값을 포함할 수 있다. QoS STA에 의해 전송되는 데이터 프레임 또는 매니지먼트 프레임에서, 기간/ID 필드는 각 프레임 타입에 대하서 정의된 duration 값을 포함할 수 있다. 예컨대, 기간/ID 필드의 B15=0으로 설정되면 기간/ID 필드가 TXOP Duration 을 지시하는데 사용된다는 것을 나타내며, B0~B14는 실제 TXOP Duration을 지시하는데 사용될 수 있다. B0~B14에 의해 지시되는 실제 TXOP Duration은 0~32767 중 어느 하나일 수 있으며, 그 단위는 마이크로 세컨드(us)일 수 있다. 다만, 기간/ID 필드가 고정된 TXOP Duration 값(e.g., 32768)을 지시하는 경우에는 B15=1이고, B0~B14=0으로 설정될 수 있다. 그 밖에 B14=1, B15=1로 설정되면 기간/ID 필드가 AID를 지시하기 위하여 사용되고, B0~B13은 1~2007 중 하나의 AID를 지시한다. MAC 헤더의 Sequence Control, QoS Control, HT Control 서브필드들의 구체적인 내용은 IEEE 802.11 표준 문서를 참조할 수 있다.
MAC 헤더의 프레임 제어 필드는, Protocol Version, Type, Subtype, To DS, From DS, More Fragment, Retry, Power Management, More Data, Protected Frame, Order 서브필드들을 포함할 수 있다. 프레임 제어 필드의 각각의 서브필드의 내용은 IEEE 802.11 표준 문서를 참조할 수 있다.
도 11은 CF(contention free)-END 프레임을 예시한다.
설명의 편의상 CF-END 프레임이 non-DMG(directional multi-gigabit, 11ad) STA에 의해 전송된다고 가정한다. CF-END 프레임은 TXOP duration을 절단(truncation)하기 위하여 전송될 수 있다. 따라서 CF-END 프레임에서 기간(duration) 필드는 0으로 설정된다. RA (Receiver Address) 필드는 브로드캐스트 그룹 주소로 설정될 수 있다. BSSID 필드는 AP에 포함된 STA의 주소로 설정될 수 있다. 다만, VHT STA이 VHT AP로 전송하는 non-HT 또는 non-HT duplicate 포맷의 CF-END 프레임의 경우, BSSID 필드의 Individual/Group 비트는 1로 설정될 수 있다.
HE PPDU 구조의 예시
이하에서는 11ax를 지원하는 무선랜 시스템에서의 HE PPDU (High Efficiency Physical layer Protocol Data Unit) 포맷의 일례들을 살펴본다.
도 12는 HE PPDU의 일 예를 도시한다. 도 12를 참조하면, HE-SIG A(또는 HE-SIG1) 필드는 L-Part (e.g., L-STF, L-LTF, L-SIG) 다음에 위치하며, L-Part와 마찬가지로 20MHz단위로 반복(duplication) 된다. HE-SIG A는 STA들에 대한 공통 제어 정보 (common control information) (e.g., BW, GI 길이, BSS 인덱스, CRC, Tail 등)를 포함한다. HE-SIG A 필드는 HE PPDU를 해석하기 위한 정보를 포함하며, 따라서 HE-SIG A 필드에 포함되는 정보는 HE PPDU의 포맷(e.g., SU PPDU, MU PPDU 또는 트리거 기반의 PPDU 등)에 따라서 달라질 수 있다. 예컨대, HE SU PPDU 포맷에서, HE-SIG A 필드는, DL/UL 지시자, HE PPDU 포맷 지시자, BSS Color, TXOP Duration, BW(bandwidth), MCS, CP + LTF 길이, 코딩 정보, 스트림 수, STBC (e.g., STBC 사용 여부), 송신빔포밍(TxBF) 정보, CRC 및 Tail 중 적어도 하나를 포함할 수 있다. HE SU PPDU 포맷의 경우, HE-SIG B 필드가 생략될 수 있다. HE MU PPDU 포맷에서, HE-SIG A 필드는, DL/UL 지시자, BSS Color, TXOP Duration, BW(bandwidth), SIG B 필드의 MCS 정보, SIG B 필드의 심볼 수, HE LTF 심볼 수, 전 대역 MU-MIMO 사용 여부 지시자, CP + LTF 길이, 송신빔포밍(TxBF) 정보, CRC 및 Tail 중 적어도 하나를 포함할 수 있다. HE 트리거 기반의 PPDU 포맷에서, HE-SIG A 필드는, 포맷 지시자(e.g., SU PPDU인지 트리거 기반 PPDU인지), BSS Color, TXOP Duration, BW, CRC 및 Tail 중 적어도 하나를 포함할 수 있다.
도 13은 HE PPDU의 다른 일 예를 도시한다. 도 13을 참조하면 HE-SIG A는 상술한 공통 제어 정보(common information) 이외에, 사용자 할당 정보(user allocation information) 예컨대, PAID 또는 GID 등의 STA 식별자, 할당된 자원 정보 및 스트림 수(Nsts) 중 적어도 하나가 포함될 수도 있다. 도 13에 따르면 HE-SIG B(또는 HE-SIG2)는 OFDMA 할당 마다 전송될 수 있다. MU-MIMO인 경우, HE-SIG B는 SDM을 통해서 STA에 의해서 구별된다. HE-SIG B는 추가적인 사용자 할당 정보(user allocation information), 예컨대, MCS, Coding 정보, STBC(Space Time Block code) 정보, 송신빔포밍(TXBF) 정보 등을 포함할 수 있다.
도 14는 HE PPDU의 또 다른 일 예를 도시한다. HE-SIG B는 HE-SIG A 다음에 전송된다. HE-SIG B는 HE-SIG A의 정보 (numerology)를 기반으로, 전 대역(full band)을 통해 전송될 수 있다. HE-SIG B는 사용자 할당 정보, 예컨대, STA AID, 자원 할당 정보(e.g., 할당 크기), MCS, 스트림 수(Nsts), Coding, STBC, 송신빔포밍(TXBF) 등을 포함할 수 있다.
도 15는 HE PPDU의 또 다른 일 예를 도시한다. HE-SIG B는 일정한 단위 채널 마다 반복 전송될 수 있다. 도 15를 참조하면 HE-SIG B는 20MHz 단위로 반복 전송될 수 있다. 예컨대, 80MHz 대역폭 상에서 20MHz 당 동일한 정보가 복사됨으로써 HE-SIG B가 전송될 수 있다.
20MHz 채널 당 반복 전송되는 HE-SIGB 를 수신한 STA/AP는 20MHz 채널 당 수신한 HE-SIG B를 누적(accumulation)하여 HE-SIG B 수신에 대한 신뢰성(reliability)을 향상 시킬 수 있다.
채널당 동일한 신호(e.g., HE-SIG B)가 반복 전송되므로 누적된 신호의 이득은 신호가 반복 전송되는 채널들의 개수에 비례하여 수신 성능이 향상될 수 있다. 이상적으로는 반복 전송되기 전 신호에 비하여, 반복 전송되는 신호는 3dB X 채널 수 (number of channel)의 이득을 가질 수 있다. 따라서, 반복 전송되는 HE-SIG B는 반복 전송되는 채널의 수에 따라서 MCS 레벨을 높여 전송될 수 있다. 예를 들어, 반복 전송이 없을 때 HE-SIG B에 MCS0가 사용된다고 가정할 때, 40MHz를 이용하여 반복 전송되는 HE-SIG B에는 MCS1가 사용될 수 있다. 반복 전송을 위한 채널의 개수가 증가할 수록 보다 높은 MCS 레벨을 통해서 HE-SIG B가 전송될 수 있으므로, 단위 채널 당의 HE-SIG B의 오버헤드가 줄어들 수 있다.
도 16은 HE PPDU의 또 다른 일 예를 도시한다. 도 16을 참조하면, HE-SIG B는 20MHz 채널 단위마다 독립적인 정보를 포함할 수 있다. HE-SIG B는 레거시 파트(e.g., L-STF, L-LTF, L-SIG) 및 HE-SIG A와 동일하게 1x 심볼 구조로 전송될 수 있다. 한편, 광 대역폭(wide bandwidth)에서, “L-STF+L-LTF+L-SIG+HE-SIGA+HE-SIGB”의 길이는 모든 채널에서 동일해야 한다. 20MHz 당 전송되는 HE-SIG B는 해당 대역에 대한 할당 정보, 예컨대, 해당 대역을 이용하는 사용자 별 할당 정보, 사용자 식별자 등을 포함할 수 있다. 하지만, 각 대역 별로 지원되는 사용자 수와 각 대역에서 이용되는 자원 블록의 구성이 다르기 때문에 HE-SIG B의 정보가 대역 별로 상이할 수 있다. 따라서, HE-SIG B의 길이는 채널 별로 서로 상이할 수 있다.
도 17은 HE-STF 이전의 길이(e.g., HE-SIG B까지의 길이)를 채널 별 동일하게 구성하기 위하여 HE-SIG B에 대한 페딩 방안을 설명한다. 예컨대, 페딩 길이(padding length)만큼 HE-SIG B를 반복 시켜 HE-SIG B 길이가 정렬될 수 있다. 도 18과 같이 HE-SIG B의 처음(또는 마지막)부터 필요한 페딩길이 만큼의 HE-SIG B가 HE-SIG B에 페딩될 수 있다.
일 실시예에 따르면 대역폭이 20 MHz 보다 크지 않은 경우, 하나의 HE-SIG B 필드가 전송될 수 있다. 대역폭이 20 MHz 보다 큰 경우 20 MHz 크기의 채널들은 각각 제1 타입 HE-SIG B(이하, HE-SIG B [1]) 또는 제2 타입 HE-SIG B(이하, HE-SIG B [2]) 중 어느 하나를 전송할 수 있다. 예컨대, HE-SIG B [1]와 HE-SIG B [2]가 번갈아 가며 전송될 수 있다. 홀수 번째 20 MHz 채널은 HE-SIG B [1]를 전송하고, 짝수 번째 20 MHz 채널은 HE-SIG B [2]를 전송할 수 있다. 보다 구체적으로, 40 MHz 대역폭의 경우 HE-SIG B [1]가 첫 번째 20 MHz 채널 상에서 전송되고, HE-SIG B [2]가 두 번째 20 MHz 채널 상에서 전송된다. 80 MHz 대역폭의 경우 HE-SIG B [1]가 첫 번째 20 MHz 채널 상에서 전송되고, HE-SIG B [2]가 두 번째 20 MHz 채널 상에서 전송되고, 동일한 HE-SIG B [1]가 세 번째 20 MHz 채널 상에서 반복 전송되고, 동일한 HE-SIG B [2]가 네 번째 20 MHz 채널 상에서 반복 전송된다. 160 MHz 대역폭에서도 이와 유사하게 전송된다.
이와 같이, HE-SIG B 는 대역폭의 크기가 증가함에 따라서 반복 전송될 수 있는데, 반복 전송되는 HE-SIG B는 자신과 동일한 타입의 HE-SIG B가 전송된 20 MHz 채널로부터 20 MHz 크기만큼 주파수 도약하여 전송될 수 있다.
한편, HE-SIG B [1]와 HE-SIG B [2] 각각의 컨텐츠는 상이할 수 있다. 단, HE-SIG-B [1] 들은 모두 동일한 컨텐츠를 갖는다. 마찬가지로, HE-SIG B [2] 들은 모두 동일한 컨텐츠를 갖는다.
일 실시예에 따르면, HE-SIG B [1]는 홀수 번 20 MHz 채널들에 대한 자원 할당 정보만을 포함하고, HE-SIG B [2]는 짝수 번 20 MHz 채널들에 대한 자원 할당 정보만을 포함하도록 설정될 수 있다. 본 발명의 다른 일 실시예에 따르면, HE-SIG B [1]가 짝수 번 20 MHz 채널들 중 적어도 일부에 대한 자원 할당 정보를 포함하거나, HE-SIG B [2]가 홀수 번 20 MHz 채널들 중 적어도 일부에 대한 자원 할당 정보를 포함할 수 있다.
HE-SIG B는 공통 필드(Common field) 및 사용자 특정 필드(User specific field)를 포함할 수 있다. 공통 필드는 사용자 특정 필드에 선행할 수 있다. 공통 필드와 사용자 특정 필드는 OFDM 심볼 단위가 아니라, 비트 단위로 구분될 수 있다.
HE-SIG B의 공통 필드는 해당 대역폭에서 PPDU를 수신하도록 지정된 STA들 모두에 대한 정보를 포함한다. 공통 필드는 RU(resource unit) 할당 정보를 포함할 수 있다. HE-SIG B [1]들 간에는 컨텐츠가 모두 동일하며, 마찬가지로 HE-SIG B [2]들 간에는 컨텐츠가 모두 동일하다. 예컨대, 80 MHz를 구성하는 4개의 20 MHz 채널들을 [LL, LR, RL, RR]로 구분할 때, HE-SIG B [1]의 공통 필드에 LL 및 RL 에 대한 공통 블록이 포함되고, HE-SIG B [2]의 공통 필드에 LR 및 RR 에 대한 공통 블록이 포함될 수 있다.
HE-SIG B의 사용자 특정 필드는 다수의 사용자 필드(user field)들을 포함할 수 있으며, 각 사용자 필드들은 PPDU를 수신하도록 지정된 개별 STA에 특정적인 정보를 포함할 수 있다. 일 예로, 사용자 필드는 스테이션 ID, STA 별 MCS, 스트림 수(Nsts), Coding(e.g., LDPC 사용에 대한 지시), DCM 지시자 및 송신 빔포밍 정보 중 적어도 하나를 포함할 수 있으며 이에 한정되지 않는다.
UL MU 전송
도 19는 본 발명의 일 실시예에 따른 상향링크 다중 사용자 전송 상황을 설명하기 위한 도면이다.
상술한 바와 같이 802.11ax 시스템에서는 UL MU 전송 방식이 사용될 수 있으며, 이는 도 19에 도시된 바와 같이 AP가 복수의 STA (예를 들어, STA 1 내지 STA 4)에게 트리거 프레임(Trigger Frame)을 전송함으로써 시작될 수 있다. 트리거 프레임은 UL MU 할당 정보를 포함할 수 있다. UL MU 할당 정보는 예컨대, 자원 위치 및 크기, STA ID들 또는 수신 STA 주소들, MCS 및 MU 타입(MIMO, OFDMA 등) 중 적어도 하나를 포함할 수 있다. 구체적으로 트리거 프레임은 (i) UL MU 프레임에 대한 지속 시간(duration), (ii) 할당의 수(N) 및 (iii) 각 할당의 정보 중 적어도 하나를 포함할 수 있다. 각 할당의 정보는 사용자 별 정보(Per user Info)를 포함할 수 있다. 각 할당의 정보는 예컨대, AID (MU일 경우, STA수만큼 추가로 포함됨), 전력 조절(Power adjustment), 자원(또는 톤) 할당 정보(e.g., 비트맵), MCS, 스트림 수 (Nsts), STBC, 코딩, 송신빔포밍에 대한 정보 중 적어도 하나를 포함할 수 있다.
한편, 도 19에 도시된 바와 같이 AP는 매체에 접속하기 위해 경쟁 과정을 거쳐 트리거 프레임을 전송할 TXOP를 획득할 수 있다. 이에 대해 STA들은 트리거 프레임의 SIFS 이후 AP에 의해 지시된 포맷으로 UL 데이터 프레임을 전송할 수 있다. 이에 대응하여 본 발명의 실시예에 따른 AP는 BA (Block ACK) 프레임을 통해 UL MU 데이터 프레임에 대해 확인 응답을 수행하는 것을 가정한다.
도 20은 일 실시예에 따른 트리거 프레임 포맷을 도시한다.
도 20을 참조하면, 트리거 프레임은 프레임 제어(frame control) 필드, 길이(duration) 필드, RA(recipient STA address) 필드, TA(transmitting STA address) 필드, 공통 정보(common information) 필드, 하나 또는 둘 이상의 개별 사용자 정보(Per User Info) 필드들 및 FCS(Frame Check Sum) 중 적어도 하나를 포함할 수 있다. RA 필드는 수신 STA의 주소 또는 ID를 나타내며, 실시예에 따라서 생략될 수도 있다. TA 필드는 송신 STA의 주소를 나타낸다.
공통 정보 필드는, 길이(length) 서브필드, 캐스캐이드 지시자(Cascade Indication), HE-SIG A 정보 서브필드, CP/LTF 타입 서브필드, 트리거 타입 서브필드 및 트리거-의존 공통 정보(trigger-dependent Common Info) 서브필드 중 적어도 하나를 포함할 수 있다. 길이 서브필드는 UL MU PPDU 의 L-SIG 길이를 지시한다. 캐스캐이드 지시자는 현재 트리거 프레임 다음에 후속하는 트리거 프레임의 전송이 있는지 여부를 지시한다. HE-SIG A 정보 서브필드는 UL MU PPDU 의 HE-SIG A에 포함되는 컨텐츠를 지시한다. CP/LTF 타입 서브필드는 UL MU PPDU에 포함되는 CP와 HE LTF 타입을 지시한다. 트리거 타입 서브필드는 트리거 프레임의 타입을 지시한다. 트리거 프레임은 해당 타입 특정한 공통 정보 및 타입 특정한 개별 사용자 정보(Per User Info)를 포함할 수 있다. 트리거 타입은, 예컨대, 베이직 트리거 타입(e.g., 타입 0), 빔포밍 보고 폴 트리거(Beamforming Report Poll Trigger) 타입(e.g., 타입 1), MU-BAR(Multi-user Block Ack Request) 타입(e.g., 타입 2) 또는 MU-RTS(multi-user ready to send) 타입(e.g., 타입 3) 중 어느 하나로 설정될 수 있으며, 이에 한정되지 않는다. 트리거 타입이 MU-BAR인 경우, 트리거 의존 공통 정보 서브필드는 GCR(Groupcast with Retries) 지시자 및 GCR 주소를 포함할 수 있다.
개별 사용자 정보 필드(Per User Info field)는 사용자 식별자 서브필드, RU(resource unit) 할당 서브필드, 코딩 타입 서브필드, MCS 필드, DCM(dual sub-carrier modulation) 서브필드, SS(spatial stream) 할당 서브필드 및 트리거 의존 개별 사용자 정보(Trigger dependent Per User Info) 서브필드 중 적어도 하나를 포함할 수 있다. 사용자 식별자 서브필드는 UL MU PPDU의 MPDU를 전송하기 위하여 해당 자원 유닛(resource unit)을 사용할 STA의 AID를 지시한다. RU 할당 서브필드는 해당 STA이 UL MU PPDU를 전송하기 위한 자원 유닛을 지시한다. 코딩 타입 서브필드는 해당 STA이 전송하는 UL MU PPDU의 코딩 타입을 지시한다. MCS 서브필드는 해당 STA이 전송하는 UL MU PPDU의 MCS를 지시한다. DCM 서브필드는 해당 STA이 전송하는 UL MU PPDU의 이중 캐리어 변조에 대한 정보를 지시한다. SS 할당 서브필드는, 해당 STA이 전송하는 UL MU PPDU의 공간 스트림(spatial streams)에 대한 정보를 지시한다. 트리거 타입이 MU-BAR인 경우, 트리거 의존 개별 사용자 정보 서브필드는 BAR 제어 및 BAR 정보를 포함할 수 있다.
NAV (network allocation vector)
NAV는 송신 STA(e.g., TXOP holder) TXOP를 보호하기 위한 일종의 타이머로 이해될 수 있다. STA은 자신에게 설정된 NAV가 유효한 기간 동안에는 채널 엑세스를 수행하지 않음으로써, 다른 STA의 TXOP를 보호할 수 있다.
현재 non-DMG STA의 경우 하나의 NAV를 지원한다. 유효한(valid) 프레임을 수신한 STA은 PSDU의 duration 필드(e.g., MAC 헤더의 duration 필드)를 통해서 NAV를 업데이트 할 수 있다. 다만, 수신된 프레임의 RA 필드가 해당 STA의 MAC 주소와 일치하는 경우, STA은 NAV를 업데이트 하지 않는다. 수신된 프레임의 duration 필드에 의해 지시된 duration이 STA의 현재 NAV 값보다 크면, STA은 수신된 프레임의 duration을 통해서 NAV를 업데이트 한다.
도 21은 NAV 설정(setting)의 일 예를 도시한다.
도 21을 참조하면, Source STA은 RTS 프레임을 전송하고, Destination은 CTS 프레임을 전송한다. 상술된 바와 같이 RTS 프레임을 통해서 수신자로 지정된 destination STA은 NAV를 설정하지 않는다. 나머지 STA들 중 일부는 RTS 프레임을 수신하여 NAV를 설정하고, 또 다른 일부는 CTS 프레임을 수신하여 NAV를 설정할 수 있다.
RTS 프레임이 수신된 시점으로부터(e.g., MAC이 RTS 프레임에 대응하는 PHY-RXEND.indication primitive를 수신한 시점) 일정 기간 내에서 CTS 프레임(e.g., PHY-RXSTART.indication primitive)이 수신되지 않는다면, RTS 프레임을 통해서 NAV를 설정 또는 업데이트한 STA들은 NAV를 리셋(e.g., 0)할 수 있다. 일정 기간은, (2*aSIFSTime + CTS_Time + aRxPHYStartDelay + 2*aSlotTime)일 수 있다. CTS_Time은 RTS 프레임이 지시하는 CTS 프레임의 길이 및 데이터 레이트에 기초하여 계산될 수 있다.
도 21에서는 편의를 위하여 RTS 프레임 또는 CTS 프레임을 통해서 NAV를 설정 또는 업데이트하는 것을 예시하였으나, NAV 설정/재설정/업데이트는 다른 다양한 프레임들 예컨대, non-HT PPDU, HT PPDU, VHT PPDU 또는 HE PPDU의 duration 필드(e.g., MAC 프레임의 MAC 헤더 내의 duration field)에 기초하여 수행될 수도 있다. 예컨대, 수신된 MAC 프레임에서 RA 필드가 자신의 주소(e.g., MAC 주소)와 일치하지 않는다면, STA은 NAV를 설정/재설정/업데이트할 수 있다.
TXOP (Transmission Opportunity) Truncation
도 22는 TXOP truncation의 일 예를 도시한다.
TXOP holder STA은 CF-END 프레임을 전송함으로써 TXOP를 절단(truncation)할 수 있다. CF-END 프레임 또는 CF-END+CF-ACK 프레임을 수신한 STA은 NAV를 리셋(e.g., 0)할 수 있다.
EDCA를 통해서 채널 엑세스를 획득한 STA이 자신의 송신 큐(queue)를 비운 경우, CF-END 프레임을 송신할 수 있다. STA은 CF-END 프레임의 송신을 통해서 자신의 TXOP 완료를 명시적으로 지시할 수 있다. CF-END 프레임은 TXOP holder에 의해 전송될 수 있다. TXOP holder가 아닌 non-AP STA은 CF-END 프레임을 전송할 수 없다. CF-END 프레임을 수신한 STA은 CF-END 프레임이 포함된 PPDU의 종료시점에서 NAV를 리셋한다.
도 22를 참조하면, EDCA를 통해서 매체에 엑세스한 STA은 NAV 설정을 위한 시퀀스(e.g., RTS/CTS 등)를 전송한다.
SIFS 이후, TXOP holder(또는 TXOP initiator)와 TXOP responder 는 PPDU들을 송수신 한다(e.g., initiator sequence). TXOP holder는 TXOP 한도 내에서 더 이상 전송할 수 있는 데이터가 없을 경우, CF-END 프레임을 전송함으로써 TXOP를 절단(truncate)한다.
CF-END 프레임을 수신한 STA들은 자신의 NAV를 리셋하고, 더 이상의 지연 없이 매체 엑세스를 위한 경쟁(contending)을 시작할 수 있다.
상술된 바와 같이 현재 무선랜 시스템에서 TXOP duration은 MAC 헤더의 Duration 필드를 통해 설정된다. 즉, TXOP holder (e.g., Tx STA) 와 TXOP Responder (e.g., Rx STA)은 이들 간에 송수신 하는 프레임의 Duration 필드에, 프레임들의 송수신에 필요한 전체 TXOP 정보를 포함시켜 전송한다. TXOP holder나 TXOP Responder가 아닌 제 3의 STA들 (i.e., Third party STAs)은 TXOP holder와 TXOP Responder간에 교화되는 프레임의 Duration 필드를 확인하고, NAV를 설정/업데이트함으로써 NAV 기간 까지 채널 사용을 연기한다.
HE PPDU를 지원하는 11ax 시스템에서, UL MU PPDU가 HE-SIG B를 포함하지 않으면, 제 3의 STA들은 UL MU PPDU를 수신하더라도 UL MU PPDU에 포함된 MPDU를 디코딩할 수 없다. 제3의 STA들이 MPDU를 디코딩 할 수 없다면, 제3의 STA들이 MPDU의 MAC 헤더에 포함된 TXOP Duration 정보(e.g., Duration 필드)를 획득할 수 없다. 따라서, NAV 설정/업데이트가 올바르게 수행되기 어려운 문제점이 있다.
HE-SIG B를 포함하는 HE PPDU 프레임이 수신되더라도, HE-SIG B 구조가 STA별로 다르게 코딩 되고 STA들이 자신에게 할당된 HE-SIG B 컨텐츠만 읽을 수 있도록 HE-SIG B 구조가 설계되는 경우, 제 3의 STA들은 다른 STA들이 송수신하는 MAC 프레임(e.g., HE PPDU 내에 다른 STA의 MPDU)을 디코딩 할 수 없다. 따라서, 이 경우에도 제3 STA들은 TXOP 정보를 획득할 수 없는 문제점이 있다.
● HE- SIG A를 통한 TXOP Duration 지시
이와 같은 문제점을 해결하기 위하여, STA은 TXOP duration 정보를 HE-SIG A에 포함시켜 전송하는 방법이 제안된다. 상술된 바와 같이 MAC 헤더의 duration 필드 중 15비트(e.g., B0~14)가 duration 정보를 지시하고, 최대 약 32.7ms(0~32767 us)를 지시 할 수 있다. MAC 헤더의 duration 필드에 포함된 15 비트의 duration 정보를 그대로 HE-SIG A에 포함시켜 전송하는 경우, 11ax third party STA이 올바르게 NAV설정/업데이트를 할 수는 있겠으나, HE-SIG A의 시그널링 오버헤드가 지나치게 증가되는 문제점이 있다. MAC 계층에서 페이로드 전송을 위한 MPDU 내에서 15비트는 상대적으로 작은 크기라 할 수 있지만, 물리 계층에서 공통 제어 정보 전송을 위한 HE-SIG A는 Compact하게 설계된 필드이므로 HE-SIG A 내에서 15 비트의 증가는 상대적으로 큰 시그널링 오버헤드에 해당한다.
따라서 본 발명의 일 실시예에서는 HE-SIG A의 오버헤드를 최소화하는 TXOP duration의 효율적인 지시 방법이 제안된다. 또한, HE-SIG A 내에 새롭게 정의된 TXOP duration을 기반으로 하는 프레임 송수신 동작이 제안된다. 이하에서, MAC 헤더의 포함된 duration 필드는 편의상 MAC duration으로 지칭될 수 있다.
이하의 실시예에서 TXOP duration 정보는 HE SIG A에 포함되어 전송되는 것을 가정하나, 본 발명의 권리범이는 이에 한정되지 않으며 다른 부분(e.g., L-SIG, HE-SIG B, HE-SIG C, …, A-MPDU나 MPDU 의 부분)를 통해서 전송될 수도 있다. 예를 들어, HE-SIG B를 통해서 TXOP duration가 전송될 경우, HE-SIG B의 공통 정보(e.g., common part) 또는 HE-SIG B에서 맨 처음(또는 맨 마지막) 부분에 전송되는 SIG B contents part(e.g., Per user Info)에서 전송될 수 있다.
이하, HE SIG 필드 내에서 TXOP duration의 구조와 이를 지시하는 실시예들에 대해서 살펴본다. 제3 STA의 NAV에 설정된 값은 TXOP holder/Responder에 대한 TXOP Duration으로 해석될 수 있다. 예컨대, Duration 필드 값은 TXOP holder/Responder의 관점에서는 프레임 송수신을 위한 TXOP이나, 제3 STA의 관점에서는 NAV 값을 의미한다. 따라서, 제3 STA들이 NAV를 설정/업데이트하는 동작은 TXOP holder/Responder에 대한 TXOP 만큼 NAV를 설정하는 것이므로, 제3 STA들이 NAV를 설정/업데이트하는 동작은 편의상 TXOP를 설정/업데이트하는 동작으로 지칭될 수도 있다. 또한, TXOP Duration의 용어는 간략히 Duration으로 지칭되거나 또는 간략히 TXOP로 지칭될 수도 있다. TXOP Duration은 경우에 따라서 프레임 내에서 필드(e.g., HE-SIG A내의 TXOP Duration 필드)를 지칭하는데 사용되거나 또는 실제 TXOP Duration 값을 지칭하는데 사용될 수도 있다.
후술하는 실시예들에 할당된 인덱스는 설명의 편의를 위한 것이므로, 서로 다른 인덱스를 갖는 실시예들이 조합됨으로써 하나의 발명이 실시될 수도 있고 또는 각각이 개별적인 발명으로 실시될 수도 있다.
TXOP duration의 실시예 1
TXOP duration은 2N-1 (또는 2N)로 설정될 수 있다. 편의상 TXOP duration이 2N-1로 설정되었다고 가정한다. N값이 HE-SIG A의 TXOP duration 필드에서 전송될 수 있다
예컨대, N이 4비트 크기일 경우, N은 0~15의 값을 가진다. 따라서, 4비트 크기의 N을 통해서 지시되는 TXOP duration은 0~32767 us의 값을 갖을 수 있다. 이와 달리, TXOP duration이 최대 5ms를 지시하도록 설정되는 경우, N=0~13의 값만이 TXOP duration을 지시하는데 사용되고, N=14 및 15는 다른 목적을 위해서 사용될 수도 있다.
본 실시예는 X * 2Y-1 방식으로 TXOP duration을 지시하는 방법들 중 하나의 예시이고(e.g., X=1인 경우), X 및/또는 Y는 다양하게 변경될 수 있다. 또한, X 및 Y 값이 HE-SIG A 필드를 통해서 전송될 수 있다.
TXOP duration의 실시예 2
본 발명의 일 실시예에 따르면 TXOP duration 은 XY-1(또는 XY)로 설정될 수 있다. 편의상 XY-1로 설정되었다고 가정한다. STA은 X와 Y 값을 TXOP duration 필드(e.g., HE-SIG A 내)를 통해서 전송할 수 있다.
HE-SIG A에서 전송되는 TXOP duration 필드가 총 K비트이라 가정하면, K 비트 중 n 비트(e.g., 앞의 n 비트)는 X의 값을 지시하고, m 비트(e.g., 뒤의 m 비트)는 Y의 값을 지시할 수 있다. n 비트는 MSB n 비트이거나 또는 LSB m비트 일 수 있으며, m 비트는 LSB m비트이거나 또는 MSB m 비트 일 수 있다. K, m, n 값은 다양하게 설정될 수 있다.
(i) 일 예로, K=6, n=3, m=3이라 가정한다. X∈{2~9}의 정수이고, Y∈{0~7}의 정수일 수 있다. 이 경우 TXOP duration 값은 0 ~ 4782968us을 가질 수 있다.
(ii) 다른 예로, K=5, n=2, m=3이라 가정한다. X∈{2~5}의 정수이고, Y∈{0~7}의 정수 일 수 있다. 이 경우 TXOP duration 값은 0 ~ 78124us을 가질 수 있다. 이와 달리, X∈{2, 3, 5, 6} 중 하나의 정수 이고, Y∈{0~7} 정수라면, TXOP duration 값은 0 ~ 78124us을 가질 수 있다.
(iii) 또 다른 예로, K=4, n=1, m=3이라 가정한다. X∈{2, 3} (또는 X∈{5, 6}) 중 하나의 정수이고, Y∈{0~7}의 정수 일 수 있다. TXOP duration 값은 0 ~ 279963us을 가질 수 있다.
만약, TXOP duration 필드(e.g., HE-SIG A 내)를 통해서 최대 P ms (e.g., 5ms)까지 지시하고자 하는 경우, XY-1≥ P ms (e.g., 5ms)를 만족시키는 (X, Y) 조합들 중에서 XY-1 가 최소가 되는 (X, Y) 조합이 최대 TXOP duration 값을 지시하는데 사용되고 나머지 (X, Y) 조합은 사용되지 않을 수 있다.
본 실시예는 Z * XY-1 방식으로 TXOP duration을 지시하는 방법들 중 하나의 예시이고, X, Y 및/또는 Z는 다양하게 변경될 수 있다.
TXOP duration의 실시예 3
본 발명의 일 실시예에 따르면 TXOP duration은 X * 2Y-1(또는 X* 2Y)로 설정될 수 있다. X와 Y 값이 TXOP duration 필드를 통해서 전송될 수 있다.
HE-SIG A에서 전송되는 TXOP duration 필드가 총 K 비트이라 가정하면, K 비트 중 n 비트(e.g., 앞의 n 비트)는 X의 값을 지시하고, m 비트(e.g., 뒤의 m 비트)는 Y의 값을 지시할 수 있다. n 비트는 MSB n 비트이거나 또는 LSB m비트 일 수 있으며, m 비트는 LSB m비트이거나 또는 MSB m 비트 일 수 있다. K, m, n 값은 다양하게 설정될 수 있다.
예컨대, K=6, n=3, m=3 이라고 가정한다. X∈{1, 5, 10, 20, 30, 40, 50, 60}이고 Y∈{0~7}일 수 있다. 이 경우, TXOP duration 값은 0 ~ 7680us을 가지게 될 것이다.
만약, TXOP duration 필드(e.g., HE-SIG A 내)를 통해서 최대 P ms (e.g., 5ms)까지 지시하고자 하는 경우, X * 2Y-1≥ P ms (e.g., 5ms)를 만족시키는 (X, Y) 조합들 중에서 X * 2Y-1가 최소가 되는 (X, Y) 조합이 최대 TXOP duration을 지시하는데 사용하고 나머지 (X, Y) 조합은 사용되지 않을 수 있다.
본 실시예는 X * ZY-1 방식으로 TXOP duration을 지시하는 방법들 중 하나의 예시이고, X, Y 및/또는 Z는 다양하게 변경될 수 있다.
TXOP duration의 실시예 4
일 실시예에 따르면, TXOP Duration은, 1 마이크로 세컨드(us) 대신에 다른 단위(e.g., 더 큰 단위 또는 심볼 단위)로 설정될 수도 있다. 예를 들어, 4us,8us, 10 us, 16us, 32us, 50us, 64us, 100us, 128us, 256us, 500us, 512us, 1024us,… 등과 같이 더 큰 단위가 사용될 수 있다. 이 경우, TXOP duration의 값은 unit (e.g., 64us) * value of TXOP duration field 로 결정될 것이다. 예를 들어, 32us단위일 때, TXOP Duration (1) = 32us, TXOP Duration (2)= 64us, TXOP Duration (3) = 96us, … 될 수 있다.
한편, TXOP Duration은 8ms까지 최대 값을 가지는 것이 바람직하다. 따라서, 단일 단위(unit)가 사용될 때, 아래와 같은 TXOP Duration field 옵션들이 고려될 수 있다.
- 옵션 1: 32 us unit이 사용되고, 8 비트 크기의 TXOP Duration 필드가 정의된다. 이 때, 최대(maximum) TXOP duration 값은 8192us일 수 있다.
- 옵션 2: 64us unit이 사용되고, 7 비트 크기의 TXOP Duration 필드가 정의된다. 이 때, maximum TXOP duration 값은 8192us일 수 있다.
TXOP field의 크기가 8비트 보다 좀 더 크게 설정된다면(e.g, 9~11 bits), 다음과 같은 TXOP Duration field 구조가 사용될 수도 있다.
- 옵션 가-1: 16us unit, ~32ms, 11 bits
- 옵션 가-2: 16us unit, ~16ms, 10 bits
- 옵션 가-3: 16us unit, ~8ms, 9 bits
- 옵션 나-1: 32us unit, ~32ms, 10 bits
- 옵션 나-2: 32us unit, ~16ms, 9 bits
- 옵션 다-1: 64us unit, ~16ms, 9 bits
또한, 하나 이상의 단위(unit)들의 조합(e.g., (16us, 512us) or (8us, 128us), etc.) 을 사용해서 사용할 수 있다. 또는, us 대신에 1x symbol 또는 4x symbol 단위가 사용되거나 또는 N * 1x symbol, N * 4x symbol 단위 (N은 자연수)로 표시될 수 있다.
표 1은 4x symbol 단위로 지시되는 TXOP Duration을 예시한다.
[표 1]
Figure PCTKR2016005341-appb-I000001
상술된 실시예 1/2/3 중 하나와 실시예 4의 조합을 통해서 TXOP duration이 지시될 수도 있다.
TXOP duration의 실시예 5
일 실시예에 따르면 TXOP Duration 필드는 사전 정의된 값을 가질 수 있다. 예컨대, TXOP duration 필드에 설정되는 값(e.g., TXOP duration 인덱스)과 실제 TXOP duration 값을 맵핑하는 테이블이 사전 정의될 수 있다. 표 2는 TXOP duration 인덱스를 예시한다.
[표 2]
Figure PCTKR2016005341-appb-I000002
일 실시예에 따르면 TXOP Duration의 일부 범위는 제1 함수 형태로 표현되고, 다른 범위는 제2 함수 형태로 표현/구성 될 수 있다. 예를 들어, 특정 값까지는 TXOP Duration이 지수(exponential) 함수 형태로 증가하고, 특정 값 다음부터는 uniform distribution 함수 형태로 증가하도록 설정될 수 있다.
표 3은 TXOP Duration 필드가 4비트로 설정된 경우를 예시한다. 표 3을 참조하면 32us ~ 512us (또는 1024us) 까지는 TXOP Duration가 지수적으로 증가하고, 512us (1024us) 부터는 512us(약0.5ms)씩 증가한다.
[표 3]
Figure PCTKR2016005341-appb-I000003
표 4는 TXOP Duration 필드가 5비트로 설정된 경우를 예시한다. 표 4를 참조하면 32us ~ 256us (또는 512us) 까지는 TXOP Duration가 지수적으로 증가하고, 256us (512us) 부터는 256us(약0.25ms)씩 증가한다.
[표 4]
Figure PCTKR2016005341-appb-I000004
TXOP duration의 실시예 6
일 실시예에 따르면, TXOP Duration은 X비트의 크기의 scaling factor와 Y비트 크기의 duration 값을 통해서 설정될 수 있다. 예컨대, TXOP duration은 값은 Scaling factor (X bits) * Duration (Y bits)에 기초하여 설정될 수 있다. 구체적으로 TXOP duration = Scaling factor (X bits) * Duration (Y bits)일 수 있다. 또는, TXOP duration = Scaling factor (X bits) * Duration (Y bits) + a이고, a는 소정의 상수일 수 있다(e.g., a=1).
TXOP duration 필드의 크기는 X + Y bits로 설정될 수 있다.
예컨대, Duration 값의 단위는 scaling factor에 의해서 1us, 4 us, 16 us 들 중 하나로 설정될 수 있다. Y bits의 길이는 다양하게 설정될 수 있다.
X비트의 scaling factor 인덱스 0은 실제 scaling factor=0을 지시할 수 있다. 표 5의 Case A 및 Case B는 각각 2bits 크기의 Scaling factor의 일례들을 나타낸다.
[표 5]
Figure PCTKR2016005341-appb-I000005
표 6은 3bits 크기의 Scaling factor의 일례를 나타낸다.
[표 6]
Figure PCTKR2016005341-appb-I000006
한편, Duration 값은 2Y형태로 표현될 수도 있다.
TXOP duration의 실시예 7
일 실시예에 따르면 TXOP Duration은 X비트의 크기의 scaling factor와 Y비트 크기의 duration 값, Z비트 크기의 duration 단위 정보를 통해서 지시될 수 있다. TXOP duration은 ‘Scaling factor (X bits) * (Duration (Y bits) us * Duration unit (Z bits)us)’일 수 있다. TXOP duration field의 크기는 (X + Y + Z )bits로 설정될 수 있다.
Z비트 크기의 duration 단위는 전송되는 duration 정보의 단위를 나타낸다. 예를 들어 Z 비트 크기가 1비트 일 때, 0은 4us단위를 지시하고, 1은 16us단위를 지시할 수 있으며, 이에 한정되지 않는다.
● TXOP Termination / Truncation 방안
한편, 상술된 실시예에 따르면, HE-SIG A의 TXOP duration 필드는 상대적으로 큰 granularity 기반으로 TXOP duration이 설정될 수 있다. 예를 들어, MAC 헤더에 포함되는 Duration 필드는 1 us granularity 기반으로 지시될 수 있는데 비하여, HE-SIG A의 TXOP duration 필드는 그보다 더 큰 granularity 기반으로 TXOP duration값을 지시하도록 설정될 수도 있다.
이와 같이 HE-SIG A의 TXOP duration 필드에 의해 상대적으로 큰 granularity 기반으로 TXOP duration이 설정되면 실제 frame 전송에 사용되는 것보다 더 긴 시간이 TXOP duration으로 설정될 수 있다. 따라서, 다른 STA들이 HE-SIG A에 기초하여 잘못된 NAV를 설정하여 특정시간 동안 채널 사용을 못 할 수 있고, 채널 효율성이 떨어질 수 있다.
이와 같은 문제점을 해결하기 위하여, TXOP의 조기 종료(Early termination) 을 위한 정보가 전송될 수 있다. 예컨대, TXOP holder/responder는 TXOP 구간 동안에 마지막 프레임(e.g., ACK, Block ACK, Multi-STA BA)을 전송할 때, TXOP를 조기 종료 한다는 것을 지시하는 정보를 마지막 프레임에 포함시켜 전송할 수 있다. TXOP 조기 종료(termination)는, TXOP truncation으로 표현되거나 또는 간략히 (early) termination/truncation으로 표현될 수도 있다. 이하, TXOP를 종료하는 방안들을 살펴본다.
(1) CF-END 프레임을 사용하는 방안
TXOP holder/responder는 TXOP 구간 동안에 마지막 프레임을 전송한 후, CF-END 프레임을 전송함으로써 TXOP을 종료(termination) 할 수 있다.
(2) 조기 종료 지시자(Early termination indicator)를 사용하는 방안
일 실시예에 따르면 STA은 조기 종료 지시자(Early termination indicator)를 프레임의 일부(e.g., HE-SIG A, HE-SIG B의 common part, etc.)에 포함시켜 전송할 수 있다. 예컨대, STA은 Early termination indicator= 1로 설정하면, TXOP가 조기 종료됨을 지시할 수 있다. TXOP는 Early termination indicator=1을 포함하는 프레임 이후에 즉시 종료될 수 있다. 한편, Early termination indicator는 Duration과 조합되어 사용될 수도 있다. 예를 들어, Early termination indicator=1이면 Duration 이 지시하는 시간에서 TXOP 가 종료된다는 것이 지시될 수 있다. Duration = 0이면 해당 프레임 후에 TXOP이 종료되고, Duration이 0 이상의 값이면 Duration이 지시하는 시간에서 TXOP가 종료될 수 있다.
(i) TXOP 조기 종료 지시자로서 MD (More data) 필드 또는 ESOP 필드가 재사용될 수도 있다.
(ii) DL frame일 경우, 조기 종료 지시자는 설정된 TXOP 의 마지막 프레임을 통해 전송될 수 있다. 예컨대, 마지막 프레임에서 조기 종료 지시자와 함께 TXOP Duration이 업데이트되어 전송될 수 있다. TXOP Duration은 기존의 TXOP Duration 보다 작은 값으로 설정되고, 조기 종료 지시자를 통해서 TXOP의 종료가 지시될 수 있다.
(iii) TXOP 정보의 업데이트가 필요한 경우 STA(e.g., TXOP holder/responder)은 프레임을 전송할 때 업데이트 되는 TXOP을 설정하여 프레임을 전송한다. TXOP를 업데이트하는 프레임에서 조기 종료 지시자(Early termination indicator)는 TXOP 업데이트 지시자로 사용된다. 예컨대, TXOP가 업데이트 될 때마다, 조기 종료 지시자=1로 설정되어 전송될 수 있다. 조기 종료 지시자=1로 설정된 프레임을 수신한 STA(e.g., third party)은 해당 STA의 TXOP를 업데이트 한다(e.g., NAV 업데이트).
(iv) 단일 프레임(e.g., PPDU) 전송의 경우는, ACK/BA의 크기로 TXOP duration이 설정될 수 있다. 다중 프레임 전송의 경우, 다중 프레임 및 ACK/BA전송을 위해 TXOP duration이 설정될 수 있다.
(v) UL MU 전송: 트리거 프레임이 non-HT PPDU(e.g., 11a format)로 전송된다면, 트리거 프레임의 콘텐츠에서 정확한 TXOP duration이 지시되므로 레거시 STA(e.g., 11ax를 지원하지 않는 STA)이라도 TXOP duration을 올바르게 설정할 수 있다(e.g., NAV 설정/업데이트). 또한 UL MU 프레임에서는 ACK/BA 프레임의 전송 길이만큼 TXOP duration을 지시하므로 NAV 설정/업데이트는 문제되지 않는다.
하지만, 11ax format이 사용되고, HE-SIG A에 설정된 TXOP duration과 프레임의 컨텐츠에 포함된 TXOP duration 정보(e.g., MAC 헤더의 TXOP duration)가 다른 경우가 문제된다. 예컨대, 일부 STA(e.g., third party)은 HE-SIG A만 읽고, 다른 STA들(e.g., third party)은 HE-SIG A 및 프레임 콘텐츠를 모두 읽었을 수 있다.
둘 다 읽은 STA들은 프레임 콘텐츠(e.g., MAC header)의 Duration 정보를 통해서 TXOP를 설정한다. 예컨대, 둘 다 읽은 STA들은, HE-SIG A에 포함된 duration 정보를 가지고 있다가, MAC 헤더의 Duration (또는 Contents의 duration)을 읽고 나면, STA들은 HE-SIG A의 duration 대신에 MAC 헤더의 duration (또는 contents의 duration)에 기초하여 최종 TXOP duration을 결정하여 NAV를 업데이트 한다.
HE-SIG A만 읽은 STA들은 HE-SIG A에 포함된 TXOP duration에 기초하여 NAV를 업데이트 한다. 이 경우에도, 실제 MAC 헤더의 TXOP duration 보다 긴 TXOP duration 설정 문제 될 수 있다. 예컨대, UL MU 프레임에 대한 ACK/BA/M-BA 프레임이 전송될 때 STA은 HE-SIG A/B 또는 MAC header에 포함된 TXOP duration 정보를 통해서 TXOP을 업데이트 하되(e.g., NAV 업데이트), 조기 종료 지시 (또는 TXOP 업데이트 지시자)가 1로 설정되면 TXOP를 해당 시점에서 종료 할 수 있다.
(vi) 한편, TXOP의 종료(Termination)는 BSS color에 기초하여 수행될 수도 있다. 예를 들어, STA(e.g., third party)은 자신의 BSS color에 해당하는 프레임을 통해서 TXOP 종료가 지시 된 경우에 만, TXOP를 종료하도록 설정될 수도 있다. STA(e.g., third party)은 프레임에 포함된 BSS color를 확인한다. 만약 BSS Color가 Other BSS임을 나타내는 경우 해당 프레임이 TXOP의 종료를 지시하더라도 STA(e.g., third party)은 TXOP를 종료시키지 않는다. 따라서 STA(e.g., third party)은 자신의 BSS의 프레임이 TXOP 종료를 지시하는 경우(e.g., 명시적 지시자 또는 duration이 0으로 설정되는 암묵적 지시)에만 TXOP을 종료(termination/truncation)할 수 있다. 다만, Other BSS에 대한 해당 STA의 엑세스 기회 손실이 발생할 수는 있다.
(vi) 일 실시예에 따르면, STA은 (e.g., TXOP holder/responder)가 TXOP 내에서 11ax 프레임을 전송함에 있어서, 마지막 프레임에는 반드시 TXOP 종료(termination/truncation) 정보를 포함시켜 전송할 수 있다. 한편, 11a 프레임의 경우에는 MAC 헤더의 duration을 통해서 TXOP가 설정되기 때문에, 정확한 TXOP 가 설정될 수 있다. 일 실시예에 따르면 HE-SIG A의 TXOP duration에 MAC header의 duration이 덮어 쓰여질 수도 있다.
(3) 마지막 프레임의 Duration field값을 이용하는 방안
일 실시예에 따르면, STA(e.g., TXOP holder/responder)은 명시적인 TXOP 종료 지시자를 사용하는 대신에, 마지막 프레임의 Duration field값을 특정 값으로 설정(e.g., 0 또는 모든 비트를 1로 설정)하여 TXOP 조기 종료(early termination/truncation)를 지시할 수도 있다. 따라서, STA(e.g., third party)이 Duration = 특정 값(e.g., 0)을 지시하는 프레임을 수신하면, 해당 프레임 이후에 TXOP duration이 종료(termination /truncation)되었다고 판단할 수 있다. 이는, CF-END 프레임과 유사한 역할로 이해될 수 있다.
(4) TXOP duration 종료를 위한 NAV 업데이트 /리셋
기존의 NAV 설정/업데이트 방식에 따르면, 수신된 프레임의 TXOP Duration 값이 STA(e.g., third party)에 현재 설정된 NAV 값 보다 큰 경우에만 NAV 업데이트가 수행되었다. TXOP의 조기 종료를 위해서는, STA에 현재 설정된 NAV 값보다 수신된 프레임의 TXOP duration 값이 작은 경우에도 NAV가 업데이트될 필요가 있다. 일 실시예에 따르면 STA은 상술한 TXOP 종료/업데이트 지시자(truncation/termination/update indicator)에 기초하여, STA에 현재 설정된 NAV 값 보다 작은 TXOP duration으로 NAV를 업데이트 할 수도 있다. 단, 현재 설정된 NAV 값 보다 작은 TXOP duration으로 NAV를 업데이트하는 것은 내 BSS(my BSS) 프레임에 포함된 TXOP 종료/업데이트 지시자에만 기초하여 수행되도록 설정될 수도 있다.
● NAV 관리
도 23은 기존 NAV 관리 방법에 따른 문제점을 예시한다.
레거시 무선랜 시스템(e.g., 11a/b/g/n/ac)에서 STA은 하나의 NAV를 유지한다. STA은 프레임(e.g., 자신을 수신자로 지시하지 않는 프레임)을 수신하면, 프레임의 MAC 헤더 내에 duration 필드(e.g., MAC duration)에 의해서 계산된 NAV가 자신에 설정된 현재 NAV보다 큰지를 판단한다. MAC duration에 의해서 계산된 NAV가 현재 NAV 보다 더 크면 STA은 MAC duration을 통해서 NAV를 업데이트 한다.
이와 같이 하나의 NAV 만을 관리하는 STA의 현재 NAV가 0 이 아닐 때에 STA이 CF-END 프레임을 수신하면, STA은 NAV를 리셋(e.g., NAV 타이머를 0으로 설정)한다. 하지만, NAV 리셋 이전에 해당 NAV가 다중의 프레임들에 의해 업데이트 되어왔다면, CF-END에 의한 NAV 리셋은 다른 프레임 전송에 영향을 미칠 수 있다.
도 23을 참조하면, AP2와 STA 3는 상호 프레임을 송수신하고 있으며, 이를 위하여 STA 2에는 NAV가 설정되었다고 가정한다. 또한, AP 2와 STA 3는 서로 프레임을 교환하는데 있어서, AP 1 및 STA 1에 영향을 주지 않는다고 간주한다. 예컨대, (AP2, STA 3)의 채널 엑세스와 (AP1, STA 1)의 채널 엑세스 간에는 상호 간에 영향이 없다고 가정한다.
따라서, AP 2 및 STA 3가 프레임(e.g., 데이터/ACK)을 교환하는 동안에도, AP 1과 STA 1이 RTS, CTS 프레임을 교환할 수 있다. 예컨대, AP 1은 STA 1을 수신자로 지정하여 RTS 프레임을 전송한다. STA 1은 RTS에 대한 응답으로, CTS 프레임을 AP 1에 전송한다. CTS 프레임의 RA 필드는 RTS 프레임의 TA 필드와 동일하게 설정되고, CTS 프레임의 Duration은 RTS 프레임의 Duration으로부터 획득될 수 있으며, CTS 프레임에서는 TA 필드가 생략될 수 있다.
STA 2는 AP 1의 RTS 프레임을 수신하지는 못하였지만, STA 1의 CTS 프레임을 수신하였다고 가정한다. STA 1의 CTS 프레임을 수신한 STA 2는 자신이 CTS 프레임의 수신자로 지정되지 않았음을 파악하고, CTS 프레임이 지시하는 Duration에 기초하여 NAV를 업데이트한다. 예컨대, STA 2의 현재 NAV 값보다 CTS 프레임이 지시하는 Duration이 더 크면, STA 2는 NAV를 업데이트 한다.
AP 2는 STA 3로부터 ACK를 수신하면, TXOP truncation을 위하여 CF-END 프레임을 전송한다. CF-END 프레임을 전송하는 AP 2는, STA 2의 NAV가 STA 1의 CTS 프레임에 의해 업데이트 되었다는 사실은 알 수 없다.
STA 2는 AP 2로부터 수신한 CF-END 프레임에 기초하여, NAV 를 리셋한다. 예컨대, STA 2의 경우 AP 1/STA 1의 TXOP 보호를 위하여 NAV를 업데이트 하였음에도, AP2 로부터 CF-END 프레임이 수신되면 NAV 리셋을 수행한다. 기존의 NAV 관리 동작에 따르면 CF-END/RTS/CTS 등의 제어 프레임이 수신되면, STA은 해당 제어 프레임의 RA(receiver address)와 자신의 주소 간의 동일성을 판별한다. STA의 주소와 일치하지 않는 프레임들에 대해서 STA은, TXOP holder/responder에 관계 없이 하나의 NAV를 관리한다.
NAV 를 리셋한 STA 2는 채널에 엑세스가 가능하므로, AP 2에 데이터를 전송할 수 있다. 하지만 STA 2의 데이터 프레임 전송은, AP1과 STA 1의 데이터/ACK 송수신에 영향을 미친다.
이와 같이 NAV가 TXOP holder/responder 1(e.g., AP1/STA1)을 통해서 업데이트 되고 해당 NAV가 끝나지 않은 상태에서 TXOP holder/responder 2(e.g., AP2/STA3)에 의해 NAV가 리셋되었다고 가정하면, NAV 리셋은 TXOP holder/responder 1의 데이터 송수신에 영향을 줄 수 있다.
상술한 기존의 NAV 관리 동작의 문제점을 해결하기 위한 NAV 관리(e.g., 설정, 업데이트 및/또는 리셋) 방안들을 살펴본다.
본 발명의 일 실시예에 따르면 STA은 BSS를 고려하여 NAV를 관리할 수 있다.
일 예로 STA은 BSS color별로 NAV를 설정 및 유지할 수도 있다. BSS color별로 NAV를 설정한 STA은, TXOP truncation 을 지시하는 프레임이 수신되면, 수신된 프레임이 지시하는 BSS Color에 해당하는 NAV의 TXOP를 truncation할 수 있다.
또한, NAV 설정 및 관리의 복잡성을 저감하기 위하여, STA은 내 BSS(my BSS) NAV와 Other BSS NAV(e.g., 내 BSS가 아닌 BSS 또는 my BSS를 지시하지 않는 프레임)로 두 가지 NAV를 설정 및 유지할 수도 있다. 내 BSS NAV의 용어는 인트라 BSS NAV로 지칭될 수 있다. Other BSS NAV의 용어는 인터(inter) BSS NAV 또는 정규(regular) NAV, 또는 비-인트라 BSS NAV로 지칭될 수도 있으며, 이에 한정되지 않는다.
NAV 관리의 실시예 1
일 실시예에 따르면 STA은 {RA(Receiver Address), TA(Transmitter Address)}의 조합 또는 {SA(Source Address), DA(Destination Address)}의 조합을 통해서 NAV를 유지/관리 할 수 있다.
예를 들어, STA이 각각의 {RA, TA} 조합을 통해서 NAV를 관리한다면, 서로 다른 {RA, TA} 조합을 가진 프레임들에 대해서는 다른 NAV를 유지해야 한다. 이러한 방법은 11ax와 같이 밀집된(dense) 환경을 고려한다면, STA이 유지해야 되는 NAV 리스트가 많아지게 된다. 따라서, STA이 각 NAV를 관리하고 업데이트 하는데 복잡도가 증가하여 11ax에서는 비효율적일 수도 있다. 표 7은 {RA, TA} 조합에 따른 NAV 리스트를 예시한다. 예컨대, 각 NAV는 {RA, TA} 조합에 의해 인덱스 된다.
[표 7]
Figure PCTKR2016005341-appb-I000007
NAV 관리의 실시예 2
본 발명의 일 실시예에 따르면 STA은 BSS별로 (예를 들어, BSSID 또는 BSS Color 별로), NAV를 유지/관리 할 수 있다.
예를 들어, BSSID별로 NAV를 유지/관리하는 STA이, 동일한 BSSID를 갖는 서로 다른 프레임들을 수신하고, 해당 프레임들 중 나중에 수신된 프레임에 의해 지시된 duration (e.g., TXOP duration 및/또는 MAC duration)이 현재 NAV (e.g., 해당 BSSID에 대한 현재 NAV)보다 길다고 가정한다. STA은 해당 BSSID에 대한 NAV를 수신된 프레임의 duration을 사용하여 업데이트 한다.
BSSID를 가지지 않는 프레임(e.g., ACK or CTS)에 대해서는 별도의 NAV가 설정될 수 있다. 예컨대, BSSID를 가지지 않는 프레임에 대해서 STA은 특정 BSSID 값(e.g., 실제 BSSID가 아니라 BSSID 포맷을 갖는 가상의 BSSID)을 사용하여 NAV를 관리할 수 있다. 이와 같은 특정 BSSID 값은 CTS 프레임, ACK 프레임 또는 (CTS&ACK) 프레임에 대응될 수 있다. 따라서, STA은 CF-END를 수신하더라도, CTS/ACK/(CTS&ACK)에 해당하는 NAV는 그대로 유지한다. 또한, STA은 CF-END를 수신하면, CF-END에 포함된 BSSID에 해당하는 NAV만 리셋할 수 있다.
표 8은 BSSID에 기반하여 설정되는 NAV 를 예시한다.
[표 8]
Figure PCTKR2016005341-appb-I000008
표 8에서, CTS&ACK에 해당하는 BSSID(e.g., Z)에 대하여 NAV(e.g., L)가 설정되는 경우, BSSID X/BSSID Y에 대한 NAV J/K는 별도로 설정되지 않을 수도 있다. 예컨대, BSSID Z로 인덱스된 NAV L을 통해서 CTS&ACK, CTS 및 ACK 프레임의 TXOP가 통합적으로 관리될 수도 있다.
편의상 ACK 프레임 및 CTS 프레임을 예시하였으나, 본 발명은 이에 한정되지 않으며 다른 제어 프레임 또는 관리 프레임에 대응하는 BSSID 및/또는 NAV가 설정될 수도 있다.
한편, STA은 ACK/CTS에 포함된 RA가 표 8의 NAV 테이블의 BSSID 리스트 중 하나와 일치하면, 해당 BSSID에 대한 NAV를 수신된 ACK/CTS프레임의 duration으로 업데이트 하고, CTS/ACK전용 NAV를 업데이트 하지 않을 수도 있다. 예컨대, RA 필드에 설정된 BSSID 값을 갖는 BSS에 대해서 NAV가 존재하면, STA은 해당 NAV에 대한 업데이트를 우선적으로 수행한다. 하지만, RA 필드에 설정된 BSSID 값을 갖는 BSS에 대해서 NAV가 존재하지 않는다면 CTS/ACK전용 NAV를 업데이트 할 수 있다.
수신된 프레임에 BSS Color 정보만 존재하고(e.g., BSSID 정보가 존재하지 않는 프레임), 해당 BSS Color에 맵핑된 BSSID가 있다면, STA은 맵핑된 BSSID를 사용하여 NAV를 추가하거나 업데이트 할 수 있다. 만약, 해당 BSS Color에 대해서 맵핑된 BSSID가 없을 경우, STA은 해당 BSS Color에 대해 하나의 BSSID를 할당하여 이를 유지할 수 있다. STA이 프레임에서 BSS Color와 BSSID를 둘 다 읽을 수 있으면, 해당 BSSID에 대응하는 NAV를 업데이트할 수 있다.
표 9는 BSS color 별로 설정된 NAV를 예시한다.
[표 9]
Figure PCTKR2016005341-appb-I000009
STA이 각 BSS Color에 대해 맵핑된 BSSID 정보를 알고 있고, BSS Color를 포함하지 않는 프레임(e.g., 11a/b/g/n/11ac(DL) 등의 레거시 프레임)에 BSSID정보 포함된 경우, 해당 프레임의 duration을 사용하여 STA은 BSSID에 맵핑된 BSS Color에 대한 NAV를 추가 또는 업데이트를 한다. STA은, ACK/CTS와 같이 BSS Color 및 BSSID가 포함되지 않는 프레임이 레거시 PPDU 포맷으로 수신되면, 해당 프레임들에 대해서는 특정의 BSS Color 값을 맵핑하여 NAV를 유지 및 관리(e.g., 추가 및 업데이트) 할 수 있다.
본 발명의 일 실시예에 따르면 NAV는 {BSSID, BSS Color}의 조합을 통해서 관리될 수도 있다. 표 10은 {BSSID, BSS Color}의 조합으로 식별되는 NAV를 예시한다.
[표 10]
Figure PCTKR2016005341-appb-I000010
NAV 관리의 실시예 3
본 발명의 일 실시예에 따르면 STA은 하나의 NAV(e.g., 하나의 NAV 타이머)를 유지하고 관리할 수 있다. STA은 NAV를 업데이트함에 있어서, NAV가 어떤 것에 의해서 업데이트되었는지에 대한 정보를 유지할 수 있다.
표 11은 본 발명의 일 실시예에 따라서 NAV의 최종 업데이트에 사용된 ID 를 예시한다.
[표 11]
Figure PCTKR2016005341-appb-I000011
NAV의 최종 업데이트에 사용된 ID(Identification used for updating the latest NAV)가 해당 NAV가 NAV에 맵핑될 수 있다. NAV의 최종 업데이트에 사용된 ID 는 예컨대, BSS Color, BSSID, {BSSID, BSS Color}, RA, TA, SA, DA, {RA, TA}, {RA, SA}, {DA, SA} 및 {DA, TA} 중 적어도 하나일 수 있으며, 이에 한정되지 않는다.
표 12는 {RA, TA}조합이 사용되는 경우를 예시한다.
[표 12]
Figure PCTKR2016005341-appb-I000012
표 13은 BSSID가 사용되는 경우를 예시한다.
[표 13]
Figure PCTKR2016005341-appb-I000013
만약, STA이 해당 ID 정보를 포함하지 않는 프레임들에 의해서 NAV를 업데이트 하는 경우, 상술된 NAV 관리 실시예 2에서 언급된 방법들 중 하나를 사용할 수 있다. 예를 들어, 표 13과 같이 BSSID가 사용되고, ACK/CTS 프레임에 BSSID (또는 BSSID와 맵핑된 정보)가 없으면, STA은 ACK/CTS 프레임에 특정 BSSID(e.g., 가상의 BSSID)를 맵핑하여 NAV 업데이트를 수행할 수 있다. 예를 들어, ACK/CTS용 BSSID가 X라고 시스템에서 정해지고, STA이 ACK이나 CTS를 수신하면 NAV 테이블의 NAV의 최종 업데이트에 사용된 ID(e.g., BSSID 항목)을 X로 업데이트 할 수 있다.
이와 같이 NAV에 대응하는 ID가 NAV와 함께 유지되고, STA이 TXOP truncation을 가리키는 프레임(e.g., CF-END)을 수신 하면, STA은 프레임의 ID정보들(e.g., RA, TA, BSS Color, BSSID 등) 중 하나가 NAV에 대응하는 ID와 일치하는 경우에만, TXOP을 truncation 할 수 있다. 예를 들어, 표 13과 같이 BSSID에 기반하여 NAV가 관리 될 때, STA은 CF-END 프레임이 현재 NAV의 BSSID에 해당하는 정보를 포함하는 경우에만 TXOP을 truncation할 수 있다. 만약, 현재 NAV의 BSSID에 해당하는 정보가 CF-END프레임에 포함되지 않은 경우, STA은 TXOP을 truncation 시키지 않을 수 있다.
본 발명의 실시예를 위해서, STA은 전송되는 프레임들을 오버히어링 함으로써, {BSS Color, BSSID}들의 리스트를 유지할 수도 있다. BSS Color만 포함하거나 또는 BSSID만 포함하는 프레임이 수신되면 STA은, {BSS Color, BSSID}리스트를 사용해서 BSS Color에 대응하는 BSSID 또는 BSSID에 대응하는 BSS Color 정보를 획득할 수도 있다.
표 14는 {BSSID, BSS Color}의 조합이 사용되는 경우를 예시한다.
[표 14]
Figure PCTKR2016005341-appb-I000014
STA은 내 BSSID에 대한 BSS Color를 다양한 방법들(e.g., 비콘, 프로브 응답 등의 관리 프레임)을 통해서 획득할 수 있다. 따라서, STA은 내 BSS에서 전송된 프레임을 수신한 경우 해당 프레임이 레거시 PPDU인지 아니면 HE(i.e., 11ax) PPDU인지에 상관 없이, BSS Color와 BSSID를 같이 업데이트 할 수 있다. 예를 들어, STA이 내 BSS Color를 포함하는 11ax PPDU를 수신 한 경우에, NAV를 업데이트할 때 BSS Color 및 내 BSSID를 같이 업데이트 할 수 있다. STA이 내 BSSID정보를 포함하는 레거시 PPDU를 수신한 경우에, NAV를 업데이트할 때 BSSID 및 BSS Color를 같이 업데이트할 수 있다.
STA이 TXOP Truncation을 지시하는 프레임(e.g., CF-END, duration =0인 프레임 등)을 수신하고, 해당 프레임에 포함된 정보들(e.g., BSS Color, BSSID, TA, RA 등) 중 하나 이상이 현재 NAV에 맵핑된 BSSID 또는 BSS Color 와 일치하면, STA은 NAV를 truncation 할 수 있다. 프레임에 포함된 정보와 현재 NAV에 맵핑된 BSSID/BSS color가 일치하지 않으면, STA은 해당 NAV를 truncation하지 않을 수 있다.
만약, STA에 {BSSID, BSS Color} 리스트가 없는 경우에, Other BSS의 프레임을 수신하거나 또는 11ax PPDU에 대해서 BSS Color만 획득하면, STA은 NAV에 맵핑되는 BSSID를 0으로 설정할 수 있다. 또한, legacy PPDU가 수신되고 STA이 BSS Color 없이 BSSID만 획득한 경우, NAV에 맵핑되는 BSS Color를 0으로 설정할 수도 있다.
STA이 제어 프레임을 수신하고, 제어 프레임이 내 BSS Color나 내BSSID 중 하나 이상과 일치하는 정보를 포함하면, STA은 NAV에 맵핑된 {BSSID, BSS Color} 정보를 NAV와 같이 업데이트할 수 있다.
만약, 제어 프레임 내에서 NAV에 맵핑된 {BSSID, BSS Color}와 일치하는 정보가 없을 경우(e.g., other BSS 제어 프레임), STA은 해당 제어 프레임에 대해서는 NAV에 {RA, TA} 조합을 맵핑할 수 있다. 이 후 TXOP Truncation 을 지시하는 프레임이 수신되고, 해당 프레임이 NAV에 맵핑된 ID정보(e.g., {BSS Color, BSSID} 또는 {RA, TA})와 일치하는 ID정보를 포함하면, STA은 TXOP을 truncation할 수 있다, 만약, 수신된 프레임이 NAV 에 맵핑된 ID 정보를 포함하지 않으면 STA은 TXOP을 truncation 시키지 않을 수 있다.
한편, STA은 NAV에 맵핑된 ID가 {BSS Color, BSSID} 조합인지, 아니면 {RA, TA} 조합인지를 나타내는 ID Type정보를 해당 NAV에 맵핑할 수도 있다. STA은 ID Type을 통해서 어떠한 ID가 NAV에 맵핑되었는지를 파악할 수 있다. 표 15는 일 실시예에 따르면 ID 타입 정보를 예시한다.
[표 15]
Figure PCTKR2016005341-appb-I000015
NAV 관리의 실시예 4
본 발명의 일 실시예에 따르면 STA들은 TXOP를 개시(initiation)하는 프레임을 수신 하면, TXOP holder 주소를 저장할 수 있다.
예를 들어, RTS프레임에서는 TA (Address 2, Transmitter address)가 TXOP holder 주소를 나타내고, CTS에서는 RA(Address 1, Receiver address)가 TXOP holder 주소룰 나타낸다.
STA은 해당 프레임들에 기초하여 NAV를 업데이트 하면서, TXOP holder 주소를 같이 저장할 수 있다. 이 후, TXOP truncation 을 지시하는 CF-END 프레임이 수신되면, STA은 CF-End의 TA와 NAV에 맵핑된 TXOP holder 주소를 비교한다. 만약, CF-END 프레임의 TA가 NAV에 맵핑된 TXOP holder 주소와 일치하면, STA은 TXOP truncation 을 수행한다. 하지만, F-END 프레임의 TA가 NAV에 맵핑된 TXOP holder 주소와 일치하지 않으면, STA은 NAV를 그대로 유지할 수 있다.
한편, 본 발명의 일 실시예에 따르면 STA은 NAV 업데이트 전의 NAV 정보를 유지할 수 있다. NAV 업데이트되기 전에 NAV 정보는, 예컨대, 업데이트 전의 NAV 값 및 업데이트 전의 TXOP holder의 정보 중 적어도 하나를 포함할 수 있다.
예컨대, STA은 현재 NAV에 대한 TXOP Holder 주소만 유지하는 것이 아니라, 이전 NAV 값 및 이전 NAV에 대한 TXOP Holder 주소를 유지할 수도 있다. STA은 이전 NAV 값을 유지하기 위하여, NAV update시에 이전 NAV 타이머를 저장하거나, 또는 이전 NAV값을 계산 할 수 있는 정보로서 NAV 차이 값(NAV difference value)를 저장 할 수 있다. 예컨대, 프레임을 수신하여 NAV를 업데이트할 때, STA은 {해당 프레임에서 지시된 Duration - 현재의 NAV 값}을 NAV 차이값으로 저장할 수 있다.
이후 CF-End 프레임이 수신되고, CF-End 프레임의 TA와 현재 NAV의 TXOP 홀더 주소와 일치하면 STA은 NAV를 리셋하는 대신에, 이전 NAV의 TXOP holder 주소와 CF-End 프레임의 TA를 비교한다. 이전 NAV 의 TXOP holder 주소와 CF-End프레임의 TA가 일치하면, STA은 NAV를 리셋한다. 하지만, 이전 NAV의 TXOP holder 주소와 CF-End프레임의 TA가 일치하지 않으면, 현재 NAV를 리셋하지 않고 이전 NAV 값을 복원한다(e.g., NAV 차이 값을 이용). CF-End 프레임의 TA가 현재 NAV의 TXOP holder 주소와 일치하지 않으면, STA은 현재 NAV를 유지한다.
일 실시예에 따르면, STA이 TXOP을 개시(initiation)하는 프레임을 수신하고 TXOP holder 주소를 저장하는 것은, 해당 STA이 어소시에이션(association)한 BSS의 TXOP holder의 주소인 것으로 한정될 수도 있다. 또는, STA은 자신이 어소시에이션한 AP의 주소만을 TXOP holder 주소로 저장하는 것으로 한정될 수 있다. 예를 들어, AP가 RTS와 같은 TXOP을 개시(initiation)하는 프레임을 전송했을 때, TXOP holder 주소는 TA (Address 2)이다. STA에 의해 전송된 CTS의 경우, AP의 RA(Address 1, AP address)가 TXOP holder 주소이다.
상술된 바와 같이, STA (e.g., AP or non-AP STA)은 프레임을 수신 했을 때, TXOP holder address(또는 STA이 어소시에이션된 TXOP holder의 address) 및/또는 BSS color (STA이 어소시에이션된 BSS의 Color)를 저장할 수 있다. 예컨대, STA이 어소시에이션된 BSS로부터 프레임을 수신한 경우, STA은 해당 BSS의 {TXOP holder address, BSS Color}를 저장할 수 있다. 만약, BSS color가 없는 프레임(e.g., RTS/CTS/Trigger frame/ACK/Block ACK 등과 같이 BSS color가 없는 legacy PPDU를 사용해서 전송되는 프레임)을 수신되고, 해당 프레임에 포함된 TXOP holder address가 자신이 어소시에이션한 AP의 MAC address 와 일치하면, STA은 자신이 사전에 알고 있는 해당 AP에 대한 BSS Color를 TXOP holder address와 같이 저장할 수 있다.
수신된 MU-RTS/RTS 프레임의 RA에 자신의 address/ID(e.g., AID or Partial AID)가 없고, TA에 자신이 associate한 BSS의 TXOP holder address가 포함되어 있으면, STA은 NAV 값과 함께 {TXOP holder address, BSS color}를 저장한다. STA은 MU-RTS/RTS에 의해 설정된 NAV를 리셋해야 되는 경우, BSS Color를 확인하여 NAV 리셋을 수행할 수 있다.
NAV 관리의 실시예 5
기존의 NAV 업데이트 방식에 따르면, OBSS(other BSS) 프레임에 의해서 NAV가 설정된 후, 내 BSS 프레임이 수신되고, 내 BSS 프레임의 NAV 값이 현재 NAV 값(e.g., OBSS 프레임에 의해 설정된 NAV)보다 크면, STA은 내 BSS 프레임에 기초하여 NAV을 업데이트 한다. 예컨대, STA이 NAV 업데이트(e.g., 변경, 리셋, 취소 등)을 요구하는 프레임(e.g., CF-End/트리거 프레임/CTS/ACK/BA 등)을 내 BSS의 STA/AP로부터 수신하면, STA은 해당 프레임을 수신하여 NAV을 업데이트 한다.
도 24는 UL MU 전송에 관련된 기존의 NAV 관리를 예시한다. STA 1, 2, 3는 AP에 어소시에이션(association)되어 있고, STA3는 OBSS 프레임을 수신하여 NAV을 설정한 상태에서 내 AP가 전송하는 TF(Trigger frame) 1을 수신하였다고 가정한다.
도 24를 참조하면, TF1에는 STA3에 대한 자원 할당 정보가 없기 때문에, TF1의 duration값이 STA 3에 설정된 현재 NAV보다 크면, STA 3는 TF1의 duration값을 통해 NAV를 업데이트 한다.
이 후, 내 AP가 TF2를 전송하여 STA3에게 UL 자원을 할당한다. STA3에는 내 BSS에 의해서 NAV가 설정되어 있으므로, STA 3는 NAV을 무시하고 UL 전송을 수행할 수 있다. 하지만 이와 같은 STA 3의 UL 전송은 OBSS에 영향을 줄 수 있다.
(1) NAV 관리 실시예 5-1: NAV 차이 값
이와 같은 문제를 해결하기 위한 방법 중 하나로서, OBSS NAV 차이 값을 사용하는 방안을 고려할 수 있다. OBSS NAV 차이 값은 간략히 NAV 차이 값으로 지칭될 수도 있다.
예컨대, STA은 하나의 NAV 타이머를 유지하되, OBSS 프레임에 의해서 설정된 NAV를 내 BSS 프레임에 기초하여 업데이트 할 때, STA은 OBSS NAV 차이 값을 계산하여 저장한할 수 있다. OBSS NAV 차이 값은 {수신된 내 BSS 프레임의 NAV 타이머 - 현재 NAV 타이머 (e.g., OBSS에 의해서 가장 최근에 업데이트 된 NAV 타이머)}와 같이 계산될 수 있다.
OBSS NAV 차이 값을 저장한 STA은 내 BSS프레임에 의해서 NAV가 업데이트 될 때(e.g., 현재 NAV가 리셋되거나, 내 AP로부터 수신된 트리거 프레임의 지시에 따라서 현재 NAV가 무시되거나 또는 고려되지 않을 때), NAV 차이 값을 이용하여 현재 시점에서 OBSS NAV가 유효한지 여부를 판단할 수 있다.
만약, OBSS NAV가 유효하다면, STA은 OBSS NAV을 고려한다(e.g., OBSS NAV가 종료되기 전까지 채널 엑세스를 보류). STA은 현재 시점에서 {현재 NAV 타이머 - NAV 차이 값}을 계산하여 OBSS NAV이 유효한지 여부를 체크 할 수 있다. 예를 들어, {현재 NAV 타이머 - NAV 차이 값}이 OBSS NAV 유효 임계치 (e.g., 0)보다 크면, STA은 OBSS NAV가 유효하다고 판단할 수 있다. 만약, {현재 NAV 타이머 - NAV 차이 값}이 0보다 작거나 같으면 STA은 OBSS NAV가 유효하지 않다고 판단할 수 있다. STA은 OBSS NAV가 유효하지 않다면, NAV 차이 값을 더 이상 유지하지 않거나 0으로 설정할 수 있다. 또한, STA은, NAV 차이 값이 없거나 0으로 설정되어 있으면, OBSS NAV를 고려하지 않고 채널 엑세스를 수행할 수 있다. STA이 NAV을 고려한다면 채널이 혼잡(busy)하다고 가정하고 프레임 전송을 시도 하지 않는다는 것을 의미할 수 있다.
STA에 저장된 NAV 차이 값은, 내 BSS 프레임에 의해서 NAV 업데이트가 없었더라면 STA에 유지되었을 OBSS NAV 타이머가 현재 시점에서 만료되었는지 아니면 잔여 시간이 있는지를 판단하기 위하여 사용될 수 있다.
도 25는 NAV 차이 값을 이용하여 NAV를 관리하는 방법을 예시한다.
도 25를 참조하면, STA3는 OBSS에 의해서 설정된 NAV을 유지하고 있다가, 내 BSS(또는 인트라 BSS) STA인 AP로부터 TF1을 수신한다. STA 3는 TF1의 NAV(e.g., duration)이 현재 NAV(e.g., OBSS NAV)보다 크면, TF1에 기반하여 자신의 NAV를 업데이트 한다. 이 때, STA3는 NAV 차이 값 (e.g., TF 1의 duration 값 - 현재 NAV 타이머)를 계산하여 저장할 수 있다.
STA3의 스케줄링 정보가 포함된 TF2가 수신되면, STA3는 TF 2에 기초한 전송을 수행하기 이전에, OBSS NAV가 유효한지 검사한다. 예컨대 {현재 NAV 타이머 - NAV 차이 값}이 OBSS NAV 유효 임계치(e.g., 0)를 초과하면, STA 3는 OBSS NAV가 유효하다고 간주할 수 있다. OBSS NAV가 유효한 동안 STA3는 TF 2에 기초한 프레임 전송을 보류할 수 있다.
한편, OBSS NAV 차이 값은 NAV가 내 BSS의 프레임(e.g., 인트라 BSS 프레임)에 의해서 업데이트 될 때, 유효하지 않을 수도 있다.
도 26는 내 BSS의 프레임에 기초한 NAV 업데이트를 예시한다.
도 26을 참조하면 STA3는 OBSS 프레임을 통해서 설정된 NAV를 TF1(e.g., STA 3가 어소시에이션된 AP로부터 수신)을 통해서 업데이트 한다. STA 3는 TF 1을 통해서 NAV를 업데이트 하는데 있어서, NAV 차이 값(e.g., 수신된 프레임의 duration에 의한 NAV 값 - 현재 NAV 값)을 계산 및 저장할 수 있다.
STA 3는 TF2를 수신하고 NAV를 업데이트 한다.
STA 3가 TF3를 통해서 UL 자원 할당을 받으면, STA3는 NAV 차이 값을 이용하여 OBSS NAV가 유효한지를 검사한다. 하지만, NAV 차이 값은 이전 NAV(e.g., TF 1)을 기반으로 계산 되었던 것이기 때문에, STA3에 저장된 NAV 차이 값은 TF 3를 수신한 시점에서는 부정확한 값이 될 수 있고, OBSS NAV 유효성 검사에 적합하지 않을 수 있다.
(2) NAV 관리 실시예 5-2: NAV 차이 값의 업데이트
상술된 문제점을 해결하기 위한 한 방법으로서, STA의 NAV가 업데이트 될 때, STA은 NAV 차이 값도 함께 업데이트 할 수 있다.
예컨대, STA은 NAV를 업데이트 할 때, NAV 차이 값을 이용하여 OBSS NAV가 유효한지 여부를 검사한다. 예를 들어, {현재 NAV 값 -NAV 차이 값}을 계산 한 결과가 OBSS NAV 유효 임계치 (e.g., 디폴트 값은 0)를 초과하면, STA은 OBSS NAV가 유효하다고 간주한다.
OBSS NAV가 유효하지 않으면, STA은 NAV 차이 값을 0으로 설정할 수 있다. 예컨대, OBSS NAV 차이 값=0 은 OBSS NAV가 유효하지 않음을 나타낼 수 있다.
OBSS NAV가 유효하면, STA은 NAV 차이 값을 업데이트할 수 있다. STA은 NAV 업데이트에 사용되는 해당 프레임의 duration 을 통해서 NAV 차이 값을 업데이트할 수 있다. 예컨대, STA은 {해당 프레임에 의한 NAV 값(e.g., duration) - (현재 NAV 값 -NAV 차이 값)} 값으로 NAV 차이 값을 업데이트 하고, 자신의 NAV 도 업데이트할 수 있다.
도 27은 NAV 차이 값의 업데이트를 예시한다. TF 1 수신 이전에 STA3는 OBSS 프레임에 의해 업데이트 된 NAV를 갖는다고 가정한다.
STA 3는 자신의 AP로부터 TF1을 수신하고 NAV를 업데이트 한다. STA 3는 TF1의 duration을 사용하여 NAV를 업데이트 하기 전에, STA3는 NAV 차이 값을 계산하여 저장한다.
STA 3는 TF2를 수신하여 NAV 업데이트를 수행하는데 있어서, OBSS NAV가 유효 한지 여부를 검사한다. OBSS NAV가 유효하다면, STA 3은 NAV 차이 값을 현재 수신된 프레임(e.g., TF2)의 duration을 기반으로 업데이트 할 수 있다. 예컨대, NAV 차이 값을 {수신된 프레임에 의한 NAV 값 - (현재 NAV 값 -저장된 NAV 차이 값)}으로 업데이트 할 수 있다. 이어서 STA 3는, TF 2를 통해서 NAV를업데이트 할 수 있다.
STA 3에 대한 UL 자원 할당을 포함하는 TF3가 수신되면, STA3는 NAV 차이 값을 사용하여 OBSS NAV가 유효한지 여부를 검사한다. 편의상 OBSS NAV가 유효하지 않다고 가정한다. 따라서, STA3는 TF 3에 응답하여 UL MU 프레임을 전송한다.
한편 NAV 차이 값의 업데이트는 OBSS NAV가 또 다른 OBSS 프레임들에서 의해 업데이트 될 때에도 수행될 수 있다. 예컨대, STA이 OBSS 프레임을 수신하였고 현재 OBSS NAV가 유효하다고 가정한다. STA은 NAV 차이 값을 사용하여, 수신된 OBSS 프레임에 의한 NAV값이 현재 OBSS NAV(=현재 NAV 값 - 저장된 NAV 차이 값)보다 큰지를 확인한다.
수신된 OBSS 프레임에 의한 NAV값이 현재 OBSS NAV 보다 크다면, STA은 NAV 차이 값을 {현재 NAV 값 - 수신된 OBSS 프레임에 의한 NAV값}으로 업데이트 한다. 이 때, STA은 자신의 NAV(e.g., 현재 NAV 값)을 그대로 유지할 수 있다. 이와 같은 NAV 차이 값 업데이트는, STA이 수신된 OBSS 프레임을 통해서 현재의 NAV는 업데이트 하지 않고, OBSS NAV를 업데이트 하기 위함이다.
도 28은 본 발명의 다른 일 실시예에 따른 NAV 차이 값 업데이트를 예시한다. STA 3는 OBSS 프레임 1에 의해 NAV를 업데이트 하였으며, 이후 자신의 AP로부터 TF1을 수신하여 NAV를 업데이트 한다고 가정한다.
STA 3는 TF1의 duration을 사용하여 NAV를 업데이트 하기 전에, NAV 차이 값을 계산 한다. 예컨대, NAV 차이 값은 {수신된 프레임에 의한 NAV (i.e., 프레임의 duration 값) -현재 NAV 타이머}일 수 있다. STA은 계산된 NAV 차이 값을 저장한다.
STA 3는 TF2를 수신하지만, NAV 업데이트는 수행되지 않으며 따라서, 현재 NAV 타이머가 유지된다고 가정한다.
이 후 STA 3는, OBSS STA로부터 OBSS 프레임 2를 수신하고, OBSS NAV가 유효한지를 검사한다. OBSS NAV가 유효하다고 가정한다. STA3는 수신된 OBSS 프레임 2에 의한 NAV(e.g., duration)이 OBSS NAV보다 큰 지를 확인한다.
OBSS 프레임 2에 의한 NAV가 OBSS NAV보다 큰 경우, STA 3는 OBSS 프레임의 duration을 사용하여 NAV 차이 값을 다시 계산한다(e.g., 업데이트). 예컨대, STA 3는 NAV 차이 값을 { 현재 NAV 타이머 -OBSS 프레임 2에 의한 OBSS NAV}로 계산하고, STA3는 계산된 NAV 차이 값을 저장할 수 있다.
이 후, STA 3는 TF3를 수신하고, TF 3를 통해 UL 자원을 할당 받는다. STA3는 UL 전송을 수행하기 이전에 NAV 차이 값을 이용하여 OBSS NAV가 유효한지를 검사한다. 편의상 OBSS NAV가 유효하다고 가정한다. 따라서, STA3는 OBSS NAV가 만료되기 전에는 UL MU 프레임을 전송하지 않는다.
NAV 관리의 실시예 6
이하에서는 앞서 도 24를 통해서 살펴본 기존의 NAV 관리 방법의 문제점을 해결하기 위한 또 다른 실시예들을 살펴본다.
(1) NAV 관리의 실시예 6-1: 다수의 NAV 타이머
본 발명의 일 실시예에 따르면 STA은 내 BSS(e.g., 인트라 BSS) NAV 타이머와 OBSS(e.g., 인터 BSS) NAV 타이머를 각각 유지/관리할 수 있다. 내 BSS 프레임에 의해서 NAV 업데이트가 필요하면, STA은 내 BSS NAV 타이머를 업데이트 할 수 있다. OBSS 프레임에 의해서 NAV 업데이트가 필요하면, STA은 OBSS NAV 타이머를 업데이트할 수 있다.
도 29는 본 발명의 일 실시예에 따른 NAV 설정을 예시한다.
도 29를 참조하면, STA 3는 OBSS 프레임을 수신하면, OBSS NAV 타이머를 업데이트(e.g., 여기서 업데이트는 설정, 변경, 최소/리셋 중 하나를 의미할 수 있다)하고, 내 BSS NAV 타이머는 업데이트하지 않는다.
STA3는 내 BSS 프레임을 수신하면, 내 BSS NAV 타이머를 설정 또는 업데이트 하고, OBSS NAV 타이머를 업데이트 하지 않는다.
STA은 내 BSS NAV와 OBSS NAV 둘 중에 하나라도 0 이상의 값을 갖는다면, STA은 채널 엑세스를 수행하지 않는다.
STA은 내 BSS NAV 타이머 대신에 기존과 같은 NAV 타이머를 유지할 수도 있다. 예컨대, STA은 기존과 같은 방식으로 동작하는 NAV 타이머와 OBSS NAV 타이머를 유지할 수 있다. 예컨대, 기존 NAV 타이머는 인트라 BSS / 인터 BSS 프레임의 구분 없이 업데이트 되고(e.g., 기존과 같이), OBSS NAV 타이머는 OBSS (인터 BSS) 프레임에 의해서만 업데이트 될 수 있다.
따라서, 기존의 NAV 타이머가 인트라 BSS STA이 전송하는 프레임에 의해서 업데이트가 되었더라도, OBSS NAV 타이머가 유효하면 STA은 OBSS NAV을 고려하여 UL MU 프레임을 전송하지 않을 수 있다. 또한, STA은 OBSS NAV 타이머가 OBSS NAV 유효 임계값(e.g., 디폴트 값은 0)보다 큰 값일 경우, OBSS NAV가 유효하다고 판단할 수 있다.
한편, OBSS NAV 유효 임계값은 시스템에 의해 결정될 수 있으며, 비콘과 같은 브로드캐스트/멀티캐스트 프레임 또는 유니캐스트 프레임을 통해서 STA에 전달 될 수 있다.
(2) NAV 관리의 실시예 6-2: 하나의 NAV 타이머
본 발명의 일 실시예에 따르면 STA은 기존처럼 하나의 NAV 타이머를 유지하되, OBSS 프레임에 의해서 설정된 NAV이 내 BSS 프레임에 의해서 업데이트 될 때, STA은 OBSS NAV 차이 값을 계산하여 저장할 수 있다. OBSS NAV 차이 값은 {수신된 프레임의 NAV 타이머 -현재 NAV 타이머}로 계산될 수 있다. 예컨대, 수신된 프레임의 NAV 타이머는 수신된 프레임의 duration을 통해 계산될 수 있고, 현재 NAV 타이머는 OBSS에 의해서 가장 최신에 업데이트 된 NAV 타이머일 수 있다. OBSS NAV 차이 값은 간략히 NAV 차이 값으로 지칭될 수 있다.
STA은 현재 NAV을 리셋(e.g., CF-End수신)하거나, 또는 현재 NAV을 고려하지 않고 프레임 전송을 시도(e.g., 트리거 프레임에 기반하여 UL 프레임을 전송하는 경우)할 때, 저장된 NAV 차이 값을 사용하여 OBSS NAV이 유효한지 검사할 수 있다.
예컨대, STA은 해당 시점에 {현재 NAV 타이머 - OBSS NAV 차이 값}의 값을 계산하여 OBSS NAV이 유효한지를 체크 할 수 있다. 예를 들어, {현재 NAV 타이머 - NAV 차이 값}의 값이 OBSS NAV 유효 임계치(e.g., 디폴트는 0, 하지만 0 보다 큰 값으로 설정될 수 있다.)보다 크면, STA은 OBSS NAV이 유효하다고 판단 한다. 만약, {현재 NAV 타이머 - NAV 차이 값}이 0보다 작거나 같으면 STA은 OBSS NAV 차이 값을 유지하지 않거나 0으로 설정할 수 있다. NAV 차이 값이 없거나 0으로 설정되어 있으면, OBSS NAV을 유효하지 않다는 것을 나타낼 수 있으며, STA은 OBSS NAV을 고려하지 않을 수 있다.
OBSS NAV이 유효하면, STA은 OBSS NAV을 고려하여 동작할 수 있다. 예컨대, STA은 OBSS NAV이 유효하면 NAV 리셋시점에서 NAV을 리셋하지 않거나, 프레임 전송시점에는 프레임을 전송하지 않을 수 있다.
STA이 NAV을 고려한다는 말은 채널이 혼잡(busy)하다고 가정하고 프레임 전송을 시도 하지 않는다는 것을 가리키거나, 또는 OBSS NAV을 리셋하지 않는 것을 의미할 수 있다.
도 30은 본 발명의 일 실시예에 따른 NAV 관리 방법을 예시한다.
STA3은 OBSS에 의해서 설정된 NAV을 유지하고 있다고 가정한다.
STA 3는 내 BSS의 AP로부터 TF1을 수신한다. TF 1의 NAV이 현재 NAV보다 크다고 가정한다. STA 3는 TF1에 기초하여 NAV를 업데이트 한다. 이 때, STA3는 NAV 차이 값 {TF 1의 NAV 타이머 - 현재 NAV 타이머}을 계산 및 저장한다.
이 후, STA 3는 TF 2를 수신한다. TF 3는 STA3의 스케줄링 정보를 포함한다. STA 3는 TF 2에 기초한 UL 전송을 시도하기 전에, OBSS NAV이 유효한지를 추가로 검사한다. 한편, STA 3의 현재 NAV이 인트라 BSS STA에 의해서 설정되어 있기 때문에, STA 3는 현재의 NAV는 고려하지 않을 수 있다.
만약, {현재 NAV 타이머 - NAV 차이 값}이 OBSS NAV 유효 임계치를 초과하면, STA3는 OBSS NAV이 유효하다고 간주할 수 있다. STA 3는 OBSS NAV가 유효한 동안 UL 프레임을 전송하지 않는다.
한편, 도 28에서 설명된 바와 같이, STA은 MyBSS (또는 인트라 BSS) 에 의해서 설정된 NAV이 OBSS (또는 인트라 BSS)에 의해서 업데이트 될 때에도 NAV 차이 값을 계산 및 저장하는 동작을 수행 할 수 있다. 예를 들어, 이후, 인터 BSS 프레임에 의해서 NAV가 업데이트 (e.g., 리셋/취소) 될 때에, STA은 MyBSS NAV이 유효한지를 체크한다. MyBSS NAV이 유효할 경우, STA은 MyBSS NAV을 고려하여 동작할 수 있다. NAV 차이 값을 계산하고, 유효 여부를 검사하는 방법은 상술된 내용과 중복되므로 설명이 생략된다.
(3) NAV 관리의 실시예 6-3: CF-END 프레임
이하에서는 TXOP truncation을 위한 CF-End를 수신한 경우 NAV 업데이트 방법을 살펴본다.
현재 NAV 이 인트라 BSS 프레임에 의해서 업데이트 된 것이고, OBSS NAV이 유효하다면, STA이 인트라 BSS STA으로부터 CF-End프레임의 수신에 따라서 현재의 NAV을 OBSS NAV으로 업데이트 할 수 있다.
상술된 NAV 관리의 실시예 6-1에서와 같이, STA이 OBSS NAV 타이머를 추가로 유지하고 있으면, STA은 OBSS NAV 타이머값을 확인함으로써 OBSS NAV이 유효한지 를 알 수 있다. OBSS NAV가 유효하다면 STA은 현재의 NAV을 OBSS NAV 타이머값으로 설정한다.
상술된 NAV 관리의 실시예 6-2에서와 같이, STA이 OBSS NAV 차이 값을 계산하여 저장하고 있다면, STA은 OBSS NAV 차이 값을 사용하여 OBSS NAV이 유효한지 를 알 수 있다. OBSS NAV가 유효하다면 STA은, OBSS NAV 차이 값을 사용하여 현재의 NAV을 OBSS NAV으로 설정할 수 있다. NAV 관리의 실시예 6-2에서 설명된 바와 같이, 현재의 NAV가 OBSS 프레임에 의해서 업데이트 될 때, STA은 OBSS NAV 차이 값 {수신된 프레임의 NAV 타이머 - 현재의 NAV 타이머}을 계산할 수 있다. STA은, OBSS NAV 유효성 검사 시점에, {현재의 NAV 타이머 - OBSS NAV 차이 값}이 OBSS NAV 유효 임계치를 초과하면, OBSS NAV이 유효하다고 판단하고 현재의 NAV을 OBSS NAV(= 현재의 NAV 타이머 - OBSS NAV 차이 값)으로 업데이트 할 수 있다.
(4) NAV 관리의 실시예 6-4: NAV 업데이트 지시자
본 발명의 일 실시예에 따르면, 현재의 NAV이 과거의 NAV 값에서 업데이트 된 것인지, 아니면 새롭게 설정된 것인지 여부에 따라서, STA이 NAV을 고려하거나 또는 NAV을 리셋할 수 있다.
예컨대, 현재 NAV 바로 이전 NAV가 zero였는지 non-zero였는지에 따라서 NAV의 리셋 여부가 결정될 수 있다. STA은 NAV을 설정 또는 업데이트할 때, 이전의 NAV에 대한 정보(e.g., NAV 업데이트 지시자)를 저장할 수 있다. 예컨대, NAV가 non-zero 값으로부터 업데이트 되면, NAV 업데이트 지시자=1로 설정되고, NAV가 zero 값에서 초기 설정되었다면, NAV 업데이트 지시자=0으로 설정될 수 있다.
STA이 자신의 AP로부터 트리거 프레임을 수신하여 UL MU 프레임을 전송하는데 있어서, 현재 NAV이 인트라 BSS STA이 전송한 프레임에 의한 것이면, STA은 NAV 업데이트 지시자를 확인한다. NAV 업데이트 지시자=0이면, STA은 현재 NAV이 새롭게 설정(e.g., NAV=0으로부터 초기 설정)되었다고 판단하고, 설정된 NAV을 고려하지 않는다(e.g., UL 프레임 전송). 만약, NAV 업데이트 지시자= 1이면, STA은 현재 NAV이 non-zero값으로부터 업데이트 된 것이라고 판단하고, 설정된 NAV을 고려할 수 있다(e.g., NAV 만료 전에는 UL 프레임 전송하지 않음).
STA이 인트라 BSS STA(e.g., AP)로부터 CF-End를 수신하였을 때, 현재 NAV이 인트라 BSS 프레임에 의한 것이면, STA는 NAV 업데이트 지시자를 확인한다. NAV 업데이트 지시자=0이면, STA은 현재 NAV이 초기 설정된 것이라고 판단하고, NAV을 리셋할 수 있다. NAV 업데이트 지시자= 1이면, STA은 현재 NAV이 non-zero값으로부터 업데이트 된 것이라고 판단하여, NAV을 리셋하지 않을 수 있다.
RTS 또는 MU-RTS프레임을 수신한 STA(e.g., third party)이 지정된 시간 안에 프레임(e.g., CTS)을 수신하지 못했을 때, NAV 업데이트 지시자를 확인할 수 있다. NAV 업데이트 지시자= 0이면, STA은 현재 NAV이 초기 설정된 것이라고 판단하고, NAV을 리셋할 수 있다. NAV 업데이트 지시자=1이면, STA은 현재 NAV이 non-zero값으로부터 업데이트 된 것이라고 판단하여, 설정된 NAV을 리셋하지 않을 수 있다.
(5) NAV 관리의 실시예 6-5: 내 BSS NAV 차이 값
상술된 방법들은 인트라 BSS (또는 내BSS) NAV에서 인터 BSS (또는 OBSS) NAV으로 업데이트 될 때에도 사용 될 수 있다. 이 경우, STA이 계산 하고 저장하는 값은 NAV 업데이트 지시자 대신에 인트라 BSS NAV 차이 값 또는 내 BSS NAV 차이 값으로 명칭될 수 있으며, 이에 한정되지 않는다. 편의상 내 BSS NAV 차이 값이라 지칭하기로 한다.
인트라 BSS NAV (i.e., 인트라 BSS 프레임을 수신하여 설정/업데이트 된 NAV을 가리킴)을 유지하던 STA이 인터 BSS 프레임을 수신하여 NAV을 업데이트 하는 경우, STA은 내 BSS NAV 차이 값을 계산한다. 내 BSS NAV 차이 값은 상술한 OBSS NAV 차이 값과 유사한 방식으로 계산될 수 있다. 예컨대, 내 BSS NAV 차이 값은 {현재 수신된 OBSS 프레임에 의해 계산된 NAV 값 - 현재의 NAV 값(e.g., 내 BSS NAV value)} 으로 계산될 수 있다. NAV 업데이트에 의해, 내 NAV은 OBSS NAV으로 변경된다. STA은 저장된 내 BSS NAV 차이 값을 사용하여 MyBSS NAV이 유효한지를 검사할 수 있다. 예컨대, OBSS NAV이 OBSS STA에 의해서 전송된 프레임(e.g., CF-End)에 의해서 NAV이 리셋되어야 하는 경우에, STA은 내 BSS NAV가 유효한지를 검사할 수 있다. 내 BSS NAV이 유효하다면, STA은 현재 NAV(e.g., OBSS NAV)를 내 BSS NAV으로 업데이트한다.
한편, STA은 내 BSS NAV 차이 값이 특정 임계치 (e.g., 디폴트 값은 0) 이상이면, 내 BSS NAV이 유효한지 검사할 필요가 있다고 판단 할 수 있다.
내 BSS NAV가 유효한지를 검사하는데 있어서 STA은 {현재 NAV 값 - 내 BSS NAV 차이 값}이 특정 임계값 (e.g., 디폴트 값은 0) 이상일 경우, 내 BSS NAV이 유효하다고 간주할 수 있다.
이 때, 내 BSS NAV은 {현재 NAV 값 - 내BSS NAV 차이 값}일 수 있다.
NAV 관리의 실시예들의 요약
상술된 바와 같이, STA이 OBSS STA으로부터 CF-END 프레임을 수신하면, STA은 현재의 NAV 가 (e.g., 가장 최근의 NAV 업데이트/설정)가 인트라 BSS 프레임에 의한 것인지 여부를 고려하여야 한다. 만약, 가장 최근의 NAV 업데이트가 인트라 BSS 프레임에 의한 것이면, STA은 OBSS로부터의 CF-END 프레임에 기초하여 NAV를 리셋하지 않는다(e.g., 인트라 BSS NAV의 보호).
또한, 인트라 BSS NAV 뿐 아니라, 인터 BSS NAV 도 보호될 필요가 있다. 예를 들어, 인트라 BSS STA으로부터 CF-END 프레임이 수신되면, STA은 현재의 NAV(e.g., 가장 최근의 NAV 업데이트/설정)가 인터 BSS 프레임에 의한 것인지 여부를 고려하여야 한다. 만약, 가장 최근의 NAV 업데이트가 인터 BSS 프레임에 의한 것이면, STA은 내 BSS로부터의 CF-END 프레임에 기초하여 NAV를 리셋하지 않을 수 있다(e.g., 인터 BSS NAV의 보호).
아울러, OBSS에 의해 설정된 NAV가 인트라 BSS 프레임에 의해서 업데이트되는 경우에 있어서, 인트라 BSS 프레임에 의한 TXOP truncation이 고려될 필요가 있다. 이하에서는 상술된 논의들을 바탕으로 인트라 BSS 프레임에 의한 TXOP truncation 방법 및/또는 UL MU 프레임 응답(e.g., 트리거 프레임에 기초한 전송)에 사용 가능한 방법들을 더 살펴본다.
도 31은 인트라 BSS 프레임에 의한 TXOP truncation을 예시한다. STA의 NAV는 OBSS에 의해서 설정된 것이라고 가정한다. STA은 자신의 AP로부터 프레임(e.g., TF 또는 CTS 등)을 수신하면, NAV를 업데이트 한다. 이후, AP가 CF-END 프레임을 전송하면 STA은 NAV를 리셋한다. NAV 리셋 이후 STA이 UL 프레임을 전송하는 경우, OBSS의 NAV가 보호될 수 없는 문제점이 있다.
도 32는 도 31의 문제점을 해결하기 위한 본 발명의 일 실시예에 따른 NAV 관리 방안을 예시한다. 도 31과 중복되는 설명은 생략한다.
도 32를 참조하면, STA이 자신의 AP로부터 CF-END 프레임을 수신하면, STA은 NAV를 리셋하기 이전에, OBSS NAV가 유효한지 여부를 먼저 판단하여야 한다. OBSS NAV가 유효하다면 STA은 NAV를 리셋하지 않을 수 있다. 예컨대, OBSS NAV가 유효하다면 STA은 현재의 NAV를 OBSS NAV로 업데이트(e.g., 복원)할 수 있다.
도 33은 NAV 차이 값을 설명하기 위한 예시이다.
OBSS NAV가 인트라 BSS 프레임에 의해서 업데이트 되는 경우, STA은 NAV 차이 값을 계산 및 저장할 수 있다. NAV 차이 값은 {수신된 프레임(e.g., 인트라 BSS 프레임)에 의한 NAV 값 - 현재 NAV 값}일 수 있다.
이후에, STA은 CF-END 프레임을 자신의 AP로부터 수신한다. STA은 NAV를 리셋하기 이전에 OBSS NAV가 유효한지 여부를 체크한다. OBSS NAV의 유효성은 NAV 차이 값에 기초하여 계산될 수 있다. 예컨대, {현재(e.g., OBSS NAV 유효성 체크 시점) NAV 값 X - NAV 차이 값 Y }가 0보다 큰 경우, STA은 OBSS NAV가 유효하다고 판단할 수 있다. 예컨대, 인트라 BSS 프레임에 의한 NAV 업데이트가 없었다는 가정하에 잔여 OBSS NAV가 존재한다면 STA은 OBSS NAV가 여전히 유효한 것이라고 판단할 수 있다.
OBSS NAV가 유효하다면, STA은 유효한 OBSS NAV 값으로 현재의 NAV를 업데이트 할 수 있다(e.g., CF-END 프레임 수신 등을 원인으로 내 BSS NAV가 더 이상 보호될 필요가 없는 경우). OBSS NAV 값을 통한 NAV 업데이트는, 인트라 BSS 프레임에 의해서 NAV가 업데이트되지 않았더라면 계속되었을 OBSS NAV 값을 복원하는 것으로 이해될 수 있다.
OBSS NAV가 유효하지 않다면, STA은 NAV를 리셋 할 수 있다(e.g., OBSS NAV 및 내 BSS NAV 모두 보호될 필요가 없는 경우).
도 34는 본 발명의 일 실시예에 따른 NAV 업데이트를 설명하기 위한 예시이다. STA 5에는 OBSS NAV가 설정되었다고 가정한다.
STA 5는 TF1(e.g., 인트라 BSS 프레임)을 통해 NAV(e.g., OBSS NAV)를 업데이트 할 때, NAV 차이 값을 계산 및 저장한다.
STA 5는 TF 2를 수신한다. TF 2에 의한 NAV 업데이트는 없으며, TF 2는 STA 5에 대한 자원 할당 정보를 포함한다고 가정한다.
STA 5는 TF 2에 기초하여 UL 프레임을 전송하기 이전에, NAV 차이 값을 이용하여 OBSS NAV가 유효한지 여부를 체크한다. 예컨대, {현재(e.g., OBSS NAV 체크 시점) NAV 값 - NAV 차이 값}이 0보다 크다면, STA 5는 OBSS NAV가 유효하다고 가정할 수 있다.
OBSS NAV가 유효한 동안 STA 5는 TF 2에 기초한 UL 프레임 전송을 수행하지 않는다(e.g., OBSSS NAV 고려).
(i) 하나의 NAV 타이머를 이용한 다수의 NAV들 관리
한편, STA은 하나의 NAV 타이머를 통해서 다수의 NAV들(e.g., 2개의 NAV) 관리할 수 있다. 다수의 NAV 들은 인트라 BSS NAV 및 비-인트라 BSS NAV를 포함할 수 있다. 인트라 BSS NAV는 인트라 BSS 프레임에 의해 업데이트 되는 NAV일 수 있다. 비-인트라 BSS NAV는 인트라 BSS 프레임이 아닌 프레임 또는 인트라 BSS 프레임으로 결정할 수 없는 프레임(e.g., 인터 BSS 프레임, 또는 CTS/ACK 등과 같이 인터 BSS 프레임인지 아니면 인트라 BSS 프레임인지를 구별할 수 없는 프레임)에 의해 업데이트 되는 NAV 일수 있다. 비-인트라 BSS NAV는 레귤러 NAV로 지칭될 수도 있다.
현재의 NAV(e.g., 하나의 NAV 타이머)가 인트라 BSS NAV에 의해 설정된 것이고, 인트라 BSS 프레임이 아닌 프레임에 의해서 업데이트되는 경우(또는 그 반대의 경우), STA은 NAV 차이 값을 계산하여 저장할 수 있다. NAV 차이 값은 {수신된 프레임에 의한 NAV 값 - 인트라 BSS NAV} 이거나 또는 {수신된 프레임에 의한 NAV 값 -인터 BSS NAV}일 수 있다.
이후 STA은 자신의 NAV(e.g., 하나의 NAV 타이머)를 인터 BSS 프레임의 duration을 통해 업데이트 할 수 있다. 따라서, STA의 현재의 NAV는 인터 BSS NAV로 볼 수 있다.
NAV 차이 값이 0인 경우, 두 개의 NAV들이 모두 유효하지 않거나 또는 현재 NAV만 유효한 경우 일 수 있다.
만약 NAV 의 체크가 필요한 경우(e.g., UL MU 프레임을 전송하기 전에 또는 NAV 리셋하기 전에), STA은 2개의 NAV들이 유효한지 여부를 체크할 수 있다. 예컨대, 2 개 NAV들의 값들이 모두 0이 아니라면, 2 개의 NAV들이 모두 유효하다고 판단된다. NAV 값이 0인 NAV는 유효하지 않다고 판단된다. 2개의 NAV들의 유효성을 판단하기 위하여 NAV 차이 값이 이용될 수 있다. 예를 들어, {현재 NAV 값(e.g., 하나의 NAV 타이머)- NAV 차이 값}이 0보다 큰 경우에는 2 개의 NAV들이 유효하다고 판단된다(e.g., 현재 NAV 값도 0이 아니므로). 그러나 {현재의 NAV 값- NAV 차이 값}이 0 보다 크지 않다면, 오직 1개의 NAV(e.g., 인트라 BSS NAV 또는 인터 BSS NAV)만 유효한 것으로 판단된다.
만약, 2개의 NAV들이 모두 유효하다면, STA은 2개의 NAV들을 모두 고려하여 동작한다. 현재의 NAV (e.g., 인트라 BSS NAV 또는 인터 BSS NAV) 만 유효하다면 STA은 해당 NAV 만 고려하여 동작할 수 있다.
현재의 NAV(e.g., 하나의 NAV 타이머)가 인트라 BSS NAV이고, STA이 인트라 BSS STA으로부터 CF-END 프레임을 수신한 경우를 가정한다. 만약, 2 NAV들이 모두 유효하다면 STA은 현재의 NAV(e.g., 하나의 NAV 타이머)를 비-인트라 NAV(e.g., 현재의 NAV 값- NAV 차이 값)로 업데이트 한다. 2 NAV 들이 모두 유효하지 않은 경우에는, STA은 CF-END 프레임에 기초하여 현재의 NAV(e.g., 하나의 NAV 타이머)를 리셋한다.
현재의 NAV(e.g., 하나의 NAV 타이머)가 인트라 BSS NAV이고, STA이 인터 BSS STA으로부터 CF-END 프레임을 수신한 경우를 가정한다. 만약, 2 NAV들이 모두 유효하다면 STA은 인트라 BSS에 해당하는 현재의 NAV(e.g., 하나의 NAV 타이머)를 리셋하지 않는다. 그러나, STA은 비-인트라 NAV는 리셋할 수 있다. 비-인트라 NAV의 리셋은 NAV 차이 값을 0으로 설정하는 것을 의미할 수 있다.
현재의 NAV(e.g., 하나의 NAV 타이머)가 비-인트라 BSS NAV이고, STA이 인터 BSS STA으로부터 CF-END 프레임을 수신한 경우를 가정한다. 만약, 2 NAV들이 모두 유효하다면 STA은 비-인트라 BSS에 대응하는 현재의 NAV(e.g., 하나의 NAV 타이머)를 인트라 NAV(e.g., 현재의 NAV 값- NAV 차이 값)로 업데이트 한다. 2 NAV 들이 모두 유효하지 않은 경우에는, STA은 CF-END 프레임에 기초하여 현재의 NAV(e.g., 하나의 NAV 타이머)를 리셋한다.
현재의 NAV(e.g., 하나의 NAV 타이머)가 비-인트라 BSS NAV이고, STA이 인트라 BSS STA으로부터 CF-END 프레임을 수신한 경우를 가정한다. 만약, 2 NAV들이 모두 유효하다면 STA은 비-인트라 BSS에 해당하는 현재의 NAV(e.g., 하나의 NAV 타이머)를 리셋하지 않는다. 그러나, STA은 인트라 NAV는 리셋할 수 있다. 인트라 NAV의 리셋은 NAV 차이 값을 0으로 설정하는 것을 의미할 수 있다.
(ii) 다수의 NAV 타이머를 이용한 다수의 NAV들 관리
이와 같이, STA은 UL MU 프레임 등을 전송하는데 있어서 NAV를 고려할 수 있으며, 특히 STA은 다수 NAV들(e.g., 인트라 BSS NAV / 비-인트라 BSS NAV)을 관리할 수 있다. 다수의 NAV들을 관리하기 위하여, STA은 하나의 NAV 타이머를 설정하는 방법(e.g., NAV 차이 값 이용)외에 다수의 NAV 타이머들을 설정할 수도 있다. 예컨대, 인트라 BSS NAV 및 비-인트라 BSS NAV 각각에 대하여 별도의 NAV 타이머가 설정될 수 있다.
예컨대, 인트라 BSS NAV 타이머는 인트라 BSS 프레임/PPDU에 의해서 업데이트되는 NAV 타이머일 수 있다. 비-인트라 BSS NAV 타이머는, 인트라 BSS 프레임이 아니거나, 인트라 BSS인지 인터 BSS인지를 구별할 수 없는 프레임에 의해서 업데이트되는 NAV 타이머 일 수 있다.
STA은 트리거 프레임에 대응하여 UL MU 프레임을 전송하기 이전에 비-인트라 BSS NAV 타이머를 고려하여야 한다.
또한, STA은 인트라 BSS로부터 CF-END 프레임이 수신되면 인트라 BSS NAV를 리셋하고, 인터 BSS로부터 CF-END 프레임이 수신되면 비-인트라 BSS NAV를 리셋할 수 있다.
도 35는 본 발명의 일 실시예에 따른 2개의 NAV 타이머들을 예시한다.
도 35를 참조하면, STA은 OBSS STA으로부터 TF 또는 CTS 등의 프레임을 수신하여 비-인트라 BSS NAV 타이머를 설정한다.
STA은 자신의 AP로부터 TF 또는 CTS 프레임을 수신하고, 인트라 BSS NAV 타이머를 시작한다. STA은 자신의 AP로부터 CE-END 프레임을 수신하면 인트라 BSS NAV 타이머를 리셋한다.
하나의 NAV 타이머를 통해서 2개의 NAV들을 관리하는 실시예에서 STA은 현재 NAV 타이머가 값이 어느 하나의 NAV에서 다른 하나의 NAV로 변경될 때마다 NAV 차이값을 계산하여 저장할 수 있다.
2개의 NAV 타이머들을 통해서 2개의 NAV들을 관리하는 실시예에서 STA은 UL MU 프레임 전송이전에 비-인트라 BSS NAV를 고려하여야 하며, CF-END 프레임이 수신되면 해당 NAV 타이머를 리셋한다.
도 36은 본 발명의 일 실시예에 따른 NAV 관리 방법을 예시한다. 상술된 설명과 중복되는 설명은 생략된다.
도 36을 참조하면 STA은 구간(duration) 정보를 포함하는 프레임을 수신한다(S3605). 구간 정보는 HE-SIG A 필드에 포함된 TXOP duration 필드가 지시하는 TXOP duration 값이거나 또는 MAC 헤더에 포함된 duration 필드가 지시하는 MAC duration 값일 수 있으며, 이에 한정되지 않는다.
예컨대, 프레임은, RTS, CTS 등의 제어 프레임, 관리 프레임, 트리거 프레임 또는 HE-PPDU 기반의 프레임 또는 Non-HE PPDU 기반의 프레임일 수 있으며, 이에 한정되지 않는다.
STA은 다수의 NAV 들 중 소정의 NAV를 선택한다(S3610).
예컨대, STA은 다수의 NAV들을 갖을 수 있다. 다수의 NAV들은, 인트라 BSS NAV 및 비-인트라 BSS NAV를 포함할 수 있다. 비-인트라 BSS NAV는, OBSS(other BSS) 프레임을 위한 것일 수 있다. 추가적으로, 비-인트라 BSS NAV는 BSS를 특정 할 수 없는 프레임을 위한 것일 수도 있다. BSS를 특정할 수 없는 프레임은 예컨대, RA 필드 또는 TA 필드 등에서 BSSID 정보를 갖지 않는 프레임 일 수 있다 (e.g., ACK, CTS 등).
소정의 NAV는, 해당 프레임이 STA이 속하는 BSS(basic service set)로부터 수신된 것인지 여부에 기초하여 선택될 수 있다. 예컨대, STA은 프레임이 내 BSS로부터 수신되었는지 여부를 판단할 수 있다.
STA은 프레임이 STA이 속한 BSS로부터 수신된 것으로 결정되면 제1 NAV(e.g., 인트라 BSS NAV)를 선택하고, 프레임이 STA이 속하지 않는 BSS로부터 수신된 것으로 결정되면 제2 NAV를 선택(e.g., 비-인트라 BSS NAV)할 수 있다. 추가적으로, STA은 프레임이 어느 BSS로부터 수신된 것인지를 결정할 수 없는 경우에도 제2 NAV를 선택(e.g., 비-인트라 BSS NAV)할 수 있다.
STA은 프레임의 구간 정보에 기초하여 소정의 NAV를 관리할 수 있다(S3615). NAV 관리는, NAV 초기 설정, NAV 업데이트 또는 NAV 리셋 중 어느 하나일 수 있으며, 이에 한정되지 않는다.
다수의 NAV들 중 어느 하나라도 0 보다 큰 값을 갖는 경우, STA은 채널 엑세스를 보류할 수 있다.
일 실시예에 따르면, STA은 다수의 NAV들에 대응되는 다수의 NAV 타이머들을 설정할 수 있다.
다른 일 실시예에 따르면, STA은 하나의 NAV 타이머만 설정할 수도 있다. 예컨대, 다수의 NAV들은, 다수의 NAV들 간의 차이 값과 하나의 NAV 타이머를 통해서 관리될 수 있다. 하나의 NAV 타이머의 값이 제1 NAV로부터 제2 NAV로 변경되거나 또는 제2 NAV로부터 제1 NAV로 변경되는 경우, 다수의 NAV들 간의 차이 값이 업데이트될 수 있다. 또한, STA은 하나의 NAV 타이머에 맵핑된 어느 하나 NAV의 현재 값과 다수의 NAV들 간의 차이 값을 이용하여 다른하나의 NAV의 유효성을 판단할 수도 있다.
도 37은 상술한 바와 같은 방법을 구현하기 위한 장치를 설명하기 위한 도면이다.
도 37의 무선 장치(800)은 상술한 설명의 특정 STA, 그리고 무선 장치(850)은 상술한 설명의 AP에 대응할 수 있다.
STA (800)은 프로세서(810), 메모리(820), 송수신기(830)를 포함할 수 있고, AP (850)는 프로세서(860), 메모리(870) 및 송수신기(880)를 포함할 수 있다. 송수신기(830 및 880)은 무선 신호를 송신/수신하고, IEEE 802.11/3GPP 등의 물리적 계층에서 실행될 수 있다. 프로세서(810 및 860)은 물리 계층 및/또는 MAC 계층에서 실행되고, 송수신기(830 및 880)와 연결되어 있다. 프로세서(810 및 860)는 상기 언급된 UL MU 스케줄링 절차를 수행할 수 있다.
프로세서(810 및 860) 및/또는 송수신기(830 및 880)는 특정 집적 회로(application-specific integrated circuit, ASIC), 다른 칩셋, 논리 회로 및/또는 데이터 프로세서를 포함할 수 있다. 메모리(820 및 870)은 ROM(read-only memory), RAM(random access memory), 플래시 메모리, 메모리 카드, 저장 매체 및/또는 다른 저장 유닛을 포함할 수 있다. 일 실시 예가 소프트웨어에 의해 실행될 때, 상기 기술한 방법은 상기 기술된 기능을 수행하는 모듈(예를 들어, 프로세스, 기능)로서 실행될 수 있다. 상기 모듈은 메모리(820, 870)에 저장될 수 있고, 프로세서(810, 860)에 의해 실행될 수 있다. 상기 메모리(820, 870)는 상기 프로세스(810, 860)의 내부 또는 외부에 배치될 수 있고, 잘 알려진 수단으로 상기 프로세스(810, 860)와 연결될 수 있다.
상술한 바와 같이 개시된 본 발명의 바람직한 실시형태에 대한 상세한 설명은 당업자가 본 발명을 구현하고 실시할 수 있도록 제공되었다. 상기에서는 본 발명의 바람직한 실시 형태를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 상술한 설명으로부터 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다. 따라서, 본 발명은 여기에 나타난 실시형태들에 제한되려는 것이 아니라, 여기서 개시된 원리들 및 신규한 특징들과 일치하는 최광의 범위를 부여하려는 것이다.
상술한 바와 같은 본 발명은 HE PPDU를 지원하는 무선랜 시스템에 적용되는 것을 가정하여 설명하였으나, 이에 한정될 필요는 없다. 본 발명은 IEEE 802.11을 비롯한 다양한 무선 통신 시스템에 적용될 수 있다.

Claims (19)

  1. HE PPDU(high efficiency physical layer protocol data unit)를 지원하는 무선랜 시스템에서 스테이션(STA)이 NAV(network allocation vector)를 관리하는 방법에 있어서,
    구간(duration) 정보를 포함하는 프레임을 수신하는 단계;
    상기 STA이 갖는 다수의 NAV들 중에서 소정의 NAV를 선택하는 단계; 및
    상기 프레임의 구간 정보에 기초하여 상기 소정의 NAV를 관리하는 단계를 포함하고,
    상기 소정의 NAV는, 상기 프레임이 상기 STA이 속하는 BSS(basic service set)로부터 수신된 것인지 여부에 기초하여 선택되는, NAV 관리 방법.
  2. 제 1 항에 있어서, 상기 소정의 NAV를 선택하는 단계는,
    상기 프레임이 상기 STA이 속한 BSS로부터 수신된 것으로 결정되면 제1 NAV를 선택하고,
    상기 프레임이 상기 STA이 속하지 않은 BSS로부터 수신된 것으로 결정되면 제2 NAV를 선택하는, NAV 관리 방법.
  3. 제 2 항에 있어서, 상기 소정의 NAV를 선택하는 단계는,
    상기 프레임이 어느 BSS로부터 수신된 것인지를 결정할 수 없는 경우 상기 제2 NAV를 선택하는, NAV 관리 방법.
  4. 제 1 항에 있어서,
    상기 다수의 NAV들은, 인트라 BSS NAV 및 비-인트라 BSS NAV를 포함하고,
    상기 비-인트라 BSS NAV는, OBSS(other BSS) 프레임을 위한 것인, NAV 관리 방법.
  5. 제 4 항에 있어서,
    상기 비-인트라 BSS NAV는, BSS를 특정 할 수 없는 프레임을 위한 것인, NAV 관리 방법.
  6. 제 5 항에 있어서,
    상기 BSS를 특정 할 수 없는 프레임은 ACK (acknowledgement) 프레임이거나 또는 CTS (clear-to-send) 프레임인, NAV 관리 방법.
  7. 제 1 항에 있어서,
    상기 다수의 NAV들 중 어느 하나라도 0 보다 큰 값을 갖는 경우, 상기 STA은 채널 엑세스를 보류하는, NAV 관리 방법.
  8. 제 1 항에 있어서,
    상기 STA은 상기 다수의 NAV들에 대응되는 다수의 NAV 타이머들을 설정하는, NAV 관리 방법.
  9. 제 1 항에 있어서, 상기 다수의 NAV들은,
    상기 다수의 NAV들 간의 차이 값과 하나의 NAV 타이머를 통해서 관리되는, NAV 관리 방법.
  10. 제 9 항에 있어서,
    상기 하나의 NAV 타이머의 값이 상기 다수의 NAV들 중 제1 NAV로부터 제2 NAV로 변경되는 경우, 상기 다수의 NAV들 간의 차이 값이 업데이트되는, NAV 관리 방법.
  11. 제 9 항에 있어서,
    상기 하나의 NAV 타이머에 맵핑된 제1 NAV의 현재 값과 상기 다수의 NAV들 간의 차이 값을 이용하여 제2 NAV의 유효성을 판단하는 단계를 더 포함하는, NAV 관리 방법.
  12. HE PPDU(high efficiency physical layer protocol data unit)를 지원하는 무선랜 시스템에서 NAV(network allocation vector)를 관리하는 스테이션(STA)에 있어서,
    구간(duration) 정보를 포함하는 프레임을 수신하는 수신기; 및
    상기 STA이 갖는 다수의 NAV들 중에서 소정의 NAV를 선택하고, 상기 프레임의 구간 정보에 기초하여 상기 소정의 NAV를 관리하는 프로세서를 포함하고,
    상기 소정의 NAV는, 상기 프레임이 상기 STA이 속하는 BSS(basic service set)로부터 수신된 것인지 여부에 기초하여 선택되는, 스테이션.
  13. 제 12 항에 있어서, 상기 소정의 NAV를 선택하는 상기 프로세서는,
    상기 프레임이 상기 STA이 속한 BSS로부터 수신된 것으로 결정되면 제1 NAV를 선택하고,
    상기 프레임이 상기 STA이 속하지 않은 BSS로부터 수신된 것으로 결정되면 제2 NAV를 선택하는, 스테이션.
  14. 제 13항에 있어서, 상기 소정의 NAV를 선택하는 상기 프로세서는,
    상기 프레임이 어느 BSS로부터 수신된 것인지를 결정할 수 없는 경우 상기 제2 NAV를 선택하는, 스테이션.
  15. 제 12 항에 있어서,
    상기 다수의 NAV들은, 인트라 BSS NAV 및 비-인트라 BSS NAV를 포함하고,
    상기 비-인트라 BSS NAV는, OBSS(other BSS) 프레임을 위한 것인, 스테이션.
  16. 제 15 항에 있어서,
    상기 비-인트라 BSS NAV는, BSS를 특정 할 수 없는 프레임을 위한 것인, 스테이션.
  17. 제 16 항에 있어서,
    상기 BSS를 특정 할 수 없는 프레임은 ACK (acknowledgement) 프레임이거나 또는 CTS (clear-to-send) 프레임인, 스테이션.
  18. 제 12 항에 있어서,
    상기 프로세서는 상기 다수의 NAV들에 대응되는 다수의 NAV 타이머들을 설정하는, 스테이션.
  19. 제 12 항에 있어서, 상기 다수의 NAV들은,
    상기 다수의 NAV들 간의 차이 값과 하나의 NAV 타이머를 통해서 관리되는, 스테이션.
PCT/KR2016/005341 2015-05-20 2016-05-20 무선랜 시스템에서 nav를 관리하는 방법 및 이를 위한 장치 WO2016186469A1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US15/508,076 US10524231B2 (en) 2015-05-20 2016-05-20 Method for managing NAV in wireless LAN system and device for same
JP2017560613A JP6849607B2 (ja) 2015-05-20 2016-05-20 無線ｌａｎシステムにおいてｎａｖを管理する方法及びそのための装置
EP16796796.7A EP3300445B1 (en) 2015-05-20 2016-05-20 Method for managing nav in wireless lan system and device for same
US16/704,815 US11564204B2 (en) 2015-05-20 2019-12-05 Method for managing NAV in wireless LAN system and device for same

Applications Claiming Priority (22)

Application Number Priority Date Filing Date Title
US201562163984P 2015-05-20 2015-05-20
US62/163,984 2015-05-20
US201562173376P 2015-06-10 2015-06-10
US62/173,376 2015-06-10
US201562201591P 2015-08-06 2015-08-06
US62/201,591 2015-08-06
US201562217795P 2015-09-11 2015-09-11
US62/217,795 2015-09-11
US201562238716P 2015-10-08 2015-10-08
US62/238,716 2015-10-08
US201562244123P 2015-10-20 2015-10-20
US62/244,123 2015-10-20
US201562246149P 2015-10-26 2015-10-26
US62/246,149 2015-10-26
US201562246639P 2015-10-27 2015-10-27
US62/246,639 2015-10-27
US201562250517P 2015-11-04 2015-11-04
US62/250,517 2015-11-04
US201562252501P 2015-11-08 2015-11-08
US62/252,501 2015-11-08
US201662276244P 2016-01-08 2016-01-08
US62/276,244 2016-01-08

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/508,076 A-371-Of-International US10524231B2 (en) 2015-05-20 2016-05-20 Method for managing NAV in wireless LAN system and device for same
US16/704,815 Continuation US11564204B2 (en) 2015-05-20 2019-12-05 Method for managing NAV in wireless LAN system and device for same

Publications (1)

Publication Number Publication Date
WO2016186469A1 true WO2016186469A1 (ko) 2016-11-24

Family

ID=57320670

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/005341 WO2016186469A1 (ko) 2015-05-20 2016-05-20 무선랜 시스템에서 nav를 관리하는 방법 및 이를 위한 장치

Country Status (4)

Country Link
US (2) US10524231B2 (ko)
EP (1) EP3300445B1 (ko)
JP (1) JP6849607B2 (ko)
WO (1) WO2016186469A1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110073691A (zh) * 2016-12-20 2019-07-30 索尼公司 通信设备和通信控制方法
CN110574441A (zh) * 2017-04-14 2019-12-13 韦勒斯标准与技术协会公司 使用bss标识符的无线通信方法和使用该方法的无线通信终端
AU2017206398B2 (en) * 2016-01-14 2020-01-02 Huawei Technologies Co., Ltd. Data transmission method and apparatus in WLAN

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016089998A1 (en) 2014-12-02 2016-06-09 Marvell Semiconductor, Inc. Signal fields in a high efficiency wireless local area network (hew) data unit
KR20170103861A (ko) * 2015-01-08 2017-09-13 마벨 월드 트레이드 리미티드 고효율 무선 근거리 통신망(wlan)에서의 다운링크 시그널링
EP3300445B1 (en) 2015-05-20 2020-05-13 LG Electronics Inc. Method for managing nav in wireless lan system and device for same
US10135651B2 (en) * 2015-06-24 2018-11-20 Newracom, Inc. Enhanced clear channel assessment
US10492221B1 (en) * 2015-06-25 2019-11-26 Marvell International Ltd. Methods and apparatus for protecting transmissions in a wireless communication network
US11477844B2 (en) * 2015-06-29 2022-10-18 Wilus Institute Of Standards And Technology Inc. Multi-user(MU) transmission for soliciting acknowledgement(ACK) from a target base station
WO2017011744A1 (en) * 2015-07-16 2017-01-19 Atefi Ali Apparatuses, methods, and computer-readable medium for communication in a wireless local area network
US10638516B2 (en) 2015-08-19 2020-04-28 Zte Corporation Controlling transmissions from multiple user devices via a request-clear technique
US10411850B2 (en) * 2015-08-28 2019-09-10 Newracom, Inc. Apparatus and method for network allocation vector operations
WO2017039377A1 (ko) * 2015-09-02 2017-03-09 주식회사 윌러스표준기술연구소 네트워크 얼로케이션 벡터를 이용하는 무선 통신 방법 및 무선 통신 단말
CN106550478B (zh) * 2015-09-22 2020-08-04 中兴通讯股份有限公司 一种多用户传输网络分配矢量设置方法和装置
US10257857B2 (en) 2015-09-28 2019-04-09 Newracom, Inc. Apparatus and methods for TXOP duration field in PHY header
MX2018004326A (es) 2015-10-29 2018-05-22 Panasonic Ip Man Co Ltd Dispositivo de comunicacion, terminal y metodo de comunicacion.
US10321485B1 (en) * 2015-12-14 2019-06-11 Newracom, Inc. Multiple network allocation vector operation
JP6962198B2 (ja) * 2016-01-06 2021-11-05 ソニーグループ株式会社 情報処理装置、通信システム、情報処理方法およびプログラム
US10178634B2 (en) * 2016-01-13 2019-01-08 Intel IP Corporation Transmission opportunity duration field in high efficiency signal field
US10200989B2 (en) 2016-01-13 2019-02-05 Intel IP Corporation Network allocation vector settings for multi-user operation
CN107172714B (zh) * 2016-03-08 2022-07-15 中兴通讯股份有限公司 网络分配矢量nav的处理方法及装置
KR102128286B1 (ko) 2016-04-02 2020-06-30 주식회사 윌러스표준기술연구소 중첩된 베이직 서비스 세트의 공간적 재사용 동작을 위한 무선 통신 방법 및 무선 통신 단말
EP4110000A1 (en) 2016-04-02 2022-12-28 Wilus Institute of Standards and Technology Inc. Wireless communication method and wireless communication terminal using basic service set identification information determination of received frame
KR20180132608A (ko) * 2016-04-13 2018-12-12 소니 주식회사 통신 장치, 통신 방법 및 프로그램
KR102344180B1 (ko) 2016-06-14 2021-12-28 주식회사 윌러스표준기술연구소 공간적 재사용 동작을 위한 무선 통신 방법 및 무선 통신 단말
US10439687B2 (en) * 2016-07-18 2019-10-08 Intel IP Corporation Transmission opportunity (TXOP) duration field disable setting in high efficiency signal A (HE-SIG-A)
US10187889B2 (en) 2016-08-25 2019-01-22 Intel IP Corporation Classification of basic service sets based on transmission opportunity holder addresses
JP2018050133A (ja) * 2016-09-20 2018-03-29 キヤノン株式会社 通信装置、制御方法、及びプログラム
US10863539B2 (en) * 2016-09-22 2020-12-08 Qualcomm Incorporated Transmission opportunity truncation
CN112272400A (zh) * 2017-01-13 2021-01-26 日本电气株式会社 无线通信系统、接入点、终端和通信方法
US20190090278A1 (en) * 2017-09-15 2019-03-21 Marvell World Trade Ltd. Clear Channel Assessment for Duplex Transmissions in Wireless Local Area Networks
US10880066B2 (en) * 2018-01-30 2020-12-29 Qualcomm Incorporated Multiplexing clients in wireless local area network transmissions
US11115104B2 (en) * 2018-05-25 2021-09-07 Intel Corporation Enhanced signaling and use of multiple transmission chains
US11245501B2 (en) * 2018-09-04 2022-02-08 Qualcomm Incorporated Multi-access point scheduling in wireless local area networks
US11374683B1 (en) * 2018-12-04 2022-06-28 Marvell Asia Pte Ltd Physical layer preamble for wireless local area networks
US11412524B2 (en) * 2019-03-19 2022-08-09 Qualcomm Incorporated Techniques to synchronize radio access technologies for co-channel operation
CN112188640A (zh) * 2019-07-05 2021-01-05 华为技术有限公司 通信保护方法及装置
US11832174B2 (en) 2020-01-24 2023-11-28 Cisco Technology, Inc. BSS-color grading in a WLAN infrastructure
JP7225177B2 (ja) * 2020-09-29 2023-02-20 任天堂株式会社 通信システム、通信方法、通信装置、および通信プログラム
WO2023152843A1 (ja) * 2022-02-09 2023-08-17 シャープ株式会社 無線通信装置および無線通信方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140113599A (ko) * 2013-03-15 2014-09-24 삼성전자주식회사 무선 네트워크에서 업링크 다중 사용자 다중 입출력 통신의 전송 기회 동작
KR20140130119A (ko) * 2012-02-10 2014-11-07 엘지전자 주식회사 무선랜 시스템에서 채널 액세스 방법 및 장치
KR20150003764A (ko) * 2012-03-29 2015-01-09 엘지전자 주식회사 무선랜 시스템에서 채널 액세스 제어 방법 및 장치
KR20150008470A (ko) * 2012-05-09 2015-01-22 인터디지탈 패튼 홀딩스, 인크 무선 근거리 네트워크 및 무선 송수신 유닛에서의 다중 사용자 다중 입력 다중 출력 통신
WO2015016684A1 (ko) * 2013-08-02 2015-02-05 엘지전자 주식회사 데이터 유닛을 수신하는 방법 및 장치

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4221225B2 (ja) * 2001-05-15 2009-02-12 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 複数の端末間の衝突を回避する方法
US7164671B2 (en) * 2001-12-27 2007-01-16 Koninklijke Philips Electronics N.V. Overlapping network allocation vector (ONAV) for avoiding collision in the IEEE 802.11 WLAN operating under HCF
US7136361B2 (en) * 2001-07-05 2006-11-14 At&T Corp. Hybrid coordination function (HCF) access through tiered contention and overlapped wireless cell mitigation
US8483105B2 (en) * 2003-10-15 2013-07-09 Qualcomm Incorporated High speed media access control
US7733835B2 (en) * 2005-07-20 2010-06-08 Interdigital Technology Corporation Method and system for reducing power consumption of a wireless transmit/receive unit
US20120182886A1 (en) * 2011-01-14 2012-07-19 Nokia Corporation Method and Apparatus for Wireless Medium Access
KR101933738B1 (ko) * 2011-06-24 2018-12-28 인터디지탈 패튼 홀딩스, 인크 광대역 및 다중 대역폭 전송 프로토콜을 지원하는 방법 및 장치
US8923146B2 (en) * 2011-08-31 2014-12-30 Nokia Corporation Channel reservation procedure
US9191889B2 (en) * 2012-07-26 2015-11-17 Stmicroelectronics, Inc. Slot-based power save improvement
GB2514169B (en) * 2013-05-16 2016-01-13 Broadcom Corp Method and apparatus for scaling coverage
CN104184702B (zh) * 2013-05-22 2017-11-24 华为终端有限公司 一种数据传输方法和设备
US9860174B2 (en) * 2013-08-28 2018-01-02 Qualcomm Incorporated Methods and apparatus for acknowledgment of multi-user uplink wireless transmissions
US10098150B2 (en) * 2013-10-05 2018-10-09 Lg Electronics Inc. Operation method and apparatus using sectorized transmission opportunity in wireless LAN system
US9749975B2 (en) * 2014-04-30 2017-08-29 Marvell World Trade Ltd. Systems and methods for implementing protected access based on a null data packet in a wireless network
WO2016087917A1 (ko) * 2014-11-19 2016-06-09 뉴라컴 인코포레이티드 고효율 무선랜에서 bss 식별정보에 기초한 ppdu프로세싱 방법 및 장치
US10314066B2 (en) * 2015-05-05 2019-06-04 Qualcomm Incorporated Techniques for protecting communications in wireless local area networks
EP3300445B1 (en) 2015-05-20 2020-05-13 LG Electronics Inc. Method for managing nav in wireless lan system and device for same

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140130119A (ko) * 2012-02-10 2014-11-07 엘지전자 주식회사 무선랜 시스템에서 채널 액세스 방법 및 장치
KR20150003764A (ko) * 2012-03-29 2015-01-09 엘지전자 주식회사 무선랜 시스템에서 채널 액세스 제어 방법 및 장치
KR20150008470A (ko) * 2012-05-09 2015-01-22 인터디지탈 패튼 홀딩스, 인크 무선 근거리 네트워크 및 무선 송수신 유닛에서의 다중 사용자 다중 입력 다중 출력 통신
KR20140113599A (ko) * 2013-03-15 2014-09-24 삼성전자주식회사 무선 네트워크에서 업링크 다중 사용자 다중 입출력 통신의 전송 기회 동작
WO2015016684A1 (ko) * 2013-08-02 2015-02-05 엘지전자 주식회사 데이터 유닛을 수신하는 방법 및 장치

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3300445A4 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2017206398B2 (en) * 2016-01-14 2020-01-02 Huawei Technologies Co., Ltd. Data transmission method and apparatus in WLAN
CN110073691A (zh) * 2016-12-20 2019-07-30 索尼公司 通信设备和通信控制方法
EP3562255A4 (en) * 2016-12-20 2019-12-11 Sony Corporation COMMUNICATION DEVICE AND COMMUNICATION CONTROL METHOD
US11012180B2 (en) 2016-12-20 2021-05-18 Sony Corporation Communication device and communication control method
CN110574441A (zh) * 2017-04-14 2019-12-13 韦勒斯标准与技术协会公司 使用bss标识符的无线通信方法和使用该方法的无线通信终端
CN110574441B (zh) * 2017-04-14 2023-04-14 韦勒斯标准与技术协会公司 使用bss标识符的无线通信方法和使用该方法的无线通信终端

Also Published As

Publication number Publication date
EP3300445A1 (en) 2018-03-28
EP3300445A4 (en) 2019-01-23
JP6849607B2 (ja) 2021-03-24
US10524231B2 (en) 2019-12-31
US20200154398A1 (en) 2020-05-14
JP2018516018A (ja) 2018-06-14
US11564204B2 (en) 2023-01-24
EP3300445B1 (en) 2020-05-13
US20170295560A1 (en) 2017-10-12

Similar Documents

Publication Publication Date Title
WO2016186469A1 (ko) 무선랜 시스템에서 nav를 관리하는 방법 및 이를 위한 장치
WO2016182390A1 (ko) 무선랜 시스템에서 프레임을 송수신하는 방법 및 이를 위한 장치
WO2020045891A1 (ko) 무선랜 시스템에서 조인트 전송을 수행하는 방법 및 장치
WO2017022898A1 (ko) 무선 통신 시스템에서 데이터 전송 방법 및 이를 위한 장치
WO2016167438A1 (ko) 무선랜 시스템에서 신호를 송수신하는 방법 및 이를 위한 장치
WO2016125998A1 (ko) 무선 통신 시스템에서 다중 사용자 송수신을 위한 방법 및 이를 위한 장치
WO2016089059A1 (ko) 무선 통신 시스템에서 데이터 전송 방법 및 이를 위한 장치
WO2015199306A1 (ko) 무선 통신 시스템에서 다중 사용자 상향링크 데이터 전송을 위한 방법 및 이를 위한 장치
WO2016143970A1 (ko) 무선 통신 시스템의 데이터 전송 방법 및 장치
WO2016021838A1 (ko) 무선 통신 시스템에서 프레임 전송 방법 및 이를 위한 장치
WO2016028125A2 (ko) 무선 통신 시스템에서 상향링크 전송 방법 및 이를 위한 장치
WO2016053024A1 (ko) 무선 통신 시스템에서 데이터 전송 방법 및 이를 위한 장치
WO2016159513A1 (ko) 무선 통신 시스템의 데이터 전송 방법 및 장치
WO2016028131A1 (ko) 무선 통신 시스템에서 상향링크 다중 사용자 전송 방법 및 이를 위한 장치
WO2016032258A2 (ko) 무선 통신 시스템에서 데이터 전송 방법 및 이를 위한 장치
WO2016021831A1 (ko) 무선 통신 시스템에서 다중 사용자 전송 방법 및 이를 위한 장치
WO2016028124A1 (ko) 무선 통신 시스템에서 데이터 전송 방법 및 이를 위한 장치
WO2016024750A1 (ko) 무선 통신 시스템에서 하향링크 다중 사용자 전송 방법 및 이를 위한 장치
WO2019103452A1 (ko) 무선 랜에서 프레임을 송신 또는 수신하기 위한 방법 및 이를 위한 장치
WO2016099139A1 (ko) 무선 통신 시스템에서 데이터 전송 방법 및 이를 위한 장치
WO2020050528A1 (ko) Rf의 최대 전송 가능한 대역폭이 서로 다른 무선장치가 있는 wlan 환경에서 최적화된 위상 회전을 적용하는 방법 및 장치
WO2019124822A1 (ko) 무선 랜에서 프레임을 송신 또는 수신하기 위한 방법 및 이를 위한 장치
WO2016195402A1 (ko) 무선랜 시스템에서 전력 저감 모드로 동작하는 방법 및 이를 위한 장치
WO2019194361A1 (ko) 무선랜 시스템에서 프레임을 송신 또는 수신하기 위한 방법 및 이를 위한 장치
WO2016200182A1 (ko) 무선랜 시스템에서 nav를 관리하는 방법 및 이를 위한 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16796796

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2016796796

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 15508076

Country of ref document: US

Ref document number: 2016796796

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2017560613

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE