BLE Beacon의 Connectable과 Non-Connectable 모드

오랜만에 블로그에 글을 올립니다. 아마도 8월달의 마지막 포스팅이 될 것 같네요.

비콘의 하드웨어에 대해서 관심 있으신 분들이나 직접 구매하여 비콘 설정에 대해 자세하게 확인하신 분들은 아마도 Connectable Mode와 Non-Connectable Mode에 대해서 들어보셨을거라 생각됩니다.  하지만 일반 App 개발자들은 이 두가지 모드에 대해서 아예 들어보지 못하셨거나 차이를 정확히 알지 못하신 분들이 대다수일 것입니다.
아마도 국내에서 판매하는 BLE Beacon의 대부분은 Connectable Mode만 지원하고 있기 때문일수도 있습니다.

우선 간단하게 Connectable Mode와 Non-Connectable Mode를 정의하자면 아래와 같습니다.

Connectable Beacon은 Peripheral Mode의 BLE 디바이스를 이야기하며 데이터를 송신할 뿐만 아니라 받을 수도 있습니다.  다시말하면,  스마트폰과 같은 Central 디바이스와 Scan_Request와 Scan-Response을 String Data로 주고 받을 수 있으며 이를 통해 OTA(Over the Air)로 Beacon 기기의 설정 값들을 변경할 수 있습니다.  즉 우리가 비콘의 ID, 송출 주기, Tx Power와 같은 설정값을 바꾸기 위해서는 비콘은 항상 Connectable Mode여야만 가능합니다.

그 와는 반대로 Non-Connectable Beacon은 Advertising Mode의 BLE 디바이스로 단순히 정의되어 있는 데이터를 송신하기만 하며 Advertising 데이터 전송 이후는 바로 Sleep 모드로 들어가고 다시 깨어나 송출하기 반복하기 때문에 전력을 최소한으로 사용할 수 있게 됩니다. 때문에 어떠한 Bluetooth 기기와도 Data를 주고 받으 수 없으며 UART, SPI, USB와 같은 물리적인 연결을 통해서만 가능합니다.  Non-Connectable Beacon의 최대 장점은 최소한의 전류 소모량을 통해 배터리 수명을 최대화 시키는 것입니다.

일반적인 Bluetooth 기기는 Central Mode 나 Peripheral Mode 혹은 두 가지 모두를 전부 지원하게 되며 Paring을 위해서 Peripheral만 지원되는 즉 다른 기기가 자신을 검색할 수 있는 기기일 경우 기기들은 모두 Connectable-Mode라고 보시면 됩니다. 하지만 비콘은 Paring이 아닌 이미 저장되어 있는 특정 Data Packet을 단 방향으로 Advertising 하는 기기이기 때문에 Non-Connectable Mode도 가능하게 됩니다.

iBeacon 발표 이후 초기에 출시된 비콘들은 대부분 Connectable Mode만을 지원하였고 실제 필드에서 몇 가지 문제점이 도출 되기도 하였습니다. 비콘의 신호를 검색하는 Central Mode의 기기들이 많아지게 되거나 동시에 여러개가 Scan을 위해 Scan_Request를 보내에 되면 Connectable Mode의 비콘들은 이에 대해 Response를 해야 하고 그에 따라 전류 소모가 많아지며 때에 따라서는 수신율도 떨어지게 됩니다.  또한 안드로이드 모델 및 버전별로 Connectable Mode와 Non-Connectable Mode의 비콘에 따라 스캔 시 Callback Event를 통한 수신 빈도도 달라지는 것이 확인 되기도 하였습니다.
이는 몇 개의 비콘을 스캔하여 서비스하는 것은 문제가 없지만 다수의 비콘을 지속적으로 스캔하는 서비스에서는 스마트 폰별로 서로 다른 수신율을 보일 수 있어 서비스의 퀄러티에 영향을 미칠 수 있다는 의미 입니다.

최근에 출시되는 해외의 비콘들은 대부분 두 가지 모두를 함께 사용할 수 있도록 합니다. 비콘의 설정 값들을 변경하기 위해서 Connectable Mode가 반드시 필요하지만 서비스를 위해 부착 또는 고정한 이후에는 Non-Connectable Mode가 전류소모 및 수신율에도 장점을 갖게 됩니다.  때문에 비콘은 두 가지 모드를 스위칭 하기 위해 몇 가지 방법을 사용하게 됩니다.
예를 들면, 전원 연결 이후 처음에는 Connectable Mode로 유지되다가 일정 시간(30초 or 1분) 이후 Non-Connectable Mode로 자동 전환되는 비콘이 있습니다.  혹은, 어떤 모델은 케이스를 분리하면 PCB 상에 작은 스위치가 있어 이를 눌러 Connectable 모드로 바꿔주어야 하기도 합니다.  이러한 비콘들은 설정값을 변경하려면 매번 배터리를 탈부착 시켜 재부팅을 해거나 케이스를 분리해야 하는 번거로움이 있습니다. 또한 배터리 교체가 불가능하거나 방수형 비콘으로 케이스 분리가 안되는 모델들은 적용이 불가능합니다.
그래서 비콘에 센서를 내장하여 외부의 물리적인 변경을 통해 Connectable Mode로의 전환을 하기도 합니다.   예를 들면 움직임 감지 센서를 통해 비콘을 두번 노크(Knock)를 하거나 흔들어서 외부 이벤트를 발생시키기도 하고 기울기 센서를 통해 비콘을 뒤집거나 새로로 굴리는 행위로 모드 전환을 하기도 합니다.
물론 센서가 이러한 이벤트를 감지하기 위해서 최소한의 전력소모가 발행하기도 함으로 어느 방법이 더 효율적인지는 제조사에서 판단하기에 따라 다를 것입니다.  기구 디자인 상으로 크게 문제가 되지 않는다면 외부에서 누를 수 있는 리셋 버튼 같은 것을 두는 것도 하나의 방법이겠죠.

앞에서도 이야기 했지만 이는 단지 비콘 디바이스의 전류 소모만을 고려하기 위한 Mode 변경의 문제가 아니라 실제 스마트 폰에서의 수신율도 달라질 수 있습니다. 비콘이 Connectable 모드로 동작될 때 수 많은 사람들이 주위에서 스마트폰으로 스캔을 하게 되면 비콘은 Scan_Request가 올 때마다 이에 대한 Scan_Response를 보내야 하기 때문에 실제 Advertising Packet과 Scan_Response를 동시에 보내야 하기 때문에 실제 모든 스캔 디바이스가 이를 받을 수 없는 경우가 생길 수도 있습니다.
또한 안드로이드에서 테스트 한 결과 서로다른 모델과 비콘의 모드에 따라 스캔 결과가 다르게 나온다는 실험 결과를 본 적이 있습니다.  제가 직접 테스트를 한 것은 아니지만 이 글에 따르면 Android 4.3이 탑재된 Nexus4 단말에서 Connectable 모드는 한 번의 스캔 사이클에서 한번의 Callback만 호출되는 반면 Non-Connectable 모드일 경우에는 여러번의 Callback을 받을 수 있다고 합니다.  이러한 Scan 결과는 폰의 모델이나 OS별로 상이하며 때문에 다양한 스캔 방법이 적용되어야 합니다.  Android 5.0이 탑재된 Nexus5에서 지원하는 Scanning 관련 API를 활용하면 동일한 비콘의 다른 Mode라 하더라도 동일하게 다수의 Callback을 받을 수 있습니다. 하지만 Nexus4에 Android 5.0을 업그레이드 하더라도 Connectable 모두에서는 한 사이클에서 한번의 Callback만 받을 수 있다고 하니 꼭 OS 버전의 문제만도 아닌 것 같습니다.
하지만, 아이폰의 경우  CBCentralManagerScanOptionAllowDuplicatesKey 라는 Flag를 스캔 함수에 전달하여 선택이 가능합니다.
이처럼 비콘을 이용하는 서비스를 개발하는 개발자의 경우 비콘의 모드에 따라 각 모델별 확인 및 테스트가 필요해 보입니다.


헬로팩토리 비콘 테스트랩에서는  40여종 이상의 다양한 비콘 제품들을 구비해서 직접 보거나 테스트 할 수 있는 공간을 마련해 놓았습니다.   제 개인적으로 시간을 할애해야 하기 때문에 한 번에 많은 분들을 응대할 수는 없지만 예약하시고 방문해 주시면 성심성의껏 대응해 드리도록 할 예정입니다.

Beacon(비콘)의 기능과 역할

다들 아시겠지만 Beacon의 기능은 상당히 간단하다.

자신의 고유 ID를 정해진 시간과 정해진 전파 세기로 지속적인 브로드캐스팅(Broadcasting)하는 기능으로 IoT(사물인터넷)기기의 대표 디바이스로 자리잡고 있다.  정보를 얻기 위해 NFC와 같은 5cm 이내 태깅을 해야 하는 불편함과 데이터를 주고 받기 위해 블루투스 페어링과 Zigbee 기기들이 갖는 통신방식에서의 거리 제한 (대략 10m 이내)을 단방향 브로드캐스팅으로 늘리면서 활용 범위가 넓어졌다.

iBeacon에서는 거리를 기반으로 한 3가지의 영역으로 구분하고 있다. 

• Immediate Zone (0-20 cm) : 아주 가까운 거리로 정확도가 높다.
• Near Zone (20 cm - 2 m) : 가까운 거리로 어느 정도 정확도를 갖는다.
• Far Zone (2 - 70 m) : 먼 거리로 정확도가 떨어진다.

위의 Zone 영역은  전파의 특성에 의해 구분되어졌다. 거리가 먼어질수록 전파 세기는 약해지면서 RSSI(received signal strength indicator)를 기반으로 계산되는 거리의 정확도가 떨어질 수 밖에 없다.

iOS에서 RSSI를 기반으로 거리를 계산하는 방법은 아래와 같다.  플랫폼에서 얻어지는 계산 방식과 동일하진 않지만 참고를 할 만하다.

protected static double calculateAccuracy(int txPower, double rssi) {
  if (rssi == 0) {
    return -1.0; // if we cannot determine accuracy, return -1.
  }

  double ratio = rssi*1.0/txPower;
  if (ratio < 1.0) {
    return Math.pow(ratio,10);
  }
  else {
    double accuracy =  (0.89976)*Math.pow(ratio,7.7095) + 0.111;    
    return accuracy;
  }
} 

(출처 : http://stackoverflow.com/questions/20416218/understanding-ibeacon-distancing)

이렇게 비콘과의 거리를 계산으로 블루투스 신호를 스캔하는 스마트폰과의 거리를 판단하여 Notification을 주거나 App 내에서 정보를 전달할 수 있게 된다.

또한 여러개의 비콘으로부터 신호를 받아 거리를 계산하고 이를 보정하여 건물내에서의 위치와 이를 기반으로 한 실내 내비게이션으로 활용도가 넓어지고 있다.

위는 경북대학병원에 설치된 비콘을 활용한 병원내 내비게이션 시연 영상이다.

이러한 위치 판단 기술은 쉬워 보이지만 실제로는 비콘이 설치된 환경, 이동 동선, 스마트폰 모델, 비콘 제품, 신호의 편차 등 다양한 변수에 의해 발생하는 거리 오차를 보정하고 정확도를 높이기 위한 기술과 경험이 필요하다. 또한 이동 구간의 path topology 혹은 스마트폰의 센서등을 활용하여 보정치를 구하기도 한다.  

또한 미국 스타트업인 비콘과의 계산을 매 위치마다 하는 것이 아닐 백터 지도 기술을 활용하고 스마트폰의 센서를 활용하여 정확도를 높히기도 했다.

이렇듯 신호를 송출하는 단순한 기능이지만 근거리 위치 판단을 기반으로 다양한 서비스에 적용이 가능하고 시장에서의 요구사항에 따라 다양한 기능과 센서들이 추가되고 있다.

온도, 가속센서와 같은 추가 센서 지원으로 Beacon과의 거리외에 추가적인 정보를 전달하고 동작 시간을 제어하기도 하고 전류소모를 줄이기 위해 다양한 배터리가 적용되거나 USB를 통한 전원 공급 타입도 제품으로 나와 있다.

지금까지 비콘을 활용하고 싶은 100여개가 넘는 다양한 분야의 업체들과 만나면서 요구사항과 적용 방법에 대해 논의해 보았을 때, 실제 현재의 비콘으로 바로 적용할 수 있는 부분도 있지만 현재 개발중이지만 아직은 출시되지 않은 스마트한 비콘과 그 분야만을 위한 특수한 형태 혹은 기능을 가진 비콘이 필요한 경우도 많았다. 

비콘 제조 업체가 이러한 시장의 요구사항을 반영한 차기 제품들이 개발되고 있으리라 믿고 비콘이 갖는 기본적인 기능과 접목시킬 수 있는 스마트한 비콘이 앞으로 IoT 시대를 여는 견인 역할을 할 수 있을 것으로 믿는다.