블루투스 구조

블루투스 강좌

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

이한욱 (BLUETOOTH Lab. 팀장)

프로토콜(Protocol)이란 디바이스간에 데이터를 송수신하기 위한 하나의 약속을 말한다. 이 프로토

콜은 하나의 통신 시스템의 성능을 결정하는 매우 핵심적인 것이다. 하지만 OSI 7 Layer 나 TCP/IP

등 그 복잡한 계층과 패킷들은 생각만 해도 골치아프게 한다. 블루투스의 프로토콜 역시 그 스택을 보

는 순간 `만만치는 않겠다'는 생각이 들게 한다.

블루투스의 스펙을 크게 두 부분으로 나눈다면 `라디오(Radio) 스펙'과 `프로토콜 스펙'으로 나눌 수

있다. 그러나 실제 블루투스 스펙을 보면 라디오 스펙에 관련된 부분은 100페이지도 되지 않는다. 나

머지 800페이지 분량을 대부분 프로토콜에 관련된 설명으로 할애하고 있다. 아무리 블루투스의 RF 부

분을 사양에 맞게 설계하였다 하더라도 초당 1600번 주파수 호핑을 하고 Inquiry, Connection 과 피

코넷(Piconet) 구성 등은 모두 프로토콜의 몫인 것이다. 즉 블루투스를 `블루투스답게 만드는 것'이 바

로 프로토콜이다.

본고에서는 일단 블루투스의 프로토콜 스택의 전반적인 내용과 하위 계층에 해당하는 베이스밴드

(Baseband)와 링크 매니져(Link Manager)에 대해 알아보기로 한다. HCI 이상의 상위 레이어에 대해

서는 2부에서 다루기로 한다.

블루투스의 프로토콜 스택(Protocol Stack)

블루투스의 프로토콜 스택은 <그림1>에서 보여지는 바와 같다. 프로토콜 스택이란 그림에서 보여지

는 바와 같이 하위 계층부터 상위 계층까지 쌓아올린 프로토콜의 집합을 말한다. 이 프로토콜 스택은

<그림1> 블루투스의 프로토콜 스택(Protocol Stack)

보통 HCI(Host Controller Interface)를 기준으로 호스트 컨트롤러(Host Controller) 프로토콜과 호스

트(Host) 프로토콜로 나뉘게 된다. <그림1>을 보면 HCI가 두 개의 계층에 위치하는데 바로 아래쪽 HCI

가 호스트 컨트롤러에 포함되는 것이고, 위쪽의 HCI가 호스트에 포함되는 것이다. 여기서 호스트 컨트

롤러에 포함되는 HCI를 `HCI Bottom', 호스트에 포함되는 HCI를 `HCI Top'이라고 말하기도 하며, 두

개의 HCI 사이는 물리 링크인 UART, USB, PCMCIA 등의 인터페이스로 연결된다.

호스트 컨트롤러란 바로 블루투스 모듈에 해당한다. 그리고 호스트 컨트롤러 프로토콜은 보통 베이

스밴드(Baseband), 링크 매니저(LM), HCI Bottom 정도가 포함된다. 대부분 이 세 개의 프로토콜이

펌웨어(Firmware) 형태로 모듈 내부에 포함된다.

호스트는 호스트 컨트롤러인 블루투스 모듈과 연결되어 블루투스 모듈을 제어하고 어플리케이션을

수행하는 곳으로 그 종류는 시스템에 따라 달라질 수 있다. 보통 PC, PDA, 핸드폰 등이 모두 호스트가

될 수 있고, 임베디드 시스템의 경우 마이크로 프로세서가 호스트가 된다. 또 호스트에 포함되는 프로

토콜은 HCI Top부터 그 상위 계층 프로토콜(L2CAP, RFCOMM, SDP, TCS, OBEX) 모두에 해당된다.

그러나 항상 상위 계층 프로토콜이 모두 포함되는 것은 아니고, 어플리케이션의 종류나 프로파일

(Profile)에 따라 포함되는 프로토콜이 달라진다.

그러나 항상 호스트와 호스트 컨트롤러 사이의 프로토콜 스택의 배분이 위와 같은 것은 아니다. 위에

서 설명한 바와 같이 HCI를 기준으로 프로토콜을 배분하는 것이 가장 일반적인 방법이기는 하나 호스

<그림2> 프로토콜 스택의 구현 및 배분의 3가지 구조 (발췌:BlueStack User Manual, Mezoe, 2001)

트의 종류에 따라 <그림2>와 같이 세종류로 나누어질 수 있다. <그림2>에서 `Standard Two

Processor Architecture'가 위에서 설명했던 가장 일반적인 구조이다. 그러나 사실 HCI 상위 계층의

L2CAP, RFCOMM, SDP, TCS 등의 많은 프로토콜을 구현하고 어플리케이션을 수행하는데는 호스트

에 걸리는 작업 로드가 크고, 많은 리소스를 필요로 하게 된다. 따라서 핸드폰과 같이 블루투스 프로토

콜 스택을 위해 할당된 리소스가 적은 호스트일 경우 <그림2>의 두 번째 구조인 `Embedded Two

Processor Architecture' 형태로 프로토콜 스택을 배분한다. <그림3>의 세 번째 구조인 `Wholly

Embedded Single Processor Architecture'는 별도의 호스트가 존재하지 않는 구조이다. 즉 호스트

컨트롤러인 블루투스 모듈만이 존재하고, 이 모듈 내에 모든 프로토콜 스택이 구현되어 있다. 이런 구

조에 가장 적합한 어플리케이션이 무선 헤드셋이다. 이 구조는 말 그대로 별도의 호스트가 필요없는

완전한 임베디드 구조를 지니기는 하나 블루투스 모듈 내부의 자체 프로세서를 사용하므로 비교적 간

단한 어플리케이션에 적합하다.

이제 베이스밴드부터 각각의 프로토콜에 대해서 알아보기로 한다.

베이스밴드 (Baseband)

베이스밴드는 블루투스의 링크 컨트롤러(Link Controller)에 해당하는 프로토콜로서 블루투스만의

고유한 통신 시스템 특성을 구현하는 곳이다. 한마디로 블루투스 프로토콜 중 `가장 바쁜 프로토콜'이

라고 할 수 있다.

우선 베이스밴드에서는 물리 채널을 정의하고 이에 대한 호핑(Hopping)을 담당한다. 블루투스에는

밴드폭이 1MHz인 RF 채널을 79개(국가에 따라 23개이기도 함)로 나누고, 각 채널을 초당 1600회 호

핑을 하는데, 이 채널 정의와 호핑 시퀀스 선택 등이 모두 베이스밴드에서 이루어진다. 또 각 채널별

로 625µs의 길이를 지닌 타임 슬롯(Time Slot)을 설정하여 슬롯을 통해 패킷을 교환하는 시분할이중

방식(TDD:Time-Division Duplex)도 베이스밴드에서 담당한다.

두 번째로 베이스밴드에서 담당하는 역할은 링크 설정이다. 블루투스에는 SCO Link(Synchronous

Connection-Oriented Link)와 ACL Link(Asynchronous Connection-Less Link)가 있다. SCO 링크

는 주기적으로 예약된 타임 슬롯을 통해 패킷을 교환하는 방식으로 주로 음성 채널에 사용된다. 반면

ACL 링크는 예약된 타임 슬롯을 사용하지 않고 패킷을 교환하는 링크이며, 일반 데이터 채널에 사용

된다. 이러한 링크 설정이 모두 베이스밴드에서 이루어진다.

또 베이스 밴드에서는 표준 패킷을 정의하고 생성한다. 표준 패킷은 억세스 코드(Access Code), 헤

<그림3> 표준 패킷의 포맷

더(Header), 페이로드(Payload)로 구성되어 있고, 역할 및 링크의 종류에 따라 링크 컨트롤 패킷,

ACL 패킷, SCO 패킷으로 나뉘어진다. 또 각 3종류의 패킷은 페이로드 길이, FEC 방식, CRC 여부 등

에 따라 더 세분화된 패킷으로 나누어진다. 또 각 패킷의 종류에 따라 전송 속도도 달라지는데 가장 최

고의 속도를 낼 수 있는 패킷은 DH5 패킷으로, 비대칭 모드로 최고 723.3kbps, 대칭 모드로는 최고

433.9kbps까지 낼 수 있다.

패킷과 관련되어 베이스 밴드에서는 에러 정정(Error Correction) 및 에러 검출(Error Checking)도

담당한다. 블루투스에서 사용되는 에러 정정 방법은 1/3 rate FEC, 2/3 rate FEC, ARQ의 세가지이며

<그림4> ARQ Scheme

그 사용은 패킷의 종류에 따라 다르다. 또 에러가 발생한 패킷은 재전송(Retransmission)을 하는데

이것은 ACL 링크에서만 가능하며, SCO 링크에서는 재전송이 이루어지지 않는다.

에러검출은 표준 패킷의 억세스 코드, 헤더, 페이로드 각각에 대해서 이루어진다. 패킷을 수신할 때

는 먼저 억세스 코드를 체크하게 되는데, 이 억세스 코드를 통해 수신된 데이터 패킷이 자신의 피코넷

데이터인지, 다른 피코넷 데이터인지를 구분해 낼 수 있다. 또 헤더의 경우에는 HEC, 페이로드의 경우

에는 CRC 방식으로 에러 검출한다.

또 베이스밴드는 여러 개의 상위 레이어들과 인터페이스를 위한 논리 채널(Logical Channel)도 정

의한다. <그림1>의 스택 구조를 보면 베이스밴드는 LM, L2CAP, Voice 레이어 등과 직접 인터페이스

를 할 수 있다. 베이스밴드에서는 5개의 논리 채널을 설정하여 LC(Link Control), LM(Link Manager)

뿐만 아니라 L2CAP나 SCO(대부분 Voice) 등과 인터페이스가 가능하다.

이외에도 저레벨 링크 라우틴(Low Level Link Routine)도 담당하여 각 링크의 트래픽(Traffic)을 관

리하고 흐름 제어(Flow Control)도 담당한다.

그러나 무엇보다 베이스밴드에서 담당하는 역할 중 가장 중요한 것은 바로 채널 컨트롤이다. 채널 컨

트롤이란 마스터와 슬레이브 사이에 커넥션이 이루어지고 피코넷이 구성되는 과정에 관련된 것이고,

<그림5> 블루투스 링크 컨트롤러의 상태도(State Diagram)

이러한 과정은 스테이트(State)로 구분지어진다. 블루투스에서는 2개의 메이저 스테이트(Major

State)와 7개의 서브스테이트(Substate)로 나뉘게 된다. 2개의 메이저 스테이트는 STANBY와

CONNECTION이며, 7개의 서브스테이트는 page, page scan, inquiry, inquiry scan, master

response, slave response이며, 각 스테이트간의 천이도는 <그림5>에 나타나 있다.

CONNECTION 상태가 되기 위해서는 inquiry와 paging을 거쳐야 한다. inquiry란 주위에 연결할 수

있는 블루투스 디바이스를 찾고자 할 때 사용하는 것이다. 이렇게 하여 주위에 연결할 수 있는 블루투

스 디바이스를 찾아내면 어드레스와 클럭(Clock) 정보 등으로 호핑 시퀀스를 동기화하며 실제 커넥션

을 수행하는데 이것이 paging이다. 이러한 inquiry와 page는 마스터에서 수행하며 IAC(Inquiry

Access Code)와 DAC(Device Access Code)를 이용한다. 따라서 슬레이브는 IAC와 DAC를 수신할

수 있는 준비가 되어야 하는데, 이 상태가 inquiry scan, page scan이다. 보통 inquiry는 두 개의 디

바이스가 처음으로 연결될 때만 수행한다. 실제로 inquiry를 수행하면 디바이스를 발견할 때까지 몇

초 이상의 비교적 긴 시간이 소요되는데, 이것은 실제 inquiry 과정에서는 디바이스 간에 호핑 설정이

없으므로, 여러 채널을 통한 브로드캐스팅(Broadcasting)을 수행하게 되므로 긴 시간이 소요되는 것

이다. 그러므로 일단 한번 연결이 된 후 종료가 되어 다시 연결을 시도할 때는 inquiry를 거치지 않고,

바로 paging으로 커넥션을 수행할 수 있으므로 inquriy로 소요되는 시간을 줄일 수 있다.

위와 같은 과정을 거쳐 CONNECTION 상태가 되면 Active, Sniff, Hold,Park라는 4가지의 동작 모드

로 나누어지게 된다. 이렇게 하는 것은 채널 및 링크를 효율적으로 확립하고, 전력 소비를 최소화하기

위함이다. Active Mode는 가장 일반적이고 제약이 없는 CONNECTION 상태이다. Sniff Mode는 슬레

이브에서만 가능하며 마스터와 슬레이브 사이에 통신이 가능한 타임 슬롯을 특정하게 제한하는 것이

다. 즉 슬레이브의 듀티 사이클(duty cycle)이 제한되어 있어 특정 타임 슬롯일 때만 마스터와의 통신

이 가능하다.

Hold Mode는 일정 시간 동안 ACL 링크가 지원되지 않는 상태로, 이 모드에서는 scanning,

inquiring, paging 등이 가능하고 심지어 다른 피코넷에 참여하여 스캐터넷을 구성할 수도 있다. 또 전

력 사용을 최소화하는 Low-Power Sleep Mode로 들어갈 수도 있다. Hold Mode에 들어가기 전에

마스터와 슬레이브는 그 Hold Mode duration을 서로 약속을 하여, 그 시간이 지나면 Hold Mode에서

벗어나게 된다.

Park Mode는 슬레이브가 현재로서는 피코넷에서 참여할 필요가 없지만 채널 동기 상태는 유지할

필요가 있을 때 사용된다. 슬레이브가 Park Mode가 되면 Parked Member Address(PM_ADDR)이

라는 새로운 어드레스가 부여되며 마스터는 PM_ADDR을 통해 Park Mode 상태인 슬레이브를 식별할

수 있다. Park Mode인 슬레이브는 마스터와 정상적인 패킷 교환은 불가능하지만, Beacon 채널을 통

해 주기적으로 마스터로부터 패킷을 수신하다. 이 Beacon 채널을 통해 Park Mode인 슬레이브 중 특

정 디바이스를 원하는 시간에 피코넷에 참여시킬 수 있다. Park Mode를 이용하면 하나의 피코넷에 8

개 이상의 슬레이브를 참여시킬 수 있다. 비록 동시에 피코넷에 참여할 수 있는 슬레이브는 7대로 한

정되지만 Active 슬레이브와 Park 슬레이브를 적절히 교환시키면서 피코넷을 구성하면 실제로 규모가

큰 피코넷을 구성하는 것이 가능하다.

이외에도 베이스밴드는 오디오 채널에 대한 인터페이스를 제공하며 보안(Security)에 관련된 과정

<그림6> 인증(Authentication) 및 암호화(Encryption)에 관련된 인자들

도 담당한다. 이상에서 살펴봤듯이 베이스밴드에서 처리하는 일들은 그 양이 많기도 하지만 블루투스

의 핵심적인 부분이라고 말할 수 있다. 따라서 블루투스의 RF와 더불어 베이스밴드 설계 기술은 블루

투스 기술의 핵심이라고 할 수 있다. 블루투스 초창기에는 블루투스의 RF와 베이스밴드가 별도의 칩

셋으로 분리되었었다. 그러나 영국 CSR사는 처음으로 이 블루투스 RF와 베이스밴드를 원칩화 시킨

칩셋을 설계하고 제품화하여 한동안 원칩화된 칩셋이 대세를 이루어가기도 했다. 그러나 최근에는 블

루투스 자체가 다양한 시스템에 내장되어 가고 있는 추세이므로 베이스밴드가 SoC 형태로 다양하게

칩셋화되어 가고 있다. PDA용 ARM7 칩셋이나 휴대폰 칩셋에 블루투스 베이스밴드가 내장된 제품이

출시되고 있다.

링크 매니져 (Link Manager:LM)

블루투스 스펙을 보면 링크 매니져는 링크 설정, 보안, 제어를 담당한다고 설명하고 있다. 그렇다면

과연 베이스밴드와 무슨 차이가 있냐는 의문을 갖게 할 수도 있다. 링크 매니져의 주된 역할은 LMP

메시지를 이용한 통신이다. 즉 링크 설정, 커넥션 스테이트(Park, Sniff, Hold)의 설정, 링크 키(key)나

암호화(Encryption) 등의 보안 설정 등을 결정하여 RF 및 링크를 직접 제어하는 곳은 베이스밴드이나,

만약 위와 같은 설정을 리모트 디바이스(Remote Device)에게 명령 및 제어를 수행하고 리모트 디바

이스의 상태에 대한 정보를 얻기 위해서는 별도의 통신 수단이 필요하다. 바로 이 역할을 하는 것이

LMP 메시지이다. 즉 베이스밴드가 `중앙사령부'라면 여기서 결정한 내용을 주위로 전달하고 또 그 상

황을 보고받는 `통신부' 역할을 하는 곳이 링크 매니져인 것이다.

LMP 메시지는 두 디바이스의 링크 매니져 사이에서 송수신되며 상위 계층으로 전달되지는 않는다.

또 페이로드를 통해 전달이 되며 L_CH라는 페이로드 헤더를 지닌다. L_CH의 코드에 따라서 베이스밴

<그림7> L_CH 코드와 논리 채널(Logical Channel)

드의 논리 채널(Logical Channel)이 설정된다. 링크 매니져에서 담당하는 일은 인증(Authentication)

을 위해 링크 키의 교환이나 페어링(Paring) 등을 수행, 암호화(Encryption), 클럭(Clock)이나 슬롯

(Slot) 관리, 롤(Role) 스위치, 커넥션 스테이트 (Park, Sniff, Hold) 설정, 파워 컨트롤, QoS 등이다. 이

<그림8> 커넥션이 성립되기 위한 LMP PDU의 교환 과정

러한 동작을 수행하기 위해 LMP PDU(Protocol Data Unit)가 두 개의 디바이스 사이에서 교환되고,

이것은 각 동작마다 정해진 규칙(Rule)에 따라야 한다. <그림8>은 커넥션이 이루어지기 위해서 두 디

바이스의 링크 매니져 사이에서 교환되는 LMP PDU의 순서가 보여지고 있다. 일단 두 개의 디바이스

의 베이스밴드에서 각각 page와 page scan 상태가 되고 난 후, 클럭 오프셋, LMP 버전, 이름 등의

정보를 LMP PDU를 통해 주고받는다. 그후 커넥션 요청 PDU와 이에 대한 응답 PDU를 주고 받으면

그 이후 페어링, 인증, 암호화 등의 보안과 관련된 LMP PDU가 교환된다.(물론 이 보안과정은 프로파

일에 따라 생략할 수도 있다.) 이러한 PDU 교환 과정을 거쳐서 커넥션이 성립되는 것이다.

이상에서 블루투스 프로토콜 스택에 대한 전반적인 내용과 이중 베이스밴드와 링크매니져에 대해서

알아보았다. 2부에서는 HCI 이상의 상위 계층 프로토콜을 다룬 후, SIG에서 규정한 프로파일(Profile)

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


	블루투스 강좌
	▣ 블루투스(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 >