 | |
 블루투스 강좌 | |
|
▣ 블루투스(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 이상의 프로토콜 계층에서는 대부분 이상과 같은 서비스 프리미티브 모델로 구현이 된다. | |
|
이제 각각의 프로토콜에 대해서 알아보기로 하겠다. | |
|
| |
|
| |
|
호스트 컨트롤러 인터페이스(이하 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) 등을 비롯한 관련 업체에서 판매 | |
|
하고 있기도 하다. | |
|
| |
|
| |
|
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)에 관련된 작업도 수행한다. | |
|
| |
|
| |
|
SDP는 연결된 블루투스 디바이스에서 어떠한 서비스가 가능하고, 그 가능한 서비스의 특징에 관한 | |
|
정보를 교환하기 위한 프로토콜이다. 즉 SDP를 통해 다양한 디지털 기기에 장착된 블루투스 디바이스 | |
|
| |
|
<그림6> Service Discovery 시나리오 | |
|
| |
|
들이 LAN 억세스 포인트(LAN Access Point), 핸드폰, 팩스, 프린터 등의 서비스가 가능한지에 대한 | |
|
정보를 교환하는 것이다. | |
|
SDP는 서버-클라이언트(Server-Client)의 구조를 지니고 있다. 서버 디바이스는 가능한 서비스의 | |
|
목록과 각 서비스에 대한 세부사항을 데이터 베이스로 지니고 있다. 클라이언트는 이 서버에 요청하여 | |
|
서비스에 관련된 정보를 얻을 수 있다. | |
|
| |
|
| |
|
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)라는 고유한 인자를 지니고 있다. 이러한 | |
|
다중 에뮬레이션은 두 개의 블루투스 디바이스 사이에서 다중 시리얼 포트를 에뮬레이션 할 수도 있지 | |
|
만, 여러개의 블루투스 디바이스와 다중 시리얼 포트 에뮬레이션을 하는 것도 가능하다. | |
|
| |
|
| |
|
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 규정한 블루투스 프로파일에 대해서 알아보기로 하겠다. | |
|
에 대해서 살펴보기로 하겠다. | |
|
| |
|
| |
|
이상과 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달러 이하의 솔루션이 되고, 수많은 가전 기기에 케이블을 대처하며 장착이 된다면 그때는 프로 | |
|
파일의 개수가 몇백개가 되는 날도 머지 않아 오지 않을까 하는 생각을 해본다. |
