WO2020071776A1 - 무선랜 시스템에서 무선 연결을 위한 장치 및 방법 - Google Patents

무선랜 시스템에서 무선 연결을 위한 장치 및 방법

Info

Publication number
WO2020071776A1
WO2020071776A1 PCT/KR2019/012890 KR2019012890W WO2020071776A1 WO 2020071776 A1 WO2020071776 A1 WO 2020071776A1 KR 2019012890 W KR2019012890 W KR 2019012890W WO 2020071776 A1 WO2020071776 A1 WO 2020071776A1
Authority
WO
WIPO (PCT)
Prior art keywords
sta
dpp
information
response
vendor
Prior art date
Application number
PCT/KR2019/012890
Other languages
English (en)
French (fr)
Inventor
조영준
김나명
박기원
이병주
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Publication of WO2020071776A1 publication Critical patent/WO2020071776A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data

Definitions

  • This specification relates to a method for establishing a wireless connection in a wireless LAN system and an apparatus supporting the same.
  • Wi-Fi Direct As a direct communication technology that enables devices to easily connect to each other without a wireless access point (AP), which is basically required in a wireless LAN system, Wi-Fi Direct or Wi-Fi P2P (peer-to) -peer) is being discussed.
  • AP wireless access point
  • Wi-Fi Direct or Wi-Fi P2P (peer-to) -peer
  • Wi-Fi Direct devices can be connected without going through a complicated setup process, and in order to provide various services to a user, it is possible to support an operation of exchanging data with each other at a communication speed of a general WLAN system.
  • the device when the device is connected to the network, the device may be connected to the network after activating the device's Soft-AP (Software enabled Access Point).
  • Soft-AP Software enabled Access Point
  • Soft-AP is a technology that implements the role of an AP in software to operate like an AP.
  • An object of the present specification is to provide a method and apparatus for establishing a wireless connection in a wireless LAN system. Specifically, in order to establish a connection between the second STA and the AP through the first STA, the connection between the first STA and the AP must be released. Therefore, after the connection between the second STA and the AP is established, the first STA must perform a procedure for establishing a connection with the AP again.
  • the embodiment of the present specification proposes a method of establishing a connection between the second STA and the AP through the first STA without releasing the connection between the first STA and the AP.
  • a method for a first STA connected to a transmitting STA includes receiving a beacon from a second STA, and in response to the beacon, a Device Provisioning Protocol (DPP) bootstrap of the second STA Transmitting a probe request frame for requesting DPP Bootstrap URI (URI) information to the second STA, in response to the probe request frame, receiving a probe response frame from the second STA, wherein the probe response frame is a DPP boot It may include the step of including the DPP Bootstrap URI (DPP Bootstrap URI) information, and establishing a connection between the second STA and the transmitting STA, based on the DPP Bootstrap URI (DPP) information.
  • DPP Device Provisioning Protocol
  • the connection between the first STA and the AP may not be released. Also, a connection process between the first STA and the second STA may not be performed. In addition, after the first STA releases the connection with the AP and the connection between the AP and the second STA is established, the first STA may not establish a connection with the AP again.
  • connection establishment and release process is not repeatedly performed, so that the connection process can be simplified and user convenience can be increased.
  • FIG. 1 is a conceptual diagram showing the structure of a wireless LAN system.
  • FIG. 2 is a conceptual diagram showing a scanning method in a wireless LAN.
  • FIG. 3 is a conceptual diagram illustrating an authentication and association procedure after scanning of the AP and the STA.
  • FIG. 4 is a diagram for explaining a neighbor discovery process.
  • 5 is a conceptual diagram of a DPP procedure.
  • FIG. 6 is a flowchart illustrating a process of performing a DPP procedure between wireless devices.
  • FIG. 7 shows a procedure for establishing a connection based on a soft-AP connection.
  • FIG. 9 illustrates a procedure for establishing a connection based on Soft-AP connection using DPP.
  • FIG. 10 shows a vendor specific information element of a beacon.
  • FIG. 11 shows a vendor-specific information element of the probe request frame.
  • FIG. 12 shows a vendor specific information element of a probe response frame.
  • FIG. 13 shows a format and an example of the DPP bootstrap URI.
  • 16 shows another procedure for establishing a connection based on Soft-AP connection using DPP.
  • FIG. 18 is a block diagram illustrating a wireless device to which the present embodiment can be applied.
  • 19 is a block diagram showing an example of an apparatus included in a processor.
  • parentheses used in the present specification may mean “for example”. Specifically, when indicated as “control information (A Signal)”, “A Signal” as an example of “control information” may be proposed. Further, even when indicated as “control information (ie, A signal)", “A signal” may be proposed as an example of "control information”.
  • 1 is a conceptual diagram showing the structure of a wireless LAN system.
  • 1 (A) shows the structure of an infrastructure network of IEEE (institute of electrical and electronic engineers) 802.11.
  • the wireless LAN system 10 of FIG. 1A may include at least one basic service set (hereinafter, 'BSS', 100, 105).
  • BSS is a set of access points (hereinafter referred to as 'AP') and stations (hereinafter referred to as 'STA') that can successfully communicate with each other through synchronization, and does not indicate a specific area.
  • the first BSS 100 may include a first AP 110 and a first STA 100-1.
  • the second BSS 105 may include a second AP 130 and one or more STAs 105-1 and 105-2.
  • the infrastructure BSS may include at least one STA, an AP (110, 130) providing a distributed service (Distribution Service), and a distributed system (Distribution System, DS, 120) connecting multiple APs. have.
  • the distributed system 120 may connect a plurality of BSSs 100 and 105 to implement an extended service set (hereinafter referred to as 'ESS') which is an extended service set.
  • 'ESS' an extended service set
  • the ESS 140 may be used as a term indicating one network in which at least one AP 110 or 130 is connected through the distributed system 120. At least one AP included in one ESS 140 may have the same service set identification (hereinafter 'SSID').
  • the portal 150 may serve as a bridge that performs a connection between a WLAN network (IEEE 802.11) and another network (eg, 802.X).
  • IEEE 802.11 IEEE 802.11
  • another network eg, 802.X
  • FIG. 1B is a conceptual diagram illustrating an independent BSS.
  • the wireless LAN system 15 of FIG. 1B performs communication by establishing a network between STAs without APs 110 and 130, unlike FIG. 1A. It may be possible.
  • a network that establishes a network between STAs without APs 110 and 130 to perform communication is defined as an ad-hoc network or an independent basic service set (BSS).
  • BSS basic service set
  • All STAs of IBSS may be made of mobile STAs, and access to a distributed system is not allowed. All STAs of IBSS form a self-contained network.
  • the STA referred to in this specification includes a medium access control (hereinafter referred to as 'MAC') and a physical layer interface to a wireless medium in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard.
  • 'MAC' medium access control
  • IEEE 802.11 Institute of Electrical and Electronics Engineers 802.11 standard
  • STAs referred to herein are mobile terminals, wireless devices, wireless transmit / receive units (WTRUs), user equipment (UEs), and mobile stations (MSs). , It may also be called various names such as a mobile subscriber unit or simply a user.
  • FIG. 2 is a conceptual diagram showing a scanning method in a wireless LAN.
  • the scanning method may be divided into passive scanning (200) and active scanning (active scanning) 250.
  • passive scanning 200 may be performed based on a beacon frame 230 periodically broadcast by the AP 210.
  • the AP 210 of the wireless LAN may broadcast the beacon frame 230 to the non-AP STA 240 every specific period (eg, 100 msec).
  • the beacon frame 230 may include information about the current network.
  • the non-AP STA 240 may periodically receive the beacon frame 230. In order to perform the authentication / association process, the non-AP STA 240 may perform scanning for the AP 210 and the channel based on the network information included in the beacon frame 230.
  • the passive scanning method 200 is a technique in which the non-AP STA 240 receives the beacon frame 230 transmitted from the AP 210 without first transmitting the frame. Therefore, the passive scanning 200 has an advantage that the overall overhead caused by data transmission / reception in the network is small.
  • the active scanning 250 is a technique of transmitting a probe request frame 270 from the non-AP STA 290 to the AP 260 to perform scanning in a proactive manner.
  • the AP 260 may receive the probe request frame 270 from the non-AP STA 290.
  • the AP 260 may wait for a random time to prevent frame collision.
  • the AP 260 may transmit a probe response frame 280 including network information to the non-AP STA 290 in response to the probe request frame 270.
  • the non-AP STA 290 may acquire network information based on the received probe response frame 280.
  • the non-AP STA 290 is proactively scanning, the time used for scanning is short.
  • the probe request frame 270 needs to be transmitted by the non-AP STA 290, there is a disadvantage in that network overhead for frame transmission and reception increases.
  • the AP and the STA may perform authentication and association procedures.
  • FIG. 3 is a conceptual diagram illustrating an authentication and association procedure after scanning of the AP and the STA.
  • the non-AP STA may perform an authentication and association procedure with one of a plurality of APs that has completed a scanning procedure through passive / active scanning.
  • authentication and association procedures may be performed through 2-way handshaking.
  • FIG. 3 (A) is a conceptual diagram showing an authentication and association procedure after passive scanning
  • FIG. 3 (B) is a conceptual diagram showing an authentication and association procedure after active scanning.
  • the authentication and association procedure can be performed regardless of whether an active scanning method or passive scanning is used.
  • AP 300, 350
  • the authentication request frame authentication request frame, 310
  • authentication response frame authentication response frame
  • association request frame association request frame
  • 330 and the association response frame 340
  • the authentication procedure may be performed by transmitting the authentication request frame 310 from the non-AP STAs 305 and 355 to the APs 300 and 350.
  • the APs 300 and 350 may transmit the authentication response frame 320 to the non-AP STAs 305 and 355 in response to the authentication request frame 310.
  • the authentication frame format is disclosed in IEEE 802.11 section 8.3.3.11.
  • the association procedure may be performed by transmitting the association request frame 330 from the non-AP STAs 305 and 355 to the APs 300 and 305.
  • the APs 300 and 350 may transmit the combined response frame 340 to the non-AP STAs 305 and 355 in response to the combined request frame 330.
  • the association request frame 330 may include information on the capability of non-AP STAs 305 and 355.
  • the APs 300 and 350 may determine whether to support the non-AP STAs 305 and 355 based on information on the performance of the non-AP STAs 305 and 355 included in the association request frame 330. You can.
  • the APs 300 and 350 accept and accept the combination request frame 340 in the combined response frame 340, and their support. Capability information may be included and transmitted to non-AP STAs 305 and 355.
  • normal data transmission and reception procedures may be performed between the AP and the STA.
  • FIG. 4 is a diagram for explaining a neighbor discovery process.
  • the example of FIG. 4 may be understood as an operation between a peer-to-peer (P2P) device and a P2P device.
  • P2P peer-to-peer
  • the neighbor discovery process may be initiated by an instruction of a Station Management Entity (SME) / application / user / vendor.
  • the neighbor discovery process may include a scan phase (S412) and a find phase (find phase) (S414-S416).
  • the scan step S412 may include an operation of scanning all available wireless channels according to the 802.11 method. Through this, the P2P device can identify the best operating channel.
  • the searching steps (S414-S416) may include a listening mode (S414) and a search (search) mode (S416).
  • the P2P device may alternately repeat the listening mode S414 and the searching mode S416.
  • the P2P devices 202 and 204 may perform active scanning using a probe request frame in a search mode (S416).
  • the search range may be limited to a social channel such as channel 1, channel 6, and channel 11 (eg, 2412 MHz, 2437 MHz, 2462 MHz) for fast search.
  • a social channel such as channel 1, channel 6, and channel 11 (eg, 2412 MHz, 2437 MHz, 2462 MHz) for fast search.
  • the P2P devices 202 and 204 may maintain a reception state on a selected one of three social channels in the listening mode S414.
  • the P2P device may respond with a probe response frame.
  • the P2P device can exchange the probe request frame and probe response frame with another P2P device. Through this, P2P devices can discover / exchange each other's device type, manufacturer, or friendly device name.
  • the P2P device may inform the SME / application / user / vendor of the P2P device discovery (S418).
  • P2P is mainly used for semi-static communication such as remote printing and photo sharing.
  • the utilization of P2P is gradually increasing.
  • social chat for example, wireless devices subscribed to a social network service (SNS) recognize wireless devices in a nearby area based on the location-based service and transmit and receive information
  • SNS social network service
  • P2P will be actively used for base news broadcasting and game interworking between wireless devices.
  • this P2P application is referred to as a new P2P application.
  • FIG. 5 is a conceptual diagram of a DPP (Device Provisioning Protocol) procedure.
  • the DPP architecture for the DPP procedure is performed during the DPP Bootstrapping protocol, DPP Authentication protocol, DPP Configuration protocol, and DPP Introduction protocol.
  • the device roles can be defined.
  • the DPP procedure there may be two types of roles for wireless devices. For example, there may be roles of a configurator and an enrollee. As another example, there may be roles of an initiator and a responder.
  • the configurator may be understood as the first wireless device 510.
  • the registrant may be understood as the second wireless device 520.
  • the first wireless device 510 that is a configurator may support setup of the second wireless device 520 that is a registrant.
  • the configurator and registrant can engage in the DPP bootstrap protocol, DPP authentication protocol, and DPP configuration protocol.
  • the configurator or registrant can act as an initiator in the DPP bootstrap protocol and DPP authentication protocol. However, only the enrollee can initiate the DPP configuration protocol and the DPP introduction protocol.
  • the DPP authentication protocol may require the initiator to obtain the responder's bootstrapping key as part of the bootstrap mechanism.
  • wireless devices may obtain each other's bootstrap keys.
  • the configurator can provision registrants for device-to-device communication or infrastructure communication.
  • the configurator can allow the enrollee to establish secure associations with other peers within the network.
  • a peer may be understood as a wireless device 530 already configured by the configurator.
  • the configurator and registrant can be associated with the DPP authentication protocol. Depending on the bootstrap scenario, the configurator or registrant can act as an initiator or responder, respectively.
  • a wireless device that initiates the DPP authentication protocol may act as an initiator.
  • the wireless device responding to the initiator's request may act as a responder.
  • the DPP authentication protocol may provide the responder's authentication to the initiator.
  • the DPP authentication protocol can provide the initiator's authentication to the responder.
  • the initiator can obtain the bootstrapping key of the responder.
  • the initiator and the responder can secure each other's bootstrap key.
  • the wireless device 510 can act as a configurator.
  • a wireless device that is not provisioned can be an access point or other wireless device.
  • the wireless device 510 serving as a configurator starts the DPP authentication protocol with the unprovisioned wireless device 520, the wireless device 510 may act as an initiator.
  • FIG. 6 is a flowchart illustrating a process of performing a DPP procedure between wireless devices.
  • the DPP procedure of FIG. 6 may be implemented by a 3-way handshaking method.
  • the first wireless device 610 may serve as an initiator, and the second wireless device 620 may serve as a responder. Also, the first wireless device 610 may serve as a configurator, and the second wireless device 620 may serve as an enrollee.
  • step S610 the first wireless device 610 and the second wireless device 620 may perform a DPP bootstrap protocol.
  • the first wireless device 610 serving as a configurator may obtain bootstrap information from the second wireless device 620 serving as a registrant using an Out Of Band (OOB) mechanism.
  • OOB Out Of Band
  • the bootstrap information may include information about the enrollee's bootstrapping public key for the DPP authentication protocol.
  • the bootstrap public key can be used only for the DPP authentication protocol by the configurator and registrant.
  • information on a global operating class channel or information on a channel list may be further included in bootstrap information.
  • the wireless device may indicate that it is listening on one of the listed channels for another device (eg, 610).
  • information on a global operating class channel or information on a channel list may not be included in bootstrap information.
  • the wireless device may not provide guidance to other devices (eg, 610) as to which channel it is listening to. Accordingly, other devices (eg, 610) must iterate through all available channels.
  • a device using QR Code bootstrapping may be required to include a single channel or at least a short list of possible channels in the bootstrap information.
  • the first wireless device 610 of FIG. 6 may start operating on a specified channel based on bootstrap information obtained from the second wireless device 620.
  • the second wireless device 620 of FIG. 6 may listen on a specific channel during step S610.
  • step S620 the first wireless device 610 and the second wireless device 620 may perform a DPP authentication protocol.
  • the first wireless device 610 serving as a configurator may transmit a DPP authentication request frame to the second wireless device 620 serving as a registrant.
  • the DPP authentication request frame may be transmitted through at least one channel corresponding to bootstrap information (eg, channel list).
  • step S621 the first wireless device 610 may transmit a DPP authentication request frame to the second wireless device 620. Subsequently, the first wireless device 610 may wait for a response to the DPP authentication request frame transmitted in step S621.
  • the first wireless device 610 may determine whether a DPP authentication response frame that is a response to the DPP authentication request frame transmitted in step S621 from the second wireless device 620 is received within a predetermined time. .
  • the predetermined time may be set based on the transmission time point of the DPP authentication request frame in step S621.
  • step S621 For a clear and concise description of FIG. 6, it may be assumed that the DPP authentication response frame is not received until a predetermined time elapses in response to the DPP authentication request frame transmitted in step S621.
  • step S622 is performed to retransmit the DPP authentication response frame.
  • step S622 the first wireless device 610 may retransmit the DPP authentication request frame to the second wireless device 620. Subsequently, the first wireless device 610 may wait for a response to the DPP authentication request frame transmitted in step S622.
  • the first wireless device 610 may determine whether the DPP authentication response frame, which is a response to the DPP authentication request frame retransmitted in step S622 from the second wireless device 620, is received within a predetermined time. .
  • the predetermined time may be set based on the transmission time point of the DPP authentication request frame in step S622.
  • step S622 For a clear and concise description of FIG. 6, it may be assumed that the DPP authentication response frame is not received until a predetermined time elapses in response to the DPP authentication request frame retransmitted in step S622.
  • step S623 is performed to retransmit the DPP authentication response frame.
  • the first wireless device 610 may retransmit the DPP authentication request frame to the second wireless device 620. Subsequently, the first wireless device 610 may determine whether the DPP authentication response frame is received from the second wireless device 620 within a predetermined time in response to the DPP authentication request frame retransmitted in step S623.
  • the predetermined time may be set based on the transmission time point of the DPP authentication request frame in step S623.
  • step S624 is performed.
  • the first wireless device 610 may receive a DPP authentication response frame from the second wireless device 620 in response to the DPP authentication request frame retransmitted in step S623.
  • the first wireless device 610 may transmit a DPP authentication confirmation frame to the second wireless device 620 to complete the DPP authentication protocol.
  • a secure channel may be established between the initiator (or configurator) and the responder (or registrant).
  • step S630 the first wireless device 610 and the second wireless device 620 may perform a DPP configuration protocol.
  • step S630 the first wireless device 610 and the second wireless device 620 may use the same MAC address. In addition, in step S630, the first wireless device 610 and the second wireless device 620 may use the same channel used during the DPP authentication protocol.
  • the second wireless device 620 may transmit a DPP configuration request frame to the first wireless device 610.
  • the DPP configuration request frame can be transmitted only by the enrollee.
  • the first wireless device 610 may transmit the DPP configuration response frame to the second wireless device 620 in response to the DPP configuration request frame.
  • the DPP configuration response frame may include a DPP configuration object.
  • the DPP configuration object may include a plurality of parameter information as shown in Table 1 below.
  • the network information of the wireless LAN system including the AP (not shown) previously associated with the first wireless device 610 is transmitted to the second wireless device 620.
  • the network information may include SSID information or password information.
  • the second wireless device 620 is a first wireless device (610) without performing a separate association (association) procedure with the AP (not shown) coupled to the first wireless device 610, the second wireless device 620 is the first wireless device ( 610) may be connected to the wireless LAN system based on the network information received.
  • FIG. 7 shows a procedure for establishing a connection based on a soft-AP connection.
  • the AP 730 may be in a state in which a connection is established with the first STA 710.
  • the second STA 720 may activate a soft-AP (software AP).
  • the second STA 720 may activate soft-AP based on a user input.
  • the second STA 720 may transmit a beacon.
  • the second STA 720 may transmit a beacon through a broadcast method.
  • the first STA 710 may release the connection with the AP 730 after receiving the beacon.
  • the first STA 710 may perform an authentication procedure (or an authentication protocol) with the second STA 720. Specifically, the first STA 710 may transmit an authentication request frame to the second STA 720. The second STA 720 may transmit an authentication response frame to the first STA 710 in response to the authentication request frame.
  • an authentication procedure or an authentication protocol
  • the first STA 710 may perform a configuration procedure (or configuration protocol) with the second STA 720. Specifically, the first STA 710 may transmit an association request frame to the second STA 720. The second STA 720 may transmit an association response frame to the first STA 710 in response to the association request frame.
  • a configuration procedure or configuration protocol
  • the first STA 710 may perform a network information transfer protocol with the second STA 720.
  • the second STA 720 may acquire network connection information for establishing a connection with the AP 730.
  • the network connection information may include SSID and / or PW (password) information.
  • the second STA 720 may deactivate the Soft-AP and establish a connection with the AP 730. Thereafter, the first STA 710 may need to establish a connection again with the AP 730 through a connection establishment procedure.
  • the first STA 810 must release the connection with the AP 830 in order to connect with the Soft-AP of the second STA 820. Specifically, the first STA 810 must receive the beacon from the second STA 820 and release the connection with the AP 830 to perform the authentication procedure and the combining procedure with the second STA 820.
  • the first STA 810 must perform an authentication procedure and an association procedure according to the 802.11 standard in order to connect with the Soft-AP of the second STA 820.
  • the first STA 810 must establish a connection between the second STA 820 and the AP 830 and then establish a connection with the AP 830 again. Accordingly, there is a problem in that a connection process (802.11 Association) and a release process (802.11 Authentication) between STAs are repeatedly performed to transmit network information to the second STA 820.
  • an embodiment according to the present specification may propose a method for solving the above-described first to third problems.
  • An embodiment according to the present specification may propose a method for establishing a connection between a first STA and a second STA and a transmitting STA (or AP) using DPP.
  • the first STA may receive information necessary for connection with the transmitting STA from the second STA.
  • the first STA may establish a connection between the second STA and the transmission STA based on the information necessary for connection with the transmission STA.
  • the first STA may be connected to the transmitting STA.
  • the first STA may receive a beacon from the second STA.
  • the first STA may transmit a probe request frame for requesting DPP Bootstrap URI (DPP Bootstrap URI) information of the second STA to the second STA in response to the beacon.
  • DPP Bootstrap URI DPP Bootstrap URI
  • the probe response frame may include DPP bootstrap URI information.
  • the first STA may establish a connection between the second STA and the transmitting STA based on the received DPP bootstrap URI information.
  • the transmitting STA may include an access point (AP).
  • the first STA may serve as a configurator in the DPP procedure.
  • the second STA may serve as an enrollee in the DPP procedure.
  • the first STA may include a smartphone, a laptop, a laptop, and the like.
  • the second STA broadcasts a beacon and may include a device capable of operating by pairing with another wireless device.
  • the second STA may include a refrigerator, an air conditioner, a washing machine, headphones, and the like.
  • FIG. 9 illustrates a procedure for establishing a connection based on Soft-AP connection using DPP.
  • the first STA 910 may be in a state in which a connection is established with the AP 930.
  • the first STA 910 may receive a beacon from the second STA 920.
  • the beacon may include information on whether a service set identifier (SSID) of the second STA 920 or DPP is supported by the second STA 920.
  • the beacon may include a vendor specific information element.
  • the vendor-specific information element may include information on whether the second STA 920 supports DPP.
  • a vendor-specific information element including information on whether DPP is supported may be called DPP IE.
  • the first STA 910 is based on the beacon. It may be confirmed whether the second STA 920 supports DPP.
  • the vendor-specific information element included in the beacon may also be referred to as a first vendor-specific information element. In FIG. 10, specific content of a vendor-specific information element included in the beacon may be described.
  • FIG. 10 shows a vendor specific information element of a beacon.
  • a vendor-specific information element (hereinafter referred to as DPP IE) included in a beacon may include information regarding whether the second STA 920 supports DPP.
  • the DPP IE may include an Element ID information field, a Length information field and / or a Description information field.
  • the Element ID information field may be an information field for assigning a Vendor Specific IE ID usable in the 802.11 standard.
  • the Length information field may be an information field for a Description information field length.
  • the Description information field may include 2 bits as a DPP Indication parameter.
  • the Description information field may include an information field regarding the DPP role preferred by the STA (eg, the second STA 920) that has transmitted the DPP IE. For example, when the information field related to the DPP role is set to ⁇ 00 ⁇ , it may indicate that the STA prefers the role of the enrollee (Enrollee). For another example, when the information field related to the DPP role is set to ⁇ 01 ⁇ , it may indicate that the STA prefers the configurator role. As another example, when the information field about the DPP role is set to ⁇ 11 ⁇ , it may indicate that the STA prefers both the configurator and registrant roles.
  • the Description information field may include a Reserved bit.
  • the reserved bit may further include contents related to DPP.
  • the first STA 910 may transmit a probe request frame to the second STA 920.
  • the first STA 910 may check information regarding whether the second STA 920 supports DPP and / or DPP role. Thereafter, the first STA 910 may transmit a probe request frame to the second STA 920. For example, the first STA 910 may confirm that the second STA 920 supports DPP and performs a DPP registrar role based on the beacon.
  • the first STA 910 may request the bootstrap URI information of the second STA 920 from the second STA 920 through the probe request frame.
  • the second STA 920 may transmit a probe request frame to the first STA 910.
  • the second STA 920 may request DPP boost strap URI information of the first STA 910 through the probe request frame.
  • the probe request frame may include a vendor specific information element.
  • the vendor-specific information element may include information for requesting bootstrap URI information of the second STA 920.
  • a vendor specific information element including information for requesting bootstrap URI information may be called DPP Bootstrap IE.
  • the second STA 920 may confirm that the first STA 910 requests DPP bootstrap URI information through the probe request frame.
  • the vendor specific information element included in the probe request frame may also be referred to as a second vendor specific information element.
  • FIG. 11 detailed contents of a vendor-specific information element included in the probe request frame may be described.
  • FIG. 11 shows a vendor-specific information element of the probe request frame.
  • a vendor-specific information element (hereinafter DPP Bootstrap IE) included in a probe request frame may include information for requesting bootstrap URI information.
  • the DPP Bootstrap IE may include an Element ID information field, a Length information field and / or a Description information field.
  • the Element ID information field and / or Length information field may be configured similarly to the Element ID information field and / or Length information field of FIG. 10.
  • the Description information field may include a DPP bootstrap parameter (1 bit).
  • the DPP bootstrap parameter can be defined as a Bootstrap URI Request. For example, when the DPP bootstrap parameter is set to ⁇ 1 ⁇ , the DPP bootstrap parameter may indicate that a bootstrap URI is requested.
  • the Description information field may include a Reserved bit. The reserved bit may further include contents related to DPP.
  • the first STA 910 may receive a probe response frame from the second STA 920.
  • the second STA 920 may transmit a probe response frame to the first STA 910 in response to the probe request frame received from the first STA 910.
  • the probe response frame may include DPP bootstrap URI information.
  • the probe response frame may include a vendor specific information element.
  • the vendor-specific information element may include bootstrap URI information of the second STA 920.
  • the vendor-specific information element including bootstrap URI information may be called DPP Bootstrap URI IE.
  • the first STA 910 may check DPP bootstrap URI information of the second STA 920 through the probe response frame.
  • the vendor specific information element included in the probe response frame may also be referred to as a third vendor specific information element.
  • FIG. 12 detailed contents of a vendor-specific information element included in the probe response frame may be described.
  • FIG. 12 shows a vendor specific information element of a probe response frame.
  • a vendor-specific information element (hereinafter DPP Bootstrap URI IE) included in the probe response frame may include bootstrap URI information of the second STA 920.
  • the DPP Bootstrap URI IE may include an Element ID information field, a Length information field, and / or a Description information field.
  • the Element ID information field and / or Length information field may be configured similarly to the Element ID information field and / or Length information field of FIG. 10.
  • the Description information field may include bootstrap URI information.
  • the Description information field may include a Reserved bit.
  • the reserved bit may further include contents related to DPP.
  • a format and an example of a specific DPP bootstrap URI can be described in FIG. 13.
  • FIG. 13 shows a format and an example of the DPP bootstrap URI.
  • the DPP bootstrap URI is a channel list, class. It may include information about the MAC address. In addition, the DPP bootstrap URI may include information that serves as a public key. The DPP bootstrap URI can be expressed in the format shown in the example of FIG. 13.
  • the second STA 920 may deactivate the Soft-AP. Thereafter, the first STA 910 and the second STA 920 perform a DPP authentication procedure (or an authentication protocol) and a DPP configuration procedure (or a configuration protocol) based on the DPP bootstrap URI. Can be done.
  • the second STA 920 may acquire network connection information based on the DPP authentication procedure and the DPP configuration procedure.
  • the network connection information may include information about SSID or PW (Password).
  • the DPP authentication procedure and the DPP configuration procedure may be related to S620 to S630 illustrated in FIG. 6.
  • the second STA 920 may establish a connection with the AP 930 based on the acquired network connection information.
  • the connection between the first STA 910 (ie, the configurator) and the AP 930 may not be released. Also, a connection process between the first STA 910 (that is, the configurator) and the second STA 920 (that is, the registrant) may not be performed. In addition, the first STA 910 (that is, the configurator) releases the connection with the AP 930, and after the connection between the AP 930 and the second STA 920 is established, the connection with the AP 930 again. It may not be established. Also, the second STA 920 may not use the Soft-AP after transmitting the probe response frame. Therefore, the second STA 920 may use the existing network connection technology and DPP at the same time.
  • a procedure for establishing a connection may be changed according to whether the first STA 1410 supports DPP. Depending on whether the first STA 1410 supports DPP, a process of Case 1 or Case 2 may be performed.
  • the first STA 1410 may receive a beacon from the second STA 1420.
  • the beacon may include information regarding whether the second STA 1420 supports DPP. Therefore, when the first STA 1410 supports DPP, the first STA 1410 may perform the process of Case 1. If the first STA 1410 does not support the first STA 1410 DPP, the first STA 1410 may perform the process of Case 2.
  • the process of Case 1 may be performed.
  • the process of Case 1 may correspond to the process shown in FIG. 9.
  • Case 2 may be performed.
  • the process of Case 2 may correspond to the process shown in FIG. 7.
  • the first STA 1410 and the second STA 1420 may perform authentication and association procedures according to the 802.11 standard. Thereafter, the first STA 1410 and the second STA 1420 may perform a procedure according to a network information transfer protocol.
  • the network information delivery protocol may include smart ThinQ, Open Connectivity Foundation (OCF), and the like.
  • OCF Open Connectivity Foundation
  • the second STA 1420 may acquire network connection information.
  • the second STA 1420 may establish a connection with the AP 1430 based on network connection information.
  • the first STA 1410 and the second STA 1420 may terminate the connection. Thereafter, the second STA 1420 may deactivate the Soft-AP. In addition, the first STA 1410 may establish a connection with the AP 1430 again.
  • DPP may be used in Case 1 (a case where the first STA 1410 supports DPP).
  • Case 2 if the first STA 1410 does not support DPP, a Soft-AP connection technology may be used. Therefore, the first STA 1410 can use both technologies without interference between DPP and Soft-AP connection technologies.
  • a procedure for transmitting the DPP bootstrap URI information of the first STA 1510 by the first STA 1510 (ie, the configurator) to the second STA 1520 (ie, the registrant) is illustrated. have.
  • the first STA 1510 may receive a beacon from the second STA 1520.
  • the first STA 1510 may transmit a probe request frame to the second STA 1520 in response to the beacon.
  • the probe request frame may include a DPP Bootstrap URI IE.
  • the first STA 1510 may transmit the DPP bootstrap URI of the first STA 1510 through the DPP Bootstrap URI IE.
  • the probe request frame may include a DPP Bootstrap URI request IE for requesting the DPP bootstrap URI of the second STA 1520.
  • the first STA 1510 may request the DPP bootstrap URI of the second STA 1520 through the DPP Bootstrap URI request IE.
  • the probe request frame may not include the DPP Bootstrap URI request IE for requesting the DPP bootstrap URI of the second STA 1520. Therefore, the first STA 1510 may not request the DPP bootstrap URI of the second STA 1520 through the DPP Bootstrap URI request IE.
  • 16 shows another procedure for establishing a connection based on Soft-AP connection using DPP.
  • the second STA 1620 may transmit a beacon after Soft-AP is activated.
  • the beacon may include a DPP bootstrap URI IE.
  • DPP bootstrap URI IE may include DPP bootstrap URI information. That is, the second STA 1620 may transmit DPP bootstrap URI information of the second STA 1620 through a beacon.
  • the first STA 1610 may receive a beacon from the second STA 1620.
  • the first STA 1610 may obtain second STA 1620 DPP bootstrap URI information through a beacon. Therefore, the first STA 1610 and the second STA 1620 may not exchange the probe request frame and the probe response frame for obtaining DPP bootstrap URI information of the second STA 1620.
  • the first STA 1610 may start a DPP protocol (eg, a DPP authentication procedure or a DPP configuration procedure).
  • the first STA 1610 and the second STA 1620 may perform a DPP authentication procedure and a DPP configuration procedure based on the DPP bootstrap URI information of the second STA 1620.
  • the second STA 1620 may acquire network connection information based on the DPP authentication procedure and the DPP configuration procedure. Therefore, the second STA 1620 may establish a connection with the AP 1630.
  • the first STA may transmit a probe request frame to the second STA. Specifically, the first STA may transmit a probe request frame for requesting DPP bootstrap URI information of the second STA to the second STA in response to the beacon. According to an embodiment, the first STA may confirm that the first STA supports DPP in response to the beacon. Since both the first STA and the second STA support DPP, the first STA may transmit a probe request frame for requesting DPP bootstrap URI information to the second STA.
  • the probe request frame may include a second vendor-specific information element.
  • the second vendor-specific information element may include information on requesting DPP bootstrap URI information.
  • the first STA may receive the probe response frame from the second STA in response to the probe request frame.
  • the probe response frame may include DPP bootstrap URI information.
  • the first STA may check DPP bootstrap URI information of the second STA through the probe response frame.
  • the probe response frame may include a third vendor-specific information element.
  • the third vendor-specific information element may include the DPP bootstrap URI information.
  • FIG. 18 is a block diagram illustrating a wireless device to which the present embodiment can be applied.
  • the wireless device is an STA that can implement the above-described embodiment and can operate as an AP or a non-AP STA. Further, the wireless device may correspond to the above-described user or a transmitting terminal that transmits a signal to the user.
  • the wireless device of FIG. 18 includes a processor 1810, a memory 1820, and a transceiver 1830 as shown.
  • the illustrated processor 1810, memory 1820, and transceiver 1830 may be implemented as separate chips, or at least two or more blocks / functions may be implemented through one chip.
  • the transceiver 1830 may include one or more antennas that transmit and / or receive wireless signals.
  • the transceiver 1830 may include an amplifier for amplifying a received signal and / or a transmitted signal and a band pass filter for transmitting on a specific frequency band.
  • the processor 1810 may implement functions, processes, and / or methods proposed herein.
  • the processor 1810 may perform an operation according to the present embodiment described above. That is, the processor 1810 may perform the operations disclosed in the embodiments of FIGS. 1 to 13.
  • the memory 1820 may include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media, and / or other storage devices.
  • ROM read-only memory
  • RAM random access memory
  • flash memory memory cards, storage media, and / or other storage devices.
  • 19 is a block diagram showing an example of an apparatus included in a processor.
  • FIG. 19 For convenience of description, the example of FIG. 19 is described based on a block for a transmission signal, but it is obvious that a received signal can be processed using the block.
  • the illustrated data processing unit 1910 generates transmission data (control data and / or user data) corresponding to the transmission signal.
  • the output of the data processing unit 1910 may be input to the encoder 1920.
  • the encoder 1920 may perform coding through a binary convolutional code (BCC) or a low-density parity-check (LDPC) technique. At least one encoder 1920 may be included, and the number of encoders 1920 may be determined according to various information (eg, the number of data streams).
  • BCC binary convolutional code
  • LDPC low-density parity-check
  • the output of the encoder 1920 may be input to the interleaver 1930.
  • the interleaver 1930 performs an operation of dispersing consecutive bit signals on radio resources (eg, time and / or frequency) to prevent burst errors due to fading.
  • Radio resources eg, time and / or frequency
  • At least one interleaver 1930 may be included, and the number of interleavers 1930 may be determined according to various information (eg, the number of spatial streams).
  • the output of the interleaver 1930 may be input to a constellation mapper 1940.
  • the constellation mapper 1940 performs constellation mapping such as biphase shift keying (BPSK), quadrature phase shift keying (QPSK), and quadrature amplitude modulation (n-QAM).
  • BPSK biphase shift keying
  • QPSK quadrature phase shift keying
  • n-QAM quadrature amplitude modulation
  • the output of the constellation mapper 1940 may be input to the spatial stream encoder 1950.
  • the spatial stream encoder 1950 performs data processing to transmit a transmission signal through at least one spatial stream.
  • the spatial stream encoder 1950 may perform at least one of space-time block coding (STBC), cyclic shift diversity (CSD) insertion, and spatial mapping for the transmission signal.
  • STBC space-time block coding
  • CSS cyclic shift diversity
  • the output of the spatial stream encoder 1950 may be input to the IDFT 1960 block.
  • the IDFT (1960) block performs an inverse discrete Fourier transform (IDFT) or an inverse fast Fourier transform (IFFT).
  • IDFT inverse discrete Fourier transform
  • IFFT inverse fast Fourier transform

Landscapes

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

Abstract

본 명세서에 따른 일례는, 제1 STA에서, 제2 STA과 전송 STA(또는 AP)를 연결하는 방법과 관련된다. 제1 STA은 제2 STA으로부터 비콘을 수신할 수 있다. 제1 STA은 제2 STA에게 DPP 부트스트랩 URI 정보를 요청하고, DPP 부트스트랩 URI 정보를 수신할 수 있다. 제1 STA은 DPP 부트스트랩 URI 정보에 기초하여 제2 STA과 전송 STA 사의의 연결을 수립할 수 있다.

Description

무선랜 시스템에서 무선 연결을 위한 장치 및 방법
본 명세서는 무선랜 시스템에서 무선 연결을 수립하기 위한 방법 및 이를 지원하는 장치에 관한 것이다.
무선랜 시스템에서 기본적으로 요구되는 무선 액세스 포인트(AP) 없이, 디바이스(device)들이 서로 용이하게 연결할 수 있도록 하는 직접 통신 기술로서, 와이파이 다이렉트(Wi-Fi Direct) 또는 Wi-Fi P2P(peer-to-peer)의 도입이 논의되고 있다.
와이파이 다이렉트에 의하면 복잡한 설정 과정을 거치지 않고도 디바이스들이 연결될 수 있고, 사용자에게 다양한 서비스를 제공하기 위해서, 일반적인 무선랜 시스템의 통신 속도로 서로 데이터를 주고 받는 동작을 지원할 수 있다.
또한, 디바이스를 네트워크에 연결할 때, 디바이스의 Soft-AP(Software enabled Access Point)를 활성화 한 뒤 네트워크에 디바이스가 연결될 수 있다. Soft-AP는 AP의 역할을 소프트웨어로 구현하여 AP와 같이 동작하도록 하는 기술이다.
본 명세서의 목적은 무선랜 시스템에서 무선 연결을 수립하기 위한 방법 및 장치를 제공하는데 있다. 구체적으로, 제1 STA을 통해 제2 STA과 AP 사이의 연결을 수립하기 위해서는 제1 STA과 AP 사이의 연결이 해제되어야 한다. 따라서, 제1 STA은 제2 STA과 AP 사이의 연결이 수립된 뒤, 다시 AP와의 연결을 수립하기 위한 절차를 수행해야 하는 문제점이 있다.
따라서, 본 명세서의 실시 예는 제1 STA과 AP 사이의 연결을 해제하지 않고 제1 STA을 통해 제2 STA과 AP 사이의 연결을 수립하는 방안을 제안한다.
일 실시 예에 따른 무선랜 시스템에서, 전송 STA과 연결된 제1 STA을 위한 방법은 제2 STA로부터 비콘을 수신하는 단계, 상기 비콘에 응답하여, 상기 제2 STA의 DPP(Device Provisioning Protocol) 부트스트랩 URI(DPP Bootstrap URI) 정보 요청을 위한 프로브 요청 프레임을 상기 제2 STA에게 전송하는 단계, 상기 프로브 요청 프레임에 응답하여, 상기 제2 STA으로부터 프로브 응답 프레임을 수신하되, 상기 프로브 응답 프레임은 DPP 부트스트랩 URI(DPP Bootstrap URI) 정보를 포함하는 단계, 및 상기 DPP 부트스트랩 URI(DPP Bootstrap URI) 정보에 기초하여, 상기 제2 STA과 상기 전송 STA 사이의 연결을 수립하는 단계를 포함할 수 있다.
본 명세서의 다양한 일례에 따르면, 제1 STA 을 통해 제2 STA 과 AP 사이의 연결을 수행하는 경우, 제1 STA과 AP 사이의 연결이 해제되지 않을 수 있다. 또한, 제1 STA과 제2 STA 간의 연결 과정이 수행되지 않을 수 있다. 또한, 제1 STA은 AP와의 연결을 해제하고, AP와 제2 STA의 연결이 수립된 이후, 다시 AP와의 연결을 수립하지 않을 수 있다.
따라서, 제1 STA을 통해 제2 STA과 AP 사이의 연결을 수립하는 경우, 연결 설정 및 해제 과정이 반복적으로 수행되지 않음으로써, 연결 과정이 간소화될 수 있으며, 사용자 편의성이 증가할 수 있다.
도 1은 무선랜 시스템의 구조를 보여주는 개념도이다.
도 2는 무선랜에서 스캐닝 방법을 나타낸 개념도이다.
도 3은 AP와 STA의 스캐닝 후 인증 및 결합 절차를 나타낸 개념도이다.
도 4는 이웃 발견 과정을 설명하기 위한 도면이다.
도 5는 DPP 절차의 개념도이다.
도 6은 무선 장치 사이에서 DPP 절차를 수행하는 과정을 보여주는 순서도이다.
도 7은 soft-AP 연결을 기반으로 연결을 수립하는 절차를 도시한다.
도 8은 Soft-AP 연결을 기반으로 연결을 수립하는 절차의 문제점을 도시한다.
도 9는 DPP를 활용한 Soft-AP 연결을 기반으로 연결을 수립하는 절차를 도시한다.
도 10은 비콘의 벤더 고유 정보 엘리먼트 도시한다.
도 11은 프로브 요청 프레임의 벤더 고유 정보 엘리먼트를 도시한다.
도 12는 프로브 응답 프레임의 벤더 고유 정보 엘리먼트 도시한다.
도 13은 DPP 부트스트랩 URI에 관한 형식 및 예시를 도시한다.
도 14는 DPP를 활용한 Soft-AP 연결을 기반으로 연결을 수립하는 다른 절차를 도시한다.
도 15는 DPP를 활용한 Soft-AP 연결을 기반으로 연결을 수립하는 또 다른 절차를 도시한다.
도 16은 DPP를 활용한 Soft-AP 연결을 기반으로 연결을 수립하는 또 다른 절차를 도시한다.
도 17은 제1 STA의 동작의 예를 도시한다.
도 18은 본 실시 예가 적용될 수 있는 무선 장치를 나타내는 블록도이다.
도 19는 프로세서에 포함되는 장치의 일례를 나타내는 블록도이다.
본 명세서에서 어떤 구성이 특정 요소들을 포함한다는 언급이 있는 경우, 또는 어떤 과정이 특정 단계들을 포함한다는 언급이 있는 경우는, 그 외 다른 요소 또는 다른 단계들이 더 포함될 수 있음을 의미한다. 즉, 본 명세서에서 사용되는 용어들은 특정 실시 형태를 설명하기 위한 것일 뿐이고, 본 명세서의 개념을 한정하기 위한 것이 아니다. 나아가, 발명의 이해를 돕기 위해 설명한 예시들은 그것의 상보적인 실시 예도 포함한다.
본 명세서에서 사용되는 슬래쉬(/)나 쉼표(comma)는 "및/또는(and/or)"를 의미할 수 있다. 예를 들어, "A/B"는 "A 및/또는 B"를 의미하므로, "오직 A"나 "오직 B"나 "A와 B 중 어느 하나"를 의미할 수 있다. 또한, 하나의 도면 내에서 개별적으로 설명되는 기술적 특징은, 개별적으로 구현될 수도 있고, 동시에 구현될 수도 있다.
또한, 본 명세서에서 사용되는 괄호는 "예를 들어(for example)"를 의미할 수 있다. 구체적으로, "제어 정보(A Signal)"로 표시된 경우, "제어 정보"의 일례로 "A Signal"이 제안된 것일 수 있다. 또한, "제어 정보(즉, A signal)"로 표시된 경우에도, "제어 정보"의 일례로 "A signal"이 제안된 것일 수 있다.
도 1은 무선랜 시스템의 구조를 보여주는 개념도이다. 도 1의 (A)는 IEEE(institute of electrical and electronic engineers) 802.11의 인프라스트럭쳐 네트워크(infrastructure network)의 구조를 나타낸다.
도 1의 (A)를 참조하면, 도 1의 (A)의 무선랜 시스템(10)은 적어도 하나의 기본 서비스 세트(Basic Service Set, 이하 'BSS', 100, 105)를 포함할 수 있다. BSS는 성공적으로 동기화를 이루어서 서로 통신할 수 있는 액세스 포인트(access point, 이하 'AP') 및 스테이션(station, 이하 'STA')의 집합으로서, 특정 영역을 가리키는 개념은 아니다.
예를 들어, 제1 BSS(100)는 제 1 AP(110) 및 하나의 제1 STA(100-1)을 포함할 수 있다. 제2 BSS(105)는 제2 AP(130) 및 하나 이상의 STA들(105-1, 105-2)을 포함할 수 있다.
인프라스트럭쳐 BSS(100, 105)는 적어도 하나의 STA, 분산 서비스(Distribution Service)를 제공하는 AP(110, 130) 그리고 다수의 AP를 연결시키는 분산 시스템(Distribution System, DS, 120)을 포함할 수 있다.
분산 시스템(120)은 복수의 BSS(100, 105)를 연결하여 확장된 서비스 세트인 확장 서비스 세트(140, extended service set, 이하, 'ESS')를 구현할 수 있다. ESS(140)는 적어도 하나의 AP(110, 130)가 분산 시스템(120)을 통해 연결된 하나의 네트워크를 지시하는 용어로 사용될 수 있다. 하나의 ESS(140)에 포함되는 적어도 하나의 AP는 동일한 서비스 세트 식별자(service set identification, 이하 'SSID')를 가질 수 있다.
포탈(portal, 150)은 무선랜 네트워크(IEEE 802.11)와 다른 네트워크(예를 들어, 802.X)와의 연결을 수행하는 브리지 역할을 수행할 수 있다.
도 1의 (A)와 같은 구조의 무선랜에서 AP(110, 130) 사이의 네트워크 및 AP(110, 130)와 STA(100-1, 105-1, 105-2) 사이의 네트워크가 구현될 수 있다.
도 1의 (B)는 독립 BSS를 나타낸 개념도이다. 도 1의 (B)를 참조하면, 도 1의 (B)의 무선랜 시스템(15)은 도 1의 (A)와 달리 AP(110, 130)가 없이도 STA 사이에서 네트워크를 설정하여 통신을 수행하는 것이 가능할 수 있다. AP(110, 130)가 없이 STA 사이에서도 네트워크를 설정하여 통신을 수행하는 네트워크를 애드-혹 네트워크(Ad-Hoc network) 또는 독립 BSS(independent basic service set, 이하 'IBSS')라고 정의한다.
도 1의 (B)를 참조하면, IBSS(15)는 애드-혹(ad-hoc) 모드로 동작하는 BSS이다. IBSS는 AP를 포함하지 않기 때문에 중앙에서 관리 기능을 수행하는 개체(centralized management entity)가 없다. 따라서, IBSS(15)에서, STA(150-1, 150-2, 150-3, 155-4, 155-5)들이 분산된 방식(distributed manner)으로 관리된다.
IBSS의 모든 STA(150-1, 150-2, 150-3, 155-4, 155-5)은 이동 STA으로 이루어질 수 있으며, 분산 시스템으로의 접속이 허용되지 않는다. IBSS의 모든 STA은 자기 완비적 네트워크(self-contained network)를 이룬다.
본 명세서에서 언급되는 STA은 IEEE(Institute of Electrical and Electronics Engineers) 802.11 표준의 규정을 따르는 매체 접속 제어(Medium Access Control, 이하 'MAC')와 무선 매체에 대한 물리계층(Physical Layer) 인터페이스를 포함하는 임의의 기능 매체로서, 광의로는 AP와 비-AP STA(Non-AP Station)을 모두 포함하는 의미로 사용될 수 있다.
본 명세서에서 언급되는 STA은 이동 단말(mobile terminal), 무선 기기(wireless device), 무선 송수신 유닛(Wireless Transmit/Receive Unit; WTRU), 사용자 장비(User Equipment; UE), 이동국(Mobile Station; MS), 이동 가입자 유닛(Mobile Subscriber Unit) 또는 단순히 유저(user) 등의 다양한 명칭으로도 불릴 수 있다.
도 2는 무선랜에서 스캐닝 방법을 나타낸 개념도이다.
도 2를 참조하면, 스캐닝 방법은 패시브 스캐닝(passive scanning, 200)과 액티브 스캐닝(active scanning, 250)으로 구분될 수 있다.
도 2의 (A)를 참조하면, 패시브 스캐닝(200)은 AP(210)가 주기적으로 브로드캐스트(broadcast)하는 비콘 프레임(230)을 기반으로 수행될 수 있다. 무선랜의 AP(210)는 비콘 프레임(230)을 특정 주기(예를 들어, 100msec)마다 non-AP STA(240)으로 브로드캐스트할 수 있다.
비콘 프레임(230)에는 현재의 네트워크에 대한 정보가 포함될 수 있다. non-AP STA(240)은 주기적으로 비콘 프레임(230)을 수신할 수 있다. 인증/결합(authentication/association) 과정을 수행하기 위해, non-AP STA(240)은 비콘 프레임(230)에 포함된 네트워크 정보를 기반으로 AP(210) 및 채널에 대한 스캐닝을 수행할 수 있다.
패시브 스캐닝 방법(200)은 non-AP STA(240)이 먼저 프레임을 전송하지 않고 AP(210)에서 전송되는 비콘 프레임(230)을 수신하는 기법이다. 따라서, 패시브 스캐닝 (200)은 네트워크에서 데이터 송신/수신에 의해 발생되는 전체적인 오버헤드가 작다는 장점이 있다.
그러나, 비콘 프레임(230)의 주기에 비례하여 수동적으로 스캐닝을 수행할 수 밖에 없기 때문에 스캐닝을 수행하는데 걸리는 시간이 늘어난다는 단점이 있다.
도 2의 (B)를 참조하면, 액티브 스캐닝(250)은 non-AP STA(290)에서 프로브 요청 프레임(270)을 AP(260)로 전송하여 주도적으로 스캐닝을 수행하는 기법이다.
AP(260)는 non-AP STA(290)으로부터 프로브 요청 프레임(270)을 수신할 수 있다. AP(260)는 프레임 충돌(frame collision)을 방지하기 위해 랜덤 시간 동안 기다릴 수 있다. AP(260)는 프로브 요청 프레임(270)에 대한 응답으로 네트워크 정보를 포함하는 프로브 응답 프레임(280)을 non-AP STA(290)으로 전송할 수 있다. non-AP STA(290)은 수신한 프로브 응답 프레임(280)을 기반으로 네트워크 정보를 획득할 수 있다.
액티브 스캐닝(250)의 경우, non-AP STA(290)이 주도적으로 스캐닝을 수행하므로 스캐닝에 사용되는 시간이 짧다는 장점이 있다. 하지만, non-AP STA(290)에서 프로브 요청 프레임(270)을 전송해야 하므로, 프레임 송신 및 수신을 위한 네트워크 오버헤드가 증가한다는 단점이 있다.
위 스캐닝 절차가 완료되면, AP와 STA은 인증(authentication) 및 결합(association) 절차를 수행할 수 있다.
도 3은 AP와 STA의 스캐닝 후 인증 및 결합 절차를 나타낸 개념도이다.
도 2 및 도 3을 참조하면, non-AP STA은 패시브/액티브 스캐닝을 통해 스캐닝 절차를 완료한 복수의 AP 중 하나의 AP와 인증 및 결합 절차를 수행할 수 있다. 예를 들어, 인증(authentication) 및 결합(association) 절차는 2-방향 핸드쉐이킹(2-way handshaking)을 통해 수행될 수 있다.
도 3의 (A)는 패시브 스캐닝 후 인증 및 결합 절차를 나타낸 개념도이고, 도 3의 (B)는 액티브 스캐닝 후 인증 및 결합 절차를 나타낸 개념도이다.
인증 및 결합 절차는 액티브 스캐닝 방법 또는 패시브 스캐닝을 사용하였는지 여부와 관계 없이 수행될 수 있다. 예를 들어, AP(300, 350)가 non-AP STA(305, 355)와 인증 요청 프레임(authentication request frame, 310), 인증 응답 프레임(authentication response frame, 320), 결합 요청 프레임(association request frame, 330) 및 결합 응답 프레임(association response frame, 340)을 교환함으로써, 인증 및 결합 절차가 수행될 수 있다.
구체적으로, 인증 절차는 non-AP STA(305, 355)에서 인증 요청 프레임(310)을 AP(300, 350)로 전송함으로써 수행될 수 있다. AP(300, 350)는 인증 요청 프레임(310)에 대한 응답으로 인증 응답 프레임(320)을 non-AP STA(305, 355)으로 전송할 수 있다. 인증 프레임 포맷(authentication frame format)에 대해서는 IEEE 802.11 8.3.3.11 절에 개시되어 있다.
구체적으로, 결합 절차는 non-AP STA(305, 355)에서 결합 요청 프레임(330)을 AP(300, 305)로 전송함으로써 수행될 수 있다. AP(300, 350)는 결합 요청 프레임(330)에 대한 응답으로 결합 응답 프레임(340)을 non-AP STA(305, 355)으로 전송할 수 있다.
결합 요청 프레임(330)은 non-AP STA(305, 355)의 성능(capability)에 관한 정보를 포함할 수 있다. AP(300, 350)는 결합 요청 프레임(330)에 포함된 non-AP STA(305, 355)의 성능에 관한 정보를 기반으로 non-AP STA(305, 355)에 대한 지원 가능 여부를 판단할 수 있다.
일 예로, non-AP STA(305, 355)에 대한 지원이 가능한 경우, AP(300, 350)는 결합 응답 프레임(340)에 결합 요청 프레임(340)에 대한 수락 여부와 그 이유, 자신이 지원 가능한 성능 정보(capability information)을 담아서 non-AP STA(305, 355)에 전송할 수 있다.
도 3에 언급된 결합 절차까지 수행되면, AP와 STA 사이에 정상적인 데이터의 송신 및 수신 절차가 수행될 수 있다.
도 4는 이웃 발견 과정을 설명하기 위한 도면이다. 도 4의 예시는 P2P(Peer to Peer) 디바이스와 P2P 디바이스 사이의 동작으로 이해될 수 있다.
도 4를 참조하면, S410에서, 이웃 발견 과정은 SME(Station Management Entity)/어플리케이션/사용자/벤더의 지시에 의해 개시될 수 있다. 예를 들어, 이웃 발견 과정은 스캔 단계(scan phase)(S412)와 찾기 단계(find phase)(S414-S416)를 포함할 수 있다.
스캔 단계(S412)는 가용한 모든 무선 채널에 대해 802.11 방식에 따라 스캔하는 동작을 포함할 수 있다. 이를 통해, P2P 디바이스는 최상의 동작 채널을 확인할 수 있다.
찾기 단계(S414-S416)는 청취(listen) 모드(S414)와 검색(search) 모드 (S416)를 포함할 수 있다. P2P 디바이스는 청취 모드(S414)와 검색 모드(S416)를 교대로 반복할 수 있다. P2P 디바이스(202, 204)는 검색 모드(S416)에서 프로브 요청 프레임(Probe request frame)을 사용하여 액티브 스캐닝을 수행할 있다.
예를 들어, 빠른 검색을 위하여 검색 범위를 1 번 채널, 6 번 채널, 11번 채널(예로, 2412 MHz, 2437 MHz, 2462 MHz)과 같은 소셜 채널(social channel)로 한정할 수 있다.
또한, P2P 디바이스(202, 204)는 청취 모드(S414)에서 3개의 소셜 채널 중 선택된 하나의 채널상에서 수신 상태를 유지할 수 있다.
이 경우, 다른 P2P 디바이스(예, 202)가 검색 모드에서 전송한 프로브 요청 프레임이 수신된 경우, P2P 디바이스(예를 들어, 204)는 프로브 응답 프레임(probe response frame)으로 응답할 수 있다.
청취 모드(S414)를 위한 시간(예로, 100, 200, 300 TU(Time Unit))은 랜덤하게 결정될 수 있다. P2P 디바이스는 검색 모드 및 수신 모드의 반복을 통해 서로의 공통 채널에 도달할 수 있다.
다른 P2P 디바이스가 발견되면, P2P 디바이스는 다른 P2P 디바이스와 프로브 요청 프레임 및 프로브 응답 프레임을 교환할 수 있다. 이를 통해, P2P 디바이스들은 서로의 디바이스 타입, 제작사 또는 친근한 디바이스 명칭(name)을 발견/교환할 수 있다.
이웃 발견 과정을 통해 발견된 주변 P2P 디바이스에 관한 필요한 정보가 획득되면, P2P 디바이스(예를 들어, 202)는 SME/어플리케이션/사용자/벤더에게 P2P 디바이스 발견을 알릴 수 있다(S418).
현재, P2P는 주로 원격 프린트, 사진 공유 등과 같은 반-정적(semi-static) 통신을 위해 사용되고 있다. 그러나, Wi-Fi 디바이스의 보편화와 위치 기반 서비스 등으로 인해, P2P의 활용성은 점점 넓어지고 있다.
예를 들어, 소셜 채팅(예를 들어, SNS(Social Network Service)에 가입된 무선 디바이스들이 위치 기반 서비스에 기초해서 근접 지역의 무선 디바이스를 인식하고 정보를 송수신), 위치-기반 광고 제공, 위치-기반 뉴스 방송, 무선 디바이스간 게임 연동 등에 P2P가 활발히 사용될 것으로 예상된다. 편의상, 이러한 P2P 응용을 신규 P2P 응용이라고 지칭한다.
도 5는 DPP(Device Provisioning Protocol) 절차의 개념도이다.
도 5를 참조하면, DPP 절차를 위한 DPP 아키텍처는 DPP 부트스트랩 프로토콜(DPP Bootstrapping protocol), DPP 인증 프로토콜(DPP Authentication protocol), DPP 구성 프로토콜(DPP Configuration protocol) 및 DPP 소개 프로토콜(DPP Introduction protocol) 동안 장치 역할(the device roles)을 정의할 수 있다.
DPP 절차에서, 무선 장치를 위한 두 가지 타입의 역할이 있을 수 있다. 예를 들어, 구성자(configurator) 및 등록자(enrollee)의 역할이 있을 수 있다. 다른 예로, 개시자(Initiator) 및 응답자(Responder)의 역할이 있을 수 있다.
도 5의 명확하고 간결한 설명을 위해, 구성자는 제1 무선 장치(510)로 이해될 수 있다. 또한, 등록자는 제2 무선 장치(520)로 이해될 수 있다.
구성자인 제1 무선 장치(510)는 등록자인 제2 무선 장치(520)의 셋업(setup)을 지원할 수 있다. 구성자 및 등록자는 DPP 부트스트랩 프로토콜, DPP 인증 프로토콜, DPP 구성 프로토콜에 관여(engage in)할 수 있다.
구성자 또는 등록자는 DPP 부트스트랩 프로토콜 및 DPP 인증 프로토콜에서 개시자(Initiator)의 역할을 수행할 수 있다. 다만, 등록자(enrollee)만이 DPP 구성 프로토콜 및 DPP 소개 프로토콜을 개시(initiate)할 수 있다.
DPP 인증 프로토콜은 부트스트랩 매커니즘의 일부로 개시자가 응답자의 부트스트랩 키(bootstrapping key)를 획득할 것을 요구할 수 있다. 선택적으로, 상호간의 인증을 제공하기 위하여, 무선 장치는 서로의 부트스트랩 키를 획득할 수 있다.
DPP 인증 프로토콜이 완료되면, 구성자는 장치 대 장치(device-to-device) 통신 또는 인프라스트럭처 통신을 위해 등록자를 프로비전(provision)할 수 있다.
이러한 프로비저닝의 일환으로, 구성자는 등록자(enrollee)가 네트워크 내에 다른 피어(peer)와 보안 연결(secure associations)을 수립하도록 할 수 있다. 여기서, 피어(peer)는 구성자에 의해 이미 구성된 무선 장치(530)로 이해될 수 있다.
구성자 및 등록자는 DPP 인증 프로토콜과 연관될 수 있다. 부트스트랩 시나리오에 따라, 구성자 또는 등록자는 각각 개시자 또는 응답자의 역할을 수행할 수 있다.
DPP 인증 프로토콜을 시작하는 무선 장치는 개시자의 역할을 수행할 수 있다. 개시자의 요청에 응답하는 무선 장치는 응답자의 역할을 수행할 수 있다. DPP 인증 프로토콜은 응답자의 인증을 개시자에게 제공할 수 있다. 선택적으로, DPP 인증 프로토콜은 개시자의 인증을 응답자에게 제공할 수 있다.
예를 들어, 단방향 인증(unidirectional authentication)을 수행하기 위해, 개시자는 응답자의 부트스트랩 키(bootstrapping key)를 확보(obtain)할 수 있다. 또한, 상호 인증을 선택적으로 수행하기 위해, 개시자 및 응답자는 서로의 부트스트랩 키를 확보할 수 있다
예를 들어, 등록자로 역할하는 프로비저닝되지 않은 무선 장치(unprovisioned device, 520)를 구성(configure)하기 위해, 무선 장치(510)는 구성자로 역할할 수 있다. 예를 들어, 프로비저닝되지 않은 무선 장치는 액세스 포인트 또는 다른 무선 장치일 수 있다.
구성자(configurator)로 역할하는 무선 장치(510)가 프로비저닝되지 않은 무선 장치(520)와 DPP 인증 프로토콜을 시작할 때, 무선 장치(510)는 개시자로 역할할 수 있다.
도 6은 무선 장치 사이에서 DPP 절차를 수행하는 과정을 보여주는 순서도이다. 도 6의 DPP 절차는 3-way handshaking 방식으로 구현될 수 있다.
도 5 및 도 6을 참조하면, 제1 무선 장치(610)는 개시자(initiator)로 역할하고, 제2 무선 장치(620)는 응답자(responder)로 역할할 수 있다. 또한, 제1 무선 장치(610)는 구성자(configurator)로 역할하고, 제2 무선 장치(620)는 등록자(enrollee)로 역할할 수 있다.
S610 단계에서, 제1 무선 장치(610) 및 제2 무선 장치(620)는 DPP 부트스트랩 프로토콜을 수행할 수 있다.
예를 들어, 구성자로 역할하는 제1 무선 장치(610)는 OOB(Out Of Band) 매커니즘을 이용하여 등록자로 역할하는 제2 무선 장치(620)로부터 부트스트랩 정보를 획득할 수 있다.
예를 들어, OOB 매커니즘은 QR 코드(예로, 521)에 기반한 스캔 QR 코드(scan QR code) 방식, NFC 탭(NFC tap) 방식 또는 BLE 교환(Bluetoooth Low Energy exchange) 방식을 기반으로 구현될 수 있다.
예를 들어, 부트스트랩 정보는 DPP 인증 프로토콜을 위한 등록자의 부트스트랩 퍼블릭 키(the enrollee's bootstrapping public key)에 관한 정보를 포함할 수 있다. 일 예로, 부트스트랩 퍼블릭 키는 구성자 및 등록자에 의한 DPP 인증 프로토콜을 위해서만 이용될 수 있다.
예를 들어, 글로벌 오퍼레이팅 클래스 채널(global operating class channel)에 대한 정보 또는 채널 리스트(channel list)에 대한 정보가 부트스트랩 정보에 더 포함될 수 있다.
이 경우, DPP 인증 프로토콜을 시작하기 위해, 무선 장치(예로, 620)는 다른 장치(예로, 610)를 위해 나열된 채널 중 하나(one of the listed channels)에서 청취하고 있음을 지시할 수 있다.
다른 예로, 글로벌 오퍼레이팅 클래스 채널에 대한 정보 또는 채널 리스트에 대한 정보가 부트스트랩 정보에 포함되지 않을 수 있다.
이 경우, 무선 장치(예로, 620)는 어느 채널을 청취하고 있는지에 대한 지침(guidance)을 다른 장치(예로, 610)에게 제공하지 않을 수 있다. 이에 따라, 다른 장치(예로, 610)는 사용 가능한 모든 채널을 반복(iterate)해야 한다.
다수의 채널에 걸친 반복(iteration)으로 인하여 DPP 인증 프로토콜에 상당한 추가적인 딜레이(extra delay)가 발생할 수 있다. 이에 따라, QR 코드 부트 스트래핑(QR Code bootstrapping)을 이용하는 장치는 부트스트랩 정보에 단일 채널 또는 가능한 한 짧은 채널 목록(at most a short list of possible channels)을 포함할 것이 요구될 수 있다.
도 6의 제1 무선 장치(610)는 제2 무선 장치(620)로부터 획득된 부트스트랩 정보를 기반으로 특정된 채널 상에서 동작을 시작할 수 있다. 도 6의 제2 무선 장치(620)는 S610 단계 동안 특정한 채널에서 청취할 수 있다.
S620 단계에서, 제1 무선 장치(610) 및 제2 무선 장치(620)는 DPP 인증 프로토콜을 수행할 수 있다.
예를 들어, 구성자로 역할하는 제1 무선 장치(610)는 등록자로 역할하는 제2 무선 장치(620)로 DPP 인증 요청 프레임을 송신할 수 있다. 이 경우, DPP 인증 요청 프레임은 부트스트랩 정보(예로, 채널 리스트)에 상응하는 적어도 하나의 채널을 통해 송신될 수 있다.
S621 단계에서, 제1 무선 장치(610)는 DPP 인증 요청 프레임을 제2 무선 장치(620)로 송신할 수 있다. 이어, 제1 무선 장치(610)는 S621 단계에서 송신된 DPP 인증 요청 프레임에 대한 응답을 기다릴 수 있다.
예를 들어, 제1 무선 장치(610)는 제2 무선 장치(620)로부터 S621 단계에서 송신된 DPP 인증 요청 프레임에 대한 응답인 DPP 인증 응답 프레임이 미리 정해진 시간 내에 수신되는지 여부를 판단할 수 있다.
일 예로, 미리 정해진 시간은 S621 단계의 DPP 인증 요청 프레임의 송신 시점을 기준으로 설정될 수 있다.
도 6의 명확하고 간결한 설명을 위해, S621 단계에서 송신된 DPP 인증 요청 프레임에 대한 응답으로 DPP 인증 응답 프레임이 미리 정해진 시간이 경과할 때까지 수신되지 않는다고 가정할 수 있다.
위 가정에 따라 미리 정해진 시간이 경과할 때까지 DPP 인증 응답 프레임이 수신되지 않는 경우, DPP 인증 응답 프레임의 재송신을 위해 S622 단계가 수행된다.
S622 단계에서, 제1 무선 장치(610)는 DPP 인증 요청 프레임을 제2 무선 장치(620)로 재송신할 수 있다. 이어, 제1 무선 장치(610)는 S622 단계에서 송신된 DPP 인증 요청 프레임에 대한 응답을 기다릴 수 있다.
예를 들어, 제1 무선 장치(610)는 제2 무선 장치(620)로부터 S622 단계에서 재송신된 DPP 인증 요청 프레임에 대한 응답인 DPP 인증 응답 프레임이 미리 정해진 시간 내에 수신되는지 여부를 판단할 수 있다.
일 예로, 미리 정해진 시간은 S622 단계의 DPP 인증 요청 프레임의 송신 시점을 기준으로 설정될 수 있다.
도 6의 명확하고 간결한 설명을 위해, S622 단계에서 재송신된 DPP 인증 요청 프레임에 대한 응답으로 DPP 인증 응답 프레임이 미리 정해진 시간이 경과할 때까지 수신되지 않는다고 가정할 수 있다.
위 가정에 따라 미리 정해진 시간이 경과할 때까지 DPP 인증 응답 프레임이 수신되지 않는 경우, DPP 인증 응답 프레임의 재송신을 위해 S623 단계가 수행된다.
S623 단계에서, 제1 무선 장치(610)는 DPP 인증 요청 프레임을 제2 무선 장치(620)로 재송신할 수 있다. 이어, 제1 무선 장치(610)는 S623 단계에서 재송신된 DPP 인증 요청 프레임에 대한 응답으로 DPP 인증 응답 프레임이 미리 정해진 시간 내에 제2 무선 장치(620)로부터 수신되는지 여부를 판단할 수 있다.
일 예로, 미리 정해진 시간은 S623 단계의 DPP 인증 요청 프레임의 송신 시점을 기준으로 설정될 수 있다.
도 6의 명확하고 간결한 설명을 위해, 미리 정해진 시간 내에 제2 무선 장치(620)로부터 DPP 인증 응답 프레임이 수신된다고 가정할 수 있다. 위 가정에 따라 미리 정해진 시간이 경과하기 전에 DPP 인증 응답 프레임이 수신되면, S624 단계가 수행된다.
S624 단계에서, 제1 무선 장치(610)는 S623 단계에서 재송신된 DPP 인증 요청 프레임에 대한 응답으로 DPP 인증 응답 프레임을 제2 무선 장치(620)로부터 수신할 수 있다.
S625 단계에서, 제1 무선 장치(610)는 DPP 인증 프로토콜을 완료하기 위해 DPP 인증 확인 프레임을 제2 무선 장치(620)로 송신할 수 있다.
DPP 인증 확인 프레임의 송신에 따라 DPP 인증 프로토콜(S620)이 성공적으로 수행되면, 개시자(또는 구성자)와 응답자(또는 등록자) 사이에 보안 채널(secure channel)이 설정(establish)될 수 있다.
S630 단계에서, 제1 무선 장치(610) 및 제2 무선 장치(620)는 DPP 구성 프로토콜을 수행할 수 있다.
S630 단계에서, 제1 무선 장치(610) 및 제2 무선 장치(620)는 같은 MAC 어드레스를 사용할 수 있다. 또한, S630 단계에서, 제1 무선 장치(610) 및 제2 무선 장치(620)는 DPP 인증 프로토콜 동안 사용된 같은 채널을 사용할 수 있다.
S631 단계에서, DPP 구성 프로토콜을 시작하기 위해, 제2 무선 장치(620)는 DPP 구성 요청 프레임을 제1 무선 장치(610)로 송신할 수 있다. 여기서, 개시자 또는 응답자가 구성자의 역할을 수행하는지 여부와 관계 없이, DPP 구성 요청 프레임은 오직 등록자(enrollee)에 의해서만 송신될 수 있다.
S632 단계에서, 제1 무선 장치(610)는 DPP 구성 요청 프레임에 대한 응답으로 DPP 구성 응답 프레임을 제2 무선 장치(620)로 송신할 수 있다. DPP 구성 응답 프레임은 DPP 구성 객체(DPP Configuration object)를 포함할 수 있다. 예를 들어, DPP 구성 객체는 하기 표 1과 같은 복수의 파라미터 정보를 포함할 수 있다.
Figure PCTKR2019012890-appb-T000001
앞서 언급된 S610단계 내지 S630 단계가 성공적으로 수행되면, 제1 무선 장치(610)와 미리 결합(associate)된 AP(미도시)를 포함하는 무선랜 시스템의 네트워크 정보가 제2 무선 장치(620)에게 전달할 수 있다. 예를 들어, 네트워크 정보는 SSID 정보 또는 비밀번호(password) 정보를 포함할 수 있다.
즉, 제2 무선 장치(620)는 제1 무선 장치(610)와 결합된 AP(미도시)와 별도의 결합(association) 절차의 수행 없이도, 제2 무선 장치(620)는 제1 무선 장치(610)로부터 수신된 네트워크 정보를 기반으로 무선랜 시스템에 연결될 수 있다.
도 7은 soft-AP 연결을 기반으로 연결을 수립하는 절차를 도시한다.
도 7을 참조하면, AP(730)는 제1 STA(710)과 연결이 수립된 상태일 수 있다. 제2 STA(720)은 soft-AP(software AP)를 활성화할 수 있다. 예를 들어, 제2 STA(720)은 사용자의 입력에 기초하여, soft-AP를 활성화할 수 있다. 제2 STA(720)은 비콘을 전송할 수 있다. 예를 들어, 제2 STA(720)은 브로드캐스트 방식을 통해 비콘을 전송할 수 있다. 제1 STA(710)은 상기 비콘을 수신한 뒤, AP(730)와 연결을 해제할 수 있다.
제1 STA(710)은 제2 STA(720)과 인증 절차(또는 인증 프로토콜)를 수행할 수 있다. 구체적으로, 제1 STA(710)은 인증 요청 프레임(Authentication request frame)을 제2 STA(720)에게 전송할 수 있다. 제2 STA(720)은 인증 요청 프레임에 응답하여 인증 응답 프레임(Authentication response frame)을 제1 STA(710)에게 전송할 수 있다.
인증 절차가 완료된 후, 제1 STA(710)은 제2 STA(720)과 구성 절차(또는 구성 프로토콜(Configuration Protocol))를 수행할 수 있다. 구체적으로, 제1 STA(710)은 결합 요청 프레임(Association request frame)을 제2 STA(720)에게 전송할 수 있다. 제2 STA(720)은 결합 요청 프레임에 응답하여 결합 응답 프레임(Association response frame)을 제1 STA(710)에게 전송할 수 있다.
제1 STA(710)은 제2 STA(720)과 네트워크 정보 전달 프로토콜을 수행할 수 있다. 제2 STA(720)은 AP(730)와 연결을 수립하기 위한 네트워크 연결 정보를 획득할 수 있다. 네트워크 연결 정보는 SSID 및/또는 PW(password)에 관한 정보를 포함할 수 있다. 제1 STA(710)과 제2 STA(720)의 연결이 해제된 후, 제2 STA(720)은 Soft-AP를 비활성화하고, AP(730)과 연결을 수립할 수 있다. 이후, 제1 STA(710)은 다시 AP(730)와 연결 수립 절차를 통해 연결을 수립 해야 할 수 있다.
도 8은 Soft-AP 연결을 기반으로 연결을 수립하는 절차의 문제점을 도시한다.
도 8을 참조하면, 제1 문제점으로, 제1 STA(810)은 제2 STA(820)의 Soft-AP와 연결하기 위해 AP(830)와의 연결을 해제해야 한다. 구체적으로, 제1 STA(810)은 제2 STA(820)로부터 비콘을 수신하고, 제2 STA(820)과 인증 절차 및 결합 절차를 수행하기 위해 AP(830)와의 연결을 해제해야 한다.
제2 문제점으로, 제1 STA(810)은 제2 STA(820)의 Soft-AP와 연결하기 위해 802.11 규격에 따른 인증 절차 및 결합 절차를 수행해야 한다.
제3 문제점으로, 제1 STA(810)은 제2 STA(820)과 AP(830) 사이의 연결을 수립한 뒤, 다시 AP(830)와 연결을 수립해야 한다. 따라서, 제2 STA(820)에게 네트워크 정보를 송신하기 위해 STA 간의 연결 과정(802.11 Association) 및 해제 과정(802.11 Authentication)이 반복적으로 수행되는 문제가 있다.
따라서, 본 명세서에 따른 실시 예는 상술한 제1 문제점 내지 제3 문제점을 해결하기 위한 방안을 제안할 수 있다. 본 명세서에 따른 실시 예는 DPP를 활용하여 제1 STA에서 제2 STA 및 전송 STA(또는 AP) 사이의 연결을 수립하기 위한 방안을 제안할 수 있다. 구체적으로, 제1 STA은 제2 STA으로부터 전송 STA과 연결에 필요한 정보를 수신할 수 있다. 제1 STA은 상기 전송 STA과 연결에 필요한 정보에 기초하여, 제2 STA과 전송 STA 사이의 연결을 수립할 수 있다.
무선랜 시스템에서, 제1 STA은 전송 STA과 연결될 수 있다. 제1 STA은 제2 STA로부터 비콘을 수신할 수 있다. 제1 STA은 비콘에 응답하여, 제2 STA의 DPP 부트스트랩 URI(DPP Bootstrap URI) 정보 요청을 위한 프로브 요청 프레임을 제2 STA에게 전송할 수 있다. 이후, 제1 STA은 프로브 요청 프레임에 응답하여, 제2 STA으로부터 프로브 응답 프레임을 수신할 수 있다. 프로브 응답 프레임은 DPP 부트스트랩 URI 정보를 포함할 수 있다. 제1 STA은 수신한 DPP 부트스트랩 URI 정보에 기초하여 제2 STA과 전송 STA 사이의 연결을 수립할 수 있다.
전송 STA은 AP(Access Point)를 포함할 수 있다. 제1 STA은 DPP 절차에서 구성자(configurator) 역할을 수행할 수 있다. 제2 STA은 DPP 절차에서 등록자(enrollee) 역할을 수행할 수 있다. 예를 들어, 제1 STA은 스마트폰, 노트북, 랩탑 등을 포함할 수 있다. 제2 STA은 비콘을 브로드캐스팅하며, 다른 무선 장치와 페어링(pairing)하여 동작할 수 있는 장치를 포함할 수 있다. 예를 들어, 제2 STA은 냉장고, 에어컨, 세탁기, 헤드폰(headphone) 등을 포함할 수 있다.
상술한 기술적 특징을 이하의 구체적인 도면(예: 도 9)을 기초로 설명하겠다. 이하의 도면에서 제시되는 구체적인 값, 필드 길이, 필드 구성 등은 예시적인 것이며 구체적인 값, 필드 길이, 필드 구성 등은 모두 변경될 수 있다.
도 9는 DPP를 활용한 Soft-AP 연결을 기반으로 연결을 수립하는 절차를 도시한다.
도 9를 참조하면, 제1 STA(910)은 AP(930)과 연결이 수립된 상태일 수 있다. 제1 STA(910)은 제2 STA(920)으로부터 비콘을 수신할 수 있다. 상기 비콘은 제2 STA(920)의 SSID(Service Set Identifier) 또는 제2 STA(920)의 DPP 지원 여부에 관한 정보를 포함할 수 있다. 상기 비콘은 벤더 고유 정보 엘리먼트(Vendor Specific Information Element)를 포함할 수 있다. 상기 벤더 고유 정보 엘리먼트는 제2 STA(920)의 DPP 지원 여부에 관한 정보를 포함할 수 있다. DPP 지원 여부에 관한 정보를 포함하는 벤더 고유 정보 엘리먼트는 DPP IE로 불릴 수 있다.
따라서, 제1 STA(910)은 비콘에 기초하여. 제2 STA(920)의 DPP 지원 여부를 확인할 수 있다. 상기 비콘에 포함된 벤더 고유 정보 엘리먼트는 제1 벤더 고유 정보 엘리먼트로도 불릴 수 있다. 도 10에서는 비콘에 포함된 벤더 고유 정보 엘리먼트에 관한 구체적인 내용이 설명될 수 있다.
도 10은 비콘의 벤더 고유 정보 엘리먼트 도시한다.
도 10을 참조하면, 비콘에 포함된 벤더 고유 정보 엘리먼트(이하 DPP IE)는 제2 STA(920)의 DPP 지원 여부에 관한 정보를 포함할 수 있다.
일 실시 예에 따르면, DPP IE는 Element ID 정보 필드, Length 정보 필드 및/또는 Description 정보 필드를 포함할 수 있다.
Element ID 정보 필드는 802.11 규격에서 사용 가능한 벤더 고유 정보(Vendor Specific IE) ID를 할당 받기 위한 정보 필드일 수 있다. Length 정보 필드는 Description 정보 필드 길이에 대한 정보 필드일 수 있다.
Description 정보 필드는 DPP Indication parameter로써 2 bit를 포함할 수 있다. Description 정보 필드는 DPP IE를 전송한 STA(예를 들어, 제2 STA(920))이 선호하는 DPP 역할에 관한 정보 필드를 포함할 수 있다. 예를 들어, DPP 역할에 관한 정보 필드가 {00}으로 설정된 경우, STA이 등록자(Enrollee) 역할을 선호함을 나타낼 수 있다. 다른 예를 들어, DPP 역할에 관한 정보 필드가 {01}으로 설정된 경우, STA이 구성자(Configurator) 역할을 선호함을 나타낼 수 있다. 또 다른 예를 들어, DPP 역할에 관한 정보 필드가 {11}으로 설정된 경우, STA이 구성자 및 등록자 역할을 모두 선호함을 나타낼 수 있다.
Description 정보 필드는 Reserved bit를 포함할 수 있다. Reserved bit는 DPP와 관련된 내용들이 더 포함될 수 있다.
다시 도 9를 참조하면, 제1 STA(910)은 프로브 요청 프레임(Probe Request Frame)을 제2 STA(920)으로 송신할 수 있다. 제1 STA(910)은 제2 STA(920)의 DPP를 지원 여부 및/또는 DPP 역할에 관한 정보를 확인할 수 있다. 이후, 제1 STA(910)은 제2 STA(920)에게 프로브 요청 프레임을 전송할 수 있다. 예를 들어, 제1 STA(910)은 비콘에 기초하여, 제2 STA(920)이 DPP를 지원하고, DPP 등록자 역할을 수행함을 확인할 수 있다. 제1 STA(910)은 제2 STA(920)에게 제1 STA(910)은 프로브 요청 프레임을 통해 제2 STA(920)의 부트스트랩 URI 정보를 요청할 수 있다.
도시되지는 않았으나, 일 실시 예에 따르면, 제2 STA(920)이 제1 STA(910)에게 프로브 요청 프레임을 전송할 수 있다. 제2 STA(920)은 프로브 요청 프레임을 통해 제1 STA(910)의 DPP 부스트랩 URI 정보를 요청할 수도 있다.
프로브 요청 프레임은 벤더 고유 정보 엘리먼트(Vendor Specific Information Element)를 포함할 수 있다. 상기 벤더 고유 정보 엘리먼트는 제2 STA(920)의 부트스트랩 URI 정보를 요청하기 위한 정보를 포함할 수 있다. 부트스트랩 URI 정보를 요청하기 위한 정보를 포함하는 벤더 고유 정보 엘리먼트는 DPP Bootstrap IE로 불릴 수 있다.
따라서, 제2 STA(920)은 프로브 요청 프레임을 통해 제1 STA(910)이 DPP 부트스트랩 URI 정보를 요청함을 확인할 수 있다. 상기 프로브 요청 프레임에 포함된 벤더 고유 정보 엘리먼트는 제2 벤더 고유 정보 엘리먼트로도 불릴 수 있다. 도 11에서는 프로브 요청 프레임에 포함된 벤더 고유 정보 엘리먼트에 관한 구체적인 내용이 설명될 수 있다.
도 11은 프로브 요청 프레임의 벤더 고유 정보 엘리먼트를 도시한다.
도 11을 참조하면, 프로브 요청 프레임에 포함된 벤더 고유 정보 엘리먼트(이하 DPP Bootstrap IE)는 부트스트랩 URI 정보를 요청하기 위한 정보를 포함할 수 있다.
일 실시 예에 따르면, DPP Bootstrap IE는 Element ID 정보 필드, Length 정보 필드 및/또는 Description 정보 필드를 포함할 수 있다.
Element ID 정보 필드 및/또는 Length 정보 필드는 도 10의 Element ID 정보 필드 및/또는 Length 정보 필드와 유사하게 구성될 수 있다.
Description 정보 필드는 DPP bootstrap parameter(1bit)를 포함할 수 있다. DPP bootstrap parameter는 Bootstrap URI Request로 정의될 수 있다. 예를 들어, DPP bootstrap parameter가 {1}로 설정된 경우, DPP bootstrap parameter는 bootstrap URI를 요청함을 나타낼 수 있다. Description 정보 필드는 Reserved bit를 포함할 수 있다. Reserved bit는 DPP와 관련된 내용들이 더 포함될 수 있다.
다시 도 9를 참조하면, 제1 STA(910)은 프로브 응답 프레임(Probe Response Frame)을 제2 STA(920)으로부터 수신할 수 있다. 제2 STA(920)은 제1 STA(910)으로부터 수신한 프로브 요청 프레임에 대한 응답으로, 프로브 응답 프레임을 제1 STA(910)에게 전송할 수 있다. 프로브 응답 프레임은 DPP 부트스트랩 URI 정보를 포함할 수 있다.
프로브 응답 프레임은 벤더 고유 정보 엘리먼트(Vendor Specific Information Element)를 포함할 수 있다. 상기 벤더 고유 정보 엘리먼트는 제2 STA(920)의 부트스트랩 URI 정보를 포함할 수 있다. 부트스트랩 URI 정보를 포함하는 벤더 고유 정보 엘리먼트는 DPP Bootstrap URI IE로 불릴 수 있다.
따라서, 제1 STA(910)은 프로브 응답 프레임을 통해 제2 STA(920)의 DPP 부트스트랩 URI 정보를 확인할 수 있다. 상기 프로브 응답 프레임에 포함된 벤더 고유 정보 엘리먼트는 제3 벤더 고유 정보 엘리먼트로도 불릴 수 있다. 도 12에서는 프로브 응답 프레임에 포함된 벤더 고유 정보 엘리먼트에 관한 구체적인 내용이 설명될 수 있다.
도 12는 프로브 응답 프레임의 벤더 고유 정보 엘리먼트 도시한다.
도 12를 참조하면, 프로브 응답 프레임에 포함된 벤더 고유 정보 엘리먼트(이하 DPP Bootstrap URI IE)는 제2 STA(920)의 부트스트랩 URI 정보를 포함할 수 있다.
일 실시 예에 따르면, DPP Bootstrap URI IE는 Element ID 정보 필드, Length 정보 필드 및/또는 Description 정보 필드를 포함할 수 있다.
Element ID 정보 필드 및/또는 Length 정보 필드는 도 10의 Element ID 정보 필드 및/또는 Length 정보 필드와 유사하게 구성될 수 있다.
Description 정보 필드는 부트스트랩 URI 정보를 포함할 수 있다. Description 정보 필드는 Reserved bit를 포함할 수 있다. Reserved bit는 DPP와 관련된 내용들이 더 포함될 수 있다. 구체적인 DPP 부트스트랩 URI에 관한 형식 및 예시가 도 13에서 설명될 수 있다.
도 13은 DPP 부트스트랩 URI에 관한 형식 및 예시를 도시한다.
도 13을 참조하면, DPP 부트스트랩 URI는 채널 리스트, 클래스. MAC address 등에 관한 정보를 포함할 수 있다. 또한, DPP 부트스트랩 URI는 공용키(public key)의 역할을 수행한다는 정보를 포함할 수 있다. DPP 부트스트랩 URI는 도 13의 Example에 도시된 것과 같은 형식으로 표현될 수 있다.
다시 도 9를 참조하면, 제2 STA(920)은 Soft-AP를 비활성화할 수 있다. 이후, 제1 STA(910) 및 제2 STA(920)은 DPP 부트스트랩 URI에 기초하여, DPP 인증 절차(또는 인증 프로토콜(Authentication Protocol)) 및 DPP 구성 절차(또는 구성 프로토콜(Configuration Protocol))를 수행할 수 있다. 제2 STA(920)은 DPP 인증 절차 및 DPP 구성 절차에 기초하여, 네트워크 연결 정보를 획득할 수 있다. 네트워크 연결 정보는 SSID 또는 PW(Password)에 관한 정보를 포함할 수 있다. DPP 인증 절차 및 DPP 구성 절차는 도 6에 도시된 S620 내지 S630과 관련될 수 있다.
제2 STA(920)은 획득한 네트워크 연결 정보에 기초하여, AP(930)와 연결을 수립할 수 있다.
상술한 실시 예에 따르면, 제1 STA(910)(즉, 구성자)과 AP(930)간의 연결이 해제되지 않을 수 있다. 또한, 제1 STA(910)(즉, 구성자)와 제2 STA(920)(즉, 등록자) 간의 연결 과정이 수행되지 않을 수 있다. 또한, 제1 STA(910)(즉, 구성자)는 AP(930)와의 연결을 해제하고, AP(930)와 제2 STA(920)의 연결이 수립된 이후, 다시 AP(930)와의 연결을 수립하지 않을 수 있다. 또한, 제2 STA(920)은 프로브 응답 프레임을 송신한 이후, Soft-AP를 사용하지 않을 수 있다. 따라서, 제2 STA(920)은 기존의 네트워크 연결 기술과 DPP를 동시에 사용할 수 있다.
도 14는 DPP를 활용한 Soft-AP 연결을 기반으로 연결을 수립하는 다른 절차를 도시한다.
도 14를 참조하면, 제1 STA(1410)의 DPP 지원 여부에 따라 연결을 수립하는 절차가 변경될 수 있다. 제1 STA(1410)의 DPP 지원 여부에 따라, Case 1 또는 Case 2의 과정이 수행될 수 있다.
구체적으로, 제1 STA(1410)은 제2 STA(1420)으로부터 비콘을 수신할 수 있다. 비콘은 제2 STA(1420)의 DPP 지원 여부에 관한 정보를 포함할 수 있다. 따라서 제1 STA(1410)은 제1 STA(1410)이 DPP를 지원하는 경우, Case 1의 과정을 수행할 수 있다. 제1 STA(1410)은 제1 STA(1410) DPP를 지원하지 않는 경우, Case 2의 과정을 수행할 수 있다.
제1 STA(1410)이 DPP를 지원하는 경우, Case 1의 과정이 수행될 수 있다. Case 1의 과정은 도 9에 도시된 과정에 상응할 수 있다.
제1 STA(1410)이 DPP를 지원하지 않는 경우, Case 2의 과정이 수행될 수 있다. Case 2의 과정은 도 7에 도시된 과정에 상응할 수 있다. 구체적으로, 제1 STA(1410) 및 제2 STA(1420)은 802.11 규격에 따른 인증 및 결합 절차를 수행할 수 있다. 이후, 제1 STA(1410) 및 제2 STA(1420)은 네트워크 정보 전달 프로토콜에 의한 절차를 수행할 수 있다. 예를 들어, 네트워크 정보 전달 프로토콜은 smart ThinQ, OCF(Open Connectivity Foundation) 등을 포함할 수 있다. 네트워크 정보 전달 프로토콜에 의한 절차가 수행된 뒤, 제2 STA(1420)은 네트워크 연결 정보를 획득할 수 있다. 제2 STA(1420)은 네트워크 연결 정보에 기초하여 AP(1430)와의 연결을 수립할 수 있다.
제1 STA(1410) 및 제2 STA(1420)은 연결을 종료할 수 있다. 이후, 제2 STA(1420)은 Soft-AP를 비활성화 할 수 있다. 또한, 제1 STA(1410)은 AP(1430)와 다시 연결을 수립할 수 있다.
도 14에 도시된 실시 예에 따르면, Case 1(제1 STA(1410)이 DPP를 지원하는 경우)에서는, DPP가 이용될 수 있다. Case 2(제1 STA(1410)이 DPP를 지원하지 않는 경우)에서는, Soft-AP 연결 기술이 이용될 수 있다. 따라서, 제1 STA(1410)은 DPP 및 Soft-AP 연결 기술 간의 간섭이 없이 두 기술을 모두 사용할 수 있다.
도 15는 DPP를 활용한 Soft-AP 연결을 기반으로 연결을 수립하는 또 다른 절차를 도시한다.
도 15를 참조하면, 제1 STA(1510)(즉, 구성자)이 제2 STA(1520)(즉, 등록자)에게 제1 STA(1510)의 DPP 부트스트랩 URI 정보를 전송하기 위한 절차가 도시될 있다.
구체적으로, 제1 STA(1510)은 제2 STA(1520)으로부터 비콘을 수신할 수 있다. 제1 STA(1510)은 비콘에 응답하여, 제2 STA(1520)에게 프로브 요청 프레임을 전송할 수 있다. 프로브 요청 프레임은 DPP Bootstrap URI IE를 포함할 수 있다. 제1 STA(1510)은 DPP Bootstrap URI IE를 통해 제1 STA(1510)의 DPP 부트스트랩 URI를 전송할 수 있다.
일 실시 예에 따르면, 프로브 요청프레임은 제2 STA(1520)의 DPP 부트스트랩 URI를 요청하기 위한 DPP Bootstrap URI request IE를 포함할 수 있다. 따라서, 제1 STA(1510)은 DPP Bootstrap URI request IE를 통해 제2 STA(1520)의 DPP 부트스트랩 URI를 요청할 수 있다.
일 실시 예에 따르면, 프로브 요청프레임은 제2 STA(1520)의 DPP 부트스트랩 URI를 요청하기 위한 DPP Bootstrap URI request IE를 포함하지 않을 수도 있다. 따라서, 제1 STA(1510)은 DPP Bootstrap URI request IE를 통해 제2 STA(1520)의 DPP 부트스트랩 URI를 요청하지 않을 수도 있다.
제1 STA(1510) 및 제2 STA(1520)이 자신의 DPP 부트스트랩 URI를 교환하는 경우, 제1 STA(1510) 및 제2 STA(1520)은 DPP 인증(authentication) 과정에서 mutual authentication을 수행할 수 있다.
도 16은 DPP를 활용한 Soft-AP 연결을 기반으로 연결을 수립하는 또 다른 절차를 도시한다.
도 16을 참조하면, 제2 STA(1620)(즉, 등록자)가 제1 STA(1610)의 DPP 부트스트랩 URI를 비콘을 통해 송신하는 절차가 설명될 수 있다.
구체적으로, 제2 STA(1620)은 Soft-AP가 활성화된 후, 비콘을 전송할 수 있다. 상기 비콘은 DPP bootstrap URI IE를 포함할 수 있다. DPP bootstrap URI IE는 DPP bootstrap URI 정보를 포함할 수 있다. 즉, 제2 STA(1620)은 비콘을 통해 제2 STA(1620)의 DPP bootstrap URI 정보를 전송할 수 있다.
제1 STA(1610)은 제2 STA(1620)으로부터 비콘을 수신할 수 있다. 제1 STA(1610)은 비콘을 통해 제2 STA(1620) DPP bootstrap URI 정보를 획득할 수 있다. 따라서, 제1 STA(1610) 및 제2 STA(1620)은 제2 STA(1620)의 DPP bootstrap URI 정보를 획득하기 위한 프로브 요청 프레임 및 프로브 응답 프레임을 교환하지 않을 수 있다. 제1 STA(1610)은 제2 STA(1620)의 DPP bootstrap URI 정보를 획득한 후, DPP 프로토콜(예를 들어, DPP 인증 절차 또는 DPP 구성 절차)을 시작할 수 있다.
제1 STA(1610) 및 제2 STA(1620)은 제2 STA(1620)의 DPP bootstrap URI 정보에 기초하여, DPP 인증 절차 및 DPP 구성 절차를 수행할 수 있다. 제2 STA(1620)은 DPP 인증 절차 및 DPP 구성 절차에 기초하여 네트워크 연결 정보를 획득할 수 있다. 따라서 제2 STA(1620)은 AP(1630)와의 연결을 수립할 수 있다.
도 17은 제1 STA의 동작의 예를 도시한다.
도 17을 참조하면, S1710 단계에서, 제1 STA(예를 들어, 제1 STA(910, 1410, 1510, 1610))은 제2 STA(예를 들어, 제2 STA(920, 1420, 1520, 1620))으로부터 비콘을 수신할 수 있다. 구체적으로, 제1 STA은 전송 STA(예를 들어, AP(930, 1430, 1530, 1630))과 연결된 상태일 수 있다. 제1 STA은 Soft-AP가 활성화된 제2 STA으로부터 비콘을 수신할 수 있다. 일 실시 예에 따르면, 상기 비콘은 제2 STA의 DPP 지원 여부에 관한 정보를 포함할 수 있다. 일 실시 예에 따르면, 비콘은 제1 벤더 고유 정보 엘리먼트를 포함할 수 있다. 상기 제1 벤더 고유 정보 엘리먼트는 제2 STA의 DPP 지원 여부에 관한 정보 또는 DPP 역할에 관한 정보 중 적어도 하나를 포함할 수 있다.
S1730 단계에서, 제1 STA은 프로브 요청 프레임을 상기 제2 STA에게 전송할 수 있다. 구체적으로, 제1 STA은 비콘에 응답하여, 제2 STA의 DPP 부트스트랩 URI 정보 요청을 위한 프로브 요청 프레임을 제2 STA에게 전송할 수 있다. 일 실시 예에 따르면, 제1 STA은 비콘에 응답하여, 제1 STA이 DPP를 지원함을 확인할 수 있다. 제1 STA 및 제2 STA이 모두 DPP를 지원하므로, 제1 STA은 DPP 부트스트랩 URI 정보 요청을 위한 프로브 요청 프레임을 제2 STA에게 전송할 수 있다.
일 실시 예에 따르면, 프로브 요청 프레임은 제2 벤더 고유 정보 엘리먼트를 포함할 수 있다. 제2 벤더 고유 정보 엘리먼트는 DPP 부트스트랩 URI 정보 요청에 관한 정보를 포함할 수 있다.
S1750 단계에서, 제1 STA은 프로브 요청 프레임에 응답하여, 제2 STA으로부터 프로브 응답 프레임을 수신할 수 있다. 상기 프로브 응답 프레임은 DPP 부트스트랩 URI 정보를 포함할 수 있다. 제1 STA은 프로브 응답 프레임을 통해 제2 STA의 DPP 부트스트랩 URI 정보를 확인할 수 있다. 일 실시 예에 따르면, 프로브 응답 프레임은 제3 벤더 고유 정보 엘리먼트를 포함할 수 있다. 제3 벤더 고유 정보 엘리먼트는 상기 DPP 부트스트랩 URI 정보를 포함할 수 있다.
S1770 단계에서, 제1 STA은 제2 STA과 전송 STA 사이의 연결을 수립할 수 있다. 구체적으로, 제1 STA은 DPP 부트스트랩 URI 정보에 기초하여, DPP 인증 절차를 수행할 수 있다. 제1 STA은 DPP 인증 절차에 응답하여, DPP 구성 절차를 수행할 수 있다. 제1 STA은 DPP 인증 절차 및 DPP 구성 절차에 기초하여, 네트워크 연결 정보를 제2 STA에게 전송할 수 있다. 네트워크 연결 정보는 SSID 또는 PW(Password)에 관한 정보를 포함할 수 있다. 제2 STA은 획득한 네트워크 연결 정보에 기초하여, 전송 STA과 연결을 수립할 수 있다.
도 18은 본 실시 예가 적용될 수 있는 무선 장치를 나타내는 블록도이다.
도 18을 참조하면, 무선 장치는 상술한 실시 예를 구현할 수 있는 STA로서, AP 또는 non-AP STA로 동작할 수 있다. 또한, 무선 장치는 상술한 사용자(user)에 대응되거나, 사용자에 신호를 송신하는 송신 단말에 대응될 수 있다.
도 18의 무선장치는, 도시된 바와 같이 프로세서(1810), 메모리(1820) 및 트랜시버(1830)를 포함한다. 도시된 프로세서(1810), 메모리(1820) 및 트랜시버(1830)는 각각 별도의 칩으로 구현되거나, 적어도 둘 이상의 블록/기능이 하나의 칩을 통해 구현될 수 있다.
트랜시버(transceiver, 1830)는 송신기(transmitter) 및 수신기(receiver)를 포함하는 장치이며, 특정한 동작이 수행되는 경우 송신기 및 수신기 중 어느 하나의 동작만이 수행되거나, 송신기 및 수신기 동작이 모두 수행될 수 있다.
트랜시버(1830)는 무선 신호를 전송 및/또는 수신하는 하나 이상의 안테나를 포함할 수 있다. 또한, 트랜시버(1830)는 수신 신호 및/또는 송신 신호의 증폭을 위한 증폭기와 특정한 주파수 대역 상으로의 송신을 위한 밴드패스필터를 포함할 수 있다.
프로세서(1810)는 본 명세서에서 제안된 기능, 과정 및/또는 방법을 구현할 수 있다. 예를 들어, 프로세서(1810)는 전술한 본 실시 예에 따른 동작을 수행할 수 있다. 즉, 프로세서(1810)는 도 1 내지 도 13의 실시 예에서 개시된 동작을 수행할 수 있다.
프로세서(1810)는 ASIC(application-specific integrated circuit), 다른 칩셋, 논리 회로, 데이터 처리 장치 및/또는 베이스밴드 신호 및 무선 신호를 상호 변환하는 변환기를 포함할 수 있다.
메모리(1820)는 ROM(read-only memory), RAM(random access memory), 플래쉬 메모리, 메모리 카드, 저장 매체 및/또는 다른 저장 장치를 포함할 수 있다.
도 19는 프로세서에 포함되는 장치의 일례를 나타내는 블록도이다.
설명의 편의를 위해, 도 19의 일례는 송신 신호를 위한 블록을 기준으로 설명되어 있으나, 해당 블록을 이용하여 수신 신호를 처리할 수 있다는 점은 자명하다.
도시된 데이터 처리부(1910)는 송신 신호에 대응되는 송신 데이터(제어 데이터 및/또는 사용자 데이터)를 생성한다. 데이터 처리부(1910)의 출력은 인코더(1920)로 입력될 수 있다. 인코더(1920)는 BCC(binary convolutional code)나 LDPC(low-density parity-check) 기법 등을 통해 코딩을 수행할 수 있다. 인코더(1920)는 적어도 1개 포함될 수 있고, 인코더(1920)의 개수는 다양한 정보(예를 들어, 데이터 스트림의 개수)에 따라 정해질 수 있다.
인코더(1920)의 출력은 인터리버(1930)로 입력될 수 있다. 인터리버(1930)는 페이딩 등에 의한 연집 에러(burst error)를 방지하기 위해 연속된 비트 신호를 무선 자원(예를 들어, 시간 및/또는 주파수) 상에서 분산시키는 동작을 수행한다. 인터리버(1930)는 적어도 1개 포함될 수 있고, 인터리버(1930)의 개수는 다양한 정보(예를 들어, 공간 스트림의 개수)에 따라 정해질 수 있다.
인터리버(1930)의 출력은 성상 맵퍼(constellation mapper, 1940)로 입력될 수 있다. 성상 맵퍼(1940)는 BPSK(biphase shift keying), QPSK(Quadrature Phase Shift Keying), n-QAM(quadrature amplitude modulation) 등의 성상 맵핑을 수행한다.
성상 맵퍼(1940)의 출력은 공간 스트림 인코더(1950)로 입력될 수 있다. 공간 스트림 인코더(1950)는 송신 신호를 적어도 하나의 공간 스트림을 통해 송신하기 위해 데이터 처리를 수행한다. 예를 들어, 공간 스트림 인코더(1950)는 송신 신호에 대한 STBC(space-time block coding), CSD(Cyclic shift diversity) 삽입, 공간 매핑(spatial mapping) 중 적어도 하나를 수행할 수 있다.
공간 스트림 인코더(1950)의 출력은 IDFT(1960) 블록에 입력될 수 있다. IDFT(1960) 블록은 IDFT(inverse discrete Fourier transform) 또는 IFFT(inverse Fast Fourier transform)을 수행한다.
IDFT(1960) 블록의 출력은 GI(Guard Interval) 삽입기(1970)에 입력되고, GI 삽입기(1970)의 출력은 도 18의 트랜시버(1830)에 입력된다.
본 명세서의 상세한 설명에서는 구체적인 실시 예에 관하여 설명하였으나, 본 명세서의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능하다. 그러므로, 본 명세서의 범위는 상술한 실시 예에 국한되어 정해져서는 안되며 후술하는 특허청구범위뿐만 아니라 이 발명의 특허청구범위와 균등한 것들에 의해 정해져야 한다.

Claims (14)

  1. 무선랜 시스템에서,
    전송 STA과 연결된 제1 STA에서, 제2 STA로부터 비콘을 수신하는 단계;
    상기 제1 STA에서, 상기 비콘에 응답하여, 상기 제2 STA의 DPP 부트스트랩 URI(DPP Bootstrap URI) 정보 요청을 위한 프로브 요청 프레임을 상기 제2 STA에게 전송하는 단계;
    상기 제1 STA에서, 상기 프로브 요청 프레임에 응답하여, 상기 제2 STA으로부터 프로브 응답 프레임을 수신하되, 상기 프로브 응답 프레임은 상기 제2 STA의 DPP 부트스트랩 URI 정보를 포함하는 단계; 및
    상기 제1 STA에서, 상기 DPP 부트스트랩 URI 정보에 기초하여, 상기 제2 STA과 상기 전송 STA 사이의 연결을 수립하는 단계
    를 포함하는
    방법.
  2. 제1 항에 있어서, 상기 비콘은 상기 제2 STA의 DPP 지원 여부에 관한 정보를 포함하는
    방법.
  3. 제2 항에 있어서, 상기 제1 STA에서, 상기 비콘에 응답하여, 상기 DPP 부트스트랩 URI 정보 요청을 위한 프로브 요청 프레임을 상기 제2 STA에게 전송하는 단계는
    상기 제1 STA에서, 상기 비콘에 응답하여, 상기 제1 STA이 DPP를 지원함을 확인하는 단계; 및
    상기 제1 STA에서, 상기 DPP 부트스트랩 URI 정보 요청을 위한 상기 프로브 요청 프레임을 상기 제2 STA에게 전송하는 단계
    를 포함하는
    방법.
  4. 제1 항에 있어서, 상기 DPP 부트스트랩 URI 정보에 기초하여, 상기 제2 STA과 상기 전송 STA 사이의 연결을 수립하는 단계는,
    상기 제1 STA에서, 상기 DPP 부트스트랩 URI 정보에 기초하여, DPP 인증 절차를 수행하는 단계;
    상기 제1 STA에서, 상기 DPP 인증 절차에 응답하여, DPP 구성 절차를 수행하는 단계; 및
    상기 제1 STA에서, 상기 DPP 구성 절차에 응답하여, 상기 제2 STA과 상기 전송 STA의 연결을 수립하는 단계를
    포함하는
    방법.
  5. 제1 항에 있어서, 상기 프로브 요청 프레임은,
    상기 제1 STA의 DPP 부트스트랩 URI 정보를 포함하는
    방법.
  6. 제1 항에 있어서, 상기 비콘은 제1 벤더 고유 정보 엘리먼트(Vendor Specific Information Element)를 포함하고,
    상기 프로브 요청 프레임은 제2 벤더 고유 정보 엘리먼트를 포함하고,
    상기 프로브 응답 프레임은 제3 벤더 고유 정보 엘리먼트를 포함하는
    방법.
  7. 제6 항에 있어서,
    상기 제1 벤더 고유 정보 엘리먼트는 상기 제2 STA의 DPP 지원 여부에 관한 정보 또는 DPP 역할에 관한 정보 중 적어도 하나를 포함하고,
    상기 제2 벤더 고유 정보 엘리먼트는 상기 DPP 부트스트랩 URI 정보 요청에 관한 정보를 포함하고,
    상기 제3 벤더 고유 정보 엘리먼트는 상기 제2 STA의 DPP 부트스트랩 URI 정보를 포함하는
    방법.
  8. 전송 STA과 연결된 제1 STA에 있어서,
    무선 신호를 송신 및 수신하는 트랜시버(transceiver); 및
    상기 트랜시버와 결합하여 동작하는 프로세서;를 포함하되,
    상기 프로세서는,
    제2 STA로부터 비콘을 수신하고,
    상기 비콘에 응답하여, 상기 제2 STA의 DPP 부트스트랩 URI(DPP Bootstrap URI) 정보 요청을 위한 프로브 요청 프레임을 상기 제2 STA에게 전송하고,
    상기 프로브 요청 프레임에 응답하여, 상기 제2 STA으로부터 프로브 응답 프레임을 수신하되, 상기 프로브 응답 프레임은 상기 제2 STA의 DPP 부트스트랩 URI 정보를 포함하고,
    상기 DPP 부트스트랩 URI 정보에 기초하여, 상기 제2 STA과 상기 전송 STA 사이의 연결을 수립하도록 설정된
    제1 STA.
  9. 제8 항에 있어서, 상기 비콘은 상기 제2 STA의 DPP 지원 여부에 관한 정보를 포함하는
    제1 STA.
  10. 제9 항에 있어서, 상기 프로세서는,
    상기 비콘에 응답하여, 상기 제1 STA이 DPP를 지원함을 확인하고,
    상기 DPP 부트스트랩 URI 정보 요청을 위한 상기 프로브 요청 프레임을 상기 제2 STA에게 전송하도록 설정된
    제1 STA.
  11. 제8 항에 있어서, 상기 프로세서는,
    상기 DPP 부트스트랩 URI 정보에 기초하여, DPP 인증 절차를 수행하고,
    상기 DPP 인증 절차에 응답하여, DPP 구성 절차를 수행하고,
    상기 DPP 구성 절차에 응답하여, 상기 제2 STA과 상기 전송 STA의 연결을 수립하도록 설정된
    제1 STA.
  12. 제8 항에 있어서, 상기 프로브 요청 프레임은,
    상기 제1 STA의 DPP 부트스트랩 URI 정보를 포함하는
    제1 STA.
  13. 제8 항에 있어서,
    상기 비콘은 제1 벤더 고유 정보 엘리먼트(Vendor Specific Information Element)를 포함하고,
    상기 프로브 요청 프레임은 제2 벤더 고유 정보 엘리먼트를 포함하고,
    상기 프로브 응답 프레임은 제3 벤더 고유 정보 엘리먼트를 포함하는
    제1 STA.
  14. 제13 항에 있어서,
    상기 제1 벤더 고유 정보 엘리먼트는 상기 제2 STA의 DPP 지원 여부에 관한 정보 또는 DPP 역할에 관한 정보 중 적어도 하나를 포함하고,
    상기 제2 벤더 고유 정보 엘리먼트는 상기 DPP 부트스트랩 URI 정보 요청에 관한 정보를 포함하고,
    상기 제3 벤더 고유 정보 엘리먼트는 상기 제2 STA의 DPP 부트스트랩 URI 정보를 포함하는
    제1 STA.
PCT/KR2019/012890 2018-10-02 2019-10-02 무선랜 시스템에서 무선 연결을 위한 장치 및 방법 WO2020071776A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20180117889 2018-10-02
KR10-2018-0117889 2018-10-02

Publications (1)

Publication Number Publication Date
WO2020071776A1 true WO2020071776A1 (ko) 2020-04-09

Family

ID=70054922

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/012890 WO2020071776A1 (ko) 2018-10-02 2019-10-02 무선랜 시스템에서 무선 연결을 위한 장치 및 방법

Country Status (1)

Country Link
WO (1) WO2020071776A1 (ko)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160112563A (ko) * 2015-03-19 2016-09-28 삼성전자주식회사 연결요구 장치와 연결수용 장치의 초기 셋업을 지원하는 기법
WO2017148710A1 (en) * 2016-03-02 2017-09-08 Blackberry Limited Provisioning a device in a network
US20170295448A1 (en) * 2016-04-08 2017-10-12 Blackberry Limited Managed object to provision a device according to one of plural provisioning techniques
KR20170137617A (ko) * 2016-06-03 2017-12-13 삼성전자주식회사 무선 통신을 위한 셋업 방법 및 장치

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160112563A (ko) * 2015-03-19 2016-09-28 삼성전자주식회사 연결요구 장치와 연결수용 장치의 초기 셋업을 지원하는 기법
WO2017148710A1 (en) * 2016-03-02 2017-09-08 Blackberry Limited Provisioning a device in a network
US20170295448A1 (en) * 2016-04-08 2017-10-12 Blackberry Limited Managed object to provision a device according to one of plural provisioning techniques
KR20170137617A (ko) * 2016-06-03 2017-12-13 삼성전자주식회사 무선 통신을 위한 셋업 방법 및 장치

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Device Provisioning Protocol Specification Version 1.0", WIFI ALLIANCE, 9 April 2018 (2018-04-09) *

Similar Documents

Publication Publication Date Title
WO2020197294A1 (en) Apparatus and method for assisting sidelink resource configuration and allocation for direct communication in wireless communication system
WO2019177231A1 (ko) 무선랜 시스템에서 타겟 액세스 포인트에 대한 정보를 전달하기 위한 방법 및 이를 이용한 액세스 포인트
WO2012121476A1 (ko) 의료 신체 영역 네트워크에서 데이터를 송수신하기 위한 방법 및 장치
WO2012078000A2 (ko) 무선통신 시스템에서 단말 및 기지국 간 접속 방법 및 그 장치
WO2014109513A1 (ko) 무선 통신 시스템에서 디스커버리 방법 및 장치
WO2014098437A1 (ko) 무선랜 시스템에서 서비스 발견 방법 및 장치
WO2012093882A2 (en) Data communication method and apparatus via interlock between heterogeneous networks in radio access system supporting multi radio access technology
WO2013122398A1 (ko) 무선랜 시스템에서 필터링 기반 스캐닝 방법 및 장치
WO2014123383A1 (ko) 무선 통신 시스템에서 세션 수립 방법 및 장치
WO2019164268A1 (ko) 무선랜 시스템에서 무선 연결을 위한 방법 및 이를 이용한 무선 장치
WO2016167618A1 (ko) 무선 통신 시스템에서 서비스 디스커버리를 수행하는 방법 및 장치
WO2020080850A1 (ko) 다중 액세스 포인트 네트워크에서의 온보딩 방법 및 이를 사용하는 액세스 포인트
WO2017014579A1 (ko) 무선 통신 시스템에서 디스커버리를 수행하는 방법 및 장치
WO2016148406A1 (ko) 무선 통신 시스템에서 어플리케이션 서비스 플랫폼을 이용하여 서비스를 지원하는 방법 및 장치
WO2017018823A1 (ko) 무선 통신 시스템에서 어플리케이션 서비스 플랫폼 세션 형성 방법 및 장치
WO2016148523A1 (ko) 무선 통신 시스템에서 서비스 디스커버리를 수행하는 방법 및 장치
WO2017146461A1 (ko) 페이징 기법에 따른 이웃 인식 네트워크를 위한 방법 및 이를 이용한 무선 단말
WO2016186403A1 (ko) 무작위 접속을 기초로 복수의 무선 통신 단말로부터 데이터를 수신하는 무선 통신 방법 및 무선 통신 단말
WO2019194391A1 (ko) 무선랜 시스템에서 무선 장치에 관한 정보를 전달하기 위한 방법 및 이를 이용한 구성자 단말
WO2014030894A1 (ko) 무선랜 시스템에서 고속 링크 셋업 방법 및 이를 위한 장치
WO2013122395A1 (ko) 무선랜 시스템에서 고속 링크 셋업 방법 및 장치
WO2017039376A1 (ko) 무선 통신 시스템에서 연결 능력 정보를 교환하는 방법 및 장치
WO2016137097A1 (ko) Nan 장치 간의 데이터 통신 방법 및 데이터 통신을 수행하는 nan 장치
WO2016209019A1 (ko) 무선 통신 시스템에서 mdns를 이용하여 디스커버리를 수행하는 방법 및 장치
WO2016148550A1 (ko) 무선 통신 시스템에서 어플리케이션 서비스 플랫폼 세션 형성을 수행하는 방법 및 장치

Legal Events

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

Ref document number: 19868369

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19868369

Country of ref document: EP

Kind code of ref document: A1