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

프로토콜(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.lab 이한욱 (BLUETOOTH Lab. 팀장)