KR20130079105A

KR20130079105A - 무선 랜을 위한 효율적인 스캐닝 방법

Info

Publication number: KR20130079105A
Application number: KR1020120074226A
Authority: KR
Inventors: 이재승; 정민호; 이제헌; 구자범; 박재우; 이석규
Original assignee: 한국전자통신연구원
Priority date: 2011-12-22
Filing date: 2012-07-06
Publication date: 2013-07-10
Also published as: KR20230019918A; US11172434B2; US20190289539A1; KR20210080342A; KR20130079209A; KR102496405B1; KR102087408B1; US20220030509A1; KR102271826B1; KR20200026868A

Abstract

본 발명은 무선 랜 환경에서 active scanning 수행시 packet flooding을 줄이고 스캐닝 시간을 단축시킬 수 있는 효율적인 스캐닝 방법에 대한 것이다.

Description

무선 랜을 위한 효율적인 스캐닝 방법{.}

본 발명은 무선 랜 환경에서 scanning 수행시 packet flooding을 줄이고 스캐닝 시간을 단축시킬 수 있는 효율적인 스캐닝 방법에 대한 것이다.

802.11 무선 랜에서 STA이 ESS에 연결되어 인터넷 서비스를 받기 시작하기 까지의 initial Link setup time을 줄이기 위해서는 연결할 AP를 선택하기 위한 초기 스캐닝 시간을 줄이는 것이 필수적이다. Initial Link setup 시간의 상당 부분은 scanning이 차지하기 때문이다.

802.11 무선 랜에서의 스캐닝 방법은 passive scanning과 active scanning 두가지가 있다. Passive scanning에서는, STA이 wireless medium의 각 채널을 하나씩 순차적으로 listen하면서 beacon frame이 오기를 기다려 beacon으로부터 AP에 대한 정보를 얻는 방법이며, 보통 default beacon 주기가 100ms이고 각 채널마다 beacon이 올 때까지 기다려야 하기 때문에 active scanning보다 AP 발견을 위한 delay가 길다.

Active scanning에서는 STA이 각 채널에 broadcast로 Probe Request frame을 보내며 한 채널에 대해 일단 MinChannelTime 동안 채널의 activity를 감지한다. 만약 MinChannelTime 동안 해당 채널에서 아무런 activity가 감지되지 않으면 STA은 해당 채널이 inactive한 것으로 간주하고 다음 채널을 스캔한다. 만약 MinChannelTime 안에 해당 채널에 activity가 감지되는 경우 이보다 더 긴 MaxChannelTime까지 Probe Response를 기다리고, MaxChannelTime에 도달하면 그때까지 받은 Probe Response를 처리한 후, 다음 채널을 동일한 방법으로 스캔한다. 이렇게 각 채널에 대한 스캐닝 결과를 바탕으로 AP를 선택하게 된다.

본 발명의 목적은 기존의 scanning을 더욱 효율적으로 수행하도록 하여 STA이 association할 AP를 더욱 빠르게 찾아 무선 랜에서의 initial Link setup time을 줄이는 것이다. 기존의 active scanning 방법에서는 Probe Request frame을 broadcast 할 때 통상적으로 연결하고자 하는 AP의 SSID 등의 정보를 사전에 정확히 알지 못하므로 와일드 카드 SSID를 사용하며, 이를 수신한 모든 AP들이 Probe Response로 응답하기 때문에 Probe Response의 flooding 문제가 발생한다. 또한 STA이 AP의 Probe Response 내역과는 무관하게 모든 채널을 순차적으로 정해진 시간까지 스캔하여 필요이상 스캐닝 시간이 길어질 수 있으며, 또한 AP는 Probe Request를 받으면 해당 STA을 association 시킬 것인지, 혹은 Probe Request를 보낸 STA이 Probe Response를 받을 수 있는 상태인지 등을 감안하지 않고 무조건 Probe Response frame을 보내며, 이는 Probe Response flooding 문제를 더욱 심하게 만들어 initial Link setup time을 길어지게 한다.

본 발명에서는 이러한 기존의 active scanning 방법의 문제점을 해결하여 Probe Response flooding을 줄이고 scanning 시간을 단축시키는 등의 active scanning을 더욱 효율적으로 수행하는 방법을 제공한다.

본 발명의 주목적은 기존의 active scanning을 더욱 효율적으로 수행하도록 하여 STA이 association할 AP를 더욱 빠르게 찾아 무선 랜에서의 initial Link setup time을 줄이는 데 있다. 본 발명에서는 기존의 active scanning 방법의 문제점을 해결하여 Probe Response flooding을 줄이고 scanning 시간을 단축시키는 등의 active scanning을 더욱 효율적으로 수행하는 방법을 제공한다.

본 발명의 일 실시예에 따르면 무선 랜을 위한 효율적인 스캐닝 방법이 제공된다.

본 발명은 기존의 active scanning을 더욱 효율적으로 수행하도록 하여 STA이 association할 AP를 더욱 빠르게 찾아 무선 랜에서의 initial Link setup time을 줄이도록 한다. 본 발명에서는 기존의 active scanning 방법의 문제점을 해결하여 Probe Response flooding을 획기적으로 줄이고 scanning 시간을 단축시키는 등의 active scanning을 더욱 효율적으로 수행할 수 있도록 한다. 또한 기존의 legacy 장비와 호환성 문제도 없다. 또한 기존 장비의 하드웨어 수정도 요구하지 않는다.

도 1은 기존 active scanning 방법의 문제점 - 개요를 나타낸다.
도 2는 기존 active scanning 방법의 문제점 - 세부 사항을 나타낸다.
도 3은 기존 active scanning 방법의 문제점 - Probe Response flooding을 나타낸다.
도 4는 본 발명에서 제안하는 개선된 active scanning 방법을 나타낸다.
도 5는 본 발명에서 제안하는 개선된 active scanning 방법 - flooding 방지 방법을 나타낸다.
도 6은 Active Scanning 처리 절차 - 요청 STA을 나타낸다.
도 7은 Active Scanning 처리 절차 - 응답 AP (혹은 Mesh STA 혹은 STA in iBSS)을 나타낸다.

본 발명에서는 기존의 active scanning 방법의 문제점을 해결하여 Probe Response flooding을 줄이고 scanning 시간을 단축시키는 등의 active scanning을 더욱 효율적으로 수행하는 방법을 제공하고자 한다.

도 1은 기존 active scanning 방법의 문제점을 대략적으로 나타낸 것이다.

도 2는 이러한 기존 active scanning 방법의 문제점을 보다 구체적으로 나타낸 도면이다.

Active scanning에서는 도 2의 예와 같이 STA이 각 채널에 broadcast로 Probe Request frame을 보내며 한 채널에 대해 일단 MinChannelTime 동안 채널의 activity를 감지한다. 만약 MinChannelTime 동안 해당 채널에서 아무런 activity가 감지되지 않으면 (도 2의 채널 2, 채널 4 등) STA은 해당 채널이 inactive한 것으로 간주하고 다음 채널을 스캔한다. 만약 MinChannelTime 안에 해당 채널에 activity가 감지되는 경우 이보다 더 긴 MaxChannelTime까지 Probe Response를 기다리고, MaxChannelTime에 도달하면 그때까지 받은 Probe Response를 처리한 후, 다음 채널을 동일한 방법으로 스캔한다. 이렇게 각 채널에 대한 스캐닝 결과를 바탕으로 AP를 선택하게 된다.

기존의 active scanning 방법에서는 Probe Request frame을 broadcast 할 때 통상적으로 연결하고자 하는 AP의 SSID 등의 정보를 사전에 정확히 알지 못하므로 와일드 카드 SSID를 사용하며, 이를 수신한 모든 AP들이 Probe Response로 응답하기 때문에 Probe Response의 flooding 문제가 발생한다.

또한 STA이 AP의 Probe Response 내역과는 무관하게 모든 채널을 순차적으로 정해진 시간까지 스캔하여 필요이상 스캐닝 시간이 길어질 수 있다. 도 2의 경우 채널 1에서 association하기에 적합한 AP가 발견되었더라도 STA은 마지막 채널까지 스캔하기 때문에 필요 이상으로 스캐닝 타임이 길어질 수 있다. 또한 AP는 Probe Request를 받으면 해당 STA을 association 시킬 것인지, 혹은 Probe Request를 보낸 STA이 Probe Response를 받을 수 있는 상태인지 등을 감안하지 않고 무조건 Probe Response frame을 보낸다. 예를 들어, 도 2에서 만약 AP 1-2, AP1-3, AP 3-3 등이 Probe Request를 요청한 STA이 해당 AP가 요구하는 capability를 지원하지 않아 어차피 이후 이 STA이 해당 AP에 association을 요청하더라도 이를 요청받은 AP가 거부할 것임에도 불구하고 해당 AP는 Probe Response를 보내며, 이는 불필요한 packet 전송이고, 만약 STA이 이들 AP를 선택하여 association을 요청할 경우 association이 거절될 것이기 때문에 이는 association 과정에서의 delay도 야기시킬 수 있다.

Probe Request를 보낸 STA이 Probe Response를 받을 수 있는 상태인지 등을 감안하지 않고 무조건 Probe Response frame을 보낼 경우 Probe Response flooding을 더욱 심하게 만들 수 있다. (도 3 참조). Probe Request를 보낸 STA은 해당 채널에서 최대 MaxChannelTime 만큼 Probe Response를 수신받으며, 이 시간이 지나면 다음 채널을 스캔하기 때문에 이후에 해당 채널로 전송되는 Probe Response를 받을 수 없다. 하지만 현재의 active scanning에서는 Probe Request를 받은 AP에서 이를 전혀 고려하지 않고 무조건 Probe Response frame을 보내며, 만약 MaxChannelTime이 지났을 경우 이 Probe Response frame은 Probe Request를 보낸 STA에 수신이 되지 않는다. Probe Response는 unicast로 전송되기 때문에 해당 STA에 수신이 되지 않으면 Probe Response를 보낸 AP는 Probe Response를 재전송하게 되며, 재전송된 Probe Response도 해당 STA은 MaxChannelTime이 지난 후이기 때문에 수신받을 수 없다. 따라서 Probe Response frame의 재전송이 계속 일어나며, 이는 심각한 Probe Response flooding을 야기시킬 수 있다.

도 4는 본 발명에서 제안하는 개선된 active scanning 방법을 포괄적으로 나타낸 도면이다.

도 5는 도 3에 나타낸 기존 active scanning 방법의 Probe response flooding 문제를 해결하기 위해 본 발명에서 제안하는 개선된 active scanning 방법을 포괄적으로 나타낸 도면이다.

1. Inclusion List/Exclusion List 의 사용

본 발명에서는 Probe Request에 응답해야 하는 AP, 혹은 응답하지 말아야 하는 AP에 대한 정보를 나타내는 List를 Probe Request frame에 추가하여 Probe Response를 보내야 하는 AP (혹은 Mesh STA 혹은 iBSS의 STA)를 구체적으로 한정시켜 불필요한 Probe Response frame 전송을 막는다.

본 발명에서는 이를 Exclusion List, Inclusion List로 칭한다.

Inclusion List, Exclusion List에 응답 AP 혹은 STA을 지칭할 수 있는 SSID들의 리스트 혹은 BSSID 들의 리스트, 혹은 MESHID 들의 리스트, 혹은 HESSID 들의 리스트, 혹은 Roaming consortium 정보 등을 포함하는 Network ID들의 리스트 들을 필요에 따라 한 종류 혹은 여러 종류를 포함시킨다. 다음 설명은 이에 대한 실시예이다. 다음의 예에서는 Information element를 정의하여 사용하였다. 하지만 Information element 형태를 사용하는 것은 단지 하나의 예이며, 일반 sub field 형태로 Probe Request 에 포함시키거나, 다른 제 3의 Information element 나 field에 sub field 형태로 포함시킨 후 해당 Information element 나 field가 Probe Request frame에 포함되도록 하는 방법도 가능하다. 본 문서의 설명에서 각 필드의 순서나 필드 길이는 하나의 실시예로 적절한 형태로 변경하여 사용할 수 있으며, 일부 필드가 필요에 따라 더 추가되거나 삭제될 수도 있다.

(1) BSSID element

BSSID element는 STA의 BSSID 혹은 맥 주소를 포함하는 element로 포맷의 예는 (그림 1-1) 과 같다.

Length field의 값은 BSSID 길이를 octet으로 나타낸 값이다.

BSSID field는 STA의 BSSID 혹은 맥 주소를 포함한다.

BSSID field가 모두 1일 경우 wildcard BSSID를 나타낸다.

(그림 1-1) BSSID element 의 예

BSSID element를 information element 형태로 Exclusion List 혹은 Inclusion List에 포함시키거나, 아니면 information element 형태가 아닌 BSSID 정보를 나열한 필드를 Exclusion List 혹은 Inclusion List에 포함시킬 수도 있다.

(2) HESSID element

HESSID element는 HESSID를 포함하는 element로 포맷의 예는 (그림 1-2)와 같다.

Length field의 값은 HESSID 길이를 octet으로 나타낸 값이다.

HESSID field는 HESSID를 포함한다.

HESSID field가 모두 1일 경우 wildcard BSSID를 나타낸다.

(그림 1-2) HESSID element의 예

HESSID element를 information element 형태로 Exclusion List 혹은 Inclusion List에 포함시키거나, 아니면 information element 형태가 아닌 HESSID 정보를 나열한 필드를 Exclusion List 혹은 Inclusion List에 포함시킬 수도 있다.

(4) BSSID List element

BSSID List element의 포맷의 예는 (그림 1-4)와 같다.

Length field의 값은 BSSID List 길이를 octet으로 나타낸 값이다 (길이는 가변).

BSSID List field는 STA이 정보를 요청하는 각 BSSID들에 해당하는 BSSID element의 list로, 각각의 BSSID element는 element ID, length field, BSSID information field를 포함한다.

길이가 0인 BSSID List field는 wildcard BSSID를 나타낸다.

BSSID List element는 Inclusion List element 혹은 Exclusion List element에 포함된다.

(그림 1-4) BSSID List element의 예

BSSID List 를 information element 형태로 Exclusion List 혹은 Inclusion List에 포함시키거나, 아니면 information element 형태가 아닌 BSSID List 정보를 나열한 필드를 Exclusion List 혹은 Inclusion List에 포함시킬 수도 있다.

(5) HESSID List element

HESSID List element의 포맷의 예는 (그림 1-5)와 같다.

Length field의 값은 HESSID List 길이를 octet으로 나타낸 값이다 (길이는 가변).

HESSID List field는 STA이 정보를 요청하는 각 HESSID 들에 해당하는 HESSID element의 list로, 각각의 HESSID element는 element ID, length field, HESSID information field를 포함한다.

HESSID List element는 Inclusion List element 혹은 Exclusion List element에 포함된다.

(그림 1-5) HESSID List element의 예

HESSID List 를 information element 형태로 Exclusion List 혹은 Inclusion List에 포함시키거나, 아니면 information element 형태가 아닌 HESSID List 정보를 나열한 필드를 Exclusion List 혹은 Inclusion List에 포함시킬 수도 있다.

(6) MESHID List element

MESHID List element의 포맷의 예는 (그림 1-6)과 같다.

Length field의 값은 MESHID List 길이를 octet으로 나타낸 값이다 (길이는 가변).

MESHID List field는 STA이 정보를 요청하는 각 MESHID 들에 해당하는 MESHID element의 list로, 각각의 MESHID element는 element ID, length field, MESHID information field를 포함한다.

MESHID List element는 Inclusion List element 혹은 Exclusion List element에 포함된다.

(그림 1-6) MESHID List element의 예

MESHID List 를 information element 형태로 Exclusion List 혹은 Inclusion List에 포함시키거나, 아니면 information element 형태가 아닌 MESHID List 정보를 나열한 필드를 Exclusion List 혹은 Inclusion List에 포함시킬 수도 있다.

(7) Inclusion List element

Inclusion List는 Probe Request에 응답해야 하는 AP 혹은 STA을 지칭할 수 있는 SSID들의 리스트 혹은 BSSID 들의 리스트, 혹은 MESHID 들의 리스트, 혹은 HESSID 들의 리스트, 혹은 Roaming consortium 정보 등을 포함하는 Network ID들의 리스트 들을 필요에 따라 한 종류 혹은 여러 종류를 포함시킨다. 다음 설명은 이에 대한 실시예이다. 다음의 예에서는 Information element를 정의하여 사용하였다. 하지만 Information element 형태를 사용하는 것은 단지 하나의 예이며, 일반 sub field 형태로 Probe Request 에 포함시키거나, 다른 제 3의 Information element 나 field에 sub field 형태로 포함시킨 후 해당 Information element 나 field가 Probe Request frame에 포함되도록 하는 방법도 가능하다. 본 문서의 설명에서 각 필드의 순서나 필드 길이는 하나의 실시예로 적절한 형태로 변경하여 사용할 수 있으며, 일부 필드가 필요에 따라 더 추가되거나 삭제될 수도 있다.

Inclusion List element 포맷의 한가지 예는 (그림 1-7)과 같다.

Length field의 값은 Inclusion List 길이를 octet으로 나타낸 값이다 (길이는 가변)

BSSID List element는 Probe Request frame에 대한 응답을 전송해야 하는 BSS들에 대한 BSSID element의 list이다. BSSID List element에 대한 설명은 위의 (4)에 나와있다.

MESHID List element는 Probe Request frame에 대한 응답을 전송해야 하는 Mesh STA들에 대한 MESHID element의 list이다. MESHID List element에 대한 설명은 위의 (6)에 나와있다.

HESSID List element는 Probe Request frame에 대한 응답을 전송해야 하는 STA들에 대한 HESSID element의 list이다. HESSID List element에 대한 설명은 위의 (5)에 나와있다.

Inclusion List element는 Probe Request frame에 포함된다.

(그림 1-7) Inclusion List element의 예

Inclusion List는 이밖에 802.11u 규격에서 정의한 roaming consortium organization identifier 혹은 Roaming Consortium element 등의 Network를 식별하는 역할을 하는 기타 network identifier들의 리스트를 포함할 수 있다. 기타 Network identifier 들의 리스트의 예는 (7-1)과 같다

(7-1) 기타 Network identifier List의 예

기타 Network identifier List에 들어갈 수 있는 정보의 예는 STA이 가입한 Roaming consortium 에 대한 정보를 포함하는 Roaming Consortium element를 넣을 수 있다. Roaming consortium element는 다음과 같이 사용자가 가입한 Roaming consortium 의 리스트를 포함한다.

Number of ANQP OIs는 Roaming consortium OI의 개수, OI #1 and #2 Lenghts는 각 OI의 길이를 나타내는 정보이며, OI #1 ~ #n은 roaming consortium ID이다.

(그림 xxx) Roaming Consortium 정보

Roaming consortium 하나만 지정할 때에는 위와 같은 IE 형태가 아닌 OI 하나만 Inclusion List or Exclusion List에 포함시킬 수도 있으며,

다수의 OI를 IE 형태가 아닌 다른 subfield 형태로 Exclusion List 혹은 Inclusion List에 포함시킬 수도 있다.

(그림 1-7-1) Inclusion List element의 또다른 형태의 예

그림 1-7-1은 Inclusion List의 또다른 형태로, SSID List까지 추가된 형태이다. (이 경우 Exclusion List의 포맷과 동일해 진다.) 기존의 SSID List에 의해 선택된 AP/STA 들을 Inclusion List에 포함된 SSID List로 추가 한정시키거나, 기존의 SSID List를 사용하지 않고 Inclusion List에 포함된 SSID List만 가지로 AP/STA을 한정할 수 있다.

(Inclusion List를 사용하는 방법 (1), (2), (3) 참조)

(8) Exclusion List element

Exclusion List는 Probe Request에 응답하지 말아야 하는 AP 혹은 STA을 지칭할 수 있는 SSID들의 리스트 혹은 BSSID 들의 리스트, 혹은 MESHID 들의 리스트, 혹은 HESSID 들의 리스트, 혹은 Roaming consortium 정보 등을 포함하는 Network ID들의 리스트 들을 필요에 따라 한 종류 혹은 여러 종류를 포함시킨다. 다음 설명은 이에 대한 실시예이다. 다음의 예에서는 Information element를 정의하여 사용하였다. 하지만 Information element 형태를 사용하는 것은 단지 하나의 예이며, 일반 sub field 형태로 Probe Request 에 포함시키거나, 다른 제 3의 Information element 나 field에 sub field 형태로 포함시킨 후 해당 Information element 나 field가 Probe Request frame에 포함되도록 하는 방법도 가능하다. 본 문서의 설명에서 각 필드의 순서나 필드 길이는 하나의 실시예로 적절한 형태로 변경하여 사용할 수 있으며, 일부 필드가 필요에 따라 더 추가되거나 삭제될 수도 있다.

Exclusion List element의 포맷의 예는 (그림 1-8)과 같다.

Length field의 값은 Exclusion List 길이를 octet으로 나타낸 값이다 (길이는 가변)

SSID List element는 Probe Request frame에 대한 응답을 전송하지 말아야 하는 STA들에 대한 SSID element의 list이다. SSID List는 기존 802.11 규격에 정의되어 있다.

BSSID List element는 Probe Request frame에 대한 응답을 전송하지 말아야 하는 BSS들에 대한 BSSID element의 list이다. BSSID List element에 대한 설명은 위의 (4)에 나와있다.

MESHID List element는 Probe Request frame에 대한 응답을 전송하지 말아야 하는 Mesh STA들에 대한 MESHID element의 list이다. MESHID List element에 대한 설명은 위의 (6)에 나와있다.

HESSID List element는 Probe Request frame에 대한 응답을 전송하지 말아야 하는 STA들에 대한 HESSID element의 list이다. HESSID List element에 대한 설명은 위의 (5)에 나와있다.

Exclusion List element는 Probe Request frame에 포함된다.

(그림 1-8) Exclusion List element의 예

Exclusion List는 이밖에 802.11u 규격에서 정의한 roaming consortium organization identifier 혹은 Roaming Consortium element 등의 Network를 식별하는 역할을 하는 기타 network identifier들의 리스트를 포함할 수 있다. 기타 Network identifier 들의 리스트의 예는 위 (7-1) 섹션의 설명과 같다

Inclusion List, Exclusion List를 반영하여 기존의 MLME-SCAN.request primitive를 다음과 같이 확장할 수 있다. (하나의 실시예)

MLME-SCAN.request(

BSSType,

BSSID,

SSID,

ScanType,

ProbeDelay,

ChannelList,

MinChannelTime,

MaxChannelTime,

RequestInformation,

SSID List,

ChannelUsage,

AccessNetworkType,

HESSID,

MeshID,

Inclusion List,

Exclusion List,

CapabilityFilterInfo,

VendorSpecificInfo

)

Inclusion List를 사용하는 방법 (1)

Inclusion List는 BSSID, SSID, SSID List, HESSID, MeshID, 기타 Network identifier 들의 List 등에 의해 선택된 대상 AP 혹은 STA의 집합을 더욱 세부적으로 한정시킨다. 즉, BSSID, SSID, SSID List, HESSID, MeshID, 기타 Network identifier 들 등에 의해 선택된 AP 혹은 STA의 집합에서, Inclusion List에서 지정한 조건까지 만족시키는 AP 혹은 STA (즉, Inclusion List에서 지정한 BSSID List, MESHID List, HESSID List, 기타 Network identifier 들의 List 등에 포함되는 대상)이 선택되도록 한다.

Inclusion List를 사용하는 방법 (2)

또 한가지의 사용 방법으로는, 기존 규격에서 정의된 BSSID, SSID, HESSID, Mesh ID 등을 사용하지 않고, Inclusion List에서 포함하는 ID에 의해 대상 AP 혹은 STA을 정하는 방법이다. 이 경우 기존 규격에서 정의된 HESSID, Mesh ID 등은 Probe Request에 포함시키지 않는다. BSSID는 Probe Request에 포함시키지 않거나, 아무 STA 혹은 AP도 선택되지 않도록 Probe Request를 보내는 STA 자신의 맥 주소를 넣거나, 000… 혹은 11111. 등의 사용되지 않는 맥 주소를 넣을 수 있다. 또한 SSID는 Probe Request에 포함시키지 않거나, 아무 STA 혹은 AP도 선택되지 않도록 null string 등의 사용되지 않는 SSID 값을 넣을 수 있다.

이 경우 기존 Identifier는 아무런 대상도 지정하지 않게 되며, Inclusion List에 의해 대상 STA/AP가 선택되게 된다.

Inclusion List를 사용하는 방법 (3)

또 한가지의 사용 방법으로는, 기존 규격에서 정의된 BSSID, SSID, HESSID, Mesh ID 등에서 지정하는 AP 혹은 STA의 집합에 Inclusion List에서 포함하는 ID에 의해 지정되는 대상 AP 혹은 STA들의 집합의 합집합을 선택하는 방법이다.

Exclusion List도 BSSID, SSID, SSID List, HESSID, MeshID 등에 의해 선택된 대상 AP 혹은 STA의 집합을 더욱 세부적으로 한정시킨다. 즉, BSSID, SSID, SSID List, HESSID, MeshID 등에 의해 선택된 AP 혹은 STA의 집합에서, Exclusion List에서 지정한 조건까지 만족시키는 AP 혹은 STA (즉, Exclusion List에서 지정한 SSID List, BSSID List, MESHID List, HESSID List 등에 포함되지 않는 대상)이 선택되도록 한다.

Inclusion List에서 선택된 대상 AP 혹은 STA의 집합도 Exclusion List를 추가로 포함할 경우 Inclusion List에서 선택된 대상을 Exclusion List에 의해 추가로 한정시킬 수 있다. (Inclusion List에 의해 선택된 대상에서 Exclusion List가 지정한 STA/AP를 제외하는 방법, Exclusion List까지 적용하여 선택된 대상에서 Inclusion List에서 지정한 대상을 추가하는 방법 등이 사용될 수 있다.)

Inclusion List, Exclusion List는 Probe Request에 포함될 수도, 포함되지 않을 수도 있다. Inclusion List, Exclusion List 둘 중 하나만 포함될 수도 있다. (필요에 따라 포함시킴). 같은 SSID List, BSSID List, MESHID List, HESSID List, 기타 Network Identifier의 리스트가 Inclusion List 와 Exclusion List 모두에 포함되어서는 안된다.

기존의 STA은 Probe Request에 Inclusion List, Exclusion List가 포함되어 있어도 이를 무시하게 되며 (이들 information element를 해석할 수 없기 때문) 기존의 active scanning 절차에 따라 Probe response를 보내게 된다.

Inclusion List, Exclusion List에 들어가는 SSID, BSSID, MESHID, HESSID 등은 full SSID, BSSID, MESHID, HESSID 등을 사용해도 되며, full ID의 substring을 넣어 substring match가 되도록 할 수 있다. Inclusion List, Exclusion List에 substring을 지원하도록 하는 방법은 다음 (A), (B), (C)의 세가지 방법이 있다.

(A) Extended Capabilities element의 Capabilities field에 substring 사용 여부를 표시

Inclusion List 혹은 Exclusion List에 명시된 ID가 full ID인지 substring인지를 나타내기 위해 기존 802.11 Capabilities field를 다음과 같이 확장하여 사용한다.

(표 1) Substring SSID, Mesh ID 지원을 위한 Capabilities field 확장 예

이 경우 Inclusion List의 포맷은 그림 1-7-1 "Inclusion List element의 또다른 형태"에 의해 정의된 포맷을 따른다 (SSID List를 포함)

Inclusion List 혹은 Exclusion List에 포함된 SSID 혹은 MESH ID가 full SSID 혹은 MESH ID를 명시한 것이면 위의 bit를 0으로 set하고, substring을 사용한 것이면 위의 bit를 1로 set 한다. 만약 substring이 사용되었다면, Inclusion List 혹은 Exclusion List에 포함된 SSID 혹은 MESH ID를 substring으로 하는 모든 SSID 혹은 MESHID가 match되게 된다. 예를들어, Inclusion List에 SKT가 substring SSID로 포함되었다면, SKT-abcd, SKT-1234 등이 모두 Inclusion List에 포함된 것과 동일하게 취급된다.

Fast Link Setup을 위한 새로운 Capabilities field를 도입하게 되는 경우, 위와 같이 기존의 Capabilities field를 확장하지 않고, 새롭게 도입되는 capabilities field에 위와 같은 bit를 추가하여 유사한 방법으로 사용하여도 된다.

(B) Inclusion List, Exclusion List에 SubstringInfo field를 추가하는 방법 I

이 방법에서는 (A)에서처럼 Capabilities field를 사용하지 않고, Inclusion List, Exclusion List element 자체에 Substring 사용 관련 정보를 포함하는 SubstringInfo field를 새로이 정의하여 추가하여 substring 사용 관련 정보를 나타낸다.

이를 위해 그림 1-7 Inclusion List, 그림 1-8 Exclusion List를 다음과 같이 확장하여 사용한다.

확장된 Inclusion List element의 포맷의 예는 그림 1-7a과 같다. (이 경우 Inclusion List와 Exclusion List format이 동일)

(그림 1-7a) 확장된 Inclusion List element의 예

확장된 Exclusion List element의 포맷은 그림 1-8a와 같다.

(그림 1-8a) 확장된 Exclusion List element의 예

SubstringInfo field를 다음과 같이 정의하여 사용한다. (그림 1-8-1)

(그림 1-8-1) SubstringInfo field format의 예

Substring Supported subfield는 STA이 SSID 혹은 Mesh ID를 substring으로 표시할 수 있는지를 나타내며, 만약 이 필드가 1이면 해당 STA이 SSID 혹은 Mesh ID를 substring으로 표시할 수 있음을 나타내며, 0이면 해당 STA이 SSID 혹은 Mesh ID를 substring으로 명시할 수 없음을 나타내고, 이 경우 Substring Type의 값은 reserved 된다.

Substring Type subfield는 SSID 혹은 Mesh ID element 에 포함된 substring의 type을 나타낸다. Substring Type subfield의 값의 의미는 표 2와 같다.

(표 2) Substring Type subfield의 값 설명 (하나의 예시이며, value는 변경 가능)

위와 같은 SubstringInfo field 를 사용하여 Exculsion List, Inclusion List에 포함된 Mesh ID, SSID가 substring인지의 여부를 나타내며, 이 방법에서는 Exclusion List 혹은 Inclusion List에 포함된 모든 Mesh ID 혹은 SSID에 대하여 한꺼번에 substring 여부를 지정한다. (즉, 개별 Mesh ID, SSID에 대해 각각에 대해 substring 형태를 다르게 지정하지 않고, 전체를 동일한 옵션으로 지정함)

Probe request에 포함된 Exclusion List, Inclusion List에서 SubstringInfo field 확인결과 만약 substring이 사용되었다면, Inclusion List 혹은 Exclusion List에 포함된 SSID 혹은 MESH ID를 substring으로 하는 모든 SSID 혹은 MESHID가 match되게 된다.

(C) Inclusion List, Exclusion List에 SubstringInfo field를 추가하는 방법 II (또다른 방법)

이 방법에서는 (B)를 변형하여, 각각의 Mesh ID, SSID에 대해 SubstringInfo field를 사용하여 substring 적용 형태를 각각 다르게 지정할 수 있다.

이를 위해 그림 1-7 Inclusion List, 그림 1-8 Exclusion List를 다음과 같이 (B)와는 다르게 확장하여 사용한다. (Inclusion List, Exclusion List format 동일)

방법 (C)에서 확장된 Inclusion List element의 포맷은 그림 1-7b과 같다.

(그림 1-7b) 또다르게 확장된 Inclusion List element의 예

방법 (C)에서 확장된 Exclusion List element의 포맷은 그림 1-8b와 같다.

(그림 1-8b) 또다르게 확장된 Exclusion List element의 예

위의 또다른 방법으로 확장한 Inclusion List, Exclusion List element 내부에 새롭게 정의한 Extended SSID List element, Extended MESHID List element 는 각각 그림 1-8-x1, 그림 1-8-x2와 같다.

(그림 1-8-x1) Extended SSID List element의 예

SubstringInfo field는 방법 (B)에서 정의한 것과 동일하다. (그림 1-8-1 SubstringInfo field format 참조)

방법 (C)에서는 Exclusion List, Inclusion List에 들어가는 각 SSID에 대해 SubstringInfo field를 쌍으로 Extended SSID List에 넣음으로써, 각각의 SSID에 대해 substring 사용 여부, 사용 형태를 각각 다르게 지정할 수 있다.

한 SSID에 대한 substring 정보를 나타내는 SubstringInfo field, 해당 SSID)의 쌍이 Exclusion List, Inclusion List에 포함되는 SSID의 개수만큼 반복적으로 Extended SSID List에 들어간다. 이를 통해 각 SSID에 대해 다른 형태로 substring 을 사용할 수 있다.

(substringInfo, SSID) 쌍들에서, SSID의 형태는 다음 둘중의 하나로 사용한다.

a. 32 octet 길이의 SSID field를 사용. String이 SSID field에 들어감.

b. 기존 802.11에서 정의된 SSID element를 사용. String이 SSID element 내부의 SSID field에 들어감.

한 exclusion list, Inclusion List에 들어가는 SSID는 위의 두가지 중 한 형태로 (substringIfo, SSID)를 지정한다 (두가지를 섞어서 사용은 안됨)

(그림 1-8-x2) Extended MESHID List element의 예

방법 (C)에서는 Exclusion List, Inclusion List에 들어가는 각 Mesh ID에 대해 SubstringInfo field를 쌍으로 Extended MESHID List에 넣음으로써, 각각의 Mesh ID에 대해 substring 사용 여부, 사용 형태를 각각 다르게 지정할 수 있다.

(한 Mesh ID에 대한 substring 정보를 나타내는 SubstringInfo field, 해당 Mesh ID)의 쌍이 Exclusion List, Inclusion List에 포함되는 Mesh ID의 개수만큼 반복적으로 Extended MESHID List에 들어간다. 이를 통해 각 Mesh ID에 대해 다른 형태로 substring 을 사용할 수 있다.

(substringInfo, Mesh ID) 쌍들에서, Mesh ID의 형태는 다음 둘중의 하나로 사용한다.

a. 32 octet 길이의 Mesh ID field를 사용. String이 Mesh ID field에 들어감.

b. 기존 802.11에서 정의된 Mesh ID element를 사용. String이 Mesh ID element 내부의 Mesh ID field에 들어감.

한 exclusion list, Inclusion List에 들어가는 Mesh ID는 위의 두가지 중 한 형태로 (substringIfo, Mesh ID)를 지정한다 (두가지를 섞어서 사용은 안됨)

Probe request에 포함된 Exclusion List, Inclusion List에서 Extended SSID List, Extended MESHID List내의 각 SubstringInfo field 확인결과 만약 각 SSID 혹은 Mesh ID에 substring이 사용되었다면, Inclusion List 혹은 Exclusion List에 포함된 각 SSID 혹은 각 MESH ID를 substring으로 하는 모든 SSID 혹은 MESHID가 match되게 된다.

Inclusion List, Exclusion List는 (표 3)과 같이 기존의 Probe Request frame에 추가되며, (표 3) 그 한 예이다.. Fast Link Setup 기능이 지원됨을 알리는 dot11FILSActivated 가 true이고, Inclusion List 혹은 Exclusion list의 field가 nonzero이면 Inclusion List, Exclusion List가 Probe Request frame에 포함될 수 있다.

(표 3) 본 발명을 위해 Probe Request frame에 추가된 부분의 예

위에서 Timeout Interval (ProbeResponse deadline interval)., Probe Response Listen Start Interval을 하나의 information element로 정의하여 사용할 수 있다.

2. STA의 Association capability/요청 STA의 선호도/AP의 Policy를 고려한 Probe Response

Probe Request를 받은 AP가 위의 1절에 해당하는 category에 의해 Probe Response를 보내야 하더라도, Probe Request를 보낸 STA의 capability가 충분하지 않을 때는 이에 대해 response를 보내지 않거나, association 할 수 없음을 의미하는 Null Probe response를 보낸다. 또한 STA이 자신의 capability 이외에 자산의 선호도 (즉, STA이 암호화 등 보안 기능을 제공하기는 하지만 사용하고 싶지 않다거나, 반드시 HT, 혹은 VHT 모드 등으로만 사용하겠다, 인터넷 억세스를 반드시 원한다, AP의 access delay, 수용 가능한 현재 admission capacity 등의 AP의 운영 condition에 대한 요구 사항, AP의 BW 혹은 Spatial Stream Utilization 등의 AP의 resoruce에 대한 요구 사항, AP가 지원하는 Advertisement protocol 선호도, STA이 선호하는 access network type, AP가 위치한 venue 정보 등의 선호도)를 probe request에 넣어 보내도록 하여, AP가 이러한 STA의 선호도 (즉, STA의 요구 사항)을 들어줄 수 없을 때도 이에 대해 response를 보내지 않거나, association 할 수 없음을 의미하는 Null Probe response를 보낸다.

Probe Request frame을 보면, Probe Request를 보낸 STA의 capability를 알 수 있다. 즉 Extended Capabilities, HT Capabilities, VHT Capabilities 등을 보고 해당 STA이 11n STA인지, 11ac STA인지, 지원 가능한 BW는 어디까지인지 등의 정보를 알 수 있다. 또한 본 발명은 여기에 STA의 device type, STA의 security capability (지원하는 algorithm, 보안 token 혹은 credential, 지원하는 채널 정보 등을 추가하여 AP에 전달하여 AP가 STA의 능력을 보고 filtering 하는 것을 더욱 세밀하게 할 수 있도록 한다.

본 발명에서 추가한 특정한 capability, preference 등에 대한 구체적인 정보, 필드 등은 단지 예이며, 해당 정보를 다양한 포맷으로 바꾸어도 되며, 필드 순서, 길이 등은 필요에 따라 바꾸어도 되며, 설명에 나온 필드 일부 혹은 추가 필드 등을 필요에 따라 선별하여 선택적으로 사용할 수 있다.

가. 방법 1

본 발명에서는, STA의 capability를 AP에 알리는 방법으로, 표 3에서와 같이 Probe Request에 RSN IE (Information Element)까지 추가하여, Probe Request frame을 통해 해당 STA의 보안 처리 능력까지 Probe request시 알릴 수 있도록 하였다.

RSN IE는 기존 802.11에 정의된 element로, STA이 지원하는 암호 알고리즘, 인증 방법, 보안 capability 등에 대한 정보가 들어 있다. AP는 이 element를 보고, STA의 보안 처리 능력을 알 수 있다. 만약 STA이 특정 암호 알고리즘 등 보안 옵션을 지원하지만 이를 사용하고 싶지 않은 경우, 해당 알고리즘 등 보안 파라미터를 RSN IE에 포함시키지 않는다

이 때, 기존의 RSN IE 중 PKMID-Count, PKMID List 등은 capabilities를 나타내는데 굳이 없어도 되기 때문에 이들을 포함시키지 않도록 해도 된다.

나. 방법 2

STA의 capability 및 Preference를 보다 더 자세하게 알리기 위해 이를 나타내는 새로운 필드를 정의할 수도 있다. 본 발명에서는 이를 CapabilityFilterInfo element로 지칭하며, Probe Request에 포함시킨다.

Information element를 사용한 것은 하나의 예이며, 본 발명의 설명에 포함된 정보 들을 다른 형태로 Probe Request에 포함시켜도 무방하다.

CapabilityFilterInfo element 는 Probe Request에 대한 응답을 요청받은 AP or STA이 STA의 preference, capability를 알 수 있도록 하여 요청 STA에게 Probe Response를 보낼지 말지를 결정하는데 사용된다.

CapabilityFilterInfo element의 format의 예는 (그림 2-1)과 같다.

필드 순서, 길이는 변경 가능하며, 특정 필드만 포함할 수도 있다.

(그림 2-1) CapabilityFilterInfo element의 예

Filtering preference field는 STA의 선호도를 나타내는 데 쓰이며, Security capability element는 STA의 보안 능력을 나타낸다.

이 밖에 STA이 AP에 요구하는 기타 capability, preference 등을 더 추가할 수 있다.

Filtering preference는 AP에 대한 STA의 요구 사항을 나타낸 필드이며, Filtering Preference field의 format의 예는 (그림 2-2)와 같다.

(그림 2-2) Filtering Preference field의 format의 예

Filter Request subfield는, Probe request를 보내는 STA이 CapabilityFilterInfo element 를 보냈을 경우, 이를 수신받은 AP가 여기에 포함된 preference, capability 정보를 보고 AP가 자신의 policy 등을 참고하여 해당 STA에 Probe Response를 보내거나 보내지 않는 filtering을 수행할 지의 여부를 나타낸다.

즉, 이 필드가 1이면 Probe request를 받은 AP or STA은 CapabilityFilterInfo element 및 Probe Request에 포함된 HT capabilities, VHT capabilities 등의 정보를 보고, 해당 STA의 capability 및 preference를 확인하여, 이들이 자신의 policy에 맞고, Probe Request에 포함된 Supported rates element에 명시된 Supported Rates가 자신이 지원하는 rate을 만족할 경우에만 probe response를 응답한다.

이 필드가 0이면 응답 AP or STA은 위의 preference, capability와 상관없이 무조건 Probe Response를 보낸다.

Filtering Preference field의 format은 그림 2-2-a와 같이 사용할 수도 있다.

그림 2-2에서 Filter Request field를 삭제한 경우이며, 이 경우는 CapabilityFilterInfo element가 Probe Request에 포함된 경우는 Probe request를 받은 AP or STA은 CapabilityFilterInfo element 및 Probe Request에 포함된 HT capabilities, VHT capabilities 등의 정보를 보고, 해당 STA의 capability 및 preference를 확인하여, 이들이 자신의 policy에 맞고, Probe Request에 포함된 Supported rates element에 명시된 Supported Rates가 자신이 지원하는 rate을 만족할 경우에만 probe response를 응답하며 (즉 그림 2-2에서 Filter Request field가 1인 경우와 동일), CapabilityFilterInfo element가 Probe Request에 포함되지 않은 경우 응답 AP or STA은 위의 preference, capability와 상관없이 무조건 Probe Response를 보낸다. (즉, 그림 2-2에서 Filter Request field가 0인 경우와 동일))

(그림 2-2-a) Filtering Preference field의 format (2)의 예

Requesting STA은 보안 처리를 사용하기를 원할때만 Require Security field를 1로 설정한다. 그리고 이 필드가 1일 경우 반드시 CapabilityFilterInfo element에 security capability element 를 포함해야 한다. security capability element는 요청 STA의 보안 처리 능력을 나타낸다. 이 필드가 1이면 Require No security field는 반드시 0으로 설정해야 한다.

Require No Security subfield는 요청 STA이 자신이 보안 처리 능력을 지원하던 지원하지 않던 상관없이, 보안 처리를 원하지 않는 경우 1로 설정한다. 1로 설정한 경우는 security capability element를 포함할 필요가 없다.

만약 요청 STA이 특별한 보안 선호도 (보안 사용/미사용)가 없을 경우, Require Security, Require No Security를 모두 1로 설정한다. 이 경우도 CapabilityFilterInfo element에 security capability element 를 포함해야 한다.

Require Security, Require No Security의 의미를 정리하면 표 2-1과 같다.

(표 2-1) Require Security, Require No Security의 의미 정리표 (숫자는 바뀔 수 있으며, 요구 사항을 표현하는 하나의 예임)

Require HT, Require VHT, Require non-HT의 의미를 정리하면 표 2-2와 같다.

(표 2-2) Require HT, Require VHT, Require non-HT의 의미 정리표 (숫자는 바뀔 수 있으며, preference를 나타내는 하나의 예시임)

Reserved field를 이용해 이 밖의 추가 preference를 정의하여 추가할 수 있다. 이를테면, STA이 특정 값 이상의 신호세기를 만족하는 경우만 AP에 연결되기를 원하는 경우, 이러한 정보를 Reserved field에 추가하여 사용할 수 있다.

CapabilityFilterInfo element 의 Security capability element의 format은 (그림 2-3)과 같다.

이 element는 요청 STA의 보안 capability를 나타낸다.

(그림 2-3) Security capability element의 예

(m: Group Data Cipher Suite Count, n: Pairwise Cipher Suite Count, o: AKM Suite Count, p: Group Management Cipher Suite Count)

Version, Pairwise Cipher Suite Count, Pairwise Cipher Suit List, AKM Suite Count, AKM Suite List, RSN Capabilities fields 는 기존 802.11의 RSN element에 사용되는 field와 동일하다. (See 8.4.2.27 of 802.11 Revmb D12).

기존의 RSN element에서는 Group Data Cipher Suite, Group Management Cipher Suite을 하나만 지정할 수 있었는데, 본 발명에서는 이를 여러 개 지정할 수 있도록 하여 STA이 선호하는 Cipher Suite을 여러 개 지정할 수 있도록 하였다.

The Group Data Cipher Suite Count field는 Group Data Cipher Suite List field에 포함된 Group data cipher suite selector의 개수를 나타낸다.

Group Data Cipher Suite List는 지원하는 Group Data Cipher Suite의 리스트를 포함한다.

Group data cipher suite은 BSS에서 group addressed frame을 보호하는데 쓰인다.

The Group Management Cipher Suite Count field는 Group Management Cipher Suite List field에 포함된 Group Management cipher suite selector의 개수를 나타낸다.

Group Management Cipher Suite List는 지원하는 Group Management Cipher Suite의 리스트를 포함한다.

Group management cipher suite은 BSS에서 group addressed robust management frame을 보호하는데 쓰인다.

만약 요청 STA이 특정 Cipher Suite을 지원하더라도 이를 사용하고 싶지 않으면 해당 Cipher Suite을 Security capability element에 포함시키지 않아 STA의 보안 선호도를 나타내는 용도로도 사용될 수 있다.

위와 같이 확장된 Probe Request frame을 통해 AP (혹은 Mesh STA 혹은 STA in iBSS) 는 Probe request를 한 STA의 capability 및 preference (선호도)를 알 수 있으며, AP는 해당 STA이 자신이 요구하는 capability (혹은 AP의 policy)를 만족하는지의 여부, AP가 STA의 선호도 (혹은 요구사항)을 만족시켜 줄 수 있는지를 판단하여, 이를 만족할 수 없으면, Probe Response를 보내지 않거나, association (or peering) 할 수 없음을 의미하는 Null Response frame을 보낸다. 해당 STA이 어차피 AP가 요구하는 capability가 없으면거나, STA이 반드시 쓰고자 요구하는 기능을 AP가 지원하지 않을 경우, Probe Response frame을 보내더라도, 해당 STA은 그 AP에 association 할 수 없으니, Probe Response를 아예 보내지 않아 불필요한 frame 전송을 막을 수 있다. 또한 AP가 요구하는 capability가 없는 STA이 AP에 association을 요청할 경우 해당 AP는 association을 거절할 것이며, 이는 association 단계에서의 delay를 가져온다. 따라서 AP가 Probe request를 보낸 STA이 AP가 요구하는 능력을 만족하지 못할 경우 차라리 response를 보내지 않거나, association 받을 수 없음을 나타내는 Null Probe Response frame을 보내는 것이 Link Setup time을 줄이는데 더 도움이 된다.

위의 CapabilityFilterInfo를 이용한 Probe Response filtering 방법의 한 실시예는 다음과 같다. 이를 응용한 다른 형태의 필터링도 가능하다.

(구체적인 실시예)

만약 Probe Request frame에 CapabilityFilterInfo element가 포함되어 있는 경우, 요청받은 STA or AP는 다음의 조건이 만족될 때만 Probe Response로 응답하고, 만족되지 않은 경우 Probe Response를 보내지 않거나 null response를 보낸다.

a) CapabilityFilterInfo element안의 Filter Request subfield 가 0으로 설정된 경우 Probe Response frame을 응답으로 보낸다.

또는 b), c)를 모두 만족하는 경우 Probe Response frame을 응답으로 보낸다.

b) CapabilityFilterInfo element안의 Filter Request subfield 가 1로 설정되고,

1) 응답 STA이 CapabilityFilterInfo element안의 Require Security subfield 와 Require No security subfield 에 명시된 보안 처리 preference를 만족하고,

2) 응답 STA이 CapabilityFilterInfo element안의 Require HT subfield와 Require VHT subfield와 Require non-HT subfield에 명시된 preference를 만족하고,

3) Require Security subfield가 1이고 Require No Security subfield가 0인 경우 요청 STA의 security capabilities가 응답 STA의 보안 정책을 만족하는 경우 Probe Response frame을 보낸다.

만약 Require Security subfield와 Require No Security subfield가 모두 1로 설정되고, 만약 응답 STA이 요청 STA에 대해 보안 처리를 원하는 경우, 응답 STA은 요청 STA의 security capabilities가 응답 STA의 보안 정책을 만족하는 경우에만 Probe Response frame을 응답으로 보낸다. 만약 Require Security subfield와 Require No Security subfield가 모두 1로 설정되고, 만약 응답 STA이 요청 STA에 대해 보안 처리를 원하지 않는 경우, 요청 STA의 security capabilities와 상관없이 Probe Response frame을 응답으로 보낸다.

요청 STA의 security capabilities가 응답 STA의 보안 정책을 만족하지 못하는 경우는 다음과 같은 경우를 말한다:

(i) 응답 STA이 AP이고, AP가 요구하는 Group Data Cipher Suite 혹은 Pairwise Cipher Suite 혹은 AKM Suite 혹은 Group Management Cipher Suite이 요청 STA의 Security capability element에 포함되지 않은 경우, 혹은

(ii) 응답 STA이 AP이고, 응답 AP가 CCMP를 지원하거나 HT를 지원하는데, 요청 STA이 HT STA이지만 요청 STA이 TKIP이나 그 이전에 나온 legacy cipher suite 만을 지원하는 경우, 혹은

(iii) 응답 STA이 AP이고, AP가 RSNA-enable 되고 RSNA를 반드시 요청 STA과 사용하려는 경우, 요청 STA의 RSN Capabilities field의 MFPC, MFPR의 값을 확인하여 이 값들이 해당 요청 STA이 응답 AP와 associate 하는데 부적합한 경우, 혹은

(iv) 응답 STA이 IBSS STA이고 요청 STA과 응답 STA이 공통의 pairwise cipher suite subset 혹은 공통의 single group cipher suite 혹은 공통의 AKMP를 지원하지 않는 경우, 혹은

(v) 응답 STA이 IBSS STA이고 응답 STA이 CCMP을 지원하거나 HT를 지원하는데 요청 STA이 HT STA이지만 요청 STA이 TKIP이나 그 이전에 나온 legacy cipher suite 만을 지원하는 경우, 혹은

(vi) 응답 STA이 IBSS STA이고, 해당 IBSS STA이 RSNA-enable 되고 RSNA를 반드시 요청 STA과 사용하려는 경우, 요청 STA의 RSN Capabilities field의 MFPC, MFPR의 값을 확인하여 이 값들이 요청 STA이 응답 IBSS STA과 associate 하는데 부적합한 경우, 혹은

(vii) 응답 STA이 Mesh STA이고 요청 Mesh STA과 응답 Mesh STA이 공통의 pairwise cipher suite subset 혹은 공통의 single group cipher suite을 지원하지 않는 경우, 혹은

(viii) 응답 STA이 Mesh STA이고 요청 STA이 WEP-40 혹은 WEP-104혹은 TKIP만을 pairwise cipher suite이나 group cipher suite으로 지원하는 경우

c) CapabilityFilterInfo element의 Filter Request subfield가 1로 설정되어 있고 요청 STA이 보낸 Probe Request frame의 Supported rates element에 명시된 rate 들이 응답 STA or AP가 요구하는 rates (BSSBasicRateSet parameter에 포함된 rates)들을 모두 지원하는 경우 Probe Response frame을 응답으로 보낸다.

(실시예 끝)

다. 방법 3

방법 2에서, Security capability element 를 사용했으나, 방법 3에서는 이를 사용하지 않고, 기존의 RSN IE를 사용한다. 즉, CapabilityFilterInfo element에 Security capability element를 넣는 대신 기존의 RSN IE를 사용한다. 나머지는 방법 2와 동일하게 처리한다.

RSN IE는 Group Data Cipher Suite, Group Management Cipher Suite을 각각 하나씩만 포함할 수 있으나, Security capability element는 이를 여러 개 지원하도록 리스트를 포함할 수 있도록 확장 했다.

하지만, 구현상의 편의를 위해 방법 3에서는 Security capability element 대신 RSN IE를 그대로 사용한다. 이를 그림으로 나타내면 그림 x와 같다.

(그림 x) 방법3: CapabilityFilterInfo element 의 예

라. 방법 4

방법 4는, 방법 2의 또다른 변형 예로, 방법 2의 Security capability element에서 Group Management Cipher Suite을 하나만 사용할 수 있도록 바꾼 것이다.

(즉, 기존 RSN IE는 Group Data Cipher Suite, Group Management Cipher Suite을 각각 하나씩만 포함할 수 있고, 방법 2는 Security capability element는 이를 여러 개 지원하도록 리스트를 포함할 수 있도록 확장 했고, 방법 4는 Group Data Cipher Suite, Group Management Cipher Suite중에서 Group Data Cipher Suite만 여러 개 나타낼 수 있도록 확장된 것이다.)

이를 그림으로 나타내면 그림 y와 같다.

(그림 y) Security capability element의 예

(m: Group Data Cipher Suite Count, n: Pairwise Cipher Suite Count, o: AKM Suite Count)

나머지는 방법 2와 동일하게 처리한다.

마. 방법 5

방법 5는, 방법 2의 또다른 변형 예로, 방법 2의 Security capability element에서 Group Data Cipher Suite을 하나만 사용할 수 있도록 바꾼 것이다.

(즉, 기존 RSN IE는 Group Data Cipher Suite, Group Management Cipher Suite을 각각 하나씩만 포함할 수 있고, 방법 2는 Security capability element는 이를 여러 개 지원하도록 리스트를 포함할 수 있도록 확장 했고, 방법 5는 Group Data Cipher Suite, Group Management Cipher Suite중에서 Group Management Cipher Suite만 여러 개 나타낼 수 있도록 확장된 것이다.)

이를 그림으로 나타내면 그림 z와 같다.

(그림 z) Security capability element의 예

(n: Pairwise Cipher Suite Count, o: AKM Suite Count, p: Group Management Cipher Suite Count)

사. 방법 6

또다른 방법으로는, CapabilityFilterInfo element에서 Security Capability element를 삭제하고 Filtering Preference만 넣는 방법이다.

이 경우, CapabilityFilterInfo element의 길이가 아주 짧아지는 부수적인 효과가 있다.

아. 방법 7.

또다른 방법으로는, 방법 2의 또다른 변형 예로, 방법 2의 Security capability element가 그림 zz와 같은 형태로 RSN Capabilities field만 포함하도록 하는 방법이다.

(그림 zz) Security capability element의 예

최근 생산되는 무선랜 제품은 RSN 규격에서 요구하는 암호 알고리즘을 대부분 지원하는 경우가 많기 때문에, Security capability element에서 암호 알고리즘 정보를 삭제하고 RSN Capabilities field만 포함시키도록 하여 Probe Request frame size 증가를 최소화한 경우이다.

아-1. 방법 7-1.

혹은, 방법 7에서 RSN Capabilities field를 element 형태로 만들지 않고 그림 aaa와 같이 CapabilityFilterInfo element에 sub field로 넣는 방법이 있다.

(그림 aaa) 간소화된 CapabilityFilterInfo element의 예

자. 방법 8.

또다른 방법으로는, 방법 1의 변형 예로, 표 3에서와 같이 Probe Request에 RSN IE (Information Element)을 포함하는 대신에 기존의 RSN element의 필드중에서 RSN capabilities만을 포함한 그림 zzz와 같은 RSN capabilities element를 포함시는 방법이다.

(즉, 표 3의 Order x 에 그림 zzz의 RSN capabilities element가 들어감)

(그림 zzz) RSN capabilities element의 예

최근 생산되는 무선랜 제품은 RSN 규격에서 요구하는 암호 알고리즘을 대부분 지원하는 경우가 많기 때문에, RSN element에서 암호 알고리즘 정보를 삭제하고 RSN Capabilities 만 포함시키도록 하여 Probe Request frame size 증가를 최소화한 경우이다.

STA의 capability가 AP의 capability 혹은 policy를 만족하는 경우라도, AP의 현재 Load가 심하거나, 기타의 이유로 AP가 더 이상 추가 STA의 association을 받을 수 없는 경우에도 response를 보내지 않거나 Null response를 보내어 STA이 association 하는 것을 차단한다.

자. CapabilityFilterInfo의 또다른 구성예: 지원 credential type으로 필터링

(그림 2-1)의 CapabilityFilterInfo에 보다 더 정교한 filtering을 위해 추가적인 정보를 더 넣을 수 있다 (그림 자-1)은 STA이 지원하는 Credential Type을 추가한 예이다.

Fitering 정보에 STA이 지원하는 credential 정보를 포함한다.

(그림 자-1) CapabilityFilterInfo element 에 Credential type을 추가한 예

Credential 정보의 예는, STA의 SIM 지원 여부, USIM 지원 여부, NFC 지원 여부, Pre-Shared key 사용 여부, X.509 인증서 지원 여부, Username/Password 방식 지원 여부, One Time Password 사용 여부, server-side authentication 만을 지원하는 지의 여부 등을 나타낼 두 있다. (그림 자-1-1)은 이러한 Supported Credential Type을 나타내는 필드의 구성 예이다. 필드 순서, 길이는 변경 가능하며, 특정 필드만 포함할 수도 있다.

(그림 자-1-1) Supported Credential Type을 나타내는 필드의 구성 예

STA은 자신이 지원하는 보안 토큰 혹은 credential type 혹은 지원가능한 인증 방식에 대한 정보를 Probe Request에 포함시켜 보내며, AP는 STA이 자신이 요구하는 인증에 필요한 credential을 지원하지 않는 경우 STA이 어차피 해당 AP에 associate 될 수 없으므로 Probe Response를 보내지 않는다.

기존에는 STA이 특정 AP가 지원하는 인증 방식에 필요한 credential type을 알아내기 위해서는 Probe Request를 보내 Probe Response를 받은 후 해당 AP가 11u 의 advertisement 기능 (ANQP)을 지원하는 지 확인 후 해당 AP에 security credential 정보를 추가의 GAS Query를 통해 받아와 자신이 해당 credential을 지원하는 지 확인 후 association을 시도하는 번거로움이 있었으나, 이와 같이 Probe request에 STA이 지원하는 credential 정보를 포함시키면 이러한 추가적인 query/response 과정을 거치지 않고 STA이 credential 정보를 지원하지 않는 경우 바로 필터링하여 association 과정을 더욱 빠르게 할 수 있다.

차. CapabilityFilterInfo의 또다른 구성 예-1

(그림 2-1)의 CapabilityFilterInfo에 보다 더 정교한 filtering을 위해 또 추가적인 정보를 더 넣을 수 있다 (그림 자-2)는 STA이 지원하는 채널 정보를 추가한 예이다.

(그림 자-2) CapabilityFilterInfo element 에 STA이 지원하는 채널정보를 추가한 예

Supported channels 는 STA이 지원하는 channel subband의 list로 , STA이 지원하는 채널 서브밴드의 first channel number, number of channel의 쌍을 반복하여 넣을 수 있다. 물론 다른 방식으로 지원 채널 정보를 표현하는 것도 가능하다.

AP는 STA의 supported channels 정보를 보고, 해당 STA이 AP가 요구하는 채널을 지원하지 않는 경우 Probe Response를 보내지 않는다.

카. Filtering Preference field에 Internet Access 요구사항을 넣어 필터링 하는 방법

STA이 Internet Access를 원하는 지의 요구를 STA이 보내는 Probe Request에 포함시켜 이를 바탕으로 Probe Request를 필터링 할 수도 있다.

STA이 Internet Access를 원한다고 preference를 Probe Request에 나타내어 보냈는데, AP가 internet access를 지원하지 않는다면 AP는 Probe Response를 보내지 않는다.

(그림 자-3)은 이 경우를 추가한 Filtering Preference field의 format을 나타낸다.

(그림 자-3) Filtering Preference field의 format 의 구성예

하나의 실시예로, Probe Request의 Require Internet Access bit이 1이면 STA이 internet 접속을 원하는 것으로, AP가 이를 지원하지 못하면 Probe Response를 보내지 않는다. 0이면 STA이 internet 접속을 굳이 하지 않아도 되는 경우로, 이 경우는 AP가 Probe Resonse를 보낼 수 있다.

(i) 본 발명에서 제안하는 Null Response frame은, 기존의 Probe Response frame에서 Frame Body를 없앤 frame이다. Null Response frame을 받은 STA은 해당 AP (or STA)에 association (or peering)시도를 하지 않으며, 해당 AP를 Exclusion List에 추가하여 향후 해당 AP (or STA)에 대해 Probe Request를 보내지 않도록 할 수 있다. 또한 해당 AP가 Inclusion List에 포함되어 있었으면 이를 삭제할 수 있다.

(ii) Null Response frame의 Frame Body에 Reason code 필드 만을 두는 실시예도 가능하다. 이 경우 위의 Frame Body를 모두 없앤 경우와 동일하게 사용하지만, Reason code field에 association을 받을 수 없는 구체적인 reason code를 넣어 보낼 경우 STA 쪽에서 보다 자세한 정보를 전달할 수 있다.

(iii) Null Response frame을 보내지 않고 아예 응답을 보내지 않을 수 있다. 이 경우 Probe Response frame을 줄이는 효과는 더 크며, 여전히 STA이 AP에 잘못 association 되는 것을 막을 수 있는 효과도 있다.

2-X AP의 Operating 상황을 고려한 Probe Response filtering

AP가 high load, 나쁜 채널 상황, admission capacity가 꽉 찼을 경우 등에는 STA에 Probe Response를 보내도, 해당 STA이 AP에 association 실패할 확률이 높다. 이런 경우 AP는 자신의 operating 상황을 참고하여 새로운 STA에 association을 시키는게 곤란한 경우 Probe response를 보내지 않는다. 또한 STA은 명시적으로 AP에게 operating condition을 요구할 수 있다.

즉, STA은 Probe Request에 AP의 현재 average access delay, 각 access category별 access delay, AP의 현재 admission capacity 등에 대한 요구 사항을 명시하여 보낼 수 있다. 예를 들어 AP의 현재 average access delay, 각 access category별 access delay 등의 최대치가 100일 경우 STA이 수치를 90이하를 설정하여 probe request를 할 경우, AP는 자신의 delay 수치가 90이 넘는 경우 STA이 요구하는 delay 수준을 만족시키지 못하는 것이므로 probe response를 보내지 않는다. Available admission capacity의 경우도, STA이 요구하는 여유 admission capacity가 10대인데, AP의 현재 상황이 10대 미만의 admission을 허용하는 경우, AP는 Probe Response를 보내지 않는다.

이밖에 STA은 AP의 현재 spatial stream utilization, 각 밴드별 채널 utilization 등에 대한 현재 상황에 대한 자신의 요구 사항을 Probe Request에 보내어 AP가 이를 만족하지 못하면 Probe Response를 보내지 않는다. 즉, AP가 load가 심해 STA이 요구하는 access delay 혹은 admission capacity 혹은 채널 활용의 여유를 만족시키지 못할 경우 Probe Response를 보내지 않아 STA이 불필요하게 association 시도를 하는 것을 막을 수 있다.

(그림 2-x-1)은 이러한 AP Operating Condition Preference를 나타낸 예이다. 반드시 Information Element 형태일 필요는 없으며, AP는 위에서 기술한 정보를 적절한 포맷을 이용해 Probe Request에 포함시켜 AP에 전송시킨다. 이 정보는 앞서 기술한 CapabilityFilter Info element에 포함시킬 수도 있으며, 별도의 element 혹은 필드로 Probe Requestㅇ 포함시킬 수도 있다.

(그림 2-x-1) AP Operating Condition Preference를 나타낸 예

(그림 2-x-2)은 위의 AP Operating Condition Preference를 나타낸 구체적인 예이다. 필드 순서, 길이, 포맷 등은 다른 형태로 사용하는 것도 가능하다.

(그림 2-x-2) AP Operating Condition Preference를 나타낸 구체적인 예

2-Y STA의 Network Preference 를 고려한 Probe Response filtering

STA이 AP를 통해 연결되어 있는 Network의 서비스 종류, 지원하는 프로토콜, Network에서 지원하는 access 방식, Network가 위치해 있는 venue 등에 대한 preference를 Probe Request에 명시하고, AP가 이를 지원하지 않는 경우 Probe Response를 보내지 않는 방법도 있다.

이를 위해 STA의 Network Preference 정보를 담은 필드들을 Probe Request에 포함시킨다.

11u에서 지원하는 ANQP, Emergency Alert system protocol의 지원 요구, MIH Information Service, MIH Command and Event Service Capability Discovery 등의 STA이 AP를 찾기 위해 사용하고자 하는 network discovery protocol 요구를 포함시킬 수 있다. STA이 network discovery 기능을 사용하려고 하는데, AP가 이를 지원하지 않는 경우 AP는 Probe response를 보내지 않는다.

또한 STA이 지원하는 Device Type, 예를 들어 STA이 smart phone인지, VoIP Phone인지, Note book인지, Game Console인지, 디지털 카메라인지, 프린터 인지 등등을 Probe Request에 포함시켜 AP에 전달하며, AP는 자신이 특정 디바이스의 접속 만을 허용하거나, 해당 device에 대한 서비스를 지원하지 않을 경우 probe response를 하지 않는다.

또한 STA은 Probe Request에 자신이 사용하고자 하는 access network type, 예를 들어 WLAN 혹은 3GPP 혹은 WiMAX 등등을 명시하여 AP에 보낼 수 있다. 예를 들어, STA이 WLAN을 사용하다가 요금 발생 등의 문제로 3GPP로 ISP가 자동으로 스위칭 시키는 것을 원하지 않을 경우, WLAN require =1, 3GPP require =0 등으로 설정하여 network provider가 강제로 사용자의 STA을 다른 망으로 접속하게 하는 것에 대한 선호도를 명시할 수 있다.

또한 기존의 802.11에는 venue type 정보를 beacon, probe response 등에 나타내는데, STA이 특정 venue에 접속을 원하는 경우, 이를 AP에 알리고, AP가 이를 지원하지 않는 경우 Probe Response를 필터링 한다.

기존의 802.11에 venue를 나타내는 element가 존재하므로, venue 정의는 이를 활용할 수도, 혹은 새롭게 venue type을 probe request 에 맞도록 optimize하여 정의할 수 있다.

예를 들어, STA은 Probe Request의 interworking element의 venue info에 자신이 어느 venue의 네트워크에 접속하는 지를 포함시키고, Probe request에 이를 기반으로 필터링 할지의 여부를 AP에 알려주고, AP는 STA이 venue 종류를 보고 필터링을 원할 경우, Probe request에 포함되어 오는 venue type에 자신이 접속을 못하는 경우라면 Probe Response를 보내지 않는다.

또한 STA은 해당 AP를 통해 사용하고자 하는 서비스 (예를 들어, 프린팅 서비스, VoIP 서비스, 스트리밍 서비스, 웹 서핑 등등..)의 정보를 Probe Request에 포함시켜 AP에게 전송하고, AP가 이러한 서비스를 지원하지 않는 경우는 Probe Response를 보내지 않는다.

본 발명의 이해를 돕기 위해 <그림 2-Y>를 예로 표시하였다.. 예에서 필드 구성, 길이, 포맷 등은 다양하게 바꾸어도 되며, 특정 필드를 선택하여 사용하거나 필요한 필드를 추가하여 사용하는 것도 가능하다.

<그림 2-Y> Network Preference를 나타내는 예

Network filtering control의 의미는 <그림 2-Y-1>과 같으며, 단지 예로 도시하였다.

<그림 2-Y-1> Network filtering control 구성 예

Filter by supported Adv Protocol은 지원되는 advertisement protocol (ANQP, MIM Informataion Service, MIH Command and Event Services Capability Discovery, Emergency Alert System 등) 이 STA이 요구하는 게 없으면 필터링 하라는 의미이다.

Filter unsupported device type은 STA이 명시한 device type을 AP가 지원하지 않거나 접속을 허락하지 않으면 필터링하라는 의미이다.

Fiter by Access Network Preference는 WLAN 혹은 3GPP 혹은 WiMAX 등등 STA이 원하는 access network 요구 사항을 만족시키지 못하면 필터링하는 의미이다.

Filter by supported venue는 STA이 접속을 원하는 venue 요구 사항을 만족시키지 못하면 필터링하는 의미이다.

Filter by supported service는 STA이 사용을 원하는 service를 지원하지 못하면 필터링하는 의미이다.

<그림 2-Y-2>는 Preferred Advertisement Protocol field의 구성 예이다.

<그림 2-Y-2>는 Preferred Advertisement Protocol field의 구성 예.

<그림 2-Y-3>은 Preferred Access network type의 구성 예이다.

<그림 2-Y-3>는 Preferred Access network type 표현 예

이밖에 STA은 AP의 RCPI, RSNI 요구 사항 등을 Probe Requests에 포함시켜 AP가 해당 Link quality를 지원하지 못하면 Probe Response를 필터링 할 수도 있다.

3. Scanning abort 기능

기존의 active scanning 과정에서는 STA은 무조건 모든 채널을 순차적으로 정해진 시간까지 스캔하여 필요이상 스캐닝 시간이 길어질 수 있다. 하지만 본 발명에서는 Scanning 도중 스캐닝 중간 결과를 리턴하도록 하고, 중간 결과에서 적절한 AP가 발견된 경우 스캐닝 도중 스캐닝을 abort 할 수 있게 하여 스캐닝 조기 종료를 통해 스캐닝 시간 단축을 할 수 있도록 한다.

이를 위해 다음과 같은 service primitive를 기존의 802.11에 추가한다.

MLME - SCAN - ABORT . request ( )

위의 service primitive를 이용해 STA이 진행하던 active scanning을 중단시킬 수 있도록 한다.

또한 기존의 MLME - SCAN . confirm ( ) 을 확장하여, 액티브 스캐닝 도중에도 스캐닝 중간 결과를 반환하여 특정 시점까지 발견된 AP들을 STA이 확인할 수 있도록 한다. 또한 위와 같이 active scanning을 중간에 abort 시킨 경우에도, abort 시점까지 발견된 AP의 정보를 STA에게 반환하도록 한다.

MLME-SCAN.confirm()은, Null Probe Response가 수신된 경우, 이 정보를 함께 전달하며, 만약에 Reason code가 함께 수신된 경우 이 내역도 함께 전달하여 Null Response frame을 보낸 AP 혹은 STA의 Mesh ID, BSSID 등을 Inclusion List에서 제거하고, Exclusion List에 포함될 수 있도록 한다.

액티브 스캐닝 도중 중간 결과에서 적절한 AP가 발견되면, 스캐닝을 도중에 abort 하고 그때까지 발견된 AP 정보를 이용해 AP를 선택한다.

4. Selective Scanning

기존의 active scanning 과정에서는 STA은 무조건 모든 채널을 순차적으로 scanning 한다. 하지만 AP가 존재할 확률이 높은 채널부터 우선적으로 스캔한다면 적합한 AP를 더 빨리 찾아 스캐닝을 더욱 빨리 종료시킬 수 있다.

본 발명에서는, active scanning 과정에서 AP로부터 수신받은 Probe Response frame에 포함된 정보를 이용하여 selective scanning을 수행한다.

AP가 보낸 Probe Response frame에는 AP Channel Report, Neighbor Report element 등의 주변 AP 정보가 포함될 수 있다. "AP Channel Report element"는 802.11k 규격에서 정의한 element로, STA이 AP를 발견할 확률이 높은 채널 리스트를 포함하고 있다.

Active scanning 초기에 첫번째 채널에 대한 Probe Request를 보낸 후 AP로부터 응답받은 Probe Response frame에 "AP Channel Report element", "Neighbor Report element" 등이 포함되어 있는 경우, 이 element에 포함되어 보고된 채널들에 AP들이 존재할 확률이 높으므로, STA이 active scanning을 하고 있는 채널들의 리스트 중에서 다음 스캔할 채널 선택시에는 이 AP Channel Report element에 포함되어 있는 채널을 우선적으로 선택한다. 또한 이후 매번 스캔한 채널에서 수신한 Probe Response frame의 AP Channel Report를 확인하여 여기에 포함된 채널 중 아직 스캔을 하지 않은 채널 (active scanning을 실시하고 있는 채널 리스트 중 아직 스캔하지 않은 채널)을 먼저 스캔한다. 즉, 가장 최근에 수신받은 Probe Response frame에 포함된 AP Channel Report의 채널 정보를 우선적으로 사용한다.

이렇게 할 경우 적합한 AP를 더 빨리 찾을 수 있으며, 적합한 AP가 발견되면 Scanning abort 기능을 사용해 스캐닝을 중단한다. AP Channel Report 이외에도 Probe Response Frame을 응답하는 AP 주위의 채널, 위치 정보 등을 유추할 수 있는 필드가 Probe Response Frame 내에 전송되어 올 경우, 이를 활용하여 Selective Scanning을 수행할 수 있다. 이의 예를 들자면, Probe Response에 Neighbor Report element가 포함되어 온 경우, Neighbor Report element에는 Probe Response를 보낸 AP 주변 AP에 대한 BSSID, capabilities, channel 정보가 들어 있어 이를 활용해 selective scanning을 하거나 neighbor report만 보고도 해당 AP가 STA의 요구를 만족한다고 판단될 경우 해당 AP로 바로 association 요청을 할 수 있다. 또한 Location Parameter element, Measurement Report element 등의 위치 관련 정보를 포함한 element를 참조해 STA으로부터 가까운 AP가 있는 채널부터 먼저 selective scanning을 수행할 수 있다.

Selective scanning을 위한 추가적인 방법으로는, 2.4 GHz에서는 채널 1,6,11을 가장 많이 사용하므로, 2.4GHz를 사용할 경우 채널 1,6,11을 우선적으로 스캔한다.

Selective scanning을 위한 또 추가적인 방법으로는, Measurement Pilot과 같은 short beacon을 이용하는 방법이다. Measurement Pilot frame은 Beacon보다 작고 대신 보다 자주 전송되며, active scanning 도중이더라도 Measurement Pilot을 수신받을 경우 Measurement Pilot에 포함된 channel에는 확실히 AP가 존재하므로 이 채널을 우선적으로 스캔한다. 혹은 Measurement Pilot에는 BSSID 및 기본적인 AP에 관한 정보가 포함되어 있으며, 이를 바탕으로 해당 AP에 associate 할 수 있다고 판단되는 경우 scanning을 abort하여 active scanning을 조기 종료되도록 한다. 만약 Measurement Pilot에 포함되어 있는 정보만으로 AP association 여부를 판단하기 부족하다면, Measurement Pilot 수신 직후 이 Mesaurement Pilot을 전송한 AP에서 보낸 Beacon을 기다려 해당 Beacon에 포함된 정보를 추가로 검색한 후 association을 수행할 수 있다.

또한 Measurement Pilot 혹은 기타 short beacon 형태의 정보, short Probe response에 다음 full beacon 혹은 broadcast probe response 까지의 duration을 표시하여, STA이 이를 참고하여 추가 정보가 더 필요할 경우 해당 duration 만큼 기다려 beacon 혹은 broadcast probe response로부터 association에 필요한 추가 정보를 요청할 수 있다. 이때 해당 STA은 다음 비콘 등까지의 duration 정보를 정확히 알 수 있으므로 이 기간동안 파워 세이빙을 할 수도 있다.

또한 다른 STA 들이 요청한 Probe Response를 참고할 수 있다. 특히 다른 STA이 요청한 Probe Request가 broadcast로 전송되어 올 경우, STA은 이 Probe Response에 포함되어 있는 정보를 참고하여 AP에 대한 정보를 획득하여 가능하면 해당 AP에 바로 association하거나, 아니면 해당 AP에 unicast로 probe request를 할 경우 더욱 빠르게 스캐닝을 진행할 수 있다.

Selective Scanning은 Abort Scanning과 결합하여 사용될 경우 scanning 시간을 획기적으로 줄일수 있다.

5. Probe Request frame에 Timeout Interval 추가

Probe Request를 보낸 STA이 Probe Response를 받을 수 있는 상태인지 등을 감안하지 않고 무조건 Probe Response frame을 보낼 경우 Probe Response flooding을 더욱 심하게 만들 수 있다. ((도 3) 참조). Probe Request를 보낸 STA은 해당 채널에서 최대 MaxChannelTime 만큼 Probe Response를 수신받으며, 이 시간이 지나면 다음 채널을 스캔하기 때문에 이후에 해당 채널로 전송되는 Probe Response를 받을 수 없다. 하지만 현재의 active scanning에서는 Probe Request를 받은 AP에서 이를 전혀 고려하지 않고 무조건 Probe Response frame을 보내며, 만약 MaxChannelTime이 지났을 경우 이 Probe Response frame은 Probe Request를 보낸 STA에 수신이 되지 않는다. Probe Response는 unicast로 전송되기 때문에 해당 STA에 수신이 되지 않으면 Probe Response를 보낸 AP는 Probe Response를 재전송하게 되며, 재전송된 Probe Response도 해당 STA은 MaxChannelTime이 지난 후이기 때문에 수신받을 수 없다. 따라서 Probe Response frame의 재전송이 계속 일어나며, 이는 심각한 Probe Response flooding을 야기시킬 수 있다.

이를 해결하기 위해, 본 발명에서는 (표 3)과 같이 Probe Request frame에 Probe Request를 전송하는 STA이 한 채널에 대해 Probe Response를 기다리는 시간 (본 발명에서는 Timeout Interval (ProbeResponse deadline Interval)이라고 칭함)을 추가하여, 이를 수신한 AP (or Mesh STA or STA in IBSS)가 이 시간 (Timeout Interval)을 확인하고, 이 시간 ( Timeout Interval)이 지난 후에는 Probe Response를 보내지 않도록 한다. 즉, Probe Request에 Probe Request를 보낸 STA이 실제로 Probe Response를 받을 수 있는 duration을 명시하여 해당 duration에만 AP들이 Probe Response를 보낼 수 있도록 한다.

Timeout Interval (ProbeResponse deadline Interval)에는, Probe Response를 보내야 하는 ProbeResponse deadline interval (Timeout Interval) 정보가 담겨있다.

기존의 MinChannelTime, MaxChannelTime은 Probe Request를 보내는 STA이 결정하지만, 이 정보는 대상 AP 혹은 STA에 전달되지 않는다.

본 발명에서는 Probe Request를 보내는 STA이, 자신의 MinChannelTime, MaxChannelTime을 고려하여 Timeout Interval (ProbeResponse deadline Interval)을 정하고, 이를 Probe Request frame에 포함시켜 전송한다. 한 예를 들자면,

MinChannelTime <= Timeout Interval (ProbeResponse deadline Interval) <= MaxChannelTime

이 되도록 Timeout Interval (ProbeResponse deadline Interval)을 결정하며, 이를 포함한 Probe Request를 수신받은 AP 혹은 STA은, Probe Request를 보낼 때 자신이 Probe Request를 받은 시점부터 Probe Request에 명시된 Timeout Interval (ProbeResponse deadline Interval)이 경과했는지 확인하여, 이를 넘었을 경우 Probe Response를 보내지 않는다. Probe Response를 재전송 할 경우에도 Timeout Interval (ProbeResponse deadline Interval)을 확인하여 이를 넘었을 경우 재전송을 하지 않는다.

Probe Request를 보낸 STA이 Probe Request를 보낸 직후부터 해당 채널을 listen하여 Probe Response를 바로 받지 않고, 약간의 delay를 두고 난후 채널을 리슨하여 Probe Response를 수신하기 시작하기를 원할 수 있다. 이 경우 Probe Request를 보낸 STA은 Timeout Interval 이외에 Probe Response listen start interval (Probe Request를 보내고 Probe Response 수신을 시작하는 시간)을 추가로 Probe Request에 포함시켜 전송할 수 있다.

즉, (a) Probe Request에 Timeout Interval만 포함시켜 전송하는 경우는 Probe Request를 전송한 STA은 Probe Request를 보낸 직후 Timeout Interval 동안만 Probe Response를 수신하며, AP는 이 duration에만 Probe Response를 보낸다.

(b) Probe Request에 Timeout Interval과 Probe Response listen start interval을 포함시켜 전송하는 경우는 Probe Request를 전송한 STA은 Probe Request를 보내고 Probe Response listen start interval 경과후부터 Probe Response 를 리슨하기 시작하며, Timeout Interval 동안만 Probe Response를 수신하며, AP는 이 duration에만 Probe Response를 보낸다. (이 경우 STA이 Probe Response를 보내는 interval은 (a)와 같이 Timeout Interval 동안이며, (a)와 차이점은 (a)의 경우 바로 리슨을 시작하여 Timeout Interval 동안 Probe Response를 수신하고, (b)의 경우 Probe Response listen start interval 경과후 Timeout Interval 동안 Probe Response를 수신받는다. (b)의 경우는 AP는 Probe Response를 Probe Response listen start interval 이전에 보내면 안된다.

,다음은 Timeout Interval (ProbeResponse deadline Interval) element를 나타내는 방법의 예이며, ProbeResponse deadline interval을 Probe Request에 필드 형태로 포함시킬 수 있다면 어떤 방법이라도 사용 가능한다.아래 format 은 하나의 예이며, ProbeResponse deadline interval을 포함시킨다는 점 이외의 다른 추가 정보 혹은 필드 길이는 하나의 예이다.

ProbeResponse deadline interval의 길이는 사용하는 시간 단위 혹은 허용 가능한 최대 시간에 따라 1 octet 혹은 2 octet 혹은 그 이상의 길이도 할당 가능하다. 본 실시예에서는 단지 설명을 위해 2 octet으로 나타냈으며, 실제 발명 적용시는 필요에 따라 더 짧거나 길게 할 수 있다.

(A)기존 802.11 규격의 TIE 사용

기존 802.11 규격에 있는 Timeout Interval element (TIE)를 다음과 같이 확장하여 사용하는 예이다.. ProbeResponse deadline Interval을 위해 기존의 802.11 규격의 Timeout Interval element (TIE)의 Reserved 된 값 중 하나를 할당하여 사용한다. (표 4)은 5번을 Timeout Interval을 위해 할당한 예이며, 5번이 아닌 다른 Timeout Interval Type 값을 할당해도 된다.

Probe Response listen start interval을 사용할 경우, 이를 위해 6번을 할당할 수 있다. 6번이 아닌 다른 Timeout Interval Type 값을 할당해도 된다. 또한 단위도 TU가 아닌 다른 단위를 선택해도 된다.

(노란색으로 표시한 부분이 본 발명에서 새로 추가한 부분)

(표 4) Timeout Interval element (TIE) 확장하여 사용하는 예

이 방법은 새로운 element를 정의하지 않고 기존의 element를 활용한다는 장점이 있다.

이 방법을 사용할 경우, Probe Response listen start interval을 명시한다면 Probe Request에 Timeout Interval을 나타내는 TIE, Probe Response listen start interval을 나타내는 TIE (2개의 TIE)가 추가된다.

Probe Response listen start interval을 사용하지 않는다면 Probe Response deadline interval을 포함하는 TIE만 Probe Request에 포함된다.

(B) 새로운 element로 정의하여 사용하는 예

다음과 같이 Probe Response deadline interval element를 새롭게 정의하여 사용할 수도 있다.

(그림 5-1-a) Probe Response deadline interval element의 예

Probe Response deadline Interval Value 는 Probe Response deadline Interval을 Time units (TUs)로 나타내거나, 혹은 다른 단위를 사용해도 된다.

Probe Response listen start interval을 명시하기 위해서는, 다음과 같이 Probe Response listen start interval element를 새롭게 정의해 사용할 수 있다.

(그림 5-1-b) Probe Response listen start interval element의 예

Probe Response listen start interval Value 는 Probe Response listen start interval을 Time units (TUs)로 나타내거나, 혹은 다른 단위를 사용해도 된다. ProbeResponse listen start interval의 길이는 사용하는 시간 단위 혹은 허용 가능한 최대 시간에 따라 1 octet 혹은 2 octet 혹은 그 이상의 길이도 할당 가능하다. 본 실시예에서는 단지 설명을 위해 2 octet으로 나타냈으며, 실제 발명 적용시는 필요에 따라 더 짧거나 길게 할 수 있다.

이 방법을 사용할 경우, Probe Response listen start interval을 명시한다면, Probe Request에 Probe Response deadline interval element, Probe Response listen start interval element 가 추가된다.

Probe Response listen start interval을 사용하지 않는다면 Probe Response deadline interval element만 Probe Request에 포함된다.

(C) 새로운 element 정의 - Timeout interval, Probe Response listen start Interval을 하나의 element로 표시

다음과 같이 Probe Response deadline interval, Probe Response listen start Interval을 하나의 element로 나타내도록 element를 새롭게 정의하여 사용할 수 있다.

(그림 5-1-c) Probe Response deadline interval element의 예

Length 는 가변이다. Probe Response deadline Interval Value 는 Probe Response deadline Interval을 Time units (TUs)로 나타내거나, 혹은 다른 단위를 사용해도 된다.

Probe Response listen start interval을 사용하지 않는다면 Probe Response listen start interval value는 생략되며, 이때 Length는 2로 설정된다..

Probe Response deadline Interval, Probe Response listen start interval의 순서는 바뀔수 있다. 위의 element는 Probe Request에 포함되어 전송된다.

위와 같이 ProbeResponse deadline interval 혹은 Probe Response listen start Interval을 Information element 형태를 사용하는 것은 단지 하나의 예이며, 일반 sub field 형태로 나타내어 Probe Request 에 포함시키거나, 다른 제 3의 Information element 나 field에 sub field 형태로 포함시킨 후 해당 Information element 나 field가 Probe Request frame에 포함되도록 하는 방법도 가능하다. (위의 Information element에서 Probe Response deadline Interval Value sub field, 혹은 Probe Response listen start Interval Value 를 Probe Response frame에 포함되도록 하면 됨)

즉, 어떤 방법으로든 ProbeResponse deadline interval 혹은 Probe Response listen start Interval 값을 Probe Request frame에 포함시키기만 하면 된다.

이렇게 ProbeResponse deadline interval까지 전달할 수 있도록 확장된 Timeout Interval 정보를 Probe Request frame에 추가한다.

6. 개선된 Active scanning 처리 절차

6-1. 스캐닝 요청 STA에서의 Active scanning 처리 절차

도 6은 액티브 스캐닝을 요청하는 STA에서의 Active scanning 절차를 나타낸 것이다.

이 처리 절차는 앞에서 설명한 active scanning 개선 방법을 조합한 처리 절차이며, 도 6은 이들 처리 방법의 가능한 조합 중 한가지를 예시로 나타낸 것이다. 앞에서 기술한 방법을 이와 다른 방법으로 조합하는 것도 가능하다.

(1) 1)STA은 BSSID, SSID, SSID List, HESSID, MeshID 등을 Probe Request Frame에 포함하여 선택할 AP (혹은 Mesh STA 혹은 STA in IBSS)의 범위를 정하며, 이에 추가적으로 Inclusion List 혹은 Exclusion List를 Probe Request Frame에 포함시켜 보다 세밀하게 선택 대상을 한정시킨다.

2) 또한 RSN IE 혹은 CapabilityFilterInfo element를 Probe Request Frame에 포함시켜 자신의 보안 capability를 비롯한 capability 및 자신의 preference가 알려질 수 있도록 한다. (이외의 STA capability는 기존의 Probe request frame에 이미 포함되어 있음)

3) Probe Response에 대한 Timeout Interval (ProbeResponse deadline Interval)을 결정하여 이 정보를 담은 TIE (Timeout Interval Element) 혹은 Probe Response deadline interval element 를 Probe Request frame에 포함시킨다.

(2) 위에서 생성한 Probe Request frame을 선택한 채널에 브로드캐스트로 전송한다.

(3) 대상 AP (혹은 Mesh STA 혹은 STA in IBSS)로부터 Probe Response를 수신하며, Probe Response 수신에 성공하면 이를 보낸 AP (혹은 Mesh STA 혹은 STA in IBSS)에 ack을 전송한다. (만약 MinChannelTime 동안 선택한 채널이 inactivity 상태이면 7번 스텝으로 가서 다음 스캔할 채널을 선택한다.)

(4) MaxChannelTime이 경과했는지 확인한다. 만약 경과하지 않았으면 3번 스텝으로 가서 Probe Response 수신 및 ack 응답 과정을 반복한다. 만약 MaxChannelTime이 경과했다면, 해당 채널에 대한 스캔을 중단한다.

(5) 중간 스캔 결과 생성 옵션이 설정되었다면, 이 시점까지의 중간 스캔 결과를 생성한다.

(6) 만약 Scan Abort 요청이 들어온다면, 9번 스텝으로 가서 abort 시점까지의 스캔된 AP에 대한 최종 리포트를 생성한다. (Scan Abort 요청은 이 시점 뿐만 아니라 스캐닝 과정중 어느 시점에서나 들어올 수 있고, 이 경우는 항상 그 시점까지의 스캔 결과를 최종 리포트로 생성하여 반환한다.)

(7) Scan이 abort 되지 않았다면, Probe Response에서 수신된 AP channel과 관련된 정보를 확인한다. 만약 AP channel Report 등이 Probe Response frame에 포함되어 수신되었다면, 포함된 AP가 존재하는 channel 정보를 보고, 이중 아직 스캔하지 않은 채널을 다음 스캔할 채널로 선택한다. 혹은 2.4 GHz의 경우 1, 6, 11채널을 우선적으로 선택할 수 있으며, Measurement Pilot을 수신받은 경우 여기에 포함된 채널 정보, AP 정보 등을 활용한다. 만약 이런 정보가 없다면, 순차적으로 다음 채널을 선택한다.

(8) 만약 스캔할 다음 채널이 존재한다면, 2번 스텝으로 가서 다음 채널에 Probe Request를 전송한다.

(9) 만약 스캔할 다음 채널이 없다면 모든 채널에 대한 스캔이 끝난 것이므로, 그때까지 스캔된 AP에 대한 최종 리포트를 생성한다.

(10) 스캐닝을 종료하고 최종 스캐닝 결과 리포트를 반환한다.

6-2. Active Scanning 처리 절차 - 응답 AP (혹은 Mesh STA 혹은 STA in iBSS)

도 7은 대상 AP (혹은 Mesh STA 혹은 STA in IBSS)에서의 Active scanning 처리 절차를 나타낸 것이다. 이 처리 절차는 앞에서 설명한 active scanning 개선 방법을 조합한 처리 절차이며, 도 7은 이들 처리 방법의 가능한 조합 중 한 가지를 예시로 나타낸 것이다. 앞에서 기술한 방법을 이와 다른 방법으로 조합하는 것도 가능하다

(1) AP (혹은 Mesh STA 혹은 STA in IBSS)가 Probe Request를 수신한다.

(2) Probe Request frame의 SSID, BSSID, Exclusion List, Inclusion List 등을 확인한다.

(3) 자신이 Probe Response frame을 응답해야 하는지 판단한다. 만약 자신이 Probe Response 응답 대상이 아니라면, 수신 Probe Request 처리를 종료한다.

(4) 자신이 Probe Response frame 응답 대상이라면, 그 다음은 Probe Request의 RSN IE 혹은 CapabilityFilterInfo element, HT Capabilities, VHT Capabilities, Extended Capabilities 등 Probe Request frame을 전송한 STA의 capability 및 Preference를 확인한다. 또한 자신의 현재 Load 상태 등 자신의 상태도 확인한다.

(5) 요청 STA의 capability, preference (선호도 혹은 요구사항)를 확인하여 자신이 추후 association 요청이 들어올 경우 association 할 것인지를 판단한다. 또한 자신의 현재 Load 상태 등 자신의 상태를 고려하여 해당 STA을 자신이 수용할 능력이 되는지도 판단한다. Association을 거부할 예정이라면, (a) 아무 응답도 보내지 않거나 (b) Frame Body가 없는 Null Probe Response를 전송하여 STA에게 거부 사실을 알리거나 (c) Reason code가 포함된 Null Probe Response를 전송하여 STA에게 거부 이유에 대한 정까지 알릴 수 있다.(a) (b) (c) 중 한가지를 수행하고 Probe Request 처리를 종료한다.

(6) 만약 해당 STA이 association 가능하다고 판단되면, Probe Request frame의 Timeout Interval (ProbeResponse deadline Interval)을 보고 Probe Request를 받은 시점부터 현 시점까지 timeout interval이 경과했는지 확인한다. 만약 경과했으면 Probe Response frame을 전송하지 않고 종료한다.

(7) 만약 timeout interval을 경과하지 않았으면 Probe Response frame을 전송한다.

(8) Probe Response Frame에 대한 ack이 수신되느지를 확인하여 수신되었으면 Probe Response 전송에 성공한 것이므로 종료한다. 만약 ack을 수신하지 못했으면 재전소을 해야 하므로 6번 스텝으로 간다. 6번 스텝에서 재전송 시점에서 Probe Request timeout interval이 경과되었는지 확인하여 경과되었으면 그냥 종료, 아니면 재전송 시도를 한다.

(9) Probe Response 처리를 종료한다.

7. 기타

본 발명에서 추가된 사항들은 legacy STA들과 동작시 compatibility 문제를 일으키지 않도록 고려되었다. 본 발명에서 추가된 element는 모두 Information Element로 정의되어 기존의 무선랜 STA은 이를 무시하기 때문에 기존의 STA이 섞여 있어도 아무 문제없이 동작 가능하다. 즉, 기존의 STA은 위의 본 발명에서 추가된 information element들을 무시하기 때문에 기존의 802.11 active scanning 절차에 따라 동작하게 된다.

Claims

무선 랜을 위한 효율적인 스캐닝 방법.