블루투스 LE를 사용한 ‘Half-duplex’ 음성 통신 (1)블루투스 LE의 개요
블루투스 LE를 사용한 ‘Half-duplex’ 음성 통신 (2)BlueVoice 애플리케이션
블루투스 LE를 사용한 ‘Half-duplex’ 음성 통신 (3)실제 하드웨어 구현
BlueVoice 애플리케이션
이 장에서는 BlueVoice 애플리케이션을 소개한다. 먼저 음성 통신 블루투스 LE 프로파일에 대해서 살펴 본 후 애플리케이션 설계와 관련해서 디바이스들의 통신 역할, 오디오 처리 및 압축, 패킷화 문제, 대역폭 요구조건 등을 살펴본다.
구성 방식은 오디오 포착(audio acquisition)에 따라 두 가지로 나뉘며, 방식에 따라 전력 소모 또한 달라진다. 그리고 애플리케이션도 제약사항 별로 나뉜다. 이장의 후반부에서는 실제 하드웨어 디바이스로 BlueVoice를 다루고 끝으로 전력 소모, 메모리 풋프린트, 처리(processing)관련 요구사항, ASR(Automatic Speech Recognition) 성능을 측정한 성능을 비교 및 논의한다.
ⓒGetty images Bank
1. 서비스 정의
오디오 스트리밍 활용 사례는 BlueVoice 애플리케이션의 음성 스트리밍 서비스 구현을 위해 블루투스 LE 프로토콜 스택 상에 BlueVoice Service(BVS)라고 하는 ‘vendor specific(특정 업체의 특수한)’ 프로파일을 정의하고 있다. 이로 인해 서버와 클라이언트 디바이스 간의 음성 데이터 교환을 규격화 할 수 있다. 뿐만 아니라 반이중 통신을 위해서도 아래에서 설명하는 것과 같이 특정 설계를 선택할 필요가 있다.
앞서 설명했듯이 GATT는 ATT 프로토콜을 디바이스 간의 데이터 교환용 전송 프로토콜로 사용한다. ATT가 정의하는 가장 작은 개체인 ‘어트리뷰트’는 어드레스 가능한 정보 조각(UUID만이 식별 가능)으로 사용자 데이터나 허용, 암호화, 권한 어트리뷰트와 같이 어트리뷰트 자체의 아키텍처에 관한 메타 정보를 포함한다.
반면, GATT 서버 어트리뷰트는 일련의 서비스로 이루어지며 서비스마다 디스크립터(descriptor)와 특성(characteristic)이 한 개 이상 포함되는 서비스 등록 어트리뷰트(service declaration attribute)로 시작된다.
각각의 특성은 노출된 어트리뷰트이다. BlueVoice 애플리케이션 처럼, 표준 프로파일 UUID와 별도로 특정 회사용 사유 UUID를 적용하여 특성에 맞게 새로운 서비스를 맞춤형으로 구현하는 것도 가능하다.
단방향 오디오 스트리밍 비대칭 시스템의 경우, 서버 노드가 내보내는 BVS 프로파일은 데이터 타입과 형식이 어떻게 구성되었으며 어떻게 액세스할 수 있는지가 클라이언트에게 노출된다. BVS 서비스는 다음과 같은 어트리뷰트로 정의되며 그림 2로도 확인할 수 있다.
•Service declaration(Handle 0x0010)
- UUID : 표준 16비트 UUID[primary service declaration (0x2800)]
- 허용범위 : 읽기
- 값(Value) : proprietary 128비트 BVS UUID
•Characteristic declaration(Handle 0x0011)
- UUID : 표준 16비트 UUID[primary service declaration(0x2803)]
- 허용범위 : 읽기
- 값(Value) : proprietary 128비트 Audio UUID(notification only), Handle : 0x012.
•Characteristic data(Handle 0x0012)
– UUID : proprietary 128비트 Audio UUID
– 허용범위 : 없음
– 값(Value) : 실제 오디오 데이터
•Characteristic declaration(Handle 0x0014)
– UUID : 표준 16비트 UUID(characteristic declaration (0x2803))
– 허용범위 : 읽기
– 값(Value) : proprietary 128비트 Sync UUID(notification only), Handle : 0x0015
•Characteristic data(Handle 0x0015)
– UUID : proprietary 128비트 Sync UUID
– 허용범위 : 없음
– 값(Value) : 실제 싱크로 데이터
이 표준에 따르면 primary Service Declaration이 이 서비스의 첫 번째 어트리뷰트이며 값의 영역에는 이 등록(declaration)이 소개하는 UUID의 정의도 포함하고 있다. BlueVoice 애플리케이션에는 128비트 proprietary UUID(BVS UUID)가 등록됐다.
BVS는 Audio와 Sync의 두 가지 특성을 갖는다. 블루투스 LE 표준은 최소한 2개의 어트리뷰트로 이루어지는데, 각각의 특성은 메타데이터의 형태로 자신의 어트리뷰트를 정의하는 특성 등록(characteristic declaration)과 실제 특성 데이터를 담고 있는 특성 값(characteristic value)이다.
BlueVoice의 경우에는 Audio와 Sync 특성 둘 다 각기 실제 오디오 데이터와 부가 정보인 동기화 값을 담고 있는 128비트 proprietary UUID(AudioData와 SyncData UUID)로 정의된 단일 어트리뷰트를 포함한다.
Audio와 Sync 특성 등록은 AudioData와 SyncData 어트리뷰트를 ‘notification only’로만 정의하며 클라이언트로부터 읽기 및 쓰기를 허용하지 않는다. 다시 말해서 오디오 및 싱크 데이터는 알림(notification)의 방식으로만 교환되며 서버에서 클라이언트로 응답을 받지 않는다는 것이다. 앞으로 다른 BlueVoice 애플리케이션이 출시되면 블루투스 LE 서비스의 계층적 아키텍처에 맞춘 다른 특성들이 추가될 수 있을 것이다.
그림 2: BlueVoice 서비스(BVS) 정의
2. 애플리케이션 설계
다음으로는 BlueVoice 애플리케이션 설계에 대해서 살펴보자. 구체적으로는 블루투스 LE 통신과 오디오 처리에 대해 살펴본다.
(1) 블루투스 LE 통신
블루투스 LE 표준에 따르면 통신은 브로드캐스트나 접속 기반으로 구현된다. BlueVoice 애플리케이션은 LL층에서 접속 기반 통신 패러다임으로 2개의 디바이스 사이에 영구적인 점대점 링크를 제공하고, 이를 통해 이 디바이스들은 중앙(Central)과 주변장치(Peripheral)의 두 가지 역할을 맡는다.
중앙(마스터) 디바이스는 주변장치(슬레이브) 디바이스와 관련하여 복합적인 기능을 제공한다. 중앙 디바이스는 접속 시행, 적응형 주파수 호핑 처리, 암호화 설정, 통신 타이밍 관리를 하며 두 디바이스 간의 데이터 교환을 정의한다.
작은 배터리를 쓰는 휴대용 디바이스가 일반적으로 슬레이브인 것처럼 에너지 제약이 더 심한 쪽의 디바이스에 수행할 업무를 적게 주는 블루투스 LE의 비대칭 구조 개념에서도 이러한 역할 분담은 동일하게 이루어진다.
하지만 규격에 따라1) 매번 접속이 일어날 때 마다 양쪽 디바이스 모두 독립적으로 데이터를 전송할 수도 있다. 또한 역할에 따라 데이터 쓰루풋이나 우선순위에 제한을 받지 않는다.
양 쪽 모두 마이크(나중에는 흔한 모니터링 애플리케이션과 같은 전형적인 IoT 제품을 위해 스칼라 센서도 탑재)가 탑재된 자율 배터리형 무선 센서 디바이스로 구동되는 BlueVoice 애플리케이션의 반이중 통신의 경우, 역할 지정을 트랜스미터 또는 리시버 기능과는 별도로 분리시켜야 한다.
LL 층뿐만 아니라 GATT 층도 위에서 설명한 마스터 및 슬레이브 역할과는 별개로 인터랙션하는 디바이스들 간의 클라이언트 및 서버 역할을 한다.
서버는 정보를 가지고 있는 디바이스이고, 클라이언트는 정보 업데이트를 요청하거나 수신하는 디바이스이다. 단방향 오디오 스트리밍 비대칭 시스템을 볼 때 음성 정보를 갖는 디바이스만이 마이크가 제공되므로 이 통신의 서버가 될 수 있다.
상대 디바이스는 클라이언트로 동작하여 서버로 요청을 전송하고 서버로부터 오디오 데이터를 담고 있는 업데이트를 수신한다. 양방향 시스템은 음성을 어느 방향으로든 전송할 수 있는 경우로서 아키텍처가 대칭적이다. 그러므로 중앙 모듈과 주변장치 모듈 둘 다 마이크가 주어지고 서버로 동작하면서 어트리뷰트로 구성된 오디오 데이터를 내보낼 수 있다.
이와 동시에 클라이언트로 동작해서 다른 모듈로 요청을 전송하고 업데이트를 수신할 수도 있다. 양방향에서는 음성 데이터 스트리밍이 주기적인 서버 대 클라이언트 알림(notification)에 기반하며 수신 디바이스로부터 요청이나 응답을 필요로 하지 않는다.
파워업 시에 슬레이브 모듈은 애드버타이징(advertising) 모드가 되어 낮은 주파수로 애드버타이징 패킷을 전송한다. 역으로 마스터 모듈은 디스커버리(discovery) 모드가 되어서 다른 장치들을 탐색하고 애드버타이즈먼트 패킷을 수신하여 슬레이브 디바이스를 발견하는 즉시 접속 요청을 전송한다.
접속 후에는 주변장치에서 중앙, 중앙에서 주변장치로, 선택 방향을 따라 서버에서 클라이언트로 오디오 데이터가 포함된 비동기 알림 패킷이 주기적으로 전송된다. 그림 3은 GATT 층에서 BlueVoice의 역할 지정을 보여준다.
(2) 오디오 처리
BlueVoice 애플리케이션의 오디오 처리는 리시버 측에서 8kHz나 16kHz(애플리케이션에 따라 선택 가능)의 오디오 샘플링 주파수를 달성하도록 설계된다. 8kHz의 샘플링 비율은 저전력 제한이 심하고 어느 정도의 낮은 오디오 품질도 허용할 수 있는 경우에 적당하다. 이러한 애플리케이션의 예로는 오디오를 ASR 서비스의 입력으로 사용하거나 사람의 청취를 목적으로 하지 않는 경우를 들 수 있다.
블루투스 LE 링크를 통해서 전송되는 오디오 신호는 Adaptive Differential Pulse Code Modulation 알고리즘을 통해 압축된다. 따라서 사용 가능한 데이터 속도 이내로 맞추어 넣을 수 있을 뿐만 아니라 무선 전송 시간과 전력 소모를 최소화 할 수 있다.
디지털 MEMS 마이크를 사용하면 디지털화된 솔루션을 설계 할 수 있다. 디지털 MEMS 마이크는 크기와 오디오 품질이 뛰어나 무선 센서 디바이스에 사용하기에 적합하다. 그림 4는 16kHz 샘플 비율의 전체적인 음성 처리 체인을 보여준다.
디지털 MEMS 마이크가 생성한 1MHz의 1비트 PDM(pulse density modulation) 신호를 포착하고, 16kHz로 16비트 PCM(pulse code modulation) 샘플로 변환하고, 이를 다시 16ks/s 주파수로 4비트 ADPCM 샘플로 압축해서 전송할 수 있게 준비시킨다. 또한 이와 함께 낮은 주파수로 일련의 부차적 동기화 데이터를 전송한다.
최종 대역폭은 64kbps의 오디오 데이터와 300bps의 동기화 정보로서 총 64.3kbps에 이른다. 8kHz 샘플링 비율의 경우, 최종 ADPCM 샘플 비율은 8ks/s로 대역폭이 부차적 정보를 포함해서 31.3kbps이다.
MEMS 마이크의 커패시티브 센싱 소자가 발생시킨 아날로그 신호가 증폭되고 높은 속도로 샘플링된 후 내장형 시그마-델타 변조기(modulator)로 처리된다. 이 변조기는 양자화(quantization)와 잡음 쉐이핑(noise shaping) 구동을 합쳐서 높은 샘플링 속도로 단일 비트를 PDM 형식으로 출력한다.
그리고 PDM과 압축 오디오 데이터 사이의 중간 단계로 PCM 변환을 선택하며 이후에는 무선 채널을 통해 전송된다. PDM 스트림을 PCM 데이터로 변환하기 위해서 1개의 데시메이션 필터와 2개의 개별적으로 구성할 수 있는 필터(저역통과 및 고역통과)를 사용한다.
이 프로세스 블록의 출력이 PCM 형식의 16비트 샘플 스트림이다. 선택한 샘플링 주파수에 따라서 각기 다른 구성의 데시메이션 필터를 사용해 16비트 PCM 데이터 샘플을 얻을 수 있다.
ADPCM 인코딩 블록은 PCM 샘플을 압축하여 전송되는 패킷 수를 줄이는 방식으로 전송 대역폭을 절약하고 에너지 소모를 낮춰준다. 위에서 언급했듯이 ADPCM은 선행 값으로부터 현재의 신호값을 예측하는 로시(lossy) 파형 코딩용 압축 알고리즘으로, adaptive quantization 스텝으로 양자화된 실제 값과 예측된 값 사이의 차이만을 전송한다.
가능한 여러 압축 표준 중에서 ADPCM 압축을 선택한 것은 파형 코딩 기법을 쓰는 것이 보코더 기법 기반의 복잡한 솔루션에 비해서 센서 네트워크 디바이스(통상적으로 마이크로컨트롤러 기반)에 사용하기에 더 적합하기 때문이다.
BlueVoice 애플리케이션에서는 매 16비트 PCM 샘플을 4비트 ADPCM 데이터로 인코딩하기 때문에 필요한 애플리케이션 전송 대역폭이 샘플링 주파수에 따라서 32ksps 또는 64kbps이다. 따라서 블루투스 LE 스트리밍 기능에 사용하기에 적당하다.
그런데 BlueVoice 애플리케이션에 필요로 하는 전체적 대역폭은 32kbps나 64kbps와 같은 이론상의 수치보다 더 높아야 한다. 왜냐하면 BlueVoice는 채널을 통해서 데이터를 전송할 때 통신 견고성을 향상시키기 위해서 부수적인 정보를 추가하기 때문이다.
16kHz 구성의 경우에는 10ms의 접속 간격을 사용하고, 8kHz 구성의 경우에는 20ms의 접속 간격을 사용한다. 전송해야 할 데이터양이 적으면 그만큼 접속 간격을 늘릴 수 있기 때문에 에너지를 절약할 수 있다. 음성 데이터 패킷은 20바이트의 패킷 형태로 전송한다. 매 데이터 패킷에 최대의 가용 페이로드를 활용하기 위해서다.
그러므로 16kHz 구성의 경우, 10ms 마다 4패킷의 음성 데이터를 전송하고 8kHz 구성에서는 20ms마다 4패킷의 음성 데이터를 전송하여 각각 64kbps와 32kbps의 데이터를 구현한다. 트랜스미터 쪽의 정보는 더 낮은 주파수에서 160m(16개나 8개의 접속 간격과 동일)마다 6바이트의 추가 패킷 형태로 전송된다.
그림 5에서는 블루투스 LE 프로토콜 스택 상의 전체적인 데이터 패킷화 정책을 요약해서 보여준다. 10ms나 20ms의 접속 간격마다 오디오 특성을 통해 20바이트로 이루어진 4개의 음성 데이터 패킷을 전송하고, Sync 특성을 통해서는 160ms마다 추가 패킷으로 트랜스미터 측 정보를 전송한다.
마우리지오 젠틸리, 로베르토 산니노 _ STMicroelectronics
마테오 페트라카 _ Scuola Superiore Sant’Anna di Pisa and National Inter-University Consortium for Telecommunications
