Method and apparatus for sharing security key based on multiple access point operation in wireless LAN system

Abstract

A method and an apparatus for sharing a security key based on multiple access point (AP) operations in a wireless LAN system are disclosed. According to one embodiment of the present disclosure, a method performed by means of a first station (STA) in a wireless LAN system may comprise the steps of: the first STA generating a multiple access point group temporary key (MAGTK); and a MAGTK encrypted based on a key shared between the first STA and the one or more second STAs is transmitted to the one or more second STAs. A security key for the third STA is encrypted based on the MAGTK, and may be shared with the first STA and the one or more second STAs.

Description

Technical Field

[0001] The present disclosure relates to a method and apparatus for sharing a security key based on multi - access point (AP) operation in a wireless local area network (WLAN) system. Background Art

[0002] New technologies have been introduced for wireless local area network (WLAN) to improve transmission rate, increase bandwidth, improve reliability, reduce errors, and reduce latency. Among WLAN technologies, the Institute of Electrical and Electronics Engineers (IEEE) 802.11 series standards can be referred to as Wi - Fi. For example, recently introduced technologies to WLAN include very high throughput (VHT) enhancements of the 802.11ac standard and high efficiency (HE) enhancements of the IEEE 802.11ax standard.

[0003] To provide a more advanced wireless communication environment, improved technologies for extremely high throughput (EHT) are being discussed. For example, technologies for MIMO and multi - access point (AP) coordination that support increased bandwidth, efficient utilization of multiple bands, and increased spatial streams are being studied, and specifically, various technologies for supporting low latency or real - time traffic are being studied. In addition, new technologies for supporting ultra - high reliability (UHR), including improvements or extensions of EHT technologies, are being discussed. Summary of the Invention

[0004] Technical Problem

[0005] A technical problem of the present disclosure is to provide a method and apparatus for sharing a security key based on multi - AP operation in a WLAN system.

[0006] An additional technical problem of the present disclosure is to provide a method and apparatus for improving the speed and efficiency of a station (STA) moving between multiple APs based on a security key shared within a multi - AP set in a WLAN system.

[0007] The technical objects to be achieved by the present disclosure are not limited to the above - mentioned technical objects, and other technical objects not described herein will be clearly understood by those skilled in the art from the following description.

[0008] Technical Solution

[0009] A method performed by a first station (STA) in a WLAN system according to an aspect of the present disclosure may include: generating, by the first STA, a multi - access point group temporary key (MAGTK); and sending, to at least one second STA, the MAGTK encrypted based on a key shared between the first STA and the at least one second STA. A security key for a third STA may be encrypted based on the MAGTK and shared with the first STA and the at least one second STA.

[0010] A method performed by a second station (STA) in a WLAN system according to an additional aspect of the present disclosure may include: obtaining a key shared between a first STA and at least one second STA including the second STA; and receiving, from the first STA, a multi-access point group temporal key (MAGTK) encrypted based on the key shared between the first STA and the at least one second STA. The MAGTK may be generated by the first STA, and a security key for a third STA may be encrypted based on the MAGTK and shared with the first STA and the at least one second STA.

[0011] Technical effects

[0012] According to the present disclosure, a method and apparatus for sharing a security key based on multi-AP operation in a WLAN system may be provided.

[0013] According to the present disclosure, a method and apparatus for improving the speed and efficiency of STA movement between multiple APs based on a security key shared within a multi-AP set in a WLAN system may be provided.

[0014] The effects achievable by the present disclosure are not limited to the above effects, and those skilled in the relevant art can clearly understand other effects not described herein through the following description. Brief description of the drawings

[0015] The drawings included as part of the specific embodiments for understanding the present disclosure provide embodiments of the present disclosure and describe the technical features of the present disclosure together with the specific embodiments.

[0016] Figure 1 The configuration block diagram of a wireless communication device according to an embodiment of the present disclosure is illustrated.

[0017] Figure 2 is a diagram illustrating an exemplary structure of a WLAN system to which the present disclosure can be applied.

[0018] Figure 3 is a diagram for explaining a link establishment process to which the present disclosure can be applied.

[0019] Figure 4 is a diagram for explaining a backoff process to which the present disclosure can be applied.

[0020] Figure 5 is a diagram for explaining a CSMA / CA-based frame transmission operation to which the present disclosure can be applied.

[0021] Figure 6 is a diagram for explaining an example of a frame structure used in a WLAN system to which the present disclosure can be applied.

[0022] Figure 7It is a diagram illustrating an example of a PPDU defined in the IEEE 802.11 standard to which the present disclosure can be applied.

[0023] Figure 8 It is a diagram for explaining various transmission or reception techniques in a MAP environment to which the present disclosure can be applied.

[0024] Figure 9 It is a diagram for explaining the four-way handshake process to which the present disclosure can be applied.

[0025] Figure 10 It is a diagram for explaining BSS transition in an existing WLAN system.

[0026] Figure 11 It is a diagram for explaining the operation of a first STA according to the present disclosure.

[0027] Figure 12 It is a diagram for explaining the operation of a second STA according to the present disclosure.

[0028] Figure 13 It is a diagram showing an example of a security key sharing range according to the present disclosure.

[0029] Figure 14 It is a diagram for explaining an example of a MAGTK shared within a MAP according to the present disclosure.

[0030] Figure 15 It is a diagram showing an example of an element including a MAGTK according to the present disclosure.

[0031] Figure 16 It is a diagram showing an example of a security key sharing operation according to the present disclosure.

[0032] Figure 17 It is a diagram showing another example of a security key sharing operation according to the present disclosure.

[0033] Figure 18 It is a diagram showing another example of a security key sharing operation according to the present disclosure. Detailed Description of the Invention

[0034] Hereinafter, embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings. The detailed description disclosed through the drawings is to describe exemplary embodiments of the present disclosure, not to represent the only embodiments in which the present disclosure can be implemented. The following detailed description includes specific details to provide a complete understanding of the present disclosure. However, those skilled in the relevant art know that the present disclosure can be implemented without these specific details.

[0035] In some cases, known structures and devices may be omitted, or may be shown in block diagram form based on the core functions of each structure and device to prevent ambiguity in the concepts of the present disclosure.

[0036] In the present disclosure, when an element is referred to as being "connected", "combined" or "linked" to another element, it may include both indirect connection relationships and direct connection relationships in which yet another element exists therebetween. Further, in the present disclosure, the terms "comprising" or "having" specify the presence of the recited features, steps, operations, components, and / or elements, but do not preclude the presence or addition of one or more other features, stages, operations, components, elements, and / or groups thereof.

[0037] In the present disclosure, terms such as "first", "second", etc. are used only to distinguish one element from another and do not limit the element, unless otherwise stated, and do not limit the order or importance, etc. between the elements. Thus, within the scope of the present disclosure, the first element in one embodiment may be referred to as the second element in another embodiment, and likewise, the second element in one embodiment may be referred to as the first element in another embodiment.

[0038] The terms used in the present disclosure are for the purpose of describing particular embodiments and are not intended to limit the claims. As used in the description of the embodiments and the appended claims, the singular forms are intended to include the plural forms unless the context clearly dictates otherwise. The term "and / or" as used in the present disclosure may refer to one of the related listed items, or may mean that it refers to and includes any and all possible combinations of two or more of them. Further, unless otherwise stated, " / " between words in the present disclosure has the same meaning as "and / or".

[0039] Examples of the present disclosure can be applied to various wireless communication systems. For example, examples of the present disclosure can be applied to a wireless LAN system. For example, examples of the present disclosure can be applied to a wireless LAN based on the IEEE 802.11a / g / n / ac / ax standards. Further, examples of the present disclosure can be applied to a wireless LAN based on the newly proposed IEEE 802.11be (or EHT) standard. Examples of the present disclosure can be applied to a wireless LAN based on the IEEE802.11be version 2 standard corresponding to additional enhancement technologies for the IEEE 802.11be version 1 standard. Additionally, examples of the present disclosure can be applied to a wireless LAN based on a next-generation standard after IEEE 802.11be. Further, examples of the present disclosure can be applied to a cellular wireless communication system. For example, it can be applied to a cellular wireless communication system based on the Long-Term Evolution (LTE) technology and the 5G New Radio (NR) technology based on the Third Generation Partnership Project (3GPP) standards.

[0040] In the following, the technical features of examples to which the present disclosure can be applied will be described.

[0041] Figure 1 A block diagram of a wireless communication device according to an embodiment of the present disclosure is illustrated.

[0042] Figure 1 The first device 100 and the second device 200 illustrated in can be replaced with various terms such as a terminal, a wireless device, a wireless transmit / receive unit (WTRU), a user equipment (UE), a mobile station (MS), a user terminal (UT), a mobile subscriber station (MSS), a mobile subscriber unit (MSU), a subscriber station (SS), an advanced mobile station (AMS), a wireless terminal (WT), or simply a user. Additionally, the first device 100 and the second device 200 include an access point (AP), a base station (BS), a fixed station, a Node B, a base transceiver system (BTS), a network. It can be replaced with various terms such as an artificial intelligence (AI) system, a roadside unit (RSU), a repeater, a router, a relay, and a gateway.

[0043] Figure 1 The devices 100 and 200 illustrated in can be referred to as a station (STA). For example, Figure 1 The devices 100 and 200 illustrated in can be referred to by various terms such as a transmitting device, a receiving device, a transmitting STA, and a receiving STA. For example, STAs 110 and 200 can perform an access point (AP) role or a non-AP role. That is, in the present disclosure, STAs 110 and 200 can perform AP and / or non-AP functions. When STAs 110 and 200 perform the AP function, they can be simply referred to as an AP, and when STAs 110 and 200 perform the non-AP function, they can be simply referred to as an STA. Additionally, in the present disclosure, an AP can also be indicated as an AP STA.

[0044] Referring to Figure 1 , the first device 100 and the second device 200 can transmit and receive radio signals through various wireless LAN technologies (e.g., the IEEE 802.11 series). The first device 100 and the second device 200 can include interfaces for a media access control (MAC) layer and a physical layer (PHY) compliant with the IEEE 802.11 standard.

[0045] In addition to the wireless LAN technology, the first device 100 and the second device 200 may additionally support various communication standards (e.g., 3GPP LTE series, 5G NR series standards, etc.). Additionally, the devices of the present disclosure may be implemented in various devices such as mobile phones, vehicles, personal computers, augmented reality (AR) devices, and virtual reality (VR) devices. Additionally, the STA of this specification may support various communication services such as voice calls, video calls, data communication, autonomous driving, machine type communication (MTC), machine-to-machine (M2M), device-to-device (D2D), Internet of Things (IoT), etc.

[0046] The first device 100 may include one or more processors 102 and one or more memories 104, and may additionally include one or more transceivers 106 and / or one or more antennas 108. The processor 102 may control the memory 104 and / or the transceiver 106, and may be configured to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts included in the present disclosure. For example, after generating first information / signals by processing the information in the memory 104, the processor 102 may send a wireless signal including the first information / signals through the transceiver 106. Additionally, the processor 102 may receive a wireless signal including second information / signals through the transceiver 106, and then store the information obtained by signal processing of the second information / signals in the memory 104. The memory 104 may be connected to the processor 102 and may store various information related to the operation of the processor 102. For example, the memory 104 may store software codes including instructions for performing all or part of the processing controlled by the processor 102 or for performing the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts included in the present disclosure. Here, the processor 102 and the memory 104 may be part of a communication modem / circuit / chip designed to implement wireless LAN technology (e.g., IEEE 802.11 series). The transceiver 106 may be connected to the processor 102 and may send and / or receive wireless signals through one or more antennas 108. The transceiver 106 may include a transmitter and / or a receiver. The transceiver 106 may be used with an RF (radio frequency) unit. In the present disclosure, a wireless device may refer to a communication modem / circuit / chip.

[0047] The second device 200 may include one or more processors 202 and one or more memories 204, and may additionally include one or more transceivers 206 and / or one or more antennas 208. The processor 202 may control the memory 204 and / or the transceiver 206, and may be configured to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts included in the present disclosure. For example, the processor 202 may generate third information / signals by processing the information in the memory 204, and then transmit wireless signals including the third information / signals through the transceiver 206. Additionally, the processor 202 may receive wireless signals including fourth information / signals through the transceiver 206, and then store the information obtained by signal processing of the fourth information / signals in the memory 204. The memory 204 may be connected to the processor 202 and may store various information related to the operation of the processor 202. For example, the memory 204 may store software codes including instructions for performing all or part of the processing controlled by the processor 202 or for performing the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts included in the present disclosure. Here, the processor 202 and the memory 204 may be part of a communication modem / circuit / chip designed to implement wireless LAN technologies (e.g., the IEEE 802.11 series). The transceiver 206 may be connected to the processor 202 and may transmit and / or receive wireless signals through one or more antennas 208. The transceiver 206 may include a transmitter and / or a receiver. The transceiver 206 may be used with an RF unit. In the present disclosure, a device may mean a communication modem / circuit / chip.

[0048] Hereinafter, the hardware components of apparatuses 100 and 200 will be described in more detail. Without being limited thereto, one or more protocol layers may be implemented by one or more processors 102 and 202. For example, one or more processors 102 and 202 may implement one or more layers (e.g., functional layers such as PHY and MAC). One or more processors 102 and 202 may generate one or more PDUs (Protocol Data Units) and / or one or more SDUs (Service Data Units) according to the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts disclosed in the present disclosure. One or more processors 102 and 202 may generate messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts disclosed in the present disclosure. One or more processors 102 and 202 may generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data, or information according to the functions, procedures, suggestions, and / or methods disclosed in the present disclosure to provide them to one or more transceivers 106 and 206. One or more processors 102 and 202 may receive signals (e.g., baseband signals) from one or more transceivers 106 and 206 according to the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts included in the present disclosure, and obtain PDUs, SDUs, messages, control information, data, or information.

[0049] One or more processors 102 and 202 may be referred to as a controller, a microcontroller, a microprocessor, or a microcomputer. One or more processors 102 and 202 may be implemented by hardware, firmware, software, or a combination thereof. For example, one or more ASICs (Application Specific Integrated Circuits), one or more DSPs (Digital Signal Processors), one or more DSPDs (Digital Signal Processor Devices), one or more PLDs (Programmable Logic Devices), or one or more FPGAs (Field Programmable Gate Arrays) may be included in one or more processors 102 and 202. The descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts included in the present disclosure may be implemented by using firmware or software, and the firmware or software may be implemented to include modules, procedures, functions, etc. The firmware or software configured to execute the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts included in the present disclosure may be included in one or more processors 102 and 202, or may be stored in one or more memories 104 and 204 and driven by one or more processors 102 and 202. The descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts included in the present disclosure may be implemented by using firmware or software in the form of codes, instructions, and / or instruction sets.

[0050] One or more memories 104, 204 may be connected to one or more processors 102, 202 and may store data, signals, messages, information, programs, code, instructions, and / or commands in various forms. One or more memories 104, 204 may be configured with ROM, RAM, EPROM, flash memory, hard disk drives, registers, cache memories, computer-readable storage media, and / or combinations thereof. One or more memories 104, 204 may be located inside and / or outside one or more processors 102, 202. Additionally, one or more memories 104, 204 may be connected to one or more processors 102, 202 through various techniques such as wired or wireless connections.

[0051] One or more transceivers 106, 206 may send user data, control information, wireless signals / channels, etc. mentioned in the methods and / or operation flowcharts, etc. of the present disclosure to one or more other devices. One or more transceivers 106, 206 may receive user data, control information, wireless signals / channels, etc. mentioned in the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts, etc. included in the present disclosure from one or more other devices. For example, one or more transceivers 106, 206 may be connected to one or more processors 102, 202 and may send and receive wireless signals. For example, one or more processors 102, 202 may control one or more transceivers 106, 206 to send user data, control information, or wireless signals to one or more other devices. Additionally, one or more processors 102, 202 may control one or more transceivers 106, 206 to receive user data, control information, or wireless signals from one or more other devices. Additionally, one or more transceivers 106, 206 may be connected to one or more antennas 108, 208, and one or more transceivers 106, 206 may be configured to send and receive user data, control information, wireless signals / channels, etc. mentioned in the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts, etc. included in the present disclosure through one or more antennas 108, 208. In the present disclosure, one or more antennas may be multiple physical antennas or multiple logical antennas (e.g., antenna ports). One or more transceivers 106, 206 may convert the received wireless signals / channels, etc. from RF band signals into baseband signals to process the received user data, control information, wireless signals / channels, etc. by using one or more processors 102, 202. One or more transceivers 106, 206 may convert the user data, control information, wireless signals / channels, etc. processed by using one or more processors 102, 202 from baseband signals into RF band signals. Thus, one or more transceivers 106, 206 may include (analog) oscillators and / or filters.

[0052] For example, one of STAs 100 and 200 may perform the expected operations of an AP, and the other of STAs 100 and 200 may perform the expected operations of a non-AP STA. For example, Figure 1 the transceivers 106 and 206 may perform the sending and receiving operations of signals (e.g., packets or physical layer protocol data units (PPDUs) compliant with IEEE 802.11a / b / g / n / ac / ax / be / bn). Additionally, in the present disclosure, the operations of various STAs to generate transmit / receive signals or to perform data processing or calculations on the transmit / receive signals in advance may be performed by Figure 1are executed by processors 102 and 202. For example, examples of operations for generating transmission / reception signals or performing data processing or calculations on transmission / reception signals in advance may include: 1) determining / acquiring / configuring / calculating / decoding / encoding bit information of fields (signals (SIG), short training fields (STF), long training fields (LTF), data, etc.) included in a PPDU; 2) determining / configuring / acquiring time resources or frequency resources (e.g., subcarrier resources) for fields (SIG, STF, LTF, data, etc.) included in a PPDU; 3) determining / configuring / acquiring a specific sequence (e.g., pilot sequence, STF / LTF sequence, additional sequence applied to SIG) for fields (SIG, STF, LTF, data, etc.) included in a PPDU operation; 4) power control operations and / or power saving operations applied to a STA; 5) operations related to ACK signal determination / acquisition / configuring / calculating / decoding / encoding, etc. Additionally, in the following examples, various information (e.g., information related to fields / sub-fields / control fields / parameters / power, etc.) used by various STAs to determine / acquire / configure / calculate / decode / encode transmission signals and reception signals may be stored in Figure 1 memories 104 and 204.

[0053] Hereinafter, a downlink (DL) may refer to a link for communication from an AP STA to a non-AP STA, and DL PPDUs / packets / signals may be transmitted and received through the DL. In DL communication, the transmitter may be part of the AP STA, and the receiver may be part of the non-AP STA. An uplink (UL) may refer to a link for communication from a non-AP STA to an AP STA, and UL PPDUs / packets / signals may be transmitted and received through the UL. In UL communication, the transmitter may be part of the non-AP STA, and the receiver may be part of the AP STA.

[0054] Figure 2 is a diagram illustrating an exemplary structure of a wireless LAN system to which the present disclosure may be applied.

[0055] The structure of a wireless LAN system may be composed of multiple components. A wireless LAN that supports STA mobility transparent to the upper layer may be provided through the interaction of multiple components. A basic service set (BSS) corresponds to the basic building block of a wireless LAN. Figure 2 Exemplarily, it is shown that there are two BSSs (BSS1 and BSS2), and two STAs included as members of each BSS (STA1 and STA2 are included in BSS1, and STA3 and STA4 are included in BSS2). Figure 2The ellipse representing the BSS can also be understood as representing the coverage area where the STAs included in the corresponding BSS maintain communication. This area can be referred to as the Basic Service Area (BSA). When an STA moves outside the BSA, it cannot communicate directly with other STAs within the BSA.

[0056] If the DS shown in Figure 2 is not considered, the most basic BSS type in a wireless LAN is the Independent BSS (IBSS). For example, an IBSS can have a minimum form that only includes two STAs. For example, assuming other components are omitted, BSS1 that only includes STA1 and STA2 or BSS2 that only includes STA3 and STA4 can respectively correspond to representative examples of an IBSS. This configuration is possible when STAs can communicate directly without an AP. Additionally, in this type of wireless LAN, it is not pre-configured but can be configured when a LAN is needed, and this can be referred to as an ad-hoc network. Since an IBSS does not include an AP, there is no centralized management entity. That is to say, in an IBSS, STAs are managed in a distributed manner. In an IBSS, all STAs can consist of mobile STAs and are not allowed to access the Distributed System (DS), thus forming a self-contained network.

[0057] The membership of STAs in a BSS can be dynamically changed by turning on or off STAs, entering or exiting the BSS area, etc. To become a member of a BSS, an STA can use synchronization processing to join the BSS. To access all services of the BSS infrastructure, an STA should be associated with the BSS. This association can be dynamically established and can include using the Distribution System Service (DSS).

[0058] The direct STA-to-STA distance in a wireless LAN may be limited by the PHY performance. In some cases, this distance limitation may be sufficient, but in some cases, communication between STAs at longer distances may be required. The Distributed System (DS) can be configured to support extended coverage.

[0059] DS means the structure for interconnecting BSSs. Specifically, as Figure 2As shown, the BSS can exist as an extended form of a network composed of multiple BSSs. The DS is a logical concept and can be specified by the characteristics of the distributed system medium (DSM). In this regard, the wireless medium (WM) and the DSM can be logically separated. Each logical medium is used for different purposes and is used by different components. These media are not limited to being the same, nor are they limited to being different. In this way, the flexibility of the wireless LAN structure (DS structure or other network structures) can be interpreted as multiple media being logically different. That is, the wireless LAN structure can be implemented in various ways, and the corresponding wireless LAN structure can be independently specified by the physical characteristics of each implementation.

[0060] The DS can support mobile devices by providing seamless integration of multiple BSSs and providing the logical services necessary for addressing the addresses to the destination. Additionally, the DS can also include a component called a portal, which is used as a bridge for the connection between the wireless LAN and other networks (e.g., IEEE 802.X).

[0061] The AP enables access to the DS through the WM for the associated non-AP STA and refers to an entity that also has the STA function. The data movement between the BSS and the DS can be performed by the AP. For example, Figure 2 STA2 and STA3 shown in have the function of an STA and provide the function of allowing the associated non-AP STAs (STA1 and STA4) to access the DS. Additionally, since all APs basically correspond to STAs, all APs are addressable entities. The address used by the AP for communication on the WM is not necessarily the same as the address used by the AP for communication on the DSM. The BSS composed of an AP and one or more STAs can be called an infrastructure BSS.

[0062] Data sent from one of the STAs associated with the AP to the STA address of the corresponding AP can always be received at the uncontrolled port and can be processed by the IEEE 802.1X port access entity. Additionally, when the controlled port is authenticated, the sent data (or frame) can be delivered to the DS.

[0063] In addition to the above DS structure, the extended service set (ESS) can also be configured to provide wide coverage.

[0064] An ESS refers to a network consisting of a DS and BSSs, with an arbitrary size and complexity. An ESS can correspond to a set of BSSs connected to a DS. However, an ESS does not include the DS. The ESS network is characterized by an IBSS in the logical link control (LLC) layer. STAs included in an ESS can communicate with each other, and a mobile STA can move from one BSS to another (within the same ESS) transparently to the LLC. APs included in an ESS can have the same service set identifier (SSID). The SSID is distinguished from the BSSID, which is the identifier of a BSS.

[0065] The wireless LAN system does not assume anything about the relative physical positions of BSSs, and all of the following forms are possible. BSSs can partially overlap, which is a form commonly used to provide continuous coverage. Additionally, BSSs can be not physically connected, and logically, there is no limit to the distance between BSSs. Additionally, BSSs can be physically located at the same position, which can be used to provide redundancy. Additionally, one (or more than one) IBSS or ESS network can physically exist in the same space as one (or more than one) ESS network. This can correspond to forms of an ESS network when an ad-hoc network operates in the location where an ESS network exists, when physically overlapping wireless networks are configured by different organizations, or when two or more different access and security policies are required at the same position.

[0066] Figure 3 is a diagram for explaining the link establishment process to which the present disclosure can be applied.

[0067] In order for an STA to establish a link with a network and send / receive data, it first discovers the network, performs authentication, establishes an association, and an authentication process is required for security. The link establishment process can also be referred to as a session initiation process or a session establishment process. Additionally, the processes of discovery, authentication, association, and security establishment in the link establishment process can be collectively referred to as an association process.

[0068] In step S310, the STA can perform a network discovery operation. The network discovery operation can include a scanning operation of the STA. That is, in order for the STA to access a network, it needs to find a network it can participate in. The STA should identify compatible networks before participating in a wireless network, and the process of identifying the networks existing in a specific area is called scanning.

[0069] Scanning schemes include active scanning and passive scanning. Figure 3A network discovery operation including an active scanning process is exemplarily illustrated. In active scanning, the STA performing the scan sends a probe request frame to discover which APs exist around it while moving across channels and waits for a response thereto. The responder sends a probe response frame as a response to the probe request frame to the STA that has sent the probe request frame. Here, the responder can be the STA that last sent a beacon frame in the BSS of the channel being scanned. In a BSS, since the AP sends a beacon frame, the AP becomes the responder, and in an IBSS, the STAs in the IBSS rotate to send beacon frames, so the responder is not constant. For example, the STA that sends a probe request frame on channel 1 and receives a probe response frame on channel 1 can store the BSS-related information included in the received probe response frame, and can move to the next channel (e.g., channel 2), and perform the scan in the same way (i.e., send and receive probe requests / responses on channel 2).

[0070] Although not shown in Figure 3 it, the scan operation can be performed in a passive scanning manner. In passive scanning, the STA performing the scan waits for beacon frames while moving across channels. A beacon frame is one of the management frames defined in IEEE 802.11 and is sent periodically to notify the existence of a wireless network and to allow the STA performing the scan to find the wireless network and participate in the wireless network. In a BSS, the AP is used to send beacon frames periodically, and in an IBSS, the STAs within the IBSS rotate to send beacon frames. When the STA performing the scan receives a beacon frame, the STA stores the information of the BSS included in the beacon frame, and while moving to another channel, records the beacon frame information in each channel. The 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 the scan in the next channel in the same way. Comparing active scanning with passive scanning, the advantage of active scanning is that it has less latency and less power consumption than passive scanning.

[0071] After the STA discovers the network, the authentication process can be performed in step S320. To clearly distinguish it from the security establishment operation in step S340 to be described later, this authentication process can be referred to as the first authentication process.

[0072] The authentication process includes the following process: The STA sends an authentication request frame to the AP, and in response thereto, the AP sends an authentication response frame to the STA. The authentication frame for authentication request / response corresponds to a management frame.

[0073] The authentication frame includes an authentication algorithm number, an authentication transaction sequence number, a status code, a challenge text, a Robust Security Network (RSN), a finite cyclic group, etc. This corresponds to some examples of information that can be included in the authentication request / response frame, and can be replaced with other information, or additional information can also be included.

[0074] The STA can send an authentication request frame to the AP. The AP can determine whether to allow the authentication of the corresponding STA based on the information included in the received authentication request frame. The AP can provide the result of the authentication process to the STA through an authentication response frame.

[0075] After the STA is successfully authenticated, the association process can be performed in step S330. The association process includes the following processes: The STA sends an association request frame to the AP, and in response, the AP sends an association response frame to the STA.

[0076] For example, the association request frame can include information related to various capabilities, a beacon listening interval, a Service Set Identifier (SSID), supported rates, supported channels, RSN, a mobility domain, supported operation classes, a Traffic Indication Map Broadcast Request (TIM broadcast request), interoperability service capabilities, etc. For example, the association response frame can include information related to various capabilities, a status code, an Association ID (AID), supported rates, an Enhanced Distributed Channel Access (EDCA) parameter set, a Received Channel Power Indicator (RCPI), a Received Signal-to-Noise Ratio Indicator (RSNI), a mobility domain, a timeout interval (e.g., an association recovery time), overlapping BSS scan parameters, a TIM broadcast response, Quality of Service (QoS) mapping, etc. This corresponds to some examples of information that can be included in the association request / response frame, and can be replaced with other information, or additional information can also be included.

[0077] After the STA is successfully associated with the network, the security establishment process can be performed in step S340. The security establishment process in step S340 can be referred to as an authentication process through a Robust Security Network Association (RSNA) request / response. The authentication process in step S320 is referred to as the first authentication process, and the security establishment process in step S340 can also be simply referred to as an authentication process.

[0078] The security establishment process in step S340 can include, for example, a process of establishing a private key using the Extensible Authentication Protocol over LAN (EAPOL) frame through a four-way handshake. Additionally, the security establishment process can be performed according to a security scheme not defined in the IEEE 802.11 standard.

[0079] Figure 4 It is a diagram for explaining the backoff process to which the present disclosure can be applied.

[0080] In a wireless LAN system, the basic access mechanism of the Media Access Control (MAC) is the Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) mechanism. The CSMA / CA mechanism is also known as the Distributed Coordination Function (DCF) of the IEEE 802.11 MAC and basically adopts a "listen before talk" access mechanism. According to this type of access mechanism, before starting to transmit, the AP and / or STA can perform a Clear Channel Assessment (CCA) of sensing the radio channel or medium during a predetermined time interval (e.g., DCF Interframe Space (DIFS)). As a result of the sensing, if it is determined that the medium is idle, frame transmission is started through the corresponding medium. On the other hand, if the medium is detected to be occupied or busy, the corresponding AP and / or STA does not start its own transmission and can set a delay period for medium access (e.g., random backoff period) and attempt frame transmission after waiting. By applying the random backoff period, since it is expected that multiple STAs will attempt frame transmission after waiting for different time periods, collisions can be minimized.

[0081] In addition, the IEEE 802.11 MAC protocol provides a Hybrid Coordination Function (HCF). The HCF is based on the DCF and the Point Coordination Function (PCF). The PCF is a polling-based synchronous access method and refers to a method in which all receiving APs and / or STAs are periodically polled to receive data frames. In addition, the HCF has Enhanced Distributed Channel Access (EDCA) and HCF Control Channel Access (HCCA). The EDCA is a contention-based access method that provides data frames for multiple users in a direction, and the HCCA uses a contention-free channel access method that utilizes a polling mechanism. In addition, the HCF includes a medium access mechanism for improving the Quality of Service (QoS) of the wireless LAN and can transmit QoS data during the Contention Period (CP) and the Contention-Free Period (CFP).

[0082] Refer to Figure 4, operations based on a random backoff period will be described. When the occupied / busy medium becomes idle, multiple STAs can attempt to send data (or frames). As a method to minimize collisions, each of the STAs can separately select a random backoff count and attempt to send after waiting for the corresponding slot time. The random backoff count has a pseudo-random integer value and can be determined as one of the values that vary from 0 to the value of CW. Here, CW is the contention window parameter value. The CW parameter is given the initial value of CWmin, but can take a value twice as large in the case of a transmission failure (e.g., when an ACK for the transmitted frame is not received). When the CW parameter value reaches CWmax, data transmission can be attempted while maintaining the CWmax value until the data transmission is successful, and when the data transmission is successful, the CWmin value is reset. The values of CW, CWmin, and CWmax are preferably set to 2n - 1 (n = 0, 1, 2,...).

[0083] When the random backoff process starts, the STA continuously monitors the medium during the countdown of the backoff slot according to the determined backoff count value. When monitoring the medium for occupancy, it stops the countdown and waits, and when the medium becomes idle, it resumes the remaining part of the countdown.

[0084] In Figure 4 the example, when the packet to be sent arrives at the MAC of STA 3, STA3 can send the frame immediately after confirming that the medium has been idle for up to DIFS. The remaining STAs monitor and wait for the medium to be occupied / busy. At the same time, the data to be sent can also occur in each of STA1, STA2, and STA5, and when the medium is monitored as idle, each STA waits for up to DIFS and then can perform the countdown of the backoff slot according to the random backoff count value selected by each STA. Assume that STA2 selects the minimum backoff count value and STA1 selects the maximum backoff count value. That is, an example is shown where the remaining backoff time of STA5 is shorter than the remaining backoff time of STA1 when STA2 finishes the backoff count and starts frame transmission. STA1 and STA5 temporarily stop the countdown and wait while STA2 occupies the medium. When the occupancy of STA2 ends and the medium becomes idle again, STA1 and STA5 wait for DIFS and resume the stopped backoff count. That is, frame transmission can start after counting down the remaining backoff slots for the remaining backoff time. Since the remaining backoff time of STA5 is shorter than the remaining backoff time of STA1, STA5 starts frame transmission. While STA2 occupies the medium, the data to be sent can also occur in STA4. From the perspective of STA4, when the medium becomes idle, STA4 can wait for DIFS and then can perform the countdown according to the random backoff count value selected by STA4 and start sending the frame. Figure 4The example shows a situation where the remaining backoff time of STA5 accidentally conflicts with the random backoff counter value of STA4. In this case, a conflict may occur between STA4 and STA5. When a conflict occurs, neither STA4 nor STA5 receives an ACK, so the data transmission fails. In this case, STA4 and STA5 can double the CW value, select a random backoff counter value, and perform a countdown. When the medium is occupied due to the transmissions of STA4 and STA5, STA1 waits. When the medium becomes idle, STA1 waits for the DIFS and then starts frame transmission after the remaining backoff time has elapsed.

[0085] As in Figure 4 the example, a data frame is a frame for transmitting data forwarded to a higher layer and can be transmitted after a backoff executed after the medium has become idle and after DIFS has elapsed. Additionally, a management frame is a frame for exchanging management information that is not forwarded to a higher layer and is transmitted after a backoff executed after an IFS such as DIFS or Point Coordination Function IFS (PIFS). As subtype frames of the management frame, there are beacons, association requests / responses, re-association requests / responses, probe requests / responses, authentication requests / responses, etc. A control frame is a frame for controlling access to the medium. As subtype frames of the control frame, there are Request to Send (RTS), Clear to Send (CTS), Acknowledgment (ACK), Power Save Poll (PS-Poll), Block Ack (BlockAck), Block ACK Request (BlockACKReq), Null Data Packet Announcement (NDP Announcement), and Trigger, etc. If a control frame is not a response frame to a previous frame, it is sent after a backoff executed after DIFS has elapsed, and if it is a response frame to a previous frame, it is sent without a backoff after Short IFS (SIFS) has elapsed. The type and subtype of a frame can be identified by the type field and subtype field in the Frame Control (FC) field.

[0086] A Quality of Service (QoS) STA can perform a backoff executed after the Arbitration IFS (AIFS) for the access category (AC) to which the frame belongs (i.e., AIFS (where i is a value determined by the AC)) and then can send the frame. Here, frames for which AIFS can be used can be data frames, management frames, or control frames other than response frames.

[0087] Figure 5 is a diagram for explaining the CSMA / CA-based frame transmission operation to which the present disclosure can be applied.

[0088] As described above, in addition to the physical carrier sensing by the STA directly sensing the medium, the CSMA / CA mechanism also includes virtual carrier sensing. Virtual carrier sensing aims to compensate for problems such as the hidden node problem that may occur in medium access. For virtual carrier sensing, the MAC of the STA can use the Network Allocation Vector (NAV). The NAV is a value that indicates to other STAs the remaining time until the medium is available for the current STA using it or the STA authorized to use the medium. Therefore, the value set as the NAV corresponds to the period during which the STA transmitting the frame plans to use the medium, and during the corresponding period, the STA receiving the NAV value is prohibited from accessing the medium. For example, the NAV can be configured based on the value of the "Duration" field in the MAC header of the frame.

[0089] In Figure 5 the example, it is assumed that STA1 aims to send data to STA2, and STA3 is in a position where it can overhear some or all of the frames transmitted and received between STA1 and STA2.

[0090] To reduce the possibility of transmission conflicts among multiple STAs in the CSMA / CA-based frame transmission operation, a mechanism using RTS / CTS frames can be applied. In Figure 5 the example, when the transmission of STA1 is being executed, as a result of the carrier sensing of STA3, it can be determined that the medium is in an idle state. That is, STA1 can correspond to a hidden node with respect to STA3. Alternatively, in Figure 5 the example, it can be determined that when the transmission of STA2 is being executed, the carrier sensing result of STA3 indicates that the medium is in an idle state. That is, STA2 can correspond to a hidden node with respect to STA3. By exchanging RTS / CTS frames before performing data transmission and reception between STA1 and STA2, STAs outside the transmission range of either STA1 or STA2 or STAs outside the carrier sensing range of the transmission from STA1 or STA3 can refrain from attempting to occupy the channel during the data transmission and reception between STA1 and STA2.

[0091] Specifically, STA1 can determine whether the channel is being used through carrier sensing. In terms of physical carrier sensing, STA1 can determine the occupied or idle state of the channel based on the energy level detected in the channel or signal correlation. Additionally, in terms of virtual carrier sensing, STA1 can use the Network Allocation Vector (NAV) timer to determine the channel occupancy state.

[0092] When the channel is in an idle state during DIFS, STA1 can send an RTS frame to STA2 after performing backoff. When STA2 receives the RTS frame, STA2 can send a CTS frame to STA1 as a response to the RTS frame after SIFS.

[0093] If STA3 cannot overhear the CTS frame from STA2 but can overhear the RTS frame from STA1, STA3 can use the duration information included in the RTS frame to set the NAV timer for the transmission period of the frames continuously transmitted thereafter (e.g., SIFS + CTS frame + SIFS + data frame + SIFS + ACK frame). Alternatively, if STA3 can overhear the CTS frame from STA2, even though STA3 cannot overhear the RTS frame from STA1, STA3 can also use the duration information included in the CTS frame to set the NAV timer for the transmission period of the frames continuously transmitted thereafter (e.g., SIFS + data frame + SIFS + ACK frame). That is, if STA3 can overhear one or more of the RTS frames or CTS frames from one or more of STA1 or STA2, STA3 can set the NAV accordingly. When STA3 receives a new frame before the expiration of the NAV timer, STA3 can use the duration information included in the new frame to update the NAV timer. STA3 does not attempt channel access until the NAV timer expires.

[0094] When STA1 receives a CTS frame from STA2, STA1 can send a data frame to STA2 after SIFS from the time point when the reception of the CTS frame is completed. When STA2 successfully receives the data frame, STA2 can send an ACK frame to STA1 after SIFS as a response to the data frame. When the NAV timer expires, STA3 can determine whether the channel is being used through carrier sensing. When STA3 determines during the DIFS period after the expiration of the NAV timer that the channel is not being used by other terminals, STA3 can attempt channel access after the contention window (CW) based on random backoff has elapsed.

[0095] Figure 6 It is a diagram for illustrating an example of the frame structure used in a WLAN system to which the present disclosure can be applied.

[0096] With instructions or primitives (meaning a set of instructions or parameters) from the MAC layer, the PHY layer can prepare the MAC PDU (MPDU) to be transmitted. For example, when receiving a command from the MAC layer to start transmission from the PHY layer, the PHY layer switches to the transmission mode, configures the information (e.g., data) provided from the MAC layer in the form of a frame, and transmits it. In addition, when the PHY layer detects a valid preamble of the received frame, the PHY layer monitors the header of the preamble and sends a command to the MAC layer notifying the start of reception by the PHY layer.

[0097] In this way, information transmission / reception in a wireless LAN system is performed in the form of frames, and for this purpose, the PHY layer protocol data unit (PPDU) format is defined.

[0098] The basic PPDU may include a Short Training Field (STF), a Long Training Field (LTF), a Signal (SIG) field, and a Data field. The most basic PPDU format (e.g., the non-HT (High Throughput) shown in Figure 7 may consist only of a Legacy-STF (L-STF), a Legacy-LTF (L-LTF), a Legacy-SIG (L-SIG) field, and a Data field. Additionally, depending on the type of PPDU format (e.g., HT Mixed format PPDU, HT Greenfield format PPDU, VHT (Very High Throughput) PPDU, etc.), additional (or different types of) RL-SIG, U-SIG, non-legacy SIG fields, non-legacy STF, non-legacy LTF (i.e., xx-SIG, xx-STF, xx-LTF (e.g., xx is HT, VHT, HE, EHT, etc.)) etc. may be included between the L-SIG field and the Data field.

[0099] The STF is a signal for signal detection, automatic gain control (AGC), diversity selection, precise time synchronization, etc., and the LTF is a signal for channel estimation and frequency error estimation. The STF and LTF can be referred to as signals for synchronization and channel estimation of the OFDM physical layer.

[0100] The SIG field may include various information related to PPDU transmission and reception. For example, the L-SIG field consists of 24 bits, and the L-SIG field may include a 4-bit Rate field, a 1-bit Reserved bit, a 12-bit Length field, a 1-bit Parity field, and a 6-bit Tail field. The RATE field may include information about the modulation and coding rate of the data. For example, the 12-bit Length field may include information about the length or duration of the PPDU. For example, the value of the 12-bit Length field may be determined based on the type of PPDU. For example, for non-HT, HT, VHT, or EHT PPDUs, the value of the Length field may be determined to be a multiple of 3. For example, for HE PPDUs, the value of the Length field may be determined to be a multiple of 3 + 1 or 3 + 2.

[0101] The data field may include a SERVICE field, a Physical Layer Service Data Unit (PSDU), and PPDU tail bits, and may also include padding bits if necessary. Some bits of the SERVICE field may be used for synchronization of the descrambler at the receiving end. The PSDU corresponds to the MAC PDU defined in the MAC layer and may include data generated / used in the upper layer. The PPDU tail bits may be used to return the encoder to the 0 state. The padding bits may be used to adjust the length of the data field in predetermined units.

[0102] The MAC PDU is defined according to various MAC frame formats, and the basic MAC frame consists of a MAC header, a frame body, and a Frame Check Sequence (FCS). The MAC frame may be composed of MAC PDUs and transmitted / received through the PSDU of the data part in the PPDU format.

[0103] The MAC header includes a Frame Control field, a Duration / ID field, an Address field, etc. The Frame Control field may include control information required for frame transmission / reception. The Duration / ID field may be set to the time for transmitting the corresponding frame, etc. For details of the Sequence Control, QoS Control, and HT Control sub-fields of the MAC header, refer to the IEEE 802.11 standard document.

[0104] The Null Data PPDU (NDP) format refers to the PPDU format that does not include a data field. In other words, the NDP refers to a frame format that includes the PPDU preamble of the general PPDU format (i.e., the L-STF, L-LTF, L-SIG fields, and additional non-conventional SIG, non-conventional STF, non-conventional LTF (if any)) and does not include the remaining part (i.e., the data field).

[0105] Figure 7 FIG. is an example of the PPDU defined in the IEEE 802.11 standard to which the present disclosure can be applied.

[0106] In standards such as IEEE 802.11a / g / n / ac / ax, various types of PPDUs have been used. The basic PPDU format (IEEE 802.11a / g) includes L-LTF, L-STF, L-SIG, and a data field. The basic PPDU format may also be referred to as the non-HT PPDU format (as shown in (a) of Figure 7 .

[0107] Compared with the basic PPDU format, the HT PPDU format (IEEE 802.11n) additionally includes HT-SIG, HT-STF, and HT-LFT fields. Figure 7The HT PPDU format shown in (b) can be referred to as the HT mixed format. In addition, an HT greenfield format PPDU can be defined, and this corresponds to a format (not shown) consisting of an HT-GF-STF, HT-LTF1, HT-SIG, one or more HT-LTFs, and a data field, excluding the L-STF, L-LTF, and L-SIG.

[0108] Compared to the basic PPDU format, an example of the VHT PPDU format (IEEE 802.11ac) additionally includes VHT SIG-A, VHT-STF, VHT-LTF, and VHT-SIG-B fields (as Figure 7 shown in (c)).

[0109] Compared to the basic PPDU format, an example of the HE PPDU format (IEEE 802.11ax) additionally includes a repeated L-SIG (RL-SIG), HE-SIG-A, HE-SIG-B, HE-STF, HE-LTF, and packet extension (PE) fields (as Figure 7 shown in (d)). Some fields can be excluded, or their lengths can vary according to the detailed example of the HE PPDU format. For example, the HE-SIG-B field is included in the HE PPDU format for multi-user (MU), and the HE-SIG-B is not included in the HE PPDU format for single-user (SU). In addition, the HE trigger-based (TB) PPDU format does not include the HE-SIG-B, and the length of the HE-STF field can vary to 8 μs. The extended range (HE ER) SU PPDU format does not include the HE-SIG-B field, and the length of the HE-SIG-A field can vary to 16 μs. For example, the RL-SIG can be configured to be the same as the L-SIG. Based on the presence of the RL-SIG, the receiving STA can know that the received PPDU is an HE PPDU or an EHT PPDU, which will be described later.

[0110] The EHT PPDU format can include Figure 7 the EHT MU (multi-user) in (e) and Figure 7 the EHT TB (trigger-based) PPDU in (f). The EHT PPDU format is similar to the HE PPDU format in including an RL-SIG following the L-SIG, but can include a U (universal)-SIG, EHT-SIG, EHT-STF, and EHT-LTF following the RL-SIG.

[0111] Figure 7The EHT MU PPDU in (e) corresponds to a PPDU carrying one or more data (or PSDU) for one or more users. That is, the EHT MU PPDU can be used for both SU transmission and MU transmission. For example, the EHT MU PPDU can correspond to a PPDU for one receiving STA or multiple receiving STAs.

[0112] Compared with the EHT MU PPDU, Figure 7 the EHT TB PPDU in (f) omits the EHT-SIG. A STA that receives a trigger for UL MU transmission (e.g., a trigger frame or a triggered response schedule (TRS)) can perform UL transmission based on the EHT TB PPDU format.

[0113] The L-STF, L-LTF, L-SIG, RL-SIG, U-SIG (universal signal), and EHT-SIG fields can be encoded and modulated so that even a legacy STA can attempt to demodulate and decode, and can be mapped based on the determined subcarrier frequency spacing (e.g., 312.5 kHz). These can be referred to as pre-EHT modulation fields. Next, the EHT-STF, EHT-LTF, data, and PE fields can be encoded and modulated to be demodulated and decoded by a STA that has successfully decoded a non-legacy SIG (e.g., U-SIG and / or EHT-SIG) and obtained the information included in this field, and can be mapped based on the determined subcarrier frequency spacing (e.g., 78.125 kHz). These can be referred to as EHT modulation fields.

[0114] Similarly, in the HE PPDU format, the L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, and HE-SIG-B fields can be referred to as pre-HE modulation fields, and the HE-STF, HE-LTF, data, and PE fields can be referred to as HE modulation fields. Additionally, in the VHT PPDU format, the L-STF, L-LTF, L-SIG, and VHT-SIG-A fields can be referred to as non-VHT modulation fields, and the VHT STF, VHT-LTF, VHT-SIG-B, and data fields can be referred to as VHT modulation fields.

[0115] Included in Figure 7The U-SIG in the EHT PPDU format can be configured based on, for example, two symbols (e.g., two consecutive OFDM symbols). Each symbol (e.g., OFDM symbol) for the U-SIG can have a duration of 4 μs, and the U-SIG can have a total duration of 8 μs. Each symbol of the U-SIG can be used to transmit 26-bit information. For example, each symbol of the U-SIG can be transmitted and received based on 52 data tones and 4 pilot tones.

[0116] The U-SIG can be constructed in units of 20 MHz. For example, if an 80 MHz PPDU is constructed, the U-SIG can be replicated. That is, the same 4 U-SIGs can be included in the 80 MHz PPDU. A PPDU with a bandwidth exceeding 80 MHz can include different U-SIGs.

[0117] For example, A uncoded bits can be sent through the U-SIG. The first symbol of the U-SIG (e.g., U-SIG-1 symbol) can send the first X bits of information out of the total A bits of information, and the second symbol of the U-SIG (e.g., U-SIG-2 symbol) can send the remaining Y bits of information out of the total A bits of information. The A bits of information (e.g., 52 uncoded bits) can include a CRC field (e.g., a 4-bit long field) and a tail field (e.g., a 6-bit long field). For example, the tail field can be used to terminate the trellis structure of the convolutional decoder and can be set to 0.

[0118] The bit information sent through the U-SIG can be divided into version-independent bits and version-dependent bits. For example, the U-SIG can be included in Figure 7 a new PPDU format not shown (e.g., UHR PPDU format), and can be included in the format of the U-SIG field included in the EHT PPDU format and the format of the U-SIG field included in the UHR PPDU format. The version-independent bits can be the same, and some or all of the version-dependent bits can be different.

[0119] For example, the size of the version-independent bits of the U-SIG can be fixed or variable. The version-independent bits can be assigned only to the U-SIG-1 symbol, or assigned to both the U-SIG-1 symbol and the U-SIG-2 symbol. The version-independent bits and the version-dependent bits can be called various names, such as the first control bit and the second control bit.

[0120] For example, the version-independent bits of the U-SIG may include 3-bit physical layer version identifiers (PHY version identifiers), and this information may indicate the PHY version of the transmitted / received PPDU (e.g., EHT, UHR, etc.). The version-independent bits of the U-SIG may include a 1-bit UL / DL flag field. The first value of the 1-bit UL / DL flag field is related to UL communication, and the second value of the UL / DL flag field is related to DL communication. The version-independent bits of the U-SIG may include information about the length of the transmission opportunity (TXOP) and information about the BSS color ID.

[0121] For example, the version-related bits of the U-SIG may include information that directly or indirectly indicates the type of the PPDU (e.g., SU PPDU, MU PPDU, TB PPDU, etc.).

[0122] The information required for PPDU transmission and reception may be included in the U-SIG. For example, the U-SIG may also include information about the bandwidth, information about the MCS technology applied to non-traditional SIGs (e.g., EHT-SIG or UHR-SIG, etc.), information indicating whether the DCM (dual carrier modulation) technology (e.g., a technology used to achieve an effect similar to frequency diversity by reusing the same signal on two subcarriers) is applied to non-traditional SIGs, information about the number of symbols for non-traditional SIGs, and information about whether non-traditional SIGs are generated across the entire frequency band.

[0123] Some of the information required for PPDU transmission and reception may be included in the U-SIG and / or non-traditional SIGs (e.g., EHT-SIG or UHR-SIG, etc.). For example, information about the type of non-traditional LTF / STF (e.g., EHT-LTF / EHT-STF or UHR-LTF / UHR-STF, etc.), information about the length of the non-traditional LTF and the CP (cyclic prefix) length, information about the GI (guard interval) applicable to non-traditional LTFs, information about the preamble puncturing applicable to the PPDU, information about the resource unit (RU) allocation, etc. may be included only in the U-SIG, included only in non-traditional SIGs, or may be indicated by a combination of the information included in the U-SIG and the information included in non-traditional SIGs.

[0124] Preamble puncturing may represent the transmission of the following PPDU, where there is no signal in one or more frequency units among the bandwidth of the PPDU. For example, the size of the frequency unit (or the resolution of the preamble puncturing) may be defined as 20 MHz, 40 MHz, etc. For example, preamble puncturing may be applied to a PPDU bandwidth of a predetermined size or larger.

[0125] In Figure 7In an example, non - traditional SIGs such as HE - SIG - B and EHT - SIG can include control information for receiving STAs. The non - traditional SIG can be sent on at least one symbol, and one symbol can have a length of 4 μs. Information about the number of symbols for EHT - SIG can be included in a previous SIG (e.g., HE - SIG - A, U - SIG, etc.).

[0126] Non - traditional SIGs such as HE - SIG - B and EHT - SIG can include a common field and user - specific fields. The common field and user - specific fields can be encoded separately.

[0127] In some cases, the common field can be omitted. For example, in a compressed mode that does not apply OFDMA (Orthogonal Frequency Division Multiple Access), the common field can be omitted, and multiple STAs can receive a PPDU (e.g., the data field of the PPDU) through the same frequency band. In a non - compressed mode that applies OFDMA, multiple users can receive a PPDU (e.g., the data field of the PPDU) through different frequency bands.

[0128] The number of user - specific fields can be determined based on the number of users. One user block field can include up to two user fields. Each user field can be associated with MU - MIMO allocation or can be associated with non - MU - MIMO allocation.

[0129] The common field can include CRC bits and tail bits. The length of the CRC bits can be determined to be 4 bits, and the length of the tail bits can be determined to be 6 bits and set to 000000. The common field can include RU allocation information. The RU allocation information can include information about the bit positions of the RUs assigned to multiple users (i.e., multiple receiving STAs).

[0130] An RU can include multiple sub - carriers (or tones). When sending signals to multiple STAs based on OFDMA technology, RUs can be used. Additionally, even when sending signals to one STA, RUs can be defined. Resources can be allocated to non - traditional STF, non - traditional LTF, and data fields in units of RUs.

[0131] The RU of an applicable size can be defined according to the PPDU bandwidth. The RU can be defined identically or differently for the applied PPDU format (e.g., HE PPDU, EHT PPDU, UHR PPDU, etc.). For example, in the case of an 80 MHz PPDU, the RU layouts of the HE PPDU and the EHT PPDU can be different. The applicable RU size, the number and position of RUs, the DC (direct current) subcarrier position and number, the null subcarrier position and number, the guard subcarrier position and number, etc. for each PPDU bandwidth can be referred to as a tone plan. For example, the tone plan for high bandwidth can be defined in the form of multiple iterations of a low bandwidth tone plan.

[0132] RUs of various sizes can be defined as 26-tone RUs, 52-tone RUs, 106-tone RUs, 242-tone RUs, 484-tone RUs, 996-tone RUs, 2×996-tone RUs, 3×996-tone RUs, etc. An MRU (multi-RU) is different from multiple individual RUs and corresponds to a set of subcarriers composed of multiple RUs. For example, an MRU can be defined as 52 + 26 tones, 106 + 26 tones, 484 + 242 tones, 996 + 484 tones, 996 + 484 + 242 tones, 2×996 + 484 tones, 3×996 tones, or 3×996 + 484 tones. Additionally, the multiple RUs constituting an MRU can be continuous or non-continuous in the frequency domain.

[0133] The specific size of an RU can be reduced or extended. Therefore, the specific size (i.e., the number of corresponding tones) of each RU in this disclosure is illustrative rather than restrictive. Additionally, in this disclosure, within a predetermined bandwidth (e.g., 20 MHz, 40 MHz, 80 MHz, 160 MHz, 320 MHz...), the number of RUs can vary according to the RU size.

[0134] Figure 7 The name of each field in the PPDU format is exemplary, and the scope of this disclosure is not limited by these names. Additionally, the examples of this disclosure can be applied to Figure 7 the PPDU format shown in Figure 7 and new PPDU formats that exclude some fields and / or add some fields based on the

[0135] Multi-Access Point (MAP) Operation

[0136] Hereinafter, examples of this disclosure for multi-access point (MAP) operation will be described.

[0137] The MAP operation can be defined as an operation between a master AP (or a sharing AP) and a slave AP (or a shared AP).

[0138] The master AP plays a role in initiating and controlling the MAP operation for transmission or reception between multiple APs. The master AP groups the slave APs and manages the links with the slave APs to share information among the slave APs. The master AP manages the information of the BSS configured with the slave APs and the information of the STAs associated with the corresponding BSS.

[0139] The slave APs can be associated with the master AP and share control information, management information, and data traffic with each other. The slave APs perform the basic functions of an AP that can establish a BSS in the same way.

[0140] The STAs in the MAP operation can be associated with the slave APs or the master AP to configure a BSS.

[0141] In the MAP environment, the master AP and the slave APs can perform direct transmission or reception with each other. The master AP and the STAs may not be able to perform direct transmission or reception with each other. A slave AP (e.g., a slave AP associated with an STA) can perform direct transmission or reception with the STA. One of the slave APs can become the master AP.

[0142] The MAP operation is a technology in which at least one AP transmits and receives information to / from at least one STA. For example, coordinated-time division multiple access (C-TDMA) technology that divides the allocation between APs on the time axis, coordinated-orthogonal frequency division multiple access (C-OFDMA) technology that divides the allocation between APs on the frequency axis, coordinated-space reuse (C-SR) technology that uses spatial reuse, etc. can be applied to the MAP operation. Alternatively, C-BF (coordinated beamforming) or joint beamforming technology that collaboratively performs simultaneous transmission or reception can also be applied to the MAP operation.

[0143] Figure 8 is a diagram for illustrating various transmission or reception technologies in the MAP environment to which the present disclosure can be applied.

[0144] When a BSS AP performs transmission to a BSS STA as in the existing method, it can be referred to as single transmission (STX). In STX, there is a problem that the performance of transmission or reception of users / STAs located at the cell edge is degraded due to interference with adjacent APs. For example, as Figure 8 in (a) of, when AP1 and AP2 simultaneously transmit to STA 1 and STA 2 in the same frequency bandwidth, a conflict may occur on the wireless medium.

[0145] In the MAP technology, performance can be improved by methods for reducing inter-symbol interference (ISI) through cooperation between neighboring APs or by performing transmissions together. For example, in Figure 8 the C-OFDMA method of (b), AP1 can perform a transmission to STA 1 in a first bandwidth, and at the same time, AP2 can perform a transmission to STA 2 in a second bandwidth, thus avoiding interference. Figure 8 The example in (c) shows a cooperative beamforming or nulling technique, where AP1 nulls the interference to AP2 and / or STA 2 when performing a transmission to STA 1, and AP2 nulls the interference to AP1 and / or STA 1 when performing a transmission to STA 2. Figure 8 The example in (d) shows an AP selection method, where the AP with good channel conditions among neighboring APs performs the transmission. As in the example in Figure 8 (e), a joint transmission (JTX) or joint reception (JRX) where multiple APs cooperate to perform transmission or reception simultaneously can be applied, and further, joint MU-MIMO can be supported.

[0146] RSN Operation

[0147] As described with reference to Figure 3 the authentication process after the discovery process between the STA and the AP can be performed in an open system manner, and the association process can be performed. This process can be called Step 0, which is used to search for support for a Robust Security Network (RSN) and establish authentication and association.

[0148] When Step 0 is successfully completed, Step 1 for ensuring a pairwise master key (PMK) and user authentication through IEEE 802.1X / EAP (Extensible Authentication Protocol) or a pre-shared key (PSK) can be performed. The mutual authentication methods applied here can include 802.1X / EAP, PSK, or SAE (simultaneous authentication of equals), etc. For example, for the 802.1X / EAP authentication method, the PMK can be generated from the master session key (MSK) after authentication between the STA and the Remote Authentication Dial-In User Service (RADIUS). For the user authentication method through PSK, the AP and the STA can directly set the PMK in the same way as the PSK. For user authentication through SAE, the AP and the STA can directly set the PMK by using the mutual authentication and the operation values of the authentication process through the SAE authentication process.

[0149] After step 1, step 2 can be performed to confirm whether the other party has the same PMK by using an EAPoL-Key frame and generate and share an encryption key. Step 2 can include a process of mutually confirming PMK generation and generating and delivering a group key (e.g., a group temporal key (GTK)) through a four-way handshake. A pairwise transient key (PTK), a key confirmation key (KCK), a key encryption key (KEK), and a temporal key (TK) can be generated through the four-way handshake.

[0150] Specifically, a PMK can be generated from an MSK in step 1, and a PTK can be generated from the PMK in step 2. Here, the PTK is respectively set as the KCK, the KEK, and the TK. The GTK can be generated from the AP and delivered to the STA. When the AP wants to generate a new GTK, it can perform a handshake with the STA and deliver the new GTK to the STA.

[0151] To confirm whether the STA and the AP have the same PMK, for 802.1X / EAP, the same MSK is set between the STA and the authentication server (AS) through the user authentication result between the STA and the AS, and the AS delivers the corresponding MSK to the AP. The STA and the AP can mutually confirm whether they have the PMK, that is, the symmetric key generated from the MSK, through a four-way handshake. For PSK, the authentication process can be replaced by mutually verifying whether the PMK generated from the pre-set PSK between the AP and the STA is ensured through a four-way handshake. For SAE, the PMK pre-set between the AP and the STA can be mutually verified through a four-way handshake.

[0152] It can also be confirmed whether the STA and the AP have the same PMK by mutually verifying that the same PTK is generated. For example, it can also be confirmed whether the PMK is ensured through message 2 and message 3 of the four-way handshake. Specifically, in message 2, the STA can send the KCK of the PTK it generated to the AP by including the KCK of the PTK it generated in the key MIC field. In message 3, the AP can send the KCK of the PTK it generated to the STA by including the KCK of the PTK it generated in the key MIC field. Through this, the STA (AP) can verify that the AP (STA) has generated the same PTK as its PTK and confirm that the AP (STA) has the same PMK as its PMK. In addition, in message 1, the value of the key MIC field can be set to 0, and in message 4, the KCK value can be included in the key MIC field.

[0153] In this way, a security key for encrypting data to be sent and received between the STA and the AP can be generated in step 2. In an RSN, different security keys are generated for each STA associated with the AP, and another security key is generated when the STA re-associates with another AP.

[0154] Based on the TK generated due to the 4-way handshake in step 2, data encryption can be performed by using the Temporal Key Integrity Protocol (TKIP), the Cipher Block Chaining Message Authentication Code Protocol (CCMP), the Galois / Counter Mode Protocol (GCMP), etc., which can be referred to as step 3.

[0155] The above-mentioned MSK, PSK, PMK, PTK, KCK, KEK, and TK correspond to pairwise keys, that is, the pairing keys between the AP and the STA. Different from the pairwise keys, a group key can be generated based on the Group Master Key (GMK) so that the AP generates a security key for group-addressed frames (such as beacon frames). The GMK is randomly set by the AP. The Group Temporal Key (GTK) is generated from the GMK by a Pseudo-Random Function (PRF) function and corresponds to a one-way group key from the AP to the STA.

[0156] Figure 9 It is a diagram for illustrating the 4-way handshake process to which the present disclosure can be applied.

[0157] The STA corresponds to the supplicant, and the AP corresponds to the authenticator. When the STA has or knows the PMK and the AP has or knows the PMK and the GMK, a 4-way handshake can be performed to generate and confirm the PTK and the GTK between the AP and the STA.

[0158] ANonce and SNonce correspond to the factors used in the PRF function for generating the PTK. ANonce can correspond to a random number generated by the access point (i.e., the authenticator). SNonce can correspond to a random number generated by the STA (i.e., the supplicant). The PRF function can correspond to a function for generating the PTK based on, for example, the PMK, ANonce, SNonce, the MAC address of the supplicant, and the MAC address of the authenticator.

[0159] In S910, message 1 is sent from the AP to the STA in unicast, and the EAPOL-key frame can include the ANonce information. When the AP generates the PMK, the PMKID can be included in the key data field of the EAPOL-key frame. The STA can generate the PTK based on the information received from the AP and can generate the KCK, KEK, and TK based on the PKT.

[0160] In S920, a message 2 is sent from the STA to the AP in unicast, and the EAPOL - key frame may include SNonce information and a key message integrity code (MIC). For example, the key MIC of message 2 may have a value based on KCK generated by the STA. The AP may generate a PTK based on the information received from the STA, and may generate KCK, KEK, and TK based on the PTK. The AP may verify whether the AP and the STA have generated the same PTK based on whether the KCK value of the PTK generated according to the value included in message 2 and the KCK value related to the key MIC value included in message 2 are the same. Additionally, if needed, the AP may generate a GTK. The GTK may be generated by the AP from the GMK without the participation of the STA.

[0161] In S930, a message 3 is sent from the AP to the STA in unicast, and the EAPOL - key frame may include PTK, MIC, and encrypted GTK information. The encrypted GTK of message 3 may be generated based on the KEK generated by the AP and may be included in the key data field. The STA may store the PTK in the PKT - SA (PKT - Security Association) and store the GTK in the GTK - SA.

[0162] In S940, a message 4 is sent from the STA to the AP in unicast, and the EAPOL - key frame may include MIC information. When the verification is completed through the MIC, the AP may store the PTK in the PKT - SA and store the GTK in the GTK - SA.

[0163] When the 4 - way handshake is successfully completed in this way, the virtual control port that blocks all traffic can be unblocked, and encrypted traffic can be sent and received. After that, all unicast traffic can be encrypted by the PTK, and all multicast / broadcast traffic can be encrypted by the GTK.

[0164] Fast BSS Transition (FT) Operation

[0165] Figure 10 is a diagram for illustrating BSS transition in an existing WLAN system.

[0166] For the fast BSS transition (FT) method, which is a typical example corresponding to BSS transition (or roaming), various processes such as authentication request / response, re - association request / response are required between the FT initiator (FTO) (or non - AP STA) and the target FTR in order to move from the current FT responder (FTR) (or current AP) to the target FTR (or target AP). In other words, in the existing BSS transition method, a re - association process is required on the same mobility domain.

[0167] In addition, after the processes exemplified in Figure 10 , various operation parameters are reset, such as agreements related to Block Acknowledgment (BA) or Service Classification Service (SCS), SN, EDCA function (EDCAF) parameters, etc. Therefore, the FTO has to perform various and a large number of frame exchanges for FT and has to perform the agreement / configuration with the new FTR again. Therefore, the complexity and overhead of the FT process are high, and data loss may occur during the FT process.

[0168] In the existing authentication method, a STA that determines it is necessary to roam to a new AP has to exchange (re)association requests / responses with the new AP and can obtain the MSK after successfully completing the authentication of the STA to the new AP. In other words, the STA has to start over from scratch with the new AP by referring to the Figure 9 described RSN authentication and key generation process.

[0169] In a refined FT method for this, obtaining the MSK during the authentication process can be completed before the STA performs roaming. For example, when the STA enters a Mobility Domain (MD), only one initial authentication process is performed, and the encryption method derived from the initial authentication process is used within the same MD (i.e., entities with the same MD identification information (MDID)), so the roaming time can be shortened and the load on the Authentication Server (AS) can be reduced.

[0170] In addition, an FT key hierarchy can be supported to support the FT method. The highest-level Key Holders (KHs) can correspond to R1KH and S1KH, while the lower-level key holders can correspond to R0KH and S0KH. R1KH and S1KH can have access rights to R0KH and S0KH. R0KH and R1KH belong to the Station Management Entity (SME) RSNA key management of the AP and can be called the authenticator key holders. S0KH and S1KH belong to the SMERSNA key management of the STA and can be called the supplicant key holders. R0KH and S0KH can be responsible for calculating PMK-R0 and PMK-R1 of the AP and the STA respectively. R1KH and S1KH can be responsible for calculating the PTK of the AP and the STA respectively.

[0171] When authentication is successfully performed in the FT initial mobility domain association method, the R0KH of the AP (e.g., the current FTR) can receive the PMK and related parameters. Here, when a KH belonging to the same MDID as the STA to be associated already exists, the PMK-R0 security association (SA) and PMK-R1 SA with the existing R0KH can be deleted, and PMK-R0 and PMK-R1 can be calculated based on the newly received PMK. Subsequently, the S1KH of the STA and the R1KH of the AP can generate the TK and GTK through the 4-way handshake, and store and manage them in each SA (e.g., PTKSA, GTKSA). Therefore, the IEEE 802.1X control port between the STA and the AP can be unlocked, and encrypted messages can be sent and received.

[0172] Secure Key Sharing Based on Multi-AP Operation

[0173] As described above, after establishing the association between the AP and the STA, the encryption key used in data encapsulation / decapsulation (e.g., TK derived from the PTK) is generated through the 4-way handshake. The security parameters in this process can be stored in the PTK security association (SA) within the AP and the STA. When the STA moves / roams from the associated AP to another AP, the corresponding information can be reused, and the encryption key (e.g., TK) can be regenerated. This process can be applied to, for example, the FT method.

[0174] A multi-AP (MAP) can be configured by including one master AP (or shared AP) and at least one slave AP (or shared AP). In a MAP environment, it can be assumed that the STA performs FT to establish a re-association with another AP in the MAP after performing the 4-way handshake for the initial association with the AP belonging to the MAP (or MAP set) through the current existing authentication method. In this case, the STA must generate different encryption keys for each connected AP to communicate with different APs. During these processes, the STA performs multiple communications with the APs in a MAP set, which may cause delays and hinder the efficient transmission and reception of data in the MAP.

[0175] This disclosure describes various examples of establishing a seamless security association between the AP belonging to the MAP and the STA.

[0176] In the present disclosure, in a MAP environment, a STA can generate a security key for data transmission and reception through an initial association with a primary AP or a secondary AP. An AP within the MAP that has established an initial association with the STA can share the corresponding key with other APs within the same MAP to reduce latency and inefficiency caused by STA movement / roaming as described above. For example, although the STA moves between APs within a MAP, it can continuously transmit and receive data with the new AP without additional authentication and re-association procedures.

[0177] Hereinafter, a specific example of a security key sharing method based on multi-AP operation is described. The names and values of fields, elements, parameters, keys, etc. proposed in the present disclosure are exemplary and are not limited to these names and values. In addition, unless otherwise specified, the STA can be an AP STA or a non-AP STA.

[0178] Figure 11 is a diagram for explaining the operation of a first STA according to the present disclosure.

[0179] In Figure 11 the example, the first STA can correspond to the primary / shared AP of the MAP, the second STA can correspond to the secondary / shared AP of the MAP, and the third STA can correspond to a non-AP STA that has established an initial association with the first STA or the second STA.

[0180] In S1110, the first STA can generate a Multi-Access Point Group Temporary Key (MAGTK).

[0181] The MAGTK can correspond to a group temporary key commonly used in the MAP. When generating the MAGTK, for example, the first GMK, MAP group key expansion, and the MAC address of the first STA can be used, and other additional factors can be further used. Here, the first GMK is the GMK used to generate the MAGTK, and the second GMK used by the first STA to generate the GTK can have the same value, or can be defined separately and have different values.

[0182] In S1120, the first STA can encrypt the MAGTK based on the key shared between the first STA and at least one second STA. The encrypted MAGTK can be sent to at least one second STA.

[0183] For example, the key shared between the first STA and at least one second STA can be a KEK or a PSK. Based on this shared key, the element / frame including the MAGTK can be encrypted. Alternatively, based on this shared key, the MAGTK itself can be encrypted and included in the element / frame (not encrypted by the MAGTK).

[0184] For example, an element including MAGTK can be a MAGTK key data element (KDE). The MAGTK KDE can include key identification information, MDID, and MAGTK. Additionally, the MAGTK KDE can further include a MAP group cipher suite. The MDID included in the MAGTK KDE can be replaced with MAP identification information.

[0185] For example, an element including MAGTK can be a predetermined element having a format different from that of the MAGTK KDE. The predetermined element can include key information (including key identification information), key length information, MDID, and MAGTK. Additionally, the predetermined element can further include a MAP group cipher suite. The MDID included in the predetermined element can be replaced with MAP identification information.

[0186] In S1130, the security key for the third STA can be encrypted based on MAGTK and shared with at least one second STA. Therefore, when sharing the security key for the third STA within the MAP, the exposure of the security key for the third STA to other STAs other than the MAP can be prevented.

[0187] The security key for the third STA can be a pairwise transient key (PTK) or a transient key (TK) of the PTK that is equally generated between the first STA or the second STA that establishes an initial association with the third STA and the third STA.

[0188] The PTK / TK of the third STA corresponds to the security key applied to the encryption of unicast traffic to / from the third STA after the completion of the security authentication process. Since the PTK / TK of the third STA is shared within the MAP, other STAs that have not established an initial association with the third STA can also use the PTK / TK to encrypt and send unicast traffic to / from the third STA.

[0189] The third STA and other second STAs or the first STA that establish an initial association with the third STA can generate the PTK / TK for the third STA. For example, when generating the PTK for the third STA (e.g., MAP-PTK), the MAC address of the third STA and the MAC address of the MAP can be used, and other additional factors can be further used. The TK can be derived from the PTK (e.g., by extracting a part of the bits of the PTK to configure the TK). Here, the MAC address of the MAP can be the MAC address of the first STA, or the MAC address shared by the first STA and at least one second STA (e.g., defined for the MAP). The MAC address of the MAP can be indicated by the BSSID.

[0190] The PTK / TK for the third STA can be encrypted by using a temporary key (TK) exported from the MAGTK. Additionally, when encrypting the PTK / TK based on the MAGTK, the information of the third STA can also be encrypted based on the MAGTK and shared with at least one second STA together with the encrypted PTK / TK for the third STA. Additionally or alternatively, when encrypting the PTK / TK based on the MAGTK, the cipher suite agreed upon between the STAs (e.g., other second STAs or the first STA) that establish an initial association with the third STA can also be encrypted based on the MAGTK and shared with at least one second STA together with the encrypted PTK / TK for the third STA.

[0191] As an example of PTK / TK sharing, another second STA that establishes an initial association with the third STA (i.e., a second STA other than the at least one second STA with which the PTK / TK is shared) can encrypt the PTK / TK for the third STA and send it to the first STA. The first STA can decrypt the encrypted PTK / TK to obtain the PTK / TK, and can encrypt the obtained PTK / TK to send it (e.g., broadcast or multicast) to at least one second STA. Alternatively, the first STA can send the encrypted PTK / TK to at least one second STA as it is.

[0192] As another example of PTK / TK sharing, another second STA that establishes an initial association with the third STA (i.e., a second STA other than the at least one second STA with which the PTK / TK is shared) can encrypt the PTK / TK for the third STA and send it to the first STA and at least one second STA.

[0193] As another example of PTK / TK sharing, the first STA that establishes an initial association with the third STA can encrypt the PTK / TK for the third STA and send it to at least one second STA.

[0194] Figure 11 The method described in the example of Figure 1 can be executed by the first device 100 in Figure 1 For example, at least one processor 102 of the first device 100 in Figure 11instructions of the method described in the examples below or described below.

[0195] Figure 12 is a diagram for explaining the operation of the second STA according to the present disclosure.

[0196] In S1210, the second STA may obtain a key shared between at least one second STA including itself and the first STA.

[0197] The specific description of the key shared between the first STA and at least one second STA is the same as that of the example in Figure 11 and thus the overlapping description is omitted.

[0198] In S1220, the second STA may receive from the first STA a MAGTK encrypted based on the key shared between the first STA and at least one second STA.

[0199] The specific description of MAGTK, the encryption of MAGTK, and the sending / receiving of the encrypted MAGTK is the same as that of the example in Figure 11 and thus the overlapping description is omitted.

[0200] In S1230, the security key for the third STA may be encrypted based on the MAGTK and shared with at least one second STA.

[0201] The specific description of the shared security key (e.g., PTK / TK) and the encrypted security key is the same as that of the example in Figure 11 and thus the overlapping description is omitted.

[0202] Figure 12 The method described in the example of Figure 1 may be executed by the second device 200 in Figure 1 For example, at least one processor 202 of the second device 200 in Figure 12 may be configured to obtain the key shared between the first STA and at least one second STA including the second STA and receive from the first STA a MAGTK encrypted based on the corresponding shared key. The MAGTK may be generated by the first STA, and the security key for the third STA may be encrypted based on the MAGTK and shared with at least one second STA. In addition, at least one memory 204 of the second device 200 may store instructions for executing the method described in the example of

[0203] Figure 11 and Figure 12 The examples ofFigure 11 and Figure 12 various examples of the present disclosure, including examples of

[0204] In the embodiments described below, sharing a security key within a MAP is described as a representative example, but the embodiments described below can be equivalently applied to a group of STAs not limited to a MAP and falling within different scopes that require security key sharing. In addition, in the embodiments described below, security key names such as MAGTK, PTK, TK, etc. are described as representative examples, but the embodiments described below can be equivalently applied to security keys under other names for corresponding functions / roles.

[0205] Embodiment 1

[0206] This embodiment relates to the definition, identification, and initial authentication of the scope to which security key sharing can be applied (e.g., a group of APs belonging to one MAP and allowing roaming of STAs).

[0207] Figure 13 is a diagram showing an example of the security key sharing scope according to the present disclosure. In Figure 13 it, M represents the master AP, and S represents the slave AP.

[0208] The scope of application of the FT protocol described by referring to Figure 10 corresponds to STAs and APs belonging to the same mobility domain (MD) within the same ESS, and this scope can be identified by the MDID.

[0209] As in the example of Figure 13 (a), the scope of applying security key sharing within a MAP according to the present disclosure (which is different from the FT operation) can be identified by setting the same MDID for the APs (e.g., the master AP and the slave AP within one MAP) to which the present disclosure is applied. The MDID set for this purpose means the same MD within the same ESS, and in addition, it can represent that the same MD corresponds to one MAP by being applied to the MAP.

[0210] As in the example of Figure 13 (b), when the APs (e.g., the master AP and the slave AP within one MAP) to which the present disclosure is applied belong to multiple ESSs, the MDID limited to one ESS may not be able to identify the corresponding APs. Therefore, a new ID different from the MDID (e.g., MAP ID) can be defined and used to identify the scope of applying the security key sharing of the present disclosure.

[0211] For Figure 13For the example of (a), a MAP ID different from the MDID can also be used to identify the scope of applying the security key sharing of the present disclosure.

[0212] Embodiment 2

[0213] This embodiment relates to a method for generating and sharing a security key after an initial association and an initial authentication between a STA and one of APs belonging to a scope (e.g., one MAP) where a security key can be shared.

[0214] The initial authentication process performed before the initial association process between an AP belonging to a MAP and a STA can be similar to the process described by referring to the FT protocol in Figure 10 and the process in Figure 3 For example, when the authentication process after the discovery process is performed in an open system manner and the association process is successfully completed, the authentication can be performed based on the IEEE 802.1X method. When the authentication is successfully completed, the STA and the AP can obtain a PMK from the IEEE 802.1X authentication server.

[0215] In the present disclosure, all other APs (i.e., the master AP and / or the slave AP) belonging to the same MAP as the AP (e.g., the master AP or the slave AP) that performs the authentication process with the STA can also receive / obtain the same PMK from the IEEE 802.1X authentication server. Different from the example described by referring to Figure 3 and Figure 10 this means that the PMK is shared based on the MAP, and for this purpose, the scope of security key sharing through the above MAP ID (or MDID) can be identified.

[0216] Next, in the MAP, the STA and the AP (e.g., the master AP or the slave AP) can generate a security key (e.g., PTK) through an initial association process and a 4-way handshake process, and store or install the same (or paired) security key (PTK) in each of the STA and the AP. For example, the initial association process can be performed similar to the FT initial (MD) association process, and the 4-way handshake process can be performed similar to the FT 4-way handshake process.

[0217] In the present disclosure, an AP that generates and stores the same / pairwise security key (e.g., PTK) as the STA can share the same / pairwise security key (e.g., PTK) or another security key (e.g., TK) derived from the corresponding security key with all other APs belonging to the same MAP (i.e., the master AP and / or the slave APs). As a sharing method, the following method can be applied: The AP that generates / stores the same / pairwise security key as the corresponding STA includes the corresponding security key (e.g., PTK or TK) in the data / frame and sends / announces it to other APs (i.e., via the wireless medium).

[0218] For example, the corresponding security key (PTK or TK) can be included in the frame sent from one AP in the MAP to other APs, and the area in the frame that includes the corresponding security key (PTK or TK) can be encrypted and sent by a key (e.g., MAGTK) shared only among the APs in the MAP. Other STAs and APs outside the MAP that do not know the corresponding MAGTK cannot know whether the security key (PTK or TK) exists in the corresponding frame and also cannot decrypt the specific value of the security key (PTK or TK). Therefore, the security of the corresponding security key (PTK or TK) can be maintained.

[0219] Figure 14 It is a diagram for illustrating an example of the MAGTK shared within the MAP according to the present disclosure.

[0220] The master AP and the slave APs belonging to the same MAP can have / store the same MAGTK. The MAGTK can be generated by the master AP and sent to all the slave APs in the MAP. The MAGTK sent to each slave AP has the same value.

[0221] The GTK can also be sent to the STA associated with the slave AP belonging to the MAP. The GTK is different from the newly defined MAGTK in the present disclosure. The GTK provided by the slave AP to the STA can be used to encrypt / decrypt the broadcast traffic from the AP, and the GTK can be encrypted by the KEK (i.e., the key derived from the PTK) and sent to the STA via message 3 during the 4-way handshake process with the STA. The GTK sent from the slave AP to the STA can be the same value or different values. The GTK sent from the slave AP to the STA can be generated by the master AP. In addition, when sharing the MAGTK, the GTK sent to the STA can be sent together through the same frame / message.

[0222] Hereinafter, a specific example of the method for generating and sharing the MAGTK shared only among the APs in the MAP is described. The MAGTK can correspond to the GTK shared in the MAP or the GTK shared by the master AP.

[0223] Embodiment 3

[0224] This embodiment relates to a method for sharing MAGTK.

[0225] Figure 15 It is a diagram showing an example of an element including MAGTK according to the present disclosure.

[0226] If there is a process of separately establishing an association / connection between the master AP and the slave AP in the MAP, the master AP can generate MAGTK and send an EAPOL-key frame including the corresponding MAGTK to the slave AP. The slave AP can store / install the received MAGTK and related information / parameters in the MAGTK-Security Association (MAGTK-SA).

[0227] MAGTK and related information can be sent and received by being included in a key data element (e.g., MAGTK KDE). The data type of the KDE selector of the MAGTK KDE can have a value different from other existing KDE types (e.g., one of 16 - 255, excluding 1 - 15 assigned to existing data types).

[0228] Figure 15 (a) of shows an example of MAGTK KDE.

[0229] The value of the Key ID field can be set to a key ID that can identify MAGTK. The value of the MDID field can indicate that it is a key sent to the AP with the corresponding MDID. As described above, when using the MAP ID, Figure 15 the MDID field in (a) of can be replaced with the MAP ID field.

[0230] Figure 15 (b) of shows another example of MAGTK KDE.

[0231] Compared with Figure 15 the example of (a) of, Figure 15 the MAGTK KDE in (b) of can also include the MAP group cipher suite. When there is a cipher suite value used by the APs within the MAP during transmission and reception (which is shared in advance by the APs within the MAP), the MAP group cipher suite field may not be included in the data including MAGTK (e.g., MAGTK KDE). When the pre-shared cipher suite does not exist or when the pre-shared cipher suite is changed to another cipher suite, the MAP group cipher suite field can be sent together with MAGTK.

[0232] The MAP group cipher suite field may include a suite selector format. The suite selector format may include an Organizationally Unique Identifier (OUI) and a suite type field. The OUI field may be set to a specific value (e.g., 00-0F-AC), and depending on the combination of the values of the OUI field and the suite type field, it may indicate cipher suites such as WEP-40, WEP-104, TKIP, CCMP-128, GCMP-128, BIP-CMAC-128, BIP-GMAC-128, etc. For example, the WEP-40 or WEP-104 cipher suite is used for GTK, but cannot be used for PTK, Integrity Group Temporal Key (IGTK), or Beacon Integrity Group Temporal Key Security Association (BIGTK). The CCMP-128 or GCMP-128 cipher suite is used for GTK and PTK, but cannot be used for IGTK or BIGTK. The BIP-CMAC-128 or BIP-GMAC-128 cipher suite is not used for GTK and PTK, but can be used for IGTK or BIGTK.

[0233] The master AP may generate MAGTK and configure a MAGTK KDE including the corresponding MAGTK. The master AP may share the MAGTK and related information by sending an EAPOL-key frame including the MAGTK to the slave AP. Here, the master AP may encrypt and send the MAGTK KDE (or MAGTK and related information) of the EAPOL-key frame by using an encryption key agreed upon between the master AP and the slave AP. The slave AP may decrypt the received MAGTK KDE (or MAGTK and related information) by using the same agreed encryption key and store / install the MAGTK and related parameters in the MAGTK-SA.

[0234] If there is no process of separately establishing an association / connection between the master AP and the slave AP in the MAP, the master AP may send the generated MAGTK to the slave AP by a separately addressed or group addressed frame / element. For example, the MAGTK may be sent by being included in a sub-element of the MAGTK (hereinafter referred to as the MAGTK sub-element). The slave AP may store / install the received MAGTK and related information / parameters in the MAGTK-SA.

[0235] For example, the MAGTK sub-element may be included in the optional parameters within the FT element (FTE). This is only an example, and the MAGTK sub-element may be included in other existing elements / frames or newly defined elements / frames.

[0236] Figure 15 (c) shows an example of the MAGTK sub-element.

[0237] The sub - element ID that identifies the MAGTK sub - element can have a value different from that of the existing sub - elements (for example, one of 8 - 255 (excluding 1 - 7) is assigned as the existing sub - element ID). The length field can be set to a value representing the length of the fields following the length field. The key information field includes a key ID sub - field, and the value of the key ID field can be set to a key ID that can identify the MAGTK. The key length field can be set to a value corresponding to the length of the MAGTK being transmitted or the length of the encrypted key. The value of the MDID field can indicate that it is a key sent to the AP with the corresponding MDID. As described above, when using the MAP ID, Figure 15 the MDID field in (c) of

[0238] Figure 15 can be replaced by the MAP ID field. The wrapped key field can include the encrypted key, that is, the result of applying encryption to the MAGTK.

[0239] Compared with Figure 15 the example in (c) of Figure 15 the MAGTK sub - element in (d) of

[0240] can also include a MAP group cipher suite. When there is a cipher group value used by the AP within the MAP during sending and receiving (which is shared in advance by the APs within the MAP), the MAP group cipher suite field may not be included in the data including the MAGTK (for example, MAGTK KDE). When the pre - shared cipher suite does not exist or when the pre - shared cipher suite is changed to another cipher suite, the MAP group cipher suite field can be sent together with the MAGTK.

[0241] As described above, the MAGTK KDE, the MAGTK sub - element, or the element / frame including the MAGTK and related parameters can be sent by the primary AP to update the MAGTK previously shared between the primary AP and the secondary AP to a new MAGTK. The secondary AP that receives the MAGTK sub - element can delete the MAGTK and related parameters stored in the existing MAGTK - SA and store the newly received MAGTK and related parameters.

[0241] The MAGTK (or MAGTK and related information) can be encrypted and sent. Thus, the MAGTK can be protected from other STAs except for the APs in the MAP. Encrypting the MAGTK (or MAGTK and related information) can include encrypting the MAGTK (or MAGTK and related information) itself, and / or encrypting the container including the MAGTK (or MAGTK and related information) (for example, MAGTK KDE or MAGTK sub - element, such as Figure 15 the example of

[0242] For example, when generating a security key (e.g., PTK) for unicast transmission between a master AP and a slave AP, the KEK derived from the PTK (or generated during the PTK generation process) can be used to encrypt the MAGTK (or the MAGTK and related information). When there is no security key for unicast transmission between the master AP and the slave AP, the master AP and the slave AP can share a PSK (e.g., a combination of various characters) in advance, and encrypt the MAGTK (or the MAGTK and related information) by using the PSK or a key derived from the PSK (or reprocessed based on the PSK).

[0243] Alternatively, regardless of whether there is a security key for unicast transmission between the master AP and the slave AP, the part including the MAGTK (or the MAGTK and related information) in the container including the MAGTK (or the MAGTK and related information) can be restricted from identifying other APs / STAs (e.g., the master AP / slave AP in the MAP) other than the AP.

[0244] The MAGTK-SA installed between the master AP and the slave AP can include not only the MAGTK but also parameters related to the MAGTK. For example, the parameters related to the MAGTK can include at least one of the following parameters.

[0245] - Direction vector: A parameter indicating whether it is a transmitted MAGTK or a received MAGTK

[0246] - Group cipher suite selector: A parameter indicating the method used to encrypt the transmitted data and decrypt the received data by using the security key based on the MAGTK between the APs

[0247] - Authenticator MAC address: For the MAGTK, the MAC address of the master AP (or the MAC address commonly used in the MAP)

[0248] - Key ID: An ID identifying the MAGTK

[0249] - All authorization-related parameters specified by local settings: For example, the authorized SSID of the STA, etc.

[0250] Embodiment 4

[0251] This embodiment relates to the MAGTK generation method and PTK generation method defined in the present disclosure.

[0252] The MAGTK can be generated by the master AP according to the following formula.

[0253] MAGTK = PRF_Length(GMK, "Multi-AP group key expansion", AA||GNonce)

[0254] PRF_Length() represents a function that derives a pseudo-random number of a specific length.

[0255] GMK is a temporary key set by the master AP, and the same key as the GMK used to generate the GTK generated by the master AP (i.e., the GTK different from MAGTK) can be used to generate MAGTK, or a key different from the GMK used to generate the GTK can be used to generate MAGTK.

[0256] In the above example, the label as the string for the purpose of identifying the key generated by the PRF function can be specified as "Multi-AP Group Key Extension" (or "Master AP Group Key Extension") corresponding to MAGTK.

[0257] AA corresponds to the value of the MAC address of the master AP (or the MAC address commonly used in the MAP).

[0258] GNonce (Group Random Number) is a random number generated by the IEEE 802.1X authenticator (e.g., the master AP).

[0259] The APs belonging to the MAP and the STAs associated with the corresponding APs can generate the PTK according to the following formula.

[0260] PTK = KDF_Hash_Length(PMK-R1, "MAP-PTK", SNonce||ANonce||BSSID||STA-ADDR)

[0261] KDF_Hash_Length() means a key derivation function that generates a key of a specific length by using a specific hashing algorithm.

[0262] PMK-R1 corresponds to the second-level key in the FT key hierarchy and can be derived from S0KH and R0KH with each other.

[0263] In the above example, the label as the string for the purpose of identifying the key generated by the PRF function can be specified as "MAP-PTK", which corresponds to the PTK (i.e., the PTK encrypted by MAGTK and shared among the APs in the MAP).

[0264] SNonce can correspond to a random number generated by the STA (i.e., the supplicant).

[0265] ANonce can correspond to a random number generated by the master AP or the slave AP (i.e., the authenticator) initially associated with the STA.

[0266] BSSID can correspond to the BSSID of the master AP, the MAC address of the master AP, or the value of the MAC address commonly used in the MAP.

[0267] The STA-ADDR corresponds to the MAC address of the STA.

[0268] Embodiment 5

[0269] This embodiment relates to a method for an AP within a MAP to share a PTK / TK.

[0270] As described above, when a STA establishes an initial association with an AP (primary AP or secondary AP) within a MAP, the STA and the corresponding AP can generate security keys (e.g., PTK or TK) in the same way. The corresponding security key (PTK / TK) can be shared with other APs (primary AP and / or secondary APs) within the MAP.

[0271] Figure 16 It is a diagram showing an example of a security key sharing operation according to the present disclosure.

[0272] In Figure 16 the example, the STA can establish an initial association with the secondary AP 1 (S1) in the MAP. Thus, security keys (e.g., PTK / TK) can be generated in the same way between the STA and S1.

[0273] S1 can encrypt the security key (PTK / TK) based on the MAGTK (e.g., by using the TK of the MAGKTK). Additionally, S1 can encrypt relevant information such as information of the corresponding STA, the cipher suite agreed upon between the STA and S1, the authentication and key management (AKM) of the STA, etc. based on the MAGTK. S1 can send the encrypted security key (PTK / TK) (and relevant information) to the primary AP (M).

[0274] M can send the encrypted security key (PTK / TK) (and relevant information) received from S1 as it is to other secondary APs (S2, S3, S4). Alternatively, M can decrypt and store the encrypted security key (PTK / TK) (and relevant information) received from S1, encrypt it again based on the MAGTK (e.g., by using the TK of the MAGKTK), and send the encrypted security key (PTK / TK) (and relevant information) to other secondary APs (S2, S3, S4). For example, M can send the MAGTK-based encrypted security key (PTK / TK) to other secondary APs (S2, S3, S4) in a broadcast manner (i.e., to all secondary APs including S1) or in a unicast / multicast manner. Thus, all APs in the MAP can obtain and store the security key (PTK / TK) for the STA.

[0275] Figure 17It is a diagram showing another example of the secure key sharing operation according to the present disclosure.

[0276] In Figure 17 the example, the STA can establish an initial association with the slave AP 1 (S1) in the MAP. Thus, a secure key (e.g., PTK / TK) can be generated between the STA and S1 in the same way.

[0277] S1 can encrypt the secure key (PTK / TK) based on the MAGTK (e.g., by using the TK of the MAGKTK). Additionally, S1 can encrypt related information such as information of the corresponding STA, the cipher suite agreed between the STA and S1, the AKM of the STA, etc. based on the MAGTK. S1 can send the encrypted secure key (PTK / TK) (and related information) to the master AP (M) and other slave APs (S2, S3, S4). S1 can send the corresponding information to other APs in the MAP in a broadcast, multicast, or unicast manner. Thus, all APs in the MAP can obtain and store the secure key (PTK / TK) for the STA.

[0278] Figure 18 It is a diagram showing another example of the secure key sharing operation according to the present disclosure.

[0279] In Figure 18 the example, the STA can establish an initial association with the master AP (M) in the MAP. Thus, a secure key (e.g., PTK / TK) can be generated between the STA and M in the same way.

[0280] M can encrypt the secure key (PTK / TK) based on the MAGTK (e.g., by using the TK of the MAGKTK). Additionally, M can encrypt related information such as information of the corresponding STA, the cipher suite agreed between the STA and M, the AKM of the STA, etc. based on the MAGTK. M can send the encrypted secure key (PTK / TK) (and related information) to the slave APs (S1, S2, S3, S4). M can send the corresponding information to other APs in the MAP in a broadcast, multicast, or unicast manner. Thus, all APs in the MAP can obtain and store the secure key (PTK / TK) for the STA.

[0281] Although the BSS transition method in the existing WLAN system is supported, a new authentication and association process with the target AP is required. According to the present disclosure, even without the authentication process / association process with other APs, the STA can send and receive data from each other by sharing the secure key generated by one AP for the STA with the remaining APs within the same AP set (e.g., MAP).

[0282] The above-described embodiments combine the elements and features of the present disclosure in a predetermined form. Unless otherwise explicitly mentioned, each element or feature should be considered optional. Each element or feature can be implemented in a form that does not combine with other elements or features. Additionally, the embodiments of the present disclosure can include combining some of the elements and / or features. The order of operations described in the embodiments of the present disclosure can be changed. Some elements or features of one embodiment can be included in other embodiments, or can be replaced with corresponding elements or features of other embodiments. Obviously, the embodiments can include combining claims that do not have an explicit citation relationship in the claims, or can be included as new claims by amendment after the application.

[0283] It is clear to those skilled in the relevant art that the present disclosure can be implemented in other specific forms without exceeding the essential features of the present disclosure. Therefore, the above detailed description should not be construed restrictively in every aspect, but should be considered illustrative. The scope of the present disclosure should be determined by a reasonable interpretation of the appended claims, and all changes within the equivalent scope of the present disclosure are included within the scope of the present disclosure.

[0284] The scope of the present disclosure includes software or machine-executable commands (e.g., operating systems, application programs, firmware, programs, etc.) that perform operations according to the methods of various embodiments in a device or computer, and non-transitory computer-readable media that enable the software or commands, etc. to be stored and executable in the device or computer. The commands that can be used to program a processing system for implementing the features described in the present disclosure can be stored in a storage medium or computer-readable storage medium, and the features described in the present disclosure can be implemented by using a computer program product including such a storage medium. The storage medium can include high-speed random access memories, such as DRAM, SRAM, DDR RAM, or other random access solid-state storage devices, but is not limited thereto, and it can include non-volatile memories, such as one or more disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. The memory optionally includes one or more storage devices located away from the processor. The memory, or alternatively, the non-volatile memory device in the memory, includes non-transitory computer-readable storage medium. The features described in the present disclosure can be stored in any kind of machine-readable medium to control the hardware of the processing system, and can be integrated into software and / or firmware that allows the processing system to interact with other mechanisms using the results from the embodiments of the present disclosure. Such software or firmware can include application code, device drivers, operating systems, and execution environments / containers, but is not limited thereto.

[0285] Industrial Applicability

[0286] The method proposed in this disclosure is mainly described based on an example applied to an IEEE 802.11-based system (5G system), but can be applied to various WLANs or wireless communication systems other than IEEE 802.11-based systems.

Claims

1. A method performed by a first station STA in a Wireless Local Area Network WLAN system, the method comprising the steps of: Generating, by the first STA, a Multi-Access Point Group Temporary Key MAGTK; And Sending the MAGTK encrypted based on a key shared between the first STA and the at least one second STA to at least one second STA, Wherein, a security key for a third STA is encrypted based on the MAGTK and is shared with the first STA and the at least one second STA.

2. The method according to claim 1, wherein, The security key is encrypted by using a Temporary Key TK of the MAGTK and is sent from another second STA that has established an initial association with the third STA to the first STA.

3. The method according to claim 2, wherein, The security key obtained by the first STA is encrypted by using the TK of the MAGTK and is sent from the first STA to the at least one second STA.

4. The method according to claim 1, wherein, The security key is encrypted by using the TK of the MAGTK and is sent from another second STA that has established an initial association with the third STA to the first STA and the at least one second STA.

5. The method according to claim 1, wherein, The security key is encrypted by using the TK of the MAGTK and is sent from the first STA that has established an initial association with the third STA to the at least one second STA.

6. The method according to claim 1, wherein, The security key is encrypted with information of the third STA and a cipher suite agreed upon between the first STA or another second STA that has established an initial association with the third STA.

7. The method according to claim 1, wherein, An element including the MAGTK is encrypted based on the key shared between the first STA and the at least one second STA, or The MAGTK is encrypted based on the key shared between the first STA and the at least one second STA.

8. The method according to claim 1, wherein, The key shared between the first STA and the at least one second STA is a Key Encryption Key KEK or a Pre-Shared Key PSK.

9. The method according to claim 1, wherein, An element including the MAGTK further includes at least one of the following: key identification information, Mobility Domain MD identification information or Multi-Access Point MAP identification information, key length information or MAP group cipher suite.

10. The method according to claim 1, wherein, The PTK is generated based at least on MAP-PTK, the Media Access Control MAC address of the third STA, or the MAC address of the MAP, and The MAC address of the MAP is the MAC address of the first STA, or is a MAC address shared by the first STA and the at least one second STA.

11. The method according to claim 1, wherein, the MAGTK is generated based at least on a first group of master keys GMK, a MAP group key expansion, or the MAC address of the first STA, and the first GMK is the same as or different from a second GMK used by the first STA to generate a group temporal key GTK.

12. The method according to claim 1, wherein, the security key for the third STA is a pairwise temporal key PTK or a TK of the PTK that is equally generated between a first STA or a second STA that establishes an initial association with the third STA and the third STA.

13. The method according to claim 1, wherein, the first STA is a primary access point AP or a shared AP of a MAP, the second STA is a slave AP or a shared AP of the MAP, and the third STA is a non-AP STA.

14. The method according to claim 1, wherein, the third STA is associated with the first STA or with one of the at least one second STA.

15. A first station STA device in a wireless local area network WLAN system, the device comprising: at least one transceiver; and at least one processor connected to the at least one transceiver, wherein the at least one processor is configured to: generate a multi-access point group temporal key MAGTK; and send, via the at least one transceiver, the MAGTK encrypted based on a key shared between the first STA and the at least one second STA to at least one second STA, wherein a security key for a third STA is encrypted based on the MAGTK and is shared with the first STA and the at least one second STA.

16. A method performed by a second station STA in a wireless local area network WLAN system, the method comprising the steps of: obtaining a key shared between a first STA and at least one second STA including the second STA; and and receiving, from the first STA, a multi-access point group temporal key MAGTK encrypted based on the key shared between the first STA and the at least one second STA, wherein the MAGTK is generated by the first STA, and wherein a security key for a third STA is encrypted based on the MAGTK and is shared with the first STA and the at least one second STA.

17. A second station STA device in a wireless local area network WLAN system, the device comprising: at least one transceiver; and at least one processor connected to the at least one transceiver, wherein the at least one processor is configured to: obtain a key shared between a first STA and at least one second STA including the second STA; and receive, via the at least one transceiver, from the first STA, a multi-access point group temporal key MAGTK encrypted based on the key shared between the first STA and the at least one second STA, wherein the MAGTK is generated by the first STA, and Among them, the security key for the third STA is encrypted based on the MAGTK and is shared with the first STA and the at least one second STA.

18. A processing apparatus configured to control a station STA in a wireless local area network WLAN system, the processing apparatus comprising: at least one processor; and at least one computer memory operatively connected to the at least one processor, the at least one computer memory storing instructions for performing the method according to claim 1 when executed by the at least one processor.

19. At least one non-transitory computer-readable medium storing at least one instruction, wherein the at least one instruction, when executed by at least one processor, controls a device in a wireless local area network WLAN system to perform the method according to claim 1.

Images