▣ 블루투스(Bluetooth) 프로토콜 스택과 프로파일(Profile) (2)

이한욱 (BLUETOOTH Lab. 팀장)

    본고에서는 지난 1부에 이어 HCI 이상의 상위 계층 프로토콜에 대한 내용에 대해 살펴보겠다.

  일반적으로 HCI 이상의 상위 계층 프로토콜들은 PC와 같은 호스트 상에 구현된다. 이러한 프로토콜들은

  자체적을 수행하는 태스크(Task) 외에도 상하위 계층에 이웃하는 프로토콜과의 인터페이스가 중요하다.

   먼저 이러한 레이어들간의 통신 모델에 대해 간단히 살펴본 후 각 레이어들에 대해 알아보기로 한다.

   그리고 마지막으로 블루투스의 프로파일(Profile)에 대한 내용을 다루고자 한다.

   프로토콜 모델

    블루투스 프로토콜은 OSI 참조 모델(OSI Reference Model)과 같이 계층화된 구조를 지니고 있다.

  또 각각의 프로토콜은 Peer-to-Peer 방식으로 원격 프로토콜과 통신이 이루어진다. 또 프로토콜 스택 내의

<그림1> 계층화된 프로토콜에서의 프리미티브 (발췌:BlueStack User Manual, Mezoe, 2001)

  이웃하는 계층의 프로토콜 사이에서는 서비스 프리미티브(Service Primitive)라는 패킷을 이용하여 프로토콜

   사이에 컨트롤 정보(PCI)나 데이터를 교환한다. 이러한 프리미티브는 `Request', `Indication', `Response',

   `Confirm'의 4종류로 나누어진다. `Request'는 (N+1)계층에서 (N)계층으

  로 전달되는 프리미티브로 서비스를 요청하고 그 서비스에 필요한 데이터나 인자들을 전달할 때 사용된다.

   `Request' 프리미티브가 전달되면 통신 링크를 통해 통신이 이루어지고 원격 디바이스의 동등 프로토콜

  (Peer Protocol)인 (N)계층에서는 요청된 서비스에 대한 정보나 동작 등을 `Indication' 프리미티브를

   통해 (N+1)계층에게 알린다. 이후 (N+1)계층에서는 `Indication'으로 전달된 정보나 동작 등을 수행한

   결과를 (N)계층에게 `Response' 프리미티브를 이용하여 전달한다. 그리고 이러한 정보는 통신 링크를

   통해 서비스 요청이 시작된 처음의 디바이스 (N)계층 프로토콜로 전달되어 여기서 다시 (N+1) 계층으로

   `Confirm' 프리미티브를 이용하여 결과를 통보한다. 실제적으로 블루투스 프로토콜 스택의

<그림2> 계층화된 프로토콜의 메시지 구조 (발췌:BlueStack User Manual, Mezoe, 2001)

   L2CAP프로토콜의 경우 상위 계층(RFCOMM, SDP, TCS)과는 `L2CA_Request',

  `L2CA_Indication', `L2CA_Response', `L2CA_Confirm'의 프리미티브를 이용하며, 하위 계층(HCI,

   `LP_Request', `LP_Indication', `LP_Response', `LP_Confirm'의 프리미티브를 이

  용하여 커넥션(Connection)이나 디스커넥션(Disconnection) 등의 동작을 수행한다. 그러나 항상 이

  4가지의 프리미티브가 모두 사용되는 것은 아니고, 서비스에 따라 4개가 모두 사용되지 않는 경우도

  있다. HCI 이상의 프로토콜 계층에서는 대부분 이상과 같은 서비스 프리미티브 모델로 구현이 된다.

  이제 각각의 프로토콜에 대해서 알아보기로 하겠다.

   호스트 컨트롤러 인터페이스(Host Controller Interface:HCI)

    호스트 컨트롤러 인터페이스(이하 HCI)는 호스트 컨트롤러에 포함된 베이스밴드나 링크 매니져, 그

  리고 하드웨어 등을 접근하고 제어하기 위한 표준화 된 인터페이스를 의미한다. 만약 이렇게 표준화

<그림3> HCI와 하위 계층 프로토콜의 구조

  된 인터페이스가 없다면 베이스밴드 프로세서나 블루투스 칩셋 등의 하드웨어 벤더에 따라 컨트롤 레

  지스터(Register)나 하위 계층 프로토콜의 인터페이스 방법이 달라질 것이다. 따라서 하드웨어에 따

  라 어플리케이션을 따로 제작해야하는 번거로움이 생기게 된다. 반면 HCI는 블루투스 SIG에서 규정한

  표준화 된 인터페이스이므로 개발자는 호스트 컨트롤러의 하드웨어적 사양에 전혀 구애받지 않을 수

  있다는 장점이 있다. 이외에도 개발자는 HCI를 통해 호스트 컨트롤러에 내장된 베이스밴드나 링크 매

  니져 등의 하위 계층 프로토콜에 비교적 쉽게 접근할 수 있으므로 개발자가 별도로 하위 계층 프로토

  콜을 개발해야 하는 부담이 덜어지게 된다.

    HCI는 호스트와 호스트 컨트롤러 사이에 연결된 물리적 버스(Physical Bus)를 통해 통신하기 위한

  인터페이스이다. 일반적으로 이 물리적 버스는 UART, USB, PC 카드 등이 사용되고, 블루투스 스펙에

  는 USB(H2), RS232(H3), UART(H4)의 각각에 대한 자세한 내용이 실려있다. 이러한 물리적 버스를

  통해 교환되는 HCI 패킷은 HCI Command, HCI Event, HCI ACL Data, HCI SCO Data의 4종류이다.

  HCI Command는 호스트에서 호스트 컨트롤러에게 특정 작업을 수행하도록 지시하거나 특정 정보를

  요청하기 위한 패킷이다. 모든 HCI Command에 대해서는 HCI Event가 존재하는데, 이것은 호스트가

  HCI Command를 통해 지시한 작업에 대한 결과나 호스트가 요청한 정보를 호스트 컨트롤러가 호스

  트에게 통보하는 패킷이다. 예를 들어 호스트가 현재 연결된 호스트 컨트롤러의 주소를 얻기 위해

<그림4> HCI 패킷의 구조

  `Read_BD_ADDR'이라는 HCI Command 패킷을 호스트 컨트롤러로 보내면, 호스트 컨트롤러에서는

  디바이스의 주소값을 포함된 HCI Event 패킷을 호스트로 보낸다. 이외에 HCI ACL Data 패킷과 HCI

  SCO Data 패킷은 ACL 링크나 SCO 링크가 설정된 후에 데이터를 주고 받기 위한 패킷이다.

    HCI Command 패킷은 각 커맨드별로 고유한 OpCode를 지니고 있다. 이 OpCode는 OGF

  (OpCode Group Field)와 OCF(OpCode Command Field)로 구성되는데, OGF는 HCI Command를

  그 성격 및 역할에 따라 그룹으로 구분짓기 위한 코드이다. 즉 HCI Command가 링크 제어에 관련된

  것인지, 베이스밴드에 관련된 것인지, 호스트 컨트럴로의 정보를 얻어오는데 관련된 것인지에 따라

  HCI Command를 그룹화하여 각 그룹에 대해서 코드를 부여한 것이 OGF이다. 그리고 각 그룹에 포함

  된 각각의 HCI Command에 대해서는 고유한 OCF를 부여하였다. 이러한 OGF와 OCF를 조합을 하면

  HCI Command마다의 고유한 OpCode가 만들어진다. 각각의 HCI 커맨드와 이벤트에 대해서는 블루

  투스 스펙에 자세히 나와있으므로 이를 참조하기 바란다.

    HCI를 구현하게 되면 블루투스의 Inquiry, Paging, Connection 등의 링크 설정과 인증(Encryption)

  , 암호화(Authentication), 링크 키(Link Key) 등의 보안이나 Hold, Sniff, Park 등의 커넥션 상태 설정

  등 블루투스의 대부분의 동작을 실제로 실행시킬 수 있다. 따라서 블루투스 프로토콜 스택이나 호스트

  어플리케이션을 개발하려한다면 제일 먼저 구현해야할 가장 기본이 되는 프로토콜이 HCI이다. 이러한

  HCI 구현을 편리하게 하기 위한 소프트웨어 툴도 에릭슨(Ericsson) 등을 비롯한 관련 업체에서 판매

  하고 있기도 하다.

   Logical Link Control and Adaptation Protocol (L2CAP)

    L2CAP는 상위 계층 프로토콜과 HCI, 베이스밴드(Baseband) 등의 하위 프로토콜 사이에서 중재 및

  조정을 하는 역할을 한다. 논리 채널(Logical Channel)이란 L2CAP 상위의 계층 프로토콜이나 어플리

  케이션에서 전달된 데이터를 위해 설정된 채널을 말한다. 실제로 블루투스 프로토콜 스택을 보면

  L2CAP 위로 3개의 프로토콜(RFCOMM, TCS, SDP)이 존재한다. 결국 각각의 프로토콜로부터 데이터

  가 전달된다면 이를 중재하고, 각각의 데이터를 논리 채널별로 설정하고 관리하여 하위 계층 프로토콜

  로 전달할 필요가 있는데 바로 이것이 L2CAP의 역할이다. 그렇다고 L2CAP가 복잡하고 덩치가 큰 프

<그림5> 프로토콜 스택에서의 L2CAP의 형태

  로토콜은 아니다. L2CAP 프로토콜은 PDA, 휴대폰, 조이스틱 등의 리소스가 제한된 호스트에도 포팅

  될 수 있도록 간략함(Simplicity)과 낮은 오버헤드(Low Overhead)를 지녀야 한다.

    L2CAP 프로토콜의 대표적인 역할은 프로토콜 멀티플렉싱(Protocol Multiplexing)이다. 베이스밴드

  프로토콜은 SDP, RFCOMM, TCS 등의 상위 레이어에 대한 정보를 지니고 있지 않다. 그러므로

  L2CAP에서 각 상위 프로토콜에 대한 멀티플렉싱을 수행한다.

    또 프로토콜에 대한 분할(Segmentation) 및 재조합(Reassembly)도 L2CAP에서 이루어진다. 베이

  스밴드의 프로토콜은 MTU(Maximum Transfer Unit)와 관련되어 패킷의 길이가 제한되어 있다. 따라

  서 어플리케이션이나 상위 계층 프로토콜에서 전달된 패킷의 길이가 길 경우에는 베이스밴드 패킷의

  길이 제한에 맞게 분할(Segmentation)해야 한다. 반대로 여러개로 분할되어 수신된 베이스밴드의 패

  킷은 상위 계층 프로토콜이나 어플리케이션으로 전달하기 전에 재조합(Reassembly)을 해야한다. 이

  러한 패킷 관리가 모두 L2CAP에서 이루어진다. 이외에도 L2CAP에서는 QoS(Quality of Service)나

  피코넷 구성 시의 그룹화(Grouping)에 관련된 작업도 수행한다.

   Service Discovery Protocol (SDP)

    SDP는 연결된 블루투스 디바이스에서 어떠한 서비스가 가능하고, 그 가능한 서비스의 특징에 관한

  정보를 교환하기 위한 프로토콜이다. 즉 SDP를 통해 다양한 디지털 기기에 장착된 블루투스 디바이스

<그림6> Service Discovery 시나리오

  들이 LAN 억세스 포인트(LAN Access Point), 핸드폰, 팩스, 프린터 등의 서비스가 가능한지에 대한

  정보를 교환하는 것이다.

    SDP는 서버-클라이언트(Server-Client)의 구조를 지니고 있다. 서버 디바이스는 가능한 서비스의

  목록과 각 서비스에 대한 세부사항을 데이터 베이스로 지니고 있다. 클라이언트는 이 서버에 요청하여

  서비스에 관련된 정보를 얻을 수 있다.

   RFCOMM

    RFCOMM은 원래 GSM폰의 멀티플렉서(Multiplexer)를 위해 고안된 ETSI(European

  Telecommunications Standards Institute)의 TS 07.10을 기반으로 한 것으로 RS-232 9핀 시리얼

  포트를 에뮬레이션 하는 역할을 담당한다. 특히 현재 블루투스의 대표적인 어플리케이션인 무선 헤드

  셋이나 랜 억세스 포인트의 기반이 되는 시리얼 포트 프로파일(Profile)에 RFCOMM이 사용이 되므로

  블루투스 어플리케이션 개발을 위해서는 피해갈 수 없는 프로토콜이다.

<그림7> RFCOMM의 두가지 통신 모델

    RFCOMM은 보통 두가지 형태의 디바이스에 이용된다. 첫 번째 형태는 두 개의 디바이스가 모두 통

  신 상의 엔드 포인트(End Point)가 되어 두 디바이스 사이에 블루투스 링크로 직접 연결이 되는 경우

  로 이런 경우를 `Type1 Device'라 한다. 두 번째 형태는 하나의 디바이스는 엔드 포인트이나 나머지

  하나의 디바이스가 또 다른 네트워크의 일부인 경우이다. 이런 디바이스를 `Type2 Device'라고 하

  며 대표적인 경우가 모뎀(Modem)이다. 그렇다고 두 개의 디바이스 타입이 각각 다른 형태의 프로토

  콜을 사용하는 것은 아니며, RFCOMM 프로토콜 자체는 어떤 타입의 디바이스인지에 대한 정보를 지

  니고 있지 않다.

    RFCOMM은 스펙상으로 동시에 60개의 포트를 열 수 있는 다중 에뮬레이션(Multiple Emulation)을

  지원하며 각 포트는 DLCI(Data Link Connection Indentifier)라는 고유한 인자를 지니고 있다. 이러한

  다중 에뮬레이션은 두 개의 블루투스 디바이스 사이에서 다중 시리얼 포트를 에뮬레이션 할 수도 있지

  만, 여러개의 블루투스 디바이스와 다중 시리얼 포트 에뮬레이션을 하는 것도 가능하다.

   Telephony Control Protocol (TCS)

   TCS는 블루투스의 어플리케이션의 하나인 `3-in-1 Phone'을 구현하기 위해 필수적인 프로토콜로

  주로 전화 회선(PSTN)이나 내선(Intercom)을 인터페이스 하기 위한 콜 컨트롤(Call Control)을 담당

<그림8> TCS 프로토콜을 이용한 어플리케이션

  한다. 실제로 `Cordless Telephony Profile'과 `Intercom Profile'는 TCS 프로토콜을 기반으로 한 프

  로파일이다. 이외에도 TCS 프로토콜은 TCS가 지원되는 블루투스 디바이스들을 WUG(Wireless

  User Group)이라는 피코넷을 구성하여 관리한다.

    이외에도 L2CAP 상위에는 IrDA나 WAP과 인터페이스 할 수 있는 프로토콜이 구현될 수 있다. 이제

  SIG 규정한 블루투스 프로파일에 대해서 알아보기로 하겠다.

  에 대해서 살펴보기로 하겠다.

   블루투스 프로파일(Profile)

    이상과 2부에 걸쳐 살펴본 블루투스 프로토콜 스택을 살펴본 결과 결코 실제로 스택을 구현하는 것

  은 쉬운 일이 아니라는 생각을 갖게 한다. 그러면서 동시에 과연 이러한 스택을 구현을 했다고 할지라

  도 `어플리케이션에 어떻게 적용할 것인가'하는 문제도 결코 쉬운 일은 아닐 것이다.

    SIG에서는 코어(Core) 스펙과 더불어 프로파일(Profile) 스펙을 발표하여 현재 버전 1.1까지 나온 상

<그림9> 블루투스 프로파일(Profile)

  태이다. 이 `프로파일'이란 블루투스 어플리케이션을 구현할 때 특정 어플리케이션마다 사용해야할 프

  로토콜의 종류와 그 구조 및 사용 방법을 규정한 것이다. 결국 프로파일은 특정 블루투스 어플리케이

  션을 제작할 때 일종의 개발 레퍼런스 역할을 하게 되는 것이다. 또한 어플리케이션이 모두 프로파일

  에 따라 제작이 된다면 제작사에 상관없이 어플리케이션이 호환될 수 있다는 장점도 있다.

    2001년 2월에 발표된 1.1버전의 프로파일 스펙에는 모두 13개의 프로파일 규정되어 있다. <그림9>

  에서 보면 13개의 프로파일의 상관 관계를 쉽게 알 수 있다. 가장 기본이 되는 프로파일은 `Generic

  Access Profile(GAP)'로 블루투스 디바이스가 연결할 디바이스를 발견하고, 커넥션을 하여 링크를

  설정하는 방법과 이에 관련된 보안(Security)에 관한 내용이 규정되어 있다. 이 프로파일은 제목 그대

  로 모든 프로파일의 기초가 된다. 나머지 프로파일은 L2CAP 상위 계층이 어떤 프로토콜이냐에 따라

  크게 세가지로 나눌 수 있다. L2CAP 상위 계층으로 SDP를 사용하는 것은 `Service Discovery

  Application Profile'이고 TCS 바이너리를 사용하는 프로파일로는 `Cordless Telephony Profile'와

  `Intercom Profile'이 있다. 또 RFCOMM을 사용하는 프로파일은 `Serial Port Profile'이라 하여 1.1버

  전에서는 가장 큰 비중을 차지하고 있다. 현재 블루투스의 대표적인 어플리케이션인 무선 헤드셋이나

  랜 억세스 포인트가 모두 `Serial Port Profile'을 기초로 한다. 또한 블루투스의 대표적 어플리케이션

  시나리오 중에 하나인 `자동 동기화(Automatic Synchronization:이메일,주소록,스케쥴 등을 동기화

  된 상태에서 자동으로 교환하는 것)'를 위한 `Synchronization Profile' 역시 `Serial Port Profile'을 기

  반으로 두고 있다.

    이러한 프로파일은 블루투스의 스펙 상 중요한 요소로 블루투스 인증 시 고려 대상 중의 하나이다.

  만약 어느 업체에서 개발한 랜 억세스 포인트가 `LAN Access Profile'의 의무(Mandatory) 규정을 지

  키지 않았다면 결코 블루투스 인증을 받을 수 없다. 이렇게 하는 가장 큰 이유는 블루투스 어플리케이

  션을 표준화 하고 개발 업체와 무관하게 호환성을 유지하기 위함이다.

    현재 SIG에서는 새로운 버전의 프로파일 스펙을 발표할 예정에 있으면 현재의 13개 프로파일 외에

  상당수의 프로파일이 추가될 것으로 알려지고 있다. 앞으로 블루투스 관련 어플리케이션이 다양해질

  수록 이에 관련된 프로파일은 지속적으로 추가될 것이다. 또 현존하는 프로파일이 최상이라고 할 수는

  없으므로 이에 관련된 내용이 지속적으로 업데이트 될 것으로 예상된다. 만약 블루투스가 초기의 목표

  대로 5달러 이하의 솔루션이 되고, 수많은 가전 기기에 케이블을 대처하며 장착이 된다면 그때는 프로

  파일의 개수가 몇백개가 되는 날도 머지 않아 오지 않을까 하는 생각을 해본다.

< 자료 출처 : Bluetooth.lab >