WO2025239596A1 - 무선랜 시스템에서 serving ap mld의 큐에 있는 dl 데이터의 송신이 끝나는 시점에 대한 정보를 알려주는 방법 및 장치 - Google Patents

무선랜 시스템에서 serving ap mld의 큐에 있는 dl 데이터의 송신이 끝나는 시점에 대한 정보를 알려주는 방법 및 장치

Info

Publication number
WO2025239596A1
WO2025239596A1 PCT/KR2025/006078 KR2025006078W WO2025239596A1 WO 2025239596 A1 WO2025239596 A1 WO 2025239596A1 KR 2025006078 W KR2025006078 W KR 2025006078W WO 2025239596 A1 WO2025239596 A1 WO 2025239596A1
Authority
WO
WIPO (PCT)
Prior art keywords
mld
roaming
information
link
sta
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
PCT/KR2025/006078
Other languages
English (en)
French (fr)
Inventor
윤예린
장인선
최진수
이홍원
백선희
김건환
차동주
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
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 LG Electronics Inc filed Critical LG Electronics Inc
Publication of WO2025239596A1 publication Critical patent/WO2025239596A1/ko
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/02—Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/16—Performing reselection for specific purposes
    • H04W36/18—Performing reselection for specific purposes for allowing seamless reselection, e.g. soft reselection
    • 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]

Definitions

  • This specification relates to a technique for notifying information about the end point of transmission of DL data in a queue of a Serving AP MLD in a wireless LAN system, and more specifically, to a method and device for determining the point in time of transition from the Serving AP MLD to the Target AP MLD by notifying the point in time when all DL data (or DL packets) remain in the queue of the Serving AP MLD when MLD roaming is performed, through a roaming response frame.
  • Wireless local area networks have been improved in various ways.
  • the IEEE 802.11ax standard proposed an improved communication environment using orthogonal frequency division multiple access (OFDMA) and downlink multi-user multiple input, multiple output (DL MU MIMO) techniques.
  • OFDMA orthogonal frequency division multiple access
  • DL MU MIMO downlink multi-user multiple input, multiple output
  • the new communications standard could be the Extreme High Throughput (EHT) standard, which is currently under discussion.
  • the EHT standard could utilize newly proposed increased bandwidth, an improved PHY layer protocol data unit (PPDU) structure, improved sequences, and the Hybrid Automatic Repeat Request (HARQ) technique.
  • the EHT standard could also be referred to as the IEEE 802.11be standard.
  • New wireless LAN standards may allow for an increased number of spatial streams. This may necessitate improvements to signaling techniques within the wireless LAN system to properly utilize these increased spatial streams.
  • the present specification proposes a method and device for notifying information about the end point of transmission of DL data in a queue of a Serving AP MLD in a wireless LAN system.
  • An example of this specification proposes a method for informing when transmission of DL data in a queue of a Serving AP MLD has ended.
  • the present embodiment can be performed in a network environment that supports a next-generation wireless LAN system (UHR (Ultra High Reliability) wireless LAN system or next wi-fi).
  • the next-generation wireless LAN system is a wireless LAN system that improves the 802.11be system and can satisfy backward compatibility with the 802.11be system.
  • the present embodiment proposes a method for determining a time point for transitioning from the Serving AP MLD to the Target AP MLD by notifying the time point when all DL data (or DL packets) remain in the queue of the Serving AP MLD when MLD roaming is performed through a roaming response frame.
  • a non-AP STA (station) belonging to the above non-AP MLD transmits a roaming request frame to the first AP belonging to the first AP MLD.
  • the non-AP STA receives a roaming response frame from the first AP.
  • the non-AP STA determines whether to transition from the first AP MLD to the second AP MLD based on the roaming response frame.
  • the roaming response frame includes first information about whether DL (downlink) data remains in the queue of the first AP MLD and second information about the DL data transmitted from the first AP MLD.
  • the point in time at which transmission of the DL data ends is determined.
  • the DL data may remain in the queue of the first AP MLD. Based on the first information being set to 0, the DL data may no longer be in the queue of the first AP MLD.
  • the second information may include information about the size of the DL data, the number of MSDUs (MAC Service Data Units) that have not yet been transmitted, information about a Sequence Number (SN) or a Packet Number (PN), and information about a Traffic IDentifier (TID) that identifies a pending MSDU.
  • the information about the SN or PN may be the SN or PN of the last MSDU in the MSDU.
  • the TID may be set to a bitmap whose size is the number of the pending MSDUs.
  • the first information is set to 1
  • the DL data remains in the queue of the first AP MLD
  • the non-AP STA can determine when the transmission of the DL data ends.
  • a transition is performed from the first AP MLD to the second AP MLD.
  • the present embodiment proposes a method for determining a time point for transition from the Serving AP MLD to the Target AP MLD by notifying the time point at which all DL data is transmitted through a roaming response frame when DL data remains in the queue of the Serving AP MLD during the process of performing MLD roaming.
  • a Non-AP STA can check the point in time when all of the DL data existing in the queue of the Serving AP MLD is transmitted, thereby having the effect of efficiently performing MLD roaming.
  • Figure 1 illustrates an example of a transmitting device and/or a receiving device of the present specification.
  • FIG. 2 is a conceptual diagram showing the structure of a wireless local area network (WLAN).
  • WLAN wireless local area network
  • Figure 3 is a diagram illustrating a general link setup process.
  • Figure 4 illustrates one embodiment of a multi-link (ML).
  • FIG. 5 illustrates a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted/received by an STA of this specification.
  • PPDU physical protocol data unit or physical layer (PHY) protocol data unit
  • Figure 6 is a diagram showing the layout of resource units (RUs) used for 20MHz PPDU.
  • Figure 7 is a diagram showing the layout of resource units (RUs) used for 40MHz PPDU.
  • Figure 8 is a diagram showing the layout of resource units (RUs) used for 80MHz PPDU.
  • Figure 9 shows the operation according to UL-MU.
  • Figure 10 shows an example of channels used/supported/defined within the 2.4 GHz band.
  • Figure 11 illustrates an example of channels used/supported/defined within the 5 GHz band.
  • Figure 12 illustrates an example of channels used/supported/defined within the 6 GHz band.
  • Figure 13 shows an example of a header of a MAC frame.
  • FIG. 14 illustrates a modified example of a transmitting device and/or a receiving device of the present specification.
  • FIG 15 illustrates an over-the-air (OTA) FT protocol in a Robust Security Network (RSN).
  • OTA over-the-air
  • RSN Robust Security Network
  • Figure 16 illustrates the high-level architecture for AP MLD.
  • Figure 17 illustrates an example of a high-level architecture for UHR AP MLD.
  • Figure 18 illustrates another example of a high-level architecture for UHR AP MLD.
  • Figure 19 illustrates another example of the High-level Architecture for UHR AP MLD.
  • Figure 20 illustrates an example of a high-level architecture in the case where there are only entities that are not MLD-based.
  • Figure 21 illustrates another example of a High-level Architecture in the case of entities that are not MLD-based.
  • Figure 22 illustrates an example of a Roaming Architecture in an AP MLD area.
  • Figure 23 shows an example of an RNR IE.
  • Figure 24 shows another example for the RNR IE.
  • Figure 25 shows another example for the RNR IE.
  • Figure 26 illustrates an example of the AP Roaming Recommendation enabled field and the Roaming Reason Code field in the Common Info field.
  • Figure 27 illustrates an example of the AP Roaming Recommendation enabled field in the Link Info field.
  • Figure 28 illustrates an example of the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • Figure 29 illustrates an example of the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • Figure 30 illustrates an example in which the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes a UHR AP MLD ID and an AP MLD ID.
  • Figure 31 illustrates an example in which an AP MLD ID is included in the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • Figure 32 illustrates an example in which the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes a UHR AP MLD ID and an AP MLD ID.
  • Figure 33 illustrates an example in which an AP MLD ID is included in the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • Figure 34 illustrates another example in which the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes the UHR AP MLD ID and the AP MLD ID.
  • Figure 35 illustrates another example in which the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes an AP MLD ID.
  • Figure 36 illustrates an example in which a Temporary field is included in the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • Figure 37 illustrates an example in which a Temporary field is included in the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • Figure 38 illustrates another example in which a Temporary field is included in the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • Figure 39 illustrates an example in which the AP Removal Timer field is included in the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • Figure 40 illustrates an example of the Common Info field of the Basic Multi-link IE proposed in this embodiment.
  • Figure 41 illustrates an example of the Link Info field of the Basic Multi-link IE proposed in this embodiment.
  • Figure 42 illustrates an example of the Group Key Information field.
  • Figure 43 illustrates a procedure for determining whether an N_AP is capable of roaming using the Collocation Enabled field.
  • Figure 44 illustrates a procedure for determining whether an N_AP is capable of roaming using a Collocation ID.
  • Figure 45 illustrates the MLD Roaming procedure when a UHR AP MLD ID is entered in the Reconfiguration element.
  • Figure 46 illustrates the MLD Roaming procedure when the UHR AP MLD ID is not entered in the Reconfiguration element.
  • Figure 47 illustrates an example of a collocated AP set.
  • Figure 48 illustrates Example 1 for the MLD Roaming procedure.
  • Figure 49 shows the operation process of Example 1 for the MLD Roaming procedure.
  • Figure 50 illustrates Example 2 for the MLD Roaming procedure.
  • Figure 51 shows the operation process of Example 2 for the MLD Roaming procedure.
  • Figure 52 illustrates Example 3 for the MLD Roaming procedure.
  • Figure 53 shows the operation process of Example 3 for the MLD Roaming procedure.
  • Figure 54 illustrates Example 4 for the MLD Roaming procedure.
  • Figure 55 shows the operation process of examples 3 and 4 for the MLD Roaming procedure.
  • Figure 56 illustrates Example 5 for the MLD Roaming procedure.
  • Figure 57 illustrates Example 6 for the MLD Roaming procedure.
  • Figure 58 shows an example of MLD Roaming using TIM.
  • Figure 59 shows the operation process for the MLD Roaming procedure using TIM.
  • Figure 60 illustrates an example of a Roaming Procedure using Context transfer (only entities exist).
  • Figure 61 illustrates an example of a roaming process using context transfer.
  • Figure 62 illustrates another example of a roaming process using context transfer.
  • Figure 63 illustrates an example of transmitting DL data accumulated in the queue of the Serving AP MLD.
  • Figure 64 illustrates a procedure for notifying the DL Timer of the completion of transmission of DL Data accumulated in the queue of the Serving AP MLD.
  • Figure 65 illustrates an example of the Baseline of the Roaming Procedure.
  • Figure 66 illustrates an example of Baseline #1 of the Roaming Procedure.
  • Figure 67 illustrates an example of Baseline #2 of the Roaming Procedure.
  • Figure 68 illustrates an example of Baseline #3 of the Roaming Procedure.
  • Figure 69 illustrates an example of Baseline #4 of the Roaming Procedure.
  • Figure 70 illustrates an example explaining the order of link establishment with the Target AP MLD.
  • Figure 71 is a flowchart illustrating the operation of a transmitting device according to the present embodiment.
  • Figure 72 is a flowchart illustrating the operation of a receiving device according to the present embodiment.
  • Figure 73 is a flowchart illustrating a procedure for notifying information about the point in time when transmission of DL data in the queue of a Serving AP MLD ends in MLD roaming according to the present embodiment.
  • Fig. 74 is a flowchart illustrating a procedure for receiving information about the point in time when transmission of DL data in the queue of a Serving AP MLD ends in MLD roaming according to the present embodiment.
  • a or B can mean “only A,” “only B,” or “both A and B.”
  • a or B in this specification can be interpreted as “A and/or B.”
  • A, B or C in this specification can mean “only A,” “only B,” “only C,” or “any combination of A, B, and C.”
  • a slash (/) or a comma can mean “and/or.”
  • A/B can mean “and/or B.”
  • A/B can mean "only A,” “only B,” or “both A and B.”
  • A, B, C can mean "A, B, or C.”
  • At least one of A and B can mean “only A,” “only B,” or “both A and B.” Additionally, in this specification, the expressions “at least one of A or B” or “at least one of A and/or B” can be interpreted identically to “at least one of A and B.”
  • parentheses used in this specification may mean “for example.” Specifically, when “control information (UHR-Signal field)” is indicated, the “UHR-Signal field” may be suggested as an example of “control information.” In other words, the “control information” in this specification is not limited to the “UHR-Signal field,” and the “UHR-Signal field” may be suggested as an example of “control information.” In addition, even when indicated as “control information (UHR-Signal field),” the “UHR-Signal field” may be suggested as an example of “control information.”
  • a/an can mean “at least one” or “one or more.” Additionally, terms ending in “(s)” can mean “at least one” or “one or more.”
  • the following examples of this specification can be applied to various wireless communication systems.
  • the following examples of this specification can be applied to wireless local area network (WLAN) systems.
  • WLAN wireless local area network
  • the present specification can be applied to the IEEE 802.11a/g/n/ac/ax/be/bn standards.
  • the examples of this specification can be applied to the Ultra High Reliability (UHR) standard or the next-generation wireless LAN standard that enhances IEEE 802.11bn.
  • UHR Ultra High Reliability
  • the examples of this specification can be applied to mobile communication systems.
  • the examples of this specification can be applied to mobile communication systems based on Long Term Evolution (LTE) and its evolution based on the 3rd Generation Partnership Project (3GPP) standard.
  • LTE Long Term Evolution
  • 3GPP 3rd Generation Partnership Project
  • Figure 1 illustrates an example of a transmitting device and/or a receiving device of the present specification.
  • FIG. 1 relates to at least one STA (station).
  • the STA (110, 120) of the present specification may also be referred to by various names such as a mobile terminal, a wireless device, a Wireless Transmit/Receive Unit (WTRU), a User Equipment (UE), a Mobile Station (MS), a Mobile Subscriber Unit, or simply a user.
  • the STA (110, 120) of the present specification may also be referred to by various names such as a network, a base station, a Node-B, an access point (AP), a repeater, a router, a relay, etc.
  • the STA (110, 120) of the present specification may also be referred to by various names such as a receiving apparatus, a transmitting apparatus, a receiving STA, a transmitting STA, a receiving device, a transmitting device, etc.
  • STA (110, 120) may perform the role of an AP (access point) or a non-AP role. That is, STA (110, 120) of the present specification may perform the functions of an AP and/or a non-AP.
  • AP may also be indicated as an AP STA.
  • the STA (110, 120) of this specification can support various communication standards other than the IEEE 802.11 standard. For example, it can support communication standards according to the 3GPP standard (e.g., LTE, LTE-A, 5G NR standard).
  • the STA of this specification can be implemented in various devices such as mobile phones, vehicles, and personal computers.
  • the STA of this specification can support communication for various communication services such as voice calls, video calls, data communications, and autonomous driving (Self-Driving, Autonomous-Driving).
  • STA 110, 120
  • STA may include a medium access control (MAC) and a physical layer interface for a wireless medium that follow the provisions of the IEEE 802.11 standard.
  • MAC medium access control
  • STA 110, 120
  • the first STA (110) may include a processor (111), a memory (112), and a transceiver (113).
  • the illustrated processor, memory, and transceiver may each be implemented as separate chips, or at least two blocks/functions may be implemented through a single chip.
  • the transceiver (113) of the first STA performs signal transmission and reception operations. Specifically, it can transmit and receive IEEE 802.11 packets (e.g., IEEE 802.11a/b/g/n/ac/ax/be, etc.).
  • IEEE 802.11a/b/g/n/ac/ax/be, etc. e.g., IEEE 802.11a/b/g/n/ac/ax/be, etc.
  • the first STA (110) can perform the intended operation of the AP.
  • the processor (111) of the AP can receive a signal through the transceiver (113), process the received signal, generate a transmission signal, and perform control for signal transmission.
  • the memory (112) of the AP can store a signal received through the transceiver (113) (i.e., a reception signal) and store a signal to be transmitted through the transceiver (i.e., a transmission signal).
  • the second STA (120) can perform the intended operation of a non-AP STA.
  • the transceiver (123) of the non-AP performs signal transmission and reception operations. Specifically, it can transmit and receive IEEE 802.11 packets (e.g., IEEE 802.11a/b/g/n/ac/ax/be, etc.).
  • the processor (121) of the Non-AP STA can receive a signal through the transceiver (123), process the received signal, generate a transmission signal, and perform control for signal transmission.
  • the memory (122) of the Non-AP STA can store a signal received through the transceiver (123) (i.e., a reception signal) and store a signal to be transmitted through the transceiver (i.e., a transmission signal).
  • the operation of a device indicated as AP may be performed in the first STA (110) or the second STA (120).
  • the operation of the device indicated as AP may be controlled by the processor (111) of the first STA (110), and a related signal may be transmitted or received through a transceiver (113) controlled by the processor (111) of the first STA (110).
  • control information related to the operation of the AP or a transmission/reception signal of the AP may be stored in the memory (112) of the first STA (110).
  • the operation of the device indicated as an AP is controlled by the processor (121) of the second STA (120), and a related signal can be transmitted or received through a transceiver (123) controlled by the processor (121) of the second STA (120).
  • control information related to the operation of the AP or the transmission/reception signal of the AP can be stored in the memory (122) of the second STA (110).
  • the operation of a device indicated as a non-AP may be performed in the STA (110) or the second STA (120).
  • the operation of the device indicated as a non-AP may be controlled by the processor (121) of the second STA (120), and a related signal may be transmitted or received through a transceiver (123) controlled by the processor (121) of the second STA (120).
  • control information related to the operation of the non-AP or the transmission/reception signal of the AP may be stored in the memory (122) of the second STA (120).
  • the operation of a device indicated as a non-AP is controlled by the processor (111) of the first STA (110), and a related signal may be transmitted or received through a transceiver (113) controlled by the processor (111) of the first STA (120).
  • control information related to the operation of the non-AP or the transmission/reception signal of the AP may be stored in the memory (112) of the first STA (110).
  • devices called (transmitting/receiving) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmitting/receiving) Terminal, (transmitting/receiving) device, (transmitting/receiving) apparatus, network, etc. may refer to the STA (110, 120) of FIG. 1.
  • devices indicated as (transmitting/receiving) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmitting/receiving) Terminal, (transmitting/receiving) device, (transmitting/receiving) apparatus, network, etc. without specific drawing symbols may also refer to the STA (110, 120) of FIG. 1.
  • the operation of various STAs transmitting and receiving signals may be performed by the transceivers (113, 123) of FIG. 1.
  • an example of an operation that generates a transmission/reception signal or performs data processing or operation in advance for a transmission/reception signal may include 1) an operation of determining/obtaining/configuring/computing/decoding/encoding bit information of a subfield (SIG, STF, LTF, Data) field included in a PPDU, 2) an operation of determining/configuring/obtaining time resources or frequency resources (e.g., subcarrier resources) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 3) an operation of determining/configuring/obtaining a specific sequence (e.g., a pilot sequence, an STF/LTF sequence, an extra sequence applied to SIG) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 3) an operation of determining/configuring/obtaining a specific sequence (e.g., a pilot sequence, an STF/LTF sequence, an extra sequence applied to SIG) used for a
  • various information e.g., information related to fields/subfields/control fields/parameters/power, etc.
  • various information e.g., information related to fields/subfields/control fields/parameters/power, etc.
  • various STAs for determining/acquiring/configuring/computing/decoding/encoding transmission/reception signals can be stored in the memory (112, 122) of FIG. 1.
  • the device/STA of the sub-drawing (a) of the above-described FIG. 1 can be modified as in the sub-drawing (b) of FIG. 1.
  • the STA (110, 120) of the present specification will be described based on the sub-drawing (b) of FIG. 1.
  • the transceiver (113, 123) illustrated in sub-drawing (b) of FIG. 1 may perform the same function as the transceiver illustrated in sub-drawing (a) of FIG. 1 described above.
  • the processing chip (114, 124) illustrated in sub-drawing (b) of FIG. 1 may include a processor (111, 121) and a memory (112, 122).
  • the processor (111, 121) and the memory (112, 122) illustrated in sub-drawing (b) of FIG. 1 may perform the same function as the processor (111, 121) and the memory (112, 122) illustrated in sub-drawing (a) of FIG. 1 described above.
  • the mobile terminal, wireless device, Wireless Transmit/Receive Unit (WTRU), User Equipment (UE), Mobile Station (MS), Mobile Subscriber Unit, user, user STA, network, Base Station, Node-B, Access Point (AP), repeater, router, relay, receiving device, transmitting device, receiving STA, transmitting STA, receiving Device, transmitting Device, receiving Apparatus, and/or transmitting Apparatus described below may refer to the STA (110, 120) illustrated in the sub-drawings (a)/(b) of FIG. 1, or may refer to the processing chip (114, 124) illustrated in the sub-drawing (b) of FIG. 1.
  • the technical feature of the present specification may be performed in the STA (110, 120) illustrated in the sub-drawings (a)/(b) of FIG. 1, or may be performed only in the processing chip (114, 124) illustrated in the sub-drawings (b) of FIG. 1.
  • the technical feature that the transmitting STA transmits a control signal may be understood as a technical feature that the control signal generated in the processor (111, 121) illustrated in the sub-drawings (a)/(b) of FIG. 1 is transmitted through the transceiver (113, 123) illustrated in the sub-drawings (a)/(b) of FIG. 1.
  • the technical feature that the transmitting STA transmits a control signal may be understood as a technical feature that the control signal to be transmitted to the transceiver (113, 123) is generated in the processing chip (114, 124) illustrated in the sub-drawings (b) of FIG. 1.
  • the technical feature of a receiving STA receiving a control signal can be understood as a technical feature of a control signal being received by a transceiver (113, 123) illustrated in sub-drawing (a) of FIG. 1.
  • the technical feature of a receiving STA receiving a control signal can be understood as a technical feature of a control signal received by a transceiver (113, 123) illustrated in sub-drawing (a) of FIG. 1 being acquired by a processor (111, 121) illustrated in sub-drawing (a) of FIG. 1.
  • the technical feature of a receiving STA receiving a control signal can be understood as a technical feature of a control signal received by a transceiver (113, 123) illustrated in sub-drawing (b) of FIG. 1 being acquired by a processing chip (114, 124) illustrated in sub-drawing (b) of FIG.
  • software code (115, 125) may be included in the memory (112, 122).
  • the software code (115, 125) may include instructions that control the operation of the processor (111, 121).
  • the software code (115, 125) may be included in various programming languages.
  • the processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include an application-specific integrated circuit (ASIC), another chipset, a logic circuit, and/or a data processing device.
  • the processor may be an application processor (AP).
  • the processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modem (modulator and demodulator).
  • DSP digital signal processor
  • CPU central processing unit
  • GPU graphics processing unit
  • modem modulator and demodulator
  • 1 may be a SNAPDRAGONTM series processor manufactured by Qualcomm®, an EXYNOSTM series processor manufactured by Samsung®, an A series processor manufactured by Apple®, a HELIOTM series processor manufactured by MediaTek®, an ATOMTM series processor manufactured by INTEL®, or an enhanced processor thereof.
  • uplink may mean a link for communication from a non-AP STA to an AP STA, and uplink PPDU/packet/signal, etc. may be transmitted through the uplink.
  • downlink may mean a link for communication from an AP STA to a non-AP STA, and downlink PPDU/packet/signal, etc. may be transmitted through the downlink.
  • FIG. 2 is a conceptual diagram showing the structure of a wireless local area network (WLAN).
  • WLAN wireless local area network
  • FIG. 2 shows the structure of the infrastructure BSS (basic service set) of IEEE (institute of electrical and electronic engineers) 802.11.
  • FIG. 2 shows the structure of the infrastructure BSS (basic service set) of IEEE (institute of electrical and electronic engineers) 802.11.
  • the wireless LAN system may include one or more infrastructure BSSs (200, 205) (hereinafter, BSS).
  • BSSs are a collection of APs and STAs, such as an access point (AP) 225 and a station (STA1, 200-1), that have successfully synchronized and can communicate with each other, and are not a concept that designates a specific area.
  • the BSS (205) may also include one or more STAs (205-1, 205-2) that can be associated with one AP (230).
  • a BSS may include at least one STA, an AP (225, 230) providing a distribution service, and a distribution system (DS, 210) connecting multiple APs.
  • a distributed system (210) can connect multiple BSSs (200, 205) to implement an extended service set (ESS, 240).
  • An ESS (240) can be used as a term to indicate a network formed by connecting one or more APs through the distributed system (210).
  • APs included in a single ESS (240) can have the same SSID (service set identification).
  • the portal can act as a bridge to connect a wireless LAN network (IEEE 802.11) to another network (e.g., 802.X).
  • IEEE 802.11 IEEE 802.11
  • 802.X another network
  • a network between APs (225, 230) and a network between APs (225, 230) and STAs (200-1, 205-1, 205-2) can be implemented.
  • a network that establishes a network and performs communication between STAs without an AP (225, 230) is defined as an ad-hoc network or an independent basic service set (IBSS).
  • FIG. 2 The bottom of Figure 2 is a conceptual diagram showing IBSS.
  • the IBSS is a BSS that operates in ad-hoc mode. Since the IBSS does not include an AP, there is no centralized management entity. That is, in the IBSS, the STAs (250-1, 250-2, 250-3, 255-4, 255-5) are managed in a distributed manner. In the IBSS, all STAs (250-1, 250-2, 250-3, 255-4, 255-5) can be mobile STAs, and access to the distributed system is not permitted, forming a self-contained network.
  • Figure 3 is a diagram illustrating a general link setup process.
  • the STA may perform a network discovery operation.
  • This network discovery operation may include scanning by the STA. That is, for the STA to access a network, it must find a network it can join. Before joining a wireless network, the STA must identify compatible networks. The process of identifying networks in a specific area is called scanning. Scanning methods include active scanning and passive scanning.
  • Figure 3 illustrates a network discovery operation that includes an active scanning process as an example.
  • active scanning an STA performing scanning transmits a probe request frame to discover which APs exist in the vicinity while moving between channels and waits for a response.
  • a responder transmits a probe response frame to the STA that transmitted the probe request frame in response to the probe request frame.
  • the responder may be the STA that last transmitted a beacon frame in the BSS of the channel being scanned.
  • the AP transmits the beacon frame, so the AP becomes the responder.
  • the STAs within the IBSS take turns transmitting beacon frames, so 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 can store BSS-related information included in the received probe response frame and move to the next channel (e.g., channel 2) to perform scanning (i.e., transmitting and receiving probe requests/responses on channel 2) in the same manner.
  • the next channel e.g., channel 2
  • scanning i.e., transmitting and receiving probe requests/responses on channel 2
  • the scanning operation can also be performed in a passive scanning manner.
  • An STA performing scanning based on passive scanning can wait for a beacon frame while moving between channels.
  • a beacon frame is one of the management frames in IEEE 802.11. It announces the presence of a wireless network and is periodically transmitted so that the scanning STA can find the wireless network and participate in the wireless network.
  • the AP periodically transmits the beacon frame, and in the IBSS, the STAs within the IBSS take turns transmitting the beacon frame.
  • the scanning STA receives a beacon frame, it stores the information about the BSS included in the beacon frame and moves to another channel, recording the beacon frame information on each channel.
  • An STA that receives a beacon frame can store the 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.
  • An STA that discovers a network can perform an authentication process through step S320.
  • This authentication process may be referred to as the first authentication process to clearly distinguish it from the security setup operation of step S340 described below.
  • the authentication process of S320 may include a process in which the STA transmits an authentication request frame to the AP, and the AP responds by transmitting an authentication response frame to the STA.
  • the authentication frame used for the authentication request/response corresponds to a management frame.
  • the authentication frame may include information such as an authentication algorithm number, an authentication transaction sequence number, a status code, a challenge text, a Robust Security Network (RSN), and a Finite Cyclic Group.
  • information such as an authentication algorithm number, an authentication transaction sequence number, a status code, a challenge text, a Robust Security Network (RSN), and a Finite Cyclic Group.
  • RSN Robust Security Network
  • An STA can transmit an authentication request frame to an AP.
  • the AP can determine whether to grant authentication to the STA based on the information contained in the received authentication request frame.
  • the AP can provide the result of the authentication process to the STA via an authentication response frame.
  • a successfully authenticated STA may perform an association process based on step S330.
  • the association process includes a process in which the STA transmits an association request frame to the AP, and the AP transmits an association response frame to the STA in response.
  • the association request frame may include information related to various capabilities, such as a beacon listen interval, a service set identifier (SSID), supported rates, supported channels, RSN, mobility domain, supported operating classes, a Traffic Indication Map Broadcast request, and interworking service capabilities.
  • the association response frame may contain information related to various capabilities, status codes, Association ID (AID), supported rates, Enhanced Distributed Channel Access (EDCA) parameter sets, Received Channel Power Indicator (RCPI), Received Signal to Noise Indicator (RSNI), mobility domains, timeout interval (association comeback time), overlapping BSS scan parameters, TIM broadcast response, QoS maps, etc.
  • AID Association ID
  • EDCA Enhanced Distributed Channel Access
  • RCPI Received Channel Power Indicator
  • RSNI Received Signal to Noise Indicator
  • mobility domains timeout interval (association comeback time)
  • association comeback time overlapping BSS scan parameters
  • TIM broadcast response TIM broadcast response
  • QoS maps etc.
  • step S340 the STA may perform a security setup process.
  • the security setup process of step S340 may include, for example, a process of setting up a private key through a four-way handshaking using an Extensible Authentication Protocol over LAN (EAPOL) frame.
  • EAPOL Extensible Authentication Protocol over LAN
  • Figure 4 illustrates one embodiment of a multi-link (ML).
  • multiple multi-link devices can communicate over a remote link.
  • the MLDs can be categorized into AP MLDs including multiple AP STAs and non-AP MLDs including multiple non-AP STAs. That is, the AP MLD can include affiliated APs (i.e., AP STAs), and the non-AP MLD can include affiliated STAs (i.e., non-AP STAs, or user-STAs).
  • a multilink may include a first link and a second link, and different channels/subchannels/frequency resources may be allocated to the first and second links.
  • the first and second multilinks may be identified through a link ID of 4 bits (or other n bits).
  • the first and second links may be configured in the same 2.4 GHz, 5 GHz, or 6 GHz band. Alternatively, the first link and the second link may be configured in different bands.
  • the AP MLD of FIG. 4 includes three affiliated APs.
  • AP1 may operate in the 2.4 GHz band
  • AP2 may operate in the 5 GHz band
  • AP3 may operate in the 6 GHz band.
  • the first link in which AP1 and non-AP1 operate may be defined as a channel/subchannel/frequency resource within the 2.4 GHz band.
  • the second link in which AP2 and non-AP2 operate may be defined as a channel/subchannel/frequency resource within the 5 GHz band.
  • the third link in which AP3 and non-AP3 operate may be defined as a channel/subchannel/frequency resource within the 6 GHz band.
  • AP1 may initiate a multi-link setup procedure (ML setup procedure) by transmitting an Association Request frame to non-AP STA1.
  • non-AP STA1 may transmit an Association Response frame in response to the Association Request frame.
  • AP e.g., AP1/2/3 illustrated in FIG. 4
  • AP1/2/3 illustrated in FIG. 4 may be identical to the AP illustrated in FIG. 1 and/or FIG. 2
  • each non-AP e.g., non-AP1/2/3) illustrated in FIG. 4 may be identical to the STA (i.e., user-STA or non-AP STA) illustrated in FIG. 1 and/or FIG. 2.
  • Figure 5 illustrates a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted/received by an STA of this specification.
  • PPDU physical protocol data unit or physical layer (PHY) protocol data unit
  • the STA (e.g., AP STA, non-AP STA, AP MLD, non-AP MLD) of the present specification can transmit and/or receive the PPDU of FIG. 5.
  • the PPDU described in the present specification may have, for example, the structure of FIG. 5.
  • the PPDU described in the present specification may be called by various names such as a transmission PPDU, a reception PPDU, a first type PPDU, or an Nth type PPDU, etc.
  • the PPDU described in the present specification can be used in a WLAN system defined according to IEEE 802.11bn and/or a next-generation WLAN system that improves IEEE 802.11bn.
  • the PPDU of FIG. 5 may be related to various PPDU types used in a UHR system.
  • the example of FIG. 5 may be used for at least one of a single-user (SU) mode/type/transmission, a multi-user (MU) mode/type/transmission, and a null data packet (NDP) mode/type/transmission related to channel sounding.
  • SU single-user
  • MU multi-user
  • NDP null data packet
  • the PPDU of FIG. 5 is used for a trigger-based (TB) mode
  • the UHR-SIG of FIG. 5 may be omitted.
  • an STA that has received a trigger frame for UL-MU (Uplink-MU) communication may transmit a PPDU with the UHR-SIG omitted in the example of FIG. 5.
  • L-STF or UHR-LTF may be called a preamble or physical preamble, and may be generated/transmitted/received/acquired/decoded in the physical layer (included in the transmitting/receiving STA).
  • Each block illustrated in Fig. 5 may be called a field/subfield/signal, etc.
  • the names of these fields/subfields/signals may be, as illustrated in Fig. 5, L-STF (legacy short training field), L-LTF (legacy long training field), L-SIG (legacy signal), RL-SIG (repeated L-SIG), U-SIG (Universal Signal), UHR-SIG (UHR-signal), etc.
  • the subcarrier spacing of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields in FIG. 5 may be set to 312.5 kHz, and the subcarrier spacing of the UHR-STF, UHR-LTF, and Data fields may be set to 78.125 kHz. That is, the tone index (or subcarrier index) of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields may be expressed in units of 312.5 kHz, and the tone index (or subcarrier index) of the UHR-STF, UHR-LTF, and Data fields may be expressed in units of 78.125 kHz.
  • L-LTF and L-STF may be identical to conventional fields (e.g., non-HT LTF and non-HT STF defined in conventional WLAN standards).
  • the L-SIG field of FIG. 5 may include, for example, 24 bits of bit information.
  • the 24 bits of information may include a 4 bit Rate field, a 1 bit Reserved bit, a 12 bit Length field, a 1 bit Parity bit, and a 6 bit Tail bit.
  • the 12 bit Length field may include information about the length or time duration of the PPDU.
  • the value of the 12 bit Length field may be determined based on the type of the PPDU.
  • the value of the Length field may be determined as a multiple of 3. For example, if the PPDU is a HE PPDU, the value of the Length field may be determined as "a multiple of 3 + 1" or "a multiple of 3 + 2".
  • the value of the Length field can be determined as a multiple of 3
  • the value of the Length field can be determined as "a multiple of 3 + 1" or "a multiple of 3 + 2".
  • the Length field in an UHR PPDU is set to a value satisfying the condition that the remainder is zero when LENGTH is divided by 3.
  • (non-AP and AP) STAs can apply BCC encoding based on a code rate of 1/2 to the 24 bits of information in the L-SIG field. Then, the transmitting STA can obtain 48 BCC coded bits. BPSK modulation can be applied to the 48 coded bits to generate 48 BPSK symbols. The transmitting STA can map the 48 BPSK symbols to positions excluding the pilot subcarriers ⁇ subcarrier index -21, -7, +7, +21 ⁇ and the DC subcarrier ⁇ subcarrier index 0 ⁇ .
  • the 48 BPSK symbols can be mapped to subcarrier indices -26 to -22, -20 to -8, -6 to -1, +1 to +6, +8 to +20, and +22 to +26.
  • the transmitting STA can additionally map the signal ⁇ -1, -1, -1, 1 ⁇ to the subcarrier indices ⁇ -28, -27, +27, +28 ⁇ .
  • the above signal can be used for channel estimation for the frequency domain corresponding to ⁇ -28, -27, +27, +28 ⁇ .
  • (non-AP and AP) STA can generate RL-SIG, which is generated in the same manner as L-SIG. BPSK modulation can be applied to RL-SIG.
  • Receiving (non-AP and AP) STA can determine whether the received PPDU is a HE PPDU, EHT PPDU, or UHR PPDU based on the presence of RL-SIG. In other words, if RL-SIG is present, receiving (non-AP and AP) STA can determine whether the received PPDU is one of HE PPDU, EHT PPDU, or UHR PPDU.
  • receiving (non-AP and AP) STA can determine whether the received PPDU is one of non-HT PPDU, HT PPDU, or VHT PPDU.
  • the RL-SIG field is a repeat of the L-SIG field and is used to differentiate an UHR PPDU from a non-HT PPDU, HT PPDU, and VHT PPDU.
  • U-SIG Universal SIG
  • the U-SIG may be called by various names such as the first SIG field, the first SIG, the first type SIG, the control signal, the control signal field, the first (type) control signal, the common control field, and the common control signal.
  • a U-SIG can contain N bits of information and can include information for identifying the type of EHT PPDU.
  • a U-SIG can be formed based on two symbols (e.g., two consecutive OFDM symbols). Each symbol (e.g., an OFDM symbol) for a U-SIG can have a duration of 4 microseconds.
  • Each symbol of a U-SIG can be used to transmit 26 bits of information. For example, each symbol of a U-SIG can be transmitted and received based on 52 data tones and 4 pilot tones.
  • a bit information (e.g., 52 uncoded bits) can be transmitted through U-SIG, and the first symbol of U-SIG can transmit the first X bits of information (e.g., 26 uncoded bits) out of the total A bit information, and the second symbol of U-SIG can transmit the remaining Y bits of information (e.g., 26 uncoded bits) out of the total A bit information.
  • the transmitting STA can obtain 26 uncoded bits included in each U-SIG symbol.
  • the transmitting STA can perform BPSK modulation on the interleaved 52 coded bits to generate 52 BPSK symbols allocated to each U-SIG symbol.
  • a single U-SIG symbol can be transmitted based on 56 tones (subcarriers) from subcarrier index -28 to subcarrier index +28, excluding DC index 0.
  • the 52 BPSK symbols generated by the transmitting STA can be transmitted based on the remaining tones (subcarriers) excluding the pilot tones -21, -7, +7, and +21.
  • a bit information (e.g., 52 uncoded bits) transmitted by U-SIG may include a CRC field (e.g., a 4-bit long field) and a tail field (e.g., a 6-bit long field).
  • the CRC field and the tail field may be transmitted through the second symbol of the U-SIG.
  • the CRC field may be generated based on 26 bits allocated to the first symbol of the U-SIG and the remaining 16 bits excluding the CRC/tail field within the second symbol, and may be generated based on a conventional CRC calculation algorithm.
  • the tail field may be used to terminate the trellis of the convolutional decoder and may be set to, for example, "000000".
  • the A bit information (e.g., 52 uncoded bits) transmitted by the U-SIG (or U-SIG field) can be divided into version-independent bits and version-dependent bits.
  • the size of the version-independent bits can be fixed or variable.
  • the version-independent bits can be assigned only to the first symbol of the U-SIG, or the version-independent bits can be assigned to both the first symbol and the second symbol of the U-SIG.
  • the version-independent bits and the version-dependent bits can be called by various names, such as the first control bit and the second control bit.
  • the version-independent bits of the U-SIG may include a 3-bit PHY version identifier.
  • the 3-bit PHY version identifier may include information related to the PHY version of the transmitted and received PPDU. For example, a first value (e.g., a value of 000) of the 3-bit PHY version identifier may indicate that the transmitted and received PPDU is an EHT PPDU.
  • a second value (e.g., a value of 001) of the 3-bit PHY version identifier may indicate that the transmitted and received PPDU is an UHR PPDU.
  • the (AP/non-AP) STA when the (AP/non-AP) STA transmits an EHT PPDU, it can set the 3-bit PHY version identifier to the first value. In other words, the receiving (AP/non-AP) STA can determine that the received PPDU is an EHT PPDU based on the PHY version identifier having the first value, and can determine that the received PPDU is an UHR PPDU based on the PHY version identifier having the second value.
  • the version-independent bits of U-SIG may include a 1-bit UL/DL flag field.
  • the first value of the 1-bit UL/DL flag field relates to UL communication
  • the second value of the UL/DL flag field relates to DL communication.
  • the version-independent bits of U-SIG may include information about the length of a transmission opportunity (TXOP) and information about the BSS color ID.
  • TXOP transmission opportunity
  • a UHR PPDU is classified into various types (e.g., a type related to SU transmission (performed based on UL or DL), a type related to DL transmission, a type related to NDP transmission, a type related to DL non-MU-MIMO, a type related to DL MU-MIMO, a type related to Multi-AP operation, a type related to CBF (Coordinated beamforming), SR (Spatial Reuse), a type related to C-OFDMA (Coordinated OFDMA), a type related to C-TDMA (Coordinated TDMA)), information about the type of the EHT PPDU (e.g., 2-bit or 3-bit information) can be included in the version-dependent bits of the U-SIG.
  • various types e.g., a type related to SU transmission (performed based on UL or DL), a type related to DL transmission, a type related to NDP transmission, a type related to DL non-MU-MIMO,
  • a U-SIG may include information about 1) a bandwidth field including information about a bandwidth, 2) a field including information about an MCS technique applied to the UHR-SIG, 3) an indication field including information about whether a dual subcarrier modulation (DCM) technique is applied to the UHR-SIG, 4) a field including information about the number of symbols used for the UHR-SIG, 5) a field including information about whether the UHR-SIG is generated over the entire band, 6) a field including information about the type of UHR-LTF/STF, and 7) a field indicating the length of the UHR-LTF and the CP length.
  • DCM dual subcarrier modulation
  • Preamble puncturing may be applied to the PPDU of FIG. 5.
  • Preamble puncturing refers to applying puncturing to a portion of the entire bandwidth of the PPDU (e.g., the secondary 20 MHz band). For example, when an 80 MHz PPDU is transmitted, the STA applies puncturing to the secondary 20 MHz band within the 80 MHz band, and can transmit the PPDU only through the primary 20 MHz band and the secondary 40 MHz band.
  • the pattern of preamble puncturing can be preset. For example, when the first puncturing pattern is applied, puncturing can be applied only to the secondary 20 MHz band within the 80 MHz band. For example, when the second puncturing pattern is applied, puncturing can be applied only to one of the two secondary 20 MHz bands included in the secondary 40 MHz band within the 80 MHz band. For example, when the third puncturing pattern is applied, puncturing can be applied only to the secondary 20 MHz band included in the primary 80 MHz band within the 160 MHz band (or 80+80 MHz band).
  • a primary 40 MHz band included in the primary 80 MHz band within the 160 MHz band may be present, and puncturing may be applied to at least one 20 MHz channel that does not belong to the primary 40 MHz band.
  • Information regarding preamble puncturing applied to the PPDU may be included in the U-SIG and/or UHR-SIG.
  • the first field of the U-SIG may include information regarding the contiguous bandwidth of the PPDU
  • the second field of the U-SIG may include information regarding preamble puncturing applied to the PPDU.
  • U-SIG and UHR-SIG may include information regarding preamble puncturing based on the following method. If the bandwidth of the PPDU exceeds 80 MHz, the U-SIG may be individually configured in units of 80 MHz. For example, if the bandwidth of the PPDU is 160 MHz, the PPDU may include a first U-SIG for the first 80 MHz band and a second U-SIG for the second 80 MHz band. In this case, the first field of the first U-SIG may include information regarding the 160 MHz bandwidth, and the second field of the first U-SIG may include information regarding preamble puncturing applied to the first 80 MHz band (i.e., information regarding the preamble puncturing pattern).
  • the first field of the second U-SIG may include information about a 160 MHz bandwidth
  • the second field of the second U-SIG may include information about preamble puncturing applied to the second 80 MHz band (i.e., information about a preamble puncturing pattern).
  • the UHR-SIG consecutive to the first U-SIG may include information about preamble puncturing applied to the second 80 MHz band (i.e., information about a preamble puncturing pattern)
  • the UHR-SIG consecutive to the second U-SIG may include information about preamble puncturing applied to the first 80 MHz band (i.e., information about a preamble puncturing pattern).
  • U-SIG and UHR-SIG may include information regarding preamble puncturing based on the following methods.
  • U-SIG may include information regarding preamble puncturing for all bands (i.e., information regarding preamble puncturing patterns). That is, UHR-SIG may not include information regarding preamble puncturing, and only U-SIG may include information regarding preamble puncturing (i.e., information regarding preamble puncturing patterns).
  • U-SIGs can be configured in 20 MHz units. For example, if an 80 MHz PPDU is configured, U-SIGs can be duplicated. That is, four identical U-SIGs can be included within an 80 MHz PPDU. PPDUs exceeding the 80 MHz bandwidth can contain different U-SIGs.
  • the UHR-SIG of FIG. 5 may include control information for a receiving STA.
  • the UHR-SIG may be transmitted via at least one symbol, and each symbol may have a length of 4 us. Information regarding the number of symbols used for the UHR-SIG may be included in the U-SIG.
  • UHR-SIG provides additional signals to the U-SIG field to enable STAs to interpret/decode UHR PPDUs.
  • the UHR-SIG field may include U-SIG overflow bits that are common to all users.
  • the UHR-SIG field also contains resource allocation information, allowing STAs to look up resources used in fields containing data fields/UHR-STF/UHR-LTF (i.e., UHR modulated fields of an UHR PPDU).
  • the frequency resources of the UHR-LTF, UHR-STF, and data fields illustrated in FIG. 5 can be determined based on RUs (resource units) defined by multiple subcarriers/tones. That is, the UHR-LTF, UHR-STF, and data fields of this specification can be transmitted/received through RUs (resource units) defined by multiple subcarriers/tones.
  • FIG. 6 is a diagram illustrating the layout of resource units (RUs) used for a 20 MHz PPDU. That is, the UHR-LTF, UHR-STF, and/or data fields included in the 20 MHz PPDU can be transmitted/received through at least one of the various RUs defined in FIG. 6.
  • RUs resource units
  • 26 units i.e., units corresponding to 26 tones
  • Six tones can be used as a guard band in the leftmost band of the 20 MHz band, and five tones can be used as a guard band in the rightmost band of the 20 MHz band.
  • seven DC tones can be inserted in the center band, i.e., the DC band, and 26 units corresponding to 13 tones can exist on each side of the DC band.
  • 26 units, 52 units, and 106 units can be allocated to other bands. Each unit can be allocated for a receiving station, i.e., a user.
  • the RU arrangement of FIG. 6 is utilized not only in a situation for multiple users (MUs) but also in a situation for a single user (SU), in which case it is possible to use one 242-unit as shown at the bottom of FIG. 4, in which case three DC tones can be inserted.
  • RUs of various sizes such as 26-RU, 52-RU, 106-RU, and 242-RU, are proposed. Since the specific sizes of these RUs can be expanded or increased, the present embodiment is not limited to the specific size of each RU (i.e., the number of corresponding tones).
  • N-RU may be represented as N-tone RU, etc.
  • 26-RU may be represented as 26-tone RU.
  • Figure 7 is a diagram showing the layout of resource units (RUs) used for 40MHz PPDU.
  • the example of Fig. 7 can also use 26-RU, 52-RU, 106-RU, 242-RU, 484-RU, etc.
  • 5 DC tones can be inserted at the center frequency
  • 12 tones can be used as a guard band in the leftmost band of the 40 MHz band
  • 11 tones can be used as a guard band in the rightmost band of the 40 MHz band.
  • 484 RUs may be used when used for a single user. Meanwhile, the specific number of RUs may be changed, as in the example of FIG. 6.
  • Figure 8 is a diagram illustrating the layout of resource units (RUs) used for an 80MHz PPDU.
  • the layout of resource units (RUs) used in this specification may vary.
  • the layout of resource units (RUs) used in the 80MHz band may vary.
  • Figure 9 illustrates an operation according to UL-MU.
  • a transmitting STA e.g., AP
  • a TB (trigger-based) PPDU is transmitted after a delay of SIFS.
  • TB PPDUs (941, 942) are transmitted at the same time and can be transmitted from multiple STAs (e.g., User STAs) whose AIDs are indicated in the Trigger frame (930).
  • the ACK frame (950) for the TB PPDU can be implemented in various forms.
  • Figure 10 shows an example of channels used/supported/defined within the 2.4 GHz band.
  • the 2.4 GHz band may be referred to by other names, such as the first band (band). Furthermore, the 2.4 GHz band may refer to a frequency range in which channels with a center frequency adjacent to 2.4 GHz (e.g., channels with a center frequency between 2.4 and 2.5 GHz) are used/supported/defined.
  • the 2.4 GHz band may include multiple 20 MHz channels.
  • the 20 MHz within the 2.4 GHz band may have multiple channel indices (e.g., indices 1 through 14).
  • the center frequency of a 20 MHz channel assigned channel index 1 may be 2.412 GHz
  • the center frequency of a 20 MHz channel assigned channel index 2 may be 2.417 GHz
  • the center frequency of a 20 MHz channel assigned channel index N may be (2.407 + 0.005*N) GHz.
  • the channel indices may be referred to by various names, such as channel numbers. The specific numerical values of the channel indices and center frequencies may change.
  • Figure 10 exemplarily illustrates four channels within the 2.4 GHz band.
  • the illustrated first frequency region (1010) to fourth frequency region (1040) may each include one channel.
  • the first frequency region (1010) may include channel 1 (a 20 MHz channel having an index of 1).
  • the center frequency of channel 1 may be set to 2412 MHz.
  • the second frequency region (1020) may include channel 6.
  • the center frequency of channel 6 may be set to 2437 MHz.
  • the third frequency region (1030) may include channel 11.
  • the center frequency of channel 11 may be set to 2462 MHz.
  • the fourth frequency region (1040) may include channel 14. In this case, the center frequency of channel 14 may be set to 2484 MHz.
  • Figure 11 illustrates an example of channels used/supported/defined within the 5 GHz band.
  • the 5 GHz band may be referred to by other names, such as a second band/band, etc.
  • the 5 GHz band may refer to a frequency range in which channels with a center frequency greater than or equal to 5 GHz and less than 6 GHz (or less than 5.9 GHz) are used/supported/defined.
  • the 5 GHz band may include multiple channels between 4.5 GHz and 5.5 GHz.
  • the specific figures shown in FIG. 11 are subject to change.
  • UNII-1 may be referred to as UNII Low.
  • UNII-2 may include frequency ranges called UNII Mid and UNII-2Extended.
  • UNII-3 may be referred to as UNII-Upper.
  • multiple channels can be configured, and the bandwidth of each channel can be variously configured, such as 20 MHz, 40 MHz, 80 MHz, or 160 MHz.
  • the 5170 MHz to 5330 MHz frequency domain/range within UNII-1 and UNII-2 can be divided into eight 20 MHz channels.
  • the 5170 MHz to 5330 MHz frequency domain/range can be divided into four channels through a 40 MHz frequency domain.
  • the 5170 MHz to 5330 MHz frequency domain/range can be divided into two channels through an 80 MHz frequency domain.
  • the 5170 MHz to 5330 MHz frequency domain/range can be divided into one channel through a 160 MHz frequency domain.
  • Figure 12 illustrates an example of channels used/supported/defined within the 6 GHz band.
  • the 6 GHz band may also be referred to by other names, such as the third band/band.
  • the 6 GHz band may refer to the frequency range in which channels with center frequencies above 5.9 GHz are used, supported, or defined.
  • the specific figures shown in Figure 12 are subject to change.
  • the 20 MHz channel of FIG. 12 can be defined from 5.940 GHz.
  • the leftmost channel among the 20 MHz channels of FIG. 12 can have an index of 1 (or channel index, channel number, etc.), and a center frequency of 5.945 GHz can be assigned. That is, the center frequency of the indexed channel N can be determined as (5.940 + 0.005*N) GHz.
  • the indexes (or channel numbers) of the 20 MHz channels of FIG. 12 are 1, 5, 9, 13, 17, 21, 25, 29, 33, 37, 41, 45, 49, 53, 57, 61, 65, 69, 73, 77, 81, 85, 89, 93, 97, 101, 105, 109, 113, 117, 121, 125, 129, 133, 137, 141, 145, 149, 153, 157, 161, 165, 169, 173, 177, 181, 185, 189, 193, It can be 197, 201, 205, 209, 213, 217, 221, 225, 229, 233.
  • the indices of the 40 MHz channels in Fig. 12 can be 3, 11, 19, 27, 35, 43, 51, 59, 67, 75, 83, 91, 99, 107, 115, 123, 131, 139, 147, 155, 163, 171, 179, 187, 195, 203, 211, 219, 227.
  • Fig. 13 illustrates an example of a header of a MAC frame.
  • the MAC frame may include a frame control field/information of 2 octets in length, a duration field/information of 2 octets in length, a RA (Receiver Address) field/information of 6 octets in length, and a TA (Transmitter Address) field/information of 6 octets in length.
  • the four fields may be consecutive to each other.
  • the MAC header of Fig. 13 may be modified in various ways, and a new field may be inserted between the four illustrated fields, or at least one of the illustrated fields may be omitted.
  • the MAC header illustrated in Fig. 13 may be positioned at the very front of a MAC frame. That is, the MAC frame may include a MAC header as illustrated in Fig. 13 and MAC body fields/information subsequent to the MAC header.
  • the MAC frame including the MAC header of Fig. 13 is inserted/included in the data field of the PPDU (e.g., UHR PPDU) illustrated in Fig. 5.
  • the PPDU e.g., UHR PPDU
  • the MAC frames included in the data field of the PPDU of this specification can be classified into various types.
  • the MAC frames of this specification can be classified into control frames, management frames, and data frames.
  • the management frame includes Association Request, Association Response, Reassociation Request, Reassociation Response, Probe Request, Probe Response, Beacon, Disassociation, Authentication, and Deauthentication frames/signals defined in conventional WLAN.
  • the values of the type fields (B3 and B2) in FIG. 13 are set to 00.
  • the values of the subtype fields (B7, B6, B5, B4) in FIG. 13 are as follows: Association Request (0000), Association Response (0001), Reassociation Request (0010), Reassociation Response (0011), Probe Request (0100), Probe Response (0101), Beacon (1000), Disassociation (1010), Authentication (1011), Deauthentication (1100).
  • control frame includes Trigger Beamforming Report Poll, NDP Announcement (NDPA), Control Frame Extension, Control Wrapper, Block Ack Request (BlockAckReq), Block Ack (BlockAck), PS-Poll, RTS, CTS, Ack, and CF-End frames/signals defined in conventional WLAN.
  • NDPA NDP Announcement
  • BlockAckReq Block Ack Request
  • BlockAck BlockAck
  • PS-Poll RTS
  • CTS CTS
  • Ack CF-End frames/signals defined in conventional WLAN.
  • the values of the type fields (B3 and B2) in FIG. 13 are set to 01.
  • Trigger (0010), Beamforming Report Poll (0100), NDP Announcement (0101), Control Frame Extension (0110), Control Wrapper (0111), BlockAckReq (1000), BlockAck (1001), PS-Poll (1010), RTS (1011), CTS (1100), Ack (1101), CF-End (1110).
  • the data frame includes (QoS) Data, (QoS) Null, etc. defined in conventional WLAN.
  • the value of the type field (B3 and B2) of Fig. 13 is set to 10.
  • the MAC frame/signal used in this specification can be identified through the type field/information and subtype field/information described above.
  • “frame” in this specification can mean a MAC frame in which the type bits B3 and B2 bits in the frame control field of the MAC header are set to 01, and the subtype bits B7, B6, B5, and B4 bits in the frame control field are set to 0010.
  • Various MAC frames described in this specification are inserted/included in the data fields of various PPDUs (e.g., HE/VHT/HE/EHT/UHR PPDUs).
  • FIG. 14 illustrates a modified example of a transmitting device and/or a receiving device of the present specification.
  • the devices (e.g., AP STA, non-AP STA) illustrated in FIGS. 1 to 4 may be modified as illustrated in FIG. 14.
  • the transceiver (630) of FIG. 14 may be identical to the transceivers (113, 123) of FIG. 1.
  • the transceiver (630) of FIG. 14 may include a receiver and a transmitter.
  • the processor (610) of FIG. 14 may be identical to the processor (111, 121) of FIG. 1. Alternatively, the processor (610) of FIG. 14 may be identical to the processing chip (114, 124) of FIG. 1.
  • the memory (150) of FIG. 14 may be the same as the memory (112, 122) of FIG. 1. Alternatively, the memory (150) of FIG. 14 may be a separate external memory different from the memory (112, 122) of FIG. 1.
  • a power management module (611) manages power to a processor (610) and/or a transceiver (630).
  • a battery (612) supplies power to the power management module (611).
  • a display (613) outputs results processed by the processor (610).
  • a keypad (614) receives input to be used by the processor (610). The keypad (614) may be displayed on the display (613).
  • a SIM card (615) may be an integrated circuit used to securely store an international mobile subscriber identity (IMSI) and an associated key used to identify and authenticate a subscriber in a mobile phone device, such as a mobile phone or computer.
  • IMSI international mobile subscriber identity
  • the speaker (640) can output sound-related results processed by the processor (610).
  • the microphone (641) can receive sound-related input to be used by the processor (610).
  • FIG 15 illustrates an over-the-air (OTA) FT protocol in a Robust Security Network (RSN).
  • OTA over-the-air
  • RSN Robust Security Network
  • FT Fast BSS Transition
  • an STA performing BSS Transition i.e., Roaming
  • an RSTA the AP to which the STA is currently associated when roaming
  • an Old AP O_AP
  • N_AP New AP
  • the Roaming method proposed in this specification is referred to as MLD Roaming.
  • the designations (names) in this specification may be changed, and an STA may include an AP STA or a non-AP STA.
  • Figure 16 illustrates the high-level architecture for AP MLD.
  • an AP MLD can include one or more APs and has a high-level architecture as shown in Figure 16.
  • the MLD can control several procedures/parameters common to multiple APs using the upper MAC sublayer. Examples of these procedures/parameters include authentication, association, SN/PN assignment, and power-save buffering of individually addressed frames.
  • MLD-level parameters can be maintained without being reset when moving between APs (affiliated APs) involved in AP MLD.
  • This specification proposes a roaming method utilizing AP MLD functionality.
  • Figure 17 illustrates an example of a high-level architecture for UHR AP MLD.
  • FIG 17 illustrates the architecture of APs supporting Seamless Roaming.
  • devices To support Seamless Roaming, devices must be compatible with previous standard versions and enable seamless roaming between multiple devices.
  • non-UHR non-AP STAs must be able to see non-UHR APs. This requires maintaining the MLD definition itself and preserving the existing architecture. Therefore, as shown in Figure 17, we define a new UHR AP MLD that maintains the existing MLD architecture while hierarchically affiliates MLDs that support seamless roaming.
  • Each LMAC of the AP MLDs interfaces with a UHR UMAC, and the functions of the UMAC of the AP MLD that supports seamless roaming are managed by the UHR UMAC.
  • a separate entity can manage various functions for roaming between AP MLDs (e.g., multi-link authentication (e.g., PTK), multi-link discovery/setup, multi-link reconfiguration). That is, this specification does not limit roaming support to UMAC.
  • An example of such a case is shown in Fig. 18.
  • An entity can manage the control plane context and other things as needed.
  • AP MLDs and UHR AP MLDs are each individually connected to a DS (Distribution System).
  • This architecture can also solve the scalability issue caused by the limitation of the bit size of the Link ID. Basically, the Link ID is 4 bits, and only a maximum of 16 Link IDs can be supported.
  • This Link ID is required to move from one link to another during roaming, but the existing method limits the number of APs that can roam to 16. To solve this, the Link ID is tied to the AP MLD ID, thereby resolving the scalability issue. This is described in more detail in 2.2 below.
  • Figure 18 illustrates another example of a high-level architecture for UHR AP MLD.
  • Figure 19 illustrates another example of the High-level Architecture for UHR AP MLD.
  • Figure 19 shows an example with a similar architecture to Figure 17 but with different interfacing.
  • Figure 18 shows that the LMAC of the AP MLD and the UHR UMAC are not directly connected, but are interfaced to the TID-to-Link Mapping function of the UMAC.
  • This architecture allows for TID-to-Link Mapping to be performed individually in the UMAC of the AP MLD or in the UHR UMAC.
  • the AP MLD and the UHR AP MLD are each individually connected to the DS.
  • the method of use of this architecture and the types and number of functions that interface with the UHR UMAC are not limited.
  • Figure 20 illustrates an example of a high-level architecture in the case where there are only entities that are not MLD-based.
  • Figure 21 illustrates another example of a High-level Architecture in the case of entities that are not MLD-based.
  • AP MLDs capable of roaming are connected to a single entity and can perform association, authentication, link setup, and other operations with this entity.
  • the entity also manages control plane contexts.
  • AP MLDs capable of roaming can be grouped under the concept of a domain, and one or more entities can exist within a domain. It manages contexts that must be shared between APs for non-AP STAs to perform seamless roaming.
  • Figure 22 illustrates an example of a Roaming Architecture in an AP MLD area.
  • Figure 22 shows the structure and process for basic Roaming.
  • Each AP MLD is in a different location (i.e., non-collocated), and the APs belonging to each AP MLD are in the same or similar locations (i.e., collocated).
  • This collocated may mean belonging to the exact same physical device, or it may mean belonging to a logically similar location even if it does not belong to a physical device.
  • an AP MLD is a logical entity, it can be any physical device, but regardless of location, it can operate as an MLD that includes affiliated APs and can apply multi-link operation (MLO).
  • MLO multi-link operation
  • all APs belonging to each AP MLD become affiliated APs of one AP MLD.
  • AP MLD 1 in Figure 22 includes affiliated APs 1, 2, and 3.
  • a non-AP MLD when a non-AP MLD moves, it will typically roam from one AP MLD to another.
  • a non-AP MLD is configured with a multi-link setup with an AP MLD, and STA 1 and STA 2 are connected to AP 2 and AP 3 of AP MLD 1, when roaming to AP MLD 2, STA 1 may be connected to AP 4 and STA 2 may be connected to AP 5.
  • each STA may temporarily associate with AP 4 and AP 5 so that AP 4 and AP 5 can transmit frames to each STA during the roaming process.
  • this architecture can be applied to a non-AP MLD with one affiliated STA, not a non-AP MLD with multiple affiliated STAs, or a non-AP STA that is not an MLD.
  • roaming does not necessarily only involve moving between different AP MLDs.
  • roaming can also involve changing APs within an AP MLD.
  • a UHR AP MLD (or roaming-capable group) is affiliated with at least one (EHT) AP MLD, each AP MLD is non-collocated, and the APs belonging to each AP MLD are collocated.
  • EHT roaming-capable group
  • a non-AP MLD (or STA) roams from one AP MLD to another (although roaming can also change APs within a specific AP MLD).
  • Roaming can be considered as a way to change links while maintaining the Multi-link Setup without completely tearing down the existing Multi-link Setup.
  • Each AP in the AP MLD announces to STAs whether it can perform MLD Roaming as proposed in this specification and information related to roaming APs within the AP MLD.
  • Frame exchange process This is the process of exchanging frames that can trigger MLD roaming. Once frame exchange is complete, MLD roaming is completed based on the negotiated information, and operations with the O_AP are no longer performed, but rather with the N_AP.
  • this specification proposes to use the following method for MLD Roaming.
  • One or more STAs belonging to a non-AP MLD can establish multiple links, each with a single radio. Therefore, we propose a method where a single STA adds and deletes links. This allows two or more links to be connected to a single STA.
  • the non-AP MLD basically informs whether it is capable of the above-described capabilities in the Association Request frame during ML setup, i.e., when transmitting a Management frame containing the Basic Multi-link ML IE.
  • This can be included in the MLD Capabilities and Operations subfield of the Common Info field if all STAs are capable, or in the Link Info field if only some STAs are capable.
  • the information to be included is as follows:
  • Single-radio ML setup enabled This information indicates that STAs in a non-AP MLD can each have one radio and set up multiple links. This means that more than two links can be connected to one STA.
  • Each AP of each AP MLD can announce whether the roaming proposed in this specification is possible (i.e., whether the frame exchange b) described above is possible).
  • Information that can be commonly conveyed to all APs can be whether the AP belongs to a UHR AP MLD or Entity, and more specifically, which UHR AP MLD/Entity it belongs to and collocation information, etc. If it is an architecture type that is affiliated with a UHR AP MLD, whether it is affiliated with a UHR AP MLD and UHR AP MLD ID information can be used, and if it is an architecture type that uses an Entity, whether it is connected to an Entity and information identifying the Entity, such as the Entity ID, can be included.
  • the relevant information is as follows, and at least one or more can be included.
  • - MLD Roaming enabled Indicates whether roaming is possible (e.g., can be indicated by 1 bit). Roaming is possible when affiliated with the same UHR AP MLD or connected to the same entity. If the AP is affiliated with a different UHR AP MLD or another entity (i.e., an AP belonging to a different mobility domain), roaming is not possible, and this can be indicated with the MLR Roaming enabled bit.
  • UHR AP MLD ID/Entity ID An ID that identifies the UHR AP MLD or entity presented above.
  • the configuration for this UHR AP MLD ID/Entity ID is as follows.
  • UHR AP MLD ID an ID to the UHR AP MLD that is affiliated with the collocated AP MLDs. This is referred to as the UHR AP MLD ID in this specification.
  • This UHR AP MLD ID can be unique within the UHR AP MLD or can be assigned a unique ID to the UHR AP MLD within the entire network.
  • UHR AP MLD IDs can be assigned values such as 0, 1, 2, etc.
  • a 4-bit UHR AP MLD ID can have values from 0 to 15, while an 8-bit UHR AP MLD ID can have values from 0 to 127. This size can be modified. The following explains the meaning of each UHR AP MLD ID.
  • the UHR AP MLD ID is 0: In this case, it can be known that the APs with this UHR AP MLD ID correspond to APs belonging to an AP MLD within the same UHR AP MLD. That is, when a non-AP MLD (or STA) recognizes this, it can recognize that the APs currently belong to the same UHR AP MLD. Therefore, roaming is possible only when the UHR AP MLD ID is 0.
  • UHR AP MLD IDs are mapped to uniquely identify each UHR AP MLD.
  • Temporary link addition/deletion Indicates whether a link can be temporarily added or removed for an STA. This means that one STA can have two or more links for a certain period of time (e.g., indicated by 1 bit).
  • Collocation enabled 1
  • it means that the AP and the reporting AP are physically close. Therefore, you can communicate with the existing connected AP without moving to the AP set to 1. Therefore, if a neighboring AP has Collocation enabled set to 1, you can avoid roaming. In other words, MLD Roaming Request/Response is not sent or received to an AP with Collocation enabled 1.
  • Collocation ID An ID that distinguishes collocated AP MLDs.
  • the configuration for this Collocation ID is as follows.
  • collocation ID can be unique within a group of collocated AP MLDs or can be assigned a unique ID to a collocated AP MLD within a UHR AP MLD.
  • Collocation IDs can be assigned values such as 0, 1, 2, etc.
  • a 4-bit collocation ID can have values from 0 to 15, while an 8-bit collocation ID can have values from 0 to 127. This size can be changed. The following explains the meaning of each collocation ID.
  • APs with this Collocation ID can be considered as APs belonging to the same collocated AP MLD group. That is, if the MLD (or STA) recognizes this, it can recognize that the APs are currently collocated.
  • other APs transmitted BSSID (TxBSSID) or nontransmitted BSSID (NonTxBSSID)
  • TxBSSID transmitted BSSID
  • NonTxBSSID nontransmitted BSSID
  • the AP MLD ID of the AP MLD to which these APs belong may be different.
  • Multiple AP MLDs can be included within a set of APs with the same Collocation ID.
  • Collocation IDs are mapped to uniquely identify each collocated AP MLD group.
  • Collocation IDs can be assigned values such as 0, 1, 2, etc.
  • a 4-bit collocation ID can have values from 0 to 15, while an 8-bit collocation ID can have values from 0 to 127, and this size can be changed.
  • the above information can be included in the Management (MGMT) frame such as Beacon or Probe Response, and can be included in the MLD Roaming IE containing new MLD Roaming information or the existing Reduced Neighbor Report (RNR) IE (Information Element).
  • MLD Roaming parameters include at least one of the fields added in FIGS. 23 and 24 and can be included as in FIGS. 23 and 24. In addition to FIGS. 23 and 24, at least one of all fields defined in this specification is included.
  • Figure 23 shows an example of an RNR IE.
  • Figure 24 shows another example for the RNR IE.
  • Non-AP STAs send and receive MLD Roaming Request/Response only to APs with Collocation ID ⁇ via RNR IE.
  • the size of the existing MLD Parameters subfield is not sufficient, as shown in FIGS. 23 and 24, a new MLD Roaming Parameters subfield can be created in the RNR IE to contain information. While the existing size can be changed, this has the problem that it may cause decoding issues for 802.11be STAs. In this case, the MLD Roaming Parameters subfield may not include MLD Roaming Enabled because the inclusion of MLD Roaming Parameters itself may indicate that MLD Roaming is possible.
  • the RNR IE can reduce overhead by only sending information such as whether another AP is collocated or non-collocated with the AP currently sending a Beacon or Probe Response in the Collocation Enabled field, as shown in Fig. 23. Furthermore, it can also indicate which AP is included in which collocation set by providing the AP's Collocation ID, as shown in Fig. 24.
  • the RNR IE can include either the Collocation Enabled field or the Collocation ID, or both.
  • Figure 25 shows another example for the RNR IE.
  • the MLD Roaming Enabled can be indicated using the existing MLD Parameters subfield. Other information can be included as separate parameters, as in Fig. 23.
  • the non-AP MLD can request information about the APs it wants to roam to through the Multi-Link Probe Request for the enabled APs, and in response, it can inform whether the AP is suitable for roaming through the Multi-Link Probe Response.
  • MLD Roaming enabled 1 can be set.
  • the AP Roaming Recommend enabled field can be added to reduce overhead that may occur when the AP makes unnecessary AP Recommendations.
  • Figure 26 illustrates an example of the AP Roaming Recommendation enabled field and the Roaming Reason Code field in the Common Info field.
  • an STA When an STA requests a recommendation for one or more AP MLDs, it may request recommendations for APs in one or more AP MLDs that are affiliated with the same SMD or UHR AP MLD by not including the AP MLD ID field.
  • a non-AP STA Before roaming, when a non-AP STA sends a list of APs to which it can roam, it can set a Roaming Reason Code to inform the AP of the reason for roaming.
  • the Probe Request Multi-Link element can be added to the Link Reconfiguration Notify Request frame, and the AP can use this Roaming Reason Code as a reference when determining which APs to recommend to the non-AP STA.
  • Roaming Reason Code is present in the Link Reconfiguration Notify Request frame, it is not included in the Probe Request Multi-Link element. If the reason for requesting roaming on all links is the same, it can be included in the Common Info field to reduce overhead.
  • the Roaming Reason Code settings are described in Table 2.
  • the AP Roaming Recommendation enabled Present field can be omitted from the Presence field and the AP Roaming Recommendation enabled field can be added only to the Common Info field.
  • Figure 27 illustrates an example of the AP Roaming Recommendation enabled field in the Link Info field.
  • the Link Info field In the case of including it in the Link Info field, it is when requesting information about APs individually for roaming. If at least one AP is included in the ML Probe Request frame for a different operation than roaming, such as an Association, the AP Roaming Recommendation enabled field can be added to the Link Info.
  • the UHR AP MLD and AP MLD ID in the STA Control field can be used instead of the AP MLD ID in the Common Info field to inform the AP MLDs that recommend one or more AP MLDs.
  • the first method is to check the total number of Per-STA Profiles through the number stored in the Number of Per-STA profile(s) field in the Common Info field. That is, you can know how many Recommended AP MLDs are recommended, and you can know that there are that many Per-STA Profiles. Therefore, you can decode this number of Per-STA Profiles.
  • the second method is to use the More STA Control field of the Per-STA Profile.
  • More STA Control is set to 1, you can know that another Per-STA Profile exists after the Per-STA Profile currently being decoded. If the More STA Control field is 0, you can know that it is the information of the last AP MLD among the Recommended AP MLDs.
  • Link Info field indicates that recommendations are being requested for all STAs affiliated with that non-AP MLD.
  • non-AP MLD can request information about APs it wants to roam to through Multi-Link Probe Request for enabled APs, and in response, it can inform whether the AP is suitable for roaming.
  • the Recommended AP List in the Probe Response framed contains a list of Link IDs for additional APs suitable for roaming.
  • a non-AP MLD can send a Link Reconfiguration Notify Request frame to the UHR AP MLD individually, without waiting for the UHR AP MLD to receive a Link Reconfiguration Notify frame for AP recommendation.
  • the reason for requesting roaming can be notified through the Roaming Reason Code.
  • the settings for the Roaming Reason Code are described in Table 2. If a non-AP STA informs the AP of the reason for roaming in this way, the AP can recommend a more suitable AP. If the Roaming Reason Code is included in the Probe Request Multi-Link element, it is not included in the Link Reconfiguration Notify Request frame. Also, if the reason for roaming is different for each link, it is not included in the Link Reconfiguration Notify Request frame.
  • UHR AP MLDs can use the Link Reconfiguration Notify frame, rather than the ML Probe Request/Response frame, to inform non-AP MLDs of links suitable for roaming.
  • Table 3 shows an example of the format of the Link Reconfiguration Notify frame Action field.
  • the Reconfiguration Multi-link IE defined in the existing 802.11be can be used to provide the information required for link recommendations. While the Reconfiguration ML element can recommend deletion or addition for a single link with a single STA Profile, it cannot recommend multiple links in this case. Therefore, to improve efficiency, one or more STA Profile subelements can be included to provide recommendations for multiple links.
  • the UHR AP MLD can indicate the most suitable AP to move to among the roaming APs. This can be indicated in STA Profile order or through the Add/Delete Link ID list field.
  • STA Profile order the link to be deleted or added can be placed first, followed by the link with the highest preference.
  • the Add/Delete Link ID list field the link to be deleted or added can be placed first in the list of links, followed by the link with the highest preference.
  • a non-AP STA sends a Reconfiguration Notify Request frame first and does not include a Roaming Reason Code, or sends a Reconfiguration Notify frame without receiving a Reconfiguration Notify Request frame, the non-AP STA may send a Reconfiguration Notify frame including a Roaming Reason Code.
  • frame exchange is required between the non-AP MLD (or STA) and the AP MLD.
  • This frame can utilize the MGMT frame, particularly the Action frame, a type of MGMT frame.
  • the frames are referred to as follows:
  • the frame in which the STA requests MLD Roaming to the AP can be called the MLD Roaming Request frame.
  • the frame in which the AP requests MLD Roaming to the STA can be called the MLD Roaming Response frame.
  • the MLD Roaming Request frame format can be configured in the following order:
  • Order 1 Basically, a Category can be included in a new UHR Action or a Protected UHR Action, but is not limited to these.
  • Order 4 The Reconfiguration Multi-link IE defined in the existing 802.11be can be used to provide the information required for MLD Roaming requests.
  • the modified Reconfiguration Multi-link IE is as follows:
  • Order 5 When requesting MLD Roaming, the degree to which context transfer is required or possible can be indicated by setting the bit value of the Context Transfer Level.
  • Figure 28 illustrates an example of the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • the Roaming Reason Code may be included within the Reconfiguration Multi-Link IE. In this case, if the reason for requesting roaming is the same for all links, the Roaming Reason Code is entered in the Common Info field, and the Roaming Reason Code has the value in Table 2.
  • Per-STA Profile subelements may be required.
  • Figure 29 illustrates an example of the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • the information on whether each link is STR (Simultaneous transmission and receive) or NSTR (non-STR) from a non-AP MLD perspective may change, so the NSTR indication bitmap may be included in the STA Info field.
  • the presence or absence of subfields in STA Info can be determined by the Present subfields in STA Control.
  • Link ID is indicated as the Link ID corresponding to N_AP.
  • the Complete Profile refers to the STA's Complete information, i.e., all information included when transmitting an Association Request frame. However, since this is an existing STA moving, not a new STA, the STA's capabilities or operational parameters may not change. Since the AP MLD already knows this, it can be used as an instruction that only includes the changed information, instead of the Complete Profile.
  • the MLD Roaming Timer refers to the time when MLD Roaming is completed, no longer operating with the O_AP, and operating with the N_AP. In other words, it can refer to the remaining time until the expected time to switch to the AP to which to roam. This is related to the TIM field described later in 2.4.
  • the MLD Roaming timer is applied commonly to all APs, it can be included in the Common Info field, unlike in Fig. 23. In this case, the presence or absence of the MLD Roaming timer in the Common Info field can be indicated through the Presence Bitmap.
  • AP MLD ID is the ID of the AP MLD to which the APs to which the non-AP MLD (or STA) will roam belong
  • UHR AP MLD ID is the ID of the UHR AP MLD to which the AP MLDs to which the non-AP MLD (or STA) will roam belong.
  • the UHR AP MLD ID field may not exist in the Reconfiguration Multi-link element.
  • Such cases are described in 1-2) case 2 when included in the Common Info field, 2-2) case 2 when included in the Link Info field - always present, and 3-2) case 2 when included in the Link Info field - not always present.
  • the Reconfiguration Multi-link IE describes the format depending on whether the Reconfiguration Multi-link IE always includes the UHR AP MLD ID, AP MLD ID, and Collocation ID.
  • Figure 30 illustrates an example in which the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes a UHR AP MLD ID and an AP MLD ID.
  • Figure 31 illustrates an example in which an AP MLD ID is included in the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • Figure 32 illustrates an example in which the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes a UHR AP MLD ID and an AP MLD ID.
  • the Link Info field can contain multiple Per-STA Profile subelements, each of which can indicate a roaming request to an AP via its Link ID.
  • the STA Control field of the Per-STA Profile subelement can identify the AP to which the STA wishes to roam via the AP MLD ID and UHR AP MLD ID. This allows roaming requests to multiple APs corresponding to different AP MLD IDs, but when requesting for the same AP MLD ID, the overhead is greater than that indicated via the Common Info field.
  • Figure 33 illustrates an example in which an AP MLD ID is included in the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • Figure 34 illustrates another example in which the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes the UHR AP MLD ID and the AP MLD ID.
  • the inclusion of the UHR AP MLD ID and AP MLD ID corresponding to the AP corresponding to the Link ID can be indicated through the UHR AP MLD ID Present and AP MLD ID Present of the STA Control field of the Per-STA Profile subelement.
  • the UHR AP MLD ID, AP MLD ID, Roaming Recommended List, and Roaming Reason Code can be included in the STA Info field or the STA Profile field. Similarly, this can request information about multiple APs corresponding to multiple AP MLD IDs.
  • the UHR AP MLD ID and AP MLD ID are indicated in Common Info in another way, it may be implicitly recognized that this is a roaming request for APs corresponding to the same UHR AP MLD ID and AP MLD ID, and thus the UHR AP MLD ID, AP MLD ID, Roaming Recommended List, and Roaming Reason Code may not be included. In other words, the UHR AP MLD ID Present field and AP MLD ID Present field may not be included.
  • Figure 35 illustrates another example in which the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes an AP MLD ID.
  • Type can be Type 0: Add / Type 1: Delete / Type 2: Temporary Add / Type 3: Temporary Delete. Temporary Delete can also be replaced with Type 1.
  • Add means that an STA of a non-AP MLD requests an additional link connection with an AP of an AP MLD. Delete means that the currently connected link is disconnected (removed).
  • Temporary Add means that an STA of a non-AP MLD requests an additional connection with an AP other than the currently connected AP so that multiple links can be configured.
  • the Temporary of the Type field above can also be composed of a separate field.
  • Type 4 Add then Delete
  • Type 5 Delete then Add.
  • links corresponding to add are added first, and then links corresponding to delete are deleted.
  • Type 5 first deletes links corresponding to delete, and then links corresponding to add are added.
  • Type 8 is when a Link Switch is performed. Unlike add and delete, a Link Switch allows you to switch a link to another link at once.
  • the Add/Delete Link ID list field is an optional field that can be entered when the Type field is set to 4 or 5.
  • the Link IDs corresponding to this Add/Delete Link ID list include a list of Link IDs of links that request both Add and Delete. For Link Info with a Link ID included in this list, if the Type is add, it indicates that it is an add link among links that both add and delete, and if it is delete, it indicates that it is a delete link.
  • the Type field of Link Info requires a value for both adding and deleting simultaneously, in addition to the value required for simply adding or deleting.
  • the Type field of Link Info can be configured as follows, but the values and settings of the Type field are not limited to the values mentioned.
  • Type 4 is the case of a link being added in an action of adding and then deleting a link
  • Type 5 is the case of a link being deleted in an action of adding and then deleting a link.
  • Type 6 is the case of a link being added in an action of deleting a link and then adding it
  • Type 7 is the case of a link being deleted in an action of deleting a link and then adding it.
  • the above Type field and the above Temporary field can be included as follows, and at least one or more fields are included.
  • Figure 36 illustrates an example in which a Temporary field is included in the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • Figure 37 illustrates an example in which a Temporary field is included in the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • Figure 38 illustrates another example in which a Temporary field is included in the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • Figure 38 is an example in which the Type field is included in Link Info in the case of Link Info in which the UHR AP MLD ID field is omitted.
  • the Link ID of the added link can be placed before the deleted link in the list order. For example, if the Link ID of the added link is 5 and the Link ID of the deleted link is 2, you can set the Add/Delete Link ID List to 5, 2. By setting the order in this way, you can tell which link is added and which link is deleted in Common Info, but since this can also be known through the Type field of the Link Info field, the action of setting the order may not be necessary.
  • the Type of the Link Info field already indicates whether the frame requests Add and Delete individually or simultaneously through Common Info, it is possible to indicate whether the link is being added or deleted using only Type 0 and 1. Alternatively, if the Link IDs are ordered in the Add/Delete Link ID List of Common Info, the overhead can be reduced by omitting the Type field in the Link Info.
  • the link being added is set to Type 4
  • the link being deleted is set to Type 5.
  • the link set to Type 4 is added first, and then the link set to Type 5 is deleted.
  • the link being added is set to Type 6, and the link being deleted is set to Type 7.
  • the link set to Type 6 is added first, and then the link set to Type 7 is deleted.
  • Figure 39 illustrates an example in which the AP Removal Timer field is included in the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.
  • the link sending the MLD Roaming Request frame is removed and the switch is made with the Link ID in the Link Info field.
  • overhead can be reduced by omitting the Type field in the Link Info field.
  • the AP When the AP notifies the STA, it can notify in the MLD Roaming Response by adding the Channel Switch Count field as shown in FIG. 40 or FIG. 41 described below.
  • the STA determines and notifies the AP, it can notify in the MLD Roaming Request by using the Delete Timer field (or AP Removal Timer field) in the Reconfiguration element.
  • the Delete Timer of Reconfiguration IE When using the Delete Timer of Reconfiguration IE to notify the link switch completion time, if all links that requested a link switch through MLD Roaming Request have the same Delete Timer value, it can be added to Common Info instead of Link Info as shown in Fig. 36 to reduce overhead.
  • the Delete Timer Present field (or AP Removal Timer Present field) of Link Info can be used to avoid using the Delete Timer field. If the Delete Timer values of the links that requested a link switch are different, the Delete Timer field can be added to Link Info instead of Common Info. If there is only one link to be linked switched, the Delete Timer field can be added to Common Info, or the Delete Timer field can be added to User Info.
  • Order Information 1 Category 2 UHR Action or Protected UHR Action 3 Dialog Token 4 Status Code 5 Basic Multi-Link element 6 Group key information 7 AID 8 Channel Switching Announcement element (optional) 9 Extended Channel Switching Announcement element (optional) 10 TID-to-link Mapping element (optional) 11 Context Transfer Level 12 Context Transfer Contents Feedback 13 Queued Packets
  • Order 1 Basically, a Category can be included in a new UHR Action or a Protected UHR Action, but is not limited to these.
  • Order 4 Status Code can utilize the existing Status code field.
  • the Basic Multi-link IE defined in the existing 802.11be can be used to obtain the necessary information about AP MLD and N_AP.
  • Order 12 Context Transfer is complete and the contents actually transferred via Context Transfer are reported. At this time, the Context Transfer Level can be used.
  • the methods for providing this information can be broadly divided into Bitmap and Indexing methods.
  • Each Context Transfer Level is indicated by a bit of 0 or 1, and if the context corresponding to the level is actually transferred, it is set to 1, and if not transferred, it is set to 0. In this way, based on the details of the actual transfer, the STA can determine what needs to be negotiated or established again after roaming. Even without using 0 and 1, the presence/absence of the bit corresponding to the Context Transfer Level can be notified. For example, if it is bit 1: BA agreement but the bit does not exist, it can be known that it was not transferred.
  • Accumulation method Accumulated in the order of Context Transfer Level. If bit 2 is displayed, it means that all contexts corresponding to bits 0, 1, and 2 have been transferred.
  • bit 3 may be a group including BA agreement and SN/PN
  • bit 4 may be a group including SN/PN and Packet Reordering.
  • bit 3 may be a group including BA agreement and SN/PN
  • bit 4 may be a group including SN/PN and Packet Reordering.
  • bit 3 may be a group including BA agreement and SN/PN
  • bit 4 may be a group including SN/PN and Packet Reordering.
  • bit 3 may be a group including BA agreement and SN/PN
  • bit 4 may be a group including SN/PN and Packet Reordering.
  • a non-AP STA can use the Queued Packets field to inform the AP MLD (e.g., current AP MLD) receiving the Roaming Response frame whether there are packets in the queue. If the Queued Packets field is set to 1, it means that there are packets left in the queue. If the Queued Packets field is set to 0, it means that there are no packets left in the queue, or vice versa.
  • a non-AP STA can read the Queued Packets field and decide whether to transition (or skip) to the newly roaming AP MLD.
  • a non-AP MLD When a non-AP MLD receives a Roaming Response, it reads the Queued Packets field, and if the Queued Packets field is set to 1, it can reflect the additional information described below to determine how and until when to receive DL Data from the Serving AP MLD before roaming to the Target AP MLD. Conversely, if the Queued Packets field is set to 0, the target AP MLD and DL/UL transmission can be started immediately after receiving the Roaming Response.
  • the Channel Switch Count is a period that allows operation (e.g., DL forwarding) with the AP MLDs connected to the previously added link, and the period is set until the point where the existing link is deleted and operation is moved to a completely new link with the AP MLD that has roamed to the newly added link when the Channel Switch Count expires.
  • the value of the Channel Switch Count can represent the number of TBTTs, or it can be expressed as an actual time period in units of X units (e.g., us).
  • the AP can inform the STA how long it will perform the link switch to the new link.
  • the Channel Switch Count field can be added to the Link Info to individually inform each link of how long it will take to complete the link switch. If a link switch is requested for only one link in the MLD Roaming Request, the Channel Switch Count field can be included in the Common Info or Link Info. When switching from O_AP to N_AP and the channels of the two links are different, and information such as when the link was switched to a different link cannot be exchanged, the Channel Switch Count can be used to determine the point in time until which the link switch will be performed even if the channel is different by setting a specified count or time.
  • This information includes:
  • TID can be notified as a bitmap or value.
  • TID is an identifier that identifies the MSDU included in the MPDU (MAC Physical Data Unit).
  • AP MLD may provide one or more of the above additional information.
  • Figure 40 illustrates an example of the Common Info field of the Basic Multi-link IE proposed in this embodiment.
  • the existing Common Info field can be utilized.
  • the Common Info information here corresponds to the N_APs where one or more STAs perform MLD Roaming.
  • the Channel Switch Count field may be omitted by using the Channel Switch Count Present field.
  • the Channel Switch Count field of the Common Info of the Basic ML IE can be included.
  • the Channel Switch Count field of the Common Info can be used to inform the AP how long to perform the link switch.
  • the Link Switch Count indicates the number of TBTTs to be received from the AP connected to the existing link before the link switches to the new link.
  • the Channel Switch Count field allows the AP to inform the STA how long to perform the link switch to the new link.
  • Channel Switch Count is the period during which operations (e.g., DL forwarding) are allowed with the AP MLDs connected to the previously added link, and when it expires, the existing link is deleted and it is applied until the point of moving to a completely new link, operating as an AP MLD that roams to the newly added link.
  • This value can represent the number of TBTTs, and in addition, the Channel Switch Count field, which actually takes in units of X units (e.g., us), allows the AP to inform the STA how long it will take to perform the link switch to the new link.
  • the Channel Switch Count field can be added to the Link Info to inform each link individually how long it will take to complete the link switch. If a link switch is requested for only one link in the MLD Roaming Request, the Channel Switch Count field can be included in the Common Info or the Link Info. Channel Switch Count is used when switching to a new link from O_AP to N_AP, and when the channels of the two links are different, and information such as when the link was switched to a different link cannot be exchanged. By setting a specified count or time, it is possible to know up to what point the link switch is performed even if the channel is different.
  • one or more Per-STA Profile subelements may be required for the corresponding APs.
  • the information changed for the STA Control field, STA Info field, and STA Profile field of the existing Basic Multi-link IE is as follows.
  • Figure 41 illustrates an example of the Link Info field of the Basic Multi-link IE proposed in this embodiment.
  • the Link ID in the STA Info field indicates the Link ID corresponding to N_AP.
  • - Complete Profile refers to the AP's Complete information, i.e., all information included when transmitting an Association Response frame, as before. However, since the AP's STA performs MLD Roaming, its Capability or operational parameters may not change. Therefore, in this case, the Complete Profile is set to 0.
  • the STA Control field includes the MLD Roaming Timer Present field
  • the STA Info field includes the MLD Roaming Timer field. This means the time when MLD Roaming is completed and no longer operates with the O_AP, but operates with the N_AP. This can utilize the MLD Roaming Timer information transmitted by the STA, but may not be included if the STA transmitted it and the Response's Status Code is SUCCESS.
  • the UHR MLD MAC Address, UHR AP MLD ID, Collocation ID, Channel Switch Count, UHR Roaming Timer included in Fig. 37 and the MLD Roaming Timer, UHR AP MLD ID, AP MLD ID, Channel Switch Count fields included in Fig. 38 can be configured to configure the Basic ML element without adding them using the presence field.
  • the Channel Switch Count field can be added to the Link Info field to indicate the individual time required for the link switch to complete for each link. If the MLD Roaming Request requests a link switch for only one link, the Channel Switch Count field can be included in either the Common Info or the Link Info field.
  • the UHR AP MLD ID and AP MLD ID can be included as follows.
  • the AP MLD ID is the ID of the AP MLD to which the APs to which the non-AP MLD (or STA) will roam belong
  • the UHR AP MLD ID is the ID of the UHR AP MLD to which the AP MLDs to which the non-AP MLD (or STA) will roam belong. If the UHR AP MLD ID is not included in the MLD Roaming Request frame, it can be determined that it is affiliated with the same UHR AP MLD, so the UHR AP MLD ID field may not be included. This case is described in 1-2) case 2 when included in the Common Info field, 2-2) case 2 when included in the Link Info field - always present, and 3-2) case 2 when included in the Link Info field - not always present.
  • the presence bitmap indicates whether or not to include the AP MLD ID, and accordingly the AP MLD ID is included in the Common Info field.
  • the STA Control field includes the UHR AP MLD ID and AP MLD ID corresponding to the AP corresponding to the Link ID of each Per-STA Profile subelement. This can provide information about multiple APs corresponding to multiple AP MLD IDs, but when providing information for the same AP MLD ID, the overhead is greater than the method of indicating it in the Common Info field.
  • the STA Control field includes the AP MLD ID corresponding to the AP corresponding to the Link ID of each Per-STA Profile subelement. This can provide information about multiple APs corresponding to multiple AP MLD IDs, but when providing information for the same AP MLD ID, the overhead is greater than the method of indicating it in the Common Info field.
  • the inclusion of the AP MLD ID corresponding to the AP corresponding to the Link ID can be indicated through the UHR AP MLD ID Present and AP MLD ID Present of the STA Control field of the Per-STA Profile subelement.
  • the UHR AP MLD ID and AP MLD ID can be included in the STA Info field or the STA Profile field. Similarly, this can provide information about multiple APs corresponding to multiple AP MLD IDs.
  • overhead can be reduced compared to method 2) by not including the UHR AP MLD ID and AP MLD ID.
  • the UHR AP MLD ID, AP MLD ID, and Collocation ID may be omitted. That is, if the Collocation ID does not exist, the AP that received the request can implicitly recognize that it is a request for information from other APs regarding the AP MLD to which it belongs.
  • the Collocation ID is indicated in Common Info in another way, it may not include the UHR AP MLD ID, AP MLD ID, and Collocation ID because it is implicitly recognized that this is information about APs corresponding to the same Collocation Set. In other words, the UHR AP MLD ID Present and AP MLD ID Present fields may not be included.
  • the presence or absence of an AP MLD ID corresponding to an AP corresponding to a Link ID can be indicated through the AP MLD ID Present in the STA Control field of the Per-STA Profile subelement.
  • the AP MLD ID can be included in the STA Info field or the STA Profile field. Similarly, this can provide information about multiple APs corresponding to multiple AP MLD IDs.
  • the overhead can be reduced compared to method 2) by not including the AP MLD ID when only providing information about APs corresponding to the same AP MLD ID.
  • the AP MLD ID and Collocation ID may be omitted. That is, if the Collocation ID does not exist, the AP that received the request can implicitly recognize that it is a request for information from other APs regarding the AP MLD to which it belongs.
  • the Collocation ID is indicated in Common Info in another way, it may not include the AP MLD ID and Collocation ID because it is implicitly recognized that this is information about APs corresponding to the same Collocation Set. In other words, the UHR AP MLD ID Present and AP MLD ID Present fields may not be included.
  • Figure 42 illustrates an example of the Group Key Information field.
  • Length indicates the length of the Group key Information.
  • the Group key Information for each N_AP includes the MLO GTK KDE format, MLO IGTK KDE, and MLO BIGTK KDE, which each include the Link ID of the N_AP as defined in 802.11be.
  • each AP MLD can manage its own AID. This means that AIDs can be assigned when roaming to other AP MLDs. However, AIDs may not be included in the following cases:
  • Orders 8 and 9 In these cases, the channel of each AP to which roaming is performed is the same, but it can be considered different from the channels of previously connected APs. However, the following cases may be included differently for Orders 8 and 9:
  • the channel of an AP to be roamed to may be the same as or different from the channel of the previously connected AP.
  • the Channel Switching Announcement IE or Extended Channel Switching Announcement IE may be included in the Link Info of the Basic Multi-link IE in Order 5, respectively. This is to perform a channel switch for each AP to be roamed to.
  • Order 10 This can be used to map TIDs in advance for newly connected links through TID-to-link mapping. If separate TID-to-link mapping is not performed, the default mapping can be applied.
  • an MLD Roaming Timer can be added to both the MLD Roaming Request/Response frames.
  • the AP MLD can include the MLD Roaming Timer of the above Reconfiguration ML IE. This can also indicate a set MLD Roaming Timer since the AP MLD can control the current roaming. For example, if the STA does not include the MLD Roaming Timer or it is inappropriate, the AP MLD can set it and notify. Also, if the STA did not transmit the MLD Roaming Timer, the AP MLD can set it and notify.
  • the meaning of the MLD Roaming Timer is the same. That is, it means the time when MLD Roaming is completed, no more operations are performed with the O_AP, and operations are performed with the N_AP.
  • the MLD Roaming timer If the MLD Roaming timer is applied commonly to all APs, it can be included in the Common Info field. At this time, the presence or absence of the Common Info field can be indicated through the Presence Bitmap.
  • the MLD Roaming Response frame can include information about the MLD Roaming Timer.
  • the STA Control field includes an MLD Roaming Timer Present field
  • the STA Info field includes an MLD Roaming Timer field. This can indicate the remaining time until the STA can receive data from the AP to which it is roaming. This can also utilize the MLD Roaming Timer information transmitted by the STA. This is basically related to the TIM field presented in 2.5.
  • the MLD Roaming timer is applied commonly to all APs, it can be included in the Common Info field.
  • the presence of the Common Info field can be indicated through the Presence Bitmap.
  • it can be included in the MLD Roaming Probe Response frame body.
  • the operation process of AP and STA performing MLD Roaming is as follows.
  • Figure 43 illustrates a procedure for determining whether an N_AP is capable of roaming using the Collocation Enabled field.
  • the transmission and reception process of the AP is as follows.
  • O_AP transmits the RNR IE to the STA in the Beacon.
  • O_AP receives the MLD Roaming Request frame from the STA, it checks the Link ID, AP MLD ID, and UHR AP MLD ID (optional) of the AP to which the STA wishes to roam.
  • O_AP sends the STA whether it accepts the request and the information described in the Roaming Response frame format through the MLD Roaming Response frame.
  • Figure 44 illustrates a procedure for determining whether an N_AP is capable of roaming using a Collocation ID.
  • the transmission and reception process of the AP is as follows.
  • O_AP transmits the RNR IE to the STA in the Beacon.
  • O_AP receives the MLD Roaming Request frame from the STA, it checks the Link ID, AP MLD ID, and UHR AP MLD ID (optional) of the AP to which the STA wishes to roam.
  • O_AP sends the STA whether it accepts the request and the information described in the Roaming Response frame format through the MLD Roaming Response frame.
  • Figure 45 illustrates the MLD Roaming procedure when a UHR AP MLD ID is entered in the Reconfiguration element.
  • the transmission and reception process of the AP is as follows.
  • O_AP transmits information about other APs to STA through Beacon.
  • STA checks the ID of AP to which it wants to roam through Link ID and AP MLID. Additionally, if MLD Roaming Request frame includes UHR AP MLD ID, STA also checks UHR AP MLD ID.
  • O_AP transmits to STA whether it accepts and the information described in 2.4.2. Roaming Response frame format through MLD Roaming Response frame.
  • the STA receives information about other APs via the beacon from the O_AP. Based on the information about the APs received from the O_AP, the STA determines the AP to which to roam. The STA transmits a Roaming Request frame to the O_AP. The STA receives an MLD Roaming Response frame from the O_AP, and if accepted, roams to the N_AP.
  • Figure 46 illustrates the MLD Roaming procedure when the UHR AP MLD ID is not entered in the Reconfiguration element.
  • the transmission and reception process of the AP is as follows.
  • O_AP transmits information about other APs to STAs via Beacon.
  • the STA Upon receiving an MLD Roaming Request frame from an STA, the STA verifies the ID of the AP it wishes to roam to using the Link ID and AP MLID.
  • O_AP transmits the MLD Roaming Response frame to the STA, indicating whether it accepts the request and including the information described in 2.4.2. Roaming Response frame format.
  • the STA receives information about other APs via the beacon from the O_AP. Based on the information about the APs received from the O_AP, the STA determines the AP to which to roam. The STA transmits a Roaming Request frame to the O_AP. The STA receives an MLD Roaming Response frame from the O_AP, and if accepted, roams to the N_AP.
  • Figure 47 illustrates an example of a collocated AP set.
  • Figure 47 shows an example of determining whether to roam based on collocation information when a non-AP MLD moves while already connected to AP 2.
  • Collocation information can be obtained through the Collocation Enabled field or Collocation ID field of the RNR IE.
  • AP 4 and AP 5 which are affiliated with AP MLD 2, exist around the non-AP MLD, they are included in the same collocated AP set as the currently connected AP 2, so the non-AP MLD does not make a roaming request to AP 4 and AP 5.
  • the non-AP MLD can make a roaming request to AP 6, AP 7, and AP 8, which are included in a different collocated AP set from AP 2.
  • Example #1 Only some STAs roam to the AP first.
  • Figure 48 illustrates Example 1 for the MLD Roaming procedure.
  • Figure 48 illustrates a case where only some STAs roam to APs first, rather than all STAs simultaneously moving to APs in a different AP MLD. For example, STA 1 first roams from AP 1 to AP 3, and then STA 2 roams from AP 3 to AP 5. In this example, there are two STAs in the non-AP MLD, but even if there are three STAs, only two STAs can roam first, and the remaining STAs can roam later.
  • STA 1 and AP 1 can first exchange MLD Roaming Request/Response.
  • STA 1 will indicate the (Optional) UHR AP MLD ID, AP MLD ID, and Link ID for AP 4 in the MLD Roaming Request, and AP 1 will include information about AP 4 in the Basic Multi-link IE along with whether to accept it.
  • STA 2 and AP 3 will go through the same process for AP 5.
  • the process can also be performed for AP 4, to which STA 1 is connected, instead of STA 2.
  • This example can be effective for data reception. While AP 1 and STA 1 are roaming, AP 2 and STA 3 can exchange data. Similarly, while AP 3 and STA 2 are roaming, AP 4 and STA 1 can exchange data. In this case, all TIDs must be mapped to the links exchanging data. However, this example is difficult to apply to non-MLD STAs or when there is only one STA in the MLD, and it can incur relatively high frame exchange overhead.
  • Figure 49 shows the operation process of Example 1 for the MLD Roaming procedure.
  • the transmission and reception process of the AP is as follows.
  • AP 1 receives a Roaming Request frame from STA 1.
  • the STA determines the ID of the AP to which it wishes to roam using the Link ID, AP MLD ID, and UHR AP MLD ID (optional).
  • AP 1 transmits to STA 1 whether it accepts the roaming request and the information described in 2.4.2.
  • STA 1 transmits an MLD Roaming Request frame for APs 4 and 5 to AP 1. If STA 1 receives roaming acceptance from AP 1 by receiving an MLD Roaming Response frame, STA 1 roams to AP 4 based on the information about AP 4 it received. After STA 1's roaming is complete, STA 2 also roams to AP 4 based on the acceptance of AP 5 received from STA 1 and the information about APs 4 and 5.
  • Example #2 When all STAs are transferred to APs of a different Group at once.
  • Figure 50 illustrates Example 2 for the MLD Roaming procedure.
  • Figure 50 illustrates a case where all STAs simultaneously move to APs in a different group. For example, STA 1 simultaneously roams from AP 1 to AP 3, and STA 2 simultaneously roams from AP 3 to AP 5.
  • STA 1 and AP 1 or STA 2 and AP 3 presented above can exchange MLD Roaming Request/Response.
  • the MLD Roaming Request will indicate the UHR AP MLD ID (Optional), AP MLD ID, and Link ID for AP 4 and AP 5, and AP 1 or AP 3 will include information about AP 4 and AP 5 in the Basic Multi-link IE along with whether to accept it.
  • This example can reduce frame overhead compared to Example 1 and, depending on the AP MLD Roaming domain structure, reduce data latency. For example, if there is an Anchor AP in AP MLD that manages data reception from the DS and MLD Roaming, if this Anchor AP accepts the MLD Roaming Request, the data path can be set for Roaming in advance.
  • Figure 51 shows the operation process of Example 2 for the MLD Roaming procedure.
  • the transmission and reception process of the AP is as follows.
  • AP 1 receives a Roaming Request frame from STA 1.
  • the STA determines the ID of the AP to which it wishes to roam using the Link ID, AP MLD ID, and UHR AP MLD ID (optional).
  • AP 1 transmits to STA 1 whether it accepts the roaming request and the information described in 2.4.2.
  • STA 1 transmits an MLD Roaming Request frame for APs 4 and 5 to AP 1. If STA 1 receives roaming acceptance from AP 1 by receiving an MLD Roaming Response frame, STA 1 roams to AP 4 based on the information about AP 4 it received. After STA 1's roaming is complete, STA 2 also roams to AP 4 based on the acceptance of AP 5 received from STA 1 and the information about APs 4 and 5.
  • Example #3 Procedure to perform temporary add and delete respectively (If using Timer, these procedures can be performed simultaneously)
  • Figure 52 illustrates Example 3 for the MLD Roaming procedure.
  • Figure 52 is an example in which STA 1 first adds AP 4 and STA 2 temporarily adds AP 5, and then deletes AP 1 and AP 3, respectively.
  • STA 1 and AP 1 or STA 2 and AP 3 can exchange MLD Roaming Request/Response.
  • the MLD Roaming Request will indicate the UHR AP MLD ID (Optional), AP MLD ID, and Link ID for AP 4 and AP 5, and AP 1 or AP 3 will include information about AP 4 and AP 5 in the Basic Multi-link IE along with whether to accept it.
  • STA 1 will be temporarily connected to AP 1 and AP 4, and STA 2 will be connected to AP 3 and AP 5.
  • STA 1 can transmit or receive data from AP 1 and AP 4. That is, when exchanging frames with AP 1, it cannot exchange frames with AP 4.
  • STA 1 performs a Temporary delete (or delete) operation on AP 1, STA 2, and AP 3. Through this procedure, STA 1 completes roaming to AP 4, and STA 2 completes roaming to AP 5.
  • the above example is a procedure that performs temporary add and delete respectively. If a timer is used here, these procedures can be performed simultaneously.
  • STA 1 and AP 1 or STA 2 and AP 3 can exchange MLD Roaming Request/Response.
  • AP 1 and AP 3 simultaneously request Delete (or Temporary Delete), and AP 4 and AP 5 request Temporary add.
  • the MLD Roaming Timer presented above is set.
  • non-AP MLD or AP MLD can set this through the MLD Roaming Response.
  • the timer starts running, and when the timer expires, the AP 1 link is deleted from STA 1, and AP 4 is fully connected, and AP 3 is deleted from STA 2, and AP 5 is fully connected.
  • Figure 53 shows the operation process of Example 3 for the MLD Roaming procedure.
  • the transmission and reception process of the AP is as follows.
  • AP 1 receives a Roaming Request frame from STA 1.
  • the STA checks the ID of the AP to which it wants to roam using the Link ID, AP MLD ID, and UHR AP MLD ID (optional).
  • AP 1 sends STA 1 whether it accepts the connection and the information described in 2.4.2.
  • Roaming Response frame format for APs 4 and 5 via the MLD Roaming Response frame.
  • AP 1 sets the MLD Roaming Timer. At this time, when the MLD Roaming Timer times out, the existing connection is completely deleted and the roamed AP is completely connected.
  • STA 1 sends an MLD Roaming Request frame for APs 4 and 5 to AP 1. If STA 1 receives roaming acceptance from AP 1 by receiving an MLD Roaming Response frame, STA 1 roams to AP 4 based on the information about AP 4 it received. After STA 1's roaming is complete, STA 2 also roams to AP 4 based on whether it accepted AP 5 received from STA 1 and the information about APs 4 and 5. STA 1 sets the MLD Roaming Timer. At this time, when the MLD Roaming Timer times out, the existing connection is completely deleted and the roamed AP is fully connected.
  • Figure 54 illustrates Example 4 for the MLD Roaming procedure.
  • Figure 51 is an example in which STA 1 first deletes (or temporarily deletes) AP 1 and STA 2 deletes (or temporarily deletes) AP 3, and then adds (or temporarily adds) AP 4 and AP 5, respectively.
  • STA 1 and AP 1 or STA 2 and AP 3 can first exchange MLD Roaming Request/Response.
  • the MLD Roaming Request will indicate (Optional) UHR AP MLD, AP MLD ID, and Link ID for AP 4 and AP 5, and AP 1 or AP 3 will include information about AP 4 and AP 5 in the Basic Multi-link IE along with whether to accept this.
  • STA 1 or STA 2 can disconnect from AP 1 and AP 3.
  • the above example is a procedure for performing temporary add and delete, respectively. If a timer is used here, these procedures can be performed simultaneously.
  • STA 1 and AP 1, or STA 2 and AP 3 can exchange MLD Roaming Request/Response.
  • AP 1 and AP 3 can request Delete (or Temporary Delete), and AP 4 and AP 5 can request Add (or Temporary Add) simultaneously or individually.
  • the MLD Roaming Timer presented above is set. As mentioned above, this can be set by non-AP MLD or AP MLD through the MLD Roaming Response.
  • the timer starts running, and when the timer expires, the AP 1 link is deleted from STA 1, and AP 4 is fully connected, and STA 2 deletes AP 3, and AP 5 is fully connected.
  • Figure 55 shows the operation process of examples 3 and 4 for the MLD Roaming procedure.
  • the transmission and reception process of the AP is as follows.
  • AP 1 receives a Roaming Request frame from STA 1.
  • STA 1 and 2 check the IDs of the APs (AP 4, 5) to which they want to roam using the Link ID, AP MLD ID, and UHR AP MLD ID (optional).
  • AP 1 sends STA 1 whether to accept the connection and the information described in 2.3.2.
  • Roaming Response frame format for AP 4 and 5 via the MLD Roaming Response frame.
  • AP 1 sets the MLD Roaming Timer. At this time, when the MLD Roaming Timer times out, the existing connection is completely deleted and the roamed AP is completely connected.
  • STA 1 transmits MLD Roaming Request frames for APs 4 and 5 to AP 1.
  • STA1 requests Delete (or Temporary Delete) for AP 1 and AP 2, and Temporary Add for AP 4 and AP 5.
  • STA 1 receives MLD Roaming Response frames from AP 1 to determine whether roaming for APs 4 and 5 is accepted and to receive information about the APs (refer to 2.3.1).
  • STA 1 sets the MLD Roaming Timer. At this time, when the MLD Roaming Timer times out, the existing connection is completely deleted and the roamed AP is fully connected.
  • Figure 56 illustrates Example 5 for the MLD Roaming procedure.
  • Figure 57 illustrates Example 6 for the MLD Roaming procedure.
  • Figures 56 and 57 illustrate embodiments of a method for setting the Type field of an MLD Request frame when sending link add and delete requests simultaneously.
  • Figure 56 shows that a non-AP MLD first requests link add in order to roam to a new AP MLD (AP MLD 2), and then a connection is created between STA 1 and AP 4, and then a request is made to delete the connection with AP 1, which was previously connected to STA 1.
  • AP MLD 2 AP MLD 2
  • the Link ID and AP MLD ID can be used to request the AP to which the request is sent.
  • STA 1 cannot transmit and receive data with AP MLD 1, but STA 2 of the non-AP MLD is connected to AP 3 of AP MLD 1, so the non-AP MLD and AP MLD 1 can transmit and receive data. Therefore, data discontinuity can be reduced during roaming.
  • STA 2 can also request a link add to AP 5 and then disconnect from AP 3 to completely roam to the new AP MLD 2.
  • AP MLD 1 and AP MLD 2 are affiliated with the same AP MLD for a seamless roaming, the data accumulated in the queue of AP MLD 1 can be transferred to AP MLD 2.
  • Fig. 57 has the same overall roaming procedure as Fig. 56, but the link is deleted first and then a link with AP MLD 2 is added.
  • the MLD Roaming Request frame can be configured in the manner of 3-1) Example of sending Add and delete requests at the same time in 2.4.1 MLD Roaming Request frame format - If you want to add a new link first and delete an existing link, and in the case of Fig. 57, the MLD Roaming Request frame can be configured in the manner of 3-2) Example of sending Add and delete requests at the same time in 2.4.1 MLD Roaming Request frame format - If you want to delete an existing link first and add a new link.
  • the Link Info field can be configured with two Per-STA Profiles (one Per-STA Profile for add, and the other Per-STA Profile for delete).
  • the configuration of the MLD Roaming Request frame that sends the add/delete request can be configured as follows: 1) If included in the Common Info field of the MLD Roaming Request frame body or Reconfiguration IE, 2-1) If included in the Link Info field of the MLD Roaming Request frame body or Reconfiguration IE, 2-2) If included in the Link Info field of the MLD Roaming Request frame body or Reconfiguration IE.
  • the response to the request is received as an MLD Roaming Response frame, and the status code can be used to determine whether the MLD Roaming Request frame is accepted or rejected.
  • Figure 58 shows an example of MLD Roaming using TIM.
  • AP 1 notifies STA 1 via TIM whether it has DL data to transmit via Beacon. At this time, STA 1 transmits MLD Roaming Request to add AP 4 for roaming. Note that this example only includes STA 1, but it can also request link addition of AP 5 to STA 2, as shown in FIG. 44. AP 1 confirms this and responds with accept to AP 4. However, STA 1 may have received information that it is not currently buffering DL data from the latest Beacon of AP 1, or may have buffered it but not yet received it. Therefore, AP 1 can notify STA 1 that AP 4 or UHR AP MLD has the DL data.
  • MLD Roaming Response frame which is as follows:
  • -> TIM Traffic Indication Map
  • the TIM field may be included in the MLD Roaming Response frame body or Common Info field.
  • the TIM field can be included in the Link Info field.
  • an STA (e.g., STA 1) can additionally use the MLD Roaming Timer of the MLD Roaming Response frame to determine the time to switch. For example, if there is still a lot of time left until it receives data from the AP to which it is currently roaming (e.g., AP 4) before switching, STA 1 can first receive DL data from the currently connected AP (e.g., AP 1) through PS-Poll (if necessary) and then switch. Alternatively, if there is still time to receive data from AP 4 even if it switches immediately, STA 1 can switch immediately.
  • the currently connected AP e.g., AP 1
  • PS-Poll if necessary
  • Figure 59 shows the operation process for the MLD Roaming procedure using TIM.
  • the transmission and reception process of the AP is as follows.
  • AP 1 notifies STA 1 via TIM whether it has DL data to transmit via Beacon.
  • AP 1 responds with accept to AP 4 (+AP 5).
  • AP 1 then informs who has the DL data.
  • the AP or UHR AP MLD that has the DL data transmits the DL data to STA 1 (+STA 2).
  • AP 1 (+AP 3) deletes the existing connection.
  • STA 1 performs roaming and transmits an MLD Roaming Request to add AP 4. At this time, it can also request the addition of a link for AP 5 to STA 2.
  • STA 1 receives information about DL data.
  • STA 1 (+STA 2) performs roaming to AP 4 (+AP 5).
  • STA 1 (+STA 2) transmits a PS-Poll to AP 4 (+AP 5) and receives the corresponding DL data.
  • STA 1 (+STA 2) requests link deletion to AP 1 (+AP 3).
  • context transfer can be used, as shown in the example in FIG. 70 described below, to preemptively transmit necessary information from the previously connected AP MLD to the new AP MLD before the non-AP STA roams.
  • the non-AP STA waits for the context transfer time after requesting roaming and performs roaming.
  • the delay caused by the context transfer increases as the amount of information to be transferred increases.
  • Context Transfer Level which allows only the necessary information to be transferred to avoid delays caused by unnecessary context transfers in situations where context transfer is not necessary.
  • the non-AP STA can specify the Context Transfer Level when making a Roaming Request, or the Serving AP MLD can specify it and notify the non-AP STA of it. If a non-AP MLD STA does not need to know the Context Transfer Level, it may not inform the non-AP MLD STA of the Context Transfer Level.
  • the Context Transfer Level can be set in at least one of the following ways:
  • Context Transfer Level 0: Transfer a context called A
  • this is a method that includes contexts transferred to the previous Context Transfer Level and new contexts.
  • Examples of contexts being transferred can be as follows.
  • Context Transfer Level 1 If you select Context Transfer Level 1, only Context B will be transferred, and if you select Context Transfer Level 0, 1, both Context A and B will be transferred.
  • Context A and B may be the same as the examples in 1) Accumulation method.
  • Bitmap For example, if the above Bitmap is X bit, B0 can be set as Context A, B1 as Context B, etc.
  • Context Transfer Level For example, if roaming is possible with only entity or UHR MLD without context transfer, set the Context Transfer Level to 0. If only SN/PN information needs to be transferred with Context Transfer, set the Context Transfer Level to 1. The context included in the value of the Context Transfer Level can be accumulated. If the Context Transfer Level is set to 3, Context Transferred items with values of 1 and 2 are included.
  • the Accumulation method is one of many methods and is not limited to the above method.
  • Figure 60 illustrates an example of a Roaming Procedure using Context transfer (only entities exist).
  • Figure 60 is an example of a roaming process when context transfer is present.
  • a non-AP MLD sends a Roaming Request
  • the process is the same as Figure 61.
  • a non-AP STA transmits the ID information of the AP to be roamed to the UHR AP MLD or AP MLD through the Roaming Request frame to perform roaming.
  • the contexts to be transferred can be specified using the Context Transfer Level field of the Roaming Request frame.
  • the UHR AP MLD or AP MLD that receives the Roaming Request frame informs whether roaming to the requested AP is possible and the Context Transfer Level through the transmission of the Roaming Response frame.
  • the UHR AP MLD or AP MLD Upon receiving the Roaming Request frame from the non-AP MLD, the UHR AP MLD or AP MLD transmits the control contexts to be transferred, set in the Context Transfer Level, to the AP MLD to be roamed through the DS. If the Context Transfer Level is set to 0, no context transfer is performed.
  • the AP MLD When the context transfer is complete, the AP MLD requests a link add to the non-AP MLD, and when a link is formed between the AP MLD to which roaming is to occur and the non-AP MLD, in the case of DL (downlink), the packets that were queued but not transmitted by roaming according to the SN/PN information received through the context transfer from the AP MLD before roaming are transmitted by the AP MLD after roaming to the non-AP STA. After this, new packets received from the DS are received by the AP MLD after roaming. In the case of UL, the non-AP STA transmits packets to the AP MLD after roaming.
  • the AP MLD requests a link delete for all links connected to the AP MLD and the non-AP STA before roaming, and the roaming process ends when the deletion of all links is complete.
  • Figure 62 illustrates an example process for a case where an AP MLD sends a Roaming Request.
  • an AP MLD sends a Roaming Request, it can provide capability information regarding the extent to which the AP MLD can transfer context through the Context Transfer Level.
  • the Context Transfer Level value is set to a value lower than the Context Transfer Level value of the Roaming Request.
  • Figure 61 illustrates an example of a roaming process using context transfer.
  • Figure 61 is an example of a process when a non-AP MLD sends a Roaming Request.
  • the AP MLD transmission and reception process is as follows.
  • the AP MLD receives a Roaming Request frame from the Non-AP MLD.
  • the AP MLD transfers information about the existing AP MLD (Serving AP MLD) and the necessary context to the Target AP MLD to which the Non-AP MLD is roaming.
  • the UHR AP MLD or entity
  • the Target AP MLD transmits packets queued in the existing AP MLD queue using the SN (Sequence Number)/PN (Packet Number) information received through the context transfer in a DL environment.
  • the Target AP MLD receives frames only through the new link.
  • the Target AP MLD requests a link delete for the link connected to the existing AP MLD.
  • Non-AP MLD transmission and reception process is as follows.
  • the Non-AP MLD transmits a Roaming Request frame to the UHR AP MLD (or Serving AP MLD).
  • the Non-AP MLD receives information about roaming acceptance and APs by receiving the Roaming Response frame.
  • the Non-AP MLD receives a link add request, it sends and receives frames on the link connected to the new AP MLD (Target AP MLD).
  • the Non-AP MLD receives a link delete request, it deletes the link connected to the existing AP MLD (Serving AP MLD).
  • Figure 62 illustrates another example of a roaming process using context transfer.
  • Figure 62 is an example of a process when AP MLD sends a Roaming Request.
  • the AP MLD transmission and reception process is as follows.
  • the AP MLD transmits a Roaming Request frame to the Non-AP MLD.
  • the AP MLD conveys information about the existing AP MLD (Serving AP MLD) and the necessary context to the Target AP MLD to which the Non-AP MLD is roaming.
  • the UHR AP MLD or entity
  • the Target AP MLD transmits the packets queued in the existing AP MLD queue using the SN (Sequence Number)/PN (Packet Number) information received through the context transfer in a DL environment.
  • the Target AP MLD receives frames only through the new link.
  • the Target AP MLD requests a link delete for the link connected to the existing AP MLD.
  • Non-AP MLD transmission and reception process is as follows.
  • the Non-AP MLD receives a Roaming Request frame from the UHR AP MLD (or Serving AP MLD).
  • the Non-AP MLD receives information about roaming acceptance and APs through the Roaming Response frame.
  • the Non-AP MLD receives a link add request, it sends and receives frames on the link connected to the new AP MLD (Target AP MLD).
  • the Non-AP MLD receives a link delete request, it deletes the link connected to the existing AP MLD (Serving AP MLD).
  • Figure 63 illustrates an example of transmitting DL data accumulated in the queue of the Serving AP MLD.
  • the Queued packet field in the Roaming Response frame is set to 1 as shown in FIG. 63 and additional information (DL data size, Number of pending MSDUs, SN or PN related information, TIDs for pending MSDU) is provided together, the DL data remaining in the queue of the Serving AP MLD after transmitting the Roaming Response frame is transmitted to the non-AP MLD STA.
  • the amount of DL data can be measured using the DL data size or Number of pending MSDUs to determine the end of DL data transmission, or the last SN/PN information or the last DL data bit in the last DL data can be used to indicate the portion of the last DL data.
  • Figure 64 illustrates a procedure for notifying the DL Timer of the completion of transmission of DL Data accumulated in the queue of the Serving AP MLD.
  • a non-AP MLD STA calculates the time required to transmit DL data through the MSDU DL data size or the Number of pending MSDUs transmitted through the Roaming Response, and then sets the DL Timer to determine when the transmission of DL data will end.
  • a non-AP MLD STA receives a Roaming Response with a Queued Packet field of 1, the non-AP STA may not know when the queued packets of the Serving AP MLD have been completely transmitted.
  • the Serving AP MLD sets the value of the Queued Packets field of the Roaming Response to 0 and resends it when the queued packets are gone, so that the non-AP MLD can know when it is transitioned (or passed over) from the Serving AP MLD to the Target AP MLD.
  • the baseline of the roaming procedure can be defined as follows:
  • Figure 65 illustrates an example of the Baseline of the Roaming Procedure.
  • Figure 65 is the most basic procedure for Seamless Roaming.
  • the Roaming Response can provide information about the success or failure of the link establishment.
  • the Roaming Request and Roaming Response can be sent by either the non-AP MLD or the AP MLD, and since the Serving AP MLD and the Target AP MLD are connected via backhaul, they share information about the Roaming Request/Response with each other.
  • Figure 66 illustrates an example of Baseline #1 of the Roaming Procedure.
  • Figure 66 is an example of a case where a Non-AP MLD sends a Roaming Request and a case where a Non-AP MLD sends a Roaming Response.
  • the AP MLD transmission and reception process is as follows.
  • the AP MLD receives a Roaming Request frame. Once a link is established between the target AP MLD and the non-AP MLD, the AP MLD receives a Roaming Response frame from the non-AP MLD.
  • Non-AP MLD transmission and reception process is as follows.
  • the non-AP MLD sends a Roaming Request frame to the AP MLD. Once a link is established between the target AP MLD and the non-AP MLD, the non-AP MLD sends a Roaming Response frame to the AP MLD.
  • Figure 67 illustrates an example of Baseline #2 of the Roaming Procedure.
  • Figure 67 is an example of a case where an AP MLD sends a Roaming Request and a case where a Non-AP MLD sends a Roaming Response.
  • the AP MLD transmission and reception process is as follows.
  • the AP MLD transmits a Roaming Request frame. Once a link is established between the target AP MLD and the non-AP MLD, the AP MLD receives a Roaming Response frame from the non-AP MLD.
  • Non-AP MLD transmission and reception process is as follows.
  • the non-AP MLD receives a Roaming Request frame from the AP MLD. Once a link is established between the target AP MLD and the non-AP MLD, the non-AP MLD sends a Roaming Response frame to the AP MLD.
  • Figure 68 illustrates an example of Baseline #3 of the Roaming Procedure.
  • Figure 68 is an example of a case where a non-AP MLD sends a Roaming Request and a case where an AP MLD sends a Roaming Response.
  • the AP MLD transmission and reception process is as follows.
  • the AP MLD receives a Roaming Request frame. Once a link is established between the target AP MLD and the non-AP MLD, the AP MLD sends a Roaming Response frame to the non-AP MLD.
  • Non-AP MLD transmission and reception process is as follows.
  • the non-AP MLD sends a Roaming Request frame to the AP MLD. Once a link is established between the target AP MLD and the non-AP MLD, the non-AP MLD receives a Roaming Response frame from the AP MLD.
  • Figure 69 illustrates an example of Baseline #4 of the Roaming Procedure.
  • Figure 69 is an example of a case where AP MLD sends a Roaming Request and a case where AP MLD sends a Roaming Response.
  • the AP MLD transmission and reception process is as follows.
  • the AP MLD transmits a Roaming Request frame. Once a link is established between the target AP MLD and the non-AP MLD, the AP MLD transmits a Roaming Response frame to the non-AP MLD.
  • Non-AP MLD transmission and reception process is as follows.
  • the non-AP MLD receives a Roaming Request frame from the AP MLD. Once a link is established between the target AP MLD and the non-AP MLD, the non-AP MLD receives a Roaming Response frame from the AP MLD.
  • Figure 70 illustrates an example explaining the order of link establishment with the Target AP MLD.
  • Figure 70 illustrates a case where a link is established with a target AP MLD before transmitting data accumulated in the queue of the Serving AP MLD. That is, Figure 70 is an example of sending DL data to a non-AP MLD STA when a Roaming Response is received and DL data packets remain in the queue of the Serving AP MLD.
  • Figure 71 is a flowchart illustrating the operation of a transmitting device according to the present embodiment.
  • FIG. 71 may be performed at a transmitting STA or transmitting device (AP and/or non-AP STA).
  • the transmitting device can obtain information regarding the aforementioned Tone Plan.
  • the information regarding the Tone Plan includes the size and location of the RU, control information related to the RU, information regarding the frequency band in which the RU is included, information regarding the STA receiving the RU, etc.
  • step S7120 the transmitting device can configure/generate a PPDU based on the acquired control information.
  • the step of configuring/generating the PPDU may include a step of configuring/generating each field of the PPDU. That is, step S7120 may include a step of configuring an EHT-SIG field including control information regarding a Tone Plan. That is, step S7120 may include a step of configuring a field including control information indicating the size/position of an RU (e.g., an N bitmap) and/or a step of configuring a field including an identifier (e.g., an AID) of an STA receiving the RU.
  • an identifier e.g., an AID
  • step S7120 may include a step of generating an STF/LTF sequence to be transmitted through a specific RU.
  • the STF/LTF sequence may be generated based on a preset STF generation sequence/LTF generation sequence.
  • step S7120 may include a step of generating a data field (i.e., MPDU) to be transmitted via a specific RU.
  • a data field i.e., MPDU
  • the transmitting device can transmit the PPDU configured through step S7120 to the receiving device based on step S6330.
  • the transmitting device may perform at least one of operations such as CSD, Spatial Mapping, IDFT/IFFT operation, and GI insertion.
  • a signal/field/sequence configured according to this specification can be transmitted in the form of FIG. 5.
  • Figure 72 is a flowchart illustrating the operation of a receiving device according to the present embodiment.
  • the above-described PPDU can be received according to an example of FIG. 72.
  • FIG. 72 may be performed at a receiving STA or receiving device (AP and/or non-AP STA).
  • a receiving device can receive all or part of a PPDU through step S7210.
  • the received signal may have the form of FIG. 5.
  • step S7210 can be determined based on step S7130 of FIG. 71. That is, step S7210 can perform an operation to restore the results of the CSD, Spatial Mapping, IDFT/IFFT operations, and GI insert operations applied in step S7130.
  • the receiving device can decode all or part of the PPDU. Additionally, the receiving device can obtain control information related to the Tone Plan (i.e., RU) from the decoded PPDU.
  • Tone Plan i.e., RU
  • the receiving device can decode the L-SIG and EHT-SIG of the PPDU based on the Legacy STF/LTF and obtain information included in the L-SIG and EHT SIG fields.
  • Information regarding various Tone Plans (i.e., RUs) described herein can be included in the EHT-SIG, and the receiving STA can obtain information regarding the Tone Plan (i.e., RU) through the EHT-SIG.
  • the receiving device can decode the remaining portion of the PPDU based on the information about the Tone Plan (i.e., RU) acquired through step S7220. For example, the receiving STA can decode the STF/LTF field of the PPDU based on the information about one Plan (i.e., RU). In addition, the receiving STA can decode the data field of the PPDU based on the information about the Tone Plan (i.e., RU) and acquire the MPDU included in the data field.
  • the Tone Plan i.e., RU
  • the receiving device may perform a processing operation to transmit the decoded data to a higher layer (e.g., MAC layer) through step S7230. Furthermore, if the generation of a signal from the higher layer to the PHY layer is instructed in response to the data transmitted to the higher layer, subsequent operations may be performed.
  • a higher layer e.g., MAC layer
  • Figure 73 is a flowchart illustrating a procedure for notifying information about the point in time when transmission of DL data in the queue of a Serving AP MLD ends in MLD roaming according to the present embodiment.
  • FIG. 73 An example of Fig. 73 can be performed in a network environment that supports a next-generation wireless LAN system (UHR (Ultra High Reliability) wireless LAN system or next wi-fi).
  • the next-generation wireless LAN system is a wireless LAN system that improves on the 802.11be system and can satisfy backward compatibility with the 802.11be system.
  • the present embodiment proposes a method for determining a time point for transitioning from the Serving AP MLD to the Target AP MLD by notifying the time point when all DL data (or DL packets) remain in the queue of the Serving AP MLD when MLD roaming is performed through a roaming response frame.
  • step S7310 the first AP belonging to the first AP MLD receives a roaming request frame from a non-AP STA (station) belonging to the non-AP MLD.
  • step S7320 the first AP transmits a roaming response frame to the non-AP STA.
  • Whether to transition from the first AP MLD to the second AP MLD is determined based on the roaming response frame.
  • the roaming response frame includes first information about whether there is DL (downlink) data remaining in the queue of the first AP MLD and second information about the DL data transmitted from the first AP MLD.
  • the point in time at which transmission of the DL data ends is determined.
  • the DL data may remain in the queue of the first AP MLD. Based on the first information being set to 0, the DL data may no longer be in the queue of the first AP MLD.
  • the second information may include information about the size of the DL data, the number of MSDUs (MAC Service Data Units) that have not yet been transmitted, information about a Sequence Number (SN) or a Packet Number (PN), and information about a Traffic IDentifier (TID) that identifies a pending MSDU.
  • the information about the SN or PN may be the SN or PN of the last MSDU in the MSDU.
  • the TID may be set to a bitmap whose size is the number of the pending MSDUs.
  • the first information is set to 1
  • the DL data remains in the queue of the first AP MLD
  • the non-AP STA can determine when the transmission of the DL data ends.
  • a transition is performed from the first AP MLD to the second AP MLD.
  • the non-AP STA can immediately start DL or UL (uplink) transmission with the second AP MLD after receiving the roaming response frame.
  • the roaming response frame may further include third information about a channel switch count.
  • the third information may be information about a time point at which a first link connected to the first AP MLD (or a first AP belonging to the first AP MLD) is transitioned to a second link connected to the second AP MLD (or a second AP belonging to the second AP MLD).
  • the channel of the first link and the channel of the second link may be different from each other. If the channels of the first and second links are the same, the non-AP STA can know the time point at which a transition from the first link to the second link is made even without the third information.
  • the above roaming response frame may include a common information field and a link information field.
  • the third information may be included in the common information field. That is, the first AP MLD may include the third information in the common information field to inform of the common time of transition for each link.
  • the third information may be included in the link information field based on the fact that the timing of transition to a link connected to the second AP MLD is different for each link connected to the second AP MLD. That is, the first AP MLD may include the third information in the link information field to individually inform the timing of transition for each link.
  • a timer for the DL data may be set based on the first information being set to 1 and the second information. Transmission of the DL data may be ended based on the timer for the DL data expiring. After the transmission of the DL data is completed and a transition is performed from the first AP MLD to the second AP MLD, the non-AP STA may transmit and receive DL data or UL data with the second AP MLD.
  • the present embodiment proposes a method for determining the time point of transition from the Serving AP MLD to the Target AP MLD by notifying the time point when all DL data remaining in the queue of the Serving AP MLD during the process of performing MLD roaming, through a roaming response frame, is transmitted. Since a Non-AP STA can confirm the time point when all DL data remaining in the queue of the Serving AP MLD are transmitted, there is an effect that MLD roaming can be efficiently performed.
  • the non-AP STA can receive information that the transfer of the context has been completed from the second AP belonging to the second AP MLD.
  • the non-AP STA can perform roaming from the first AP to the second AP based on the roaming request frame and the roaming response frame.
  • the first and second AP MLDs are included in a roaming-enabled group.
  • the first AP may be affiliated with the first AP MLD, and the second AP may be affiliated with the second AP MLD.
  • a non-AP STA may be affiliated with the non-AP MLD.
  • the first AP may be referred to as Old AP (O_AP), Serving AP, or Current AP.
  • the second AP may be referred to as New AP (N_AP) or Target AP.
  • the first AP MLD including the first AP may be referred to as Serving AP MLD.
  • the second AP MLD including the second AP may be referred to as Target AP MLD.
  • MLD roaming from the Serving AP MLD to the Target AP MLD is defined as an operation of seamlessly moving from one AP to another without any disconnection between the AP and the STA within the MLD.
  • the above roaming-enabled group may be referred to as a UHR AP MLD.
  • the first and second AP MLDs are non-collocated, but are included in the same roaming-enabled group, so roaming (or movement) from an AP in the first AP MLD to an AP in the second AP MLD may be possible.
  • the APs in the first AP MLD are collocated.
  • the APs in the second AP MLD are also collocated.
  • the MLD-based architecture refers to a case where all AP MLDs have a single medium access control (MAC) service access point (SAP) in a single domain called SMD (Single Mobility Domain).
  • SAP medium access control
  • the MLD-based architecture has a common AP MLD upper MAC interfaced to all AP MLDs capable of performing seamless roaming.
  • the UMAC of the UFT AP MLD controls all UMAC functions required for seamless roaming and has its own MAC SAP and unique MLD MAC address. Since the MLD-based architecture is a centralized architecture, contexts are not transferred through the DS (Distribution System), and context transfer may not exist.
  • This context-passing-based architecture is an improved roaming architecture that utilizes existing architectures (specifically, existing Fast Transition (FT)).
  • FT Fast Transition
  • This method requires context-passing between the serving AP MLD and the target AP MLD.
  • Each AP MLD has its own MAC SAP.
  • Each AP MLD is individually mapped to a DS, and non-AP MLDs are associated with an AP MLD.
  • a non-AP MLD roams from the serving AP MLD to the target AP MLD, it should roam without re-authentication and re-association.
  • a security key e.g., a single MAC address for SMD
  • a security key must be shared among AP MLDs within the same single domain.
  • the MLD-based architecture offers virtually no delay, but requires architectural changes and is more complex to implement. Security keys are generated in the roaming MLD and shared with affiliated AP MLDs. In contrast, roaming with context transfer introduces some delay, which may worsen over other channels. However, it maintains the current architecture and offers simpler implementation. Security keys are shared over a secure channel. Therefore, the MLD-based architecture is the preferred scenario because it satisfies the goal of seamless roaming with virtually no delay. However, implementation can be challenging due to the architectural changes, and a context transfer-based architecture can be used for ease of implementation.
  • the first AP MLD, the second AP MLD, and the roaming-enabled group may be connected to a Distribution System (DS).
  • DS Distribution System
  • the context may be transmitted to the second AP MLD via the DS.
  • the above context may be referred to as a parameter set negotiated between an AP and an STA (or between a non-AP MLD STA and a Serving AP MLD).
  • the DS may be a backbone network for a wireless LAN that extends a wireless network by providing connectivity between different BSSs (Basic Service Sets).
  • BSSs Basic Service Sets
  • the above roaming request frame may be defined based on a Reconfiguration Multi-link Information Element (IE).
  • IE Reconfiguration Multi-link Information Element
  • the above roaming response frame may be defined based on either a Reconfiguration Multi-link IE or a Basic Multi-link IE.
  • a roaming reason code may be included in the first common information field or the first link information field of the roaming request frame. Additionally, a roaming reason code may be included in the second common information field or the second link information field of the roaming response frame.
  • the reason for recommending roaming to the AP may not be specified.
  • the reason for recommending roaming to the AP may be excessive frame loss rate or poor conditions.
  • the reason for recommending roaming to the AP may be excessive delay for the current traffic stream.
  • the reason for recommending roaming to the AP may be insufficient Quality of Service (QoS) capacity for the current traffic stream.
  • QoS Quality of Service
  • the reason for recommending roaming to the AP may be discovery of a better link.
  • the reason for recommending roaming to the AP may be the discovery of a better AP.
  • the reason for recommending roaming to the AP may be the receipt of too many replay counter failures.
  • the reason for recommending roaming to the AP may be the receipt of too many data MIC (Message Integrity Code) failures.
  • the reason for recommending roaming to the AP may be the exceeding of the maximum number of retransmissions.
  • the reason for recommending roaming to the AP may be the receipt of too many broadcast disassociations.
  • the reason for recommending roaming to the above AP may be that too many broadcast de-authentications are being received.
  • the reason for recommending roaming to the AP may be a previous roaming failure.
  • the reason for recommending roaming to the AP may be a low Received Signal Strength Indication (RSSI).
  • RSSI Received Signal Strength Indication
  • the reason for recommending roaming to the AP may be a switch due to a received roaming request frame.
  • the reason for recommending roaming to the AP may be inclusion in a recommended roaming list.
  • the reason for recommending roaming to the AP may be reserved.
  • Fig. 74 is a flowchart illustrating a procedure for receiving information about the point in time when transmission of DL data in the queue of a Serving AP MLD ends in MLD roaming according to the present embodiment.
  • FIG. 74 An example of Fig. 74 can be performed in a network environment that supports a next-generation wireless LAN system (UHR (Ultra High Reliability) wireless LAN system or next wi-fi).
  • the next-generation wireless LAN system is a wireless LAN system that improves the 802.11be system and can satisfy backward compatibility with the 802.11be system.
  • the present embodiment proposes a method for determining a time point for transitioning from the Serving AP MLD to the Target AP MLD by notifying the time point when all DL data (or DL packets) remain in the queue of the Serving AP MLD when MLD roaming is performed through a roaming response frame.
  • a non-AP STA (station) belonging to the non-AP MLD transmits a roaming request frame to the first AP belonging to the first AP MLD.
  • the non-AP STA receives a roaming response frame from the first AP.
  • the non-AP STA determines whether to transition from the first AP MLD to the second AP MLD based on the roaming response frame.
  • the roaming response frame includes first information about whether DL (downlink) data remains in the queue of the first AP MLD and second information about the DL data transmitted from the first AP MLD.
  • the point in time at which transmission of the DL data ends is determined.
  • the DL data may remain in the queue of the first AP MLD. Based on the first information being set to 0, the DL data may no longer be in the queue of the first AP MLD.
  • the second information may include information about the size of the DL data, the number of MSDUs (MAC Service Data Units) that have not yet been transmitted, information about a Sequence Number (SN) or a Packet Number (PN), and information about a Traffic IDentifier (TID) that identifies a pending MSDU.
  • the information about the SN or PN may be the SN or PN of the last MSDU in the MSDU.
  • the TID may be set to a bitmap whose size is the number of the pending MSDUs.
  • the first information is set to 1
  • the DL data remains in the queue of the first AP MLD
  • the non-AP STA can determine when the transmission of the DL data ends.
  • a transition is performed from the first AP MLD to the second AP MLD.
  • the non-AP STA can immediately start DL or UL (uplink) transmission with the second AP MLD after receiving the roaming response frame.
  • the roaming response frame may further include third information about a channel switch count.
  • the third information may be information about a time point at which a first link connected to the first AP MLD (or a first AP belonging to the first AP MLD) is transitioned to a second link connected to the second AP MLD (or a second AP belonging to the second AP MLD).
  • the channel of the first link and the channel of the second link may be different from each other. If the channels of the first and second links are the same, the non-AP STA can know the time point at which a transition from the first link to the second link is made even without the third information.
  • the above roaming response frame may include a common information field and a link information field.
  • the third information may be included in the common information field. That is, the first AP MLD may include the third information in the common information field to inform of the common time of transition for each link.
  • the third information may be included in the link information field based on the fact that the timing of transition to the link connected to the second AP MLD is different for each link connected to the second AP MLD. That is, the first AP MLD may include the third information in the link information field to individually inform the timing of transition for each link.
  • a timer for the DL data may be set based on the first information being set to 1 and the second information. Transmission of the DL data may be ended based on the timer for the DL data expiring. After the transmission of the DL data is completed and a transition is performed from the first AP MLD to the second AP MLD, the non-AP STA may transmit and receive DL data or UL data with the second AP MLD.
  • the present embodiment proposes a method for determining the time point of transition from the Serving AP MLD to the Target AP MLD by notifying the time point when all DL data remaining in the queue of the Serving AP MLD during the process of performing MLD roaming, through a roaming response frame, is transmitted. Since a Non-AP STA can confirm the time point when all DL data remaining in the queue of the Serving AP MLD are transmitted, there is an effect that MLD roaming can be efficiently performed.
  • the non-AP STA can receive information that the transfer of the context has been completed from the second AP belonging to the second AP MLD.
  • the non-AP STA can perform roaming from the first AP to the second AP based on the roaming request frame and the roaming response frame.
  • the first and second AP MLDs are included in a roaming-enabled group.
  • the first AP may be affiliated with the first AP MLD, and the second AP may be affiliated with the second AP MLD.
  • a non-AP STA may be affiliated with the non-AP MLD.
  • the first AP may be referred to as Old AP (O_AP), Serving AP, or Current AP.
  • the second AP may be referred to as New AP (N_AP) or Target AP.
  • the first AP MLD including the first AP may be referred to as Serving AP MLD.
  • the second AP MLD including the second AP may be referred to as Target AP MLD.
  • MLD roaming from the Serving AP MLD to the Target AP MLD is defined as an operation of seamlessly moving from one AP to another without any disconnection between the AP and the STA within the MLD.
  • the above roaming-enabled group may be referred to as a UHR AP MLD.
  • the first and second AP MLDs are non-collocated, but are included in the same roaming-enabled group, so roaming (or movement) from an AP in the first AP MLD to an AP in the second AP MLD may be possible.
  • the APs in the first AP MLD are collocated.
  • the APs in the second AP MLD are also collocated.
  • the MLD-based architecture refers to a case where all AP MLDs have a single medium access control (MAC) service access point (SAP) in a single domain called SMD (Single Mobility Domain).
  • SAP medium access control
  • the MLD-based architecture has a common AP MLD upper MAC interfaced to all AP MLDs capable of performing seamless roaming.
  • the UMAC of the UFT AP MLD controls all UMAC functions required for seamless roaming and has its own MAC SAP and unique MLD MAC address. Since the MLD-based architecture is a centralized architecture, contexts are not transferred through the DS (Distribution System), and context transfer may not exist.
  • This context-passing-based architecture is an improved roaming architecture that utilizes existing architectures (specifically, existing Fast Transition (FT)).
  • FT Fast Transition
  • This method requires context-passing between the serving AP MLD and the target AP MLD.
  • Each AP MLD has its own MAC SAP.
  • Each AP MLD is individually mapped to a DS, and non-AP MLDs are associated with an AP MLD.
  • a non-AP MLD roams from the serving AP MLD to the target AP MLD, it should roam without re-authentication and re-association.
  • a security key e.g., a single MAC address for SMD
  • a security key must be shared among AP MLDs within the same single domain.
  • the MLD-based architecture offers virtually no delay, but requires architectural changes and is more complex to implement. Security keys are generated in the roaming MLD and shared with affiliated AP MLDs. In contrast, roaming with context transfer introduces some delay, which may worsen over other channels. However, it maintains the current architecture and offers simpler implementation. Security keys are shared over a secure channel. Therefore, the MLD-based architecture is the preferred scenario because it satisfies the goal of seamless roaming with virtually no delay. However, implementation can be challenging due to the architectural changes, and a context transfer-based architecture can be used for ease of implementation.
  • the first AP MLD, the second AP MLD, and the roaming-enabled group may be connected to a Distribution System (DS).
  • DS Distribution System
  • the context may be transmitted to the second AP MLD via the DS.
  • the above context may be referred to as a parameter set negotiated between an AP and an STA (or between a non-AP MLD STA and a Serving AP MLD).
  • the DS may be a backbone network for a wireless LAN that extends a wireless network by providing connectivity between different BSSs (Basic Service Sets).
  • BSSs Basic Service Sets
  • the above roaming request frame may be defined based on a Reconfiguration Multi-link Information Element (IE).
  • IE Reconfiguration Multi-link Information Element
  • the above roaming response frame may be defined based on either a Reconfiguration Multi-link IE or a Basic Multi-link IE.
  • a roaming reason code may be included in the first common information field or the first link information field of the roaming request frame. Additionally, a roaming reason code may be included in the second common information field or the second link information field of the roaming response frame.
  • the reason for recommending roaming to the AP may not be specified.
  • the reason for recommending roaming to the AP may be excessive frame loss rate or poor conditions.
  • the reason for recommending roaming to the AP may be excessive delay for the current traffic stream.
  • the reason for recommending roaming to the AP may be insufficient Quality of Service (QoS) capacity for the current traffic stream.
  • QoS Quality of Service
  • the reason for recommending roaming to the AP may be discovery of a better link.
  • the reason for recommending roaming to the AP may be the discovery of a better AP.
  • the reason for recommending roaming to the AP may be the receipt of too many replay counter failures.
  • the reason for recommending roaming to the AP may be the receipt of too many data MIC (Message Integrity Code) failures.
  • the reason for recommending roaming to the AP may be the exceeding of the maximum number of retransmissions.
  • the reason for recommending roaming to the AP may be the receipt of too many broadcast disassociations.
  • the reason for recommending roaming to the above AP may be that too many broadcast de-authentications are being received.
  • the reason for recommending roaming to the AP may be a previous roaming failure.
  • the reason for recommending roaming to the AP may be a low Received Signal Strength Indication (RSSI).
  • RSSI Received Signal Strength Indication
  • the reason for recommending roaming to the AP may be a switch due to a received roaming request frame.
  • the reason for recommending roaming to the AP may be inclusion in a recommended roaming list.
  • the reason for recommending roaming to the AP may be reserved.
  • the technical features of the present specification described above can be applied to various devices and methods.
  • the technical features of the present specification described above can be performed/supported by the devices of FIG. 1 and/or FIG. 14.
  • the technical features of the present specification described above can be applied only to a part of FIG. 1 and/or FIG. 14.
  • the technical features of the present specification described above can be implemented based on the processing chip (114, 124) of FIG. 1, or based on the processor (111, 121) and the memory (112, 122) of FIG. 1, or based on the processor (610) and the memory (620) of FIG. 14.
  • the device of the present specification transmits a roaming request frame to a first AP belonging to a first AP (access point) multi-link device (MLD); receives a roaming response frame from the first AP; And based on the roaming response frame, it is determined whether to transition from the first AP MLD to the second AP MLD.
  • AP access point
  • MLD multi-link device
  • the technical features of this specification can be implemented based on a computer-readable medium (CRM).
  • CRM computer-readable medium
  • the CRM proposed by this specification is at least one computer-readable recording medium containing instructions that are executed by at least one processor.
  • the CRM may store instructions for performing operations including the steps of transmitting a Roaming Request frame to a first AP belonging to a first AP (access point) MLD (multi-link device); receiving a Roaming Response frame from the first AP; and determining whether to transition from the first AP MLD to a second AP MLD based on the Roaming Response frame.
  • the instructions stored in the CRM of the present specification may be executed by at least one processor.
  • At least one processor related to the CRM of the present specification may be the processor (111, 121) or the processing chip (114, 124) of FIG. 1, or the processor (610) of FIG. 14.
  • the CRM of this specification may be the memory (112, 122) of FIG. 1, the memory (620) of FIG. 14, or a separate external memory/storage medium/disk, etc.
  • the technical features of this specification described above are applicable to various applications and business models.
  • the technical features described above can be applied to wireless communication in devices that support artificial intelligence (AI).
  • AI artificial intelligence
  • AI Artificial intelligence
  • ML machine learning
  • Machine learning is also defined as an algorithm that improves performance on a task through consistent experience.
  • An artificial neural network is a model used in machine learning. It can refer to a model with problem-solving capabilities, consisting of artificial neurons (nodes) formed by the connection of synapses to form a network.
  • An ANN can be defined by the connection patterns between neurons in different layers, the learning process that updates model parameters, and the activation function that generates output values.
  • An artificial neural network may include an input layer, an output layer, and optionally one or more hidden layers. Each layer contains one or more neurons, and the artificial neural network may include synapses connecting neurons. In an artificial neural network, each neuron can output a function value of an activation function based on input signals, weights, and biases received through the synapses.
  • Model parameters are parameters determined through learning, including synaptic connection weights and neuron biases.
  • Hyperparameters are parameters that must be set before learning in machine learning algorithms, including the learning rate, number of iterations, mini-batch size, and initialization function.
  • the goal of artificial neural network training can be seen as determining model parameters that minimize a loss function.
  • the loss function can be used as an indicator for determining optimal model parameters during the artificial neural network training process.
  • Machine learning can be classified into supervised learning, unsupervised learning, and reinforcement learning depending on the learning method.
  • Supervised learning refers to a method for training an artificial neural network when given labels for the training data.
  • the labels can refer to the correct answer (or output value) that the artificial neural network must infer when the training data is input to the artificial neural network.
  • Unsupervised learning can refer to a method for training an artificial neural network when the training data is not given labels.
  • Reinforcement learning can refer to a learning method in which an agent defined within a given environment is trained to select actions or action sequences that maximize the cumulative reward in each state.
  • Machine learning implemented with a deep neural network (DNN) containing multiple hidden layers among artificial neural networks is also called deep learning, and deep learning is a subset of machine learning.
  • machine learning is used to encompass deep learning.
  • a robot can be defined as a machine that automatically performs or operates a given task based on its own capabilities. Specifically, a robot capable of perceiving its environment, making independent judgments, and performing actions can be called an intelligent robot.
  • Robots can be categorized into industrial, medical, household, and military applications based on their intended use or field. Robots are equipped with actuators or motors, enabling them to perform various physical actions, such as moving robot joints. Furthermore, mobile robots incorporate wheels, brakes, and propellers into their actuators, enabling them to move on the ground or fly in the air.
  • Extended reality is a general term for virtual reality (VR), augmented reality (AR), and mixed reality (MR).
  • VR technology presents real-world objects and backgrounds as CG images only
  • AR technology presents virtual CG images over images of real objects
  • MR technology is a computer graphics technology that blends and combines virtual objects with the real world.
  • MR technology is similar to AR in that it presents both real and virtual objects simultaneously. However, while AR uses virtual objects to complement real objects, MR uses virtual and real objects on an equal footing.
  • XR technology can be applied to HMD (Head-Mount Display), HUD (Head-Up Display), mobile phones, tablet PCs, laptops, desktops, TVs, digital signage, etc., and devices to which XR technology is applied can be called XR devices.
  • HMD Head-Mount Display
  • HUD Head-Up Display
  • mobile phones tablet PCs, laptops, desktops, TVs, digital signage, etc.
  • XR devices devices to which XR technology is applied.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

무선랜 시스템에서 Serving AP MLD의 큐에 있는 DL 데이터의 송신이 끝나는 시점에 대한 정보를 알려주는 방법 및 장치가 제안된다. 구체적으로, non-AP MLD에 소속된 non-AP STA은 제1 AP MLD에 소속된 제1 AP에게 로밍 요청 프레임을 송신한다. non-AP STA은 제1 AP로부터 로밍 응답 프레임을 수신한다. non-AP STA은 로밍 응답 프레임을 기반으로 제1 AP MLD에서 제2 AP MLD로 전이할지 여부를 결정한다.

Description

무선랜 시스템에서 SERVING AP MLD의 큐에 있는 DL 데이터의 송신이 끝나는 시점에 대한 정보를 알려주는 방법 및 장치
본 명세서는 무선랜 시스템에서 Serving AP MLD의 큐에 있는 DL 데이터의 송신이 끝나는 시점에 대한 정보를 알려주는 기법에 관한 것으로, 보다 상세하게는, MLD 로밍이 수행될 때 Serving AP MLD의 큐에 DL 데이터(또는 DL 패킷)가 남아 있는 경우, 상기 DL 데이터가 모두 송신되는 시점을 로밍 응답 프레임을 통해 알려주어 상기 Serving AP MLD에서 Target AP MLD로 전이되는 시점을 결정하는 방법 및 장치에 관한 것이다.
WLAN(wireless local area network)은 다양한 방식으로 개선되어왔다. 예를 들어, IEEE 802.11ax 표준은 OFDMA(orthogonal frequency division multiple access) 및 DL MU MIMO(downlink multi-user multiple input, multiple output) 기법을 사용하여 개선된 통신 환경을 제안했다.
본 명세서는 새로운 통신 표준에서 활용 가능한 기술적 특징을 제안한다. 예를 들어, 새로운 통신 표준은 최근에 논의 중인 EHT(Extreme high throughput) 규격일 수 있다. EHT 규격은 새롭게 제안되는 증가된 대역폭, 개선된 PPDU(PHY layer protocol data unit) 구조, 개선된 시퀀스, HARQ(Hybrid automatic repeat request) 기법 등을 사용할 수 있다. EHT 규격은 IEEE 802.11be 규격으로 불릴 수 있다.
새로운 무선랜 규격에서는 증가된 개수의 공간 스트림이 사용될 수 있다. 이 경우, 증가된 개수의 공간 스트림을 적절히 사용하기 위해 무선랜 시스템 내에서의 시그널링 기법이 개선되어야 할 수 있다.
본 명세서는 무선랜 시스템에서 Serving AP MLD의 큐에 있는 DL 데이터의 송신이 끝나는 시점에 대한 정보를 알려주는 방법 및 장치를 제안한다.
본 명세서의 일례는 Serving AP MLD의 큐에 있는 DL 데이터의 송신이 끝나는 시점에 대한 정보를 알려주는 방법을 제안한다.
본 실시예는 차세대 무선랜 시스템(UHR(Ultra High Reliability) 무선랜 시스템 또는 next wi-fi)이 지원되는 네트워크 환경에서 수행될 수 있다. 상기 차세대 무선랜 시스템은 802.11be 시스템을 개선한 무선랜 시스템으로 802.11be 시스템과 하위 호환성(backward compatibility)을 만족할 수 있다.
본 실시예는 MLD 로밍이 수행될 때 Serving AP MLD의 큐에 DL 데이터(또는 DL 패킷)가 남아 있는 경우, 상기 DL 데이터가 모두 송신되는 시점을 로밍 응답 프레임을 통해 알려주어 상기 Serving AP MLD에서 Target AP MLD로 전이되는 시점을 결정하는 방법을 제안한다.
상기 non-AP MLD에 소속된 non-AP STA(station)은 제1 AP MLD에 소속된 제1 AP에게 로밍 요청 프레임(Roaming Request frame)을 송신한다.
상기 non-AP STA은 상기 제1 AP로부터 로밍 응답 프레임(Roaming Response frame)을 수신한다.
상기 non-AP STA은 상기 로밍 응답 프레임을 기반으로 상기 제1 AP MLD에서 제2 AP MLD로 전이(transition)할지 여부를 결정한다.
상기 로밍 응답 프레임은 상기 제1 AP MLD의 큐(queue)에 DL(downlink) 데이터가 남아있는지 여부에 대한 제1 정보 및 상기 제1 AP MLD로부터 송신되는 상기 DL 데이터에 대한 제2 정보를 포함한다.
상기 제1 정보가 1로 설정되는 것과 상기 제2 정보에 기초하여, 상기 DL 데이터의 송신이 끝나는 시점이 결정된다.
상기 제1 정보가 1로 설정되는 것에 기초하여, 상기 제1 AP MLD의 큐에 상기 DL 데이터가 남아있을 수 있다. 상기 제1 정보가 0으로 설정되는 것에 기초하여, 상기 제1 AP MLD의 큐에 상기 DL 데이터가 더 이상 없을 수 있다.
상기 제2 정보는 상기 DL 데이터의 크기, 아직 송신되지 않은 MSDU(MAC Service Data Unit)의 개수, SN(Sequence Number) 또는 PN(Packet Number)에 관한 정보, 및 펜딩(pending) 중인 MSDU를 식별하는 TID(Traffic IDentifiers)에 대한 정보를 포함할 수 있다. 상기 SN 또는 PN에 관한 정보는 상기 MSDU에서 마지막 MSDU의 SN 또는 PN일 수 있다. 상기 TID는 상기 펜딩 중이 MSDU의 개수를 크기로 하는 비트맵으로 설정될 수 있다.
즉, 상기 제1 정보가 1로 설정되어 상기 제1 AP MLD의 큐에 상기 DL 데이터가 남아있고, 상기 DL 데이터에 대한 정보를 기반으로 상기 non-AP STA은 상기 DL 데이터의 송신이 끝나는 시점을 알 수 있다. 이때, 상기 DL 데이터의 송신이 끝나는 시점을 기반으로, 상기 제1 AP MLD에서 상기 제2 AP MLD로 전이가 수행된다.
즉, 본 실시예는 MLD 로밍을 수행하는 과정에서 Serving AP MLD의 큐에 DL 데이터가 남아 있는 경우, 상기 DL 데이터가 모두 송신되는 시점을 로밍 응답 프레임을 통해 알려주어 상기 Serving AP MLD에서 Target AP MLD로 전이되는 시점을 결정하는 방법을 제안한다.
본 명세서에서 제안하는 실시예에 따르면, Non-AP STA은 상기 Serving AP MLD의 큐에 존재하는 상기 DL 데이터가 모두 송신되는 시점을 확인할 수 있어, MLD 로밍을 효율적으로 수행할 수 있다는 효과가 있다.
도 1은 본 명세서의 송신 장치 및/또는 수신 장치의 일례를 나타낸다.
도 2는 무선랜(WLAN)의 구조를 나타낸 개념도이다.
도 3은 일반적인 링크 셋업(link setup) 과정을 설명하는 도면이다.
도 4는 멀티 링크(Multi-link; ML)의 일 실시예를 설명한다.
도 5는 본 명세서의 STA에서 송신/수신되는 PPDU(physical protocol data unit 또는 physical layer (PHY) protocol data unit)가 설명된다.
도 6은 20MHz PPDU를 위해 사용되는 자원유닛(RU)의 배치를 나타내는 도면이다.
도 7은 40MHz PPDU를 위해 사용되는 자원유닛(RU)의 배치를 나타내는 도면이다.
도 8은 80MHz PPDU를 위해 사용되는 자원유닛(RU)의 배치를 나타내는 도면이다.
도 9는 UL-MU에 따른 동작을 나타낸다.
도 10은 2.4 GHz 밴드 내에서 사용/지원/정의되는 채널의 일례를 나타낸다.
도 11은 5 GHz 밴드 내에서 사용/지원/정의되는 채널의 일례를 도시한다.
도 12는 6 GHz 밴드 내에서 사용/지원/정의되는 채널의 일례를 도시한다.
도 13은 MAC 프레임의 헤더의 일례를 나타낸다.
도 14는 본 명세서의 송신 장치 및/또는 수신 장치의 변형된 일례를 나타낸다.
도 15는 RSN(Robust Security Network)에서 OTA(Over-the-air) FT 프로토콜을 도시한다.
도 16은 AP MLD에 대한 High-level Architecture를 도시한다.
도 17은 UHR AP MLD에 대한 High-level Architecture의 일례를 도시한다.
도 18은 UHR AP MLD에 대한 High-level Architecture의 다른 예를 도시한다.
도 19는 UHR AP MLD에 대한 High-level Architecture의 또 다른 예를 도시한다.
도 20은 MLD based가 아닌 entity만 있는 경우 High-level Architecture의 일례를 도시한다.
도 21은 MLD based가 아닌 entity만 있는 경우 High-level Architecture의 다른 예를 도시한다.
도 22는 AP MLD 영역에서 Roaming Architecture의 일례를 도시한다.
도 23은 RNR IE에 대한 일례를 나타낸다.
도 24는 RNR IE에 대한 다른 예를 나타낸다.
도 25는 RNR IE에 대한 또 다른 예를 나타낸다.
도 26은 Common Info field에서의 AP Roaming Recommendation enabled field와 Roaming Reason Code field의 일례를 도시한다.
도 27은 Link Info field에서의 AP Roaming Recommendation enabled field의 일례를 도시한다.
도 28은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Common Info field의 일례를 도시한다.
도 29는 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field의 일례를 도시한다.
도 30은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Common Info field에 UHR AP MLD ID와 AP MLD ID가 포함되는 일례를 도시한다.
도 31은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Common Info field에 AP MLD ID가 포함되는 일례를 도시한다.
도 32는 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field에 UHR AP MLD ID와 AP MLD ID가 포함되는 일례를 도시한다.
도 33은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field에 AP MLD ID가 포함되는 일례를 도시한다.
도 34는 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field에 UHR AP MLD ID와 AP MLD ID가 포함되는 다른 예를 도시한다.
도 35는 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field에 AP MLD ID가 포함되는 다른 예를 도시한다.
도 36은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Common Info field에 Temporary field가 포함되는 일례를 도시한다.
도 37은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field에 Temporary field가 포함되는 일례를 도시한다.
도 38은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field에 Temporary field가 포함되는 다른 예를 도시한다.
도 39는 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Common Info field에 AP Removal Timer 필드가 포함되는 일례를 도시한다.
도 40은 본 실시예에서 제안하는 Basic Multi-link IE의 Common Info field의 일례를 도시한다.
도 41은 본 실시예에서 제안하는 Basic Multi-link IE의 Link Info field의 일례를 도시한다.
도 42는 Group Key Information 필드의 일례를 도시한다.
도 43은 Collocation Enabled 필드를 사용하여 N_AP가 로밍이 가능한지 여부를 확인하는 절차를 도시한다.
도 44는 Collocation ID를 사용하여 N_AP가 로밍이 가능한지 여부를 확인하는 절차를 도시한다.
도 45는 Reconfiguration element에 UHR AP MLD ID가 들어가는 경우의 MLD Roaming 절차를 도시한다.
도 46은 Reconfiguration element에 UHR AP MLD ID가 들어가지 않는 경우의 MLD Roaming 절차를 도시한다.
도 47은 Collocated된 AP 집합의 일례를 도시한다.
도 48은 MLD Roaming 절차에 대한 예시 1을 도시한다.
도 49는 MLD Roaming 절차에 대한 예시 1의 동작 과정을 나타낸다.
도 50은 MLD Roaming 절차에 대한 예시 2를 도시한다.
도 51은 MLD Roaming 절차에 대한 예시 2의 동작 과정을 나타낸다.
도 52는 MLD Roaming 절차에 대한 예시 3을 도시한다.
도 53은 MLD Roaming 절차에 대한 예시 3의 동작 과정을 나타낸다.
도 54는 MLD Roaming 절차에 대한 예시 4를 도시한다.
도 55는 MLD Roaming 절차에 대한 예시 3과 4의 동작 과정을 나타낸다.
도 56은 MLD Roaming 절차에 대한 예시 5를 도시한다.
도 57은 MLD Roaming 절차에 대한 예시 6을 도시한다.
도 58은 TIM을 활용한 MLD Roaming의 일례를 나타낸다.
도 59는 TIM을 활용한 MLD Roaming 절차에 대한 동작 과정을 나타낸다.
도 60은 Context transfer를 이용한 Roaming Procedure의 일례(Entity만 존재)를 도시한다.
도 61은 Context transfer를 이용한 로밍 과정의 일례를 도시한다.
도 62는 Context transfer를 이용한 로밍 과정의 다른 예를 도시한다.
도 63은 Serving AP MLD의 queue에 쌓여있는 DL Data를 송신하는 일례를 도시한다.
도 64는 Serving AP MLD의 queue에 쌓여있는 DL Data의 송신 완료를 DL Timer로 알려주는 절차를 도시한다.
도 65는 Roaming Procedure의 Baseline의 일례를 도시한다.
도 66은 Roaming Procedure의 Baseline #1의 일례를 도시한다.
도 67은 Roaming Procedure의 Baseline #2의 일례를 도시한다.
도 68은 Roaming Procedure의 Baseline #3의 일례를 도시한다.
도 69는 Roaming Procedure의 Baseline #4의 일례를 도시한다.
도 70은 Target AP MLD와의 link establishment의 순서를 설명하는 일례를 도시한다.
도 71은 본 실시예에 따른 송신 장치의 동작을 나타낸 절차 흐름도이다.
도 72는 본 실시예에 따른 수신 장치의 동작을 나타낸 절차 흐름도이다.
도 73은 본 실시예에 따른 MLD 로밍에서 Serving AP MLD의 큐에 있는 DL 데이터의 송신이 끝나는 시점에 대한 정보를 알려주는 절차를 도시한 흐름도이다.
도 74는 본 실시예에 따른 MLD 로밍에서 Serving AP MLD의 큐에 있는 DL 데이터의 송신이 끝나는 시점에 대한 정보를 수신하는 절차를 도시한 흐름도이다.
본 명세서에서 “A 또는 B(A or B)”는 “오직 A”, “오직 B” 또는 “A와 B 모두”를 의미할 수 있다. 달리 표현하면, 본 명세서에서 “A 또는 B(A or B)”는 “A 및/또는 B(A and/or B)”으로 해석될 수 있다. 예를 들어, 본 명세서에서 “A, B 또는 C(A, B or C)”는 “오직 A”, “오직 B”, “오직 C”또는 “A, B 및 C의 임의의 모든 조합(any combination of A, B and C)”를 의미할 수 있다.
본 명세서에서 사용되는 슬래쉬(/)나 쉼표(comma)는 “및/또는(and/or)”을 의미할 수 있다. 예를 들어, “A/B”는 “및/또는 B”를 의미할 수 있다. 이에 따라, “A/B”는 “오직 A”, “오직 B”, 또는 “A와 B 모두”를 의미할 수 있다. 예를 들어, “A, B, C”는 “A, B 또는 C”를 의미할 수 있다.
본 명세서에서 “적어도 하나의 A 및 B(at least one of A and B)”는, “오직 A”“오직 B” 또는 “A와 B 모두”를 의미할 수 있다. 또한, 본 명세서에서 “적어도 하나의 A 또는 B(at least one of A or B)”나 “적어도 하나의 A 및/또는 B(at least one of A and/or B)”라는 표현은 “적어도 하나의 A 및 B(at least one of A and B)”와 동일하게 해석될 수 있다.
또한, 본 명세서에서 사용되는 괄호는 “예를 들어(for example)”를 의미할 수 있다. 구체적으로, “제어 정보(UHR-Signal 필드)”로 표시된 경우, “제어 정보”의 일례로 “UHR-Signal 필드”가 제안된 것일 수 있다. 달리 표현하면 본 명세서의 “제어 정보”는 상기 “UHR-Signal 필드”로 제한(limit)되지 않고, “UHR-Signal 필드”가 “제어 정보”의 일례로 제안될 것일 수 있다. 또한, “제어 정보(UHR-Signal 필드)”로 표시된 경우에도, “제어 정보”의 일례로 “UHR-Signal 필드”가 제안된 것일 수 있다.
또한, 본 명세서에서 사용되는 “a/an”은 “적어도 하나(at least one)”또는 “하나 또는 그 이상(one or more)”를 의미할 수 있다. 또한 “(s)”로 끝나는 용어는 “적어도 하나(at least one)”또는 “하나 또는 그 이상(one or more)”를 의미할 수 있다.
또한 본 명세서에서 사용하는 “기초로 하는(based on)”또는 “기반으로 하는(on the basis of)”또는 “에 따라(according to)”의 표현은 “적어도 기초로 하는(based at least in part on)”를 의미하며, “오로지 하나를 기반으로 하는(based sonly on)”을 의미하지 않는다.
본 명세서에서 하나의 도면 내에서 개별적으로 설명되는 기술적 특징은, 개별적으로 구현될 수도 있고, 동시에 구현될 수도 있다.
본 명세서의 이하의 일례는 다양한 무선 통신시스템에 적용될 수 있다. 예를 들어, 본 명세서의 이하의 일례는 무선랜(wireless local area network, WLAN) 시스템에 적용될 수 있다. 예를 들어, 본 명세서는 IEEE 802.11a/g/n/ac/ax/be/bn의 규격에 적용될 수 있다. 또한 본 명세서의 일례는 UHR(Ultra High Reliability)규격 또는 IEEE 802.11bn를 개선(enhance)한 차세대(next-generation) 무선랜 규격에도 적용될 수 있다. 또한 본 명세서의 일례는 이동 통신 시스템에 적용될 수 있다. 예를 들어, 3GPP(3rd Generation Partnership Project) 규격에 기반하는 LTE(Long Term Evolution) 및 그 진화(evolution)에 기반하는 이동 통신 시스템에 적용될 수 있다.
이하 본 명세서의 기술적 특징을 설명하기 위해 본 명세서가 적용될 수 있는 기술적 특징을 설명한다.
도 1은 본 명세서의 송신 장치 및/또는 수신 장치의 일례를 나타낸다.
도 1의 일례는 이하에서 설명되는 다양한 기술적 특징을 수행할 수 있다. 도 1은 적어도 하나의 STA(station)에 관련된다. 예를 들어, 본 명세서의 STA(110, 120)은 이동 단말(mobile terminal), 무선 기기(wireless device), 무선 송수신 유닛(Wireless Transmit/Receive Unit; WTRU), 사용자 장비(User Equipment; UE), 이동국(Mobile Station; MS), 이동 가입자 유닛(Mobile Subscriber Unit) 또는 단순히 유저(user) 등의 다양한 명칭으로도 불릴 수 있다. 본 명세서의 STA(110, 120)은 네트워크, 기지국(Base Station), Node-B, AP(Access Point), 리피터, 라우터, 릴레이 등의 다양한 명칭으로 불릴 수 있다. 본 명세서의 STA(110, 120)은 수신 장치(apparatus), 송신 장치, 수신 STA, 송신 STA, 수신 Device, 송신 Device 등의 다양한 명칭으로 불릴 수 있다.
예를 들어, STA(110, 120)은 AP(access Point) 역할을 수행하거나 non-AP 역할을 수행할 수 있다. 즉, 본 명세서의 STA(110, 120)은 AP 및/또는 non-AP의 기능을 수행할 수 있다. 본 명세서에서 AP는 AP STA으로도 표시될 수 있다.
본 명세서의 STA(110, 120)은 IEEE 802.11 규격 이외의 다양한 통신 규격을 함께 지원할 수 있다. 예를 들어, 3GPP 규격에 따른 통신 규격(예를 들어, LTE, LTE-A, 5G NR 규격)등을 지원할 수 있다. 또한 본 명세서의 STA은 휴대 전화, 차량(vehicle), 개인용 컴퓨터 등의 다양한 장치로 구현될 수 있다. 또한, 본 명세서의 STA은 음성 통화, 영상 통화, 데이터 통신, 자율 주행(Self-Driving, Autonomous-Driving) 등의 다양한 통신 서비스를 위한 통신을 지원할 수 있다.
본 명세서에서 STA(110, 120)은 IEEE 802.11 표준의 규정을 따르는 매체 접속 제어(medium access control, MAC)와 무선 매체에 대한 물리 계층(Physical Layer) 인터페이스를 포함할 수 있다.
도 1의 부도면 (a)를 기초로 STA(110, 120)을 설명하면 이하와 같다.
제1 STA(110)은 프로세서(111), 메모리(112) 및 트랜시버(113)를 포함할 수 있다. 도시된 프로세서, 메모리 및 트랜시버는 각각 별도의 칩으로 구현되거나, 적어도 둘 이상의 블록/기능이 하나의 칩을 통해 구현될 수 있다.
제1 STA의 트랜시버(113)는 신호의 송수신 동작을 수행한다. 구체적으로, IEEE 802.11 패킷(예를 들어, IEEE 802.11a/b/g/n/ac/ax/be 등)을 송수신할 수 있다.
예를 들어, 제1 STA(110)은 AP의 의도된 동작을 수행할 수 있다. 예를 들어, AP의 프로세서(111)는 트랜시버(113)를 통해 신호를 수신하고, 수신 신호를 처리하고, 송신 신호를 생성하고, 신호 송신을 위한 제어를 수행할 수 있다. AP의 메모리(112)는 트랜시버(113)를 통해 수신된 신호(즉, 수신 신호)를 저장할 수 있고, 트랜시버를 통해 송신될 신호(즉, 송신 신호)를 저장할 수 있다.
예를 들어, 제2 STA(120)은 Non-AP STA의 의도된 동작을 수행할 수 있다. 예를 들어, non-AP의 트랜시버(123)는 신호의 송수신 동작을 수행한다. 구체적으로, IEEE 802.11 패킷(예를 들어, IEEE 802.11a/b/g/n/ac/ax/be 등)을 송수신할 수 있다.
예를 들어, Non-AP STA의 프로세서(121)는 트랜시버(123)를 통해 신호를 수신하고, 수신 신호를 처리하고, 송신 신호를 생성하고, 신호 송신을 위한 제어를 수행할 수 있다. Non-AP STA의 메모리(122)는 트랜시버(123)를 통해 수신된 신호(즉, 수신 신호)를 저장할 수 있고, 트랜시버를 통해 송신될 신호(즉, 송신 신호)를 저장할 수 있다.
예를 들어, 이하의 명세서에서 AP로 표시된 장치의 동작은 제1 STA(110) 또는 제2 STA(120)에서 수행될 수 있다. 예를 들어 제1 STA(110)이 AP인 경우, AP로 표시된 장치의 동작은 제1 STA(110)의 프로세서(111)에 의해 제어되고, 제1 STA(110)의 프로세서(111)에 의해 제어되는 트랜시버(113)를 통해 관련된 신호가 송신되거나 수신될 수 있다. 또한, AP의 동작에 관련된 제어 정보나 AP의 송신/수신 신호는 제1 STA(110)의 메모리(112)에 저장될 수 있다. 또한, 제2 STA(110)이 AP인 경우, AP로 표시된 장치의 동작은 제2 STA(120)의 프로세서(121)에 의해 제어되고, 제2 STA(120)의 프로세서(121)에 의해 제어되는 트랜시버(123)를 통해 관련된 신호가 송신되거나 수신될 수 있다. 또한, AP의 동작에 관련된 제어 정보나 AP의 송신/수신 신호는 제2 STA(110)의 메모리(122)에 저장될 수 있다.
예를 들어, 이하의 명세서에서 non-AP(또는 User-STA)로 표시된 장치의 동작은 제 STA(110) 또는 제2 STA(120)에서 수행될 수 있다. 예를 들어 제2 STA(120)이 non-AP인 경우, non-AP로 표시된 장치의 동작은 제2 STA(120)의 프로세서(121)에 의해 제어되고, 제2 STA(120)의 프로세서(121)에 의해 제어되는 트랜시버(123)를 통해 관련된 신호가 송신되거나 수신될 수 있다. 또한, non-AP의 동작에 관련된 제어 정보나 AP의 송신/수신 신호는 제2 STA(120)의 메모리(122)에 저장될 수 있다. 예를 들어 제1 STA(110)이 non-AP인 경우, non-AP로 표시된 장치의 동작은 제1 STA(110)의 프로세서(111)에 의해 제어되고, 제1 STA(120)의 프로세서(111)에 의해 제어되는 트랜시버(113)를 통해 관련된 신호가 송신되거나 수신될 수 있다. 또한, non-AP의 동작에 관련된 제어 정보나 AP의 송신/수신 신호는 제1 STA(110)의 메모리(112)에 저장될 수 있다.
이하의 명세서에서 (송신/수신) STA, 제1 STA, 제2 STA, STA1, STA2, AP, 제1 AP, 제2 AP, AP1, AP2, (송신/수신) Terminal, (송신/수신) device, (송신/수신) apparatus, 네트워크 등으로 불리는 장치는 도 1의 STA(110, 120)을 의미할 수 있다. 예를 들어, 구체적인 도면 부호 없이 (송신/수신) STA, 제1 STA, 제2 STA, STA1, STA2, AP, 제1 AP, 제2 AP, AP1, AP2, (송신/수신) Terminal, (송신/수신) device, (송신/수신) apparatus, 네트워크 등으로 표시된 장치도 도 1의 STA(110, 120)을 의미할 수 있다. 예를 들어, 이하의 일례에서 다양한 STA이 신호(예를 들어, PPDU)를 송수신하는 동작은 도 1의 트랜시버(113, 123)에서 수행되는 것일 수 있다. 또한, 이하의 일례에서 다양한 STA이 송수신 신호를 생성하거나 송수신 신호를 위해 사전에 데이터 처리나 연산을 수행하는 동작은 도 1의 프로세서(111, 121)에서 수행되는 것일 수 있다. 예를 들어, 송수신 신호를 생성하거나 송수신 신호를 위해 사전에 데이터 처리나 연산을 수행하는 동작의 일례는, 1) PPDU 내에 포함되는 서브 필드(SIG, STF, LTF, Data) 필드의 비트 정보를 결정/획득/구성/연산/디코딩/인코딩하는 동작, 2) PPDU 내에 포함되는 서브 필드(SIG, STF, LTF, Data) 필드를 위해 사용되는 시간 자원이나 주파수 자원(예를 들어, 서브캐리어 자원) 등을 결정/구성/회득하는 동작, 3) PPDU 내에 포함되는 서브 필드(SIG, STF, LTF, Data) 필드를 위해 사용되는 특정한 시퀀스(예를 들어, 파일럿 시퀀스, STF/LTF 시퀀스, SIG에 적용되는 엑스트라 시퀀스) 등을 결정/구성/회득하는 동작, 4) STA에 대해 적용되는 전력 제어 동작 및/또는 파워 세이빙 동작, 5) ACK 신호의 결정/획득/구성/연산/디코딩/인코딩 등에 관련된 동작을 포함할 수 있다. 또한, 이하의 일례에서 다양한 STA이 송수신 신호의 결정/획득/구성/연산/디코딩/인코딩을 위해 사용하는 다양한 정보(예를 들어, 필드/서브필드/제어필드/파라미터/파워 등에 관련된 정보)는 도 1의 메모리(112, 122)에 저장될 수 있다.
상술한 도 1의 부도면 (a)의 장치/STA는 도 1의 부도면 (b)와 같이 변형될 수 있다. 이하 도 1의 부도면 (b)을 기초로, 본 명세서의 STA(110, 120)을 설명한다.
예를 들어, 도 1의 부도면 (b)에 도시된 트랜시버(113, 123)는 상술한 도 1의 부도면 (a)에 도시된 트랜시버와 동일한 기능을 수행할 수 있다. 예를 들어, 도 1의 부도면 (b)에 도시된 프로세싱 칩(114, 124)은 프로세서(111, 121) 및 메모리(112, 122)를 포함할 수 있다. 도 1의 부도면 (b)에 도시된 프로세서(111, 121) 및 메모리(112, 122)는 상술한 도 1의 부도면 (a)에 도시된 프로세서(111, 121) 및 메모리(112, 122)와 동일한 기능을 수행할 수 있다.
이하에서 설명되는, 이동 단말(mobile terminal), 무선 기기(wireless device), 무선 송수신 유닛(Wireless Transmit/Receive Unit; WTRU), 사용자 장비(User Equipment; UE), 이동국(Mobile Station; MS), 이동 가입자 유닛(Mobile Subscriber Unit), 유저(user), 유저 STA, 네트워크, 기지국(Base Station), Node-B, AP(Access Point), 리피터, 라우터, 릴레이, 수신 장치, 송신 장치, 수신 STA, 송신 STA, 수신 Device, 송신 Device, 수신 Apparatus, 및/또는 송신 Apparatus는, 도 1의 부도면 (a)/(b)에 도시된 STA(110, 120)을 의미하거나, 도 1의 부도면 (b)에 도시된 프로세싱 칩(114, 124)을 의미할 수 있다. 즉, 본 명세서의 기술적 특징은, 도 1의 부도면 (a)/(b)에 도시된 STA(110, 120)에 수행될 수도 있고, 도 1의 부도면 (b)에 도시된 프로세싱 칩(114, 124)에서만 수행될 수도 있다. 예를 들어, 송신 STA가 제어 신호를 송신하는 기술적 특징은, 도 1의 부도면 (a)/(b)에 도시된 프로세서(111, 121)에서 생성된 제어 신호가 도 1의 부도면 (a)/(b)에 도시된 트랜시버(113, 123)을 통해 송신되는 기술적 특징으로 이해될 수 있다. 또는, 송신 STA가 제어 신호를 송신하는 기술적 특징은, 도 1의 부도면 (b)에 도시된 프로세싱 칩(114, 124)에서 트랜시버(113, 123)로 전달될 제어 신호가 생성되는 기술적 특징으로 이해될 수 있다.
예를 들어, 수신 STA가 제어 신호를 수신하는 기술적 특징은, 도 1의 부도면 (a)에 도시된 트랜시버(113, 123)에 의해 제어 신호가 수신되는 기술적 특징으로 이해될 수 있다. 또는, 수신 STA가 제어 신호를 수신하는 기술적 특징은, 도 1의 부도면 (a)에 도시된 트랜시버(113, 123)에 수신된 제어 신호가 도 1의 부도면 (a)에 도시된 프로세서(111, 121)에 의해 획득되는 기술적 특징으로 이해될 수 있다. 또는, 수신 STA가 제어 신호를 수신하는 기술적 특징은, 도 1의 부도면 (b)에 도시된 트랜시버(113, 123)에 수신된 제어 신호가 도 1의 부도면 (b)에 도시된 프로세싱 칩(114, 124)에 의해 획득되는 기술적 특징으로 이해될 수 있다.
도 1의 부도면 (b)을 참조하면, 메모리(112, 122) 내에 소프트웨어 코드(115, 125)가 포함될 수 있다. 소프트웨어 코드(115, 125)는 프로세서(111, 121)의 동작을 제어하는 instruction이 포함될 수 있다. 소프트웨어 코드(115, 125)는 다양한 프로그래밍 언어로 포함될 수 있다.
도 1에 도시된 프로세서(111, 121) 또는 프로세싱 칩(114, 124)은 ASIC(application-specific integrated circuit), 다른 칩셋, 논리 회로 및/또는 데이터 처리 장치를 포함할 수 있다. 프로세서는 AP(application processor)일 수 있다. 예를 들어, 도 1에 도시된 프로세서(111, 121) 또는 프로세싱 칩(114, 124)은 DSP(digital signal processor), CPU(central processing unit), GPU(graphics processing unit), 모뎀(Modem; modulator and demodulator) 중 적어도 하나를 포함할 수 있다. 예를 들어, 도 1에 도시된 프로세서(111, 121) 또는 프로세싱 칩(114, 124)은 Qualcomm®에 의해 제조된 SNAPDRAGONTM 시리즈 프로세서, Samsung®에 의해 제조된 EXYNOSTM 시리즈 프로세서, Apple®에 의해 제조된 A 시리즈 프로세서, MediaTek®에 의해 제조된 HELIOTM 시리즈 프로세서, INTEL®에 의해 제조된 ATOMTM 시리즈 프로세서 또는 이를 개선(enhance)한 프로세서일 수 있다.
본 명세서에서 상향링크는 non-AP STA로부터 AP STA으로의 통신을 위한 링크를 의미할 수 있고 상향링크를 통해 상향링크 PPDU/패킷/신호 등이 송신될 수 있다. 또한, 본 명세서에서 하향링크는 AP STA로부터 non-AP STA으로의 통신을 위한 링크를 의미할 수 있고 하향링크를 통해 하향링크 PPDU/패킷/신호 등이 송신될 수 있다.
도 2는 무선랜(WLAN)의 구조를 나타낸 개념도이다.
도 2의 상단은 IEEE(institute of electrical and electronic engineers) 802.11의 인프라스트럭쳐 BSS(basic service set)의 구조를 나타낸다.
도 2의 상단은 IEEE(institute of electrical and electronic engineers) 802.11의 인프라스트럭쳐 BSS(basic service set)의 구조를 나타낸다.
도 2의 상단을 참조하면, 무선랜 시스템은 하나 또는 그 이상의 인프라스트럭쳐 BSS(200, 205)(이하, BSS)를 포함할 수 있다. BSS(200, 205)는 성공적으로 동기화를 이루어서 서로 통신할 수 있는 AP(access point, 225) 및 STA1(Station, 200-1)과 같은 AP와 STA의 집합으로서, 특정 영역을 가리키는 개념은 아니다. BSS(205)는 하나의 AP(230)에 하나 이상의 결합 가능한 STA(205-1, 205-2)을 포함할 수도 있다.
BSS는 적어도 하나의 STA, 분산 서비스(distribution Service)를 제공하는 AP(225, 230) 및 다수의 AP를 연결시키는 분산 시스템(distribution System, DS, 210)을 포함할 수 있다.
분산 시스템(210)은 여러 BSS(200, 205)를 연결하여 확장된 서비스 셋인 ESS(extended service set, 240)를 구현할 수 있다. ESS(240)는 하나 또는 여러 개의 AP가 분산 시스템(210)을 통해 연결되어 이루어진 하나의 네트워크를 지시하는 용어로 사용될 수 있다. 하나의 ESS(240)에 포함되는 AP는 동일한 SSID(service set identification)를 가질 수 있다.
포털(portal, 220)은 무선랜 네트워크(IEEE 802.11)와 다른 네트워크(예를 들어, 802.X)와의 연결을 수행하는 브리지 역할을 수행할 수 있다.
도 2의 상단과 같은 BSS에서는 AP(225, 230) 사이의 네트워크 및 AP(225, 230)와 STA(200-1, 205-1, 205-2) 사이의 네트워크가 구현될 수 있다. 하지만, AP(225, 230)가 없이 STA 사이에서도 네트워크를 설정하여 통신을 수행하는 것도 가능할 수 있다. AP(225, 230)가 없이 STA 사이에서도 네트워크를 설정하여 통신을 수행하는 네트워크를 애드-혹 네트워크(Ad-Hoc network) 또는 독립 BSS(independent basic service set, IBSS)라고 정의한다.
도 2의 하단은 IBSS를 나타낸 개념도이다.
도 2의 하단을 참조하면, IBSS는 애드-혹 모드로 동작하는 BSS이다. IBSS는 AP를 포함하지 않기 때문에 중앙에서 관리 기능을 수행하는 개체(centralized management entity)가 없다. 즉, IBSS에서 STA(250-1, 250-2, 250-3, 255-4, 255-5)들은 분산된 방식(distributed manner)으로 관리된다. IBSS에서는 모든 STA(250-1, 250-2, 250-3, 255-4, 255-5)이 이동 STA으로 이루어질 수 있으며, 분산 시스템으로의 접속이 허용되지 않아서 자기 완비적 네트워크(self-contained network)를 이룬다.
도 3은 일반적인 링크 셋업(link setup) 과정을 설명하는 도면이다.
도시된 S310 단계에서 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 관련 정보를 저장하고 다음 채널로 이동하여 동일한 방법으로 다음 채널에서 스캐닝을 수행할 수 있다.
네트워크를 발견한 STA은, 단계 S320를 통해 인증 과정을 수행할 수 있다. 이러한 인증 과정은 후술하는 단계 S340의 보안 셋업 동작과 명확하게 구분하기 위해서 첫 번째 인증(first authentication) 과정이라고 칭할 수 있다. S320의 인증 과정은, 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은 단계 S330을 기초로 연결 과정을 수행할 수 있다. 연결 과정은 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 맵 등의 정보를 포함할 수 있다.
이후 S340 단계에서, STA은 보안 셋업 과정을 수행할 수 있다. 단계 S340의 보안 셋업 과정은, 예를 들어, EAPOL(Extensible Authentication Protocol over LAN) 프레임을 통한 4-웨이(way) 핸드쉐이킹을 통해서, 프라이빗 키 셋업(private key setup)을 하는 과정을 포함할 수 있다.
도 4는 멀티 링크(Multi-link; ML)의 일 실시예를 설명한다.
도 4에 도시된 바와 같이 복수의 MLD(multi-link device)가 멀리 링크를 통해 통신을 수행할 수 있다. 상기 MLD는 복수의 AP STA을 포함하는 AP MLD와 복수의 non-AP STA을 포함하는 non-AP MLD로 분류될 수 있다. 즉 AP MLD는 연계된(affiliated) AP(즉, AP STA)들을 포함할 수 있고, non-AP MLD는 연계된(affiliated) STA(즉, non-AP STA, 또는 user-STA)들을 포함할 수 있다.
멀티링크는 제1 링크와 제2 링크를 포함할 수 있고, 상기 제1 및 제2 링크에는 서로 다른 채널/서브채널/주파수자원이 할당될 수 있다. 상기 제1 및 제2 멀티링크는 4비트 길이(또는 기타 n 비트 길이)의 링크 ID를 통해 식별될 수 있다. 상기 제1 및 제2 링크는 동일한 2.4 GHz, 5 GHz, 또는 6 GHz 밴드에 구성될 수 있다. 또는 상기 제1 링크 및 링크는 서로 다른 밴드에 구성될 수 있다.
도 4의 AP MLD는 3개의 연계된 AP들(three affiliated APs)을 포함한다. 도 4의 일례에서, AP1이 2.4 GHz 밴드에서 동작(operate)하고, AP2는 5 GHz 밴드에서 동작하고, AP3은 6 GHz 밴드에서 동작할 수 있다. 도 4의 일례에서 AP1과 non-AP1이 동작하는 제1 링크는 2.4 GHz 밴드 내의 채널/서브채널/주파수자원으로 정의될 수 있다. 또한, 도 4의 일례에서 AP2와 non-AP2가 동작하는 제2 링크는 5 GHz 밴드 내의 채널/서브채널/주파수자원으로 정의될 수 있다. 또한, 도 4의 일례에서 AP3과 non-AP3이 동작하는 제3 링크는 6 GHz 밴드 내의 채널/서브채널/주파수자원으로 정의될 수 있다.
도 4의 일례에서 AP1은 non-AP STA1로 Association Request frame를 송신하는 방식으로 멀티링크 셋업 절차(ML setup procedure)를 시작할 수 있다. 도 4의 일례에서 non-AP STA1은 상기 Association Request frame에 대한 응답으로 Association Response frame을 송신할 수 있다. 도 4에 도시된 각각의 AP(예를 들어, AP1/2/3)는 도 1 및/또는 도 2에 도시된 AP와 동일할 수 있고, 도 4에 도시된 각각의 non-AP(예를 들어, non-AP1/2/3)는 도 1 및/또는 도 2에 도시된 STA(즉, user-STA 또는 non-AP STA)와 동일할 수 있다.
본 명세서의 구체적인 특징은 도 4의 구체적인 특징에 제한되지 않는다. 즉 링크의 개수는 다양하게 정의될 수 있고, 복수의 링크는 적어도 하나의 밴드 내에서 다양하게 정의될 수 있다.
도 5는 본 명세서의 STA에서 송신/수신되는 PPDU(physical protocol data unit 또는 physical layer (PHY) protocol data unit)가 설명된다.
본 명세서의 STA(예를 들어, AP STA, non-AP STA, AP MLD, non-AP MLD)는 도 5의 PPDU를 송신 및/또는 수신할 수 있다. 본 명세서에서 설명되는 PPDU는 예를 들어 도 5의 구조를 가질 수 있다. 또한 본 명세서에서 설명되는 PPDU는 UHR(Ultra High Reliability) PPDU는 송신 PPDU, 수신 PPDU, 제1 타입 또는 제N 타입 PPDU 등의 다양한 명칭으로 불릴 수 있다. 본 명세서에서 설명되는 PPDU는 IEEE 802.11bn에 따라 정의되는 WLAN 시스템 및/또는 IEEE 802.11bn을 개선하는 차세대 WLAN 시스템에서 사용될 수 있다.
도 5의 PPDU는 UHR 시스템에서 사용되는 다양한 PPDU 타입에 관련될 수 있다. 예를 들어, 도 5의 일례는 SU(single-user) 모드/타입/transmission, MU(multi-user) 모드/타입/transmission, 및 채널 사운딩에 관련된 NDP(null data packet) 모드/타입/transmission 중 적어도 어느 하나를 위해 사용될 수 있다. 예를 들어 도 5의 일례가 NDP에 관련되는 경우 도시된 Data 필드가 생략될 수 있다. 도 5의 PPDU가 TB(Trigger-based) 모드를 위해 사용되는 경우, 도 5의 UHR-SIG는 생략될 수 있다. 달리 표현하면 UL-MU(Uplink-MU) 통신을 위한 Trigger frame을 수신한 STA은, 도 5의 일례에서 UHR-SIG가 생략된 PPDU를 송신할 수 있다.
도 5에서 L-STF 내지 UHR-LTF는 프리앰블(preamble) 또는 물리 프리앰블(physical preamble)로 불릴 수 있고, (송신/수신 STA에 포함되는) 물리계층에서 생성/송신/수신/획득/디코딩될 수 있다.
도 5에 도시된 각각의 블록은 필드/서브필드/신호 등으로 불릴 수 있다. 이러한 필드/서브필드/신호의 명칭은, 도 5에 도시된 바와 같이, L-STF(legacy short training field), L-LTF(legacy long training field), L-SIG(legacy signal), RL-SIG(repeated L-SIG), U-SIG(Universal Signal), UHR-SIG(UHR-signal) 등이 될 수 있다.
도 5의 L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, UHR-SIG 필드의 subcarrier spacing은 312.5 kHz로 정해지고, UHR-STF, UHR-LTF, Data 필드의 subcarrier spacing은 78.125 kHz로 정해질 수 있다. 즉, L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, UHR-SIG 필드의 tone index(또는 subcarrier index)는 312.5 kHz 단위로 표시되고, UHR-STF, UHR-LTF, Data 필드의 tone index(또는 subcarrier index)는 78.125 kHz 단위로 표시될 수 있다.
도 5의 PPDU는 L-LTF 및 L-STF는 종래의 필드(예를 들어, 종래의 WLAN 표준에 정의되는 non-HT LTF 및 non-HT STF)와 동일할 수 있다.
도 5의 L-SIG 필드는 예를 들어 24 비트의 비트 정보를 포함할 수 있다. 예를 들어, 24비트 정보는 4 비트의 Rate 필드, 1 비트의 Reserved 비트, 12 비트의 Length 필드, 1 비트의 Parity 비트 및, 6 비트의 Tail 비트를 포함할 수 있다. 예를 들어, 12 비트의 Length 필드는 PPDU의 길이 또는 time duration에 관한 정보를 포함할 수 있다. 예를 들어, 12비트 Length 필드의 값은 PPDU의 타입을 기초로 결정될 수 있다. 예를 들어, PPDU가 non-HT(non-High Throughput), HT(High Throughput), VHT(Very High Throughput) PPDU이거나 EHT(extremely high throughput) PPDU, UHR PPDU인 경우, Length 필드의 값은 3의 배수로 결정될 수 있다. 예를 들어, PPDU가 HE PPDU인 경우, Length 필드의 값은 "3의 배수 + 1" 또는 "3의 배수 +2"로 결정될 수 있다. 달리 표현하면, non-HT, HT, VHT PPDU이거나 EHT PPDU, UHR PPDU를 위해 Length 필드의 값은 3의 배수로 결정될 수 있고, HE(High-Efficiency) PPDU를 위해 Length 필드의 값은 "3의 배수 + 1" 또는 "3의 배수 +2"로 결정될 수 있다. 달리 표현하면 UHR PPDU의 Length 필드는 길이를 3으로 나눴을 때 나머지가 0이라는 조건을 만족하는 값으로 설정(The LENGTH field in an UHR PPDU is set to a value satisfying the condition that the remainder is zero when LENGTH is divided by 3)된다.
예를 들어, (non-AP 및 AP) STA은 L-SIG 필드의 24 비트 정보에 대해 1/2의 부호화율(code rate)에 기초한 BCC 인코딩을 적용할 수 있다. 이후 송신 STA은 48 비트의 BCC 부호화 비트를 획득할 수 있다. 48 비트의 부호화 비트에 대해서는 BPSK 변조가 적용되어 48 개의 BPSK 심볼이 생성될 수 있다. 송신 STA은 48개의 BPSK 심볼을, 파일럿 서브캐리어{서브캐리어 인덱스 -21, -7, +7, +21} 및 DC 서브캐리어{서브캐리어 인덱스 0}를 제외한 위치에 매핑할 수 있다. 결과적으로 48개의 BPSK 심볼은 서브캐리어 인덱스 -26 내지 -22, -20 내지 -8, -6 내지 -1, +1 내지 +6, +8 내지 +20, 및 +22 내지 +26에 매핑될 수 있다. 송신 STA은 서브캐리어 인덱스 {-28, -27, +27, +28}에 {-1, -1, -1, 1}의 신호를 추가로 매핑할 수 있다. 위의 신호는 {-28, -27, +27, +28}에 상응하는 주파수 영역에 대한 채널 추정을 위해 사용될 수 있다.
예를 들어, (non-AP 및 AP) STA은 L-SIG와 동일하게 생성되는 RL-SIG를 생성할 수 있다. RL-SIG에 대해서는 BPSK 변조가 적용될 수 있다. 수신 (non-AP 및 AP) STA은 RL-SIG의 존재를 기초로 수신 PPDU가 HE PPDU, EHT PPDU, UHR PPDU임을 알 수 있다. 달리 표현하면 수신 (non-AP 및 AP) STA은 RL-SIG가 존재하는 경우, 수신 PPDU가 HE PPDU, EHT PPDU, UHR PPDU 중 어느 하나임을 알 수 있다. 달리 표현하면 수신 (non-AP 및 AP) STA은 RL-SIG가 존재하지 않는 경우, 수신 PPDU가 non-HT PPDU, HT PPDU, VHT PPDU 중 어느 하나임을 알 수 있다. 달리 표현하면, RL-SIG 필드는 L-SIG 필드의 반복으로, UHR PPDU를 비-HT PPDU, HT PPDU 및 VHT PPDU와 구분하는 데 사용된다(The RL-SIG field is a repeat of the L-SIG field and is used to differentiate an UHR PPDU from a non-HT PPDU, HT PPDU, and VHT PPDU.).
도 5의 RL-SIG 이후에는 U-SIG(Universal SIG)가 삽입될 수 있다. U-SIG는 제1 SIG 필드, 제1 SIG, 제1 타입 SIG, 제어 시그널, 제어 시그널 필드, 제1 (타입) 제어 시그널, 공통 제어 필드, 공통 제어 시그널 등의 다양한 명칭으로 불릴 수 있다.
U-SIG는 N 비트의 정보를 포함할 수 있고, EHT PPDU의 타입을 식별하기 위한 정보를 포함할 수 있다. 예를 들어, U-SIG는 2개의 심볼(예를 들어, 연속하는 2 개의 OFDM 심볼)을 기초로 구성될 수 있다. U-SIG를 위한 각 심볼(예를 들어, OFDM 심볼)은 4 us의 duration을 가질 수 있다. U-SIG의 각 심볼은 26 비트 정보를 송신하기 위해 사용될 수 있다. 예를 들어 U-SIG의 각 심볼은 52개의 데이터 톤과 4 개의 파일럿 톤을 기초로 송수신될 수 있다.
U-SIG를 통해서는 예를 들어 A 비트 정보(예를 들어, 52 un-coded bit)가 송신될 수 있고, U-SIG의 제1 심볼은 총 A 비트 정보 중 처음 X 비트 정보(예를 들어, 26 un-coded bit)를 송신하고, U-SIG의 제2 심볼은 총 A 비트 정보 중 나머지 Y 비트 정보(예를 들어, 26 un-coded bit)를 송신할 수 있다. 예를 들어, 송신 STA은 각 U-SIG 심볼에 포함되는 26 un-coded bit를 획득할 수 있다. 송신 STA은 R=1/2의 rate를 기초로 convolutional encoding(즉, BCC 인코딩)을 수행하여 52-coded bit를 생성하고, 52-coded bit에 대한 인터리빙을 수행할 수 있다. 송신 STA은 인터리빙된 52-coded bit에 대해 BPSK 변조를 수행하여 각 U-SIG 심볼에 할당되는 52개의 BPSK 심볼을 생성할 수 있다. 하나의 U-SIG 심볼은 DC 인덱스 0을 제외하고, 서브캐리어 인덱스 -28부터 서브캐리어 인덱스 +28까지의 56개 톤(서브캐리어)을 기초로 송신될 수 있다. 송신 STA이 생성한 52개의 BPSK 심볼은 파일럿 톤인 -21, -7, +7, +21 톤을 제외한 나머지 톤(서브캐리어)를 기초로 송신될 수 있다.
예를 들어, U-SIG에 의해 송신되는 A 비트 정보(예를 들어, 52 un-coded bit)는 CRC 필드(예를 들어 4비트 길이의 필드) 및 테일 필드(예를 들어 6비트 길이의 필드)를 포함할 수 있다. 상기 CRC 필드 및 테일 필드는 U-SIG의 제2 심볼을 통해 송신될 수 있다. 상기 CRC 필드는 U-SIG의 제1 심볼에 할당되는 26 비트와 제2 심볼 내에서 상기 CRC/테일 필드를 제외한 나머지 16 비트를 기초로 생성될 수 있고, 종래의 CRC calculation 알고리즘을 기초로 생성될 수 있다. 또한, 상기 테일 필드는 convolutional decoder의 trellis를 terminate하기 위해 사용될 수 있고, 예를 들어 "000000"으로 설정될 수 있다.
U-SIG(또는 U-SIG 필드)에 의해 송신되는 A 비트 정보(예를 들어, 52 un-coded bit)는 version-independent bits와 version-dependent bits로 구분될 수 있다. 예를 들어, version-independent bits의 크기는 고정적이거나 가변적일 수 있다. 예를 들어, version-independent bits는 U-SIG의 제1 심볼에만 할당되거나, version-independent bits는 U-SIG의 제1 심볼 및 제2 심볼 모두에 할당될 수 있다. 예를 들어, version-independent bits와 version-dependent bits는 제1 제어 비트 및 제2 제어 비트 등의 다양한 명칭으로 불릴 수 있다.
예를 들어, U-SIG의 version-independent bits는 3비트의 PHY version identifier를 포함할 수 있다. 예를 들어, 3비트의 PHY version identifier는 송수신 PPDU의 PHY version에 관련된 정보를 포함할 수 있다. 예를 들어, 3비트의 PHY version identifier의 제1 값(예를 들어, 000 값)은 송수신 PPDU가 EHT PPDU임을 지시할 수 있다. 또한, 3비트의 PHY version identifier의 제2 값(예를 들어, 001 값)은 송수신 PPDU가 UHR PPDU임을 지시할 수 있다.
달리 표현하면, (AP/non-AP) STA은 EHT PPDU를 송신하는 경우, 3비트의 PHY version identifier를 제1 값으로 설정할 수 있다. 달리 표현하면, 수신 (AP/non-AP) STA은 제1 값을 가지는 PHY version identifier를 기초로, 수신 PPDU가 EHT PPDU임을 판단할 수 있고, 제2 값을 가지는 PHY version identifier를 기초로, 수신 PPDU가 UHR PPDU임을 판단할 수 있다.
예를 들어, U-SIG의 version-independent bits는 1비트의 UL/DL flag 필드를 포함할 수 있다. 1비트의 UL/DL flag 필드의 제1 값은 UL 통신에 관련되고, UL/DL flag 필드의 제2 값은 DL 통신에 관련된다.
예를 들어, U-SIG의 version-independent bits는 TXOP(transmission opportunity)의 길이에 관한 정보, BSS color ID에 관한 정보를 포함할 수 있다.
예를 들어 UHR PPDU가 다양한 타입(예를 들어, (UL 또는 DL을 기반으로 수행되는) SU transmission에 관련된 type, DL transmission에 관련된 type, NDP transmission에 관련된 type, DL non-MU-MIMO에 관련된 type, DL MU-MIMO에 관련된 type, Multi-AP operation에 관련된 type, CBF(Coordinated beamforming), SR(Spatial Reuse)에 관련된 type, C-OFDMA (Coordinated OFDMA)에 관련된 type, C-TDMA (Coordinated TDMA)에 관련된 type)으로 구분되는 경우, EHT PPDU의 타입에 관한 정보(예를 들어, 2비트 또는 3비트 정보)는 U-SIG의 version-dependent bits에 포함될 수 있다.
예를 들어, U-SIG는 1) 대역폭에 관한 정보를 포함하는 대역폭 필드, 2) UHR-SIG에 적용되는 MCS 기법에 관한 정보를 포함하는 필드, 3) UHR -SIG에 듀얼 서브캐리어 모듈레이션(dual subcarrier modulation, DCM) 기법이 적용되는지 여부에 관련된 정보를 포함하는 지시 필드, 4) UHR -SIG를 위해 사용되는 심볼의 개수에 관한 정보를 포함하는 필드, 5) UHR -SIG가 전 대역에 걸쳐 생성되는지 여부에 관한 정보를 포함하는 필드, 6) UHR -LTF/STF의 타입에 관한 정보를 포함하는 필드, 7) UHR -LTF의 길이 및 CP 길이를 지시하는 필드에 관한 정보를 포함할 수 있다.
도 5의 PPDU에는 프리앰블 펑처링(puncturing)이 적용될 수 있다. 프리앰블 펑처링은 PPDU의 전체 대역 중에서 일부 대역(예를 들어, Secondary 20 MHz 대역)을 펑처링을 적용하는 것을 의미한다. 예를 들어, 80 MHz PPDU가 송신되는 경우, STA은 80 MHz 대역 중 secondary 20 MHz 대역에 대해 펑처링을 적용하고, primary 20 MHz 대역과 secondary 40 MHz 대역을 통해서만 PPDU를 송신할 수 있다.
예를 들어 프리앰블 펑처링의 패턴은 사전에 설정될 수 있다. 예를 들어, 제1 펑처링 패턴이 적용되는 경우, 80 MHz 대역 내에서 secondary 20 MHz 대역에 대해서만 펑처링이 적용될 수 있다. 예를 들어, 제2 펑처링 패턴이 적용되는 경우, 80 MHz 대역 내에서 secondary 40 MHz 대역에 포함된 2개의 secondary 20 MHz 대역 중 어느 하나에 대해서만 펑처링이 적용될 수 있다. 예를 들어, 제3 펑처링 패턴이 적용되는 경우, 160 MHz 대역(또는 80+80 MHz 대역) 내에서 primary 80 MHz 대역에 포함된 secondary 20 MHz 대역에 대해서만 펑처링이 적용될 수 있다. 예를 들어, 제4 펑처링 패턴이 적용되는 경우, 160 MHz 대역(또는 80+80 MHz 대역) 내에서 primary 80 MHz 대역에 포함된 primary 40 MHz 대역은 존재(present)하고 primary 40 MHz 대역에 속하지 않는 적어도 하나의 20 MHz 채널에 대해 펑처링이 적용될 수 있다.
PPDU에 적용되는 프리앰블 펑처링에 관한 정보는 U-SIG 및/또는 UHR-SIG에 포함될 수 있다. 예를 들어, U-SIG의 제1 필드는 PPDU의 연속하는 대역폭(contiguous bandwidth)에 관한 정보를 포함하고, U-SIG의 제2 필드는 PPDU에 적용되는 프리앰블 펑처링에 관한 정보를 포함할 수 있다.
예를 들어, U-SIG 및 UHR-SIG는 아래의 방법을 기초로 프리앰블 펑처링에 관한 정보를 포함할 수 있다. PPDU의 대역폭이 80 MHz를 초과하는 경우, U-SIG는 80 MHz 단위로 개별적으로 구성될 수 있다. 예를 들어, PPDU의 대역폭이 160 MHz인 경우, 해당 PPDU에는 첫 번째 80 MHz 대역을 위한 제1 U-SIG 및 두 번째 80 MHz 대역을 위한 제2 U-SIG가 포함될 수 있다. 이 경우, 제1 U-SIG의 제1 필드는 160 MHz 대역폭에 관한 정보를 포함하고, 제1 U-SIG의 제2 필드는 첫 번째 80 MHz 대역에 적용된 프리앰블 펑처링에 관한 정보(즉, 프리앰블 펑처링 패턴에 관한 정보)를 포함할 수 있다. 또한, 제2 U-SIG의 제1 필드는 160 MHz 대역폭에 관한 정보를 포함하고, 제2 U-SIG의 제2 필드는 두 번째 80 MHz 대역에 적용된 프리앰블 펑처링에 관한 정보(즉, 프리앰블 펑처링 패턴에 관한 정보)를 포함할 수 있다. 한편, 제1 U-SIG에 연속하는 UHR-SIG는 두 번째 80 MHz 대역에 적용된 프리앰블 펑처링에 관한 정보(즉, 프리앰블 펑처링 패턴에 관한 정보)를 포함할 수 있고, 제2 U-SIG에 연속하는 UHR-SIG는 첫 번째 80 MHz 대역에 적용된 프리앰블 펑처링에 관한 정보(즉, 프리앰블 펑처링 패턴에 관한 정보)를 포함할 수 있다.
추가적으로 또는 대체적으로, U-SIG 및 UHR-SIG는 아래의 방법을 기초로 프리앰블 펑처링에 관한 정보를 포함할 수 있다. U-SIG는 모든 대역에 관한 프리앰블 펑처링에 관한 정보(즉, 프리앰블 펑처링 패턴에 관한 정보)를 포함할 수 있다. 즉, UHR-SIG는 프리앰블 펑처링에 관한 정보를 포함하지 않고, U-SIG 만이 프리앰블 펑처링에 관한 정보(즉, 프리앰블 펑처링 패턴에 관한 정보)를 포함할 수 있다.
U-SIG는 20 MHz 단위로 구성될 수 있다. 예를 들어, 80 MHz PPDU가 구성되는 경우, U-SIG가 복제될 수 있다. 즉, 80 MHz PPDU 내에 동일한 4개의 U-SIG가 포함될 수 있다. 80 MHz 대역폭을 초과하는 PPDU는 서로 다른 U-SIG를 포함할 수 있다.
도 5의 UHR-SIG는 수신 STA을 위한 제어 정보를 포함할 수 있다. UHR-SIG는 적어도 하나의 심볼을 통해 송신될 수 있고, 하나의 심볼은 4 us의 길이를 가질 수 있다. UHR-SIG를 위해 사용되는 심볼의 개수에 관한 정보는 U-SIG에 포함될 수 있다.
UHR-SIG는 U-SIG 필드에 추가 신호를 제공하여 STA가 UHR PPDU를 해석(interpret)/디코딩할 수 있도록 합니다. UHR-SIG 필드에는 모든 사용자에게 공통으로 적용되는 U-SIG 오버플로 비트(U-SIG overflow bits)가 포함될 수 있다. 또한 UHR-SIG 필드에는 리소스 할당 정보가 포함되어 있어, STA이 데이터 필드/UHR-STF/UHR-LTF를 포함하는 필드들(즉, UHR modulated fields of an UHR PPDU)에서 사용되는 자원을 look-up(조회)하는 것이 가능하다.
도 5에 도시된 UHR-LTF, UHR-STF, 데이터 필드의 주파수 자원은 복수의 서브캐리어/톤으로 정의되는 RU(자원유닛)을 기초로 결정될 수 있다. 즉 본 명세서의 UHR-LTF, UHR-STF, 데이터 필드는 복수의 서브캐리어/톤으로 정의되는 RU(자원유닛)을 통해 송신/수신될 수 있다.
도 6은 20MHz PPDU를 위해 사용되는 자원유닛(RU)의 배치를 나타내는 도면이다. 즉 20 MHz PPDU에 포함되는 UHR-LTF, UHR-STF 및/또는 데이터 필드는 도 6에 정의되는 다양한 RU 중 적어도 어느 하나를 통해 송신/수신될 수 있다.
도 6의 최상단에 도시된 바와 같이, 26-유닛(즉, 26개의 톤에 상응하는 유닛)이 배치될 수 있다. 20MHz 대역의 최좌측(leftmost) 대역에는 6개의 톤이 가드(Guard) 대역으로 사용되고, 20MHz 대역의 최우측(rightmost) 대역에는 5개의 톤이 가드 대역으로 사용될 수 있다. 또한 중심대역, 즉 DC 대역에는 7개의 DC 톤이 삽입되고, DC 대역의 좌우측으로 각 13개의 톤에 상응하는 26-유닛이 존재할 수 있다. 또한, 기타 대역에는 26-유닛, 52-유닛, 106-유닛이 할당될 수 있다. 각 유닛은 수신 스테이션, 즉 사용자를 위해 할당될 수 있다.
한편, 도 6의 RU 배치는 다수의 사용자(MU)를 위한 상황뿐만 아니라, 단일 사용자(SU)를 위한 상황에서도 활용되며, 이 경우에는 도 4의 최하단에 도시된 바와 같이 1개의 242-유닛을 사용하는 것이 가능하며 이 경우에는 3개의 DC 톤이 삽입될 수 있다.
도 6의 일례에서는 다양한 크기의 RU, 즉, 26-RU, 52-RU, 106-RU, 242-RU 등이 제안되었는 바, 이러한 RU의 구체적인 크기는 확장 또는 증가할 수 있기 때문에, 본 실시예는 각 RU의 구체적인 크기(즉, 상응하는 톤의 개수)에 제한되지 않는다. 본 명세서에서 N-RU는 N-tone RU 등으로 표시될 수 있다. 예를 들어 26-RU는 26-tone RU라 표시될 수 있다.
도 7은 40MHz PPDU를 위해 사용되는 자원유닛(RU)의 배치를 나타내는 도면이다.
도 6의 일례에서 다양한 크기의 RU가 사용된 것과 마찬가지로, 도 7의 일례 역시 26-RU, 52-RU, 106-RU, 242-RU, 484-RU 등이 사용될 수 있다. 또한, 중심주파수에는 5개의 DC 톤이 삽입될 수 있고, 40MHz 대역의 최좌측(leftmost) 대역에는 12개의 톤이 가드(Guard) 대역으로 사용되고, 40MHz 대역의 최우측(rightmost) 대역에는 11개의 톤이 가드 대역으로 사용될 수 있다.
또한, 도시된 바와 같이, 단일 사용자를 위해 사용되는 경우, 484-RU가 사용될 수 있다. 한편, RU의 구체적인 개수가 변경될 수 있다는 점은 도 6의 일례와 동일하다.
도 8은 80MHz PPDU를 위해 사용되는 자원유닛(RU)의 배치를 나타내는 도면이다. 본 명세서에서 사용되는 자원유닛(RU)의 배치는 다양하게 변경될 수 있다. 예를 들어, 80MHz 대역 상에서 사용되는 자원유닛(RU)의 배치는 다양하게 변경될 수 있다.
도 9는 UL-MU에 따른 동작을 나타낸다. 도시된 바와 같이, 송신 STA(예를 들어, AP)는 contending (즉, Backoff 동작)을 통해 채널 접속을 수행하고, Trigger frame(930)을 송신할 수 있다. 즉, 송신 STA(예를 들어, AP)은 Trigger Frame(930)이 포함된 PPDU를 송신할 수 있다. Trigger frame이 포함된 PPDU가 수신되면 SIFS 만큼의 delay 이후 TB(trigger-based) PPDU가 송신된다.
TB PPDU(941, 942)는 동일한 시간 대에 송신되고, Trigger frame(930) 내에 AID가 표시된 복수의 STA(예를 들어, User STA)으로부터 송신될 수 있다. TB PPDU에 대한 ACK 프레임(950)은 다양한 형태로 구현될 수 있다.
도 10은 2.4 GHz 밴드 내에서 사용/지원/정의되는 채널의 일례를 나타낸다.
2.4 GHz 밴드는 제1 밴드(대역) 등의 다른 명칭으로 불릴 수 있다. 또한, 2.4 GHz 밴드는 중심주파수가 2.4 GHz에 인접한 채널(예를 들어, 중심주파수가 2.4 내지 2.5 GHz 내에 위치하는 채널)들이 사용/지원/정의되는 주파수 영역을 의미할 수 있다.
2.4 GHz 밴드에는 다수의 20 MHz 채널이 포함될 수 있다. 2.4 GHz 밴드 내의 20 MHz은 다수의 채널 인덱스(예를 들어, 인덱스 1 내지 인덱스 14)를 가질 수 있다. 예를 들어, 채널 인덱스 1이 할당되는 20 MHz 채널의 중심주파수는 2.412 GHz일 수 있고, 채널 인덱스 2가 할당되는 20 MHz 채널의 중심주파수는 2.417 GHz일 수 있고, 채널 인덱스 N이 할당되는 20 MHz 채널의 중심주파수는 (2.407 + 0.005*N) GHz일 수 있다. 채널 인덱스는 채널 번호 등의 다양한 명칭으로 불릴 수 있다. 채널 인덱스 및 중심주파수의 구체적인 수치는 변경될 수 있다.
도 10은 2.4 GHz 밴드 내의 4개의 채널을 예시적으로 나타낸다. 도시된 제1 주파수 영역(1010) 내지 제4 주파수 영역(1040)은 각각 하나의 채널을 포함할 수 있다. 예를 들어, 제1 주파수 영역(1010)은 1번 채널(1번 인덱스를 가지는 20 MHz 채널)을 포함할 수 있다. 이때 1번 채널의 중심 주파수는 2412 MHz로 설정될 수 있다. 제2 주파수 영역(1020)는 6번 채널을 포함할 수 있다. 이때 6번 채널의 중심 주파수는 2437 MHz로 설정될 수 있다. 제3 주파수 영역(1030)은 11번 채널을 포함할 수 있다. 이때 채널 11의 중심 주파수는 2462 MHz로 설정될 수 있다. 제4 주파수 영역(1040)는 14번 채널을 포함할 수 있다. 이때 채널 14의 중심 주파수는 2484 MHz로 설정될 수 있다.
도 11은 5 GHz 밴드 내에서 사용/지원/정의되는 채널의 일례를 도시한다.
5 GHz 밴드는 제2 밴드/대역 등의 다른 명칭으로 불릴 수 있다. 5 GHz 밴드는 중심주파수가 5 GHz 이상 6 GHz 미만 (또는 5.9 GHz 미만)인 채널들이 사용/지원/정의되는 주파수 영역을 의미할 수 있다. 또는 5 GHz 밴드는 4.5 GHz에서 5.5 GHz 사이에서 복수개의 채널을 포함할 수 있다. 도 11에 도시된 구체적인 수치는 변경될 수 있다.
5 GHz 밴드 내의 복수의 채널들은 UNII(Unlicensed National Information Infrastructure)-1, UNII-2, UNII-3, ISM을 포함한다. UNII-1은 UNII Low로 불릴 수 있다. UNII-2는 UNII Mid와 UNII-2Extended로 불리는 주파수 영역을 포함할 수 있다. UNII-3은 UNII-Upper로 불릴 수 있다.
5 GHz 밴드 내에는 복수의 채널들이 설정될 수 있고, 각 채널의 대역폭은 20 MHz, 40 MHz, 80 MHz 또는 160 MHz 등으로 다양하게 설정될 수 있다. 예를 들어, UNII-1 및 UNII-2 내의 5170 MHz 내지 5330MHz 주파수 영역/범위는 8개의 20 MHz 채널로 구분될 수 있다. 5170 MHz에서 5330MHz 주파수 영역/범위는 40 MHz 주파수 영역을 통하여 4개의 채널로 구분될 수 있다. 5170 MHz에서 5330MHz 주파수 영역/범위는 80 MHz 주파수 영역을 통하여 2개의 채널로 구분될 수 있다. 또는, 5170 MHz에서 5330MHz 주파수 영역/범위는 160 MHz 주파수 영역을 통하여 1개의 채널로 구분될 수 있다.
도 12는 6 GHz 밴드 내에서 사용/지원/정의되는 채널의 일례를 도시한다.
6 GHz 밴드는 제3 밴드/대역 등의 다른 명칭으로 불릴 수 있다. 6 GHz 밴드는 중심주파수가 5.9 GHz 이상인 채널들이 사용/지원/정의되는 주파수 영역을 의미할 수 있다. 도 12에 도시된 구체적인 수치는 변경될 수 있다.
예를 들어, 도 12의 20 MHz 채널은 5.940 GHz부터 정의될 수 있다. 구체적으로 도 12의 20 MHz 채널 중 최-좌측 채널은 1번 인덱스(또는, 채널 인덱스, 채널 번호 등)를 가질 수 있고, 중심주파수는 5.945 GHz가 할당될 수 있다. 즉, 인덱스 N번 채널의 중심주파수는 (5.940 + 0.005*N) GHz로 결정될 수 있다.
이에 따라, 도 12의 20 MHz 채널의 인덱스(또는 채널 번호)는, 1, 5, 9, 13, 17, 21, 25, 29, 33, 37, 41, 45, 49, 53, 57, 61, 65, 69, 73, 77, 81, 85, 89, 93, 97, 101, 105, 109, 113, 117, 121, 125, 129, 133, 137, 141, 145, 149, 153, 157, 161, 165, 169, 173, 177, 181, 185, 189, 193, 197, 201, 205, 209, 213, 217, 221, 225, 229, 233일 수 있다. 또한, 상술한 (5.940 + 0.005*N) GHz 규칙에 따라 도 12의 40 MHz 채널의 인덱스는 3, 11, 19, 27, 35, 43, 51, 59, 67, 75, 83, 91, 99, 107, 115, 123, 131, 139, 147, 155, 163, 171, 179, 187, 195, 203, 211, 219, 227일 수 있다.
이하에서는 MAC 프레임의 구조 및 타입/서브타입에 대해 설명한다.
도 13은 MAC 프레임의 헤더의 일례를 나타낸다. 도시된 바와 같이 MAC 프레임은 2 옥텟 길이의 frame control 필드/정보, 2 옥텟 길이의 duration 필드/정보, 6 옥텟 길이의 RA(Receiver Address) 필드/정보, 6 옥텟 길이의 TA(Transmitter Address) 필드/정보를 포함할 수 있다. 도 13에 도시된 바와 같이 4개의 필드는 서로 연속할 수 있다. 도 13의 MAC 헤더는 다양하게 변형될 수 있고, 도시된 4개의 필드 사이에 새로운 필드가 삽입되거나 도시된 필드 중 적어도 하나의 필드가 생략될 수 있다.
도 13에 도시된 MAC 헤더는 MAC 프레임의 제일 앞에 위치할 수 있다. 즉 MAC 프레임은 도 13과 같은 MAC 헤더 및 상기 MAC 헤더에 연속하는 MAC body 필드/정보를 포함할 수 있다. 도 13의 MAC 헤더를 포함하는 MAC 프레임은 도 5에 도시된 PPDU(예를 들어, UHR PPDU)의 데이터 필드에 삽입/포함된다.
본 명세서의 PPDU의 데이터 필드에 포함되는 MAC 프레임은 다양한 type으로 분류될 수 있다. 예를 들어, 본 명세서의 MAC 프레임은 control frame, management frame, data frame으로 분류될 수 있다.
예를 들어, management frame는 종래 WLAN에서 정의된 Association Request, Association Response, Reassociation Request, Reassociation Response, Probe Request, Probe Response, Beacon, Disassociation, Authentication, Deauthentication 프레임/신호를 포함한다. 상기 management frame을 위하여 도 13의 type 필드(B3 및 B2)의 값은 00으로 설정된다. 또한 도 13의 subtype 필드(B7, B6, B5, B4)의 값은 다음과 같다: Association Request(0000), Association Response(0001), Reassociation Request(0010), Reassociation Response(0011), Probe Request(0100), Probe Response(0101), Beacon(1000), Disassociation(1010), Authentication(1011), Deauthentication(1100).
예를 들어, control frame는 종래 WLAN에서 정의된 Trigger Beamforming Report Poll, NDP Announcement (NDPA), Control Frame Extension, Control Wrapper, Block Ack Request (BlockAckReq), Block Ack (BlockAck), PS-Poll, RTS, CTS, Ack, CF-End 프레임/신호를 포함한다. 상기 control frame을 위하여 도 13의 type 필드(B3 및 B2)의 값은 01로 설정된다. 또한 도 13의 subtype 필드(B7, B6, B5, B4)의 값은 다음과 같다: Trigger(0010), Beamforming Report Poll(0100), NDP Announcement(0101), Control Frame Extension(0110), Control Wrapper(0111), BlockAckReq(1000), BlockAck(1001), PS-Poll(1010), RTS(1011), CTS(1100), Ack(1101), CF-End(1110).
예를 들어, data frame은 종래 WLAN에서 정의된 (QoS) Data, (QoS) Null 등을 포함한다. 상기 management frame을 위하여 도 13의 type 필드(B3 및 B2)의 값은 10으로 설정된다.
본 명세서에서 사용하는 MAC 프레임/신호는 상술한 type 필드/정보 및 subtype 필드/정보를 통해 식별될 수 있다. 예를 들어, 본 명세서의 “frame”은 MAC 헤더의 frame control 필드 내의 type 비트인 B3, B2 비트가 01로 설정되면서, 또한 상기 frame control 필드 내의 subtype 비트인 B7, B6, B5, B4 비트가 0010으로 설정된 MAC 프레임을 의미할 수 있다. 본 명세서에서 설명되는 다양한 MAC 프레임은 다양한 PPDU(예를 들어, HE/VHT/HE/EHT/UHR PPDU)의 데이터 필드에 삽입/포함된다.
도 14는 본 명세서의 송신 장치 및/또는 수신 장치의 변형된 일례를 나타낸다.
도 1 내지 도 4에 도시된 장치(예를 들어, AP STA, non-AP STA)은 도 14와 같이 변형될 수 있다. 도 14의 트랜시버(630)는 도 1의 트랜시버(113, 123)와 동일할 수 있다. 도 14의 트랜시버(630)는 수신기(receiver) 및 송신기(transmitter)를 포함할 수 있다.
도 14의 프로세서(610)는 도 1의 프로세서(111, 121)과 동일할 수 있다. 또는, 도 14의 프로세서(610)는 도 1의 프로세싱 칩(114, 124)과 동일할 수 있다.
도 14의 메모리(150)는 도 1의 메모리(112, 122)와 동일할 수 있다. 또는, 도 14의 메모리(150)는 도 1의 메모리(112, 122)와는 상이한 별도의 외부 메모리일 수 있다.
도 14를 참조하면, 전력 관리 모듈(611)은 프로세서(610) 및/또는 트랜시버(630)에 대한 전력을 관리한다. 배터리(612)는 전력 관리 모듈(611)에 전력을 공급한다. 디스플레이(613)는 프로세서(610)에 의해 처리된 결과를 출력한다. 키패드(614)는 프로세서(610)에 의해 사용될 입력을 수신한다. 키패드(614)는 디스플레이(613) 상에 표시될 수 있다. SIM 카드(615)는 휴대 전화 및 컴퓨터와 같은 휴대 전화 장치에서 가입자를 식별하고 인증하는 데에 사용되는 IMSI(international mobile subscriber identity) 및 그와 관련된 키를 안전하게 저장하기 위하여 사용되는 집적 회로일 수 있다.
도 14를 참조하면, 스피커(640)는 프로세서(610)에 의해 처리된 소리 관련 결과를 출력할 수 있다. 마이크(641)는 프로세서(610)에 의해 사용될 소리 관련 입력을 수신할 수 있다.
1. 종래기술의 문제점 (Fast BSS Transition (FT))
도 15는 RSN(Robust Security Network)에서 OTA(Over-the-air) FT 프로토콜을 도시한다.
현재 802.11에서 한 non-AP STA이 AP (Old AP)에서 다른 AP (New AP)로 이동 (Roaming), 즉 BSS(Basic Service Set) Transition을 위해서는 동일한 Mobility domain에서 Reassociation 과정을 거쳐야 한다. 대표적으로 Fast BSS Transition (FT) 기술이 있다. FT에서는 도 15와 같이 FT Originator (FTO)와 Target FT Responder (FTR) (즉, New AP)와 Authentication, Reassociation 등의 여러 과정을 거치게 된다.
이 과정 이후, BlockAck (BA), Stream Classification Service (SCS) 등과 관련된 Agreement, Sequence Number (SN), EDCAF Parameter 등 많은 operational parameter가 재설정된다. 이에 따라, 여러 frame exchange와 더불어 agreement/configuration을 다시 수행해야 하는 overhead가 존재하며, 또한 FT 과정 동안의 data loss도 발생할 수 있다. 또한, Non-AP STA 관점에서 끊기지 않는, 즉 Seamless한 Roaming이 쉽지 않다. 따라서, 본 명세서에서는 이를 해결하기 위해 AP MLD(Multi-Link Device)를 활용한 Seamless Roaming 방법에 대해 제안한다. FT와 달리, Roaming에서는 Authentication/Association 과정을 다시 하지 않는다.
본 명세서에서는 BSS Transition (즉, Roaming)을 수행하는 STA을 RSTA으로 지칭하고, STA이 Roaming할 때 현재 association되어 있는 AP를 Old AP (O_AP), Roaming할 AP를 New AP (N_AP)로 지칭한다. 또한, 본 명세서에서 제안하는 Roaming 방법을 MLD Roaming이라 지칭한다. 본 명세서에서의 지칭(이름)은 변경될 수 있으며, STA은 AP STA 또는 non-AP STA을 포함할 수 있다.
2. Roaming을 위한 UHR AP MLD 구조
2.1 General Procedure of Roaming in AP MLD
도 16은 AP MLD에 대한 High-level Architecture를 도시한다.
기본적으로 AP MLD는 하나 또는 그 이상의 AP를 포함할 수 있으며, 도 16과 같은 High-level Architecture를 갖는다. 기본적으로 MLD는 upper MAC sublayer를 이용하여 여러 AP에게 공통적으로 해당하는 여러 procedure/parameter를 제어할 수 있다. 예를 들어, 해당 절차/파라미터는 authentication, association, SN/PN assignment, Power save buffering of individually addressed frames 등이 있다.
따라서 AP MLD functionality를 이용하게 된다면 AP MLD에 연루되어 있는 AP(affiliated AP)간에 이동 시 MLD-level의 parameter들을 Reset하지 않고, 유지할 수 있다. 본 명세서에서는 AP MLD의 functionality를 활용한 Roaming 방법을 제안한다.
도 17은 UHR AP MLD에 대한 High-level Architecture의 일례를 도시한다.
도 17은 Seamless Roaming을 지원하는 AP들의 architecture를 보여준다. Seamless Roaming을 지원하기 위해서는 이전 표준 버전의 기기들과의 호환이 되어야 하고 많은 기기들 간의 seamless roaming을 할 수 있어야한다. 먼저 이전 기기들과의 legacy compatibility를 보장하기 위해서는 non-UHR non-AP STA들이 non-UHR AP들을 볼 수 있어야 한다. 그러기 위해서는 MLD 자체의 정의를 침범하지 않고 기존의 architecture를 변경하지 않아야 한다. 따라서 도 17과 같이 기존 MLD의 architecture를 유지하며 hierarchical하게 seamless roaming이 가능한 MLD들을 affiliate하고 있는 UHR AP MLD를 새로 정의한다. 이때, AP MLD들의 각각의 LMAC들은 UHR UMAC과 interface되어있고 seamless roaming을 하는 AP MLD의 UMAC의 functions들은 UHR UMAC에서 관리한다. 별도의 entity가 AP MLD들 사이의 roaming을 위한 여러 functionality(e.g., multi-link authentication (e.g., PTK), multi-link discovery/setup, multi-link reconfiguration)들을 관리할 수 있다. 즉, 본 명세서는 roaming을 지원하는 것을 UMAC으로 국한하지 않는다. 이와 같은 경우의 예시는 도 18에 보여준다. Entity는 control plane context를 관리할 수 있고 필요에 따라 이 외의 것들도 관리할 수 있다. AP MLD와 UHR AP MLD들은 각각 다 개별적으로 DS(Distribution System)와 연결되어 있다. 이와 같은 architecture는 Link ID의 bit 크기의 한계에 의한 scalability issue도 해결할 수 있다. 기본적으로 link ID는 4 bit으로 최대 16개의 Link ID만 지원할 수 있다. Roaming에서 어느 한 링크에서 다른 링크로 옮겨가기 위해서는 이 Link ID 가 필요한데 기존의 방식으로는 roaming을 할 수 있는 AP의 개수가 16개로 제한이 된다. 이를 해결하기 위해 AP MLD ID로 Link ID를 묶어주며 scalability issue를 해결한다. 이는 후술하는 2.2에 더 자세히 서술되어 있다.
도 18은 UHR AP MLD에 대한 High-level Architecture의 다른 예를 도시한다.
도 19는 UHR AP MLD에 대한 High-level Architecture의 또 다른 예를 도시한다.
도 19는 도 17과 비슷한 architecture을 가져가지만 interfacing이 다른 예시를 보여준다. 도 18은 AP MLD의 LMAC과 UHR UMAC이 직접적으로 연결된 것이 아닌 UMAC의 function들 중 TID-to-Link Mapping에 interface되어있다. 이러한 architecture은 TID-to-Link Mapping을 AP MLD의 UMAC에서 개별적으로 할 수도 있고 UHR UMAC에서 할 수도 있다. AP MLD와 UHR AP MLD들은 각각 다 개별적으로 DS와 연결되어 있다. 이 architecture에 활용 방식과 UHR UMAC과 interface되는 function들의 종류와 개수는 국한되지 않는다.
도 20은 MLD based가 아닌 entity만 있는 경우 High-level Architecture의 일례를 도시한다.
도 21은 MLD based가 아닌 entity만 있는 경우 High-level Architecture의 다른 예를 도시한다.
도 18, 도 20, 도 21에 있는 Entity는 Roaming을 위한 functionality들을 갖고 있다. Roaming을 할 수 있는 AP MLD들은 하나의 같은 Entity에 연결되어 있고 association, authentication, link setup 등을 이 Entity와 할 수 있다. Entity는 Control plane context들도 관리한다. Roaming을 할 수 있는 AP MLD들을 domain의 컨셉으로 그룹을 형성할 수 있는데, 이때, 하나의 domain 안에 하나 또는 그 이상의 entity가 존재할 수 있다. Non-AP STA가 Seamless Roaming을 수행하기 위해 AP간 공유되어야 하는 context들을 관리한다.
도 22는 AP MLD 영역에서 Roaming Architecture의 일례를 도시한다.
도 22는 기본적인 Roaming을 위한 구조와 과정을 보여준다.
각 AP MLD는 서로 다른 위치에 있고(즉, non-collocated되어 있고), 각 AP MLD에 속한 AP들은 동일한 또는 비슷한 위치에 있다(즉, Collocated되어 있다). 이 Collocated는 완전히 동일한 Physical device에 속한다는 것을 의미할 수 있으며, 또는 physical device에 속하지는 않아도 논리적으로 비슷한 위치에 있음을 의미할 수 있다. 기본적으로 AP MLD는 logical entity이기 때문에 어느 한 physical device일 수 있지만, 위치에 상관없이 affiliated APs를 포함하고, Multi-link operation (MLO)을 적용할 수 있는 MLD로써 동작이 가능하다. 결국은 각 AP MLD에 속한 AP들은 모두 한 AP MLD의 affiliated AP가 된다. 예를 들어, 도 22의 AP MLD 1에는 affiliated AP 1,2,3이 포함된다.
도 22를 기반으로 보통은 non-AP MLD가 이동할 때, 한 AP MLD에서 다른 AP MLD로 Roaming을 수행할 것이다. 예를 들어, non-AP MLD가 AP MLD와 Multi-link setup이 되어 있고, 각 STA 1과 STA 2는 AP MLD 1의 AP 2와 AP 3와 연결되어 있을 때, AP MLD 2로 Roaming을 수행하게 되면 STA 1은 AP 4와 연결되고 STA 2는 AP 5와 연결될 수 있다. 이 경우, Roaming 과정에서 AP 4와 AP 5가 각 STA에게 frame을 전송할 수 있도록 각 STA은 일시적으로 AP 4 와 AP 5와 association을 맺을 수도 있다.
참고로 도 22에서는 non-AP MLD는 여러 affiliated STA이 있는 non-AP MLD가 아닌 하나의 affiliated STA가 있는 non-AP MLD 또는 MLD가 아닌 non-AP STA에도 이 Architecture를 적용할 수 있다.
하지만, 반드시 다른 AP MLD간에 이동만을 Roaming으로 간주하지 않는다. 예를 들어, 한 AP MLD 내에서도 Roaming을 통해 AP를 변경할 수 있다.
즉, UHR AP MLD(또는 Roaming 가능한 그룹)는 적어도 하나의 (EHT) AP MLD를 affiliate하고 있고, 각각의 AP MLD는 non-collocated되어 있으며, 각 AP MLD에 속한 AP들은 collocated되어 있다.
일반적으로, non-AP MLD(또는 STA)이 하나의 AP MLD에서 다른 AP MLD로 Roaming을 수행한다(특정 AP MLD 내에서도 Roaming을 통해 AP를 변경할 수 있다고는 함).
AP MLD 내에서 AP를 변경하고 있기 때문에 기존 Multi-link Setup을 전체 teardown하지 않고, Multi-link Setup을 유지하면서 link를 변경하는 방법으로 Roaming을 고려할 수 있다.
이 과정들은 AP MLD 내에서 AP를 변경하고 있기 때문에 기존 Multi-link Setup을 전체 teardown하지 않고, Multi-link Setup을 유지하면서 link를 변경하는 방법으로 Roaming을 고려할 수 있다.
기본적으로 a) Announcement 과정과 b) Frame exchange로 구성될 수 있다.
a) Announcement 과정: AP MLD의 각 AP가 본 명세서에서 제안하는 MLD Roaming을 수행할 수 있는지, AP MLD 내에 Roaming AP들과 관련된 정보를 STA들에게 announce한다.
b) Frame exchange 과정: MLD Roaming을 Trigger할 수 있는 frame을 exchange하는 과정이다. Frame exchange가 완료되면 negotiation된 정보에 기반하여 MLD Roaming을 완료하고 더 이상 O_AP와 operation하지 않고, N_AP와 operation을 수행한다.
특히, 본 명세서에서는 MLD Roaming을 위해 다음 방법을 이용하는 것을 제안한다.
- 한 non-AP MLD에 속한 하나 이상의 STA은 각각 한 radio를 가지고 여러 link를 setup할 수 있다. 따라서 한 STA이 link를 add하고, delete하는 방법을 이용하는 것을 제안한다. 따라서 한 STA에 대해 2개 이상의 link가 연결될 수 있다.
- 하지만, 한 link에서만 frame exchange를 수행하고, 나머지 link에 대해서는 frame exchange를 할 수 없기 때문에 doze state 또는 disable 상태가 된다.
- 기본적으로 이를 위해서 non-AP MLD는 ML setup시 Association Request frame 등에서, 즉 Basic Multi-link ML IE를 포함하는 Management frame 전송 시 자신이 위에 설명된 capability가 가능한지를 알려준다. 이는 모든 STA이 가능하다면 Common Info field의 MLD Capabilities and Operations subfield 또는 일부 STA만 가능하다면 Link Info field에 포함될 수 있다. 포함될 정보는 다음과 같다.
=> Single-radio ML setup enabled: 한 non-AP MLD에 STA은 각각 한 radio를 가지고 여러 link를 setup할 수 있다는 정보이다. 따라서 한 STA에 대해 2개 이상의 link가 연결될 수 있음을 의미한다.
2.2 MLD Roaming에 대한 Announcement 과정
각 AP MLD의 각 AP는 본 명세서에서 제안하는 Roaming이 가능한지에 대한 여부(즉, 상술한 b) frame exchange 가능 여부)를 Announcement할 수 있다. 모든 AP들에 대해 공통적으로 전해줄 수 있는 정보는 AP가 UHR AP MLD 또는 Entity 에 속해 있는지 여부에 대해 알려줄 수 있고 세부적으로는 어떤 UHR AP MLD/ Entity에 속해 있는지 와 Collocation 정보 등을 announce할 수 있다. 만일 UHR AP MLD에 affiliate 이 되어있는 architecture 형태라면 UHR AP MLD에 affiliate 되어있는지에 대한 여부와 UHR AP MLD ID 정보를 사용할 수 있고, Entity를 사용하는 architecture 형태라면 Entity에 연결이 되어 있는지에 대한 여부와 Entity ID 같은 Entity를 식별하는 정보를 포함할 수 있다. 관련 정보는 다음과 같으며 적어도 하나 이상 포함할 수 있다.
- MLD Roaming enabled: Roaming 가능 여부에 대한 지시자(예를 들어, 1bit로 지시할 수 있음). 동일한 UHR AP MLD에 affiliate되어있거나 동일한 entity에 연결되어 있는 경우에 Roaming이 가능하다. 만일 다른 UHR AP MLD에 affiliate되어있거나 다른 entity, 즉 다른 mobility domain에 속한 AP의 경우에는 Roaming을 할 수 없고 이에 대해 MLR Roaming enabled bit로 지시해줄 수 있다.
- UHR AP MLD ID/Entity ID: 위에서 제시한 UHR AP MLD 또는 entity를 구분하는 ID. 이 UHR AP MLD ID/Entity ID에 대한 configuration은 다음과 같다.
A. ID Configuration for Roaming in AP MLD
기본적으로, Collocated되어 있는 AP MLD 들을 affiliate하고 있는 UHR AP MLD에 ID를 부여할 수 있다. 본 명세서에서는 이를 UHR AP MLD ID로 지칭한다. 이러한 UHR AP MLD ID는 UHR AP MLD 내에서 Unique하거나 전체 Network 내에서 UHR AP MLD에 Unique한 ID를 부여할 수 있다. UHR AP MLD ID를 정의하여 UHR AP MLD를 구분함으로 link의 한정된 개수로 인해 생기는 scalability 문제를 해결하고 더 많은 AP들에 대한 식별할 수 있게 도와줄 수 있다.
A-1) Unique ID Configuration within UHR AP MLD in a Network
본 절에서는 UHR AP MLD ID가 한 Network 내에서 Unique한 방법을 제안한다. 기본적으로 UHR AP MLD ID는 0,1,2,.. 등의 값을 부여할 수 있다. 예를 들어, UHR AP MLD ID가 4bit를 가지면 0~15, 8bit를 가지면 0~127 값을 가질 수 있으며 이 size는 변경될 수 있다. 다음은 각 UHR AP MLD ID가 가지는 의미를 설명한다.
1) UHR AP MLD ID가 0인 경우: 이 경우, 이 UHR AP MLD ID를 가지는 AP들은 동일한 UHR AP MLD 내에 속한 AP MLD에 속한 AP에 해당함을 알 수 있다. 즉, non-AP MLD(or STA)가 이를 인지한 경우, 해당 AP들은 현재 같은 UHR AP MLD에 속해 있다고 인지할 수 있다. 따라서, UHR AP MLD ID가 0인 경우에만 Roaming이 가능하다. 또한, 이 UHR AP MLD에 속한 각 AP가 속한 Multiple BSSID set의 다른 AP들(transmitted BSSID (TxBSSID) 또는 nontransmitted BSSID (NonTxBSSID))도 동일한 Physical resource를 사용하기 때문에 이 UHR AP MLD ID가 부여된다. 하지만, 이 AP들이 속한 (transmitted BSSID (TxBSSID) 또는 nontransmitted BSSID (NonTxBSSID)) AP MLD의 AP MLD ID는 다를 수 있다.
다른 UHR AP MLD ID는 각 UHR AP MLD에 unique하게 인지할 수 있도록 mapping한다.
A-2) Unique ID Configuration within AP MLD
본 절에서는 전체 UHR AP MLD 내에서 Roaming할 수 있는 AP들에게 Unique한 ID를 부여하는 방법을 제안한다.
- Temporary link addition/deletion: 일시적으로 한 STA에 대해 링크를 추가하거나 제거할 수 있는지를 지시한다. 즉, 한 STA이 2개 이상의 link를 일정 시간 동안 가질 수 있도록 지원함을 의미한다(예를 들어, 1bit로 지시됨).
- Collocation enabled: AP MLD끼리 collocate되어있는지 여부를 지시한다(예를 들어, 1bit로 지시됨)
=> Collocation enabled = 1이면 해당 AP와 reporting AP는 물리적으로 가까이 있음을 의미한다. 따라서 1로 설정되어 있는 AP로 옮겨가지 않고도 기존 연결된 AP와 통신할 수 있기 때문에, neighboring AP 중 Collocation enabled이 1로 설정되어 있다면 roaming을 하지 않을 수 있다. 즉 Collocation enabled = 1인 AP 에게는 MLD Roaming Request/Response를 송수신 하지 않는다.
- Collocation ID: Collocated된 AP MLD들을 구분하는 ID. 이 Collocation ID에 대한 configuration은 다음과 같다.
B. Collocation ID Configuration for Roaming in UHR AP MLD
기본적으로, Collocated되어 있는 AP MLD들에게 ID를 부여할 수 있다. 본 명세서에서는 이를 Collocation ID로 지칭한다. 이러한 Collocation ID는 다음과 같이 한 collocated된 AP MLD 집단 내에서 Unique하거나 UHR AP MLD 내에서 Collocated된 AP MLD에게 Unique한 ID를 부여할 수 있다.
B-1. Unique Collocation ID Configuration within the Collocation Set in UHR AP MLD
본 절에서는 Collocation ID가 한 Collocated된 AP MLD 집단 내에서 Unique한 방법을 제안한다. 기본적으로 Collocation ID는 0,1,2,.. 등의 값을 부여할 수 있다. 예를 들어, Collocation ID가 4bit를 가지면 0~15 값을 가질 수 있고, 8bit를 가지면 0~127 값을 가질 수 있으며, 이 size는 변경될 수 있다. 다음은 각 Collocation ID가 가지는 의미를 설명한다.
=> Collocation ID가 0인 경우: 이 경우, 이 Collocation ID를 가지는 AP들은 Collocated된 동일한 AP MLD 집단 내에 속한 AP들로 고려할 수 있다. 즉, MLD(or STA)이 이를 인지한 경우, 해당 AP들은 현재 Collocated되어 있다고 인지할 수 있다. 또한, 이 집단에 속한 각 AP가 속한 Multiple BSSID set의 다른 AP들 (transmitted BSSID (TxBSSID) 또는 nontransmitted BSSID (NonTxBSSID))도 동일한 Physical resource를 사용하기 때문에 이 Collocation ID가 부여된다. 하지만, 이 AP들이 속한 (transmitted BSSID (TxBSSID) 또는 nontransmitted BSSID (NonTxBSSID)) AP MLD의 AP MLD ID는 다를 수 있다.
동일한 Collocation ID를 가진 AP들의 set 안에 여러 AP MLD가 포함될 수 있다.
다른 Collocation ID는 각 Collocated된 AP MLD 집단에 unique하게 인지할 수 있도록 mapping한다.
B-2) Unique Collocation ID Configuration within UHR AP MLD
본 절에서는 Collocation ID가 UHR AP MLD 내에서 collocated된 AP MLD 집단 내에 Unique한 Collocation ID를 부여하는 방법을 제안한다. 기본적으로 Collocation ID는 0,1,2,.. 등의 값을 부여할 수 있다. 예를 들어, Collocation ID가 4bit를 가지면 0~15 값을 가질 수 있고, 8bit를 가지면 0~127 값을 가질 수 있으며, 이 size는 변경될 수 있다.
상기 정보들은 Beacon or Probe Response 등의 Management (MGMT) frame에 포함될 수 있으며, 새로운 MLD Roaming 정보를 포함하는 MLD Roaming IE나 기존 Reduced Neighbor Report (RNR) IE(Information Element)에 포함될 수 있다. 다음은 RNR IE에 포함될 수 있을 때의 예시이다. 기본적으로 각 AP에 대해서 TBTT Information field 안에 해당 정보가 포함될 수 있다. MLD Roaming parameters 안에는 도 23 및 도 24에 추가된 field들이 적어도 하나 이상 포함되며 도 23 및 도 24처럼 포함될 수 있다. 또한 도 23 및 도 24 외에도 본 명세서에서 정의되는 모든 field들은 적어도 하나 이상이 포함이 된다.
도 23은 RNR IE에 대한 일례를 나타낸다.
Non-AP STA는 RNR IE를 통해 Collocation Enabled = 0인 AP들에게만 MLD Roaming Request/Response를 송수신한다.
도 24는 RNR IE에 대한 다른 예를 나타낸다.
Non-AP STA는 RNR IE를 통해 Collocation ID ≠인 AP들에게만 MLD Roaming Request/Response를 송수신한다.
도 23 및 도 24와 같이 기존의 MLD Parameters subfield의 size가 충분하지 않다면 RNR IE에 새로운 MLD Roaming Parameters subfield를 만들어 정보를 포함할 수 있다. 기존 size를 변경할 수도 있지만, 이는 802.11be STA에게 decoding 이슈를 발생시킬 수 있다는 문제점이 있다. 이 경우, MLD Roaming Parameters가 포함하는 자체가 MLD Roaming이 가능함을 의미할 수 있기 때문에 MLD Roaming Parameters subfield에 MLD Roaming Enabled를 포함하지 않을 수도 있다.
RNR IE 에는 도 23과 같이 Collocation Enabled field로 다른 AP가 현재 Beacon이나 Probe Response를 보내는 AP와 collocated되어있는지 non-collocated 되어있는지 여부만 보내어 overhead를 줄일 수 있다. 또한, 도 24와 같이 AP의 Collocation ID를 알려주면서 어느 AP가 어느 Collocation set에 포함되어 있는지 알려줄 수도 있다. RNR IE는 Collocation Enabled field나 Collocation ID 중 하나만 포함할 수도 있고 둘 다 포함할 수도 있다.
도 25는 RNR IE에 대한 또 다른 예를 나타낸다.
도 25와 같이 MLD Roaming 가능 여부만 포함한다면 상기 MLD Roaming Enabled는 기존의 MLD Parameters subfield를 이용하여 지시할 수 있다. 다른 정보는 도 23과 같이 별도의 Parameter로 포함될 수 있다.
2.3 Recommendation of Roaming APs
RNR IE의 MLD Roaming enabled를 보고 enabled되어있는 AP들을 상대로 non-AP MLD가 Multi-Link Probe Request를 통하여 Roaming하고 싶은 AP들에 대한 정보를 요청하고 이에 대한 response로 roaming하기에 적합한 AP인지에 대한 여부를 Multi-Link Probe Response를 통해 알려줄 수 있다. 해당 AP로 roaming하기 위해 ML Probe request frame을 보내는 경우 MLD Roaming enabled = 1로 세팅할 수 있다.
2.3.1 AP Recommendation ML Probe Request frame format
Roaming을 위하지 않은 Probe Request인 경우 AP가 불필요하게 AP Recommendation을 하여 발생할 수 있는 overhead를 줄이기 위해 AP Roaming Recommend enabled field를 추가할 수 있다.
1) Common Info field에 포함되는 경우
도 26은 Common Info field에서의 AP Roaming Recommendation enabled field와 Roaming Reason Code field의 일례를 도시한다.
이는 Presence Bitmap을 통해 AP Roaming Recommendation enabled의 포함 여부를 지시할 수 있다. Common Info field에만 포함하는 경우에는 Probe Request를 보내는 모든 AP들에 대한 정보를 Roaming을 하기 위해 요청하는 경우이다. 즉, 적어도 하나 이상의 AP 가 Roaming이 아닌 Association 과 같은 다른 동작을 하기 위해 ML Probe Request frame에 포함된다면 Common Info에 AP Roaming Recommendation enabled field는 추가되지 않는다.
STA가 하나 이상의 AP MLD에 대한 recommendation을 요청하는 경우, AP MLD ID field를 포함하지 않아 동일한 SMD 또는 UHR AP MLD에 affiliate되어있는 하나 이상의 AP MLD의 AP 들에 대해 recommendation을 요청할 수 있다.
Roaming을 하기 이전에 non-AP STA 가 Roaming 할 수 있는 AP 들에 대한 리스트를 보낼 때 Roaming Reason Code 를 세팅하여 non-AP STA 가 로밍을 하는 이유를 AP 에게 알려줄 수 있다. 이때 Link Reconfiguration Notify Request frame에 Probe Request Multi-Link element 를 추가하여 이 Roaming Reason Code를 통하여 AP는 non-AP STA 에게 Recommend 해줄 AP 들을 정할 때 참고할 수 있다.
Roaming Reason Code 가 Link Reconfiguration Notify Request frame에 존재할 경우 Probe Request Multi-Link element 에는 포함되지 않는다. 만약 모든 link에 대한 Roaming을 요청하는 이유가 동일할 경우에는 Common Info field에 포함하여 overhead 를 줄일 수 있다. Roaming Reason Code의 설정 값은 표 2에 설명 되어있다.
추가적으로 overhead를 줄이기 위해 Presence field에 AP Roaming Recommendation enabled Present field를 생략하고 Common Info field에만 AP Roaming Recommendation enabled field가 추가될 수 있다.
2) Link Info field에 포함되는 경우
도 27은 Link Info field에서의 AP Roaming Recommendation enabled field의 일례를 도시한다.
Link Info field에 포함하는 경우는 개별적으로 AP 들에 대한 정보를 Roaming을 하기 위해 요청하는 경우이다. 적어도 하나 이상의 AP가 Roaming이 아닌 Association과 같은 다른 동작을 하기 위해 ML Probe Request frame에 포함된다면 Link Info에 AP Roaming Recommendation enabled field를 추가할 수 있다. 하나의 UHR AP MLD 또는 Entity에 속해 있는 모든 AP MLD들에 대해 recommendation하는 경우가 아닌 개별적으로 recommendation을 해줄 때는 Common Info field의 AP MLD ID를 사용하는 것이 아닌 STA Control field의 UHR AP MLD 와 AP MLD ID를 사용하여 하나 이상의 AP MLD 들에 대해 recommendation하는 AP MLD 들을 알려줄 수 있다.
하나 이상의 AP MLD에 대한 recommendation을 하는 경우 Link Info field 를 반복해서 포함하여 Recommendation을 할 수 있다. 이때, Per-STA Profile의 마지막 field를 읽고 그 뒤에 다른 AP MLD에 대한 또 다른 Per-STA Profile 이 온다는 사실을 알 수 있는 방법은 두가지가 존재한다. 첫번째 방법은 Common Info field에 있는 Number of Per-STA profile(s)의 field 에 저장된 숫자를 통해 총 몇 개의 Per-STA Profile 이 존재하는지 즉, Recommended 된 AP MLD의 개수가 recommended 되었는지 알 수 있고 그 숫자만큼의 Per-STA Profile이 존재함을 알 수 있다. 따라서, 이 개수만큼의 Per-STA Profile을 decoding한다. 두번째 방법은 Per-STA Profile의 More STA Control field를 이용할 수 있다. More STA Control이 1로 설정되어 있다면 현재 decoding하고 있는 Per-STA Profile 뒤에 또 다른 Per-STA Profile이 존재함을 알 수 있다. More STA Control field가 0인 Per-STA Profile인 경우 Recommended AP MLD 중 마지막 AP MLD의 정보임을 알 수 있다.
Link Info field를 포함하지 않고 있다면 해당 non-AP MLD에 affiliate되어있는 모든 STA 들에 대해 recommendation을 요청하는 것임을 알 수 있다.
2.3.2 AP Recommendation ML Probe Response frame format
MLD Roaming enabled를 보고 enabled되어있는 AP 들을 상대로 non-AP MLD가 Multi-Link Probe Request를 통하여 Roaming하고 싶은 AP들에 대한 정보를 요청하고 이에 대한 response로 roaming하기에 적합한 AP인지 알려줄 수 있다.
Probe Response framed의 Recommended AP List는 추가하여 Roaming을 하기에 적합한 AP 들에 대한 Link ID들의 list를 포함한다.
2.3.3. AP Recommendation Link Reconfiguration Notify Request frame
Non-AP MLD는 UHR AP MLD가 AP recommendation을 위해 Link Reconfiguration Notify frame을 전송받을 때까지 기다리지 않고 개별적으로 Link Reconfiguration Notify Request frame을 UHR AP MLD에게 보냄으로써 Link Reconfiguration Notify Request frame을 보낼 수 있다. 이때, Roaming을 요청하는 이유를 Roaming Reason Code를 통해 알려줄 수 있다. Roaming Reason Code의 설정 값은 표 2에 설명되어 있다. Non-AP STA는 이와 같이 AP에게 Roaming하는 이유를 알려준다면 AP 입장에서 더 적합한 AP를 recommend해줄 수 있다. 만약 Roaming Reason Code가 Probe Request Multi-Link element 안에 포함되어 있다면 Link Reconfiguration Notify Request frame 안에는 들어가지 않는다. 또한, Roaming을 하는 이유가 링크 마다 다른 경우에도 Link Reconfiguration Notify Request frame에 포함하지 않는다.
Order Meaning
1 Category
2 Protected UHR Action
3 Dialog Token
4 Probe Request element or Reconfiguration Multi-Link element
5 Roaming Reason Code (Optional)
Roaming Reason Value Description
0 Unspecified
1 Excessive frame loss rates and/or poor conditions
2 Excessive delay for current traffic streams
3 Insufficient QoS capacity for current traffic streams
4 Better link found
5 Better AP found
6 Received too many replay counter failures
7 Received too many data MIC failures
8 Exceeded maximum number of retransmissions
9 Received too many broadcast disassociations
10 Received too many broadcast de-authentications
11 Previous roaming failed
12 Low RSSI
13 Transition due to received Roaming Request frame
14 Preferred Roaming List of Recommendation included
15 - 255 Reserved
2.3.4. AP Recommendation Link Reconfiguration Notify frame
ML Probe Request/Response frame이 아닌 Link Reconfiguration Notify frame을 이용하여 UHR AP MLD가 non-AP MLD에게 Roaming 하기 좋은 link를 알려줄 수 있다. 하기 표 3은 Link Reconfiguration Notify frame Action field의 포맷의 일례를 나타낸다.
Order Meaning
1 Category
2 Protected UHR Action
3 Dialog Token
4 Probe Request element
5 Roaming Reason Code (Optional)
Order 4: Link Recommendation을 할 때 필요한 정보에 대해서 기존 802.11be에서 정의된 Reconfiguration Multi-link IE를 활용할 수 있다. Reconfiguration ML element에 하나의 STA Profile로 한 링크에 대해서 delete 하거나 add하게 추천해줄 수 있지만 이러한 경우 여러 link에 관해 recommendation해줄 수 없기 때문에 효율성을 높이기 위해 하나 이상의 STA Profile subelement들을 포함하여 여러 링크에 대해 Recommendation해줄 수 있다. 이때, UHR AP MLD는 roaming할 AP 중 가장 옮겨가기에 적합한 AP 선호도에 대해 알려줄 수 있다. 이는 STA Profile 순서로 나타내거나 Add/Delete Link ID list field를 통하여 알려줄 수 있다. STA Profile의 순서로 알려줄 경우에는, 가장 먼저 delete을 하거나 add하고 싶은 링크를 가장 먼저 위치하게 하고 그 다음으로 선호도가 높은 순서대로 위치하게 할 수 있다. Add/Delete Link ID list field을 통하여 알려주는 경우에도 동일하게 가장 먼저 delete을 하거나 add하고 싶은 링크를 link들의 list 중 가장 먼저 위치하게 하고 그 다음으로 선호도가 높은 순서대로 위치하게 할 수 있다.
Order 5: Non-AP STA가 먼저 Reconfiguration Notify Request frame을 보내고 Roaming Reason Code를 포함하고 있지 않거나 Reconfiguration Notify Request frame을 받지 않고 Reconfiguration Notify frame을 보내는 경우에 Roaming Reason Code를 포함하여 Reconfiguration Notify frame을 보낼 수 있다.
2.4 MLD Roaming에 대한 Frame exchange 과정
기본적으로 MLD Roaming이 Trigger되기 위해서는 Non-AP MLD(or STA)과 AP MLD간에 frame exchange가 필요하다. 여기서 frame은 MGMT frame을 활용할 수 있으며, 특히 MGMT frame의 일종인 Action frame을 활용할 수 있다. 여기서 frame은 다음과 같이 지칭한다.
- STA이 AP에게 MLD Roaming을 요청하는 frame을 MLD Roaming Request frame이라고 할 수 있다.
- AP가 STA에게 MLD Roaming을 요청하는 frame을 MLD Roaming Response frame이라고 할 수 있다.
2.4.1 MLD Roaming Request frame format
MLD Roaming Request frame format은 다음과 같은 순서로 구성될 수 있다.
Order Information
1 Category
2 UHR Action or Protected UHR Action
3 Dialog Token
4 Reconfiguration Multi-Link element
5 Context Transfer Level
Order 1: 기본적으로 Category는 새로운 UHR Action 또는 Protected UHR Action에 포함될 수 있으며, 이로 한정되지 않는다.
Order 4: MLD Roaming 요청 시 필요한 정보에 대해서 기존 802.11be에서 정의된 Reconfiguration Multi-link IE를 활용할 수 있다.
- 수정된 Reconfiguration Multi-link IE는 다음과 같다.
Order 5: MLD Roaming 요청 시 Context transfer가 필요한 또는 가능한 정도를 Context Transfer Level의 bit 값을 설정하여 알려줄 수 있다.
1) Common Info field
도 28은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Common Info field의 일례를 도시한다.
새로운 AP로 이동하면서 STA, 특히 non-AP MLD 관점에서 하나 또는 그 이상의 STA이 동시에 MLD Roaming을 수행하게 된다면 MLD capabilities and operation이나 EML Capabilities가 달라질 수 있기 때문에 추가적으로 이러한 정보를 Common Info field에 포함할 수 있다. 기존과 같이 Common Info field의 subfield 존재 여부는 Presence Bitmap에서 결정한다.
Reconfiguration Notify Request frame에 Reconfiguration Multi-Link IE가 포함되거나 Reconfiguration Notify frame을 통해 Roaming Reason Code를 전해줄 때 Reconfiguration Multi-Link IE 안에 Roaming Reason Code가 들어갈 수 있다. 이 때, 모든 링크에 관해 Roaming을 요청하는 이유가 같은 경우에는 Common Info field에 Roaming Reason Code가 들어가며 Roaming Reason Code는 표 2의 값을 가진다.
2) Link Info field
1)에서 언급했듯이 하나 이상의 STA이 동시에 MLD Roaming을 수행할 경우, 하나 이상의 Per-STA Profile subelement가 필요할 수 있다.
도 29는 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field의 일례를 도시한다.
- 기본적으로 다른 AP로 Transition했을 경우, Non-AP MLD 관점에서 각 link 간에 STR(Simultaneous transmission and receive)인지 NSTR(non-STR)인지에 대한 정보가 변경될 수 있기 때문에 STA Info field에 NSTR indication bitmap을 포함할 수도 있다. 마찬가지로 기존과 같이 STA Info의 Subfield들의 존재 여부는 STA Control의 Present subfield들에 의해 결정될 수 있다.
- 여기서 Link ID는 N_AP에 상응하는 Link ID로 지시한다.
- Complete Profile은 기존과 같이 STA의 Complete 정보, 즉 Association Request frame을 전송했을 경우 포함되는 모든 정보를 의미한다. 하지만, 이는 새로운 STA이 아닌 기존 STA이 이동하는 경우이기 때문에 STA에 대한 capabilities나 operational parameter가 변경되지 않을 수 있다. AP MLD는 이를 이미 알고 있기 때문에 Complete Profile 대신 변경된 정보만 포함하는 지시로 이용될 수 있다.
=> 예를 들어, 기존과 같이 Partial Profile인 Complete Profile = 0인 경우에는 STA Profile에 N_AP로 이동했을 경우, 변경될 정보 (즉, field/IE)만 포함한다. 또는 Complete Profile을 Changed Profile로 지칭하여 이 값이 1일 경우, STA Profile에 N_AP로 이동했을 경우, 변경될 정보(즉, field/IE)만 포함한다.
- MLD Roaming Timer는 MLD Roaming이 완료되어 O_AP와는 더 이상 operation을 하지 않고, N_AP와 operation을 하는 시간을 의미한다. 즉, Roaming할 AP로 switch할 예상되는 시간까지의 남아있는 시간을 의미할 수 있다. 이는 2.4에서 후술하는 TIM field와 관련이 있다.
=> MLD Roaming timer를 모든 AP에 공통적으로 적용한다면 도 23과 다르게 Common Info field에 포함할 수 있다. 이 때 Presence Bitmap을 통해 Common Info field 내 MLD Roaming timer의 존재유무를 지시할 수 있다.
이는 STA이 전송하는 정보이기 때문에 AP MLD에게는 Reference로 해석될 수도 있다.
- UHR AP MLD ID, AP MLD ID, Collocation ID는 도 25 및 도 26을 기반으로 상술한 정보에 추가적으로 다음과 같이 포함될 수 있다. AP MLD ID는 non-AP MLD (or STA) 가 roaming할 AP들이 속한 AP MLD의 ID이고 UHR AP MLD ID는 non-AP MLD (or STA)가 roaming할 AP들이 속한 AP MLD들이 속한 UHR AP MLD의 ID이다. AP MLD는 사전에 beacon이나 probe request/response 과정을 통해 UHR AP MLD ID를 확인하고 같은 UHR AP MLD에게만 roaming 요청을 보내는 상황에는 UHR AP MLD ID field는 Reconfiguration Multi-link element에 존재하지 않을 수 있다. 이와 같은 경우는 1-2) Common Info field에 포함되는 경우의 case 2, 2-2) Link Info field에 포함되는 경우 - 항상 존재하는 경우의 case 2, 3-2) Link Info field에 포함되는 경우 - 항상 존재하지 않는 경우 case 2에 서술되어 있다.
즉, Reconfiguration Multi-link IE에 UHR AP MLD ID, AP MLD ID, Collocation ID를 항상 포함할 것인지 여부에 따른 포맷을 설명한다.
1-1) Common Info field에 포함되는 경우 case 1
도 30은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Common Info field에 UHR AP MLD ID와 AP MLD ID가 포함되는 일례를 도시한다.
이는 Presence Bitmap을 통해 UHR AP MLD ID, AP MLD ID, Collocation ID, Roaming Recommended List, Roaming Reason Code 포함 여부를 지시할 수 있다. Common Info field에만 포함하는 경우에는 UHR AP MLD ID, AP MLD ID, Collocation ID가 동일한 AP들에게만 Roaming을 요청할 수 있다. 즉, 동일한 UHR AP MLD 내라도 여러 AP MLD ID, 여러 Collocation ID에 대해서는 요청하지 못한다. 예를 들어, 한 개 이상의 STA들이 AP MLD의 AP와 다른 AP MLD에 속한 AP로 reconfiguration 요청을 하지 못한다. 하지만, 같은 AP MLD 로 Roaming이 일반적인 경우, 아래 Link Info field에 각각 포함시키는 경우보다는 overhead를 줄일 수 있다.
1-2) Common Info field에 포함되는 경우 case 2
도 31은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Common Info field에 AP MLD ID가 포함되는 일례를 도시한다.
이전 association 과정을 통해 N_AP와 O_AP가 affiliate되어있는 UHR AP MLD가 같다는 사실을 STA과 AP가 확인하고 인지하고 있다면 UHR AP MLD ID를 전송할 필요가 없기 때문에 도 28과 같이 UHR AP MLD ID field를 별도로 추가하지 않으면서 overhead를 줄일 수 있다. Field들 포함 방식은 UHR AP MLD ID field의 포함 여부만 예외로 나머지 field들의 추가 방식은 1-1) Common Info field에 포함되는 경우 case 1과 같다.
2-1) Link Info field에 포함되는 경우 - 항상 존재하는 경우 case 1
도 32는 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field에 UHR AP MLD ID와 AP MLD ID가 포함되는 일례를 도시한다.
Link Info field는 여러 개의 Per-STA Profile subelement를 포함할 수 있으며, 각각 Link ID를 통해 한 AP에 대한 Roaming 요청을 지시할 수 있다. Per-STA Profile subelement의 STA Control field의 AP MLD ID와 UHR AP MLD ID를 통해 STA가 Roaming하려는 AP를 구분할 수 있다. 이는 여러 AP MLD ID에 해당하는 여러 AP에 대해 Roaming을 요청할 수 있지만, 동일한 AP MLD ID에 대해서 요청하는 경우에는 Common Info field에 지시하는 방법보다 오버헤드가 더 크다.
2-2) Link Info field에 포함되는 경우 - 항상 존재하는 경우 case 2
도 33은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field에 AP MLD ID가 포함되는 일례를 도시한다.
이전 association 과정을 통해 N_AP 와 O_AP가 affiliate되어있는 UHR AP MLD가 같다는 사실을 STA과 AP가 확인하고 인지하고 있다면 UHR AP MLD ID를 전송할 필요가 없기 때문에 도 31과 같이 UHR AP MLD ID field를 별도로 추가하지 않으면서 overhead를 줄일 수 있다.
3-1) Link Info field에 포함되는 경우 - 항상 존재하지 않는 경우 case 1
도 34는 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field에 UHR AP MLD ID와 AP MLD ID가 포함되는 다른 예를 도시한다.
Per-STA Profile subelement의 STA Control field의 UHR AP MLD ID Present와 AP MLD ID Present를 통해 Link ID에 해당하는 AP에 해당하는 UHR AP MLD ID와 AP MLD ID의 포함 여부를 지시할 수 있다. UHR AP MLD ID, AP MLD ID, Roaming Recommended List, Roaming Reason Code는 STA Info field나 STA Profile field에 포함될 수 있다. 마찬가지로, 이는 여러 AP MLD ID에 해당하는 여러 AP에 대해 정보를 요청할 수 있다. 특히, 1) 방법의 Common Info field에서의 지시 방법과 결합한다면 동일한 AP MLD ID에 해당하는 AP들에 대해 Roaming을 요청하는 경우, UHR AP MLD ID, AP MLD ID, Roaming Recommended List, Roaming Reason Code를 포함시키지 않음으로써 2) 방법에 비해 오버헤드를 줄일 수 있다.
한편, 또 다른 방법으로 Common Info에서 UHR AP MLD ID와 AP MLD ID가 지시된다면 이는 동일한 UHR AP MLD ID와 AP MLD ID에 해당하는 AP들의 Roaming 요청이라는 것을 Implicit하게 인지하여 UHR AP MLD ID, AP MLD ID, Roaming Recommended List, Roaming Reason Code를 포함하지 않을 수도 있다. 즉, UHR AP MLD ID Present field 와 AP MLD ID Present field는 포함되지 않을 수 있다.
3-2) Link Info field에 포함되는 경우 - 항상 존재하지 않는 경우 case 2
도 35는 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field에 AP MLD ID가 포함되는 다른 예를 도시한다.
이전 association 과정을 통해 N_AP와 O_AP가 affiliate되어있는 UHR AP MLD가 같다는 사실을 STA과 AP가 확인하고 인지하고 있다면 UHR AP MLD ID를 전송할 필요가 없기 때문에 도 32와 같이 UHR AP MLD ID field를 별도로 추가하지 않으면서 overhead를 줄일 수 있다.
또한, 본 명세서에서는 MLD Roaming을 위해 일시적으로 link를 add하고 delete하는 function을 포함하고 있기 때문에 이를 지시할 수 있는 방법이 필요하며, 다음과 같은 방법을 사용할 수 있다.
기본적으로 2bit 또는 그 이상을 사용하여 Type은 Type 0: Add / Type 1: Delete / Type 2: Temporary Add / Type 3: Temporary Delete가 될 수 있다. Temporary Delete는 Type 1으로 대체할 수도 있다. Add는 non-AP MLD의 STA이 AP MLD의 AP와 추가 link 연결 요청을 의미한다. Delete는 현재 연결된 link의 연결을 끊는(제거) 것을 의미한다. Temporary Add는 non-AP MLD의 한 STA이 여러 link를 구성할 수 있도록 현재 연결된 AP 이외에 다른 AP와의 추가 연결 요청을 의미한다.
=> 위에 Type field의 Temporary는 별도의 field로 구성될 수도 있다. 예를 들어, Temporary 1bit과 Temporary add/delete를 제외한 Type field로 구성되고, 두 field의 값(예를 들어, Temporary = 1, Type = Add)을 이용하여 Temporary Add를 구성할 수 있다.
MLD Roaming을 할 때 delete와 add를 동시에 요청하는 경우에는 Common Info의 Type를 4 또는 5로 설정해줄 수 있다. 즉, Type 4: Add then Delete, Type 5: Delete then Add로 정의할 수 있다. Type 4인 경우에는 add에 해당하는 link들을 먼저 add한 후에 delete에 해당하는 link들을 delete한다. 반대로 Type 5은 delete에 해당하는 link들을 먼저 delete한 후에 add에 해당하는 link들을 add한다.
Type 8은 Link Switch 를 하는 경우이다. Link Switch는 add와 delete와 달리 링크를 한번에 다른 link로 switch할 수 있게 해준다.
Add/Delete Link ID list field는 Type field 가 4와 5로 설정될 경우에 들어갈 수 있는 optional field이다. 이 Add/Delete Link ID list에 해당하는 Link ID들은 Add 와 delete을 동시에 요청하는 링크들의 Link ID 들의 list를 포함한다. 이 list에 포함된 Link ID를 가진 Link Info의 경우 Type가 add이면 add와 delete을 동시에 하는 링크 중 add 하는 link임을 알 수 있고 delete이면 delete하는 링크임을 알 수 있다.
Link Info의 Type field의 값은 단순히 add 만 또는 delete만 할 때 필요한 Type field의 값과 별도로 add와 delete을 동시에 요청할 때의 값도 필요하다. Link Info field의 Type 값은 다음과 같이 구성될 수 있으나 Type field의 값과 설정은 언급된 값들에 국한되지 않는다.
- Type 0: Add
- Type 1: Delete
- Type 2: Temporary Add
- Type 3: Temporary Delete
- Type 4: Add then Delete (Add)
- Type 5: Add then Delete (Delete)
- Type 6: Delete then Add (Add)
- Type 7: Delete then Add (Delete)
- Type 8: Link Switch
Type 4는 link를 add 후 delete하는 동작에서 Add하는 link의 경우이고, Type 5는 link를 add 후 delete하는 동작에서 delete하는 link의 경우이다.
Type 6는 link를 delete 후 add하는 동작에서 Add 하는 link의 경우이고, Type 7는 link를 delete 후 add하는 동작에서 delete하는 link의 경우이다.
상기 Type field와 상기 Temporary field는 다음과 같이 포함될 수 있고 적어도 하나 이상의 field들이 포함된다.
1) MLD Roaming Request frame body 또는 Reconfiguration IE의 Common Info field에 포함되는 경우
도 36은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Common Info field에 Temporary field가 포함되는 일례를 도시한다.
이 경우에는 모든 AP들에 대해 하나의 operation밖에 하지 못한다. 즉, Add인 경우에는 Link info에 지시되는 AP들에 대해서 link를 add하는 요청만 할 수 있다. 도 36은 Common Info에 포함되는 예시이다.
2-1) MLD Roaming Request frame body 또는 Reconfiguration IE의 Link Info field에 포함되는 경우
도 37은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field에 Temporary field가 포함되는 일례를 도시한다.
이 경우에는 각 AP들에 대해 다른 Operation을 요청할 수 있다. 즉, 한 AP에 대해서는 Temporary add, 다른 AP에 대해서는 delete 등을 요청할 수 있다. 도 37은 Link Info에 포함되는 예시이다.
2-2) MLD Roaming Request frame body 또는 Reconfiguration IE의 Link Info field에 포함되는 경우
도 38은 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Link Info field에 Temporary field가 포함되는 다른 예를 도시한다.
도 38은 UHR AP MLD ID field가 생략된 Link Info의 경우에 Type field가 Link Info에 포함되는 예시이다.
3-1) Add와 delete 요청을 동시에 보내는 경우의 실시예 - 새로운 링크를 먼저 add하고 기존 링크를 delete하고 싶은 경우
- Common Info field에 Type field와 Add/Delete Link ID list field 둘 다 포함하는 경우
Common Info field의 Type을 4로 설정하고 Add/Delete Link ID list에 새로 add하는 링크의 Link ID와 delete하는 Link ID들을 추가한다. 이때, add하는 링크의 Link ID를 리스트의 순서에서 delete하는 링크보다 먼저 오게 할 수 있다. 예를 들어, Add하는 링크의 Link ID가 5이고 delete하는 링크의 Link ID가 2인 경우, Add/Delete Link ID List를 5, 2와 같이 설정할 수 있다. 이렇게 순서를 정해주면서 Common Info에서 어떤 링크가 add이고 어떤 링크가 delete인지 알 수 있지만 이는 Link Info field의 Type field를 통해서도 알 수 있기 때문에 순서대로 설정하는 동작이 필요하지 않을 수 있다.
Link Info field의 Type은 이미 Common Info를 통해 Add, delete을 개별적으로 요청하는 frame인지 동시에 요청하는 frame인지 알 수 있기 때문에 Type 0, 1만 사용하여 add하는 링크인지 delete하는 링크인지 알려줄 수 있다. 또는 Common Info의 Add/Delete Link ID List에서 Link ID를 순서대로 하는 경우에는 Link Info에 Type field을 생략함으로써 overhead를 줄일 수 있다.
- Common Info field에 Type field만 포함하는 경우
Common Info field의 Type을 4로 설정하고 Link Info field에 Type 0, 1을 사용하여 add하는 링크인지 delete하는 링크인지 알려줄 수 있다.
- Common Info field에 Type field와 Add/Delete Link ID list field 둘 다 포함하지 않는 경우
이 경우 Link Info field의 Type field 값을 4 또는 5를 사용하여 Add then delete을 요청할 수 있다. 이 때 add하는 링크는 Type 4로 설정되고 Type 5는 delete하는 링크에 설정된다. Type 4로 설정된 링크를 먼저 Add한 후 Type 5로 설정된 링크를 delete한다.
3-2) Add 와 delete 요청을 동시에 보내는 경우의 실시예 - 기존 링크를 먼저 delete하고 새로운 링크를 add하고 싶은 경우
- Common Info field에 Type field와 Add/Delete Link ID list field 둘 다 포함하는 경우
Common Info field의 Type을 5로 설정하고 나머지 동작은 3-1) Add와 delete 요청을 동시에 보내는 경우의 실시예 - 새로운 링크를 먼저 add하고 기존 링크를 delete하고 Common Info field에 Type field와 Add/Delete Link ID list field 둘 다 포함하는 경우와 동일하다.
- Common Info field에 Type field만 포함하는 경우
Common Info field의 Type을 5로 설정하고 나머지 동작은 3-1) Add와 delete 요청을 동시에 보내는 경우의 실시예 - 새로운 링크를 먼저 add하고 기존 링크를 delete하고 Common Info field에 Type field만 포함하는 경우와 동일하다.
- Common Info field에 Type field와 Add/Delete Link ID list field 둘 다 포함하지 않는 경우
이 경우 Link Info field의 Type field 값을 6 또는 7을 사용하여 Add then delete을 요청할 수 있다. 이 때 add하는 링크는 Type 6로 설정되고 Type 7는 delete하는 링크에 설정된다. Type 6로 설정된 링크를 먼저 Add한 후 Type 7로 설정된 링크를 delete한다.
4) Type field를 이용하여 Link Switch를 하는 경우
도 39는 본 실시예에서 제안하는 Reconfiguration Multi-link IE의 Common Info field에 AP Removal Timer 필드가 포함되는 일례를 도시한다.
Link를 변경할 때 add/delete을 사용하는 게 아닌 Common Info의 Type 8를 이용하여 link switch할 경우엔 MLD Roaming Request frame을 보내는 link를 없애고 Link Info field에 있는 Link ID로 switch 한다. Link switch의 경우엔 Link Info field에 Type field를 생략하여 overhead를 줄일 수 있다 Link Switch를 할 때 언제까지 link switch해야하는지 AP와 STA가 알아야한다. 이는 AP가 정해서 STA에게 알려줄 수도 있고 STA이 정해서 AP에게 알려줄 수 있다. Link switch로 인해 New AP와 Old AP의 채널이 서로 다르며, New AP에서는 삭제에 대한 정보가 필요하고, Old AP에서는 추가에 대한 정보가 필요하다.
AP가 STA에게 알려주는 경우에는 후술하는 도 40 또는 도 41과 같이 Channel Switch Count field를 추가하여 MLD Roaming Response에서 알려줄 수 있다. STA이 정해서 AP에게 알려주는 경우에는 Reconfiguration element에 있는 Delete Timer field(또는 AP Removal Timer field)를 사용하여 MLD Roaming Request에서 알려줄 수 있다.
Reconfiguration IE의 Delete Timer를 사용하여 link switch 완료 시간을 알려주는 경우 MLD Roaming Request를 통해 link switch를 요청한 모든 링크들이 같은 Delete Timer 값을 가진다면 overhead를 줄이기 위해 도 36과 같이 Link Info가 아닌 Common Info에 추가될 수 있다. 이 때 Link Info의 Delete Timer Present field(또는 AP Removal Timer Present field)를 사용하여 Delete Timer field를 사용하지 않을 수 있다. 만일 link switch 요청된 링크들의 Delete Timer 값이 서로 다르다면 Common Info가 아닌 Link Info에 Delete Timer field가 추가될 수 있다. Link switch 하려는 링크가 하나라면 Common Info에 Delete Timer field가 추가될 수 있고, User Info에 Delete Timer field가 추가될 수도 있다.
2.4.2 MLD Roaming Response frame format
MLD Roaming Response frame에서는 Multi-link Setup을 유지하면서 link를 변경해야 하기 때문에 필수적으로 제공되어야 할 link-level parameter를 고려할 필요가 있다.
Order Information
1 Category
2 UHR Action or Protected UHR Action
3 Dialog Token
4 Status Code
5 Basic Multi-Link element
6 Group key Information
7 AID
8 Channel Switching Announcement element (optional)
9 Extended Channel Switching Announcement element (optional)
10 TID-to-link Mapping element (optional)
11 Context Transfer Level
12 Context Transfer Contents Feedback
13 Queued Packets
Order 1: 기본적으로 Category는 새로운 UHR Action 또는 Protected UHR Action에 포함될 수 있으며, 이로 한정되지 않는다.
Order 4: Status Code는 기존 Status code field를 활용할 수 있다.
- MLD Roaming 요청에 대한 응답 시 AP MLD와 N_AP에 대한 필요한 정보에 대해서 기존 802.11be에서 정의된 Basic Multi-link IE를 활용할 수 있다.
Order 5: 수정된 Basic Multi-link IE는 다음과 같다.
Order 11: MLD Roaming Response를 보낼 때 Context transfer가 필요한 정도를 Context Transfer Level의 bit 값을 설정하여 알려줄 수 있다.
Order 12: Context Transfer가 완료되고 실제로 Context Transfer를 통해 전송된 contents들을 알려준다. 이때, Context Transfer Level을 이용할 수 있다.
해당 정보를 알려주는 방법은 크게 Bitmap 방식과 Indexing 방식으로 나눌 수 있다.
- Bitmap 방식: 각 Context Transfer Level 당 0 또는 1 bit로 표시하여 해당 레벨에 해당하는 context가 실제로 전송이 되었으면 1로 설정하고 전송되지 않았다면 0으로 설정한다. 이렇게 실제로 transfer된 내역들에 따라 STA은 Roaming 이후에 다시 negotiation을 하거나 establishment해야하는 것들을 정할 수 있다. 0과 1을 사용하지 않고도 Context Transfer Level에 해당하는 bit의 존재 유/무로 알려줄 수 있다. 예를 들어 bit 1:BA agreement인데 해당 bit가 존재하지 않는다면 transfer되지 않았다는 것을 알 수 있다.
- Indexing 방식:
a. 누적 방식: Context Transfer Level의 순서대로 누적되어 만약 bit 2가 표시된다면 bit 0, 1, 2에 해당하는 context가 모두 다 전송이 되었다는 것을 알 수 있다.
b. Grouping 방식: 특정 bit들을 grouping한 bit로 알려줄 수 있다. 예를 들어, bit 3이 BA agreement와 SN/PN을 포함한 group이고 bit 4는 SN/PN과 Packet Reordering을 포함한 group일 수 있다. 해당 예시같은 경우 만약 Roaming Response에서 context transfer를 알려주는 field가 bit 3으로 설정되어 있다면, SN/PN과 BA Agreement에 해당하는 Context가 transfer되었음을 알 수 있다. Grouping의 방법은 여러가지 경우의 수가 존재하며 해당 예시로 국한하지 않는다.
위와 같이 Context transfer된 항목의 유/무를 알려줄 수도 있고 Context transfer가 되지 않은 것들 또는 Context transfer가 된 것들만 알려줄 수 있다.
Order 13: Roaming을 할 때 non-AP STA이 Roaming Response frame을 받는 AP MLD(e.g. current AP MLD)의 queue에 packet의 존재 여부를 Queued Packets 필드로 알려줄 수 있다. Queued Packets 필드가 1로 설정되어 있는 경우 Queue에 packet이 남아있다는 뜻이고 Queued Packets 필드가 0으로 설정되어 있다면 queue에 남아있는 packet이 없다는 것을 뜻하거나 반대가 될 수 있다. Roaming을 할 때 non-AP STA는 상기 Queued Packets 필드를 읽고 새로 roaming을 하는 AP MLD에 전이할지(또는 넘어갈지) 말지 여부를 정할 수 있다. Non-AP MLD이 Roaming Response를 받았을 때 상기 Queued Packets 필드를 읽고 만일 상기 Queued Packets 필드가 1로 설정되어 있다면 후술한 추가적인 정보들을 반영하여 non-AP MLD가 Target AP MLD로 roaming하기 전에 Serving AP MLD로부터 DL Data을 언제까지 어떻게 수신 받아야함을 알 수 있다. 반대로 상기 Queued Packets 필드가 0으로 설정되어 있다면 Roaming Response를 받고 바로 Target AP MLD와 DL/UL transmission을 시작할 수 있다. Channel Switch Count는 이전 링크가 add된 상태에서 연결되어 있는 AP MLD들과 operation을 허용(e.g. DL forwarding)하는 구간이고, 상기 구간은 상기 Channel Switch Count가 만료되면 기존 link는 delete되고 새로 add된 link로 roaming한 AP MLD로 operation하는, 완전히 새로운 link로 옮겨가는 시점까지로 설정된다. 상기 Channel Switch Count의 값은 TBTTs의 개수를 나타낼 수도 있고 이 외에도 X unit (e.g. us) 단위로 실제 걸리는 시간 구간으로 나타낼 수 있다. Channel Switch Count field를 통해 AP는 STA에게 언제까지 새로운 링크로 link switch를 수행할지 알려줄 수 있다. 각 링크가 link switch를 완료해야 하는 시간이 서로 다를 경우에는 Link Info에 Channel Switch Count field를 추가하여 각 링크에 대해 개별적으로 언제까지 link switch를 마칠지 알려줄 수 있다. MLD Roaming Request에서 한 링크에 대해서만 link switch를 요청한다면 Channel Switch Count field는 Common Info에 포함되거나 또는 Link Info에 포함될 수 있다. O_AP에서 N_AP로 옮겨갈 때 새로운 link로 switch를 한 상황에서 두 링크의 channel이 다른 경우 다른 링크로 언제 옮겨졌는지 등에 대한 정보를 주고받을 수 없을 때에, 상기 Channel Switch Count를 통해 지정된 Count 또는 시간을 정해 놓음으로써 channel이 달라도 어느 시점까지 link switch가 이뤄지는지 알 수 있다.
Queued packet 이 1로 설정되어 있는 경우, 추가적인 정보들에 대해서도 알려줄 수 있다. 해당 정보들은 다음과 같다.
- DL data size: DL data의 실제 양
- Number of pending MSDUs(MAC Service Data Units): 아직 전송이 되지 않은 MSDU의 개수
- SN 또는 PN 관련 정보 ex) Last SN/PN among MSDUs or Range
- TIDs(Traffic IDentifiers) for pending MSDU: TID는 bitmap 또는 값으로 알릴 수 있다. 이때, TID는 MPDU(MAC Physical Data Unit)에 포함된 MSDU를 식별하는 식별자이다.
AP MLD는 위의 추가적인 정보들을 하나 이상 포함하여 알려줄 수 있다.
Queued Packets 필드를 이용하여 Serving AP MLD의 queue에 쌓여있는 DL Data의 존재 여부를 알려주는 예시는 도 63 및 도 64에서 후술한다.
1) Common Info field
도 40은 본 실시예에서 제안하는 Basic Multi-link IE의 Common Info field의 일례를 도시한다.
- 기존 Common Info field를 활용할 수 있다. 여기의 Common Info 정보는 하나 이상의 STA이 MLD Roaming을 수행하는 N_AP들에 상응하는 Common Info 정보이다.
- Beacon이나 Multi-Link Probe Response frame을 보낼 때 Basic Multi-link element를 포함하는 경우에는 Channel Switch Count Present field를 이용해 Channel Switch Count field를 포함하지 않을 수 있다.
MLD Roaming Request frame의 Reconfiguration IE에 Common Info의 Type field가 Type 8로 설정되거나 User Info의 Type field가 Type 8로 설정되어 있는 경우에 Basic ML IE의 Common Info에 Channel Switch Count field를 포함할 수 있다. Common Info에 포함하는 경우는 만약 Link Switch의 요청을 하나의 MLD Roaming Request로 동시에 요청하는 하나 이상의 link(s)가 새로운 link(s)로 switch를 마무리해야 하는 시간이 동일할 때 Common Info의 Channel Switch Count field를 사용하여 AP에게 언제까지 Link switch를 수행하는지 알려줄 수 있다. Link Switch Count는 링크가 새로운 링크로 switch하기 이전까지 기존 link로 연결되어 있는 AP로부터 받을 TBTTs의 개수를 나타낸다. Channel Switch Count field를 통해 AP는 STA에게 언제까지 새로운 링크로 link switch를 수행할지 알려줄 수 있다. Channel Switch Count는 이전 링크가 add된 상태에서 연결되어 있는 AP MLD들과 operation을 허용(e.g. DL forwarding)하는 구간이고 만료되면 기존 link는 delete되고 새로 add된 link로 roaming 한 AP MLD로 동작하는, 완전히 새로운 link로 옮겨가는 시점까지 해당된다. 해당 값은 TBTTs의 개수를 나타낼 수도 있고 이 외에도 X unit (e.g. us) 단위로 실제 걸리는 Channel Switch Count field를 통해 AP는 STA에게 언제까지 새로운 링크로 link switch 를 수행할지 알려줄 수 있다. 각 링크가 link switch를 완료해야 하는 시간이 서로 다를 경우에는 Link Info에 Channel Switch Count field를 추가하여 각 링크에 대해 개별적으로 언제까지 link switch를 마칠지 알려줄 수 있다. MLD Roaming Request에서 한 링크에 대해서만 link switch를 요청한다면 Channel Switch Count field는 Common Info에 포함되거나 또는 Link Info에 포함될 수 있다. Channel Switch Count는 O_AP에서 N_AP로 옮겨갈 때 새로운 link 로 switch를 한 상황에서 두 링크의 channel이 다른 경우 다른 링크로 언제 옮겨졌는지 등에 대한 정보를 주고 받을 수 없을 때에 지정된 Count 또는 시간을 정해 놓음으로써 channel이 달라도 어느 시점까지 link switch가 이뤄지는지 알 수 있다.
2) Link Info field
1)에서 언급했듯이 하나 이상의 STA이 동시에 MLD Roaming을 수행할 경우, 그에 상응하는 AP들에 대해 하나 이상의 Per-STA Profile subelement가 필요할 수 있다.
기존 Basic Multi-link IE의 STA Control field와 STA Info field, 그리고 STA Profile field에 대해 변경되는 정보는 다음과 같다.
도 41은 본 실시예에서 제안하는 Basic Multi-link IE의 Link Info field의 일례를 도시한다.
- 기본적으로 STA Info field의 Link ID는 N_AP에 상응하는 Link ID로 지시한다.
- Complete Profile은 기존과 같이 AP의 Complete 정보, 즉 Association Response frame을 전송했을 경우 포함되는 모든 정보를 의미한다. 하지만, AP는 STA이 MLD Roaming을 수행하기 때문에 Capability나 operational parameter가 변경되지 않을 수 있다. 따라서 이 경우에는 Complete Profile을 0으로 지시한다.
- 추가적으로 MLD Roaming Timer에 대한 정보를 포함한다. 이를 위해 STA Control field에는 MLD Roaming Timer Present field를 STA Info field에는 MLD Roaming Timer field를 포함한다. 이는 MLD Roaming이 완료되어 O_AP와는 더 이상 operation을 하지 않고, N_AP와 operation을 하는 시간을 의미한다. 이는 STA이 전송했던 MLD Roaming Timer 정보를 활용할 수도 있으며, STA이 이를 전송했고, Response의 Status Code가 SUCCESS인 경우에는 포함하지 않을 수 있다.
Association Request/Response에 포함되는 경우에 Basic Multi-Link IE를 포함하는 경우에는 Roaming 관련한 정보들이 필요하지 않기 때문에 도 37에 포함된 UHR MLD MAC Address, UHR AP MLD ID, Collocation ID, Channel Switch Count, UHR Roaming Timer와 도 38에 포함된 MLD Roaming Timer, UHR AP MLD ID, AP MLD ID, Channel Switch Count field들을 presence field를 이용하여 추가하지 않고 Basic ML element를 구성할 수 있다.
각 링크가 link switch를 완료해야 하는 시간이 서로 다를 경우에는 Link Info에 Channel Switch Count field를 추가하여 각 링크에 대해 개별적으로 언제까지 link switch를 마칠지 알려줄 수 있다. MLD Roaming Request에서 한 링크에 대해서만 link switch를 요청한다면 Channel Switch Count field는 Common Info에 포함되거나 Link Info에 포함될 수 있다.
- UHR AP MLD ID와 AP MLD ID는 위 정보에 추가적으로 다음과 같이 포함될 수 있다. AP MLD ID는 Non-AP MLD(or STA)가 Roaming할 AP들이 속하는 AP MLD의 ID이고, UHR AP MLD ID는 non-AP MLD (or STA)가 roaming할 AP들이 속한 AP MLD들이 속한 UHR AP MLD의 ID이다. MLD Roaming Request frame에 UHR AP MLD ID가 포함되어 있지 않은 경우 같은 UHR AP MLD에 affiliate 되어있다는 것을 알 수 있어 UHR AP MLD ID field를 포함하지 않을 수 있다. 이와 같은 경우는 1-2) Common Info field에 포함되는 경우의 case 2, 2-2) Link Info field에 포함되는 경우 - 항상 존재하는 경우의 case 2, 3-2) Link Info field에 포함되는 경우 - 항상 존재하지 않는 경우 case 2에 서술되어 있다.
1-1) Common Info field에 포함되는 경우 case 1
이는 위에서 기술된 Reconfiguration ML IE에서 1-1) Common Info field case 1에 포함되는 경우 방법으로 요청한 경우에 활용 가능하다.
마찬가지로 Presence Bitmap을 통해 UHR AP MLD ID와 AP MLD ID의 포함 여부를 지시하며, 이에 따라 UHR AP MLD ID와 AP MLD ID는 Common Info field에 포함된다. 이는 UHR AP MLD ID = 0이고 Collocation ID≠인 AP MLD의 AP들의 정보만 제공할 수 있다.
1-2) Common Info field에 포함되는 경우 case 2
이는 위에서 기술된 Reconfiguration ML IE에서 1-2) Common Info field에 포함되는 경우 case 2 방법으로 요청한 경우에 활용 가능하다.
마찬가지로 Presence Bitmap을 통해 AP MLD ID 포함 여부를 지시하며, 이에 따라 AP MLD ID는 Common Info field에 포함된다.
2-1) Link Info field에 포함되는 경우 - 항상 존재하는 경우 case 1
이는 위에서 기술된 Reconfiguration ML IE에서 2-1) Link Info field에 포함되는 경우 - 항상 존재하는 경우 case 1 방법으로 요청한 경우에 활용 가능하다.
각 Per-STA Profile subelement의 Link ID에 해당하는 AP에 해당하는 UHR AP MLD ID와 AP MLD ID를 STA Control field에 포함한다. 이는 여러AP MLD ID에 해당하는 여러 AP에 대한 정보를 제공할 수 있지만, 동일한 AP MLD ID에 대해서 제공하는 경우에는 Common Info field에 지시하는 방법보다 오버헤드가 더 크다.
2-2) Link Info field에 포함되는 경우 - 항상 존재하는 경우 case 2
이는 위에서 기술된 Reconfiguration ML IE에서 2-2) Link Info field에 포함되는 경우 - 항상 존재하는 경우 case 2 방법으로 요청한 경우에 활용 가능하다.
각 Per-STA Profile subelement의 Link ID에 해당하는 AP에 해당하는 AP MLD ID를 STA Control field에 포함한다. 이는 여러AP MLD ID에 해당하는 여러 AP에 대한 정보를 제공할 수 있지만, 동일한 AP MLD ID에 대해서 제공하는 경우에는 Common Info field에 지시하는 방법보다 오버헤드가 더 크다.
3-1) Link Info field에 포함되는 경우 - 항상 존재하지 않는 경우 case 1
이는 위에서 기술된 Reconfiguration ML IE에서 3-1) Link Info field에 포함되는 경우 - 항상 존재하지 않는 경우 case 1에 방법으로 요청한 경우에 활용 가능하다.
Per-STA Profile subelement의 STA Control field의 UHR AP MLD ID Present 와 AP MLD ID Present를 통해 Link ID에 해당하는 AP에 해당하는 AP MLD ID의 포함 여부를 지시할 수 있다. UHR AP MLD ID와 AP MLD ID는 STA Info field나 STA Profile field에 포함될 수 있다. 마찬가지로, 이는 여러 AP MLD ID에 해당하는 여러 AP에 대해 정보를 제공할 수 있다. 특히, 1) 방법의 Common Info field에서의 지시 방법과 결합한다면 동일한 AP MLD ID에 해당하는 AP들의 정보만 제공하는 경우, UHR AP MLD ID 와 AP MLD ID를 포함시키지 않음으로써 2) 방법에 비해 오버헤드를 줄일 수 있다.
=> 한편, 위에서 기술된 AP MLD ID 설정 관련 Unique ID Configuration within the Collocation Set in AP MLD의 경우, Collocation ID가 0이라면 UHR AP MLD ID, AP MLD ID, Collocation ID는 생략될 수도 있다. 즉, Collocation ID가 존재하지 않다면 request를 수신한 AP는 자신이 속한 AP MLD에 대한 다른 AP들의 정보 요청임을 implicit하게 인지할 수 있다.
=> 한편, 또 다른 방법으로 Common Info에서 Collocation ID가 지시된다면 이는 동일한 Collocation Set에 해당하는 AP들의 정보라는 것을 Implicit하게 인지하여 UHR AP MLD ID, AP MLD ID, Collocation ID를 포함하지 않을 수도 있다. 즉, UHR AP MLD ID Present와 AP MLD ID Present field는 포함되지 않을 수 있다.
3-2) Link Info field에 포함되는 경우 - 항상 존재하지 않는 경우 case 2
이는 위에서 기술된 Reconfiguration ML IE에서 3-2) Link Info field에 포함되는 경우 - 항상 존재하지 않는 경우 case 2에 방법으로 요청한 경우에 활용 가능하다.
Per-STA Profile subelement의 STA Control field의 AP MLD ID Present를 통해 Link ID에 해당하는 AP에 해당하는 AP MLD ID의 포함 여부를 지시할 수 있다. AP MLD ID는 STA Info field나 STA Profile field에 포함될 수 있다. 마찬가지로, 이는 여러 AP MLD ID에 해당하는 여러 AP에 대해 정보를 제공할 수 있다. 특히, 1) 방법의 Common Info field에서의 지시 방법과 결합한다면 동일한 AP MLD ID에 해당하는 AP들의 정보만 제공하는 경우, AP MLD ID를 포함시키지 않음으로써 2) 방법에 비해 오버헤드를 줄일 수 있다.
=> 한편, 위에서 기술된 AP MLD ID 설정 관련 Unique ID Configuration within the Collocation Set in AP MLD의 경우, Collocation ID가 0이라면 AP MLD ID, Collocation ID는 생략될 수도 있다. 즉, Collocation ID가 존재하지 않다면 request를 수신한 AP는 자신이 속한 AP MLD에 대한 다른 AP들의 정보 요청임을 implicit하게 인지할 수 있다.
=> 한편, 또 다른 방법으로 Common Info에서 Collocation ID가 지시된다면 이는 동일한 Collocation Set에 해당하는 AP들의 정보라는 것을 Implicit하게 인지하여 AP MLD ID, Collocation ID를 포함하지 않을 수도 있다. 즉, UHR AP MLD ID Present와 AP MLD ID Present field는 포함되지 않을 수 있다.
Order 6: Group key Information
기본적으로 Group key는 link마다 다르기 때문에 N_AP들에 대한 Group key 정보를 제공할 필요가 있다.
도 42는 Group Key Information 필드의 일례를 도시한다.
도 42를 참조하면, Length는 Group key Information에 대한 길이를 지시한다. 각 N_AP에 대한 Group key Information은 802.11be에서 정의된 각각 N_AP의 Link ID를 포함하는 MLO GTK KDE format, MLO IGTK KDE, MLO BIGTK KDE를 포함한다.
Order 7: 전체 AID(Association Identifier) space는 한정되어 있기 때문에 각 AP MLD에서 AID를 관리할 수 있다. 즉, 다른 AP MLD으로 Roaming 시 AID를 부여할 수 있다. 하지만, 다음과 같은 경우에는 AID를 포함하지 않을 수 있다.
- 다른 AP MLD으로 Roaming하고 동일한 AID를 부여하는 경우
- 기존과 같이 전체 AID space를 UHR AP MLD가 관리하는 경우
Order 8, 9: 이렇게 포함되는 경우, Roaming을 할 각 AP의 채널이 동일하지만 이전에 연결되어 있던 AP들의 채널과는 다르다고 볼 수 있다. 하지만, 다음과 같은 경우는 다르게 Order 8,9에 대해서 포함될 수 있다.
- MLD Roaming을 enable하는 모든 AP들이 항상 동일 채널이라고 가정하면 이 IE들을 포함하지 않는다.
- Roaming할 하나의 AP의 채널이 이전 연결될 AP의 채널과 동일할 수도 있고 다를 수 있다. 이런 경우, Channel Switching Announcement IE나 Extended Channel Switching Announcement IE는 Order 5에 존재하는 Basic Multi-link IE의 Link Info에 각각 포함될 수 있다. 즉, roaming할 각 AP에 대한 channel switch를 수행하기 위함이다.
Order 10: 새로 연결될 link에 대해서 미리 TID-to-link mapping을 통해 TID를 mapping시키기 위해서 활용할 수 있다. TID-to-link mapping을 별도로 하지 않는다면 default mapping을 적용할 수 있다.
또한, MLD Roaming Request/Response frame에 둘다 MLD Roaming Timer를 추가할 수 있다.
추가적으로 AP MLD는 위의 Reconfiguration ML IE의 MLD Roaming Timer를 포함할 수 있다. 이는 마찬가지로 AP MLD가 현재 Roaming을 제어할 수 있기 때문에 정해진 MLD Roaming Timer를 지시할 수 있다. 예를 들어, STA이 MLD Roaming Timer를 포함하지 않았거나 적절하지 않다면 AP MLD가 설정하여 알려줄 수 있다. 또한, STA이 MLD Roaming Timer를 전송하지 않았다면 AP MLD가 설정하여 알려줄 수 있다. MLD Roaming Timer의 의미는 동일하다. 즉, MLD Roaming이 완료되어 O_AP와는 더 이상 operation을 하지 않고, N_AP와 operation을 하는 시간을 의미한다.
=> Temporary Add 요청을 수신한 경우, MLD Roaming Timer가 만료된 후 완전히 STA이 O_AP와 연결을 끊고(즉, Temporary Delete or Delete), N_AP와 연결될 수 있게 한다.
=> MLD Roaming timer를 모든 AP에 공통적으로 적용한다면 Common Info field에 포함할 수 있다. 이 때 Presence Bitmap을 통해 Common Info field의 존재유무를 지시할 수 있다.
- 추가적으로 MLD Roaming Response frame에 MLD Roaming Timer에 대한 정보를 포함할 수 있다. 이를 위해 STA Control field에는 MLD Roaming Timer Present field를 STA Info field에는 MLD Roaming Timer field를 포함한다. 이는 STA이 Roaming할 AP로부터 data를 수신할 수 있는 시간까지 남아있는 시간을 의미할 수 있다. 이는 STA이 전송했던 MLD Roaming Timer 정보를 활용할 수도 있다. 이는 기본적으로 2.5에서 제시한 TIM field와 관련이 있다.
=> MLD Roaming timer를 모든 AP에 공통적으로 적용한다면 Common Info field에 포함할 수 있다. 이 때 Presence Bitmap을 통해 Common Info field의 존재유무를 지시할 수 있다. 또는 MLD Roaming Probe Response frame body에 포함될 수 있다.
2.5 MLD Roaming 예시
MLD Roaming을 수행하는 AP와 STA의 동작 과정은 다음과 같다.
도 43은 Collocation Enabled 필드를 사용하여 N_AP가 로밍이 가능한지 여부를 확인하는 절차를 도시한다.
도 43을 참조하면, AP의 송수신 과정은 다음과 같다.
O_AP는 Beacon에 RNR IE를 포함하여 STA에게 송신한다. O_AP는 STA에게 MLD Roaming Request frame을 받으면 STA이 roaming하고 싶은 AP의 Link ID, AP MLD ID, UHR AP MLD ID(optional)를 통해 확인한다. O_AP는 STA에게 이에 대한 accept 여부와 Roaming Response frame format에 서술된 정보들을 MLD Roaming Response frame을 통하여 전송한다.
도 43을 참조하면, STA의 송수신 과정은 다음과 같다.
STA은 Beacon을 수신하면 TBTT Information field에 MLD Roaming Parameters field의 존재 여부를 확인한다. STA은 MLD Roaming Parameters field 내에 MLD Roaming Enabled, UHR AP MLD ID, Collocation Enabled field들을 확인한다. 이때, MLD Roaming Enabled=1, UHR AP MLD ID=0, Collocation Enabled=0으로 설정된다. STA은 O_AP에게 MLD Roaming Request frame을 전송한다. STA은 O_AP로부터 MLD Roaming Response frame을 받고 accept되면 N_AP로 roaming한다.
도 44는 Collocation ID를 사용하여 N_AP가 로밍이 가능한지 여부를 확인하는 절차를 도시한다.
도 44를 참조하면, AP의 송수신 과정은 다음과 같다.
O_AP는 Beacon에 RNR IE를 포함하여 STA에게 송신한다. O_AP는 STA에게 MLD Roaming Request frame을 받으면 STA이 roaming하고 싶은 AP의 Link ID, AP MLD ID, UHR AP MLD ID(optional)를 통해 확인한다. O_AP는 STA에게 이에 대한 accept 여부와 Roaming Response frame format에 서술된 정보들을 MLD Roaming Response frame을 통하여 전송한다.
도 44를 참조하면, STA의 송수신 과정은 다음과 같다.
STA은 Beacon을 수신하면 TBTT Information field에 MLD Roaming Parameters field의 존재 여부를 확인한다. STA은 MLD Roaming Parameters field 내에 MLD Roaming Enabled, UHR AP MLD ID, Collocation ID들을 확인한다. 이때, MLD Roaming Enabled=1, UHR AP MLD ID=0, Collocation ID≠으로 설정된다. STA은 O_AP에게 MLD Roaming Request frame을 전송한다. STA은 O_AP로부터 MLD Roaming Response frame을 받고 accept되면 N_AP로 roaming한다.
도 45는 Reconfiguration element에 UHR AP MLD ID가 들어가는 경우의 MLD Roaming 절차를 도시한다.
도 45를 참조하면, AP의 송수신 과정은 다음과 같다.
O_AP는 Beacon을 통하여 다른 AP들에 대한 정보를 STA에게 송신한다. STA에게서 MLD Roaming Request frame을 받으면 STA은 roaming하고 싶은 AP의 ID를 Link ID, AP MLID를 통해 확인한다. 추가적으로 MLD Roaming Request frame에 UHR AP MLD ID가 포함되어 있는 경우 STA은 UHR AP MLD ID도 같이 확인한다. O_AP는 STA에게 accept 여부와 2.4.2. Roaming Response frame format에 서술된 정보들을 MLD Roaming Response frame을 통하여 전송한다.
도 45를 참조하면, STA의 송수신 과정은 다음과 같다.
STA은 Beacon을 O_AP를 통하여 다른 AP들에 대한 정보들을 수신한다. STA은 O_AP에게서 받은 AP들에 대한 정보를 기반으로 roaming할 AP를 결정한다. STA은 O_AP에게서 Roaming Request frame을 전송한다. STA은 O_AP로부터 MLD Roaming Response frame을 받고 accept되면 N_AP로 roaming을 한다.
도 46은 Reconfiguration element에 UHR AP MLD ID가 들어가지 않는 경우의 MLD Roaming 절차를 도시한다.
도 46을 참조하면, AP의 송수신 과정은 다음과 같다.
O_AP는 Beacon을 통하여 다른 AP들에 대한 정보를 STA에게 송신한다. STA에게서 MLD Roaming Request frame을 받으면 STA은 roaming하고 싶은 AP의 ID를 Link ID, AP MLID를 통해 확인한다. O_AP는 STA에게 accept 여부와 2.4.2. Roaming Response frame format에 서술된 정보들을 MLD Roaming Response frame을 통하여 전송한다.
도 46을 참조하면, STA의 송수신 과정은 다음과 같다.
STA은 Beacon을 O_AP를 통하여 다른 AP들에 대한 정보들을 수신한다. STA은 O_AP에게서 받은 AP들에 대한 정보를 기반으로 roaming할 AP를 결정한다. STA은 O_AP에게서 Roaming Request frame을 전송한다. STA은 O_AP로부터 MLD Roaming Response frame을 받고 accept되면 N_AP로 roaming을 한다.
도 47은 Collocated된 AP 집합의 일례를 도시한다.
도 47은 non-AP MLD가 기존에 AP 2에 연결되어 있는 상황에서 움직일 때 Collocation 정보에 따라 roaming 여부를 결정하는 예시를 보여준다. Collocation 정보는 RNR IE의 Collocation Enabled field나 Collocation ID field를 통해 알 수 있다. Non-AP MLD 주변에 AP MLD 2에 affiliate되어있는 AP 4와 AP 5도 존재하지만 이들은 현재 연결되어 있는 AP 2와 같은 Collocated AP set에 포함되어 있기 때문에, non-AP MLD는 AP 4와 AP 5에 대해 roaming request를 하지 않는다. 반면 non-AP MLD는 AP 2와 다른 Collocated AP set에 포함되어 있는 AP 6, AP 7, AP 8에게는 roaming request가 가능하다. 이렇게 Collocated AP set을 정의하여 물리적으로 가까이 있어 Roaming할 필요가 없는 AP들에 대한 정보를 알려줌으로써, 불필요한 roaming을 막을 수 있다.
1) 예시 #1 - 일부 STA만 AP로 먼저 Roaming하는 경우
도 48은 MLD Roaming 절차에 대한 예시 1을 도시한다.
도 48은 한 번에 모든 STA이 다른 AP MLD의 AP로 넘어가기 보다는 일부 STA만 AP로 먼저 Roaming하는 경우이다. 예를 들어, STA 1이 먼저 AP 1에서 AP 3로 Roaming하고 다음으로 STA 2가 AP 3에서 AP 5로 Roaming한다. 본 예시에서는 non-AP MLD에서는 2개의 STA이 있지만, 3개의 STA이 있는 경우에도 2개의 STA만 먼저 Roaming하고 나머지 STA이 다음 Roaming할 수 있다.
본 예시에서는 위에서 제시한 STA 1과 AP 1은 먼저 MLD Roaming Request/Response를 exchange할 수 있다. STA 1은 MLD Roaming Request에서 AP 4에 대한 (Optional)UHR AP MLD ID, AP MLD ID와 Link ID를 지시할 것이고, AP 1은 이에 대한 accept여부와 함께 AP 4에 대한 정보를 Basic Multi-link IE에 포함하여 줄 것이다. 다음으로, STA 2와 AP 3도 AP 5에 대해 동일한 절차를 거친다. 이 때, STA 2 대신 STA 1이 연결된 AP 4에게 해당 절차를 수행할 수도 있다.
이 예시를 활용하면 Data를 수신하는 데에 효과적일 수 있다. AP 1과 STA 1이 Roaming 절차를 거치는 동안 AP 2와 STA 3가 data를 exchange할 수 있으며, AP 3와 STA 2가 Roaming 절차를 거치는 동안 AP 4와 STA 1이 data를 exchange할 수 있다. 이 때, 각 data를 exchange하는 link들에는 모든 TID가 mapping되어 있을 필요가 있다. 하지만, 본 예시는 MLD가 아닌 STA 또는 MLD에 하나의 STA이 있을 경우에는 적용하기 어렵고, 상대적으로 frame exchange overhead가 발생할 수 있다.
도 49는 MLD Roaming 절차에 대한 예시 1의 동작 과정을 나타낸다.
도 49를 참조하면, AP의 송수신 과정은 다음과 같다.
AP 1은 STA 1로부터 Roaming Request frame을 수신한다. STA은 roaming하고 싶은 AP의 ID를 Link ID, AP MLD ID, UHR AP MLD ID(optional)를 통해 확인한다. AP 1은 STA 1에게 accept 여부와 AP 4와 5에 대한 2.4.2. Roaming Response frame format에 서술된 정보들을 MLD Roaming Response frame을 통해 전송한다.
도 49를 참조하면, STA의 송수신 과정은 다음과 같다.
STA 1은 AP 1에게 AP 4와 5에 대한 MLD Roaming Request frame을 전송한다. STA 1은 AP 1에게서 MLD Roaming Response frame 수신을 통해 roaming accept를 받으면 받은 AP 4에 대한 정보를 기반으로 AP 4로 roaming한다. STA 1의 roaming이 끝나면 STA 2도 STA 1을 통해 받은 AP 5에 대한 accept 여부와 AP 4와 5에 대한 정보를 기반으로 AP 4로 roaming한다.
2) 예시 #2 - 한 번에 모든 STA이 다른 Group의 AP로 넘어가는 경우
도 50은 MLD Roaming 절차에 대한 예시 2를 도시한다.
도 50은 한 번에 모든 STA이 다른 Group의 AP로 넘어가는 경우이다. 예를 들어, STA 1은 AP 1에서 AP 3로 STA 2는 AP 3에서 AP 5로 한 번에 Roaming한다.
본 예시에서는 위에서 제시한 STA 1과 AP 1 또는 STA 2와 AP 3가 MLD Roaming Request/Response를 exchange할 수 있다. 이 때 MLD Roaming Request에서 AP 4와 AP 5에 대한 UHR AP MLD ID(Optional), AP MLD ID와 Link ID를 지시할 것이고, AP 1 또는 AP 3는 이에 대한 accept여부와 함께 AP 4와 AP 5에 대한 정보를 Basic Multi-link IE에 포함하여 줄 것이다.
이 예시를 활용하면 예시 1에 비해 frame overhead를 줄일 수 있고 AP MLD Roaming domain 구조에 따라 data 지연 현상을 감소할 수 있다. 예를 들어, AP MLD에서 DS로부터 data 수신과 MLD Roaming을 관장하는 Anchor AP가 존재한다면 이 Anchor AP가 MLD Roaming Request에 accept한다면 미리 data path를 Roaming에 설정할 수 있다.
도 51은 MLD Roaming 절차에 대한 예시 2의 동작 과정을 나타낸다.
도 51을 참조하면, AP의 송수신 과정은 다음과 같다.
AP 1은 STA 1로부터 Roaming Request frame을 수신한다. STA은 roaming하고 싶은 AP의 ID를 Link ID, AP MLD ID, UHR AP MLD ID(optional)를 통해 확인한다. AP 1은 STA 1에게 accept 여부와 AP 4와 5에 대한 2.4.2. Roaming Response frame format에 서술된 정보들을 MLD Roaming Response frame을 통해 전송한다.
도 51을 참조하면, STA의 송수신 과정은 다음과 같다.
STA 1은 AP 1에게 AP 4와 5에 대한 MLD Roaming Request frame을 전송한다. STA 1은 AP 1에게서 MLD Roaming Response frame 수신을 통해 roaming accept를 받으면 받은 AP 4에 대한 정보를 기반으로 AP 4로 roaming한다. STA 1의 roaming이 끝나면 STA 2도 STA 1을 통해 받은 AP 5에 대한 accept 여부와 AP 4와 5에 대한 정보를 기반으로 AP 4로 roaming한다.
3) 예시 #3 - temporary add와 delete를 각각 수행하는 절차 (Timer를 활용한다면 동시에 이 절차를 수행할 수 있음)
도 52는 MLD Roaming 절차에 대한 예시 3을 도시한다.
도 52는 먼저 STA 1이 AP 4를 그리고 STA 2가 AP 5를 Temporary add하고 다음으로 각각 AP 1과 AP 3를 Delete하는 예시이다.
본 예시에서는 위에서 제시한 Temporary add를 위해 먼저 STA 1과 AP 1 또는 STA 2와 AP 3가 MLD Roaming Request/Response를 exchange할 수 있다. 이 때 MLD Roaming Request에서 AP 4와 AP 5에 대한 UHR AP MLD ID(Optional), AP MLD ID와 Link ID를 지시할 것이고, AP 1 또는 AP 3는 이에 대한 accept여부와 함께 AP 4와 AP 5에 대한 정보를 Basic Multi-link IE에 포함하여 줄 것이다. 이 과정이 완료되면 STA 1은 일시적으로 AP 1과 AP 4, STA 2는 AP 3와 AP 5와 연결되어 있을 것이다. STA 1은 AP 1과 AP 4로부터 data를 송신 또는 수신할 수 있다. 즉, AP 1과 frame exchange할 때는 AP 4와는 frame exchange를 할 수 없다. 다음으로 STA 1은 AP 1을 STA 2와 AP 3을 Temporary delete (or delete) operation을 수행한다. 이 절차를 통해 STA 1은 AP 4, STA 2는 AP 5로 roaming이 완료된다.
위 예시는 temporary add와 delete를 각각 수행하는 절차이다. 여기서 Timer를 활용한다면 동시에 이 절차를 수행할 수 있다. 예를 들어, STA 1과 AP 1 또는 STA 2와 AP 3가 MLD Roaming Request/Response를 exchange할 수 있다. 이 때, MLD Roaming Request에서 AP 1과 AP 3에 대해서는 Delete (or Temporary Delete), AP 4와 AP 5는 Temporary add를 동시에 요청한다. 이 때, 위에서 제시한 MLD Roaming Timer를 설정한다. 이는 위에서 언급한 것처럼 non-AP MLD 또는 AP MLD가 MLD Roaming Response를 통해 설정할 수 있다. MLD Roaming Response가 성공적으로 전송된 이후 Timer가 동작하고, Timer가 만료되면 STA 1으로부터 AP 1 link라 delete되고, AP 4와 완전히 연결되고, STA 2로부터 AP 3가 delete되고, AP 5와 완전히 연결된다.
도 53은 MLD Roaming 절차에 대한 예시 3의 동작 과정을 나타낸다.
도 53을 참조하면, AP의 송수신 과정은 다음과 같다.
AP 1은 STA 1로부터 Roaming Request frame을 수신한다. STA은 roaming하고 싶은 AP의 ID를 Link ID, AP MLD ID, UHR AP MLD ID(optional)를 통해 확인한다. AP 1은 STA 1에게 accept 여부와 AP 4와 5에 대한 2.4.2. Roaming Response frame format에 서술된 정보들을 MLD Roaming Response frame을 통해 전송한다. AP 1은 MLD Roaming Timer를 설정한다. 이때, MLD Roaming Timer가 timeout 시 기존 연결은 완전히 delete되고 roaming한 AP에서 완전히 연결된다.
도 53을 참조하면, STA의 송수신 과정은 다음과 같다.
STA 1은 AP 1에게 AP 4와 5에 대한 MLD Roaming Request frame을 전송한다. STA 1은 AP 1에게서 MLD Roaming Response frame 수신을 통해 roaming accept를 받으면 받은 AP 4에 대한 정보를 기반으로 AP 4로 roaming한다. STA 1의 roaming이 끝나면 STA 2도 STA 1을 통해 받은 AP 5에 대한 accept 여부와 AP 4와 5에 대한 정보를 기반으로 AP 4로 roaming한다. STA 1은 MLD Roaming Timer를 설정한다. 이때, MLD Roaming Timer가 timeout 시 기존 연결은 완전히 delete되고 roaming한 AP에서 완전히 연결된다.
4) 예시 #4 내지 #6 - delete 후 add 또는 add 후 delete하는 절차
도 54는 MLD Roaming 절차에 대한 예시 4를 도시한다.
도 51은 먼저 STA 1이 AP 1을 그리고 STA 2가 AP 3를 delete(or temporary delete)하고 다음으로 각각 AP 4과 AP 5를 add(or temporary add)하는 예시이다.
본 예시에서는 위에서 제시한 delete를 위해 먼저 STA 1과 AP 1 또는 STA 2와 AP 3가 MLD Roaming Request/Response를 exchange할 수 있다. 이때, MLD Roaming Request에서 AP 4와 AP 5에 대한 (Optional) UHR AP MLD, AP MLD ID와 Link ID를 지시할 것이고, AP 1 또는 AP 3는 이에 대한 accept여부와 함께 AP 4와 AP 5에 대한 정보를 Basic Multi-link IE에 포함하여 줄 것이다. 이 과정이 완료된 후 STA 1 또는 STA 2는 AP 1과 AP 3과의 연결을 끊을 수 있다. 한쪽 링크가 delete 된 상황에서도 link delete을 한 AP로부터 data가 올 경우에는 아직 delete하지 않은 STA이 대신 받거나 UHR AP MLD가 roaming할 AP로 보내어 roaming 이후에 보낼 수 있다. 다음으로 STA 1은 AP 4에 대해 add 동작을 수행하고, STA 2은 AP 5에 대해 add 동작을 수행한다. 이 절차를 통해 STA 1은 AP 4로, STA 2는 AP 5로 roaming이 완료된다.
위 예시는 temporary add와 delete를 각각 수행하는 절차이다. 여기서 Timer를 활용한다면 동시에 이 절차를 수행할 수 있다. 예를 들어, STA 1과 AP 1 또는 STA 2와 AP 3가 MLD Roaming Request/Response를 exchange할 수 있다. 이 때, MLD Roaming Request에서 AP 1과 AP 3에 대해서는 Delete(or Temporary Delete), AP 4와 AP 5는 add(or Temporary add)를 동시에 요청할 수도 있고 개별적으로 전송할 수도 있다. 이때, 위에서 제시한 MLD Roaming Timer를 설정한다. 이는 위에서 언급한 것처럼, non-AP MLD 또는 AP MLD가 MLD Roaming Response를 통해 설정할 수 있다. MLD Roaming Response가 성공적으로 전송된 이후 Timer가 동작하고, Timer가 만료되면 STA 1으로부터 AP 1 link가 delete되고, AP 4와 완전히 연결되고, STA 2로부터 AP 3가 delete되고, AP 5와 완전히 연결된다.
도 55는 MLD Roaming 절차에 대한 예시 3과 4의 동작 과정을 나타낸다.
도 55를 참조하면, AP의 송수신 과정은 다음과 같다.
AP 1은 STA 1로부터 Roaming Request frame을 수신한다. STA 1과 2는 roaming하고 싶은 AP(AP 4, 5)의 ID를 Link ID, AP MLD ID, UHR AP MLD ID(optional)를 통해 확인한다. AP 1은 STA 1에게 accept 여부와 AP 4와 5에 대한 2.3.2. Roaming Response frame format에 서술된 정보들을 MLD Roaming Response frame을 통해 전송한다. AP 1은 MLD Roaming Timer를 설정한다. 이때, MLD Roaming Timer가 timeout 시 기존 연결은 완전히 delete되고 roaming한 AP에서 완전히 연결된다.
도 55를 참조하면, STA의 송수신 과정은 다음과 같다.
STA 1은 AP 1에게 AP 4와 5에 대한 MLD Roaming Request frame을 전송한다. 이때, STA1은 AP 1과 AP 2에 대해서는 Delete(or Temporary Delete)를 요청하고, AP4와 AP5에 대해서는 Temporary add를 요청한다. STA 1은 AP 1에게서 MLD Roaming Response frame 수신을 통해 AP 4와 5의 roaming accept 여부와 AP들에 대한 정보(2.3.1 참고)를 수신한다. STA 1은 MLD Roaming Timer를 설정한다. 이때, MLD Roaming Timer가 timeout 시 기존 연결은 완전히 delete되고 roaming한 AP에서 완전히 연결된다.
도 56은 MLD Roaming 절차에 대한 예시 5를 도시한다.
도 57은 MLD Roaming 절차에 대한 예시 6을 도시한다.
도 56 및 도 57은 link add와 delete의 요청을 동시에 보낼 때 MLD Request frame의 Type field를 설정하는 방법의 실시예이다. 도 56은 non-AP MLD가 새로운 AP MLD(AP MLD 2)로 로밍을 하기 위해 먼저 link add를 요청 후 STA 1과 AP 4 간의 연결이 생성된 후 기존에 STA 1과 연결되어 있던 AP 1과의 연결을 delete 요청을 한다. Add와 Delete을 요청할 때 Link ID와 AP MLD ID를 사용하여 자신이 요청을 보내는 AP에게 요청할 수 있다. Delete 요청을 보내고 STA 1과 AP 1과의 연결이 완전히 delete되면 STA 1은 AP MLD 1와의 data 송수신이 불가능하지만 non-AP MLD의 STA 2는 AP MLD 1의 AP 3와 연결이 되어있기 때문에 non-AP MLD와 AP MLD 1는 data 송수신이 가능하다. 따라서 Roaming하는 과정에서 data discontinuity를 줄일 수 있다. STA 1의 link 변경이 완료된 후 STA 2도 동일하게 AP 5로 link add를 요청한 후 AP 3와의 연결을 끊어 새로운 AP MLD 2로 완전히 roaming할 수 있다. 이 때 AP MLD 1과 AP MLD 2는 같은 AP MLD for a seamless roaming에 affiliate되어있기 때문에 AP MLD 1의 queue에 쌓여 있던 data를 AP MLD 2로 넘겨줄 수 있다. 도 57은 도 56과 전체적인 roaming procedure은 같지만 link를 먼저 delete한 후 AP MLD 2와의 link를 add 한다.
Link를 add하고 delete할 때는 MLD Roaming Request frame에 하나씩 요청하여 두 번을 요청할 수 있거나 두가지 동작을 한 frame에 동시에 요청할 수도 있다. 동시에 요청할 경우에 도 56의 경우 2.4.1 MLD Roaming Request frame format의 3-1) Add와 delete 요청을 동시에 보내는 경우의 실시예 - 새로운 링크를 먼저 add하고 기존 링크를 delete하고 싶은 경우 방식으로 MLD Roaming Request frame을 구성하고 도 57의 경우 2.4.1 MLD Roaming Request frame format의 3-2) Add와 delete 요청을 동시에 보내는 경우의 실시예 - 기존 링크를 먼저 delete하고 새로운 링크를 add하고 싶은 경우 방식으로 MLD Roaming Request frame을 구성할 수 있다. 즉, Link Info field은 2개의 Per-STA Profile(하나의 Per-STA Profile은 add를 위해, 다른 하나의 Per-STA Profile은 delete을 위해)로 구성될 수 있다. Add와 Delete을 개별적으로 요청하는 경우에는 먼저 add/delete요청을 보내는 MLD Roaming Request frame의 구성을 2.3.1 MLD Roaming Request frame format의 1) MLD Roaming Request frame body 또는 Reconfiguration IE의 Common Info field에 포함되는 경우, 2-1) MLD Roaming Request frame body 또는 Reconfiguration IE의 Link Info field에 포함되는 경우, 2-2) MLD Roaming Request frame body 또는 Reconfiguration IE의 Link Info field에 포함되는 경우 같이 구성될 수 있다. 이후 요청에 대한 Response는 MLD Roaming Response frame으로 받고 Status Code를 통해 MLD Roaming Request frame의 accept/reject 여부를 알 수 있다.
또한, STA 1이 AP 1에서 AP 4로 완전히 넘어가기 위해서는 도 58 및 도 59와 같은 과정이 필요하다.
도 58은 TIM을 활용한 MLD Roaming의 일례를 나타낸다.
AP 1은 Beacon을 통해 STA 1에게 전송할 DL data가 있는지에 대한 여부를 TIM을 통해 알려주고 있다. 이 때 STA 1이 roaming을 수행을 위하여 AP 4를 추가하기 위해 STA 1은 MLD Roaming Request를 전송한다. 참고로 해당 예시는 STA 1만 포함되어 있지만, 도 44와 같이 STA 2에 대한 AP 5의 link addition도 같이 요청할 수 있다. AP 1은 이를 확인하고 AP 4에 대해 accept으로 Response한다. 하지만, STA 1은 현재 AP 1의 최근 Beacon으로부터 DL data를 buffer하고 있지 않다는 정보를 받았거나 buffer하고 있어도 아직 수신하지 못했을 수 있다. 따라서 AP 1은 STA 1이 AP 4 또는 UHR AP MLD가 해당 DL data를 가지고 있음을 알려줄 수 있다. 즉, AP 4로 switch 했을 때 Beacon을 수신할 때까지 기다리지 않고도 바로 STA 1은 AP 4에게 PS-poll 전송을 통해 DL data를 수신할 수 있다. 이를 위해서는 MLD Roaming Response frame에 추가적인 정보가 지시될 필요가 있으며, 해당 정보는 다음과 같다.
-> TIM(Traffic Indication Map) field (예를 들어, 1bit): 이는 해당 AP 또는 AP MLD 가 현재 요청한 STA에 대한 DL data를 buffer하고 있음을 지시한다.
MLD-level 관점에서 본다면, UHR AP MLD가 요청 STA에 대한 DL data를 buffer하고 있음을 알려준다면, 상기 TIM field는 MLD Roaming Response frame body나 Common Info field에 포함될 수 있다.
해당 AP 관점에서 본다면, 예를 들어 AP 4로 switch하기 전에 AP 4가 DL data를 가지고 있음을 알려준다면 상기 TIM field는 Link Info field에 포함될 수 있다.
한편, 추가적으로 STA(예를 들어, STA 1)은 MLD Roaming Response frame의 MLD Roaming Timer를 활용하여 Switch할 시간을 정할 수 있다. 예를 들어, 현재 자신이 switch하기 전에 roaming할 AP(e.g., AP 4)로부터 data를 받기까지 시간이 많이 남았다면 STA 1은 현재 연결된 AP(e.g., AP 1)로 PS-Poll(필요하다면)을 통해 DL data를 먼저 수신하고 switch할 수 있다. 또는 바로 switch해도 AP 4로부터 data를 수신할 수 있는 시간이라면 STA 1은 바로 switch할 수 있다.
도 59는 TIM을 활용한 MLD Roaming 절차에 대한 동작 과정을 나타낸다.
도 59를 참조하면, AP의 송수신 과정은 다음과 같다.
AP 1은 Beacon을 통해 STA 1에게 전송할 DL data가 있는지에 대한 여부를 TIM을 통해 알려준다. Roaming Request를 받은 AP 1은 AP 4(+AP 5)에 대해 accept로 response한다. AP 1은 DL data를 누가 가지고 있는지 알려준다. DL data를 갖고 있는 AP 또는 UHR AP MLD가 DL data를 STA 1(+STA 2)에게 전송한다. STA에게서 삭제 연결 요청을 받으면 AP 1(+AP 3)은 기존 연결을 삭제한다.
도 59를 참조하면, STA의 송수신 과정은 다음과 같다.
STA 1은 roaming을 수행하고 AP 4를 추가하기 위해 MLD Roaming Request를 전송한다. 이때, STA 2에 대한 AP 5의 링크 추가도 같이 요청할 수 있다. STA 1은 DL data에 대해 정보를 수신한다. STA 1(+STA 2)는 AP 4(+AP 5)로 roaming을 수행한다. STA 1(+STA 2)는 AP 4(+AP 5)에게 PS-Poll을 전송하고 이에 따른 DL data를 수신한다. STA 1(+STA 2)는 AP 1(+AP 3)에게 링크 삭제를 요청한다.
2.6. Context Transfer Level
Non-AP STA이 새로운 AP MLD로 roaming할 때 packet loss 같은 현상으로 인해 data discontinuity 현상을 막기 위해 후술하는 도 70에 나온 예시처럼 context transfer를 이용해 이전에 연결되어 있던 AP MLD에서 필요한 정보들을 non-AP STA가 roaming을 하기 이전에 새로운 AP MLD에게 사전적으로 전송을 해줄 수 있다. 이때, non-AP STA는 roaming을 요청하고 나서 context transfer가 이뤄지는 시간 동안 기다리고 roaming을 수행하는데 context transfer 해주는 정보량이 많아질수록 context transfer로 인해 발생하는 delay는 커진다. 여기서는, Context transfer가 필요 없는 상황에서는 불필요한 context transfer로 인해 야기되는 delay 현상을 피하기 위해 필요한 정보들만 transfer해줄 수 있는 Context Transfer Level이라는 개념을 정의한다. Context Transfer Level은 Roaming Request를 할 때 non-AP STA가 Context Transfer Level을 지정해줄 수 있고 또는 Serving AP MLD가 지정해서 non-AP STA에게 이를 알려줄 수 있다. Non-AP MLD STA가 Context Transfer Level을 알 필요가 없는 경우에는 non-AP MLD STA에게 Context Transfer Level을 알려주지 않을 수도 있다.
Context Transfer Level은 적어도 다음 하나 이상의 방법으로 설정될 수 있다.
1) Accumulation 방식
Context Transfer Level = 0: A라는 Context를 transfer
Context Transfer Level = 1: A + B라는 Context들을 transfer
…
위와 같이, 이전 Context Transfer Level에 transfer되는 context들과 새로운 context를 포함하는 방식이다.
Transfer되는 A, B 등의 context의 예는 다음과 같을 수 있다.
A = SN(Sequence Number)
B = PN(Packet Number)
C = BA agreement
D = BA parameters
…
위의 예는 하나의 예시일 뿐, 해당 예시에 국한되지 않는다. 또한 언급된 예시보다 더 많은 종류이 context들이 정의될 수 있다.
2) Independent 방식
Context Transfer Level = 0: Context A
Context Transfer Level = 1: Context B
…
Independent 방식은 Context Transfer Level을 하나만 선택하여 하나의 Context만 보낼 수도 있고 여러 개의 Context Transfer Level을 선택하여 여러 개의 Context들을 transfer할 수 있다.
만약 Context Transfer Level 1을 선택한다면 Context B만 transfer하고 Context Transfer Level 0, 1을 선택한다면 Context A, B 둘 다 transfer해준다.
Context A 와 B의 예시는 1) Accumulation 방식에서 든 예시와 같을 수 있다.
3) Bitmap
1)과 2)의 방식에 대한 대안으로 Bitmap으로 Context Transfer에 대한 level을 설정할 수 있다.
예를 들어, 상기 Bitmap이 X bit이면 B0은 Context A, B1은 Context B와 같이 설정할 수도 있다.
또한 2) Independent 방식과 같이 여러 bit를 조합하여 한 종류의 context만이 아닌 여러 종류의 context를 transfer하게 설정할 수 있다.
또 다른 예로, 비트의 값에 따른 Context의 정보를 다음과 같이 설정해줄 수도 있다.
Context Transfer Level Context Transferred
0 No Context transfer
1 SN/PN
2 BA Agreement
3 Packet Reordering
4-15 Reserved
예를 들어, 만약 context transfer 없이 entity 또는 UHR MLD만으로 Roaming이 가능하다면 Context Transfer Level을 0으로 설정한다. Context Transfer로 SN/PN 정보만 전해주면 된다면 Context Transfer Level을 1로 설정한다. Context Transfer Level의 값이 포함하는 context는 accumulation되는 방식을 사용할 수 있다. 만약 Context Transfer Level을 3으로 설정했다면 1과 2의 값을 가지는 Context Transferred 항목들이 포함된다. Accumulation 방식은 여러 방법 중 하나이며 상기 방법으로만 국한되지 않는다.
<Context transfer를 이용한 Roaming Procedure>
도 60은 Context transfer를 이용한 Roaming Procedure의 일례(Entity만 존재)를 도시한다.
도 60은 Context transfer가 있는 경우에 Roaming 과정에 대한 예시이다. Roaming Request를 non-AP MLD가 보내는 경우 도 61과 같은 과정을 갖는다. 먼저, Non-AP STA는 Roaming을 하기 위해 Roaming을 하려는 AP의 ID 정보들을 Roaming Request frame을 통하여 UHR AP MLD 또는 AP MLD에게 전송한다. 또한, Roaming Request frame의 Context Transfer Level field를 사용하여 transfer할 context들을 정해줄 수 있다. Roaming Request frame을 받은 UHR AP MLD 또는 AP MLD는 요청된 AP로 Roaming이 가능한지에 대한 여부와 Context Transfer Level을 Roaming Response frame의 전송을 통해 알려준다. Non-AP MLD 에게서 Roaming Request frame을 받으면, UHR AP MLD 또는 AP MLD는 Context Transfer Level에 설정된 transfer해야 할 control context들을 Roaming할 AP MLD에게 DS를 통해 전송한다. 만약, Context Transfer Level이 0으로 설정된다면 Context transfer는 하지 않는다. Context transfer가 완료되면 AP MLD는 non-AP MLD에게 link add를 요청하고 roaming하려는 AP MLD와 non-AP MLD 사이에 link가 형성되면 DL(downlink)의 경우에는 roaming 이전의 AP MLD에게 context transfer로 수신된 SN/PN 정보에 따라 queue에 쌓여 있었으나 roaming으로 전송되지 못한 packet들을 roaming 이후의 AP MLD가 non-AP STA에게 전송한다. 이후, DS로부터 수신된 새로운 packet들은 roaming 이후의 AP MLD를 통해서 받는다. UL의 경우, non-AP STA는 roaming 이후의 AP MLD에게 packet을 전송한다. AP MLD는 roaming 이전의 AP MLD와 non-AP STA과 연결되어 있는 모든 link들에 대한 link delete을 요청하고 모든 link들의 삭제가 완료되면 roaming 과정은 끝이 난다.
도 62는 AP MLD가 Roaming Request를 보내는 경우에 대한 과정 예시이다. AP MLD가 Roaming Request를 보내는 경우에는 Context Transfer Level을 통하여 AP MLD가 Context transfer할 수 있는 정도에 대한 capability 정보를 알려줄 수 있다. 이런 경우에는 non-AP STA가 Roaming Response를 보낼 때 Context Transfer Level 값을 Roaming Request의 Context Transfer Level 값 이하의 값으로 설정한다.
도 61은 Context transfer를 이용한 로밍 과정의 일례를 도시한다.
도 61은 non-AP MLD가 Roaming Request를 보내는 경우에 대한 과정 예시이다.
도 61을 참조하면, AP MLD 송수신 과정은 다음과 같다.
AP MLD는 Non-AP MLD로부터 Roaming Request frame을 수신한다. AP MLD는 Non-AP MLD가 roaming하려는 Target AP MLD에게 기존 AP MLD(Serving AP MLD)에 대한 정보 및 필요한 context를 전달한다. Context transfer가 완료되면, UHR AP MLD(또는 entity)가 non-AP MLD에게 link add를 요청한다. 새로운 link가 형성된 후, Target AP MLD는 DL 환경에서는 Context transfer로 받은 SN(Sequence Number)/PN(Packet Number) 정보를 통하여 기존 AP MLD queue에 쌓여있던 packet들을 전송한다. UL 환경에서는 Target AP MLD는 새로운 link로만 frame을 수신한다. Target AP MLD는 기존 AP MLD와 연결되어 있는 link에 대해 link delete를 요청한다.
도 61을 참조하면, Non-AP MLD 송수신 과정은 다음과 같다.
Non-AP MLD는 UHR AP MLD(또는 Serving AP MLD)에게 Roaming Request frame을 전송한다. Non-AP MLD는 Roaming Response frame의 수신을 통해 roaming accept 여부와 AP들에 대한 정보를 수신한다. Non-AP MLD는 link add 요청을 받으면 새로운 AP MLD(Target AP MLD)와 연결된 link로 frame을 송수신한다. Non-AP MLD는 link delete 요청을 받으면 기존 AP MLD(Serving AP MLD)와 연결된 link를 삭제한다.
도 62는 Context transfer를 이용한 로밍 과정의 다른 예를 도시한다.
도 62는 AP MLD가 Roaming Request를 보내는 경우에 대한 과정 예시이다.
도 62를 참조하면, AP MLD 송수신 과정은 다음과 같다.
AP MLD는 Non-AP MLD에게 Roaming Request frame을 송신한다. AP MLD는 Non-AP MLD가 roaming하려는 Target AP MLD에게 기존 AP MLD(Serving AP MLD)에 대한 정보 및 필요한 context를 전달한다. Context transfer가 완료되면, UHR AP MLD(또는 entity)가 non-AP MLD에게 link add를 요청한다. 새로운 link가 형성된 후, Target AP MLD는 DL 환경에서는 Context transfer로 받은 SN(Sequence Number)/PN(Packet Number) 정보를 통하여 기존 AP MLD queue에 쌓여있던 packet들을 전송한다. UL 환경에서는 Target AP MLD는 새로운 link로만 frame을 수신한다. Target AP MLD는 기존 AP MLD와 연결되어 있는 link에 대해 link delete를 요청한다.
도 62를 참조하면, Non-AP MLD 송수신 과정은 다음과 같다.
Non-AP MLD는 UHR AP MLD(또는 Serving AP MLD)로부터 Roaming Request frame을 수신한다. Non-AP MLD는 Roaming Response frame의 수신을 통해 roaming accept 여부와 AP들에 대한 정보를 수신한다. Non-AP MLD는 link add 요청을 받으면 새로운 AP MLD(Target AP MLD)와 연결된 link로 frame을 송수신한다. Non-AP MLD는 link delete 요청을 받으면 기존 AP MLD(Serving AP MLD)와 연결된 link를 삭제한다.
도 63은 Serving AP MLD의 queue에 쌓여있는 DL Data를 송신하는 일례를 도시한다.
도 63과 같이 Roaming Response frame 내 Queued packet 필드가 1로 설정되어 있고 추가적인 정보들(DL data size, Number of pending MSDUs, SN 또는 PN 관련 정보, TIDs for pending MSDU)이 함께 제공된다면, Roaming Response frame 전송 이후에 Serving AP MLD의 queue에 남아있는 DL Data들을 non-AP MLD STA에게 전송한다. 이때, DL data size나 Number of pending MSDUs 등을 통해 DL data의 양을 측정하여 DL Data의 전송의 끝이 어디인지 알 수 있거나 Last SN/PN의 정보 또는 마지막 DL data에 last DL data bit을 이용하여 마지막 DL data의 부분을 알려줄 수 있다.
도 64는 Serving AP MLD의 queue에 쌓여있는 DL Data의 송신 완료를 DL Timer로 알려주는 절차를 도시한다.
도 64를 참조하면, non-AP MLD STA은 Roaming Response을 통해 전달되는 MSDU DL data size나 Number of pending MSDUs 등을 통해 DL Data를 전송하기 위해 필요한 시간을 계산 후 DL Timer를 설정하여 어느 시점에 DL Data의 송신이 끝나는지 알 수 있다.
추가적으로 non-AP MLD STA이 Roaming Response를 받았는데 Queued packet 필드가 1이고 non-AP STA가 어느 시점에 Serving AP MLD의 queue되어있는 packet들이 전송이 완료되는지 알 수 없을 수 있다. 이때, Serving AP MLD는 queue에 쌓여있는 packet이 없어진 시점에 Roaming Response의 Queued Packets field의 값을 0으로 설정하여 다시 보내줌으로 non-AP MLD는 Serving AP MLD에서 Target AP MLD로 전이되는(또는 넘어가는) 시점을 알 수 있다.
<MLD Roaming Examples>
Roaming 절차의 Baseline은 다음과 같이 정의될 수 있다.
도 65는 Roaming Procedure의 Baseline의 일례를 도시한다.
도 65는 Seamless Roaming의 가장 기본적인 procedure이다.
Roaming Request를 non-AP MLD 또는 AP MLD가 전송하고 Target AP MLD와 Non-AP MLD 사이에 link가 established되면 Roaming Response를 통해 link establishment에 대한 success/fail 여부에 대한 정보를 roaming response를 통해 알려줄 수 있다. Roaming Request와 Roaming Response는 non-AP MLD 또는 AP MLD가 전송할 수 있으며 Serving AP MLD와 Target AP MLD는 backhaul 로 연결되어 있기 때문에 Roaming Request/Response에 관한 내용을 서로 공유한다.
도 66은 Roaming Procedure의 Baseline #1의 일례를 도시한다.
도 66은 Non-AP MLD가 Roaming Request 보내는 경우와 Non-AP MLD가 Roaming Response 보내는 경우에 대한 예시이다.
도 66을 참조하면, AP MLD 송수신 과정은 다음과 같다.
AP MLD는 Roaming Request frame을 수신한다. Target AP MLD와 non-AP MLD 간에 링크가 established되면 AP MLD는 non-AP MLD로부터 Roaming Response frame을 수신한다.
도 66을 참조하면, Non-AP MLD 송수신 과정은 다음과 같다.
Non-AP MLD는 AP MLD에게 Roaming Request frame을 송신한다. Target AP MLD와 non-AP MLD 간에 링크가 established되면 non-AP MLD는 AP MLD에게 Roaming Response frame을 송신한다.
도 67은 Roaming Procedure의 Baseline #2의 일례를 도시한다.
도 67은 AP MLD가 Roaming Request 보내는 경우와 Non-AP MLD가 Roaming Response 보내는 경우에 대한 예시이다.
도 67을 참조하면, AP MLD 송수신 과정은 다음과 같다.
AP MLD는 Roaming Request frame을 송신한다. Target AP MLD와 non-AP MLD 간에 링크가 established되면 AP MLD는 non-AP MLD로부터 Roaming Response frame을 수신한다.
도 67을 참조하면, Non-AP MLD 송수신 과정은 다음과 같다.
Non-AP MLD는 AP MLD로부터 Roaming Request frame을 수신한다. Target AP MLD와 non-AP MLD 간에 링크가 established되면 non-AP MLD는 AP MLD에게 Roaming Response frame을 송신한다.
도 68은 Roaming Procedure의 Baseline #3의 일례를 도시한다.
도 68은 non-AP MLD가 Roaming Request 보내는 경우와 AP MLD가 Roaming Response 보내는 경우에 대한 예시이다.
도 68을 참조하면, AP MLD 송수신 과정은 다음과 같다.
AP MLD는 Roaming Request frame을 수신한다. Target AP MLD와 non-AP MLD 간에 링크가 established되면 AP MLD는 non-AP MLD에게 Roaming Response frame을 송신한다.
도 68을 참조하면, Non-AP MLD 송수신 과정은 다음과 같다.
Non-AP MLD는 AP MLD에게 Roaming Request frame을 송신한다. Target AP MLD와 non-AP MLD 간에 링크가 established되면 non-AP MLD는 AP MLD로부터 Roaming Response frame을 수신한다.
도 69는 Roaming Procedure의 Baseline #4의 일례를 도시한다.
도 69는 AP MLD가 Roaming Request 보내는 경우와 AP MLD가 Roaming Response 보내는 경우에 대한 예시이다.
도 69를 참조하면, AP MLD 송수신 과정은 다음과 같다.
AP MLD는 Roaming Request frame을 송신한다. Target AP MLD와 non-AP MLD 간에 링크가 established되면 AP MLD는 non-AP MLD에게 Roaming Response frame을 송신한다.
도 69를 참조하면, Non-AP MLD 송수신 과정은 다음과 같다.
Non-AP MLD는 AP MLD로부터 Roaming Request frame을 수신한다. Target AP MLD와 non-AP MLD 간에 링크가 established되면 non-AP MLD는 AP MLD로부터 Roaming Response frame을 수신한다.
Serving AP MLD에 queue에 쌓여있는 packet들이 남아있는 경우 동작 예시 과정은 다음과 같다.
도 70은 Target AP MLD와의 link establishment의 순서를 설명하는 일례를 도시한다.
도 70은 Serving AP MLD의 queue에 쌓여있는 data들을 전송하기 이전에 target AP MLD와의 link를 establish하는 경우를 설명한다. 즉, 도 70은 Roaming Response를 받고 Serving AP MLD에 DL Data packet들이 queue에 남아있을 경우에는 non-AP MLD STA에게 DL Data들을 보내주는 예시이다.
도 71은 본 실시예에 따른 송신 장치의 동작을 나타낸 절차 흐름도이다.
도 71의 일례는 송신 STA 또는 송신 장치(AP 및/또는 non-AP STA)에서 수행될 수 있다.
도 71의 일례의 각 step (또는 후술하는 세부적인 sub-step) 중 일부는 생략되거나 변경될 수 있다.
S7110 단계를 통해, 송신 장치(송신 STA)는 상술한 Tone Plan에 관한 정보를 획득(obtain)할 수 있다. 상술한 바와 같이 Tone Plan에 관한 정보는 RU의 크기, 위치, RU에 관련된 제어정보, RU가 포함되는 주파수 대역에 관한 정보, RU를 수신하는 STA에 관한 정보 등을 포함한다.
S7120 단계를 통해, 송신 장치는 획득한 제어 정보를 기초로 PPDU를 구성/생성할 수 있다. PPDU를 구성/생성하는 단계는 PPDU의 각 필드를 구성/생성하는 단계를 포함할 수 있다. 즉, S7120 단계는 Tone Plan에 관한 제어정보를 포함하는 EHT-SIG 필드를 구성하는 단계를 포함한다. 즉, S7120 단계는 RU의 크기/위치를 지시하는 제어정보(예를 들어, N 비트맵)을 포함하는 필드를 구성하는 단계 및/또는 RU를 수신하는 STA의 식별자(예를 들어, AID)를 포함하는 필드를 구성하는 단계를 포함할 수 있다.
또한, S7120 단계는 특정 RU를 통해 송신되는 STF/LTF 시퀀스를 생성하는 단계를 포함할 수 있다. STF/LTF 시퀀스는 기 설정된 STF 생성 시퀀스/LTF 생성 시퀀스를 기초로 생성될 수 있다.
또한, S7120 단계는 특정 RU를 통해 송신되는 데이터 필드(즉, MPDU)를 생성하는 단계를 포함할 수 있다.
송신 장치는 S7120 단계를 통해 구성된 PPDU를 S6330 단계를 기초로 수신 장치로 송신할 수 있다.
S7130 단계를 수행하는 동안, 송신 장치는 CSD, Spatial Mapping, IDFT/IFFT 동작, GI 삽입(insert) 등의 동작 중 적어도 하나를 수행될 수 있다.
본 명세서에 따라 구성된 신호/필드/시퀀스는 도 5의 형태로 송신될 수 있다.
도 72는 본 실시예에 따른 수신 장치의 동작을 나타낸 절차 흐름도이다.
상술한 PPDU는 도 72의 일례에 따른 수신될 수 있다.
도 72의 일례는 수신 STA 또는 수신 장치(AP 및/또는 non-AP STA)에서 수행될 수 있다.
도 72의 일례의 각 step (또는 후술하는 세부적인 sub-step) 중 일부는 생략될 수 있다.
수신 장치(수신 STA)는 S7210 단계를 통해 PPDU의 전부 또는 일부를 수신할 수 있다. 수신된 신호는 도 5의 형태일 수 있다.
S7210 단계의 sub-step은 도 71의 S7130 단계를 기초로 결정될 수 있다. 즉 S7210 단계는 S7130 단계에서 적용된, CSD, Spatial Mapping, IDFT/IFFT 동작, GI 삽입(insert) 동작의 결과를 복원하는 동작을 수행할 수 있다.
S7220 단계에서, 수신 장치는 PPDU의 전부/일부에 대한 디코딩을 수행할 수 있다. 또한 수신 장치는 디코딩된 PPDU로부터 Tone Plan(즉, RU)에 관련된 제어정보를 획득할 수 있다.
보다 구체적으로 수신 장치는 Legacy STF/LTF를 기초로 PPDU의 L-SIG 및 EHT-SIG를 디코딩하고, L-SIG 및 EHT SIG 필드에 포함된 정보를 획득할 수 있다. 본 명세서에 기재된 다양한 Tone Plan(즉, RU)에 관한 정보는 EHT-SIG에 포함될 수 있고, 수신 STA은 EHT-SIG를 통해 Tone Plan(즉, RU)에 관한 정보를 획득할 수 있다.
S7230 단계에서, 수신 장치는 S7220 단계를 통해 획득한 Tone Plan(즉, RU)에 관한 정보를 기초로 PPDU의 나머지 부분을 디코딩 할 수 있다. 예를 들어, 수신 STA은 one Plan(즉, RU)에 관한 정보를 기초로 PPDU의 STF/LTF 필드를 디코딩할 수 있다. 또한, 수신 STA은 Tone Plan(즉, RU)에 관한 정보를 기초로 PPDU의 데이터 필드를 디코딩하고, 데이터 필드에 포함된 MPDU를 획득할 수 있다.
또한, 수신 장치는 S7230 단계를 통해 디코딩된 데이터를 상위 계층(예를 들어, MAC 계층)으로 전달하는 처리 동작을 수행할 수 있다. 또한, 상위 계층으로 전달된 데이터에 대응하여 상위 계층으로부터 PHY 계층으로 신호의 생성이 지시되는 경우, 후속 동작을 수행할 수 있다.
이하에서는, 도 1 내지 도 72를 참조하여, 상술한 실시예를 설명한다.
도 73은 본 실시예에 따른 MLD 로밍에서 Serving AP MLD의 큐에 있는 DL 데이터의 송신이 끝나는 시점에 대한 정보를 알려주는 절차를 도시한 흐름도이다.
도 73의 일례는 차세대 무선랜 시스템(UHR(Ultra High Reliability) 무선랜 시스템 또는 next wi-fi)이 지원되는 네트워크 환경에서 수행될 수 있다. 상기 차세대 무선랜 시스템은 802.11be 시스템을 개선한 무선랜 시스템으로 802.11be 시스템과 하위 호환성(backward compatibility)을 만족할 수 있다.
본 실시예는 MLD 로밍이 수행될 때 Serving AP MLD의 큐에 DL 데이터(또는 DL 패킷)가 남아 있는 경우, 상기 DL 데이터가 모두 송신되는 시점을 로밍 응답 프레임을 통해 알려주어 상기 Serving AP MLD에서 Target AP MLD로 전이되는 시점을 결정하는 방법을 제안한다.
S7310 단계에서, 상기 제1 AP MLD에 소속된 제1 AP는 non-AP MLD에 소속된 non-AP STA(station)로부터 로밍 요청 프레임(Roaming Request frame)을 수신한다.
S7320 단계에서, 상기 제1 AP는 상기 non-AP STA에게 로밍 응답 프레임(Roaming Response frame)을 송신한다.
상기 제1 AP MLD에서 제2 AP MLD로 전이(transition)할지 여부는 상기 로밍 응답 프레임을 기반으로 결정된다.
상기 로밍 응답 프레임은 상기 제1 AP MLD의 큐(queue)에 DL(downlink) 데이터가 남아있는지 여부에 대한 제1 정보 및 상기 제1 AP MLD로부터 송신되는 상기 DL 데이터에 대한 제2 정보를 포함한다.
상기 제1 정보가 1로 설정되는 것과 상기 제2 정보에 기초하여, 상기 DL 데이터의 송신이 끝나는 시점이 결정된다.
상기 제1 정보가 1로 설정되는 것에 기초하여, 상기 제1 AP MLD의 큐에 상기 DL 데이터가 남아있을 수 있다. 상기 제1 정보가 0으로 설정되는 것에 기초하여, 상기 제1 AP MLD의 큐에 상기 DL 데이터가 더 이상 없을 수 있다.
상기 제2 정보는 상기 DL 데이터의 크기, 아직 송신되지 않은 MSDU(MAC Service Data Unit)의 개수, SN(Sequence Number) 또는 PN(Packet Number)에 관한 정보, 및 펜딩(pending) 중인 MSDU를 식별하는 TID(Traffic IDentifiers)에 대한 정보를 포함할 수 있다. 상기 SN 또는 PN에 관한 정보는 상기 MSDU에서 마지막 MSDU의 SN 또는 PN일 수 있다. 상기 TID는 상기 펜딩 중이 MSDU의 개수를 크기로 하는 비트맵으로 설정될 수 있다.
즉, 상기 제1 정보가 1로 설정되어 상기 제1 AP MLD의 큐에 상기 DL 데이터가 남아있고, 상기 DL 데이터에 대한 정보를 기반으로 상기 non-AP STA은 상기 DL 데이터의 송신이 끝나는 시점을 알 수 있다. 이때, 상기 DL 데이터의 송신이 끝나는 시점을 기반으로, 상기 제1 AP MLD에서 상기 제2 AP MLD로 전이가 수행된다.
상기 제1 정보가 0으로 설정되어 상기 제1 AP MLD의 큐에 상기 DL 데이터가 남아 있지 않다면, 상기 non-AP STA은 상기 로밍 응답 프레임을 수신한 이후 바로 상기 제2 AP MLD와 DL 또는 UL(uplink) 송신을 시작할 수 있다.
상기 로밍 응답 프레임은 채널 스위치 카운트(channel switch count)에 대한 제3 정보를 더 포함할 수 있다. 상기 제3 정보는 상기 제1 AP MLD(또는 상기 제1 AP MLD에 소속된 제1 AP)에 연결된 제1 링크에서 상기 제2 AP MLD(또는 상기 제2 AP MLD에 소속된 제2 AP)에 연결된 제2 링크로 전이되는 시점에 대한 정보일 수 있다. 이때, 상기 제1 링크의 채널과 상기 제2 링크의 채널은 서로 다를 수 있다. 만약, 상기 제1 및 제2 링크의 채널이 서로 같다면, 상기 제3 정보 없이도 상기 non-AP STA은 상기 제1 링크에서 상기 제2 링크로 전이되는 시점을 알 수 있다.
상기 로밍 응답 프레임은 공통 정보 필드 및 링크 정보 필드를 포함할 수 있다.
상기 제2 AP MLD로 전이되는 시점이 상기 제2 AP MLD에 연결된 각 링크에 대해 모두 동일한 것에 기초하여, 상기 제3 정보는 상기 공통 정보 필드에 포함될 수 있다. 즉, 상기 제1 AP MLD는 상기 공통 정보 필드에 상기 제3 정보를 포함하여 각 링크에 대해 공통적으로 전이되는 시점을 알려줄 수 있다.
상기 제2 AP MLD에 연결된 링크로 전이되는 시점이 상기 제2 AP MLD에 연결된 각 링크에 대해 서로 다른 것에 기초하여, 상기 제3 정보는 상기 링크 정보 필드에 포함될 수 있다. 즉, 상기 제1 AP MLD는 상기 링크 정보 필드에 상기 제3 정보를 포함하여 각 링크에 대해 개별적으로 전이되는 시점을 알려줄 수 있다.
다른 예로, 상기 제1 정보가 1로 설정되는 것과 상기 제2 정보에 기초하여, 상기 DL 데이터에 대한 타이머가 설정될 수 있다. 상기 DL 데이터에 대한 타이머가 만료되는 것에 기초하여, 상기 DL 데이터의 송신이 끝날 수 있다. 상기 DL 데이터의 송신이 완료되어 상기 제1 AP MLD에서 상기 제2 AP MLD로 전이가 수행된 이후, 상기 non-AP STA은 상기 제2 AP MLD와 DL 데이터 또는 UL 데이터를 송수신할 수 있다.
즉, 본 실시예는 MLD 로밍을 수행하는 과정에서 Serving AP MLD의 큐에 DL 데이터가 남아 있는 경우, 상기 DL 데이터가 모두 송신되는 시점을 로밍 응답 프레임을 통해 알려주어 상기 Serving AP MLD에서 Target AP MLD로 전이되는 시점을 결정하는 방법을 제안한다. Non-AP STA은 상기 Serving AP MLD의 큐에 존재하는 상기 DL 데이터가 모두 송신되는 시점을 확인할 수 있어, MLD 로밍을 효율적으로 수행할 수 있다는 효과가 있다.
상기 제1 AP MLD에서 상기 제2 AP MLD로 컨텍스트가 전달된 이후, 상기 non-AP STA은 상기 제2 AP MLD에 소속된 제2 AP로부터 상기 컨텍스트의 전달이 완료되었다는 정보를 수신할 수 있다. 상기 non-AP STA은 상기 로밍 요청 프레임 및 상기 로밍 응답 프레임을 기반으로 상기 제1 AP에서 상기 제2 AP로 로밍을 수행할 수 있다.
상기 제1 및 제2 AP MLD는 로밍이 가능한 그룹에 포함된다. 상기 제1 AP MLD에 제1 AP가 소속되고(is affiliated with), 상기 제2 AP MLD에 제2 AP가 소속될 수 있다. 상기 non-AP MLD에 non-AP STA이 소속될 수 있다.
상기 제1 AP는 Old AP(O_AP), Serving AP 또는 Current AP라고 불릴 수 있다. 상기 제2 AP는 New AP(N_AP) 또는 Target AP라고 불릴 수 있다. 상기 제1 AP를 포함하는 상기 제1 AP MLD는 Serving AP MLD라고 불릴 수 있다. 상기 제2 AP를 포함하는 상기 제2 AP MLD는 Target AP MLD라고 불릴 수 있다. Serving AP MLD에서 Target AP MLD로의 MLD 로밍은 MLD 내 AP와 STA 간의 단절 없이 AP에서 다른 AP로 끊기지 않고(seamless) 옮기는 동작으로 정의된다.
상기 로밍이 가능한 그룹은 UHR AP MLD라고 불릴 수 있다. 상기 제1 및 제2 AP MLD는 non-collocated되어 있으나, 상기 로밍이 가능한 같은 그룹에 포함되어 있어 상기 제1 AP MLD의 AP에서 상기 제2 AP MLD로의 AP로의 로밍(또는 이동)이 가능할 수 있다. 상기 제1 AP MLD 내 AP들은 collocated되어 있다. 상기 제2 AP MLD 내 AP들도 collocated되어 있다.
끊김없는 로밍(seamless roaming)에서는 두 가지 유형의 아키텍처(architecture)가 있을 수 있다.
첫 번째로, MLD 기반 아키텍처가 있다. 상기 MLD 기반 아키텍처는 SMD(Single Mobility Domain)라 불리는 단일 도메인에서 모든 AP MLD가 하나의 MAC(medium access control) SAP(service access point)을 가지는 경우를 의미한다. 즉, 상기 MLD 기반 아키텍처는 seamless roaming을 수행할 수 있는 모든 AP MLD에 인터페이스된 공통 AP MLD upper MAC을 가진다. UFT AP MLD의 UMAC은 seamless roaming에 필요한 모든 UMAC 기능들을 제어하며 자신만의 MAC SAP과 고유한 MLD MAC address를 가진다. 상기 MLD 기반 아키텍처는 Centralized 형식의 아키텍처이기 때문에 컨텍스트가 DS(Distribution System)를 통해 전달되지 않으며, 컨텍스트 전달이 존재하지 않을 수 있다.
두 번째로, 컨텍스트 전달 기반 아키텍처가 있다. 상기 컨텍스트 전달 기반 아키텍처는 기존 아키텍처(특히, 기존 FT(Fast Transition))를 사용한 개선된 로밍 아키텍처이다. 이 방법은 serving AP MLD와 target AP MLD 간에 컨텍스트 전달을 요구한다. 각 AP MLD는 자신만의 MAC SAP을 가지고 있다. 모든 AP MLD는 DS에 개별적으로 매핑되고, non-AP MLD는 AP MLD와 연계된다. Non-AP MLD가 serving AP MLD에서 target AP MLD로 로밍할 때, re-authentication과 re-association 없이 로밍을 해야한다. AP MLD 중 정보를 공유하기 위해 단일 도메인에서 AP MLD들은 logical entity와 연결될 필요가 있다. 보안 키(security key, 예를 들어, SMD에 대한 single MAC address)는 동일한 단일 도메인에서 AP MLD들 중 공유되어야 한다.
MLD based architecture는 거의 지연(delay)이 없으나, 아키텍처 변경이 요구되고 구현하는데 보다 복잡하다. 보안 키는 roaming MLD에서 생성되어 affiliated AP MLD들에게 공유될 수 있다. 이에 반해, roaming with context transfer는 다소 지연이 존재하며, 다른 채널의 경우 지연이 악화될 수 있으나, 현재 아키텍처를 유지하며 구현도 보다 단순하다. 보안 키는 보안된 채널을 통해 공유된다. 즉, MLD based architecture는 거의 지연이 없어 원활한 roaming 목적을 충족하기 때문에 가장 선호되는 시나리오이다. 그러나, 아키텍처의 변경으로 인해 구현하기 어려울 수 있으며, 구현의 용이성을 위해 컨텍스트 전송 기반 아키텍처를 사용할 수 있다.
상기 제1 AP MLD, 상기 제2 AP MLD 및 상기 로밍이 가능한 그룹은 DS(Distribution System)에 연결될 수 있다. 일례로, 상기 제1 및 제2 AP MLD가 개별적으로 MAC SAP을 가지고 있는 것에 기초하여, 상기 MLD 로밍 요청 프레임이 송신된 후에, 상기 컨텍스트는 상기 제2 AP MLD에게 상기 DS를 통해 전달될 수 있다.
상기 컨텍스트는 AP와 STA 간(또는 non-AP MLD STA과 Serving AP MLD 간) 협상이 되어 있는 파라미터 세트(parameter set)라고 할 수 있다. 상기 DS는 서로 다른 BSS(Basic Service Set) 간의 연결을 제공하여 무선망을 확장시키는 무선 LAN용 백본(backbone) 네트워크일 수 있다.
상기 로밍 요청 프레임은 재설정(Reconfiguration) Multi-link IE(Information Element)를 기반으로 정의될 수 있다. 상기 로밍 응답 프레임은 재설정 Multi-link IE 또는 기본(Basic) Multi-link IE 중 하나를 기반으로 정의될 수 있다.
상기 로밍 요청 프레임의 제1 공통 정보 필드 또는 제1 링크 정보 필드에 로밍 이유 코드가 포함될 수 있다. 또한, 상기 로밍 응답 프레임의 제2 공통 정보 필드 또는 제2 링크 정보 필드에 로밍 이유 코드가 포함될 수 있다.
상기 로밍 이유 코드의 값에 따른 로밍을 하는 이유에 대한 정보는 다음과 같이 설정될 수 있다.
상기 로밍 이유 코드가 0으로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 지정되지 않을 수 있다. 상기 로밍 이유 코드가 1로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 과도한 프레임 손실률 또는 열악한 조건일 수 있다. 상기 로밍 이유 코드가 2로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 현재 트래픽 스트림에 대한 과도한 지연일 수 있다. 상기 로밍 이유 코드가 3으로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 현재 트래픽 스트림에 대한 부족한 QoS(Quality of Service) 용량일 수 있다. 상기 로밍 이유 코드가 4로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 더 나은 링크의 발견일 수 있다.
상기 로밍 이유 코드가 5로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 더 나은 AP의 발견일 수 있다. 상기 로밍 이유 코드가 6으로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 리플레이 카운터 실패(replay counter failures)가 너무 많이 수신됨일 수 있다. 상기 로밍 이유 코드가 7로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 데이터 MIC(Message Integrity Code) 실패가 너무 많이 수신됨일 수 있다. 상기 로밍 이유 코드가 8로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 재전송 최대 횟수의 초과일 수 있다. 상기 로밍 이유 코드가 9로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 브로드캐스트 분리(broadcast disassociations)가 너무 많이 수신됨일 수 있다. 상기 로밍 이유 코드가 10으로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 브로드캐스트 인증 해제(broadcast de-authentications)가 너무 많이 수신됨일 수 있다.
상기 로밍 이유 코드가 11로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 이전 로밍의 실패일 수 있다. 상기 로밍 이유 코드가 12로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 낮은 RSSI(Received Signal Strength Indication)일 수 있다. 상기 로밍 이유 코드가 13으로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 수신된 로밍 요청 프레임으로 인한 전환일 수 있다. 상기 로밍 이유 코드가 14로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 추천된 로밍 목록의 포함일 수 있다. 상기 로밍 이유 코드가 15 내지 255로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 유보될 수 있다(reserved).
도 74는 본 실시예에 따른 MLD 로밍에서 Serving AP MLD의 큐에 있는 DL 데이터의 송신이 끝나는 시점에 대한 정보를 수신하는 절차를 도시한 흐름도이다.
도 74의 일례는 차세대 무선랜 시스템(UHR(Ultra High Reliability) 무선랜 시스템 또는 next wi-fi)이 지원되는 네트워크 환경에서 수행될 수 있다. 상기 차세대 무선랜 시스템은 802.11be 시스템을 개선한 무선랜 시스템으로 802.11be 시스템과 하위 호환성(backward compatibility)을 만족할 수 있다.
본 실시예는 MLD 로밍이 수행될 때 Serving AP MLD의 큐에 DL 데이터(또는 DL 패킷)가 남아 있는 경우, 상기 DL 데이터가 모두 송신되는 시점을 로밍 응답 프레임을 통해 알려주어 상기 Serving AP MLD에서 Target AP MLD로 전이되는 시점을 결정하는 방법을 제안한다.
S7410 단계에서, 상기 non-AP MLD에 소속된 non-AP STA(station)은 제1 AP MLD에 소속된 제1 AP에게 로밍 요청 프레임(Roaming Request frame)을 송신한다.
S7420 단계에서, 상기 non-AP STA은 상기 제1 AP로부터 로밍 응답 프레임(Roaming Response frame)을 수신한다.
S7430 단계에서, 상기 non-AP STA은 상기 로밍 응답 프레임을 기반으로 상기 제1 AP MLD에서 제2 AP MLD로 전이(transition)할지 여부를 결정한다.
상기 로밍 응답 프레임은 상기 제1 AP MLD의 큐(queue)에 DL(downlink) 데이터가 남아있는지 여부에 대한 제1 정보 및 상기 제1 AP MLD로부터 송신되는 상기 DL 데이터에 대한 제2 정보를 포함한다.
상기 제1 정보가 1로 설정되는 것과 상기 제2 정보에 기초하여, 상기 DL 데이터의 송신이 끝나는 시점이 결정된다.
상기 제1 정보가 1로 설정되는 것에 기초하여, 상기 제1 AP MLD의 큐에 상기 DL 데이터가 남아있을 수 있다. 상기 제1 정보가 0으로 설정되는 것에 기초하여, 상기 제1 AP MLD의 큐에 상기 DL 데이터가 더 이상 없을 수 있다.
상기 제2 정보는 상기 DL 데이터의 크기, 아직 송신되지 않은 MSDU(MAC Service Data Unit)의 개수, SN(Sequence Number) 또는 PN(Packet Number)에 관한 정보, 및 펜딩(pending) 중인 MSDU를 식별하는 TID(Traffic IDentifiers)에 대한 정보를 포함할 수 있다. 상기 SN 또는 PN에 관한 정보는 상기 MSDU에서 마지막 MSDU의 SN 또는 PN일 수 있다. 상기 TID는 상기 펜딩 중이 MSDU의 개수를 크기로 하는 비트맵으로 설정될 수 있다.
즉, 상기 제1 정보가 1로 설정되어 상기 제1 AP MLD의 큐에 상기 DL 데이터가 남아있고, 상기 DL 데이터에 대한 정보를 기반으로 상기 non-AP STA은 상기 DL 데이터의 송신이 끝나는 시점을 알 수 있다. 이때, 상기 DL 데이터의 송신이 끝나는 시점을 기반으로, 상기 제1 AP MLD에서 상기 제2 AP MLD로 전이가 수행된다.
상기 제1 정보가 0으로 설정되어 상기 제1 AP MLD의 큐에 상기 DL 데이터가 남아 있지 않다면, 상기 non-AP STA은 상기 로밍 응답 프레임을 수신한 이후 바로 상기 제2 AP MLD와 DL 또는 UL(uplink) 송신을 시작할 수 있다.
상기 로밍 응답 프레임은 채널 스위치 카운트(channel switch count)에 대한 제3 정보를 더 포함할 수 있다. 상기 제3 정보는 상기 제1 AP MLD(또는 상기 제1 AP MLD에 소속된 제1 AP)에 연결된 제1 링크에서 상기 제2 AP MLD(또는 상기 제2 AP MLD에 소속된 제2 AP)에 연결된 제2 링크로 전이되는 시점에 대한 정보일 수 있다. 이때, 상기 제1 링크의 채널과 상기 제2 링크의 채널은 서로 다를 수 있다. 만약, 상기 제1 및 제2 링크의 채널이 서로 같다면, 상기 제3 정보 없이도 상기 non-AP STA은 상기 제1 링크에서 상기 제2 링크로 전이되는 시점을 알 수 있다.
상기 로밍 응답 프레임은 공통 정보 필드 및 링크 정보 필드를 포함할 수 있다.
상기 제2 AP MLD로 전이되는 시점이 상기 제2 AP MLD에 연결된 각 링크에 대해 모두 동일한 것에 기초하여, 상기 제3 정보는 상기 공통 정보 필드에 포함될 수 있다. 즉, 상기 제1 AP MLD는 상기 공통 정보 필드에 상기 제3 정보를 포함하여 각 링크에 대해 공통적으로 전이되는 시점을 알려줄 수 있다.
상기 제2 AP MLD에 연결된 링크로 전이되는 시점이 상기 제2 AP MLD에 연결된 각 링크에 대해 서로 다른 것에 기초하여, 상기 제3 정보는 상기 링크 정보 필드에 포함될 수 있다. 즉, 상기 제1 AP MLD는 상기 링크 정보 필드에 상기 제3 정보를 포함하여 각 링크에 대해 개별적으로 전이되는 시점을 알려줄 수 있다.
다른 예로, 상기 제1 정보가 1로 설정되는 것과 상기 제2 정보에 기초하여, 상기 DL 데이터에 대한 타이머가 설정될 수 있다. 상기 DL 데이터에 대한 타이머가 만료되는 것에 기초하여, 상기 DL 데이터의 송신이 끝날 수 있다. 상기 DL 데이터의 송신이 완료되어 상기 제1 AP MLD에서 상기 제2 AP MLD로 전이가 수행된 이후, 상기 non-AP STA은 상기 제2 AP MLD와 DL 데이터 또는 UL 데이터를 송수신할 수 있다.
즉, 본 실시예는 MLD 로밍을 수행하는 과정에서 Serving AP MLD의 큐에 DL 데이터가 남아 있는 경우, 상기 DL 데이터가 모두 송신되는 시점을 로밍 응답 프레임을 통해 알려주어 상기 Serving AP MLD에서 Target AP MLD로 전이되는 시점을 결정하는 방법을 제안한다. Non-AP STA은 상기 Serving AP MLD의 큐에 존재하는 상기 DL 데이터가 모두 송신되는 시점을 확인할 수 있어, MLD 로밍을 효율적으로 수행할 수 있다는 효과가 있다.
상기 제1 AP MLD에서 상기 제2 AP MLD로 컨텍스트가 전달된 이후, 상기 non-AP STA은 상기 제2 AP MLD에 소속된 제2 AP로부터 상기 컨텍스트의 전달이 완료되었다는 정보를 수신할 수 있다. 상기 non-AP STA은 상기 로밍 요청 프레임 및 상기 로밍 응답 프레임을 기반으로 상기 제1 AP에서 상기 제2 AP로 로밍을 수행할 수 있다.
상기 제1 및 제2 AP MLD는 로밍이 가능한 그룹에 포함된다. 상기 제1 AP MLD에 제1 AP가 소속되고(is affiliated with), 상기 제2 AP MLD에 제2 AP가 소속될 수 있다. 상기 non-AP MLD에 non-AP STA이 소속될 수 있다.
상기 제1 AP는 Old AP(O_AP), Serving AP 또는 Current AP라고 불릴 수 있다. 상기 제2 AP는 New AP(N_AP) 또는 Target AP라고 불릴 수 있다. 상기 제1 AP를 포함하는 상기 제1 AP MLD는 Serving AP MLD라고 불릴 수 있다. 상기 제2 AP를 포함하는 상기 제2 AP MLD는 Target AP MLD라고 불릴 수 있다. Serving AP MLD에서 Target AP MLD로의 MLD 로밍은 MLD 내 AP와 STA 간의 단절 없이 AP에서 다른 AP로 끊기지 않고(seamless) 옮기는 동작으로 정의된다.
상기 로밍이 가능한 그룹은 UHR AP MLD라고 불릴 수 있다. 상기 제1 및 제2 AP MLD는 non-collocated되어 있으나, 상기 로밍이 가능한 같은 그룹에 포함되어 있어 상기 제1 AP MLD의 AP에서 상기 제2 AP MLD로의 AP로의 로밍(또는 이동)이 가능할 수 있다. 상기 제1 AP MLD 내 AP들은 collocated되어 있다. 상기 제2 AP MLD 내 AP들도 collocated되어 있다.
끊김없는 로밍(seamless roaming)에서는 두 가지 유형의 아키텍처(architecture)가 있을 수 있다.
첫 번째로, MLD 기반 아키텍처가 있다. 상기 MLD 기반 아키텍처는 SMD(Single Mobility Domain)라 불리는 단일 도메인에서 모든 AP MLD가 하나의 MAC(medium access control) SAP(service access point)을 가지는 경우를 의미한다. 즉, 상기 MLD 기반 아키텍처는 seamless roaming을 수행할 수 있는 모든 AP MLD에 인터페이스된 공통 AP MLD upper MAC을 가진다. UFT AP MLD의 UMAC은 seamless roaming에 필요한 모든 UMAC 기능들을 제어하며 자신만의 MAC SAP과 고유한 MLD MAC address를 가진다. 상기 MLD 기반 아키텍처는 Centralized 형식의 아키텍처이기 때문에 컨텍스트가 DS(Distribution System)를 통해 전달되지 않으며, 컨텍스트 전달이 존재하지 않을 수 있다.
두 번째로, 컨텍스트 전달 기반 아키텍처가 있다. 상기 컨텍스트 전달 기반 아키텍처는 기존 아키텍처(특히, 기존 FT(Fast Transition))를 사용한 개선된 로밍 아키텍처이다. 이 방법은 serving AP MLD와 target AP MLD 간에 컨텍스트 전달을 요구한다. 각 AP MLD는 자신만의 MAC SAP을 가지고 있다. 모든 AP MLD는 DS에 개별적으로 매핑되고, non-AP MLD는 AP MLD와 연계된다. Non-AP MLD가 serving AP MLD에서 target AP MLD로 로밍할 때, re-authentication과 re-association 없이 로밍을 해야한다. AP MLD 중 정보를 공유하기 위해 단일 도메인에서 AP MLD들은 logical entity와 연결될 필요가 있다. 보안 키(security key, 예를 들어, SMD에 대한 single MAC address)는 동일한 단일 도메인에서 AP MLD들 중 공유되어야 한다.
MLD based architecture는 거의 지연(delay)이 없으나, 아키텍처 변경이 요구되고 구현하는데 보다 복잡하다. 보안 키는 roaming MLD에서 생성되어 affiliated AP MLD들에게 공유될 수 있다. 이에 반해, roaming with context transfer는 다소 지연이 존재하며, 다른 채널의 경우 지연이 악화될 수 있으나, 현재 아키텍처를 유지하며 구현도 보다 단순하다. 보안 키는 보안된 채널을 통해 공유된다. 즉, MLD based architecture는 거의 지연이 없어 원활한 roaming 목적을 충족하기 때문에 가장 선호되는 시나리오이다. 그러나, 아키텍처의 변경으로 인해 구현하기 어려울 수 있으며, 구현의 용이성을 위해 컨텍스트 전송 기반 아키텍처를 사용할 수 있다.
상기 제1 AP MLD, 상기 제2 AP MLD 및 상기 로밍이 가능한 그룹은 DS(Distribution System)에 연결될 수 있다. 일례로, 상기 제1 및 제2 AP MLD가 개별적으로 MAC SAP을 가지고 있는 것에 기초하여, 상기 MLD 로밍 요청 프레임이 송신된 후에, 상기 컨텍스트는 상기 제2 AP MLD에게 상기 DS를 통해 전달될 수 있다.
상기 컨텍스트는 AP와 STA 간(또는 non-AP MLD STA과 Serving AP MLD 간) 협상이 되어 있는 파라미터 세트(parameter set)라고 할 수 있다. 상기 DS는 서로 다른 BSS(Basic Service Set) 간의 연결을 제공하여 무선망을 확장시키는 무선 LAN용 백본(backbone) 네트워크일 수 있다.
상기 로밍 요청 프레임은 재설정(Reconfiguration) Multi-link IE(Information Element)를 기반으로 정의될 수 있다. 상기 로밍 응답 프레임은 재설정 Multi-link IE 또는 기본(Basic) Multi-link IE 중 하나를 기반으로 정의될 수 있다.
상기 로밍 요청 프레임의 제1 공통 정보 필드 또는 제1 링크 정보 필드에 로밍 이유 코드가 포함될 수 있다. 또한, 상기 로밍 응답 프레임의 제2 공통 정보 필드 또는 제2 링크 정보 필드에 로밍 이유 코드가 포함될 수 있다.
상기 로밍 이유 코드의 값에 따른 로밍을 하는 이유에 대한 정보는 다음과 같이 설정될 수 있다.
상기 로밍 이유 코드가 0으로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 지정되지 않을 수 있다. 상기 로밍 이유 코드가 1로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 과도한 프레임 손실률 또는 열악한 조건일 수 있다. 상기 로밍 이유 코드가 2로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 현재 트래픽 스트림에 대한 과도한 지연일 수 있다. 상기 로밍 이유 코드가 3으로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 현재 트래픽 스트림에 대한 부족한 QoS(Quality of Service) 용량일 수 있다. 상기 로밍 이유 코드가 4로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 더 나은 링크의 발견일 수 있다.
상기 로밍 이유 코드가 5로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 더 나은 AP의 발견일 수 있다. 상기 로밍 이유 코드가 6으로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 리플레이 카운터 실패(replay counter failures)가 너무 많이 수신됨일 수 있다. 상기 로밍 이유 코드가 7로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 데이터 MIC(Message Integrity Code) 실패가 너무 많이 수신됨일 수 있다. 상기 로밍 이유 코드가 8로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 재전송 최대 횟수의 초과일 수 있다. 상기 로밍 이유 코드가 9로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 브로드캐스트 분리(broadcast disassociations)가 너무 많이 수신됨일 수 있다. 상기 로밍 이유 코드가 10으로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 브로드캐스트 인증 해제(broadcast de-authentications)가 너무 많이 수신됨일 수 있다.
상기 로밍 이유 코드가 11로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 이전 로밍의 실패일 수 있다. 상기 로밍 이유 코드가 12로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 낮은 RSSI(Received Signal Strength Indication)일 수 있다. 상기 로밍 이유 코드가 13으로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 수신된 로밍 요청 프레임으로 인한 전환일 수 있다. 상기 로밍 이유 코드가 14로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 추천된 로밍 목록의 포함일 수 있다. 상기 로밍 이유 코드가 15 내지 255로 설정되는 것에 기초하여, 상기 AP로 로밍을 추천하는 이유는 유보될 수 있다(reserved).
<장치 구성>
상술한 본 명세서의 기술적 특징은 다양한 장치 및 방법에 적용될 수 있다. 예를 들어, 상술한 본 명세서의 기술적 특징은 도 1 및/또는 도 14의 장치를 통해 수행/지원될 수 있다. 예를 들어, 상술한 본 명세서의 기술적 특징은, 도 1 및/또는 도 14의 일부에만 적용될 수 있다. 예를 들어, 상술한 본 명세서의 기술적 특징은, 도 1의 프로세싱 칩(114, 124)을 기초로 구현되거나, 도 1의 프로세서(111, 121)와 메모리(112, 122)를 기초로 구현되거나, 도 14의 프로세서(610)와 메모리(620)를 기초로 구현될 수 있다. 예를 들어, 본 명세서의 장치는, 제1 AP(access point) MLD(multi-link device)에 소속된 제1 AP에게 로밍 요청 프레임(Roaming Request frame)을 송신하고; 상기 제1 AP로부터 로밍 응답 프레임(Roaming Response frame)을 수신하고; 및 상기 로밍 응답 프레임을 기반으로 상기 제1 AP MLD에서 제2 AP MLD로 전이(transition)할지 여부를 결정한다.
본 명세서의 기술적 특징은 CRM(computer readable medium)을 기초로 구현될 수 있다. 예를 들어, 본 명세서에 의해 제안되는 CRM은 적어도 하나의 프로세서(processor)에 의해 실행됨을 기초로 하는 명령어(instruction)를 포함하는 적어도 하나의 컴퓨터로 읽을 수 있는 기록매체(computer readable medium)이다.
상기 CRM은, 제1 AP(access point) MLD(multi-link device)에 소속된 제1 AP에게 로밍 요청 프레임(Roaming Request frame)을 송신하는 단계; 상기 제1 AP로부터 로밍 응답 프레임(Roaming Response frame)을 수신하는 단계; 및 상기 로밍 응답 프레임을 기반으로 상기 제1 AP MLD에서 제2 AP MLD로 전이(transition)할지 여부를 결정하는 단계를 포함하는 동작(operations)을 수행하는 명령어(instructions)를 저장할 수 있다. 본 명세서의 CRM 내에 저장되는 명령어는 적어도 하나의 프로세서에 의해 실행(execute)될 수 있다. 본 명세서의 CRM에 관련된 적어도 하나의 프로세서는 도 1의 프로세서(111, 121) 또는 프로세싱 칩(114, 124)이거나, 도 14의 프로세서(610)일 수 있다. 한편, 본 명세서의 CRM은 도 1의 메모리(112, 122)이거나 도 14의 메모리(620)이거나, 별도의 외부 메모리/저장매체/디스크 등일 수 있다.
상술한 본 명세서의 기술적 특징은 다양한 응용예(application)나 비즈니스 모델에 적용 가능하다. 예를 들어, 인공 지능(Artificial Intelligence: AI)을 지원하는 장치에서의 무선 통신을 위해 상술한 기술적 특징이 적용될 수 있다.
인공 지능은 인공적인 지능 또는 이를 만들 수 있는 방법론을 연구하는 분야를 의미하며, 머신 러닝(기계 학습, Machine Learning)은 인공 지능 분야에서 다루는 다양한 문제를 정의하고 그것을 해결하는 방법론을 연구하는 분야를 의미한다. 머신 러닝은 어떠한 작업에 대하여 꾸준한 경험을 통해 그 작업에 대한 성능을 높이는 알고리즘으로 정의하기도 한다.
인공 신경망(Artificial Neural Network; ANN)은 머신 러닝에서 사용되는 모델로써, 시냅스의 결합으로 네트워크를 형성한 인공 뉴런(노드)들로 구성되는, 문제 해결 능력을 가지는 모델 전반을 의미할 수 있다. 인공 신경망은 다른 레이어의 뉴런들 사이의 연결 패턴, 모델 파라미터를 갱신하는 학습 과정, 출력값을 생성하는 활성화 함수(Activation Function)에 의해 정의될 수 있다.
인공 신경망은 입력층(Input Layer), 출력층(Output Layer), 그리고 선택적으로 하나 이상의 은닉층(Hidden Layer)를 포함할 수 있다. 각 층은 하나 이상의 뉴런을 포함하고, 인공 신경망은 뉴런과 뉴런을 연결하는 시냅스를 포함할 수 있다. 인공 신경망에서 각 뉴런은 시냅스를 통해 입력되는 입력 신호들, 가중치, 편향에 대한 활성 함수의 함숫값을 출력할 수 있다.
모델 파라미터는 학습을 통해 결정되는 파라미터를 의미하며, 시냅스 연결의 가중치와 뉴런의 편향 등이 포함된다. 그리고, 하이퍼파라미터는 머신 러닝 알고리즘에서 학습 전에 설정되어야 하는 파라미터를 의미하며, 학습률(Learning Rate), 반복 횟수, 미니 배치 크기, 초기화 함수 등이 포함된다.
인공 신경망의 학습의 목적은 손실 함수를 최소화하는 모델 파라미터를 결정하는 것으로 볼 수 있다. 손실 함수는 인공 신경망의 학습 과정에서 최적의 모델 파라미터를 결정하기 위한 지표로 이용될 수 있다.
머신 러닝은 학습 방식에 따라 지도 학습(Supervised Learning), 비지도 학습(Unsupervised Learning), 강화 학습(Reinforcement Learning)으로 분류할 수 있다.
지도 학습은 학습 데이터에 대한 레이블(label)이 주어진 상태에서 인공 신경망을 학습시키는 방법을 의미하며, 레이블이란 학습 데이터가 인공 신경망에 입력되는 경우 인공 신경망이 추론해 내야 하는 정답(또는 결과 값)을 의미할 수 있다. 비지도 학습은 학습 데이터에 대한 레이블이 주어지지 않는 상태에서 인공 신경망을 학습시키는 방법을 의미할 수 있다. 강화 학습은 어떤 환경 안에서 정의된 에이전트가 각 상태에서 누적 보상을 최대화하는 행동 혹은 행동 순서를 선택하도록 학습시키는 학습 방법을 의미할 수 있다.
인공 신경망 중에서 복수의 은닉층을 포함하는 심층 신경망(DNN: Deep Neural Network)으로 구현되는 머신 러닝을 딥 러닝(심층 학습, Deep Learning)이라 부르기도 하며, 딥 러닝은 머신 러닝의 일부이다. 이하에서, 머신 러닝은 딥 러닝을 포함하는 의미로 사용된다.
또한 상술한 기술적 특징은 로봇의 무선 통신에 적용될 수 있다.
로봇은 스스로 보유한 능력에 의해 주어진 일을 자동으로 처리하거나 작동하는 기계를 의미할 수 있다. 특히, 환경을 인식하고 스스로 판단하여 동작을 수행하는 기능을 갖는 로봇을 지능형 로봇이라 칭할 수 있다.
로봇은 사용 목적이나 분야에 따라 산업용, 의료용, 가정용, 군사용 등으로 분류할 수 있다. 로봇은 액츄에이터 또는 모터를 포함하는 구동부를 구비하여 로봇 관절을 움직이는 등의 다양한 물리적 동작을 수행할 수 있다. 또한, 이동 가능한 로봇은 구동부에 휠, 브레이크, 프로펠러 등이 포함되어, 구동부를 통해 지상에서 주행하거나 공중에서 비행할 수 있다.
또한 상술한 기술적 특징은 확장 현실을 지원하는 장치에 적용될 수 있다.
확장 현실은 가상 현실(VR: Virtual Reality), 증강 현실(AR: Augmented Reality), 혼합 현실(MR: Mixed Reality)을 총칭한다. VR 기술은 현실 세계의 객체나 배경 등을 CG 영상으로만 제공하고, AR 기술은 실제 사물 영상 위에 가상으로 만들어진 CG 영상을 함께 제공하며, MR 기술은 현실 세계에 가상 객체들을 섞고 결합시켜서 제공하는 컴퓨터 그래픽 기술이다.
MR 기술은 현실 객체와 가상 객체를 함께 보여준다는 점에서 AR 기술과 유사하다. 그러나, AR 기술에서는 가상 객체가 현실 객체를 보완하는 형태로 사용되는 반면, MR 기술에서는 가상 객체와 현실 객체가 동등한 성격으로 사용된다는 점에서 차이점이 있다.
XR 기술은 HMD(Head-Mount Display), HUD(Head-Up Display), 휴대폰, 태블릿 PC, 랩탑, 데스크탑, TV, 디지털 사이니지 등에 적용될 수 있고, XR 기술이 적용된 장치를 XR 장치(XR Device)라 칭할 수 있다.
본 명세서에 기재된 청구항들은 다양한 방식으로 조합될 수 있다. 예를 들어, 본 명세서의 방법 청구항의 기술적 특징이 조합되어 장치로 구현될 수 있고, 본 명세서의 장치 청구항의 기술적 특징이 조합되어 방법으로 구현될 수 있다. 또한, 본 명세서의 방법 청구항의 기술적 특징과 장치 청구항의 기술적 특징이 조합되어 장치로 구현될 수 있고, 본 명세서의 방법 청구항의 기술적 특징과 장치 청구항의 기술적 특징이 조합되어 방법으로 구현될 수 있다.

Claims (18)

  1. 무선랜 시스템에서 non-AP(non-access point) MLD(multi-link device)에 의해 수행되는 방법에 있어서,
    상기 non-AP MLD에 소속된 non-AP STA(station)이, 제1 AP MLD에 소속된 제1 AP에게 로밍 요청 프레임(Roaming Request frame)을 송신하는 단계;
    상기 non-AP STA이, 상기 제1 AP로부터 로밍 응답 프레임(Roaming Response frame)을 수신하는 단계; 및
    상기 non-AP STA이, 상기 로밍 응답 프레임을 기반으로 상기 제1 AP MLD에서 제2 AP MLD로 전이(transition)할지 여부를 결정하는 단계를 포함하되,
    상기 로밍 응답 프레임은 상기 제1 AP MLD의 큐(queue)에 DL(downlink) 데이터가 남아있는지 여부에 대한 제1 정보 및 상기 제1 AP MLD로부터 송신되는 상기 DL 데이터에 대한 제2 정보를 포함하고,
    상기 제1 정보가 1로 설정되는 것과 상기 제2 정보에 기초하여, 상기 DL 데이터의 송신이 끝나는 시점이 결정되고, 및
    상기 DL 데이터의 송신이 끝나는 시점을 기반으로, 상기 제1 AP MLD에서 상기 제2 AP MLD로 전이가 수행되는
    방법.
  2. 제1항에 있어서,
    상기 제1 정보가 1로 설정되는 것에 기초하여, 상기 제1 AP MLD의 큐에 상기 DL 데이터가 남아있고,
    상기 제1 정보가 0으로 설정되는 것에 기초하여, 상기 제1 AP MLD의 큐에 상기 DL 데이터가 더 이상 없고,
    상기 제2 정보는 상기 DL 데이터의 크기, 아직 송신되지 않은 MSDU(MAC Service Data Unit)의 개수, SN(Sequence Number) 또는 PN(Packet Number)에 관한 정보, 및 펜딩(pending) 중인 MSDU를 식별하는 TID(Traffic IDentifiers)에 대한 정보를 포함하고,
    상기 SN 또는 PN에 관한 정보는 상기 MSDU에서 마지막 MSDU의 SN 또는 PN인
    방법.
  3. 제1항에 있어서,
    상기 로밍 응답 프레임은 채널 스위치 카운트(channel switch count)에 대한 제3 정보를 더 포함하고,
    상기 제3 정보는 상기 제1 AP MLD에 연결된 제1 링크에서 상기 제2 AP MLD에 연결된 제2 링크로 전이되는 시점에 대한 정보이고,
    상기 제1 링크의 채널과 상기 제2 링크의 채널은 서로 다른
    방법.
  4. 제3항에 있어서,
    상기 로밍 응답 프레임은 공통 정보 필드 및 링크 정보 필드를 포함하고,
    상기 제2 AP MLD로 전이되는 시점이 상기 제2 AP MLD에 연결된 각 링크에 대해 모두 동일한 것에 기초하여, 상기 제3 정보는 상기 공통 정보 필드에 포함되고,
    상기 제2 AP MLD에 연결된 링크로 전이되는 시점이 상기 제2 AP MLD에 연결된 각 링크에 대해 서로 다른 것에 기초하여, 상기 제3 정보는 상기 링크 정보 필드에 포함되는
    방법.
  5. 제1항에 있어서,
    상기 제1 정보가 1로 설정되는 것과 상기 제2 정보에 기초하여, 상기 DL 데이터에 대한 타이머가 설정되고,
    상기 DL 데이터에 대한 타이머가 만료되는 것에 기초하여, 상기 DL 데이터의 송신이 끝나는
    방법.
  6. 제1항에 있어서,
    상기 제1 AP MLD에서 상기 제2 AP MLD로 컨텍스트가 전달된 이후, 상기 non-AP STA이, 상기 제2 AP MLD에 소속된 제2 AP로부터 상기 컨텍스트의 전달이 완료되었다는 정보를 수신하는 단계; 및
    상기 non-AP STA이, 상기 로밍 요청 프레임 및 상기 로밍 응답 프레임을 기반으로 상기 제1 AP에서 상기 제2 AP로 로밍을 수행하는 단계를 더 포함하되,
    상기 제1 및 제2 AP MLD는 로밍이 가능한 그룹에 포함되는
    방법.
  7. 제6항에 있어서,
    상기 제1 AP MLD, 상기 제2 AP MLD 및 상기 로밍이 가능한 그룹은 DS(Distribution System)에 연결되고,
    상기 제1 및 제2 AP MLD가 개별적으로 MAC(medium access control) SAP(service access point)을 가지고 있는 것에 기초하여, 상기 로밍 요청 프레임이 송신된 후에, 상기 컨텍스트는 상기 제2 AP MLD에게 상기 DS를 통해 전달되는
    방법.
  8. 제1항에 있어서,
    상기 로밍 요청 프레임은 재설정(Reconfiguration) Multi-link IE(Information Element)를 기반으로 정의되고,
    상기 로밍 응답 프레임은 재설정 Multi-link IE 또는 기본(Basic) Multi-link IE 중 하나를 기반으로 정의되는
    방법.
  9. 무선랜 시스템에서, non-AP(non-access point) MLD(multi-link device)는,
    메모리;
    트랜시버; 및
    상기 메모리 및 상기 트랜시버와 동작 가능하게 결합된 프로세서를 포함하되, 상기 프로세서는:
    상기 non-AP MLD에 소속된 non-AP STA(station)이, 제1 AP MLD에 소속된 제1 AP에게 로밍 요청 프레임(Roaming Request frame)을 송신하고;
    상기 non-AP STA이, 상기 제1 AP로부터 로밍 응답 프레임(Roaming Response frame)을 수신하고; 및
    상기 non-AP STA이, 상기 로밍 응답 프레임을 기반으로 상기 제1 AP MLD에서 제2 AP MLD로 전이(transition)할지 여부를 결정하되,
    상기 로밍 응답 프레임은 상기 제1 AP MLD의 큐(queue)에 DL(downlink) 데이터가 남아있는지 여부에 대한 제1 정보 및 상기 제1 AP MLD로부터 송신되는 상기 DL 데이터에 대한 제2 정보를 포함하고,
    상기 제1 정보가 1로 설정되는 것과 상기 제2 정보에 기초하여, 상기 DL 데이터의 송신이 끝나는 시점이 결정되고, 및
    상기 DL 데이터의 송신이 끝나는 시점을 기반으로, 상기 제1 AP MLD에서 상기 제2 AP MLD로 전이가 수행되는
    Non-AP MLD.
  10. 무선랜 시스템에서 제1 AP(access point) MLD(multi-link device)에 수행되는 방법에 있어서,
    상기 제1 AP MLD에 소속된 제1 AP가, non-AP MLD에 소속된 non-AP STA(station)로부터 로밍 요청 프레임(Roaming Request frame)을 수신하는 단계; 및
    상기 제1 AP가, 상기 non-AP STA에게 로밍 응답 프레임(Roaming Response frame)을 송신하는 단계를 포함하되,
    상기 제1 AP MLD에서 제2 AP MLD로 전이(transition)할지 여부는 상기 로밍 응답 프레임을 기반으로 결정되고,
    상기 로밍 응답 프레임은 상기 제1 AP MLD의 큐(queue)에 DL(downlink) 데이터가 남아있는지 여부에 대한 제1 정보 및 상기 제1 AP MLD로부터 송신되는 상기 DL 데이터에 대한 제2 정보를 포함하고,
    상기 제1 정보가 1로 설정되는 것과 상기 제2 정보에 기초하여, 상기 DL 데이터의 송신이 끝나는 시점이 결정되고, 및
    상기 DL 데이터의 송신이 끝나는 시점을 기반으로, 상기 제1 AP MLD에서 상기 제2 AP MLD로 전이가 수행되는
    방법.
  11. 제10항에 있어서,
    상기 제1 정보가 1로 설정되는 것에 기초하여, 상기 제1 AP MLD의 큐에 상기 DL 데이터가 남아있고,
    상기 제1 정보가 0으로 설정되는 것에 기초하여, 상기 제1 AP MLD의 큐에 상기 DL 데이터가 더 이상 없고,
    상기 제2 정보는 상기 DL 데이터의 크기, 아직 송신되지 않은 MSDU(MAC Service Data Unit)의 개수, SN(Sequence Number) 또는 PN(Packet Number)에 관한 정보, 및 펜딩(pending) 중인 MSDU를 식별하는 TID(Traffic IDentifiers)에 대한 정보를 포함하고,
    상기 SN 또는 PN에 관한 정보는 상기 MSDU에서 마지막 MSDU의 SN 또는 PN인
    방법.
  12. 제10항에 있어서,
    상기 로밍 응답 프레임은 채널 스위치 카운트(channel switch count)에 대한 제3 정보를 더 포함하고,
    상기 제3 정보는 상기 제1 AP MLD에 연결된 제1 링크에서 상기 제2 AP MLD에 연결된 제2 링크로 전이되는 시점에 대한 정보이고,
    상기 제1 링크의 채널과 상기 제2 링크의 채널은 서로 다른
    방법.
  13. 제12항에 있어서,
    상기 로밍 응답 프레임은 공통 정보 필드 및 링크 정보 필드를 포함하고,
    상기 제2 AP MLD로 전이되는 시점이 상기 제2 AP MLD에 연결된 각 링크에 대해 모두 동일한 것에 기초하여, 상기 제3 정보는 상기 공통 정보 필드에 포함되고,
    상기 제2 AP MLD에 연결된 링크로 전이되는 시점이 상기 제2 AP MLD에 연결된 각 링크에 대해 서로 다른 것에 기초하여, 상기 제3 정보는 상기 링크 정보 필드에 포함되는
    방법.
  14. 제10항에 있어서,
    상기 제1 정보가 1로 설정되는 것과 상기 제2 정보에 기초하여, 상기 DL 데이터에 대한 타이머가 설정되고,
    상기 DL 데이터에 대한 타이머가 만료되는 것에 기초하여, 상기 DL 데이터의 송신이 끝나는
    방법.
  15. 제10항에 있어서,
    상기 로밍 요청 프레임은 재설정(Reconfiguration) Multi-link IE(Information Element)를 기반으로 정의되고,
    상기 로밍 응답 프레임은 재설정 Multi-link IE 또는 기본(Basic) Multi-link IE 중 하나를 기반으로 정의되는
    방법.
  16. 무선랜 시스템에서, 제1 AP(access point) MLD(multi-link device)는,
    메모리;
    트랜시버; 및
    상기 메모리 및 상기 트랜시버와 동작 가능하게 결합된 프로세서를 포함하되, 상기 프로세서는:
    상기 제1 AP MLD에 소속된 제1 AP가, non-AP MLD에 소속된 non-AP STA(station)로부터 로밍 요청 프레임(Roaming Request frame)을 수신하고; 및
    상기 제1 AP가, 상기 non-AP STA에게 로밍 응답 프레임(Roaming Response frame)을 송신하되,
    상기 제1 AP MLD에서 제2 AP MLD로 전이(transition)할지 여부는 상기 로밍 응답 프레임을 기반으로 결정되고,
    상기 로밍 응답 프레임은 상기 제1 AP MLD의 큐(queue)에 DL(downlink) 데이터가 남아있는지 여부에 대한 제1 정보 및 상기 제1 AP MLD로부터 송신되는 상기 DL 데이터에 대한 제2 정보를 포함하고,
    상기 제1 정보가 1로 설정되는 것과 상기 제2 정보에 기초하여, 상기 DL 데이터의 송신이 끝나는 시점이 결정되고, 및
    상기 DL 데이터의 송신이 끝나는 시점을 기반으로, 상기 제1 AP MLD에서 상기 제2 AP MLD로 전이가 수행되는
    제1 AP MLD.
  17. 적어도 하나의 프로세서(processor)에 의해 실행됨을 기초로 하는 명령어(instruction)를 포함하는 적어도 하나의 컴퓨터로 읽을 수 있는 기록매체(computer readable medium)에 있어서,
    제1 AP(access point) MLD(multi-link device)에 소속된 제1 AP에게 로밍 요청 프레임(Roaming Request frame)을 송신하는 단계;
    상기 제1 AP로부터 로밍 응답 프레임(Roaming Response frame)을 수신하는 단계; 및
    상기 로밍 응답 프레임을 기반으로 상기 제1 AP MLD에서 제2 AP MLD로 전이(transition)할지 여부를 결정하는 단계를 포함하되,
    상기 로밍 응답 프레임은 상기 제1 AP MLD의 큐(queue)에 DL(downlink) 데이터가 남아있는지 여부에 대한 제1 정보 및 상기 제1 AP MLD로부터 송신되는 상기 DL 데이터에 대한 제2 정보를 포함하고,
    상기 제1 정보가 1로 설정되는 것과 상기 제2 정보에 기초하여, 상기 DL 데이터의 송신이 끝나는 시점이 결정되고, 및
    상기 DL 데이터의 송신이 끝나는 시점을 기반으로, 상기 제1 AP MLD에서 상기 제2 AP MLD로 전이가 수행되는
    기록매체.
  18. 무선랜 시스템에서 장치에 있어서,
    메모리; 및
    상기 메모리와 동작 가능하게 결합된 프로세서를 포함하되, 상기 프로세서는:
    제1 AP(access point) MLD(multi-link device)에 소속된 제1 AP에게 로밍 요청 프레임(Roaming Request frame)을 송신하고;
    상기 제1 AP로부터 로밍 응답 프레임(Roaming Response frame)을 수신하고; 및
    상기 로밍 응답 프레임을 기반으로 상기 제1 AP MLD에서 제2 AP MLD로 전이(transition)할지 여부를 결정하되,
    상기 로밍 응답 프레임은 상기 제1 AP MLD의 큐(queue)에 DL(downlink) 데이터가 남아있는지 여부에 대한 제1 정보 및 상기 제1 AP MLD로부터 송신되는 상기 DL 데이터에 대한 제2 정보를 포함하고,
    상기 제1 정보가 1로 설정되는 것과 상기 제2 정보에 기초하여, 상기 DL 데이터의 송신이 끝나는 시점이 결정되고, 및
    상기 DL 데이터의 송신이 끝나는 시점을 기반으로, 상기 제1 AP MLD에서 상기 제2 AP MLD로 전이가 수행되는
    장치.
PCT/KR2025/006078 2024-05-13 2025-05-07 무선랜 시스템에서 serving ap mld의 큐에 있는 dl 데이터의 송신이 끝나는 시점에 대한 정보를 알려주는 방법 및 장치 Pending WO2025239596A1 (ko)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
KR20240062702 2024-05-13
KR10-2024-0062702 2024-05-13
KR20240110703 2024-08-19
KR10-2024-0110703 2024-08-19
KR20240114536 2024-08-26
KR10-2024-0114536 2024-08-26

Publications (1)

Publication Number Publication Date
WO2025239596A1 true WO2025239596A1 (ko) 2025-11-20

Family

ID=97720507

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2025/006078 Pending WO2025239596A1 (ko) 2024-05-13 2025-05-07 무선랜 시스템에서 serving ap mld의 큐에 있는 dl 데이터의 송신이 끝나는 시점에 대한 정보를 알려주는 방법 및 장치

Country Status (1)

Country Link
WO (1) WO2025239596A1 (ko)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11863978B2 (en) * 2020-07-16 2024-01-02 Qualcomm Incorporated Fast basic service set transition for multi-link operation
US20240138007A1 (en) * 2022-10-20 2024-04-25 Nxp Usa, Inc. Distributed access point multi-link device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11863978B2 (en) * 2020-07-16 2024-01-02 Qualcomm Incorporated Fast basic service set transition for multi-link operation
US20240138007A1 (en) * 2022-10-20 2024-04-25 Nxp Usa, Inc. Distributed access point multi-link device

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BINITA GUPTA (CISCO SYSTEMS): "Seamless roaming within a mobility domain - follow up", IEEE DRAFT; 11-24-0396-00-00BN-SEAMLESS-ROAMING-WITHIN-A-MOBILITY-DOMAIN-FOLLOW-UP, IEEE-SA MENTOR, PISCATAWAY, NJ USA, vol. 802.11 UHR; 802.11bn, no. 0, 26 March 2024 (2024-03-26), Piscataway, NJ USA, pages 1 - 18, XP068276413 *
BINITA GUPTA (CISCO SYSTEMS): "Seamless roaming within a mobility domain", IEEE DRAFT; 11-23-2157-01-00BN-SEAMLESS-ROAMING-WITHIN-A-MOBILITY-DOMAIN, IEEE-SA MENTOR, PISCATAWAY, NJ USA, vol. 802.11 UHR; 802.11bn, no. 1, 17 January 2024 (2024-01-17), Piscataway, NJ USA, pages 1 - 26, XP068275222 *
RYUICHI HIRATA (SONY CORPORATION): "Further thoughts on seamless roaming", IEEE DRAFT; 11-23-1971-01-00BN-FURTHER-THOUGHTS-ON-SEAMLESS-ROAMING, IEEE-SA MENTOR, PISCATAWAY, NJ USA, vol. 802.11 UHR; 802.11bn, no. 1, 12 January 2024 (2024-01-12), Piscataway, NJ USA, pages 1 - 12, XP068275729 *

Similar Documents

Publication Publication Date Title
WO2021251696A1 (ko) 무선랜 시스템에서 mld 간 링크 재설정을 수행하는 방법 및 장치
WO2022108370A1 (ko) 무선랜 시스템에서 송신 mld 내 ap들에 대한 부분 정보를 요청하는 방법 및 장치
WO2021251757A1 (ko) 무선랜 시스템에서 mld 간 중요 업데이트 정보를 획득하는 방법 및 장치
WO2022050814A1 (ko) 무선랜 시스템에서 mld 간 링크에 대한 정보를 획득하는 방법 및 장치
WO2022103114A1 (ko) 무선랜 시스템에서 송신 mld 내 ap들에게 중요 업데이트 정보를 요청하는 방법 및 장치
WO2022119091A1 (ko) 무선랜 시스템에서 송신 mld 내 ap들에게 부분 정보를 요청하는 방법 및 장치
WO2022158944A1 (ko) 무선랜 시스템에서 액션 프레임을 사용하여 송신 mld 내 다른 ap에 대한 정보를 요청하는 방법 및 장치
WO2025239596A1 (ko) 무선랜 시스템에서 serving ap mld의 큐에 있는 dl 데이터의 송신이 끝나는 시점에 대한 정보를 알려주는 방법 및 장치
WO2025234731A1 (ko) 무선랜 시스템에서 실제로 serving ap mld에서 target ap mld로 전달된 컨텍스트를 알려주는 방법 및 장치
WO2025249803A1 (ko) 무선랜 시스템에서 컨텍스트의 전달과 ds 매핑 변경의 시점을 정의하는 방법 및 장치
WO2025188053A1 (ko) 무선랜 시스템에서 mld 로밍에서 타이머를 설정하여 기존 링크를 삭제하는 방법 및 장치
WO2025188052A1 (ko) 무선랜 시스템에서 mld 로밍 응답 프레임을 통해 실제로 전달된 컨텍스트를 확인하는 방법 및 장치
WO2025188115A1 (ko) 무선랜 시스템에서 target ap mld에 연결된 새로운 링크와 serving ap mld에 연결된 기존 링크를 통해 ul/dl 데이터를 송수신하는 방법 및 장치
WO2025183468A1 (ko) 무선랜 시스템에서 컨텍스트를 전달하여 mld 로밍을 수행하는 방법 및 장치
WO2025188116A1 (ko) 무선랜 시스템에서 mld 로밍에서 target ap mld에 연결될 새로운 링크를 한번에 요청하거나 serving ap mld에 연결된 기존 링크를 한번에 삭제하는 방법 및 장치
WO2025234730A1 (ko) 무선랜 시스템에서 링크 재구성 알림 프레임을 기반으로 로밍에 적합한 ap를 추천하는 방법 및 장치
WO2025170314A1 (ko) 무선랜 시스템에서 컨텍스트를 전달하여 mld 로밍을 수행하는 방법 및 장치
WO2025170429A1 (ko) 무선랜 시스템에서 mld 로밍을 위한 ap mld들이 ds에 개별적으로 연결되어 끊김없는 로밍의 아키텍쳐를 정의하는 방법 및 장치
WO2025071186A1 (ko) 무선랜 시스템에서 유형 필드를 기반으로 링크 스위치를 수행하는 방법 및 장치
WO2025151012A1 (ko) 무선랜 시스템에서 로밍을 하는 이유를 기반으로 로밍을 추천하는 ap를 결정 또는 선택하는 방법 및 장치
WO2025071188A1 (ko) 무선랜 시스템에서 유형 필드를 기반으로 mld 로밍을 수행하는 방법 및 장치
WO2025014157A1 (ko) 무선랜 시스템에서 다른 ap에 대한 collocation 여부를 기반으로 mld 로밍을 결정하는 방법 및 장치
WO2025009850A1 (ko) 무선랜 시스템에서 ap 간 끊기지 않는 mld 로밍을 수행하는 방법 및 장치
WO2026049493A1 (ko) 무선랜 시스템에서 serving ap mld가 target ap mld에게 컨텍스트를 전달하는데 사용되는 컨텍스트 전달 프레임을 구성하는 방법 및 장치
WO2026054528A1 (ko) 무선랜 시스템에서 serving ap mld가 대기 중인 dl 데이터를 non-ap sta과 target ap mld에게 전달하는 방법 및 장치

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: 25803795

Country of ref document: EP

Kind code of ref document: A1