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

URL : http://www.microvision.co.kr/bluetooth/lecture/lecture_protocol_2.htm

본고에서는 지난 1부에 이어 HCI 이상의 상위 계층 프로토콜에 대한 내용에 대해 살펴보겠다.
일반적으로 HCI 이상의 상위 계층 프로토콜들은 PC와 같은 호스트 상에 구현된다. 이러한 프로토콜들은 자체적을 수행하는 태스크(Task) 외에도 상하위 계층에 이웃하는 프로토콜과의 인터페이스가 중요하다.
먼저 이러한 레이어들간의 통신 모델에 대해 간단히 살펴본 후 각 레이어들에 대해 알아보기로 한다. 그리고 마지막으로 블루투스의 프로파일(Profile)에 대한 내용을 다루고자 한다.


프로토콜 모델
블루투스 프로토콜은 OSI 참조 모델(OSI Reference Model)과 같이 계층화된 구조를 지니고 있다. 또 각각의 프로토콜은 Peer-to-Peer 방식으로 원격 프로토콜과 통신이 이루어진다. 또 프로토콜 스택 내의 이웃하는 계층의 프로토콜 사이에서는 서비스 프리미티브(Service Primitive)라는 패킷을 이용하여 프로토콜 사이에 컨트롤 정보(PCI)나 데이터를 교환한다. 이러한 프리미티브는 `Request', `Indication', `Response', `Confirm'의 4종류로 나누어진다.

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


`Request'는 (N+1)계층에서 (N)계층으로 전달되는 프리미티브로 서비스를 요청하고 그 서비스에 필요한 데이터나 인자들을 전달할 때 사용된다.
`Request' 프리미티브가 전달되면 통신 링크를 통해 통신이 이루어지고 원격 디바이스의 동등 프로토콜 (Peer Protocol)인 (N)계층에서는 요청된 서비스에 대한 정보나 동작 등을 `Indication' 프리미티브를 통해 (N+1)계층에게 알린다. 이후 (N+1)계층에서는 `Indication'으로 전달된 정보나 동작 등을 수행한 결과를 (N)계층에게 `Response' 프리미티브를 이용하여 전달한다. 그리고 이러한 정보는 통신 링크를 통해 서비스 요청이 시작된 처음의 디바이스 (N)계층 프로토콜로 전달되어 여기서 다시 (N+1) 계층으로 `Confirm' 프리미티브를 이용하여 결과를 통보한다. 실제적으로 블루투스 프로토콜 스택의 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개가 모두 사용되지 않는 경우도있다.

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


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

호스트 컨트롤러 인터페이스(이하 HCI)는 호스트 컨트롤러에 포함된 베이스밴드나 링크 매니져, 그리고 하드웨어 등을 접근하고 제어하기 위한 표준화 된 인터페이스를 의미한다. 만약 이렇게 표준화된 인터페이스가 없다면 베이스밴드 프로세서나 블루투스 칩셋 등의 하드웨어 벤더에 따라 컨트롤 레지스터(Register)나 하위 계층 프로토콜의 인터페이스 방법이 달라질 것이다. 따라서 하드웨어에 따라 어플리케이션을 따로 제작해야하는 번거로움이 생기게 된다. 반면 HCI는 블루투스 SIG에서 규정한 표준화 된 인터페이스이므로 개발자는 호스트 컨트롤러의 하드웨어적 사양에 전혀 구애받지 않을 수 있다는 장점이 있다. 이외에도 개발자는 HCI를 통해 호스트 컨트롤러에 내장된 베이스밴드나 링크 매니져 등의 하위 계층 프로토콜에 비교적 쉽게 접근할 수 있으므로 개발자가 별도로 하위 계층 프로토콜을 개발해야 하는 부담이 덜어지게 된다.

.....

Logical Link Control and Adaptation Protocol (L2CAP)
L2CAP는 상위 계층 프로토콜과 HCI, 베이스밴드(Baseband) 등의 하위 프로토콜 사이에서 중재 및 조정을 하는 역할을 한다. 논리 채널(Logical Channel)이란 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)에 관련된 작업도 수행한다.

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


Service Discovery Protocol (SDP)
SDP는 연결된 블루투스 디바이스에서 어떠한 서비스가 가능하고, 그 가능한 서비스의 특징에 관한정보를 교환하기 위한 프로토콜이다.

.....

SDP는 서버-클라이언트(Server-Client)의 구조를 지니고 있다. 서버 디바이스는 가능한 서비스의 목록과 각 서비스에 대한 세부사항을 데이터 베이스로 지니고 있다. 클라이언트는 이 서버에 요청하여 서비스에 관련된 정보를 얻을 수 있다.


RFCOMM
RFCOMM은 원래 GSM폰의 멀티플렉서(Multiplexer)를 위해 고안된 ETSI(European Telecommunications Standards Institute)의 TS 07.10을 기반으로 한 것으로 RS-232 9핀 시리얼 포트를 에뮬레이션 하는 역할을 담당한다. 특히 현재 블루투스의 대표적인 어플리케이션인 무선 헤드셋이나 랜 억세스 포인트의 기반이 되는 시리얼 포트 프로파일(Profile)에 RFCOMM이 사용이 되므로 블루투스 어플리케이션 개발을 위해서는 피해갈 수 없는 프로토콜이다.

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

FCOMM은 보통 두가지 형태의 디바이스에 이용된다. 첫 번째 형태는 두 개의 디바이스가 모두 통신 상의 엔드 포인트(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)을 담당한다. 실제로 `Cordless Telephony Profile'과 `Intercom Profile'는 TCS 프로토콜을 기반으로 한 프로파일이다. 이외에도 TCS 프로토콜은 TCS가 지원되는 블루투스 디바이스들을 WUG(Wireless User Group)이라는 피코넷을 구성하여 관리한다.

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

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


.....


블루투스 프로파일(Profile)


.....


이 `프로파일'이란 블루투스 어플리케이션을 구현할 때 특정 어플리케이션마다 사용해야할 프로토콜의 종류와 그 구조 및 사용 방법을 규정한 것이다. 결국 프로파일은 특정 블루투스 어플리케이션을 제작할 때 일종의 개발 레퍼런스 역할을 하게 되는 것이다. 또한 어플리케이션이 모두 프로파일에 따라 제작이 된다면 제작사에 상관없이 어플리케이션이 호환될 수 있다는 장점도 있다.

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

.....


<그림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'을 기반으로 두고 있다.

.....