woodyLee

Sticky client는 어떤 공간에, 여러개의 AP(ESS같은 Topology에서)가 배치되어 있을 때,클라이언트가 이동하면서 다른 AP로 roaming하지 않고 기존에 연결된 AP에 "sticky"하게 머물러있는 현상을 말한다.
클라이언트가 RSSI,SNR,오류,재전송 시도 같은 지표를 모니터링하면서 새 AP로 로밍하는 것이 이상적이지만, 아직 클라이언트의 로밍을 결정하는 기준은 표준화되지 않았으며, 이 결정인 클라이언트 장치 자체에 의해 결정된다. 즉, 일반적으로 로밍 결정은 AP나 컨트롤러가 결정하는 것이 아닌, 클라이언트가 결정한다. AP나 컨트롤러가 클라이언트의 로밍을 강제할 수 있는 옵션은 거의 없다.(SDN같은 경우를 제외하고)

사례를 통해 알아보자.

클라이언트가 (1) -> (2) -> (3) 의 방향으로 이동한다고 하자. 처음 클라이언트는 AP에 접속해 54mbps의 속도로 통신하고 있다. 이때 클라이언트가 (2)로 이동한다면, AP와 거리가 멀어짐으로써 신호 레벨, 프레임 오류 및 재전송이 증가하게 된다. 이상적으로는 클라이언트가 여기서 주변의 새 AP를 probe나 beacon을 통해 알아내고, 새 AP와 연결을 하는 것이지만, 대다수의 경우는 기존 연결에서 프레임 오류 및 재전송을 줄이기 위해 연결 속도를 줄이게 된다.(36mbps) 이러한 과정이 (3)까지 이어지고, 더 멀어짐에 따라 속도는 점점 떨어지게 된다.
결국 클라이언트가 신호 레벨이나 프레임 오류 및 재전송 수준이 허용수준을 넘어선 순간, 새로운 AP로 이동하게 된다. 이 시점은 클라이언트 하드웨어마다 다르며, 제조사쪽에서도 자주 발표하지 않는다. 더 심각한 문제는, 이런 현상이 클라이언트 하나뿐만 아니라 전체 네트워크에 악영향을 미친다는 점이다.

Wireless LAN은 contended medium을 사용하기 때문에, 어떤 클라이언트가 매체를 사용해 데이터를 보내고 있으면 다른 클라이언트는 대기해야 한다. 위 상황에서, 어떤 클라이언트의 연결 속도가 낮다면, 다른 클라이언트는 그 클라이언트가 데이터를 보낼 때까지 더 오래 기다려야한다.위의 그림에서, 클라이언트 1,2는 AP1가 가깝기 대문에 54mbps의 속도로 연결되어 있다. 반면 클라이언트3은 거리가 멀기 때문에 24mbps의 속도로 연결되어 있다. 이 때, 각 클라이언트가 10Mbyte의 속도로 데이터를 보내기를 원한다고 하자. 만일 클라이언트 3이 가장 먼저 데이터 전송을 시작한다면 클라이언트3의 연결속도는 24mbps이기때문에 클라이언트 1,2보다 2배 이상 느리게 데이터를 전송하게 되고, 클라이언트 1,2는 그만큼을 더 기다려야한다. 물론 클라이언트3가 더 멀어질수록 이러한 현상은 더 악화된다. Wi-Fi 네트워크의 성능은 airtime efficiency에 의해 결정된다. 무선 매체가 경합중이라면, 무선 클라이언트는 최대한 빨리 데이터를 전송하고, 대기하고 있는 다음 클라이언트가 데이터를 전송하는 것이 가장 이상적이다. 아주 소수의 sticky client라도 전체 무선 네트워크의 성능을 끌어내릴 수 있다.

왜 클라이언트는 빠르게 다른 AP로 roaming하지 않을까? 그 차이는 Enterprise WLAN과 일반 홈 WLAN의 차이에 있다. 일반적으로 집에는 단일 AP를 설치한다.우리는 신호의 감도가 조금 떨어져도 집 안에서 AP와 연결이 끊어지는 것을 원하지 않는다.따라서, 클라이언트의 하드웨어에는 한개의 AP와의 연결에 충실한 방법이 기본적으로 탑재되어 있다.

그렇다면, Enterprise WLAN에서는 어떻게 대처해야 할까?

여기에 3가지 방법이 있다.
1. 클라이언트가 더 나은 roaming을 할 수 있도록 정보를 주는 것.(friendly advice)
2. 클라이언트가 roaming을 하도록 연결을 일부러 악화시키는 것.
3. 클라이언트가 바로 roaming을 하도록 강제하는 것.

1. 이런 접근법을 위해 802.11k와  802.11v에서는 특정 기능을 제공하고 있다. 단, 클라이언트와 WLAN 장비가 이 기능을 지원해야 한다.

-  802.11k

802.11k는 Radio Resource Management 표준이다. 이는 무선 LAN 관리 및 유지를 용이하게 만든다.이를 통해 클라이언트는 AP에게, 해당 AP가 알고 있는 주변 AP의 목록을 요청할 수 있다.(이를 Neighbor report라고 한다.) 기존에는 클라이언트가 Acitve scanning,즉 probe를 통해 AP목록을 구성하거나,(이는 여러 채널을 옮겨다니면서 probe를 보내야 하므로 비용이 상대적으로 큰 작업이다.) AP가 발신하는 beacon으로 AP목록을 구성했다면(Passive scanning), Neighbor report를 통해 비슷한 정보를 얻을 수 있다. 이것은 훨씬 더 효율적이고 짧은 시간에 로밍 결정을 내릴 수 있게 해준다.추가적으로, 클라이언트의 소비전력을 감소시키고, WLAN의 airtime을 좀 더 효율적으로 사용할 수 있다.(스캐닝을 그만큼 덜하기 때문에)

- 802.11v

802.11v는 802.11 표준에 대한 Wireless Network Management 개정안이다. 이 표준을 통해 AP와 Client가 정보를 교환할 수 있다.(BSS Trasistion) 이 메커니즘을 통해 AP가 클라이언트에게 특정 AP로 로밍하도록 요청하거나, AP 집합 정보를 제공할 수 있다.

두가지 표준은 AP와 클라이언트 양쪽에서 지원해야 사용할 수 있는 표준이다. 하지만 802.11k와 v는 선택사항이므로, 지원되지 않는 환경일 가능성이 있다. 또한, 두 표준 모두 클라이언트에게 정보를 제공할뿐, 최종 결정은 여전히 클라이언트가 내린다.

2. 여기서는 클라이언트가 AP에서 멀어질수록 연결이 유지되는 것을 어렵게 만드는 기법을 사용한다.

AP와 클라이언트와의 거리가 멀어지면 신호 세기가 떨어지고, 에러율이 증가하기 때문에 이를 줄이기 위해서 전송 속도를 줄인다.이 과정이 반복되면서 결국 연결 속도가 매우 떨어지게 되고, 네트워크에 악영향을 끼치게 된다. 여기서는 클라이언트가 낮은 속도까지 AP에 달라붙지 못하도록 낮은 속도로 연결된 클라이언트에게 지원을 끊어버린다. 예를 들어, 2.4GHz의 주파수를 사용하는 AP에서, 24Mbps이하의 속도로 연결된 클라이언트는 데이터를 주고 받을 수 없다면, 훨씬 빨리 다른 AP로 로밍할 수 있게 된다. 일반적으로 AP에서 지원속도 - 예를 들어 2.4Ghz에서 54,48,36,24,18,12,9,6 mbps를 지원한다면, 54,48,36,24 mbps만 지원함으로써, 멀리 있는 클라이언트는 다른 AP를 찾게 한다.

3. 이 방식은 2.와 달리, 바로 AP에서 클라이언트를 쫓아버린다.

- RSSI Threshold

클라이언트가 특정 RSSI 수준보다 낮다면, AP는 해당 클라이언트를 무시해버린다. 클라이언트는 결국 새로운 AP를 찾게 된다.이러한 방식은 간단하지만, 몇가지 허점이 있다.첫번째로, 노트북과 스마트폰은 다른 RSSI수준을 가진다. 스마트폰쪽이 더 낮은 RSSI 수준을 가지기 때문에, 어떤 RSSI기준은 노트북에서는 잘 작동할 수 있지만, 스마트폰은 더 적은 AP 목록 가지게된다. 두번째로, 이렇게 AP가 클라이언트를 무시하게되면, 클라이언트는 AP와의 통신을 재시도하려고 한다.

- RSSI Threshold with De-authentication

위의 방법은 클라이언트가 어떤 상황인지 파악하고 다음 action을 취하기까지 시간이 꽤 오래 걸릴 수 있다. 클라이언트가 자주 움직이는 경우, 이 문제는 더 심각해질 수 있다. 이 기법에서는, 명시적으로 RSSI Threshold 미만인 경우, de-authentication을 수행, 클라이언트가 해당 AP와 연결이 끊어졌음을 바로 알 수 있게 한다.

참조 :

http://wifinigel.blogspot.kr/2015/03/what-are-sticky-clients.html

https://blogs.cisco.com/wireless/why-the-802-11k-and-neighbor-report-are-important

https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide/Chapter-11.pdf

TSPEC(Traffic Specification)은 VoIP나 비디오 스트리밍같은 실시간 네트워크 환경에서 사용되는 QoS 기술이다.(802.11e 표준에서 지정됨)
QoS-capable 무선 클라이언트가 무선 AP를 통해서 traffic stream을 사용하고 있을 때, 트래픽 요구 사항(데이터 속도,패킷 크기, 스트림 개수)을 포함한 TSPEC을 AP로 전송할 수 있다.(이때 ADDTS(add traffic stream)을 사용함) AP는 해당 정보를 받고 클라이언트에게 High-priority 통신의 가능 여부를 알려준다. 이 연결을 통해 무선 링크의 충돌이나 혼잡을 방지하면서 좋은 통신 품질을 얻을 수 있다.

참고 :

http://what-when-how.com/deploying-and-troubleshooting-cisco-wireless-lan-controllers/qos-cisco-wireless-lan-controllers/

https://sbkb.cisco.com/CiscoSB/GetArticle.aspx?docid=babf0d2f50914354ac8ab379dceb58c3_Traffic_Specification__TSPEC__Access_Point__AP__Statistics_o.xml&pid=2&converted=0

https://mrncciew.com/2013/03/19/tspec/

http://www.pica8.com/document/v2.3/pdf/ovs-commands-reference.pdf

* ovs-vsctl -> bridge configuration

+

add-br [브릿지 이름]
: 브릿지 추가

show
: 추가한 장치들 보기

del-br [브릿지 이름]
: 브릿지 삭제

add-port [브릿지 이름] [NIC]
: 둘 연결

del-port [브릿지이름] [NIC]
:연결 끊기

list bridge    | more
     port
     interface
     controller
: OVS에서 추가한 장치들 목록과 상태

set-manager tcp:[서버ip]:[포트]
set-controller [브릿지 이름] tcp:[서버ip]:[포트]
(둘이 무슨 차이인지 모르겠음. 상단의 레퍼런스 사이트에서는 controller만 존재.)

: 브릿지에 컨트롤러 세팅. 포트는 컨트롤러 버전마다 다르다. (0.3.4 , 0.6.0 기준 6653.)

* ovs-appctl -> ovs daemon query

+
fdb/show [브릿지이름]
: MAC 주소 테이블

* ovs-ofctl -> openflow parameter query

show [브릿지 이름]
: 포트 정보

dump-flows [브릿지 이름]
: flow 보기

add-flows
: flow 추가

del-flows
: flow 제거