본문 바로가기

Software/Bluetooth

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

해당글은 http://www.microvision.co.kr/bluetooth/lecture/lecture_protocol_1.htm 에서 정리되었습니다.


프로토콜(Protocol)이란 디바이스간에 데이터를 송수신하기 위한 하나의 약속을 말한다. 이 프로토콜은 하나의 통신 시스템의 성능을 결정하는 매우 핵심적인 것이다. 하지만 OSI7 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>와 같이 세종류로 나누어질 수 있다.

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

<그림 2>와 같이 세종류로 나누어질 수 있다. <그림 2>에서 'Standard Two Processor Architecture'가 위에서 설명했던 가장 일반적인 구조이다. 그러나 사실 HCI 상위 계층의 L2CAP, RFCOMM, SDP, TCS 등의 많은 프로토콜을 구현하고 어플리케이션을 수행하는데는 호스트에 걸리는 작업 로드가 크고, 많은 리소스를 필요로 하게 된다. 따라서 핸드폰과 같이 블루투스 프로토콜 스택을 위해 할당된 리소스가 적은 호스트일 경우 <그림 2>의 두 번째 구조인 'Embedded Two Processor Architecture' 형태로 프로토콜 스택을 배분한다.

<그림 2>의 'Wholly Embedded Single processor Architecture'는 별도의 호스트가 존재하지 않는 구조이다. 즉 호스트 컨트롤러인 블루투스 모듈만이 존재하고, 이 모듈 내에 모든 프로토콜 스택이 구현되어 있다. 이런 구조에 가장 적합한 어플리케이셔이 무선 헤드셋이다. 이 구조는 말 그대로 별도의 호스트가 필요없는 완전한 임베디드 구조를 지니기는 하나 블루투스 모듈 내부의 자체 프로세서를 사용하므로 비교적 간단한 어플리케이션에 적합하다. 이제 베이스밴드 부터  각각의 프로토콜에 대해서 알아보기로 한다.



베이스밴드(Baseband)

베이스밴드는 블루투스의 링크 컨트롤러(Link Controller)에 해당하는 프로토콜로서 블루투스만의 고유한 통신 시스템 특성을 구현하는 곳이다. 한마디로 블루투스 프로토콜 중 '가장 바쁜 프로토콜'이라고 할 수 있다.

우선 베이스밴드에서는 물리 채널을 정의하고 이에 대한 호핑(Hopping)을 담당한다. 블루투스에는 밴드폭이 1MHz인 RF채널을 79개(국가에 따라 23개 이기도 함)로 나누고, 각 채널을 초당 1600회 호핑을 하는데, 이 채널의 정의와 호핑 시퀀스 선택 등이 모두 베이스밴드에서 이루어진다. 또 각 채널별로 625us의 길이를 지닌 타임 슬롯(Time slot)을 설정하여 슬롯을 통해 패킷을 교환하는 시분할 이중방식(TDD:Time-Division Duplex)도 베이스밴드에서 담당한다.

두 번째로 베이스밴드에서 담당하는 역할은 링크 설정이다. 블루투스에는 SCO Link(Synchronous Connection-Oriented Link)와 ACL Link(Asynchronous Connection-Less Link)가 있다. SCO 링크는 주기적으로 예약된 타임 슬롯을  통해 패킷을 교환하는 방식으로 주로 음성 채널에 사용된다. 반면 ACL 링크는 예약된 타임 슬롯을 사용하지 않고 패킷을 교환하는 링크이며, 일반 데이터 채널에 사용된다. 이러한 링크 설정이 모두 베이스밴드에서 이루어진다.

또 베이스 밴드에서는 표준 패킷을 정의하고 생성한다. 표준 패킷은 억세스 코드(Access Code), 헤더(Header), 페이로드(Payload)로 구성되어 있고, 역할 및 링크의 종류에 따라 링크 컨트롤 패킷, ACL 패킷, SCO 패킷으로 나뉘어진다.

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

또 각 3종류의 패킷은 페이로드 길이, FEC 방식, CRC 여부 등에 따라 더 세분화된 패킷으로 나누어진다. 또 각 패킷의 종류에 따라 전송 속도도 달라지는데 가장 최고의 속도를 낼 수 있는 패킷은 DH5 패킷으로, 비대칭 모드로 최고 723.3kbps, 대칭 모드로는 최고 433.9bkps 까지 낼 수 있다.

패킷과 관련되어 베이스밴드에서는 에러 정정(Error correction) 및 에러 검출(Error Checking)도 담당한다. 블루투스에서 사용되는 에러 정정법은 1/3 rate FEC, 2/3 rate FEC, ARQ의 세가지이며 그 사용은 패킷의 종류에 따라 다르다. 또 에러가 발생한 패킷은 재전송(Retransmission)을 하는데 이것은 ACL 링크에서만 가능하며, SCO 링크에서는 재전송이 이루어지지 않는다.

<그림 4> ARQ Scheme

에러 검출은 표준 패킷의 억세스 코드, 헤더, 페이로드 각각에 대해서 이루어진다. 패킷을 수신할 때는 먼저 억세스 코드를 체크하게 되는데, 이 억세스 코드를 통해 수신된 데이터 패킷이 자신의 피코넷 데이터인지, 다른 피코넷 데이터인지를 구분해 낼 수 있다. 또 헤더의 경우에는 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)도 담당한다. 

그러나 무엇보다 베이스밴드에서 담당하는 여갈 중 가장 중요한 것은 바로 채널 컨트롤이다. 채널 컨트롤이란 Master와 Slave 사이에 Connection이 이루어지고 피코넷이 구성되는 과정에 관련된 것이고, 이러한 과정은 스테이트(State)로 구분지어진다. 블루투스에서는 2개의 메이저 스테이트(Major state)와 7개의 서브 스테이트(Substate)로 나뉘게 된다. 2개의 메이저 스테이트는 STANDBY와 CONNECTION이며, 7개의 서브 스테이트는 page, page scan, inquiry, inquiry scan, master response, slave response이며, 각 스테이트간의 천이도는 <그림 5>에 나타나 있다.

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

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으로 Connection을 수행할 수 있으므로 inquiry로 소요되는 시간을 줄일 수 있다.

위와 같은 과정을 거쳐 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 메세지이다.

즉 베이스밴드가 '중앙사령부'라면 여기서 결정한 내용을 주위로 전달하고 또 그 상황을 보고받은 '통신부' 역할을 하는 곳이 링크 메니저인 것이다.

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

LMP 메세지는 두 디바이스의 링크 메니저 사이에서 송수신되며 상위 계층으로 전달되지는 않는다. 또 페이로드를 통해 전달이 되며 L_CH라는 페이로드 헤더를 지닌다. L_CH의 코드에 따라서 베이스밴드의 논리 채널(Logical Channel)이 설정된다. 링크 매니저에서 담당하는 일은 인증(Authentication)을 위해 링크 키의 교환이나 페어링(Pairing) 등을 수행, 암호화(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)에 대해서 살펴보기로 하겠다.

반응형