WO2019225941A1

WO2019225941A1 - Method for establishing wireless connection in wireless lan system and wireless apparatus using same

Info

Publication number: WO2019225941A1
Application number: PCT/KR2019/006053
Authority: WO
Inventors: 조영준; 박기원; 이병주
Original assignee: 엘지전자 주식회사
Priority date: 2018-05-21
Filing date: 2019-05-21
Publication date: 2019-11-28

Abstract

A method and an apparatus for receiving an advertising packet in a wireless LAN system are proposed. Specifically, a first wireless apparatus receives a first advertising packet through a primary channel from a second wireless apparatus. The first wireless apparatus receives a second advertising packet through a secondary channel from the second wireless apparatus. The first advertising packet includes information on the secondary channel. The second advertising packet includes a header field, a bloom filter field, and an extended payload field. The extended payload field includes additional data in order to support multiple services included in the bloom filter field. The additional data includes multiple pieces of channel information and actual channel information.

Description

Method for wireless connection in wireless LAN system and wireless device using same

The present disclosure relates to wireless communication, and more particularly, to a method for wireless connection in a WLAN system and a wireless device using the same.

Wireless display transmission technology is a technology that allows the image of the mobile device to be viewed on a large screen TV (television) or monitor. Wireless display transmission technology can be largely divided into a content transmission method and a mirroring method (that is, screen casting).

The content transmission method converts a screen of a mobile device into a signal and then transmits the converted signal to a remote device. In the mirroring method, a content file is streamed to a remote device to simultaneously display an image of the mobile device on the remote device. The mirroring method has the advantage of being able to wirelessly transmit pixel information of the original screen without being dependent on a specific service.

Miracast can be understood as a wireless video transmission standard and wireless display transmission technology created by the WiFi Alliance. Miracast may also be understood as one type following a mirroring scheme.

An object of the present specification is to provide a method for wireless connection and a wireless device using the same in a WLAN system having improved performance.

The present specification proposes a method of receiving an advertising packet capable of advertising a plurality of services.

This embodiment proposes a method of configuring advertising packets for advertising a plurality of services in a bloom filter format. The first wireless device, which will be described later, may be a provider providing BLE, and the second wireless device may be a seeker looking for BLE.

The first wireless device receives the first advertising packet from the second wireless device through the primary channel.

The first wireless device receives a second advertising packet from the second wireless device through the secondary channel.

The first advertising packet includes information about the secondary channel. The second advertising packet includes a header field, a bloom filter field, and an extended payload field.

The extended payload field includes additional data to support multiple services included in the bloom filter field. The additional data includes multiple channel information and actual channel information.

The existing advertising packet defined by WFA NAN R3 is designed based on the TDS packet using BT 4.x. The TDS packet does not support an extended payload capable of advertising multiple services. There was no limit. Accordingly, the present embodiment proposes a method of constructing an advertising packet including an extended payload supporting multiple services. The advertising packet proposed in this embodiment may support BT 5.x or higher.

The additional data may support up to 254 octets. This is a much larger amount of advertising packets defined by the existing WFA NAN R3 compared to supporting up to 31 octets of payload. Thus, the advertising packet proposed in this embodiment can support a plurality of services.

The header field may include a data transfer indicate bit. If the data transmission indication bit is set to 1, the extended payload field may include the additional data.

The plurality of channel information may include interface bits for each of the plurality of services. The actual channel information may include channel information of a service in which the interface bit is set to one. For example, if the interface bit for the NAN and the infrastructure is 1, the extended payload (or additional data) may include channel information for the NAN and channel information for the infrastructure.

For example, the service in which the interface bit is set to 1 may include a first service and a second service. The additional data may include first and second length fields, first and second type fields, and first and second value fields. For example, the first service may be a NAN and the second service may be an infrastructure. In this case, the extended payload (or additional data) may be defined in LTV (Length / Type / Value) format for each service.

The first length field may include information about the length of data supporting the first service. The first type field may include an identifier of the first service. The first value field may include data supporting the first service.

The second length field may include information about the length of data supporting the second service. The second type field may include an identifier of the second service. The second value field may include data supporting the second service.

The first value field may include a third length field, a third type field, and a third value field. The second value field may include a fourth length field, a fourth type field, and a fourth value field. That is, a value field may be defined in a new LTV format.

The first wireless device may transmit a third advertising packet to the second wireless device.

The first wireless device may perform NAN (Neighbor Awareness Network) service discovery with the second wireless device based on the first to third advertising packets.

The first advertising packet may be defined in the format of a transport discovery service (TDS) packet of the ADV_EXT_IND type. The second advertising packet may be defined in the format of a TDS packet of type AUX_ADV_IND. The third advertising packet may be defined in the format of a TDS packet of type ADV) NONCON_IND.

The primary channel may be set to any one of three predetermined channels among 40 channels having a 2 MHz bandwidth of the 2.4 GHz band. The secondary channel may be set to any one of the remaining channels except for the three channels in 40 channels having the 2 MHz bandwidth of the 2.4 GHz band.

The 2.4 GHz band may be a band for BLE (Bluetooth low energy) based communication. The primary channel may be an advertising channel, and the secondary channel may be a data channel.

According to an embodiment of the present disclosure, a method for wireless connection and a wireless device using the same in a WLAN system having improved performance may be provided.

1 is an exemplary diagram illustrating a structure of an IEEE 802.11 system.

2 is a view for explaining a WFD device discovery process.

3 is a diagram for explaining a P2P GO negotiation process.

4 is a flowchart for determining a group owner based on an intent value.

5 is a conceptual diagram of a DPP procedure.

6 is a flowchart illustrating a process of performing a DPP procedure between wireless devices.

7 illustrates channelization for BLE-based communication.

8 shows an example of a frame format for TDS.

9 shows an example of a frame format for TDS in the advertising mechanism triggered BLE.

10 shows an example of a structure of a BLE Advertisement packet according to the present embodiment.

11 illustrates an example of an operation of ADV_EXT_IND and AUX_ADV_IND according to the present embodiment.

12 shows an example of a bloom filter frame format supporting multiple services.

13 shows another example of a bloom filter frame format supporting multiple services.

14 shows another example of a bloom filter frame format supporting multiple services.

15 shows another example of a bloom filter frame format supporting multiple services.

16 illustrates a procedure of an NAN R3 operation procedure using ADV_NONCON_IND.

17 shows a procedure of an operation procedure of a proposed technique using ADV_EXT_IND and AUX_ADV_IND.

18 is a flowchart illustrating a procedure of receiving an advertising packet according to the present embodiment.

19 is a flowchart illustrating a procedure of transmitting an advertising packet according to the present embodiment.

20 is a view for explaining an apparatus for implementing the method as described above.

21 illustrates a more detailed wireless device implementing an embodiment of the present invention.

1 is an exemplary diagram illustrating a structure of an IEEE 802.11 system.

Referring to FIG. 1, an IEEE 802.11 architecture may be composed of a plurality of components, and a wireless LAN system supporting transparent STA mobility to upper layers by their interaction may be provided in a wireless local system. area network, hereinafter referred to as "WLAN").

The Basic Service Set (BSS) may be a basic building block of an IEEE 802.11 LAN. Referring to FIG. 1, two BSSs (BSS1 and BSS2) exist and each BSS may include two STAs. For example, STA1 and STA2 may be included in BSS1, and STA3 and STA4 may be included in BSS2.

Here, the STA means a device that operates according to the Medium Access Control (MAC) / PHY (Physical) specification of IEEE 802.11. A station (STA) may include an access point (AP) STA (simply an AP) and a non-AP STA. The AP corresponds to a device that provides a network (eg, WLAN) connection to a non-AP STA through an air interface. The station may be called various names such as a (wireless LAN) device.

The AP may be configured in a fixed or mobile form and may include a portable wireless device (eg, laptop computer, smart phone, etc.) that provides a hot spot. AP is a base station (BS), Node-B, Evolved Node-B (eNB), Base Transceiver System (BTS), femto base station in other wireless communication fields (Femto BS) or the like.

Non-AP STAs generally correspond to devices that a user directly handles, such as laptop computers, PDAs, wireless modems, and smart phones. The non-AP STA includes a terminal, a wireless transmit / receive unit (WTRU), a user equipment (UE), a mobile station (MS), a mobile terminal, a mobile subscriber station. (Mobile Subscriber Station, MSS) and the like.

Referring to FIG. 1, an ellipse representing a BSS may be understood to represent a coverage area where STAs included in each BSS maintain communication. This area may be referred to as a basic service area (BSA). The most basic type of BSS in an IEEE 802.11 LAN is an independent BSS (IBS).

For example, the IBSS may have a minimal form consisting of only two STAs. In addition, BSS (BSS1 or BSS2) of FIG. 1 is the simplest form and can be understood as a representative example of IBSS. This configuration is possible when STAs can communicate directly. In addition, this type of LAN is not configured in advance, but may be configured when a LAN is required. This type of LAN may be referred to as an ad-hoc network.

In an existing WLAN system, operations between devices (ie, AP and STA) in an infrastructure BSS (basic service set) in which an access point (AP) functions as a hub are mainly defined.

The AP may be responsible for a physical layer support function for a wireless / wired connection, a routing function for devices on a network, a function of adding / removing a device to a network, and a service providing function. That is, in the existing WLAN system, devices in a network are connected through APs, but not directly connected to each other.

As a technology for supporting direct connection between devices, a Wi-Fi Direct (WFD) standard is defined. Wi-Fi Direct (WFD) is a direct communication technology that allows devices (or STAs) to easily connect with each other without an access point basically required in a conventional WLAN system. When Wi-Fi Direct (WFD) is used, a connection is established between devices without complicated setup process to provide various services to the user.

Wi-Fi Direct (WFD) is also called Wi-Fi P2P. Wi-Fi P2P adds support for direct device-to-device communication while retaining most of the functionality of the existing Wi-Fi standard. Therefore, there is an advantage in that the device equipped with the Wi-Fi chip (chip) can fully utilize hardware and physical characteristics, and provide P2P communication between devices mainly by upgrading software functions.

In the P2P group, there is a device that plays the role of an AP in an existing infrastructure network. In the P2P specification, the device is called a P2P group owner (hereinafter referred to as 'P2P GO'). Various P2P clients may exist around P2P GO. Only one P2P GO can exist in one P2P group, and all other devices become client devices.

The Wi-Fi Alliance (hereinafter referred to as "WFA") provides various services using the Wi-Fi Direct link (e.g., Send, Play, Display, Print, etc.). Supported Wi-Fi Direct Service (WFDS) is being studied. According to the WFDS, an application may be controlled or managed by an application service platform (hereinafter referred to as 'ASP').

The WFDS devices supported by the WFDS may include devices supporting a WLAN system such as a display device, a printer, a digital camera, a projector, and a smartphone. In addition, the WFDS device may include a STA and an AP. WFDS devices in the WFDS network may be directly connected to each other.

The WFD standard is defined for transferring audio / video (AV) data between devices while satisfying high quality and low latency. WFD networks (WFD sessions) with the WFD standard allow Wi-Fi devices to connect to each other in a peer-to-peer manner without going through a home network, office network, or hot-spot network. Can be.

Hereinafter, a device for transmitting and receiving data according to the WFD standard may be expressed by the term WFD device. WFD devices in the WFD network may search for information about the WFD devices (for example, capability information), establish a WFD session, and render content through the WFD session.

A WFD session may be a network between a source device that provides content and a sink device that receives and renders the content. In this specification, the source device may be referred to as a WFD source. In this specification, a sink device may be referred to as a WFD sink.

The WFD source may mirror data present on the display (or screen) of the WFD source to the display of the WFD sink. The WFD source and the WFD sink may perform a device discovery and service discovery procedure by exchanging a first sequence message between each other.

After the device discovery procedure and service discovery procedure between the WFD source and the WFD sink are completed, an internet protocol (hereinafter, referred to as 'IP') address may be allocated for each of the WFD source and the WFD sink. After a transmission control protocol (“TCP”) connection is established between the WFD source and the WFD sink, a real time streaming protocol (“RTSP”) stack for the WFD source and the WFD sink and A real time protocol (RTP) stack may be activated.

A capability negotiation procedure between the WFD source and the WFD sink may be performed via RTSP. The WFD source and the WFD sink may exchange RTSP based messages (ie, M1 through M4) during the capability negotiation procedure. Thereafter, the WFD source and the WFD sink may exchange WFD session control messages.

In addition, a data session via RTP may be established between the WFD source and the WFD sink. User datagram protocol (UDP) may be used for data transport in a WFD network.

FIG. 2 is a diagram for describing a WFD device discovery process. Referring to FIG. 2, in step S210, the WFD device discovery process may be initiated by an indication of a station management entity (SME) / application / user / vendor.

The WFD device discovery process may include a scan phase S212 and a find phase S214-S216.

For example, in the scanning step S212 # 1, the first P2P device 202 may search for the neighboring P2P device according to the 802.11 scheme for all available wireless channels. In scan step S212 # 1, the first P2P device 202 may identify the best operating channel.

As another example, in the scanning step S212 # 2, the second P2P device 204 may search for the neighboring P2P device according to the 802.11 scheme for all available wireless channels. In scan step S212 # 2, the second P2P device 204 may identify the best operating channel.

In a search step (S214-S216), the listening state may include a listen state S214 and a search state S216. The P2P device may alternately transition the listening state S214 and the search state S216.

The P2P device in the listening state S214 may wait to receive a probe request frame from another P2P device. For example, the P2P device in the listening state S214 may maintain a reception state on a particular one of three social channels (ie, ch # 1, ch # 6, ch # 11).

For example, the first P2P device 202 in the first listening state S214 # 1 may wait on the first channel ch1. As another example, the second P2P device 204 in the second listening state S214 # 2 may wait on the sixth channel ch6.

The P2P device in the search state S216 may perform active scanning using the probe request frame.

For example, the search range in which active scanning is performed for fast searching may be limited to social channels such as channel 1, channel 6, and channel 11 (eg, 2412 MHz, 2437 MHz, 2462 MHz). Can be.

For example, when a probe request frame transmitted from the first P2P device (eg, 202) in the first search state S216 # 1 is received, the second P2P device (eg, 204) may receive a probe response frame. frame).

The time (eg, 100, 200, 300 Time Units (TU)) for the listening state S214 may be randomly determined. The P2P devices may reach each other's common channel through repetition of the discovery state S214 and the reception state S216.

If another P2P device is found, the P2P device may exchange probe request frames and probe response frames with other P2P devices. This allows P2P devices to discover / exchange each other's device type, manufacturer or friendly device name.

When necessary information about the neighboring P2P device found through the WFD device discovery process is acquired, the P2P device (eg, 202) may inform the SME / application / user / vendor of the P2P device discovery (S218 # 1).

At present, P2P is mainly used for semi-static communication such as remote printing, photo sharing and the like. However, due to the popularity of Wi-Fi devices and location-based services, the utilization of P2P is getting wider.

3 is a diagram for explaining a P2P GO negotiation process.

Referring to FIG. 3, the first P2P device 302 of FIG. 3 corresponds to the first P2P device 202 of FIG. 2, and the second P2P device 304 of FIG. 3 corresponds to the second P2P device (FIG. 2) of FIG. 204).

In operation S310, when a probe request frame is received from the second P2P device 304 found through the WFD device discovery process, the first P2P device 302 may respond with a probe response frame. In this case, the first P2P device 302 and the second P2P device 304 may operate on the same channel (that is, ch # 1).

Accordingly, when the probe response frame is received, the second P2P device 304 may discover the first P2P device 302.

In operation S320, the first P2P device 302 may transition to a formation state for the P2P group to start the P2P group formation process.

In operation S321, the first P2P device 302 may transmit a GO negotiation request frame to the second P2P device 304.

For example, a first intent value preset in the first P2P device 302 for a group owner (hereinafter, 'GO') may be '3'. For example, the GO negotiation request frame may include information corresponding to the first intent value '3' of the first P2P device 302.

The second P2P device 304 may attempt to switch to the formed state according to the GO negotiation request frame received in step S321.

In operation S322, the second P2P device 304 may transmit a GO negotiation response frame to the first P2P device 302. For example, in step S322, the state of the second P2P device 304 is a search state, not a formation state. Accordingly, the GO negotiation response frame transmitted in step S322 may include information indicating a failure.

In operation S330, the second P2P device 304 may transition to the formation state to start the P2P group formation process.

In operation S331, the first P2P device 302 may transmit a GO negotiation request frame to the second P2P device 304. For example, the GO negotiation request frame may include information corresponding to the first intent value '3' of the first P2P device 302.

In operation S332, the second P2P device 304 may transmit a GO negotiation response frame to the first P2P device 302. For example, the second intent value preset in the second P2P device 304 for the group owner GO may be '10'.

In this case, since the second P2P device 304 has completed the transition to the formed state, the GO negotiation response frame transmitted in step S332 corresponds to the second intent value '10' of the second P2P device 304. Information may be included.

In operation S333, the first P2P device 302 may transmit a GO negotiation confirm frame to confirm the GO negotiation process to the second P2P device 304.

For example, after transmission of the GO negotiation confirm frame, the first P2P device 302 may operate as a client. In addition, after the transmission of the GO negotiation confirm frame, the second P2P device 304 may operate as the group owner GO.

4 is a flowchart for determining a group owner GO based on an intent value.

3 and 4, 'x1' in FIG. 4 may be a first intent value of the first P2P device 302. 'X2' in FIG. 4 may be a second intent value of the second P2P device 304.

Each of the

P2P devices

302 and 304 may perform a comparison operation based on its own intent value and the counterpart device's intent value through steps S331 and S332 of FIG. 3. Hereinafter, the P2P device may be understood as the first P2P device 302 or the second P2P device 304 of FIG. 3.

In operation S410, the P2P device may compare whether 'x1' and 'x2' are the same value.

If it is determined that 'x1' and 'x2' are not the same value, the procedure proceeds to step S420. In operation S420, the P2P device may determine whether 'x1' is less than 'x2'.

For example, if 'x1' is determined to be smaller than 'x2', in operation S431, the second P2P device 304 having 'x2' may be determined as the group owner GO. As another example, if 'x1' is determined to be greater than 'x2', in operation S432, the first P2P device 302 having 'x1' may be determined as the group owner GO.

If 'x1' and 'x2' are determined to be the same value, the procedure proceeds to step S440. In operation S440, the P2P device may determine whether 'x1' and 'x2' are smaller than '15'.

For example, if 'x1' and 'x2' are determined to be smaller than '15', the P2P device in which a specific bit is set to '1' among the two P2P devices may be the group owner GO. As another example, if 'x1' and 'x2' are determined to be greater than '15', the group owner GO cannot be determined among the two P2P devices.

5 is a conceptual diagram of a device provisioning protocol (DPP) procedure.

Referring to FIG. 5, the DPP architecture for the DPP procedure includes a DPP Bootstrapping protocol, a DPP Authentication protocol, a DPP Configuration protocol, and a DPP Introduction protocol. The device roles can be defined.

In the DPP procedure, there can be two types of roles for the wireless device. For example, there may be a role of a configurator and an enrollee. As another example, there may be a role of an initiator and a responder.

For clarity and concise description of FIG. 5, the configurator may be understood as the first wireless device 510. The enrollee may be understood as the second wireless device 520.

For example, the first wireless device 510 as a configurator may support the setup of the second wireless device 520 as a registrant. Constructors and registrants may engage in the DPP bootstrap protocol, the DPP authentication protocol, and the DPP configuration protocol.

The configurator or registrar may play the role of an initiator in the DPP bootstrap protocol and the DPP authentication protocol. However, only an 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. Optionally, to provide mutual authentication, the wireless devices can obtain each other's bootstrap keys.

Once the DPP authentication protocol is complete, the configurator can provision the registrant for device-to-device communication or infrastructure communication.

As part of this provisioning, the configurator may allow the enrollee to establish secure associations with other peers in the network. Here, another peer may be understood as a wireless device 530 already configured by the constructor.

The constructor and the registrant can be associated with the DPP authentication protocol. Depending on the bootstrap scenario, the configurator or registrar may play the role of initiator or responder, respectively.

The wireless device initiating the DPP authentication protocol may serve as the initiator. The wireless device responding to the initiator's request may act as a responder. The DPP authentication protocol may provide the initiator with authentication of the responder. Optionally, the DPP authentication protocol may provide the responder with authentication of the initiator.

For example, to perform unidirectional authentication, the initiator can obtain the responder's bootstrapping key. In addition, to selectively perform mutual authentication, the initiator and the responder may obtain each other's bootstrap keys.

For example, to configure an unprovisioned device 520 that serves as a registrar, the wireless device 510 may serve as a configurator. For example, a non-provisioned wireless device can be an access point or other wireless device.

When the wireless device 510 serving as a configurator initiates the DPP authentication protocol with the unprovisioned wireless device 520, the wireless device 510 may serve as an initiator.

6 is a flowchart illustrating a process of performing a DPP procedure between wireless devices. The DPP procedure of FIG. 6 may be implemented in a 3-way handshaking manner.

5 and 6, the first wireless device 610 may serve as an initiator, and the second wireless device 620 may serve as a responder.

In addition, the first wireless device 610 may serve as a configurator, and the second wireless device 620 may serve as an enrollee.

In operation S610, the first wireless device 610 and the second wireless device 620 may perform a DPP bootstrap protocol.

For example, 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 mechanism.

For example, the OOB mechanism may be implemented based on a scan QR code method based on a QR code (eg, 521), an NFC tap method, or a Bluetooth Low Energy exchange method. .

For example, the bootstrap information may include information regarding the enrollee's bootstrapping public key for the DPP authentication protocol. As an example, the bootstrap public key may be used only for the DPP authentication protocol by the constructor and registrant.

For example, the information on the global operating class channel or the channel list may be further included in the bootstrap information.

In this case, to initiate the DPP authentication protocol, the wireless device (eg, 620) may indicate that it is listening on one of the listed channels for another device (eg, 610).

As another example, the information on the global operating class channel or the information on the channel list may not be included in the bootstrap information.

In this case, the wireless device (eg, 620) may not provide guidance to which device is listening to the other device (eg, 610). Accordingly, another device (eg, 610) must iterate over all available channels.

Iteration over multiple channels can result in significant additional delay in the DPP authentication protocol. Accordingly, an apparatus using QR Code bootstrapping may be required to include a single channel or at most a short list of possible channels in the bootstrap information.

The first wireless device 610 of FIG. 6 may start an operation on a specified channel based on the 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.

Hereinafter, in the present specification, step S610 will be described on the premise that the Bluetooth Low Energy (hereinafter, referred to as BLE) scheme is implemented. In addition, in the present specification, it may be mentioned that the DPP protocol is started when the steps S620 and S630 are started.

In operation S620, the first wireless device 610 and the second wireless device 620 may perform a DPP authentication protocol.

For example, 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 registrar. In this case, the DPP authentication request frame may be transmitted through at least one channel corresponding to bootstrap information (eg, a channel list).

In operation 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.

For example, the first wireless device 610 may determine whether a DPP authentication response frame, which 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. .

For example, the predetermined time may be set based on a transmission time of the DPP authentication request frame in step S621.

For clarity 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.

If the DPP authentication response frame is not received until a predetermined time elapses according to the above assumption, step S622 is performed for retransmission of the DPP authentication response frame.

In operation 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.

For example, the first wireless device 610 may determine whether a DPP authentication response frame, which is a response to the DPP authentication request frame retransmitted in step S622, from the second wireless device 620 within a predetermined time. .

For example, the predetermined time may be set based on a transmission time of the DPP authentication request frame in step S622.

For clarity 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 resent in step S622.

If the DPP authentication response frame is not received until a predetermined time elapses according to the above assumption, step S623 is performed for retransmission of the DPP authentication response frame.

In operation S623, 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 resent in step S623.

For example, the predetermined time may be set based on a transmission time of the DPP authentication request frame in step S623.

For clarity and concise description of FIG. 6, it may be assumed that a DPP authentication response frame is received from the second wireless device 620 within a predetermined time. According to the above assumption, if a DPP authentication response frame is received before a predetermined time elapses, step S624 is performed.

In operation S624, 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 resent in operation S623.

In operation S625, the first wireless device 610 may transmit a DPP authentication confirmation frame to the second wireless device 620 to complete the DPP authentication protocol.

When the DPP authentication protocol S620 is successfully performed according to the transmission of the DPP authentication confirmation frame, a secure channel may be established between the initiator (or configurator) and the responder (or registrant).

In operation S630, the first wireless device 610 and the second wireless device 620 may perform a DPP configuration protocol.

In operation S630, the first wireless device 610 and the second wireless device 620 may use the same MAC address. In operation S630, the first wireless device 610 and the second wireless device 620 may use the same channel used during the DPP authentication protocol.

In operation S631, to start the DPP configuration protocol, the second wireless device 620 may transmit a DPP configuration request frame to the first wireless device 610. Here, regardless of whether the initiator or responder plays the role of the configurator, the DPP configuration request frame can be sent only by the enrollee.

In operation S632, the first wireless device 610 may transmit a 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. For example, the DPP configuration object may include a plurality of parameter information as shown in Table 1 below.

When the aforementioned steps S610 to S630 are successfully performed, network information of the WLAN system including an AP (not shown) previously associated with the first wireless device 610 is displayed in the second wireless device 620. Can be forwarded to For example, the network information may include SSID information or password information.

That is, the second wireless device 620 may be connected to the first wireless device 610 without performing an association procedure with an AP (not shown) coupled to the first wireless device 610. It may be connected to the WLAN system based on the network information received from 610.

FIG. 7 is a diagram illustrating channelization for BLE-based communication.

Referring to FIG. 7, 40 channels having a 2 MHz bandwidth of a 2.4 GHz band for Bluetooth low energy (BLE) based communication are illustrated.

For example, the 37 th to 39 th BLE channels (BLE ch # 37 to 39) may be used for an advertising channel.

In the present specification, the 37 th to 39 th BLE channels (BLE ch # 37 to 39) may be referred to as primary channels. Here, the advertising channel may be allocated for communication of packets exchanged to establish a connection with an advertising packet.

For example, the remaining BLE channels (BLE ch # 0 to 36) may be understood as data channels. In the present specification, the remaining BLE channels (BLE ch # 0 to 36) may be referred to as secondary channels.

That is, the remaining BLE channels (BLE ch # 0 to 36) may be used for exchange of data packets after connection.

In the BLE-based communication according to the present specification, only two types of packets (ie, advertising packets and data packets) exist.

For example, before a BLE based connection is established between wireless devices, only packets of an advertising type may be transmitted and received. In addition, after a BLE-based connection is established between wireless devices, a packet of data type may be transmitted and received.

For example, the BLE-based advertising packet may be defined as shown in Table 2 according to a specific criterion.

According to the present specification, the first criterion for defining an advertising packet may be connectivity.

For example, when a Connectable Advertising Packet is received from a counterpart wireless device, the wireless device may understand that the counterpart wireless device wants to establish a connection.

Accordingly, the wireless device can transmit a Connection Request (hereinafter referred to as CONNECT REQ) to the counterpart wireless device. In this case, when a packet of a type other than CONNECT REQ is received at the counterpart wireless device, the counterpart wireless device may ignore the packet and hop to the next channel.

As another example, when a Non-Connectable Advertising Packet is received from a counterpart wireless device, the wireless device may not transmit a CONNECT REQ.

According to the present specification, a second criterion for defining an advertising packet may be scannability.

For example, when a Scannable Advertising Packet is received from a counterpart wireless device, the wireless device may transmit a Scan Request (hereinafter referred to as SCAN REQ) to the counterpart wireless device. In this case, when a packet of a type other than SCAN REQ is received at the counterpart wireless device, the counterpart wireless device may ignore the packet.

According to the present specification, a third criterion for defining an advertising packet may be directivity.

For example, the directed packet may include the MAC address of the wireless device of the transmitting end and the MAC address information of the counterpart wireless device of the receiving end. In addition, the Directed packet may not include data desired by the user.

As another example, the Undirected packet may not include MAC address establishment of the other party's wireless device at the receiving end. In addition, the Undirected packet may include data desired by the user.

Referring to Table 2, when the type of the BLE-based advertising packet is ADV_IND, the PDU of the ADV_IND type may be understood as a packet having characteristics of Connectable and Scannable. In this case, a PDU of type ADV_IND may have a length of 8 to 39 bytes.

When the type of the BLE-based advertising packet is ADV_DIRECT_IND, the PDU of the ADV_DIRECT_IND type may be understood as a packet having the characteristic of Connectable Directed. In this case, a PDU of type ADV_DIRECT_IND may have a length of 14 bytes.

When the type of the BLE-based advertising packet is ADV_NONCONN_IND, the PDU of the ADV_NONCONN_IND type may be understood as a packet having characteristics of Non-Connectable and Non-Scannable Undireced. In this case, a PDU of type ADV_NONCONN_IND may have a length of 8 to 39 bytes.

When the type of the BLE-based advertising packet is ADV_SCAN_IND, the PDU of the ADV_SCAN_IND type may be understood as a packet having a scannable characteristic. In this case, a PDU of type Scannable may have a length of 8 to 39 bytes.

Bluetooth (BT) is a Transport Discovery Service (TDS) to support groups (organizations and / or companies) assigned to transmit group-specific-data using the Bluetooth Low Energy exchange (BLE) transport mechanism. Released a profile.

The BT SIG has assigned a specific Org.ID to the Wi-Fi Alliance. In many WFA programs (including future ones), a unified Org.Data format must be defined for general use.

A transport discovery service (TDS) allows a device using BLE wireless technology to provide a service that can be used by a transmission device other than BLE. As used herein, the term 'transport' describes a communication technique that can be used for data transmission between a server and a client. When used in conjunction with higher level specs (e.g. specs that reference and use TDS), the information provided by this service is not defined by the Bluetooth SIG, as defined by the Wi-Fi Alliance® or other organizations. / Enhanced Data Rate) or to facilitate the discovery and utilization of transmissions. This service is designed to be used by other organizations to describe their own transports and services using their own incremental requirements.

Hereinafter, the advertising data requirement for the TDS is defined.

8 shows an example of a frame format for TDS.

Here, the role of the device (that is, whether it is looking for a service (navigator), or whether it is providing a service that can be used in a particular transport (provider)), the organization and transport associated with the supported service, transport status, Describes the content and requirements of the Transport Discovery Data AD Type, which enables you to determine other information such as functionality.

Transport Discovery Data AD Type should be included in Advertising Data (ie, AdvData) and may be included in Extended Inquiry Response (EIR). EIR and Advertising packets may be different in size and may contain other information within the Transport Discovery Data AD Type.

Transport Discovery Data AD Type may be defined as follows.

FieldField	Data TypeData type	Size(octets)Size (octets)	RequirementRequirement
Transport Discovery Data AD Type CodeTransport Discovery Data AD Type Code	Uint8Uint8	1One	MM
Organization IDOrganization ID	Uint8Uint8	1One	MM
TDS FlagsTDS Flags	8bit8bit	1One	MM
Transport Data LengthTransport Data Length	Uint8Uint8	1One	MM
Transport DataTransport data	VariableVariable	Variable(typically 0-26)Variable (typically 0-26)	OO

The Transport Discovery Data AD Type Code field should be included in the Transport Discovery Data AD Type. This field shall contain a 1 octet Transport Discovery Data AD Type Code value defined in the GAP (Generic Access Profile) section of the Bluetooth SIG assignment number.

The transport block includes the Organization ID, TDS Flags, Transport Data Length, and Transport Data fields.

There may be one or more transport blocks in the Transport Discovery Data AD Type. The field value is relevant only to the transport described by the block (i.e., only in that Transport Block)

The data contained in the transport block must be fully resolvable by the client even if the entire data must be in the Generic Attribute Profile (GATT) database due to size or other limitations.

The Organization ID field must be included in the transport block.

The Organization ID field shall contain a 1 octet organization ID value of Bluetooth SIG assigned number [3], along with the value set in the appropriate organization. Details on how to notify multiple services (associated with the same or different organization IDs) in the same packet will be described later. The value of the Organization ID field is shown in FIG.

The TDS Flags field should be included in the transport block. The TDS Flags field shall contain one octet value indicating information about the device's role and device status and supported functions. Bits defined as Reserved for Future Use (RFU) must be set to zero. The value of the TDS Flags field is shown in FIG.

The Transport Data Length field should be included in the transport block. The Transport Data Length field shall contain one octet value representing the total number of octets in the following Transport Data field. This allows the scanning device to determine the length of the variable field that follows and allows for scalability in the future. For example, a Transport Data Length value of 0x10 indicates that a 16 octet transport data field follows. Similarly, a value of 0x00 of the Transport Data Length indicates that there is no transport data field.

The transport data field may be included in a transport block. Using the Transport Data field includes organization-specific-data and sorts it byte by byte. This value should fit within the available space of the Advertising Packet. The content of this field is defined by a higher level specification.

If multiple service identifiers are listed in the Transport Data field, the advertisement device must be listed in priority or descending priority. For example, if the list represents more than one supported service (corresponding to the provider role), then the order represents basic support (for example, the device can transfer data using the faster and slower legacy methods). If the list represents more than one mandatory service (corresponding to the Seeker role), the order indicates the preferred service order (for example, the device requires immediate service but other services may be of lower priority).

WFA Neighbor Awareness Networking (NAN) R3 defines the advertising mechanism for which BLE is triggered.

Multiple services may be advertised in a bloom filter format.

Service names with bloom filter elements are hashed and mapped to the Bloom filter format.

When the Channel Info bit of the header of FIG. 9 is set to 1, channel information may be transmitted as additional data.

However, if multiple interfaces associated with the bloom filter cannot set the Chanel Info Present Bit, they are only used when one interface (data link identifier) is passed.

It is not possible to support data transfer for multiple services because the mechanism for distinguishing additional data is not defined yet. Currently it is designed for NAN so data transmission is not yet considered.

The BLE-triggered advertising mechanism defined by NAN R3 is designed based on TDS using ADV_NONCONN_IND (BT4.x). Therefore, the extended payload cannot be considered in ADV_EXT_IND (BT5.0 or higher). Therefore, use a limited length (up to 32 bytes).

However, it can be assumed that the mechanism proposed herein supports multiple services using an extended payload.

Hereinafter, BLE for triggering a NAN will be described.

BLE (Bluetooth Low Energy) Transport Discovery Service (TDS) can be used to trigger the device to power on the NAN radio for service discovery. The generic frame format specified in the TDS Spec shall be used for transmitting basic service information for triggering future discovery over the NAN.

9 illustrates a BLE TDS frame format used to trigger a NAN radio. BLE trigger data is summarized in TDS AD type using the organization ID of Wi-Fi Alliance Generic Service Discovery (0x02).

The Transport Data field is composed of a 1 byte header field, a variable length Bloom filter field, and an optional channel information field. When generating this payload, no data should be present after the fields defined herein. When parsing this payload, the data behind the fields defined herein are ignored. This is to allow future specs to scale their payloads without compromising old or new analysis.

If the Channel Info Present bit is set, the Channel Informationa field is next in the packet. This field consists of an 802.11 operating class and an 802.11 channel number.

The Transport Data header field is defined in the table below.

BitsBits	Subfield Name Subfield name		DescriptionDescription
00	Bloom Filter LengthBloom Filter Length	0b0: The length of the Bloom Filter field is 10 bytes0b1: The length of the Bloom Filter field is 20 bytes0b0: The length of the Bloom Filter field is 10 bytes
1-61-6	ReservedReserved	Reserved for future useReserved for future use
77	Channel Information Present BitChannel Information Present Bit	0b0: The Channel Information field is not present0b1: The Channel Information field is present0b0: The Channel Information field is not present

The bloom filter (BF) field contains a set of bit positions set to "1" after hashing the bloom filter element.

The link layer packet format of FIG. 10 includes a PDU, and the PDU includes an advertising channel PDU. The advertising channel PDU includes a header and a payload. The payload may be defined by the header.

The header of the advertising channel PDU includes a PDU Type, RFU, TxAdd, RxAdd, Length, and RFU fields.

The PDU Type may be defined as follows.

In the above table, ADV_NONCONN_IND is a type used in NAN. In the above table, ADV_EXT_IND and AUX_ADV_IND are types to be used herein.

The payload is set to the ADV_NONCONN_IND PDU payload in the existing BT 4.x or less. The ADV_NONCONN_IND PDU payload includes an AdvA field having 6 octets and an AdvData field having 0 to 31 octets.

The payload is set to the Common Extended Advertising Payload Format in BT 5.x and above. The Common Extended Advertising Payload includes a 6-bit Extended Header Length field, a 2-bit AdvMode field, an 0-63 octet Extended Header field and an 0-254 octet AdvData field.

The above-described TDS frame format may be included in the AdvData field included in the two payloads.

ADV_EXT_IND is delivered in

BLE Advertising Channels

37, 38, and 39 called Primary Channel. ADV_EXT_IND includes information about the data channel.

AUX_ADV_IND is delivered in BLE Data Channels 0 ~ 36 called Secondary channel. AUX_ADV_IND may include actual advertising data in the payload (eg, TDS).

Specifically, the wireless device that receives the ADV_EXT_IND in the primary channel checks the channel information in the ADV_EXT_IND and passes the data to the corresponding channel. The wireless device may receive AUX_ADV_IND on the channel that has been passed to secure the Advertisement data in the payload.

The BLE triggered advertising mechanism defined by WFA NAN R3 is designed based on TDS using BT 4.x. Accordingly, there is a limitation in that extended payload for advertising multi service in ADV_EXT_IND is not supported. Therefore, the present specification proposes a frame format including an extended payload supporting multiple services. In particular, the present specification proposes a method of configuring a bloom filter format that supports multiple services advertisement.

12 illustrates a bloom filter frame in which multiple channel info exists. This embodiment defines a field representing the interface in the Data field of FIG. 12. The actual channel info field may follow the Multiple channel info field depending on which interface bit is set.

Unlike FIG. 12, FIG. 13 illustrates various interfaces using the TLV / LTV format. Referring to FIG. 13, the Data field carries Multiple channel info and Actual channel info in LTV (Length, Type, Value) format.

Referring to FIG. 14, various services may be supported by additional data transmission by using 1 bit in the Reserved field of the header. The 1 bit may be defined as a Data Transfer Indicate Bit. If the Data Transfer Indicate Bit is set to 1, one or more services related to the bloom filter may transfer additional data. Channel Info may be related to the format of the proposed additional data.

Referring to FIG. 15, a bloom filter frame may be defined as an additional data format for supporting various services. Bloom filter frames must support multiple data for different services. Bloom filters include multiple services, some of which want to carry additional data.

Some ways to indicate additional data formats are:

First, multiple services can be supported using the TLV or LTV format.

Length: This indicates the data length including the type.

Type: indicates the type of value (highest level type indicates service ID to distinguish the owner of the next data). The service ID may be hashed with a service name or a hashed bloom filter element or a WFA-defined value.

-Value: Represents data. It may be another LTV format.

Referring to FIG. 15, it can be seen that the Data Transfer Indicate Bit included in the header is set to 1 and the Data field is set to the LTV format. However, FIG. 15 also includes an embodiment in which the LTV format is set again in the value.

Referring to FIG. 16, the BLE Seeker may support service 1 and service 2, and the BLE provider may support service 1.

The BLE Seeker sends the ADV_NONCON_IND packet to the BLE Provider. The ADV_NONCON_IND packet includes a bloom filter including a header and service 1 and service 2. This is because the BLE Seeker can support Service 1 and Service 2.

The BLE Seeker receives the ADV_NONCON_IND packet from the BLE Provider. The ADV_NONCON_IND packet includes a Bloom filter including a header and service 1. This is because the BLE provider can support only service 1.

As a result, the BLE Seeker and the BLE Provider may perform NAN service discovery, and the NAN service may be turned on.

Referring to FIG. 17, the BLE Seeker may support service 1 and service 2, and the BLE provider may support service 1.

The BLE Seeker sends the ADV_EXT_IND packet to the BLE Provider. The ADV_EXT_IND packet includes data channel information. The data channel may be the secondary channel described with reference to FIG. 7.

In addition, the BLE Seeker transmits the AUX_ADV_IND packet to the BLE Provider. The AUX_ADV_IND packet includes a bloom filter including a header and service 1 and service 2. This is because the BLE Seeker can support Service 1 and Service 2.

The BLE Seeker receives the ADV_NONCON_IND packet from the BLE Provider. The ADV_NONCON_IND packet includes a Bloom filter including a header and service 1. This is because the BLE provider can support only service 1. In addition, the ADV_NONCON_IND packet includes additional data for service 1.

As a result, the BLE Seeker and the BLE Provider may perform NAN service discovery, and the NAN service may be turned on. The BLE Seeker can simplify the NAN service discovery process or later by utilizing additional data for the service 1 received in advance.

In step S1810, the first wireless device receives the first advertising packet from the second wireless device through the primary channel.

In operation S1820, the first wireless device receives a second advertising packet from the second wireless device through the secondary channel.

This embodiment proposes a method of configuring advertising packets for advertising a plurality of services in a bloom filter format. The first wireless device to be described later may be a seeker looking for BLE, and the second wireless device may be a provider providing BLE.

In operation S1910, the first wireless device transmits a first advertising packet to the second wireless device through the primary channel.

In step S1920, the first wireless device transmits a second advertising packet to the second wireless device through the secondary channel.

The wireless device 100 of FIG. 20 may correspond to an initiator STA transmitting a signal described in the above description, and the wireless device 150 may correspond to a responder STA receiving the signal described in the above description. In this case, each station may correspond to an 11ay terminal or a PCP / AP. Hereinafter, for the convenience of description, the initiator STA transmitting a signal is called a transmitting device 100, and the responder STA receiving a signal is called a receiving device 150.

The transmitter 100 may include a processor 110, a memory 120, and a transceiver 130, and the receiver device 150 may include a processor 160, a memory 170, and a transceiver 180. can do. The

transceiver

130 and 180 may transmit / receive a radio signal and may be executed in a physical layer such as IEEE 802.11 / 3GPP. The

processors

110 and 160 are executed in the physical layer and / or the MAC layer and are connected to the

transceivers

130 and 180.

The

processors

110 and 160 and / or the

transceivers

130 and 180 may include application-specific integrated circuits (ASICs), other chipsets, logic circuits, and / or data processors. The

memory

120, 170 may include read-only memory (ROM), random access memory (RAM), flash memory, memory card, storage medium and / or other storage unit. When an embodiment is executed by software, the method described above can be executed as a module (eg, process, function) that performs the functions described above. The module may be stored in the

memories

120 and 170 and may be executed by the

processors

110 and 160. The

memories

120 and 170 may be disposed inside or outside the

processes

110 and 160, and may be connected to the

processes

110 and 160 by well-known means.

The

processors

110 and 160 may implement the functions, processes, and / or methods proposed herein. For example, the

processors

110 and 160 may perform operations according to the above-described embodiment.

The operation of the processor 110 of the transmitter is specifically as follows. The processor 110 of the transmitting device transmits the first advertising packet through the primary channel, and transmits the second advertising packet through the secondary channel.

The operation of the processor 160 of the receiving apparatus is as follows. The processor 160 of the receiving apparatus receives the first advertising packet through the primary channel and the second advertising packet through the secondary channel.

21 illustrates a more detailed wireless device implementing an embodiment of the present invention. The present invention described above with respect to the transmitting apparatus or the receiving apparatus can be applied to this embodiment.

The wireless device includes a processor 610, a power management module 611, a battery 612, a display 613, a keypad 614, a subscriber identification module (SIM) card 615, a memory 620, a transceiver 630. ), One or more antennas 631, speakers 640, and microphones 641.

Processor 610 may be configured to implement the proposed functions, procedures, and / or methods described herein. Layers of the air interface protocol may be implemented in the processor 610. The processor 610 may include an application-specific integrated circuit (ASIC), another chipset, a logic circuit, and / or a data processing device. The processor may be an application processor (AP). The processor 610 may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modem (modulator and demodulator). Examples of processor 610 include SNAPDRAGONTM series processors manufactured by Qualcomm®, EXYNOSTM series processors manufactured by Samsung®, A Series processors manufactured by Apple®, HELIOTM series processors manufactured by MediaTek®, INTEL® It may be an ATOMTM series processor or a corresponding next generation processor manufactured by.

The power management module 611 manages power of the processor 610 and / or the transceiver 630. The battery 612 supplies power to the power management module 611. The display 613 outputs the result processed by the processor 610. Keypad 614 receives input to be used by processor 610. Keypad 614 may be displayed on display 613. SIM card 615 is an integrated circuit used to securely store an international mobile subscriber identity (IMSI) and its associated keys used to identify and authenticate subscribers in mobile phone devices such as mobile phones and computers. You can also store contact information on many SIM cards.

The memory 620 is operatively coupled with the processor 610 and stores various information for operating the processor 610. The memory 620 may include read-only memory (ROM), random access memory (RAM), flash memory, memory card, storage medium, and / or other storage device. When an embodiment is implemented in software, the techniques described herein may be implemented as modules (eg, procedures, functions, etc.) that perform the functions described herein. The module may be stored in the memory 620 and executed by the processor 610. The memory 620 may be implemented inside the processor 610. Alternatively, the memory 620 may be implemented outside the processor 610 and communicatively connected to the processor 610 through various means known in the art.

The transceiver 630 is operatively coupled with the processor 610 and transmits and / or receives a radio signal. The transceiver 630 includes a transmitter and a receiver. The transceiver 630 may include a baseband circuit for processing radio frequency signals. The transceiver controls one or more antennas 631 to transmit and / or receive wireless signals.

The speaker 640 outputs a sound related result processed by the processor 610. The microphone 641 receives a sound related input to be used by the processor 610.

In the case of the transmitting apparatus, the processor 610 of the transmitting apparatus transmits the first advertising packet through the primary channel, and transmits the second advertising packet through the secondary channel.

In the case of the receiving apparatus, the processor 610 of the receiving apparatus receives the first advertising packet through the primary channel and the second advertising packet through the secondary channel.

Claims

In the method for receiving an advertising packet in a WLAN system,

Receiving, by the first wireless device, the first advertising packet from the second wireless device via the primary channel; And

Receiving, by the first wireless device, a second advertising packet from the second wireless device via a secondary channel,

The first advertising packet includes information about the secondary channel,

The second advertising packet includes a header field, a bloom filter field, and an extended payload field.

The extended payload field includes additional data to support multiple services included in the bloom filter field, and

The additional data includes multiple channel information and actual channel information.

Way.
The method of claim 1,

The header field includes a data transfer indicate bit;

If the data transfer indication bit is set to 1, the extended payload field includes the additional data.

Way.
The method of claim 1,

The plurality of channel information includes interface bits for each of the plurality of services,

The actual channel information includes channel information of a service in which the interface bit is set to one.

Way.
The method of claim 3,

The service with the interface bit set to 1 includes a first service and a second service,

The additional data includes first and second length fields, first and second type fields, first and second value fields,

The first length field includes information about the length of data supporting the first service,

The first type field includes an identifier of the first service,

The first value field includes data supporting the first service,

The second length field includes information about the length of data supporting the second service,

The second type field includes an identifier of the second service,

The second value field includes data supporting the second service,

Way.
The method of claim 4, wherein

The first value field comprises a third length field, a third type field and a third value field,

The second value field includes a fourth length field, a fourth type field, and a fourth value field.

Way.
The method of claim 1,

Sending, by the first wireless device, a third advertising packet to the second wireless device; And

Performing, by the first wireless device, NAN (Neighbor Awareness Network) service discovery with the second wireless device based on the first to third advertising packets.

Way.
The method of claim 6,

The first advertising packet is defined in the format of a TDS (Transport Discovery Service) packet of type ADV_EXT_IND,

The second advertising packet is defined in the format of a TDS packet of type AUX_ADV_IND,

The third advertising packet is defined in the format of a TDS packet of type ADV) NONCON_IND.

Way.
The method of claim 1,

The primary channel is set to any one of three predetermined channels out of 40 channels having a 2 MHz bandwidth of 2.4 GHz band,

The secondary channel is set to any one of the remaining channels except for the three channels in 40 channels having the 2 MHz bandwidth of the 2.4 GHz band,

The 2.4GHz band is a band for BLE (Bluetooth low energy) based communication,

The primary channel is an advertising channel,

The secondary channel is a data channel

Way.
The method of claim 8,

The first wireless device is a provider for providing the BLE,

The second wireless device is a seeker looking for the BLE.

Way.
The method of claim 1,

The additional data supports up to 254 octets.

Way.
In a first wireless device for receiving an advertising packet in a wireless LAN system, the first wireless device,

Memory;

Transceiver; And

A processor operatively coupled with the memory and the transceiver, the processor comprising:

Receiving, by the first wireless device, the first advertising packet from the second wireless device via the primary channel; And

Receiving, by the first wireless device, a second advertising packet from the second wireless device via a secondary channel,

The first advertising packet includes information about the secondary channel,

The second advertising packet includes a header field, a bloom filter field, and an extended payload field.

The extended payload field includes additional data to support multiple services included in the bloom filter field, and

The additional data includes multiple channel information and actual channel information.

Wireless device.
The method of claim 11,

The header field includes a data transfer indicate bit;

If the data transfer indication bit is set to 1, the extended payload field includes the additional data.

Wireless device.
The method of claim 11,

The plurality of channel information includes interface bits for each of the plurality of services,

The actual channel information includes channel information of a service in which the interface bit is set to one.

Wireless device.
The method of claim 13,

The service with the interface bit set to 1 includes a first service and a second service,

The additional data includes first and second length fields, first and second type fields, first and second value fields,

The first length field includes information about the length of data supporting the first service,

The first type field includes an identifier of the first service,

The first value field includes data supporting the first service,

The second length field includes information about the length of data supporting the second service,

The second type field includes an identifier of the second service,

The second value field includes data supporting the second service,

Wireless device.
The method of claim 14,

The first value field comprises a third length field, a third type field and a third value field,

The second value field includes a fourth length field, a fourth type field, and a fourth value field.

Wireless device.
The method of claim 11,

The processor sends a third advertising packet to the second wireless device; And

The processor may perform NAN service discovery with the second wireless device based on the first to third advertising packets.

Wireless device.
The method of claim 16,

The first advertising packet is defined in the format of a TDS (Transport Discovery Service) packet of type ADV_EXT_IND,

The second advertising packet is defined in the format of a TDS packet of type AUX_ADV_IND,

The third advertising packet is defined in the format of a TDS packet of type ADV) NONCON_IND.

Wireless device.
The method of claim 11,

The primary channel is set to any one of three predetermined channels out of 40 channels having a 2 MHz bandwidth of 2.4 GHz band,

The secondary channel is set to any one of the remaining channels except for the three channels in 40 channels having the 2 MHz bandwidth of the 2.4 GHz band,

The 2.4GHz band is a band for BLE (Bluetooth low energy) based communication,

The primary channel is an advertising channel,

The secondary channel is a data channel

Wireless device.
The method of claim 18,

The first wireless device is a provider for providing the BLE,

The second wireless device is a seeker looking for the BLE.

Wireless device.
In a method for transmitting an advertising packet in a WLAN system,

Transmitting, by the first wireless device, the first advertising packet to the second wireless device through the primary channel; And

Sending, by the first wireless device, a second advertising packet to the second wireless device through a secondary channel;

The first advertising packet includes information about the secondary channel,

The second advertising packet includes a header field, a bloom filter field, and an extended payload field.

The extended payload field includes additional data to support multiple services included in the bloom filter field, and

The additional data includes multiple channel information and actual channel information.

Way.