마이크로비젼-블루투스강좌

블루투스 강좌

▣ 블루투스 애플리케이션 개발 (2)

- PC 기반의 애플리케이션 제작 -

이한욱 (BLUETOOTH Lab. 팀장 )

자료제공 : 마이크로비젼 (www.microvision.com)

본고에서는 PC 기반의 블루투스 애플리케이션 제작에 관련된 내용을 다루어보기로 하겠다.

먼저 PC 기반 애플리케이션의 종류와 시스템 구조에 대해서 살펴보고, PC와 연결하여 동작시키기 위한

간단한 블루투스-PC 인터페이스 보드를 제작하기로 한다. 또 HCI (Host Controller Interface)

커맨드/이벤트를 통해 블루투스를 동작시켜보기로 하겠다.

ㆍPC 기반의 블루투스 애플리케이션의 구조

PC에 블루투스가 장착되면 다양한 애플리케이션 시나리오가 가능하다.

우선 PC와 연결되는 주변 기기들을 무선으로 연결할 수 있다. 즉 마우스, 키보드 등은 물론이고

MP3 플레이어, 디지털 카메라, PDA 등이 모두 블루투스를 기반으로 PC와 연결할 수 있다.

이것은 `케이블을 무선화'한다는 블루투스의 컨셉과도 부합되는 것이다.

물론 무선 랜(IEEE802.11b)과 유사한 인터넷 애플리케이션도 가능하다.

FTP나 인터넷 공유기와 같은 블루투스 애플리케이션도 이미 제품화되어 있다.

하는 툴은 매우 주목할 만하다.

이러한 PC 기반의 블루투스 애플리케이션의 구조는 그림1과 같이 나타낼 수 있다.

일반적으로 블루투스 시스템은 호스트 컨트롤러(Host Controller)와 호스트(Host)로 나누어진다.

호스트 컨트롤러는 블루투스 모듈에 해당하고, 호스트는 블루투스 모듈과 연결되는 디바이스를 의미한다.

임베디드 시스템의 마이크로프로세서나 PC가 이 호스트가 된다.

지난호에서도 언급했었지만 이러한 시스템 구조에서 중요한 것은 프로토콜 스택의 배분이다.

그림1에서 볼 수 있듯이 호스트컨트롤러 내에는 RF, 베이스밴드, 링크 매니져 부분만이 내장되어 있다.

따라서 그 상위 계층의 프로토콜(L2CAP, RFCOMM, TCS, SDP)은 개발자가 호스트에서 별도로

구현해야 한다. 즉 PC 기반의 블루투스 시스템의 경우에는 상위 계층의 프로토콜이 PC의 운영 체제에

맞는 소프트웨어 혹은 디바이스 드라이버 형태로 구현되어야 하는 것이다.

이러한 상위 계층 프로토콜의 구현이 블루투스 애플리케이션 개발에서 가장 어려운 요소가 되고 있다.

만약 상위 계층 프로토콜을 직접 구현한다고 하더라도, 그 작업은 시간과 비용을 상당히 필요로

하는 일이다. 또 직접 개발한 프로토콜이 블루투스 제품에 내장되기 위해서는 그 프로토콜에 대한

인증(Qualification) 테스트가 필수적인데, 이 인증 절차 역시 시간이나 비용면에서 결코 쉬운 일은 아니다.

따라서 대부분 상위 계층 프로토콜에 관련하여 스택 개발 업체들로부터 스택을 구매하는 것이 보통이다.

스택 개발 업체들은 인증 테스트를 통과한 스택을 공급해주는 것과 동시에 개발자가 원하는

애플리케이션과 그 환경에 맞는 기술 지원을 제공한다.

<그림1> PC 기반 블루투스 시스템의 구조

이렇게 전체의 프로토콜 스택이 PC와 블루투스 모듈로 나누어지게 되면 그 사이의 인터페이스가 필요하다.

그 인터페이스가 바로 HCI(Host Controller Interface)이다.

HCI는 블루투스 시스템에서 호스트와 호스트 컨트롤러 사이의 표준 인터페이스이다.

PC와 블루투스 모듈 사이는 UART, USB, PCMCIA 등의 링크로 연결되고, 그 링크를 통해 HCI 패킷이

교환된다. 이 HCI는 Bluetooth SIG(Special Interest Group)에서 제정한 표준 인터페이스이므로 블루투스

모듈의 제조 회사에 상관없이 모두 호환된다.

또 애플리케이션 및 상위 계층 프로토콜에 관련된 개발자들은 제조사에 따른 각 하드웨어별 특성이나

그 내부의 구조를 파악하지 않더라도 HCI를 통해 하위 계층 프로토콜(베이스밴드, 링크 매니져)에

비교적 쉽게 접근할 수 있다. 따라서 개발 부담이 줄어들 뿐만 아니라 모든 하드웨어와 호환이 가능한

애플리케이션 및 상위 계층 프로토콜을 개발할 수 있다.

큰 이미지 보기

<그림 2> 블루투스-PC 인터페이스 보드 회로도

ㆍ블루투스-PC 인터페이스 보드 제작

이제 PC와 인터페이스를 위한 블루투스 보드를 제작하기로 하겠다.

블루투스 보드의 회로도는 그림2에 나타내었다. 그림2의 회로도는 블루투스 모듈이 PC와 시리얼 포트로

인터페이스를 하기 위한 보드이며, 크게 전원부, 블루투스 모듈, RS232 인터페이스의 세 부분으로

나눌 수 있다. 그림2의 회로도는 비교적 간단한 편인데, 그것은 블루투스 칩셋과 그에 관련된 주변

회로들이 모두 블루투스 모듈 내에 포함되어 있기 때문이다.
블루투스 모듈이란 블루투스 RF 칩 및 IF, 베이스밴드 프로세서, 외부 플래쉬, 기타 주변 회로들이 포함된

소형 PCB 보드를 의미한다. 따라서 개발자들은 블루투스 모듈을 사용할 경우 그림2와 같이 단순한 회로를

구성하는 것이 가능하다. 물론 블루투스 RF와 베이스밴드 칩셋을 구입해서 직접 블루투스 모듈을

구성하는 것도 가능하다. 그러나 2.4GHz RF 회로를 다루는 것이므로, 관련된 여러가지 인자들을 고려하여

세심하게 설계하지 않으면 RF 성능이 잘 나오지 못하게 된다. 또 블루투스 모듈 역시 RF 테스트를 비롯한

인증 테스트를 통과해야 한다.

제조사	모듈명	사용 칩셋 제조사	홈페이지
CSR	BC01MOD	CSR	www.csr.com
Ericsson	ROK 101 007/008	Ericsson	www.ericsson.com
ALPS	UGXZ Series	CSR	www.alps.co.jp
Taiyo Yuden	EYSF Series	Silicon Wave	www.yuden.co.jp
UNIWILL	BTM Series	CSR, Zeevo, Broadcom	www.uniwill.com.tw
Sharp	DC2D1BZ Series	CSR	www. sharp-world.com
Mitsumi	WML Series	CSR	www.mitsumi.co.jp/english/
Murata	LMBTB Series	CSR	www.murata.com
Windigo Systems	BTM Series	CSR, Broadcom	www.windigosys.com
BlueWINC	BW-BTM 01	CSR	www.bluewinc.com
삼성전기	BlueSEM	CSR	www.sem.samsung.com
LG 이노텍	LBMx-2001	CSR	www.lginnotek.com
제노컴	BlueLink Series	CSR	www.zenocom.co.kr
휴네텍	HBM Series	CSR	www.hunetec.com

<표 1> 인증 테스트를 통과한 모듈을 생산하는 국내외 모듈 벤더 및 모듈명

그림2의 회로도에는 CSR의 BlueCore2 모듈을 사용하였다.

그러나 모듈 벤더가 다르더라도 그 모듈의 핀 구성은 그림2와 비슷하다.

더구나 CSR의 BlueCore 칩셋을 이용한 모듈의 경우에는 그림2의 모듈과 핀 배치만 차이가 날 뿐이다.

(심지어는 핀 배치마저 동일한 모듈도 있다.) 현재 전세계 블루투스 칩셋 시장의 반 이상은 CSR 제품이

사용되고 있다. 따라서 CSR 칩셋을 이용한 모듈도 다수의 벤더에서 생산되고 있다.

표1에는 인증 테스트를 통과한 모듈을 생산하는 국내외 모듈 벤더를 정리하였다.

그림2의 회로도의 좌측 상단부는 레귤레이터를 사용한 전원 회로로 3.3V를 회로에 공급한다.

또 오른쪽 상단부는 Max3225를 이용하여 PC와 시리얼 포트 인터페이스를 구현한 부분이다.

그림2의 회로도에서 보는 바와 같이 블루투스 모듈은 PC와 UART 인터페이스(TXD, RXD, RTS)로 통신을

한다. 또 좌측에 모듈과 연결된 두 개의 LED(D2, D3)는 모듈의 상태를 모니터링 하기 위한 것이며,

`Discoverable', `Inquiry', `Connection' 등의 동작 상태를 이 두 개의 LED를 통해 알 수 있다.

그림2의 회로도와 같이 하드웨어를 구성하면 블루투스-PC 인터페이스 보드는 완성이 된 것이다.

이제 직접 제작한 보드를 동작시키기 전에 동작을 위해 필요한 HCI에 대해 먼저 알아보도록 하자.

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

앞에서 제작한 블루투스-PC 인터페이스 보드를 직접 동작해보기 위해서는 HCI 인터페이스를

구현하여야 한다. 앞에서도 언급했듯이 HCI 인터페이스는 블루투스 시스템에서 호스트와 호스트컨트롤러

사이의 통신을 위해 SIG에서 규정한 표준 인터페이스이다. HCI 패킷은 USB, RS232, UART, PC Card 등의

인터페이스를 통해 PC와 교환된다. 또 패킷의 형태는 커맨드 패킷, 이벤트 패킷, 데이터 패킷으로

나눌 수 있다. 커맨드 패킷은 호스트(PC)에서 호스트 컨트롤러(블루투스 모듈)에게 특정 동작을

명령하기 위해 보내는 패킷이며, 이에 대한 결과가 이벤트 패킷을 통해 호스트 컨트롤러에서 호스트로

보내진다. 또 데이터 패킷은 하나 이상의 블루투스 디바이스와 링크(ACL 혹은 SCO)가 설정되었을 때,

그 디바이스간에 무선으로 데이터를 송수신할 때 사용되는 패킷이다.

따라서 블루투스를 동작시키기 위해서는 PC에서 적절한 HCI 커맨드 패킷을 송신해야 한다.

HCI 커맨드 패킷의 형태는 그림 3에 나타나 있다. 패킷의 앞부분에는 2바이트 길이의 OpCode라는 것이

있는데, 이 값은 커맨드마다 부여되는 고유한 값이다. 이 OpCode는 6비트의 OpCode Group Field (OGF)와

10비트의 OpCode Command Field (OCF)의 조합으로 구성된다. OGF는 커맨드의 그룹별로 부여되는 값이며,

OCF는 각 그룹 내에 존재하는 커맨드별로 부여되는 값이다. 현재의 v1.1 스펙에는 95개의 커맨드가 6개의

그룹으로 나누어져 있다. OpCode 다음에는 1바이트의 인자 길이 정보와 각 커맨드별 인자(Parameter)들이

포함된다. 각 커맨드별 OGF, OCF, 인자들에 대한 자세한 내용은 블루투스 코어 스펙의 Part H:1에 실려있다.

<그림 3> HCI Command Packet

<그림 4> HCI Event Packet

이제 직접 HCI 커맨드 코드를 만들어보기로 하자.

간단한 예로 `HCI_Reset' 커맨드의 코드를 만들어본다. `HCI_Reset'은 블루투스 모듈 및 내부에 포함된

하위 계층 프로토콜을 초기화시키기 위한 커맨드이다. `HCI_Reset'은 `HOST CONTROLLER & BASEBAND

COMMANDS'라는 커맨드 그룹에 포함되어 있으며, 이 그룹의 OGF는 0x03 (6bit), `HCI_Reset'의 OCF는

0x0003(10bit)이다. `HCI_Reset'의 OGF와 OCF가 조합되어 OpCode가 생성되는 과정은 그림 5에 도시하였다.

생성된 OpCode는 0x0c03이 된다. 또 `HCI_Reset' 커맨드는 인자를 지니지 않으므로 인자 길이는 0이 된다.

이상의 내용을 종합하여 그림3에 도시된 포맷에 맞는 커맨드 패킷을 만들면 `0x0c 0x03 0x00'의

3 바이트패킷이 얻어진다. 그런데 여기서 몇가지 주의할 점이 있다.

우선 블루투스는 리틀 엔디안(Little Endian) 방식이므로 하위 바이트가 먼저 전송된다.

따라서 OpCode 0x0c03의 전송 방식은 하위 바이트인 0x03이 먼저 전송되게 된다.

또 현재 제작한 보드는 PC와 UART(H4) 링크로 연결되어 있는데, UART의 경우에는 각 패킷의 종류마다

패킷 헤더에 패킷 인디케이터(Indicatior)를 붙여주어야 한다.

그림6을 보면 커맨드의 경우 패킷 인디케이터는 `0x01'이다. 이상을 종합하면 `HCI_Reset' 커맨드의 패킷은

`0x01 0x03 0x0c 0x00'으로 얻어진다. 나머지 커맨드에 대해서도 블루투스 코어 스펙의 Part H:1을 참조하여

독자가 직접 만들어보기 바란다.

이러한 HCI 커맨드 패킷을 PC에서 블루투스 모듈로 전송을 하면 각 커맨드에 대한 이벤트 패킷이

그림4의 형태로 블루투스 모듈에서 PC로 전송되게 된다.

<그림 5> `HCI_Reset'의 OpCode 생성 과정

<그림6> HCI Packet Indicators

ㆍ블루투스-PC 인터페이스 보드의 테스트

이제 앞에서 제작한 블루투스-PC 인터페이스 보드를 직접 테스트 해보기로 하겠다.

일단 동작을 위해서는 BTPacketTester라는 간단한 툴이 필요하다. 이 툴은 블루투스 랩(Bluetooth Lab.)

홈페이지(www.bluetoothlab.com)의 자료실에서 받을 수 있다. BTPacketTester는 블루투스 모듈로부터

송신되는 이벤트 혹은 데이터 패킷을 패킷 단위로 잘라서 그 코드를 보여주고, 또 커맨드 혹은 데이터

패킷을 헥사 코드 형태로 입력하여 블루투스 모듈로 전송할 수 있다.

<그림 7> BTPacket Tester의 화면

먼저 앞에서 제작한 보드를 PC의 시리얼 포트와 연결한다. 그리고 PC에서 BTPacketTester를 실행하면

그림7과 같은 화면이 띄어진다. 이후 보드가 연결된 포트의 이름(COM1,COM2 등)과 블루투스 모듈

내부의 보 레이트(Baud Rate)에 맞게 설정하여 `START' 버튼을 누른다. 이때 CSR 칩을 이용한 모듈의

경우에는 `04 0f 04 00 01 00 00'이라는 Command Status Event가 발생하게 되어 BTPacketTester의 창에

보여지게 된다. 만약 이러한 이벤트가 발생하지 않았을 경우에는 보드의 리셋 버튼을 누르면 발생하게 된다.

일단 이 이벤트가 발생하면 보드는 정상으로 동작하는 경우이다.

만약 리셋 버튼을 눌러도 위의 이벤트가 발생하지 않으면 앞에서 설명했던 `HCI_Reset' 커맨드를 보내본다.

화면 중앙의 에디 박스에 커서를 클릭하고 `01 03 0c 00'을 입력한다. BTPacketTester의 커맨드 입력은 헥사

코드로 이루어지므로 1바이트의 헥사코드가 입력될 때마다 자동으로 띄어쓰기가 된다.

이렇게 입력을 한 후 `Send' 버튼을 누른다. 모듈이 정상으로 동작한다면 `04 0e 04 01 03 0c 00'이라는

이벤트가 띄게 된다. 만약 이 이벤트 마저 발생하지 않는다면 보드는 정상으로 동작하지 않는 경우가 된다.

이러한 문제점의 원인은 일단 세 가지 정도로 추정할 수 있다. 첫 번째 모듈의 보레이트와

BTPacketTester의 보레이트가 맞는 않는 경우이다. 모듈의 보레이트를 정확히 모르는 경우라면

BTPacketTester의 보레이트를 9600부터 115200까지 바꾸어가며 위의 동작을 수행하여 이벤트가 발생하는지

확인한다. 두 번째는 CSR의 칩셋을 사용한 모듈의 경우 펌웨어의 설정이 HCI (H4)가 아니라 BCSP로 되어

있는 경우들이 있다. 이 경우에는 HCI (H4)로 바꾸어야 하는데, 그러기 위해서는 CSR에서 제공하는 `

PSTool'이 필요하다. 만약 이러한 툴이 없는 경우에는 모듈 벤더 및 구입처에 문의를 하여야 한다.

위의 경우가 모두 정상이라면 결국 제작한 보드를 디버깅하여야 한다.

<그림 8> HCI_Read_BD_ADDR의 Event Packet

보드가 정상으로 동작한다면 몇 개의 커맨드를 더 보내보기로 하겠다.

`HCI_Read_BD_ADDR'이라는 커맨드는 현재 호스트와 연결되어있는 블루투스 모듈의 주소(BD_ADDR)을

읽어오는 명령이다. BTPacketTester에서 `01 09 10 00'을 입력하면 그림8에서 보이는 것과 같은 이벤트가

발생할 것이다. 물론 마지막 6바이트는 그림8의 코드와 일치하지 않을 것이다.

그림8에서 보이는 코드의 마지막 6바이트는 현재 PC와 연결된 블루투스 모듈의 BD_ADDR 값이므로

이 부분은 독자마다 다르게 된다.

& 이 6바이트를 제외하고는 나머지 코드들은 모두 그림8과 일치하여야 한다. 그림8의 이벤트 코드들은

그림4에서 보여지는 이벤트 패킷 형태를 따르고 있는 것이다. 특히 `Status' 바이트가 중요한데,

만약 이 부분의 코드가 `0x00' 값이 아니라면 커맨드 처리가 정상적으로 이루어지지 못한 경우이다.

이외에 기본적인 커맨드로 `HCI_Read_Buffer_Size'가 있다. 이것은 현재 블루투스 모듈에서 처리 가능한

데이터 패킷 길이와 개수에 대한 정보를 얻어오는 명령으로 커맨드 코드는 `01 05 10 00'이다.

이에 대한 이벤트 처리는 그림8과 같은 형태로 블루투스 스펙을 참조하여 독자가 직접 해보기 바란다.

ㆍ 블루투스-PC 인터페이스 보드의 동작 (Inquiry, Connection, ACL 링크)

이제 두 개의 블루투스를 연결하여 무선으로 데이터를 전송해보기로 한다.

이렇게 하기 위해서는 두 개의 블루투스 디바이스가 필요하다.

그리고 이 중 하나는 `Discoverable Mode'로 설정이 되어 있어야 한다.

만약 `Discoverable Mode'로 설정할 수 있는 별도의 개발 킷이나 블루투스 디바이스가 존재한다면 그것을

사용하면 된다. 그러한 디바이스가 없는 독자라면 앞의 블루투스-PC 인터페이스 보드를 하나 더

제작하여야 한다. 이제 두 개의 블루투스-PC 인터페이스 보드가 완성되었고, 앞의 테스트들이 모두

완료되었다면 하나를 Discoverable Mode로 설정한다. Discoverable Mode에 대한 설정 시 필요한 커맨드와

그때 발생하는 이벤트는 방법은 표2에 정리하였다.

Command 명	Code 종류	Code (Hexadecimal)
HCI_Set_Event_Filter	Command	01 05 0c 03 02 00 02
HCI_Set_Event_Filter	Event	04 0e 04 01 05 0c 00
HCI_Write_Pagescan_Activity	Command	01 1c 0c 04 00 08 12 00
HCI_Write_Pagescan_Activity	Event	04 0e 04 01 1c 0c 00
HCI_Write_Inquiryscan_Activity	Command	01 1e 0c 04 00 08 12 00
HCI_Write_Inquiryscan_Activity	Event	04 0e 04 01 1e 0c 00
HCI_Write_Scan_Enable	Command	01 1a 0c 01 03
HCI_Write_Scan_Enable	Event	4 0e 04 01 1a 0c

<표 2> Discoverable 셋팅 시 필요한 커맨드와 이벤트

BTPacketTester를 이용하여 표2에 있는 커맨드를 하나씩 입력하고 그에 대한 이벤트가 성공적으로
발생하면 보드에서 블루투스 모듈의 PIO[0]와 연결된 LED(D3)가 깜빡일 것이다.
이 LED가 깜빡이면 `Discoverable Mode'로의 설정이 성공한 것이다.
이 `Discoverable Mode'는 `Inquiry Scan'과 `Page Scan'이 설정된 상태이다. 이 상태는 다른 디바이스가
자신을 찾아서 연결해 주기를 기다리는 상태이다. 이렇게 `Discoverable Mode'로 설정된 디바이스는 링크가 설정되어 피코넷이 구성되면 슬레이브(Slave)가 된다. 그리고 나머지 하나의 디바이스는 마스터(Master)가
된다.
이제 마스터 보드에서 커넥션을 해보도록 하자.
블루투스 피코넷이 설정되려면 우선 주위에 연결될 디바이스를 검색하여야 한다. 이 동작을 `Inquiry'라고
한다. `Inquiry'를 통해 마스터는 주위에 연결 가능한 디바이스들의 주소(BD_ADDR)와 클럭
오프셋(Offset)값을 얻어오게 된다. 이 클럭 오프셋은 마스터가 페이징(Paging) 과정에서 슬레이브
디바이스와 주파수 채널을 동기화시키기 위해 필요한 매우 중요한 인자이다.
이제 BTPacketTester에서 `01 01 04 05 33 8b 9e 0a 08'을 입력하여 보자. 그러면 블루투스-PC 인터페이스
보드에 PIO 포트와 연결된 LED가 켜지게 될 것이다. 이후 몇 개의 이벤트가 발생하게 되는데,
이중 `04 02'로 시작하는 것이 `Inquiry_Result' 이벤트이다. 만약 2개 이상의 블루투스 디바이스가
검색되었다면 `Inquiry_Result' 이벤트도 2개 이상 발생하게 된다.

<그림 9> Inquiry와 Connection 과정으로부터 ACL 패킷이 생성되는 과정

앞에서도 언급했지만 `Inquiry_Result' 이벤트에는 검색된 블루투스 디바이스의 주소(BD_ADDR)와 클럭
오프셋(Clock_Offset) 값이 포함되어 있다. 이 두 개의 인자는 커넥션 커맨드인 `HCI_Create_Connection'에 포함된다. 이 과정은 그림9에 나타나 있다.(물론 BD_ADDR과 Clock_Offset의 값은 독자마다 다를 것이다.) 이제
그림9와 같이 `HCI_Create_Connection' 커맨드를 만든 후에 BTPacketTester로 전송해보자. `HCI_Create_Connection'이 전송되면 호스트 컨트롤러는 원격 블루투스 디바이스와 페이징(Paging) 과정
으로 주파수 채널을 동기화한 후 피코넷을 구성하여 ACL 링크를 생성한다.
이 과정이 끝나면 호스트에게 `Connection_Complete'라는 이벤트를 전송하게 된다. 그림 9의 `Connection_Complete' 이벤트를 보면 좌측에서 4번째 바이트가 `0x00'으로 되어 있는데 이것은
`Status'를 나타낸다. 만약 `0x00'이 아니라면 에러가 발생한 것이다.

<그림 10> ACL Packet

`Connection_Complete' 이벤트에서 가장 중요한 인자는 커넥션 핸들(Connection Handle)이다.
그림9에서 보여지는 바와 같이 커넥션 핸들은 `Connection_Complete' 이벤트의 좌측에서 5번째와 6번째
바이트에 해당한다. 이 커넥션 핸들은 Data Packet을 만드는데 사용된다.
현재는 ACL 링크가 설정되어 있으므로, 그림9에서 보이는 바와 같이 ACL Packet을 구성할 수 있다.
ACL 패킷의 형태는 그림10에 나타나 있다. 그림10에 보이는 바와 같이 12비트의 커넥션 핸들에 PB Flag와 BC Flag를 추가해야 한다. 본고에서는 패킷 분할을 하지 않고, 브로드캐스팅(Broadcasting)을 사용하지 않으므로 0x2(4비트)가 된다.(PB Flag와 BC Flag의 자세한 내용은 코어 스펙을 참조하기 바란다.) 따라서 그림9와 같이 ACL 데이터 패킷이 만들어지게 된다.
이 데이터 패킷을 BTPacketTester로 보내면 다른쪽 블루투스 디바이스의 호스트에 패킷이 수신되게 된다. 이러한 방식으로 한쌍의 블루투스 디바이스가 무선으로 데이터를 교환할 수 있다.

이상과 같이 HCI를 이용하면 블루투스 디바이스 사이의 링크 설정과 데이터 교환이 가능하다.
이외에도 HCI 커맨드를 이용하여 인증(Authentication) 및 암호화(Encryption) 등의 다양한 링크 설정이
가능하고, 블루투스 디바이스에 대한 다양한 동작 명령을 수행하고 정보를 얻어올 수 있다.
본고에서 다루지 않은 HCI 커맨드/이벤트에 대해서는 독자가 스스로 코어 스펙을 보면서 동작시켜보기
바란다.

위와 같은 블루투스 동작은 매우 간단하기 때문에 `블루투스가 별 것 아닌 것'으로 생각될 수도
있을 것이다. 하지만 본고에서 언급한 HCI 커맨드/이벤트는 말 그대로 하나의 인터페이스일 뿐이다.
완전한 하나의 블루투스 애플리케이션을 완성하기 위해서는 HCI 위로 L2CAP, RFCOMM, SDP와 같은
상위 계층 프로토콜이 필요하다.(현재는 HCI로만 구현 가능한 프로파일은 없다.) 각 애플리케이션별로
구현되어야 할 상위 프로토콜은 프로파일 스펙에 명시되어 있다. 예를 들어 헤드셋(Headset)의 경우
L2CAP, SDP, RFCOMM 프로토콜이 필수적으로 구현되어야 한다. 그러나 HCI만으로 블루투스
디바이스의 대부분의 동작이 가능하고, 실제 제작한 하드웨어의 테스트도 수행할 수 있으므로 HCI는 블루투스 애플리케이션 제작 시 가장 기본이 되는 것이다.
다음호에서는 임베디드 시스템에서의 블루투스 애플리케이션 개발 및 상위 계층 프로토콜에 관련된
내용을 다루기로 하겠다.

ㆍ 필자 소개

이한욱 : 1975년 9월 16일생. 1999년 서울대 공대 기계항공공학부 졸업(학사).

2001년 동 대학원 기계항공공학부 졸업(석사).

2001년~현재 동대학원 기계항공공학부 박사과정.

블루투스 랩(Bluetooth Lab.) 사이트(www.bluetoothlab.com) 운영.