Bluetooth® Core 7.0 기능 개요
| 버전: | 1.0 |
| 발행일: | 2026년 11월 3일 |
| 작성자: | 루공유 |
1. 소개
Bluetooth® Core 7.0은 데이터 처리량, 등시성 전송, 보안 및 구현 지원 전반에 걸쳐 Bluetooth® LE의 기능을 확장하는 다양한 개선 사항을 도입합니다. 이러한 개선 사항은 더 높은 처리량, 보다 유연한 전송 동작, 새로운 보안 모델, 그리고 개발 및 상호 운용성 테스트를 위한 향상된 가시성에 대한 변화하는 요구 사항을 충족시킵니다. 이 모든 개선 사항은 기존 Bluetooth 아키텍처를 기반으로 하면서도, Bluetooth 기기가 점점 더 까다로워지는 애플리케이션과 운영 환경에 적응할 수 있도록 하는 새로운 기능을 도입합니다.
본 논문은 Bluetooth® Core 7.0에 도입된 주요 기능에 대한 기술적 개요를 제시합니다. 이 논문에서는 Bluetooth® HDT( 고속 데이터 처리량 ), Bluetooth® LE 아이소크로너스 IPU( 매개변수 Update), Bluetooth® EKS(Encryption Key Schedule), Bluetooth® TAK(Transient Application Key), Bluetooth® EPD( 제품 Debugging)를 살펴봅니다. 이 논문은 각 기술( 기능)에 대해 그 배경이 되는 동기, 아키텍처 개념 및 주요 프로토콜 메커니즘을 설명함으로써, 이러한 변화가 블루투스 기술을 어떻게 확장하고 발전시키는지를 이해하는 데 필요한 기초를 제공합니다.
참고: 본 문서는 마케팅 용도로 작성된 것이며, 어떠한 방식으로도 Bluetooth® 핵심 사양을 대체하거나 무효화하기 위한 것이 아닙니다. 각 기능 개선 사항은 관련 배경 정보를 시작으로 별도의 섹션에서 설명되어 있습니다. 이는 Bluetooth® LE의 특정 측면에 익숙하지 않은 독자들에게 도움을 드리기 위한 것입니다. 다만, 배경 정보 섹션은 모든 내용을 완벽하게 다루고 있지는 않습니다. 익숙하지 않은 용어나 개념을 접하게 되는 독자들은 Bluetooth® LE 입문서를 다운로드하여 읽어보시기 바랍니다 .
2. 한눈에 보기
2.1 블루투스® 고속 데이터 처리량
Bluetooth® 고해상도 전송( 고속 데이터 처리량 , HDT)은 무선 효율성과 안정성을 향상시키면서 Bluetooth의 최대 비트 전송률을 7.5 Mbps로 높이는 새로운 Bluetooth LE 물리 계층을 도입합니다. 고차 변조, 컨볼루션 전방 오류 정정, 동기화 개선, 적응형 전송률 선택 및 향상된 패킷 아키텍처를 결합한 HDT를 통해 Bluetooth 기기는 더 많은 양의 데이터를 보다 효율적이고 안정적으로 전송할 수 있습니다. 기능 는 기존 블루투스 LE 아키텍처와의 하위 호환성을 유지하면서, 고해상도 및 무손실 오디오 스트리밍을 포함한 향후 더 높은 데이터 전송 속도를 요구하는 블루투스 애플리케이션을 위한 확장 가능한 기반을 제공합니다.
2.2 블루투스® LE 등시성 매개변수 업데이트
Bluetooth® LE 등시성 연결 스트림( 매개변수 ) 업데이트(IPU)는 스트림이 설정된 후에도 활성 상태인 연결된 등시성 스트림(CIS)의 매개변수를 업데이트할 수 있도록 하는 표준화된 메커니즘을 도입합니다. 대역폭, 지연 시간, 전송 또는 스케줄링 요구 사항이 변경될 때 연결된 등시성 그룹(CIG)을 제거하고 다시 생성하는 대신, IPU를 통해 장치는 기존 연결을 유지한 채 대체 스트림 구성 간에 전환할 수 있습니다. 이 기능은 Bluetooth LE 오디오 및 기타 등시성 애플리케이션의 유연성을 향상시키고, 서비스 중단을 줄이며, Bluetooth® 장치가 변화하는 애플리케이션 요구 사항에 맞춰 전송 특성을 동적으로 조정할 수 있도록 합니다.
2.3 블루투스® 암호화 키 스케줄
블루투스® 암호화 키 스케줄(EKS)은 블루투스® LE 연결에서 사용되는 암호화 키를 설정하고 관리하기 위한 새로운 프레임워크를 도입합니다. EKS는 장기 키(LTK)에서 직접 암호화 자료를 도출하는 대신, ECDH 기반 키 설정과 CMAC 기반 키 도출 계층 구조를 결합하여 세션별 암호화 자료를 생성합니다. 이 아키텍처를 통해 기기는 암호화 키를 갱신하고, 서로 다른 전송 유형에 대해 별도의 보안 컨텍스트를 유지하며, 강화된 메시지 무결성 코드(MIC) 보호 기능을 지원할 수 있습니다. EKS는 블루투스® HDT( 고속 데이터 처리량 )의 보안 기반 역할을 하는 동시에, 추가적인 블루투스 사용 사례를 지원할 수 있는 독립적인 블루투스 기능 로 정의됩니다.
2.4 블루투스® 일시적 애플리케이션 키
블루투스® 일시적 애플리케이션 키(TAK)는 페어링이나 본딩에 의존하지 않고도 암호화를 가능하게 함으로써, 블루투스® LE 연결을 보호하는 새로운 방식을 도입합니다. 이 모델에서는 상위 계층 애플리케이션이 인증 및 키 설정을 처리하며, 이 애플리케이션은 보안 강도가 128비트인 공유 비밀 키를 설정하여 블루투스 호스트에 제공합니다. 그런 다음 TAK를 사용하여 ‘암호화된 데이터 전송( 링크 Layer )’ 암호화를 설정함으로써, 기기들이 장기적인 신뢰 관계를 형성하지 않고도 안전한 연결을 구축할 수 있게 합니다. 호스트는 암호화 시작 절차를 시작한 후 TAK을 폐기하는 반면, 상위 계층 애플리케이션은 자신이 보유한 키 사본을 어떻게 관리할지 결정합니다.
2.5 블루투스® 암호화 제품 디버깅
블루투스® 암호화 확장 프로파일( 제품 ) 디버깅(EPD)은 블루투스® 호스트가 암호화된 연결에서 사용되는 활성 암호화 자격 증명을 수신할 수 있도록 하는 표준화된 메커니즘을 도입합니다. EPD는 승인된 디버깅 도구가 컨트롤러가 생성하고 관리하는 자격 증명을 확인할 수 있도록 함으로써, 블루투스 암호화가 기존의 장기 키 기반 운영 방식을 넘어 발전해 나가는 과정에서 프로토콜 분석 및 상호 운용성 디버깅 기능을 유지하는 데 기여합니다.
3. 블루투스® HDT( 고속 데이터 처리량 )
블루투스® 고해상도 전송( 고속 데이터 처리량 , HDT)은 무선 효율성과 안정성을 향상시키면서 블루투스 최대 비트 전송률을 7.5 Mbps로 높이는 새로운 블루투스® LE 물리 계층을 도입합니다. 고차 변조, 컨볼루션 전방 오류 정정, 동기화 개선, 적응형 전송률 선택 및 향상된 패킷 아키텍처를 결합한 HDT를 통해 블루투스 기기는 더 많은 양의 데이터를 보다 효율적이고 안정적으로 전송할 수 있습니다. 기능 는 기존 Bluetooth® LE 아키텍처와의 통합을 유지하면서, 고해상도 및 무손실 오디오 스트리밍을 포함한 향후 더 높은 데이터 전송 속도를 요구하는 Bluetooth 애플리케이션을 위한 확장 가능한 기반을 제공합니다.
3.1 배경
3.1.1 블루투스® LE 처리량의 발전
블루투스 LE는 다양한 성능 목표를 달성하기 위해 설계된 새로운 물리 계층의 도입을 통해 발전해 왔습니다. 초기 LE 1M PHY에 이어, 블루투스 기술은 처리량을 높이기 위해 1.5M PHY( LE 2M )를, 까다로운 무선 환경에서 통신 거리와 안정성을 개선하기 위해 2.4M PHY( LE 코디드 )를 도입했습니다. 이러한 개선 사항을 통해 상호 운용성과 전력 효율성을 유지하면서도 다양한 애플리케이션에 걸쳐 블루투스® LE의 활용 범위가 확대되었습니다.
그러나 블루투스 LE가 지속적으로 발전해 왔음에도 불구하고, 지원되는 최대 비트 전송률은 여전히 2 Mbps로 제한되어 있습니다. 블루투스 기기들이 점점 더 많은 양의 데이터를 주고받고, 더 높은 성능을 요구하는 애플리케이션을 지원함에 따라, 더 높은 처리량에 대한 필요성도 계속해서 증가하고 있습니다.
3.1.2 기존 Bluetooth® LE PHY의 한계
전송 속도를 2 Mbps 이상으로 높이는 것은 더 근본적인 과제를 안고 있습니다. 블루투스 LE는 전 세계적으로 사용 가능한 2.4 GHz ISM 대역의 제약 조건 내에서 작동하며, 이 대역에서는 주파수 가용성, 규제 요건, 구현의 복잡성, 전력 효율성 등을 모두 신중하게 균형 있게 고려해야 합니다.
기존 블루투스 LE 물리 계층은 가우시안 주파수 변조(GFSK)를 기반으로 하며, 이 변조 방식은 단순성, 견고성, 낮은 구현 복잡성 덕분에 블루투스 기술의 성공에 크게 기여해 왔습니다. 그러나 이러한 특성들 때문에 기존 방식으로는 처리량을 높일 수 있는 한계가 있습니다.
3.2 기술 개요
3.2.1 HDT 아키텍처
블루투스® HDT( 고속 데이터 처리량 )는 블루투스® LE 아키텍처 내에 완벽하게 통합된 상태를 유지하면서도, 훨씬 더 높은 스펙트럼 효율을 위해 최적화된 새로운 블루투스® LE 물리 계층을 도입함으로써 이러한 한계를 해결합니다. HDT는 별도의 무선 기술을 도입하는 대신, 기존의 블루투스® LE 프레임워크를 기반으로 하여 훨씬 더 높은 처리량을 지원하도록 설계된 새로운 기능을 추가함으로써 이를 확장합니다.
물리 계층에서 HDT는 기존 블루투스 채널 구조 내에서 훨씬 더 높은 데이터 전송 속도를 가능하게 하는 새로운 변조 및 부호화 기술을 도입합니다. 이러한 기능을 지원하기 위해 HDT는 패킷 형식, 링크 Layer 절차, 보안 메커니즘 및 호스트 컨트롤러 인터페이스(HCI) 기능에 대한 개선 사항도 도입합니다. 이러한 개선 사항들이 종합적으로 작용하여, 블루투스 기기는 블루투스 기술에 기대되는 상호 운용성과 신뢰성을 유지하면서 더 많은 데이터를 더 효율적으로 전송할 수 있게 됩니다.
그림 3.2.1은 블루투스 LE 프로토콜 스택 를 설명하고, HDT를 지원하기 위해 개선된 주요 프로토콜 계층을 강조하고 있다. HDT는 상당한 새로운 기능을 도입하고 있지만, 여전히 블루투스 LE 아키텍처 내에 완전히 통합되어 있으며, 기존 블루투스 LE 장치와 동일한 2.4 GHz ISM 주파수 대역에서 계속 작동한다.
다음 섹션에서는 HDT PHY를 시작으로 패킷 아키텍처, 링크 Layer 개선 사항, 보안 프레임워크에 이르기까지, 이러한 아키텍처 개선 사항들을 각각 더 자세히 살펴보며, 이 모든 요소가 종합적으로 높은 처리량의 블루투스 통신을 가능하게 합니다.
3.2.2 HDT PHY
HDT PHY는 블루투스® 고속 데이터 처리량 의 기반이 되며, 기존의 블루투스® LE PHY보다 훨씬 더 높은 비트 전송률을 구현합니다. 이는 변조, 코딩 및 동기화 메커니즘을 개선함으로써 달성되며, 이러한 개선 사항들은 신뢰할 수 있는 무선 통신을 유지하면서 스펙트럼 효율을 종합적으로 향상시킵니다.
3.2.2.1 변조, 부호화 및 HDT 속도
기존의 블루투스® LE PHY는 가우시안 주파수 변조(GFSK)를 기반으로 하며, 여기서 각 심볼은 단일 비트의 정보를 나타냅니다. 이 방식은 뛰어난 내성과 구현의 간편성을 제공하지만, 주어진 채널 대역폭 내에서 전송할 수 있는 정보의 양을 제한 합니다. HDT는 고차 코히어런트 변조 방식과 전방 오류 정정(FEC)을 도입하여 이러한 한계를 해결함으로써, 스펙트럼 효율을 획기적으로 향상시킵니다.
HDT PHY는 모든 작동 모드에서 공통된 컨볼루션 FEC 프레임워크를 사용합니다. 다양한 HDT 전송률은 변조 효율과 부호화 효율의 조합을 통해 달성됩니다. FEC 부호화 후, 펀처링을 사용하여 부호화된 비트를 선택적으로 제거함으로써 유효 부호화율을 높이고, 처리량과 내결함성 간의 다양한 절충점을 확보할 수 있습니다.
LE HDT PHY는 2 Msym/s의 고정 심볼 속도(심볼 주기 = 0.5 μs)로 동작합니다. 유효 비트 속도는 다음 세 가지 요인에 따라 달라집니다:
- 기호 속도
- 심볼당 비트 수
- 유효 코드율
개념적으로, 유효 비트율은 다음과 같이 표현할 수 있습니다:
유효 비트 전송률 = 심볼 속도 × 심볼당 비트 수 × 유효 코드율
변조 방식은 각 전송 심볼이 몇 비트를 나타내는지 결정하는 반면, 유효 코드 속도는 FEC 인코딩 및 펀처링이 적용된 후 사용자 데이터를 전달하는 전송 비트의 비율을 반영합니다. 고차 변조 방식은 심볼당 더 많은 비트를 전달함으로써 스펙트럼 효율을 높이는 반면, 높은 코드율은 코딩 오버헤드를 줄이고 유효 데이터의 비율을 높입니다. 이러한 메커니즘이 결합되어 HDT는 표 3.2.2.1에 요약된 바와 같이 공통된 PHY 아키텍처를 유지하면서 여러 작동 속도를 지원할 수 있습니다.
| HDT 비율 | 유효 비트율 | 변조 방식 | 심볼당 비트 수 | 유효 코드율 | 재고 현황 |
|---|---|---|---|---|---|
| HDT2 | 2 Mb/s | π/4 QPSK | 2 | 1/2 | 필수 |
| HDT3 | 3 Mb/s | π/4 QPSK | 2 | 3/4 | 필수 |
| HDT4 | 4 Mb/s | 8PSK | 3 | 2/3 | 필수 |
| HDT6 | 6 Mb/s | 16QAM | 4 | 3/4 | 선택 사항 |
| HDT7.5 | 7.5 Mb/s | 16QAM | 4 | 15/16 | 선택 사항* |
*HDT7.5를 지원하려면 HDT6를 지원해야 합니다.
예를 들어, HDT2는 2 Msym/s의 심볼 속도, π/4 QPSK 변조(심볼당 2비트), 1/2의 유효 코드율을 결합하여 2 Mb/s의 유효 비트율을 달성합니다. 마찬가지로, HDT7.5는 16QAM 변조(심볼당 4비트)와 15/16의 유효 코드율을 결합하여 7.5 Mb/s의 유효 비트율을 달성합니다. 이러한 변조 효율과 코딩 효율의 유연한 조합을 통해 HDT 장치는 작동 요구 사항과 채널 조건에 따라 처리량과 내결함성을 균형 있게 조정할 수 있습니다.
필수 HDT2, HDT3 및 HDT4 전송 속도는 HDT 기능을 지원하는 기기 간의 상호 운용성을 위한 공통 기준을 마련합니다. 더 높은 전송 속도 모드는 16QAM 변조와 코딩 오버헤드 감소를 통해 처리량을 더욱 높여, 블루투스 기술이 최대 7.5 Mb/s의 비트 속도를 지원할 수 있게 합니다.
3.2.2.2 동기화 및 견고성
고차 변조 방식은 일반적으로 기존의 GFSK 기반 통신보다 더 정밀한 동기화 및 채널 추정 기능을 필요로 합니다. 더 높은 비트 속도에서도 안정적인 작동을 유지하기 위해, HDT는 수신 과정 전반에 걸쳐 패킷 획득, 채널 추정, 수신기 추적 및 주기적인 재동기화를 지원하는 여러 PHY 수준 메커니즘을 도입합니다. 표 3.2.2.2는 HDT가 도입한 주요 동기화 및 견고성 메커니즘을 요약하고 있습니다.
| 메커니즘 | 요약 |
|---|---|
| 단기 훈련 순서(STS) | • 신속한 초기 패킷 감지, 대략적인 타이밍 정렬 및 AGC 안정화를 가능하게 합니다. • 모든 HDT 패킷의 맨 처음인 프리앰블에 나타나며, 여러 번 연속으로 반복됩니다. • 패킷으로 들어가는 안정적인 진입점을 확보합니다. |
| 장시간 훈련 시퀀스(LTS) | • 정밀한 타이밍 정렬, 주파수 오프셋 추정/보정 및 초기 채널 추정을 가능하게 합니다. • HDT 패킷의 프리앰블 내 STS 뒤에도 나타나며, 여러 번 연속으로 반복됩니다. • 코히어런트 복조를 위해 수신기 를 준비합니다. |
| 가드 간격(GI) | • 훈련 시퀀스, 심볼 스트림, 변조 또는 부호화 경계 간의 전환으로 인한 과도 현상을 상쇄하기 위한 시간 버퍼 • 프리앰블 내 STS와 LTS 사이에 명시적으로 나타나며, 종결 심볼 을 통해 패킷 전체에 걸쳐 암시적으로 나타남 • 정밀한 LTS 동기화 전에 수신기 필터와 타이밍 루프가 안정화될 수 있도록 하고, 심볼 스트림 간의 원활한 전환을 보장함 |
| 종료 기호 | • 심볼 스트림 간에 명확한 경계를 설정하고, 심볼 스트림 전환 시 발생하는 과도 현상을 흡수합니다. • 패킷 내에서 독립적으로 처리되는 각 심볼 스트림의 끝 부분에 나타납니다(예: 제어 헤더 뒤, PDU 헤더 영역 뒤, 패킷 형식 1의 각 PHY 간격 뒤 등). • FEC 디코더가 다음 세그먼트/스트림이 시작되기 전에 비우기( 상태 ) 및 리셋을 수행할 수 있도록 허용합니다. • 특히 패킷 형식 1의 경우, 오류 전파를 제한하고, 부분적인 패킷 복구를 가능하게 하며, 오류가 단일 PHY 간격에 국한되었을 때 재전송 비용을 줄이는 데 중요합니다. |
| PHY 인터벌 | • 긴 페이로드를 더 작고 처리하기 쉬운 디코딩 단위로 분할할 수 있도록 합니다. • 패킷 형식 1(PF1) HDT 패킷의 페이로드 영역에만 나타납니다. • 적응형 변조 및 동적 전송률 선택을 지원합니다. |
| PHY 인터벌 트레이닝 순서(PITS) | • 패킷 중간 재훈련을 활성화하여, 여러 PHY 간격으로 분할된 페이로드의 안정적인 수신을 위해 위상 및 채널 추정치를 갱신합니다. • 패킷 형식 1(PF1) HDT 패킷의 페이로드 영역에만 나타납니다. • 높은 비트 속도로 전송되는 긴 페이로드의 경우, 패킷 전송 기간 동안 채널 상태가 변동할 수 있으므로 이 기능이 중요합니다. 지속적인 채널 추적은 페이딩, 위상 드리프트 및 다중 경로에 대한 내성을 향상시킵니다. |
이러한 메커니즘들이 결합되어 계층적인 동기화 프레임워크를 제공합니다. STS와 LTS는 초기 패킷 획득 및 채널 추정을 지원하는 반면, PHY 간격과 PITS는 장시간에 걸친 고처리량 전송 중에 주기적인 채널 추적 및 동기화 갱신을 가능하게 합니다. 종단 심볼(Terminating Symbols)은 안정적인 패킷 완료와 종단 후 동기화( 수신기 ) 및 종단 후 채널 추적(상태 ) 전환을 지원합니다.
이러한 메커니즘의 통합을 통해 HDT는 변화하는 무선 환경에서도 안정적인 통신을 유지하면서, 기존의 Bluetooth® LE PHY보다 훨씬 더 높은 처리량을 지원합니다.
3.2.3 HDT 패킷
HDT PHY는 데이터 처리량을 획기적으로 높이는 기반을 제공합니다. 하지만 이러한 비트율에서 안정적이고 효율적인 작동을 실현하려면 블루투스 패킷 아키텍처도 이에 상응하는 개선이 필요합니다. Bluetooth® HDT( 고속 데이터 처리량 )는 적응형 비트 레이트, 대용량 페이로드 전송, 선택적 재전송 및 다양한 무선 환경에서의 향상된 내구성을 지원하도록 설계된 새로운 패킷 프레임워크를 도입합니다. 기존 Bluetooth® LE 패킷과 달리, HDT 패킷은 제어 정보, 프로토콜 메타데이터 및 페이로드 데이터를 독립적으로 처리할 수 있도록 하는 추가적인 구조적 계층을 도입함으로써, 향상된 처리량 및 신뢰성 기능을 구현합니다.
3.2.3.1 HDT 패킷 구조
그림 3.2.3.1에 표시된 바와 같이, HDT 패킷 구조는 프리앰블, 제어 헤더, 선택적 PDU 헤더 영역, 선택적 페이로드 영역이라는 네 가지 주요 영역으로 구성됩니다. 프리앰블과 제어 헤더는 모든 HDT 패킷 형식에 포함되지만, PDU 헤더 영역과 페이로드 영역은 사용 중인 패킷 형식에 따라 포함 여부가 달라집니다.
대체로 보면, 각 구역은 저마다 뚜렷한 목적을 가지고 있습니다:
서문
신뢰할 수 있는 HDT 수신에 필요한 패킷 감지, 동기화, 타이밍 획득, 주파수 오프셋 보정 및 채널 추정 기능을 제공합니다. 이러한 기능에 대한 자세한 내용은 3.2.2절에서 설명합니다.
제어 헤더
패킷을 식별하고 후속 패킷의 내용을 어떻게 처리해야 할지 결정하는 데 필요한 필수 정보를 포함하고 있습니다. 이 정보를 고속 페이로드 데이터와 분리함으로써, 페이로드 복조 작업이 시작되기 전에 패킷을 안정적으로 해석할 수 있습니다.
PDU 헤더 영역
페이로드 데이터를 해석하고 관리하는 데 사용되는 프로토콜 수준의 메타데이터를 전달합니다. 이 메타데이터는 페이로드 집계, 수신 확인 처리, 선택적 재전송, 링크 품질 피드백, 흐름 제어 및 향후 프로토콜 확장성 등의 기능을 지원합니다.
화물 구역
하나 이상의 블록으로 구성된 사용자 데이터를 전달합니다. 패킷 형식 0에는 단일 블록만 포함됩니다. 패킷 형식 1에서는 효율적인 오류 복구 및 선택적 재전송을 지원하기 위해 페이로드를 논리적 블록으로 분할할 수 있습니다.
3.2.3.2 HDT 패킷 형식
다양한 블루투스 애플리케이션과 트래픽 패턴을 지원하기 위해 HDT는 세 가지 패킷 형식을 정의합니다. 각 형식은 처리량, 내결함성 및 프로토콜 오버헤드 간의 서로 다른 균형에 최적화되어 있습니다.
짧은 형식
단축 형식은 페이로드 데이터가 전송되지 않을 때 사용되는 최소한의 패킷 구조입니다. 이 형식은 주로 확인 응답, 동기화 및 제어 신호 전송을 목적으로 하며, 송신 시간 소모와 프로토콜 오버헤드를 최소화합니다. 단축 형식 패킷의 구조는 그림 3.2.3.2a에 나와 있습니다.
패킷 형식 0 (PF0)
패킷 형식 0은 오버헤드를 최소화하면서 단일 페이로드 블록을 전송하도록 최적화되어 있습니다. 이 형식은 페이로드 분할이나 고급 재전송 메커니즘이 필요하지 않은 소규모 및 중규모 데이터 전송에 적합합니다. 패킷 형식 0의 구조는 그림 3.2.3.2b에 나와 있습니다.
패킷 형식 1 (PF1)
패킷 형식 1(PF1)은 가장 성능이 뛰어난 HDT 패킷 형식으로, 최대 처리량과 대용량 페이로드 전송을 위해 설계되었습니다. PF1은 훨씬 더 대용량의 데이터 전송을 지원할 뿐만 아니라, 페이로드 집계, 블록 기반 전송, 선택적 재전송, 향상된 헤더 보호 기능, 그리고 PHY 수준의 내결함성 메커니즘을 도입했습니다. 패킷 형식 1의 구조는 그림 3.2.3.2c에 나와 있습니다.
표 3.2.3.2는 세 가지 패킷 형식에 대한 비교 및 요약을 제시합니다.
| 짧은 | PF0 | PF1 | |
|---|---|---|---|
| 최대 적재량 | N/A | 494 옥텟 | 8175 옥텟 |
| 다음과 같은 경우에 유용합니다 | 더 높은 처리량 | 최고의 처리량, 효율성 및/또는 내구성 | |
| 주요 주요 장점 | • 전송할 페이로드 데이터가 없거나, 연속된 전체 페이로드에 대해서만 확인 응답이 필요한 경우, 통신 시간을 단축합니다. | • 구현이 더 간편함 • 오버헤드가 더 낮음 • MIC가 포함된 단일 페이로드 블록 | • 패킷당 최대 4개의 페이로드 • 페이로드의 블록 단위 분할 • 선택적(블록) 확인 응답 • 페이로드 블록이 여러 패킷에 걸쳐 분산될 수 있음 • PHY 간격, PITS를 이용한 위상 추적 |
3.2.3.3 페이로드 집계 및 신뢰성
패킷 형식 1(PF1)이 도입한 주요 혁신 중 하나는 강력한 무선 성능을 유지하면서 대량의 데이터를 효율적으로 전송할 수 있는 능력입니다. 이를 달성하기 위해 PF1은 페이로드 집계, 블록 기반 전송, 선택적 재전송 및 향상된 오류 보호 메커니즘을 도입했습니다. 이러한 기능들이 종합적으로 작용하여 HDT는 패킷 손실 및 변화하는 무선 환경의 영향을 최소화하면서 처리량을 크게 향상시킬 수 있습니다. 그림 3.2.3.3은 HDT 패킷 내에서 이러한 기능을 지원하는 PDU 구성 요소를 보여줍니다.
패킷 형식 0은 단일 페이로드 블록만 전달하는 반면, 패킷 형식 1은 단일 패킷 전송 내에 최대 4개의 독립적인 페이로드를 통합할 수 있습니다. 이러한 기능을 통해 여러 페이로드를 함께 전송할 수 있게 되어 프로토콜 오버헤드를 줄이고 채널 활용도를 높일 수 있습니다.
효율성을 더욱 높이기 위해 PF1은 블록 기반 페이로드 모델을 도입합니다. 전체 페이로드를 단일 전송 단위로 취급하는 대신, 각 페이로드를 1개에서 16개 사이의 논리 블록으로 나눌 수 있습니다. 이러한 블록들은 독립적으로 정의, 전송 및 추적될 수 있어 대용량 페이로드를 보다 효율적으로 관리할 수 있습니다.
블록 기반 전송은 선택적 재전송을 가능하게 합니다. 추가적인 패킷 메타데이터를 통해 패킷 수신자( 송신기 )와 패킷 발신자( 수신기 )는 어떤 페이로드 블록이 성공적으로 수신되었는지, 어떤 블록이 재전송이 필요한지 판단할 수 있습니다. 전송 오류가 발생할 경우, 오류가 발생한 블록만 재전송하면 되며, 정상적으로 수신된 블록은 그대로 유지할 수 있습니다. 이러한 방식은 전체 페이로드를 재전송하는 것에 비해 재전송 오버헤드를 크게 줄여줍니다.
또한 PF1은 추가적인 보호 메커니즘을 통해 신뢰성을 높입니다. 전송되는 각 블록에는 독립적인 무결성 검사 기능이 포함되어 있어, 전체 페이로드를 검증할 필요 없이 개별 블록을 확인할 수 있습니다. 또한, 패킷 형식 1(PF1)은 PDU 헤더 영역에 대한 헤더 오류 검사(HEC-P)를 통해 프로토콜 메타데이터에 대한 전용 보호 기능을 제공함으로써, 페이로드 관리 정보의 신뢰할 수 있는 해석을 보장합니다.
이 패킷 아키텍처는 또한 선택적 프로토콜 메타데이터를 통해 고급 링크 관리 기능을 지원합니다. 신호 강도, 신호 대 잡음비(SNR), 권장 전송 속도 등의 지표를 포함한 링크 품질 정보를 교환함으로써 현재 채널 상태에 대한 가시성을 높일 수 있습니다. 또한 이 아키텍처는 흐름 제어 신호를 지원하여, 버퍼링 또는 처리 자원이 부족해질 때 장치가 페이로드 전송 동작을 동적으로 관리할 수 있도록 합니다.
마지막으로, PF1은 3.2.2절에서 설명한 PHY 간격(PHY Intervals) 및 PHY 간격 훈련 시퀀스(PITS)와 같은 PHY 수준 메커니즘과 함께 작동하도록 설계되었습니다. 이러한 메커니즘은 장시간 전송 중에 주기적인 PHY 간격 동기화( 수신기 ) 재동기화를 가능하게 하며, 페이딩, 위상 드리프트 및 기타 시간 변화형 채널 조건 하에서도 안정적인 통신을 유지하는 데 도움을 줍니다.
페이로드 집계, 논리 블록, 선택적 재전송, 강화된 메타데이터 보호 및 PHY 계층 수준의 내결함성 메커니즘을 결합함으로써, 패킷 형식 1은 효율적이고 신뢰할 수 있는 고대역폭 블루투스 통신을 위한 기반을 마련합니다.
3.2.4 블루투스® HDT 링크 Layer
HDT PHY 및 패킷 아키텍처는 훨씬 더 높은 처리량을 위한 기반을 제공하지만, 이러한 비트 레이트에서 안정적인 작동을 실현하기 위해서는 블루투스® LE 링크 Layer 에 대한 상응하는 개선도 필요합니다. HDT는 별도의 프로토콜 아키텍처를 도입하는 대신, 기존의 블루투스® LE 링크 Layer 에 새로운 절차, 기능 및 제어 메커니즘을 추가함으로써, 확립된 블루투스® LE 프레임워크 내에서 고처리량 통신이 작동할 수 있도록 합니다.
이러한 개선 사항들은 종합적으로 HDT 기능 협상, PHY 관리, 페이로드 전송, 전송 속도 조정, 보안, 신뢰성 및 등시성 통신을 지원합니다. HDT 애플리케이션 프레임워크( 링크 Layer )는 HDT PHY의 잠재적 처리량을 효율성, 견고성 및 애플리케이션 성능의 실질적인 향상으로 전환하는 운영 프레임워크를 제공합니다.
표 3.2.4는 HDT 지원을 위해 도입된 주요 ‘ 링크 Layer ’ 기능 영역을 요약하고 있다.
| 역량 | 묘사 |
|---|---|
| HDT 개시 및 PHY 관리 | HDT 활성화, 기능 협상 및 GFSK와 HDT 작동 모드 간의 전환을 지원합니다. |
| HDT 데이터 길이 관리 및 스케줄링 | 블루투스® LE의 타이밍 및 스케줄링 요구 사항을 준수하면서도 더 큰 페이로드를 지원합니다. |
| HDT 링크 품질 | 동적인 링크 품질 보고 및 적응 기능을 제공합니다. |
| HDT 및 동기 채널 | HDT 운영을 위한 CIS 및 BIS 전송 지원 확대 |
| HDT 보안 및 암호화 | EKS 통합, 더 긴 MIC, 그리고 조정된 키 관리 기능을 제공합니다. |
| HDT 신뢰성 및 유량 제어 | 블록 수준의 신뢰성 메커니즘 및 향상된 흐름 제어를 지원합니다. |
다음 섹션에서는 이러한 절차를 통해 구현되는 ‘ 링크 Layer ’의 주요 기능에 대한 개요를 간략히 설명합니다.
3.2.4.1 블루투스® HDT 초기화 및 PHY 관리
Bluetooth® HDT는 Bluetooth® LE 연결을 통해 실행되는 링크 Layer 절차를 통해 시작 및 관리됩니다. 기기 간에 HDT 기능이 설정되면, HDT 작동은 ACL 연결, 연결된 등시 스트림(CIS) 및 브로드캐스트 등시 스트림(BIS)에 사용될 수 있습니다. HDT PHY는 광고(advertising) 용도로 사용되지 않으며, 반드시 전용 링크 Layer 절차를 통해 활성화되어야 합니다.
이 프로세스는 새로운 LL_HDT_CONFIG_REQ 및 LL_HDT_CONFIG_RSP 제어 PDU를 사용하는 HDT 구성 교환 절차로 시작됩니다. 이 절차를 통해 장치들은 지원되는 HDT 속도, 페이로드 윈도우 기능, 보안 관련 매개변수 및 HDT 작동을 설정하는 데 필요한 기타 정보를 포함하여 HDT 관련 기능과 작동 매개변수를 교환합니다.
장치들은 단일 운영 속도를 협상하기보다는 지원되는 HDT 속도의 범위를 설정합니다. 작동 중 컨트롤러는 현재 채널 상태, 구현 정책 및 애플리케이션 요구 사항에 따라 협상된 범위 내의 임의의 속도를 동적으로 선택할 수 있습니다. 이러한 적응형 속도 모델을 통해 추가적인 연결 재구성 없이도 처리량과 내구성의 균형을 맞출 수 있습니다.
기능 정보가 교환된 후, 기기는 기존 LL_PHY_REQ, LL_PHY_RSP 및 LL_PHY_UPDATE_IND 제어 PDU를 확장한 ‘PHY 업데이트 및 암호화 갱신’ 절차를 사용하여 GFSK PHY와 HDT PHY 간을 전환할 수 있습니다. 이를 통해 HDT 기능을 지원하는 기기는 활성 Bluetooth® LE 연결을 유지한 상태에서 HDT 작동 모드로 동적으로 진입하거나, 해당 모드를 수정하거나, 또는 종료할 수 있습니다.
GFSK PHY에서 HDT 작동 방식으로 전환하려면 HDT 전용 물리 채널 주소 지정 정보도 설정해야 합니다. 이 과정에서 장치들은 물리 채널에서 HDT 트래픽을 고유하게 식별하는 물리 채널 주소(PCA) 정보를 교환합니다. PCA는 기존 Bluetooth® LE 연결 아키텍처와의 연동을 유지하면서 패킷 필터링, 동기화 및 HDT 전송 수신을 지원합니다.
정상 작동 시, 연결의 양방향 모두 GFSK PHY 또는 HDT PHY를 사용합니다. 그러나 HDT 전송 속도는 각 방향별로 독립적으로 선택할 수 있으므로, 변화하는 채널 상태와 애플리케이션 요구 사항에 따라 처리량을 동적으로 조정할 수 있습니다. HDT 작동이 불가능하거나 더 이상 적합하지 않은 경우, 기존의 블루투스 LE PHY를 사용하여 통신을 계속할 수 있습니다.
3.2.4.2 Bluetooth® HDT 데이터 길이 관리 및 스케줄링
블루투스 HDT는 기존 블루투스® LE 작동에서 사용되는 것보다 훨씬 더 큰 페이로드를 지원하면서도, 블루투스 연결 및 등시성 스트림에 필요한 타이밍 특성을 유지하기 위해 향상된 데이터 길이 관리 기능을 도입합니다.
이를 위해 블루투스 저에너지( 링크 Layer )는 HDT 및 GFSK 동작에 대해 각각 별도의 전송 길이 및 타이밍 매개변수를 유지합니다. 이를 통해 각 PHY 계열은 각각의 페이로드 및 에어타임 제약 조건에 따라 작동할 수 있으며, 동시에 HDT와 기존 블루투스 LE 모드 간의 원활한 전환을 지원합니다.
또한 HDT는 단일 HDT 전송 내에서 여러 페이로드를 통합할 수 있게 해주는 페이로드 윈도우 관리 기능을 도입합니다. HDT 구성 절차를 통해, 장치들은 페이로드 데이터가 어떻게 그룹화되고 전송될 수 있는지를 정의하는 페이로드 윈도우 기능을 서로 교환합니다. 이러한 기능들은 3.2.3절에서 설명한 페이로드 통합 및 블록 기반 전송 메커니즘과 연동되어 채널 활용도와 전송 효율을 향상시킵니다.
HDT 패킷은 기존 블루투스 LE 패킷보다 훨씬 더 많은 양의 데이터를 전달할 수 있기 때문에, 패킷의 송신 시간을 제한하고 ACL 연결, CIS, BIS 및 기타 동시 블루투스 활동과의 공존을 유지하기 위해 추가적인 스케줄링 제약 조건이 도입되었습니다. 이러한 스케줄링 메커니즘을 통해 예측 가능한 블루투스 LE 타이밍 동작을 저해하지 않으면서 더 높은 처리량을 달성할 수 있습니다.
LL_LENGTH_REQ [v2] 및 LL_LENGTH_RSP [v2]를 사용하는 향상된 데이터 길이 업데이트 절차( Data Length Update )를 통해, 장치는 최대 송신 및 수신 페이로드 길이와 관련 타이밍 매개변수를 함께 통신할 수 있습니다. HDT는 PHY별 데이터 길이 요청( 제한)을 유지함으로써, 컨트롤러가 연결 이벤트 스케줄링, 아이소크로너스 작동 및 멀티링크 활동과의 호환성을 유지하면서 처리량을 극대화할 수 있도록 합니다.
3.2.4.3 블루투스® HDT 연결 품질
HDT는 작동 중 채널 상태에 대한 실시간 정보를 기기 간에 교환할 수 있게 해주는 선택적 링크 품질 피드백(LQF) 기능을 도입합니다. 이 기능이 활성화되면 기기 간에 링크 품질 정보가 지속적으로 보고되어, 컨트롤러가 현재 무선 상태를 더욱 명확하게 파악할 수 있게 됩니다.
이러한 보고서에는 신호 품질 측정값과 함께 권장 작동 속도가 포함될 수 있으며, 이를 통해 제어기는 보다 정확한 정보를 바탕으로 적응 결정을 내릴 수 있습니다. 구현 정책 및 측정된 채널 상태에 따라, 제어기는 HDT 작동 속도를 조정하거나, 전송 방식을 변경하거나, HDT와 GFSK 작동 모드 간을 전환할 수 있습니다.
HDT 링크 품질 활성화 절차는 새로운 LL_HDT_LQF_REPORTING_IND 제어 PDU를 사용하여 링크 품질 피드백(LQF) 보고를 활성화하거나 비활성화합니다. LQF는 ACL 및 CIS 전송에 대해 독립적으로 구성할 수 있으므로, 적절한 경우 서로 다른 트래픽 유형이 채널 품질 정보를 활용할 수 있습니다.
LQF는 현재 채널 상태에 대한 직접적인 가시성을 제공함으로써, 적응형 전송 속도 운영 방식을 보다 효율적으로 활용할 수 있도록 지원하며, 다양한 무선 환경에서 HDT의 성능 이점을 극대화하는 데 기여합니다.
3.2.4.4 블루투스® HDT의 신뢰성 및 흐름 제어
HDT는 대용량 페이로드 전송을 효율적으로 지원하기 위해 설계된 향상된 신뢰성 메커니즘을 도입합니다. HDT는 패킷 형식 1(PF1)의 블록 기반 페이로드 아키텍처를 기반으로 하여, 기존의 Bluetooth® LE 확인 응답 동작에 블록 단위 복구 메커니즘을 보완합니다.
기존의 블루투스 LE 시퀀스 번호 지정 및 확인 응답 절차는 여전히 패킷 순서 지정 및 누적 확인 응답 기능을 제공합니다. HDT는 페이로드 블록에 대한 선택적 확인 응답을 통해 이 모델을 확장합니다. 이를 통해 대량의 데이터를 전송할 때 재전송 오버헤드를 크게 줄일 수 있습니다.
HDT는 또한 향상된 흐름 제어 기능을 도입합니다. HDT 패킷 헤더에 포함된 정보를 통해, 수신 장치는 추가적인 버퍼링이나 처리 리소스가 필요할 때 새로운 페이로드 데이터의 전송을 일시적으로 중단할 수 있습니다. 이 기간 동안 재전송 작업은 계속될 수 있으므로, 신뢰성 확보 절차를 진행하면서도 수신기 의 과부하를 방지할 수 있습니다.
리소스가 확보되면, 상위 계층의 개입이나 연결 재구성 없이도 정상적인 페이로드 전송이 재개됩니다. 이러한 메커니즘들이 종합적으로 작용하여 효율성을 높이고 신뢰성을 유지하며, HDT가 까다로운 운영 환경에서도 높은 처리량을 유지할 수 있도록 돕습니다.
3.2.4.5 대표적인 Bluetooth® HDT 링크 Layer 절차 및 제어 메시지
위에서 설명한 HDT( 링크 Layer ) 기능은 새로 추가되거나 개선된 일련의 절차와 제어 메시지를 통해 구현됩니다. 표 3.2.4.5에는 HDT의 설정, 관리, 보안 유지 및 최적화에 사용되는 대표적인 링크 Layer 절차와 관련 LL 제어 PDU가 요약되어 있습니다.
| 절차 | 주요 기능 | 대표적인 LL 제어 PDU |
|---|---|---|
| HDT 구성 교환 | 페이로드 창, 전송 속도 지원 범위, ACL/CIS HDT 매개변수 | LL_HDT_CONFIG_REQ / LL_HDT_CONFIG_RSP |
| HDT 링크 품질 활성화 | ACL/CIS 피드백 보고 | LL_HDT_LQF_REPORTING_IND |
| 키 스케줄을 이용한 암호화 시작 | EKS 구축 | LL_ENC_ECDH_REQ / LL_ENC_ECDH_RSP |
| 데이터 길이 업데이트 | PHY별 페이로드 및 송신 시간 제한 | LL_LENGTH_REQ [v2] / LL_LENGTH_RSP [v2] |
| PHY 업데이트 및 암호화 갱신 | PHY 전환, PCA 할당, MIC 업데이트, 키 갱신 | LL_PHY_REQ [v2], LL_PHY_RSP [v2], LL_PHY_UPDATE_IND [v2] |
| 연결된 등시성 스트림 생성 | HDT 지원 CIS 구축 | LL_CIS_REQ [v2], LL_CIS_IND [v2] |
이러한 절차들은 종합적으로, 기존 블루투스 LE 링크 Layer 아키텍처와의 호환성을 유지하면서 HDT의 작동을 활성화, 관리, 보안 및 최적화하는 데 필요한 신호 전달 프레임워크를 제공합니다. 또한 이 절차들은 HDT가 기존 블루투스 LE 절차를 대체하기보다는 이를 확장함으로써, 아키텍처의 일관성과 상호 운용성을 유지하면서 더 높은 처리량을 블루투스 생태계에 통합할 수 있는 방법을 보여줍니다.
3.2.5 블루투스® HDT HCI 계층
호스트 컨트롤러 인터페이스(HCI)는 호스트와 컨트롤러 간의 주요 제어 및 상태 인터페이스를 제공합니다. HDT 작동을 지원하기 위해 Bluetooth® LE는 새로운 HCI 명령어와 이벤트를 도입하는 한편, 여러 기존 메커니즘을 확장합니다. 이러한 개선 사항을 통해 호스트는 HDT 기능을 탐색하고, 작동 설정을 구성하며, PHY 전환을 모니터링하고, 보안 기능을 관리하며, HDT 지원 등시 전송을 제어할 수 있습니다.
블루투스 아키텍처에 따라, 대부분의 HDT 전용 기능은 컨트롤러 내에 남아 있습니다. PHY 전환, 전송 속도 조정, 재전송 처리, 패킷 스케줄링과 같은 타이밍이 중요한 기능은 계속해서 컨트롤러가 자율적으로 수행하는 반면, HCI는 정책 구성, 진단 및 애플리케이션 인식에 필요한 정보와 제어 기능을 제공합니다. 이를 통해 호스트의 의사 결정과 컨트롤러의 실행 간에 기존에 유지되어 온 분리를 보존하는 동시에, 애플리케이션이 HDT 기능의 이점을 누릴 수 있게 합니다.
HDT에 필요한 HCI 개선 사항은 기능 탐색 및 구성, PHY 관리, 처리량 관리, 보안 관리, 등시 전송 관리, 테스트 및 진단 등 6가지 범주로 분류할 수 있다. 표 3.2.5는 HDT 지원과 관련된 주요 HCI 기능 영역을 요약하고 있다.
| 역량 | 묘사 |
|---|---|
| 기능 탐색 및 구성 | HDT의 기능을 살펴보고 운영 설정을 구성하세요 |
| PHY 선정 및 전환 조정 | HDT PHY 작동 요청 및 모니터링 |
| 데이터 길이 및 처리량 관리 | 제한 및 처리량 관련 매개변수 구성 |
| 보안 및 암호화 관리 | EKS 관련 기능을 관리하고 암호화를 모니터링합니다. 상태 |
| 등시적 전송 관리 | HDT가 활성화된 CIS 및 BIS 전송 구성 및 모니터링 |
| 테스트 및 진단 | 검증, 디버깅 및 링크 품질 분석 지원 |
다음 섹션에서는 HDT 지원을 위해 도입된 주요 HCI 기능에 대한 개요를 간략히 설명합니다.
3.2.5.1 기능 탐색 및 구성
Bluetooth® HDT를 사용하기 전에, 호스트는 로컬 및 원격 컨트롤러가 지원하는 기능을 파악하고 향후 연결에 적용될 운영 기본 설정을 구성해야 합니다. HDT를 지원하는 컨트롤러는 지원되는 PHY 모드, HDT 전송 속도, 최대 페이로드 크기, 타이밍 제약 조건 및 HDT 관련 보안 기능에 대한 정보를 제공합니다. 이 정보를 통해 애플리케이션은 특정 사용 사례에 HDT 작동이 적합한지 판단하고 적절한 운영 정책을 수립할 수 있습니다.
또한 HCI를 통해 호스트는 HDT의 기본 작동 설정을 지정할 수 있습니다. 이러한 설정에는 선호하는 HDT 속도, 지원되는 패킷 형식, 페이로드 윈도우 기능 및 보안 관련 매개변수 등이 포함될 수 있습니다. 대표적인 인터페이스로는 ‘LE Set HDT Default Parameters’ 명령과 ‘LE Read Maximum Data Length’와 같은 향상된 기능 보고 절차가 있습니다.
호스트는 패킷 수준의 작동을 직접 제어하기보다는, 선호하는 작동 방식을 명시하고 실시간 의사 결정은 컨트롤러에 맡깁니다. 예를 들어, 호스트는 ACL 및 등시성 전송에 대해 선호하는 HDT 속도 범위를 지정하거나 특정 패킷 형식을 선호한다고 명시할 수 있습니다. 실제 작동 중에는 컨트롤러가 속도 조정, 패킷 스케줄링 및 기타 시간 민감형 의사 결정을 계속 담당합니다. 이러한 접근 방식은 유연성을 제공하면서도, 호스트가 링크 Layer 의 실행에 불필요하게 개입하는 것을 방지합니다.
3.2.5.2 PHY 선택 및 전환 조정
PHY 선택 및 PHY 전환은 HCI 계층에서 블루투스® HDT 작동의 가장 눈에 띄는 측면 중 하나입니다. 호스트는 기존의 PHY 선택 메커니즘을 통해 HDT PHY에서의 작동을 지원하거나 이를 선호한다는 의사를 표시할 수 있습니다. 이러한 요청은 원하는 작동 방식을 전달하는 역할을 하며, HDT 작동이 성공적으로 설정될 수 있는지 여부를 판단하는 책임은 여전히 컨트롤러에 있습니다.
PHY 전환이 발생하면(HDT 작동 모드로 진입하거나 이 모드를 종료할 때), 컨트롤러는 HCI 이벤트를 통해 그 결과를 보고합니다. 이러한 알림을 통해 호스트는 ‘ 링크 Layer ’ 실행에 대한 세부적인 정보를 알 필요 없이 활성 PHY 선택을 모니터링하고, 애플리케이션 동작을 조정하며, 처리량 관련 기대치를 관리할 수 있습니다. 대표적인 인터페이스로는 LE Set PHY 명령어와 향상된 LE PHY Update Complete 이벤트가 있으며, 이를 통해 PHY 전환 후의 작동 모드를 파악할 수 있습니다.
HDT 속도 선택은 여전히 컨트롤러가 제어하므로, HCI 보고는 데이터 링크 계층( 링크 Layer)에서 수행되는 패킷별 결정보다는 PHY 선택 및 작동 결과에 중점을 둡니다. 이를 통해 호스트 정책과 컨트롤러 실행 간의 전통적인 구분이 유지됩니다.
3.2.5.3 데이터 길이 및 처리량 관리
Bluetooth® HDT를 통해 가능해진 더 큰 페이로드와 더 높은 처리량에 대응하기 위해서는 HCI 수준의 구성 및 모니터링 기능도 이에 상응하게 강화되어야 합니다. 호스트는 구현상의 공존 및 타이밍 제약 조건을 준수하면서 처리량을 최적화하기 위해 페이로드 관련 작동 매개변수를 구성하고 컨트롤러의 기능을 조회할 수 있습니다.
기존의 페이로드 길이 정보 외에도, HDT 기능 보고를 통해 페이로드 윈도우 기능, 최대 수신 패킷 용량 및 기타 처리량 관련 운영 매개변수가 제공됩니다. 이러한 기능을 통해 컨트롤러의 잠재적 처리량을 보다 명확하게 파악할 수 있으며, 애플리케이션이 고대역폭 데이터 전송을 위해 버퍼링, 스케줄링 및 자원 할당에 관한 정보에 기반한 의사결정을 내리는 데 도움이 됩니다.
HDT는 정책 결정과 링크 Layer 의 실행을 계속해서 분리하고 있습니다. 호스트는 선호하는 운영 제한 를 구성하고 협상된 기능을 모니터링할 수 있는 반면, 컨트롤러는 활성 운영 중 패킷 집계, 페이로드 분할, 재전송 관리 및 스케줄링 결정에 대한 책임을 계속 지게 됩니다. 이러한 접근 방식을 통해 애플리케이션은 호스트 수준에서 프로토콜의 복잡성을 추가로 증가시키지 않으면서도 더 큰 페이로드와 더 높은 처리량의 이점을 누릴 수 있습니다.
협상된 페이로드 용량에 대한 변경 사항은 향상된 LE 데이터 길이 변경(LE Data Length Change ) 이벤트를 통해 보고될 수 있으며, 이를 통해 호스트는 활성 연결의 유효한 운영 데이터 길이( 제한 )를 지속적으로 파악할 수 있습니다. LE 데이터 길이 설정(LE Set Data Length ) 및 LE 최대 데이터 길이 읽기(LE Read Maximum Data Length)와 함께, 이러한 인터페이스들은 HDT 지원 시스템에서 처리량 관리를 위한 주요 HCI 프레임워크를 제공합니다.
3.2.5.4 보안 및 암호화 관리
3.2.6절에서 설명한 Bluetooth® HDT 보안 강화 기능은 일련의 HCI 제어 및 상태 메커니즘을 통해 제공되며, 이를 통해 호스트는 기존 Bluetooth® LE 보안 아키텍처와의 호환성을 유지하면서 암호화 키 스케줄(EKS) 관련 기능을 구성하고 모니터링할 수 있습니다.
대표적인 인터페이스로는 LE 읽기 암호화 키 스케줄 디버그 모드 및 LE 쓰기 암호화 키 스케줄 디버그 모드 명령어가 있습니다. 이러한 명령어는 주로 개발, 테스트 및 상호 운용성 검증 환경을 위해 고안되었으며, 활성화된 암호화 세션의 보안 상태 을 수정하기보다는 이후의 연결에 적용됩니다.
추가된 HCI 개선 사항을 통해 MIC 길이 선택, EKS 사용 현황 및 암호화 갱신 절차에 대한 가시성을 확보할 수 있습니다. ‘LE Enable Encryption [v2] ’ 및 ‘Refresh Encryption Key [v2]’와 같은 명령어와 ‘Encryption Change [v3] ’ 및 ‘Encryption 키 갱신 Complete [v2]’와 같은 이벤트를 통해 호스트는 HDT 운영과 관련된 보안 관련 ‘ 상태 ’ 상태 전환을 모니터링할 수 있습니다.
이러한 인터페이스를 통해 애플리케이션은 기본이 되는 링크 Layer 보안 절차에 직접 관여하지 않고도 보안 상태 및 구성 변경 사항을 지속적으로 파악할 수 있습니다. 다른 HDT 기능과 마찬가지로, 컨트롤러는 시간에 민감한 보안 작업을 계속 관리하는 한편, 호스트는 해당 작업의 결과와 운영 상태 에 대한 가시성을 유지합니다.
3.2.5.5 등시 전송 관리
Bluetooth® HDT는 Bluetooth LE 등시성 통신을 확장하므로, 연결된 등시성 그룹(CIG), 연결된 등시성 스트림(CIS) 및 브로드캐스트 등시성 스트림(BIS)에 대한 해당 HCI 지원이 필요합니다. 관련 HCI 인터페이스를 통해 호스트는 기존 Bluetooth LE 등시성 관리 모델을 유지하면서 HDT 지원 전송 계층을 구성할 수 있습니다.
이러한 인터페이스는 HDT 속도, 패킷 형식 선택, 페이로드 기능, MIC 길이 구성 등 HDT 고유의 작동 설정을 지원합니다. 이러한 메커니즘을 통해 애플리케이션은 기존 블루투스 LE 절차와의 호환성을 유지하면서 전송 동작을 처리량, 지연 시간, 신뢰성 및 보안 요구 사항에 맞출 수 있습니다. 대표적인 구성 인터페이스로는 LE Set CIG Parameters [v2] 및 LE Create BIG [v2]가 있습니다.
전송 설정 절차가 완료되면, 컨트롤러는 향상된 상태 이벤트를 통해 그 결과로 도출된 운영 특성을 보고합니다. LE CIS Established [v3] 및 LE Create BIG Complete [v2] 와 같은 인터페이스는 HDT가 활성화된 전송 생성 과정을 가시화하며, 호스트가 구성 결과를 확인하고 이에 따라 애플리케이션 동작을 조정할 수 있도록 합니다.
HDT는 완전히 새로운 제어 모델을 도입하기보다는 기존의 등시성 관리 메커니즘을 확장함으로써, 블루투스 개발자들에게 이미 익숙한 운영 프레임워크를 유지하면서도 애플리케이션이 훨씬 더 높은 처리량을 활용할 수 있도록 합니다.
3.2.5.6 테스트 및 진단
블루투스® HDT는 운영 제어 기능 외에도, 검증, 성능 측정, 상호운용성 분석 및 구현 디버깅을 지원하기 위한 HCI 기능을 도입했습니다. 이러한 기능을 통해 HDT 고유의 작동 특성을 파악할 수 있으며, 다양한 무선 환경 및 트래픽 패턴에서 컨트롤러 성능을 보다 쉽게 평가할 수 있습니다.
테스트 및 진단 인터페이스를 통해 컨트롤러를 HDT 전용 테스트 매개변수로 구성할 수 있으며, HDT 링크 품질 및 PHY 작동과 관련된 정보를 포함하여 수집된 측정값에 대한 보고 기능을 제공합니다. 이러한 기능은 HDT( 제품 ) 개발, 인증 테스트, 성능 특성 분석 및 다양한 구현 간 상호운용성 검증을 지원합니다.
이 기능과 관련된 대표적인 인터페이스로는 ‘LE Set HDT Parameters Test’ 명령어와 ‘LE Test Report HDT Link Quality’ 이벤트가 있습니다. 이러한 메커니즘을 통해 개발자와 테스트 엔지니어는 HDT 구현을 평가하고 최적화하는 데 필요한 정보를 활용할 수 있습니다.
3.2.5.7 대표적인 Bluetooth® HDT HCI 명령 및 이벤트
위에서 설명한 HCI 개선 사항은 새로운 명령어와 확장된 명령어, 그리고 이벤트를 조합하여 구현됩니다. 표 3.2.5.7은 각 HDT 기능 영역과 관련된 대표적인 인터페이스를 요약하고, 호스트가 HDT 지원 컨트롤러와 어떻게 상호작용하는지를 보여줍니다.
| 역량 | 대표적인 명령어 및 이벤트 |
|---|---|
| 기능 탐색 및 구성 | LE, HDT 기본 매개변수 설정, LE, 최대 데이터 길이 읽기 |
| PHY 선정 및 전환 조정 | LE Set PHY, LE PHY 업데이트 완료 |
| 데이터 길이 및 처리량 관리 | LE 데이터 길이 설정, LE 데이터 길이 변경 |
| 보안 및 암호화 관리 | LE 암호화 활성화 [v2], 암호화 키 갱신 [v2], 암호화 변경 [v3], 암호화 키 갱신 완료 [v2], LE 암호화 키 읽기/쓰기 일정 디버그 모드 |
| 등시적 전송 관리 | LE CIG 매개변수 설정 [v2], LE BIG 생성 [v2], LE CIS 설정 완료 [v3], LE BIG 생성 완료 [v2] |
| 테스트 및 진단 | LE HDT 매개변수 설정 테스트, LE 테스트 보고서: HDT 링크 품질 이벤트 |
이러한 명령어와 이벤트는 종합적으로 HDT 운영을 위한 호스트와 컨트롤러 간의 주요 관리 인터페이스를 제공합니다. 이를 통해 애플리케이션은 호스트 정책과 컨트롤러 실행 간의 기존 아키텍처적 분리를 유지하면서, 컨트롤러의 기능을 파악하고, 운영 설정을 구성하며, 시스템 상태를 모니터링하고, HDT가 활성화된 전송을 관리할 수 있습니다.
3.2.6 블루투스® HDT 보안
블루투스 HDT는 기존의 블루투스® LE 보안 아키텍처를 기반으로 하면서, 높은 처리량의 통신을 지원하기 위해 고안된 여러 가지 개선 사항을 도입합니다. 이러한 개선 사항은 키 관리를 강화하고, 무결성 보호 기능을 향상시키며, 보안 절차를 PHY 작동과 더욱 긴밀하게 연계합니다.
HDT는 별도의 보안 아키텍처를 정의하기보다는, 암호화 키 스케줄(EKS)을 도입하고, 더 긴 메시지 무결성 검사(MIC) 길이를 지원하며, PHY 작동과 연계된 보안 절차를 통해 기존의 블루투스 LE 보안 메커니즘을 확장합니다. 이러한 개선 사항들은 HDT에 필요한 보안 기능을 제공하는 동시에, 다른 블루투스 기능 및 사용 사례에서도 활용할 수 있는 메커니즘을 기반으로 합니다.
3.2.6.1 메시지 무결성 보호 기능 강화
기존의 Bluetooth® LE 통신은 32비트 메시지 무결성 검사(MIC)를 사용합니다. HDT는 여기에 더해 64비트 및 128비트 MIC 길이를 추가로 지원하여, 대용량 데이터를 전송할 때 패킷 변조, 위조 및 전송 오류에 대해 더욱 강력한 보호 기능을 제공합니다.
3.2.6.2 보안 고려형 PHY 전환
Bluetooth® HDT는 PHY 업데이트 및 암호화 갱신 절차를 통해 보안 관리와 PHY 작동을 더욱 긴밀하게 통합합니다. 이 절차는 PHY 전환 및 암호화 업데이트를 독립적인 활동으로 취급하는 대신, 필요에 따라 장치가 PHY 변경 사항과 관련 보안 업데이트를 조율할 수 있도록 합니다.
이러한 통합된 접근 방식을 통해 기기는 보안 통신을 유지하면서 운영 중단을 최소화한 상태로 GFSK 및 HDT 작동 모드 간을 원활하게 전환할 수 있습니다. PHY 및 보안 상태 관리를 동기화함으로써, 기기는 연결을 재설정하거나 상위 계층 서비스를 중단할 필요 없이 변화하는 운영 요구 사항에 적응할 수 있습니다.
MIC 길이의 변경 시, 보안 상태 이 선택된 보호 수준과 일치하도록 보장하기 위해 이에 상응하는 키 갱신 가 필요합니다. 동시에, 키 갱신 작업은 PHY 전환과 독립적으로 수행될 수 있어, 강력한 보안 보호 기능을 유지하면서도 유연성을 제공합니다.
이 절차는 LL_PHY_REQ, LL_PHY_RSP 및 LL_PHY_UPDATE_IND의 향상된 버전을 통해 지원되며, 이들 인터페이스는 PHY 작동과 보안 상태 관리를 조정하는 데 필요한 신호 전달 기능을 제공합니다.
3.2.6.3 보안 아키텍처 호환성
Bluetooth® HDT는 기존의 Bluetooth® LE 보안 메커니즘을 대체하기보다는 이를 확장함으로써, 제조업체들이 광범위한 Bluetooth 생태계와의 상호 운용성을 유지하면서 강화된 보안 기능을 도입할 수 있도록 합니다. 이러한 접근 방식은 도입 과정을 간소화하며, 근본적으로 다른 보안 모델을 도입할 필요 없이 제품이 HDT 기능의 이점을 누릴 수 있게 해줍니다.
3.3 요약
블루투스® HDT( 고속 데이터 처리량 )는 기존 블루투스 아키텍처와 완벽하게 통합된 상태에서 최대 7.5 Mb/s의 비트 전송률을 지원할 수 있는 새로운 고효율 물리 계층을 통해 블루투스® LE의 기능을 확장합니다. PHY, 패킷 아키텍처, 링크 Layer, HCI 및 보안 프레임워크의 개선을 통해 HDT는 블루투스 LE의 상호 운용성, 효율성 및 배포 유연성을 유지하면서 훨씬 더 높은 처리량을 제공합니다.
이러한 개선 사항들은 종합적으로, 차세대 오디오 시스템, 웨어러블 기기, 산업용 솔루션 및 기타 새로운 활용 사례를 포함하여 훨씬 더 큰 데이터 용량을 필요로 하는 미래의 블루투스 애플리케이션을 위한 확장 가능한 기반을 마련합니다. HDT는 기존 블루투스 생태계와의 호환성을 유지하면서 증가하는 대역폭 수요를 충족하기 위해 블루투스 LE가 어떻게 지속적으로 발전할 수 있는지를 보여줍니다.
4. Bluetooth® LE 등시성 매개변수 업데이트(IPU)
4.1 배경
4.1.1 정적 CIS 구성 및 제한 사항
블루투스® LE 오디오 는 시간에 민감한 애플리케이션을 위한 전송 메커니즘으로 CIS(Connected Isochronous Streams)를 도입했습니다. CIS 설정 과정에서 PHY 선택, ISO_Interval, 버스트 번호(BN), 플러시 타임아웃(FT), 최대 SDU 크기(Max_SDU), 전송 지연 시간과 같은 전송 매개변수가 장치 간에 협상되며, 이는 스트림의 수명 기간 동안 고정됩니다. 이 모델은 스케줄링을 단순화하고 등시성 통신을 위한 예측 가능한 타이밍 동작을 제공합니다.
그러나 실제 배포 환경에서는 스트림이 활성화된 동안 운영 조건이 자주 변합니다. 간섭, 이동성 또는 환경 변화로 인해 무선 품질이 변동할 수 있으며, 애플리케이션은 지연 시간, 신뢰성, 처리량 또는 전력 요구 사항이 서로 다른 운영 모드 간에 전환될 수 있습니다. 그 결과, 단일한 정적 CIS 구성만으로는 전송 동작을 항상 효율적으로 최적화할 수 없습니다.
Bluetooth® LE 등시성 업데이트( 매개변수 , IPU)가 도입되기 전에는, 이러한 변화하는 요구 사항에 대응하기 위해 일반적으로 기존 CIS를 종료하고 업데이트된 매개변수를 적용한 새로운 스트림을 설정해야 했습니다. 기능적으로는 효과적이지만, 이러한 방식은 서비스 중단을 초래하거나 추가적인 시스템 재구성을 필요로 할 수 있으며, 작동 모드 간의 원활한 전환을 복잡하게 만들 수 있습니다.
4.1.2 런타임 적응 소개
Bluetooth® LE 등시성 매개변수 업데이트(IPU)는 CIS가 활성화된 상태에서도 전송 매개변수를 업데이트할 수 있도록 함으로써 이러한 한계를 해결합니다. IPU는 CIS 구성을 일회성 설정으로 간주하는 대신, 장치가 스트림의 전체 수명 기간 동안 대체 운영 구성 간에 전환할 수 있도록 합니다.
이 기능을 통해 블루투스® 시스템은 스트림을 다시 설정할 필요 없이 변화하는 무선 환경, 애플리케이션 요구 사항 및 작동 모드에 맞춰 전송 동작을 조정할 수 있습니다. IPU는 조정된 런타임 구성 전환을 지원함으로써, 등시성 애플리케이션에 필요한 연속성과 동기화 특성을 유지하면서 유연성을 향상시킵니다.
다음 섹션에서는 이 새로운 전송 적응 모델을 가능하게 하는 설계 개념, 구성 아키텍처 및 런타임 메커니즘에 대해 설명합니다.
4.2 블루투스® IPU 설계 개념
4.2.1 정적 스트림에서 런타임 구성 관리로
전통적으로, 연결된 등시성 스트림(CIS)의 전송 매개변수는 스트림이 설정된 후에는 고정된 상태로 유지됩니다. 따라서 운영 요구 사항이 크게 변경될 경우, 전송 방식을 조정하기 위해서는 활성 상태인 CIS를 종료하고 다른 매개변수를 가진 새로운 CIS를 설정해야 할 수 있습니다. 이러한 접근 방식은 필요한 전송 특성을 제공하지만, 서비스 중단과 추가적인 시스템 재구성을 초래할 수 있습니다.
IPU는 스트림을 교체하지 않고도 활성 CIS의 전송 매개변수를 업데이트할 수 있는 대체 모델을 도입합니다. 무선 환경, 애플리케이션 요구 사항 또는 시스템 정책이 변경될 경우, 장치들은 CIS가 활성 상태를 유지하는 동안 적절한 사전 정의된 구성을 선택하고 조정된 업데이트를 수행할 수 있습니다. 이를 통해 전송 적응을 스트림 설정과 분리함으로써, 장치들은 스트림을 재설정하지 않고도 변화하는 요구 사항에 대응할 수 있습니다.
그림 4.2.1은 IPU를 통해 활성화된 런타임 업데이트 모델과 스트림 재설정을 비교한 것이다.
4.2.2 구성 중심의 적응 모델
Bluetooth® IPU는 미리 정의된 일련의 CIG 구성을 통해 런타임 적응을 지원합니다. 각 구성은 CIG 내 CIS에 대한 정의된 작동 지점을 나타내며, 해당 작동 지점에 필요한 전송 매개변수를 포함합니다. 구현 시 다양한 애플리케이션 요구 사항, 무선 환경 또는 시스템 정책을 충족하기 위해 여러 구성을 설정할 수 있습니다.
가동 중에는 활성 CIS의 전송 동작을 정의하기 위해 이러한 구성 중 하나가 선택됩니다. 조건이 변경되면 IPU 절차를 통해 다른 구성을 선택하여 적용할 수 있습니다. 따라서 구성은 사용 가능한 전송 동작점을 나타내며, 활성 CIS는 선택된 구성이 적용된 지속적인 전송 경로로 유지됩니다.
그림 4.2.2는 런타임 드라이버, 사전 정의된 구성, 선택된 구성 및 활성화된 CIS 간의 관계를 보여줍니다.
4.2.3 다중 작동점 설계
CIG에 프로비저닝된 구성은 다양한 전송 목표를 달성할 수 있도록 설계될 수 있습니다. 예를 들어, 어떤 구성은 처리량을 우선시하고, 다른 구성은 전송 지연 시간을 줄이며, 또 다른 구성은 열악한 무선 환경에서도 더 높은 내구성을 제공할 수 있습니다. 적절한 구성 세트는 제품 에서 지원하는 작동 모드 및 적응 요구 사항에 따라 달라집니다.
IPU는 각 구성 요소( 매개변수 )나 사용 사례(use case)마다 별도의 업데이트 절차를 정의하는 대신, 이러한 미리 정의된 작동 지점 간을 전환하기 위한 공통 메커니즘을 제공합니다. 구성 간에 차이가 있는 매개변수는 업데이트의 영향을 받는 전송 측면을 결정하며, IPU 절차는 선택된 구성이 언제, 어떻게 활성화될지를 조정합니다.
다음 섹션에서는 이러한 구성이 어떻게 식별되고 구성되는지, 호스트와 컨트롤러 간에 업데이트 책임이 어떻게 분담되는지, 그리고 다양한 ‘ 매개변수 ’ 변경 사항이 CIS 운영에 어떤 영향을 미치는지에 대해 설명합니다.
4.3 블루투스® IPU 아키텍처 및 핵심 개념
4.3.1 여러 가지 구성이 존재하는 이유
최신 블루투스® 기기들은 종종 서로 다른 전송 특성이 요구되는 환경에서 작동합니다. 무선 신호 품질, 애플리케이션 동작, 전력 제약 또는 지연 시간 요구 사항의 변화에 따라 각각 다른 전송 작동 지점이 적합할 수 있습니다.
IPU는 조건이 바뀔 때마다 개별 전송 매개변수를 수정하는 대신, 전송 동작을 미리 정의된 구성 모음으로 체계화합니다. 각 구성은 완전한 작동 지점을 나타내며, 이를 선택하여 활성화된 CIS(Connected Isochronous Stream)에 적용할 수 있습니다.
이 접근 방식은 업데이트를 개별 전송 매개변수에 대한 독립적인 수정으로 간주하기보다는 미리 정의된 구성 간의 전환으로 취급함으로써 런타임 적응 과정을 단순화합니다.
표 4.3.1은 서로 다른 전송 구성이 필요할 수 있는 운영 요구 사항의 예시를 제시하며, 단일 정적 CIS 구성이 모든 운영 조건에서 최적이 아닐 수 있는 이유를 설명하고 있다.
| 운영 요건 | 수송 목표 예시 |
|---|---|
| 음악 재생 | 더 높은 처리량과 음질 |
| 음성 통신 | 전송 지연 시간 단축 |
| RF 성능 저하 복구 | 신뢰성 향상 |
| 전력 제약 조건 하의 작동 | 방사능 감소 |
4.3.2 런타임 구성 관리
다양한 운영 구성을 지원하려면 구성 관리가 필요합니다. IPU는 관련 운영 지점을 함께 묶는 계층적 모델을 사용하여 구성을 체계화합니다. 각 구성은 Config_ID로 식별되며, Config_Group_ID 및 전송 지연 그룹(TL_Group) 식별자를 사용하여 구성을 체계화할 수도 있습니다.
가장 상위 수준에서, 구성은 연결된 등시 그룹(CIG)과 연관되어 있습니다. CIG 내에서 구성은 전송 지연 시간 특성에 따라 TL_Group으로 구성될 수 있습니다. TL_Group 내에서 Config_Group은 관련 전송 동작점을 지원하는 구성들을 연관시키는 방법을 제공합니다. Config_Group 내의 개별 구성은 해당 Config_ID로 식별됩니다.
이 구조는 장치가 여러 개의 미리 정의된 작동 지점을 유지하도록 하면서, 실행 시 적응 과정에서 구성을 선택하기 위한 체계적인 메커니즘을 제공합니다. 호스트가 생성한 구성과 컨트롤러가 자율적으로 생성한 구성 모두 이 프레임워크 내에서 관리될 수 있습니다.
그림 4.3.2에서 볼 수 있듯이, IPU는 지연 시간과 관련된 그룹화를 개별 전송 구성과 분리하는 계층적 조직 모델을 도입합니다. 구성을 서로 무관한 매개변수 세트로 보는 것보다는, CIG의 잠재적 작동 모드를 정의하는 더 큰 구성 공간의 구성 요소로 보는 것이 종종 유용합니다.
4.3.3 전송 지연 시간 그룹이 중요한 이유
전송 지연 시간은 등시성 전송의 중요한 특성인데, 이는 전송 지연 시간의 변화가 버퍼링 동작, 표시 타이밍 및 애플리케이션 수준 처리 요구 사항에 영향을 미칠 수 있기 때문이다.
따라서 IPU는 전송 지연 그룹(TL_Groups)을 사용하여 구성을 관리합니다. 동일한 TL_Group 내의 구성들은 동일한 전송 지연 특성을 공유하는 반면, 서로 다른 TL_Group에 속한 구성들은 서로 다른 전송 지연 모델을 나타냅니다.
이 구조는 런타임 전환 시 중요한데, 업데이트 전반에 걸친 페이로드 처리는 전환이 동일한 TL_Group 내에서 이루어지는지, 아니면 TL_Group 경계를 넘나드는지에 부분적으로 좌우되기 때문입니다.
4.3.4 호스트 및 컨트롤러의 책임
모든 구성 변경이 동일한 범위나 영향을 미치는 것은 아닙니다. 일부 업데이트는 링크 Layer 의 작동에만 영향을 미치는 반면, 다른 업데이트는 전송 지연 시간, 버퍼링 가정 또는 애플리케이션 수준의 동작에 영향을 미칠 수 있습니다.
IPU는 호스트와 컨트롤러 간의 책임을 구분함으로써 이러한 차이를 반영합니다.
호스트는 애플리케이션 요구 사항, 운영 모드, 품질 목표 또는 시스템 정책에 따라 전송 구성을 선택하거나 요청하는 것을 포함하여, 애플리케이션 수준의 조정 결정을 담당합니다. 컨트롤러는 해당 업데이트 절차를 실행하고 전송 전환을 조정하는 역할을 담당합니다.
이러한 분리를 통해 IPU는 애플리케이션 주도형 및 컨트롤러 주도형 적응 방식을 모두 지원할 수 있습니다. 예를 들어, 애플리케이션이 작동 모드를 변경할 때 호스트가 구성 변경을 시작할 수 있는 반면, 컨트롤러는 변화하는 무선 환경이나 기타 링크 Layer 조건에 대응하여 전송 매개변수를 자율적으로 조정할 수 있습니다.
그림 4.3.4에서 볼 수 있듯이, 호스트는 전송 전환이 왜, 언제 이루어져야 하는지를 결정하는 반면, 컨트롤러는 전환을 조정하고 실행하는 역할을 담당한다.
4.3.5 적응의 차원
블루투스® IPU의 대표적인 특징 중 하나는 런타임 적응이 단일 전송 방식 매개변수 에만 국한되지 않는다는 점입니다. 다양한 구성에 따라 무선 성능, 전송 주기, 신뢰성, 지연 시간, 이벤트 스케줄링 등 CIS 동작의 여러 측면이 달라질 수 있습니다.
건축학적 관점에서 볼 때, 이러한 변화들은 몇 가지 적응 차원을 통해 이해할 수 있다.
| 적응 목표 | 매개변수 예시 |
|---|---|
| PHY / 링크 적응 | PHY, 전송 속도, 재전송 매개변수 |
| 비트레이트 적응 | Max_SDU |
| 일정 조정 유연성 | 앵커 포인트, ISO_Interval |
| 지연 시간 조정 | 전송 지연 시간, TL_Group |
| 작동 모드 조정 | 다양한 애플리케이션 요구 사항에 따른 구성 변경 |
표 4.3.5에서 볼 수 있듯이, IPU 구성은 여러 전송 목표에 걸친 적응을 지원할 수 있습니다. 구성 변경은 선택된 동작점에 따라 하나 이상의 매개변수에 동시에 영향을 미칠 수 있습니다. 이를 통해 무선 동작, 비트레이트, 스케줄링, 지연 시간 및 애플리케이션 작동 모드를 조정하기 위한 공통 프레임워크가 제공됩니다.
사양서에는 수많은 업데이트 시나리오가 정의되어 있지만, 그 대부분은 이러한 적용 차원 간의 변형으로 이해될 수 있습니다. 이러한 관점은 가능한 모든 업데이트 조합을 일일이 검토하지 않고도, 다양한 매개변수 변경 사항이 CIS 운영에 어떤 영향을 미치는지 이해하는 데 유용한 틀을 제공합니다.
다음 섹션에서는 IPU가 동기화를 유지하고 페이로드의 연속성을 보장하면서 이러한 차원 간 전환을 어떻게 조정하는지에 대해 설명합니다.
4.4 구성 수명 주기 및 런타임 조정
4.4.1 구성 수명 주기
Bluetooth® IPU가 도입한 핵심 개념 중 하나는 구성 정의와 구성 활성화를 분리하는 것입니다. 구성은 CIS가 설정될 때만 생성되는 것이 아니라, 활성 전송과 독립적으로 정의, 프로비저닝 및 유지 관리될 수 있습니다.
프로비저닝된 각 구성은 연결된 등시 그룹(CIG)에 대한 완전한 전송 동작 지점을 나타냅니다. 구성에는 PHY 선택, ISO 타이밍 특성, 스케줄링 동작, 재전송 매개변수, 전송 지연 특성 및 관련 동기화 정보가 정의될 수 있습니다. 구성은 고유한 Config_ID 값으로 식별되며, CIS가 설정되기 전에 프로비저닝될 수 있습니다.
호스트 관리형 및 컨트롤러 관리형 구성 프로비저닝을 모두 지원하기 위해, Config_ID 값은 별도의 할당 범위로 구분됩니다. 구성 정의는 런타임 업데이트 절차와 분리되어 있습니다. 구성을 사전에 정의하고 프로비저닝할 수 있으므로, 작동점 변경이 필요할 때 업데이트 절차는 전환 과정의 일환으로 새로운 구성을 정의하는 대신 기존 구성을 활성화할 수 있습니다. 0x01부터 0x7F까지의 Config_ID 값은 호스트가 할당하는 반면, 0x80부터 0xFF까지의 값은 컨트롤러가 자율적으로 할당할 수 있습니다. 이러한 분리는 충돌을 방지하는 동시에 애플리케이션 주도형 및 컨트롤러 주도형 적응 모델을 모두 가능하게 합니다.
구성이 프로비저닝되면 런타임에서 선택할 수 있게 되며, 이후 운영 요구 사항이 변경될 때 활성화될 수 있습니다. 구성 정의가 스트림 생성과 분리되어 있으므로, 하나의 CIG 내에 여러 구성이 공존할 수 있으며 스트림의 수명 주기 내내 사용할 수 있습니다.
구성 관리와 스트림 설정 간의 이러한 구분은 IPU의 근본적인 아키텍처적 특징입니다. 스트림 설정이 완료되면 전송 매개변수가 사실상 고정되었던 기존의 CIS 구현과 달리, IPU는 미리 정의된 작동점 중에서 선택함으로써 전송 동작이 변화할 수 있도록 합니다.
결과적으로, 전송 적응은 구성을 새로 생성하는 과정이 아니라 구성을 선택하고 활성화하는 과정이 되며, 이를 통해 CIS는 재설정 없이도 변화하는 요구 사항에 맞춰 조정될 수 있습니다.
4.4.2 런타임 구성의 조정된 업데이트
구성 변경 사항은 궁극적으로 개별 CIS의 전송 매개변수에 영향을 미치지만, 업데이트 실행은 CIG 수준에서 조정됩니다. 이를 통해 동일한 CIG에 속한 여러 CIS가 일관되게 전환되고, 업데이트 과정 전반에 걸쳐 동기화를 유지할 수 있습니다.
런타임 적응은 장치가 현재의 작동 조건에 더 적합한 다른 전송 작동 지점이 있다고 판단할 때 시작됩니다. 구성 변경의 동기는 애플리케이션 작동 모드의 전환, 무선 환경의 변화, 지연 시간 요구 사항, 신뢰성 목표 또는 시스템 수준의 적응 정책 등에서 비롯될 수 있습니다.
대상 구성을 식별한다고 해서 활성 CIS가 즉시 수정되는 것은 아닙니다. 새로운 구성이 적용되려면 두 장치 모두 Bluetooth® IPU 업데이트 절차를 통해 전환 과정을 조율해야 합니다.
이러한 조정을 통해 참여 장치들은 업데이트가 활성화되기 전에 목표 구성 및 관련 전송 특성에 대해 합의하게 됩니다. IPU는 구성 선택과 활성화 과정을 분리함으로써, 안전한 전송 전환에 필요한 시간적 제약과 무관하게 적응 결정을 내릴 수 있도록 합니다.
가장 일반적인 배포 모델에서, 중앙 장치는 대상 구성을 선택하고 CIS 업데이트 절차를 시작합니다. IPU는 주변 장치에서 시작된 업데이트 요청도 지원하므로, 주변 장치가 다른 전송 작동 지점이 더 바람직할 수 있음을 알릴 수 있으면서도, 최종 업데이트 결정을 내리는 중앙 장치의 역할은 유지됩니다.
이니시에이터 에 관계없이, 업데이트는 동일한 조정 모델을 따르며 궁극적으로 동기화된 업데이트 경계에서 활성화됩니다. 이 과정 전반에 걸쳐 CIS는 유지되며 지속적인 운영을 위해 사용 가능한 상태를 유지합니다. 이를 통해 운영 요구 사항이 변경될 때마다 스트림을 종료하고 다시 설정할 필요 없이 전송 동작이 진화할 수 있습니다.
4.4.3 인스턴트 기반 활성화 및 동기화
구성 업데이트는 요청 즉시 적용되지 않습니다. 대신, 새로운 구성은 ‘인스턴트(Instant)’라고 하는 미리 정의된 활성화 시점에 활성화됩니다.
Instant는 두 장치가 동시에 업데이트된 구성으로 전환할 수 있도록 하는 공통 동기화 경계를 제공합니다. 조율된 활성화가 이루어지지 않으면, 한 장치가 다른 장치가 준비되기 전에 업데이트된 전송 매개변수로 작동을 시작할 수 있으며, 이로 인해 스케줄링 불일치, 페이로드 정렬 오류 또는 일시적인 동기화 상실이 발생할 수 있습니다.
이러한 이유로, 업데이트 절차에서는 전환이 적용되기 전에 먼저 목표 구성과 그 활성화 시점에 대한 합의를 도출합니다. 두 장치 모두 합의된 시점이 도래할 때까지 현재 구성으로 계속 작동하며, 해당 시점에 도달하면 선택된 구성이 활성화됩니다.
업데이트가 앵커 오프셋 조정을 통해 CIS 타이밍 배치에 영향을 미치는 경우에도 동일한 인스턴트 기반 접근 방식이 사용됩니다. 이러한 시나리오에서 업데이트는 전송 특성뿐만 아니라 향후 CIS 이벤트의 타이밍 위치도 수정합니다. 변경 사항을 미리 정의된 인스턴트에 스케줄링함으로써, 두 컨트롤러 모두 업데이트 후 이벤트 타임라인에 대해 일관된 관점을 유지합니다.
앵커 포인트 조정은 활성 Config_ID를 변경하지 않고도 적용될 수 있습니다. 이러한 경우, 업데이트는 기본 전송 구성을 변경하지 않은 채 향후 CIS 이벤트의 배치를 수정합니다. 이를 통해 전송매개변수 의 전환과 무관하게 스케줄링 최적화 및 타이밍 재조정이 이루어질 수 있습니다.
블루투스® IPU는 구성 활성화를 공통 CIS 이벤트 경계와 연동함으로써, 업데이트되는 전송 매개변수와 관계없이 두 컨트롤러 모두 결정론적인 방식으로 새로운 타이밍 모델로 전환되도록 보장합니다. 이러한 변경이 처리량, 재전송 동작, 전송 지연 시간 또는 향후 이벤트 위치에 영향을 미치든 상관없이, 동일한 동기화 원리가 적용됩니다.
인스턴트에 도달하면 구성 활성화 프로세스가 완료되지만, 전환 과정 전반에 걸쳐 페이로드의 연속성과 타이밍 일관성을 유지하기 위해서는 추가적인 메커니즘이 필요합니다. 이러한 메커니즘은 업데이트된 구성이 전송 타이밍, 지연 시간 특성, 스케줄링 동작 또는 페이로드 전달에 영향을 미칠 때 특히 중요해집니다.
4.5 구성 전환 시 연속성 유지
4.5.1 런타임 전환과 연속성
특정 시점에 새로운 구성을 활성화한다고 해서, 이전 구성과 관련된 모든 전송 활동이 반드시 완료된 것은 아닙니다. 업데이트되는 매개변수에 따라, 업데이트 시점 이후에도 이전 구성과 관련된 페이로드가 전송 중일 수 있습니다.
따라서 Bluetooth® IPU는 구성 전환 과정에서 페이로드 처리를 조정하기 위한 메커니즘을 제공합니다. 전환 페이로드(Transition Payloads)와 플러시 포인트(Flush Points)를 통해 컨트롤러는 동기화를 유지하고, 이전 구성과 관련된 전송 인스턴스( 상태 )를 언제 해제할 수 있는지 판단할 수 있습니다. 새로운 구성을 활성화하는 것은 IPU 업데이트 과정의 한 단계에 불과합니다.
4.5.2 전환 과정 중 페이로드 관리
이전 구성과 관련된 페이로드가 아직 처리 중인 동안에도 CIS 업데이트가 발생할 수 있습니다. Bluetooth® IPU는 업데이트 순간에 걸쳐 페이로드 처리를 관리하기 위해 ‘전환 페이로드(Transition Payloads)’와 ‘전환 후 페이로드(Post-Transition Payloads)’를 정의합니다.
전환 페이로드는 업데이트 시점 이전의 CIS 기준 앵커 포인트와 연관됩니다. 이러한 페이로드의 처리 방식은 업데이트의 특성과, 해당 업데이트가 전송 지연 그룹을 변경하는지 또는 최대 패킷 페이로드 크기를 줄이는지에 따라 달라집니다.
업데이트로 인해 TL_Group_ID가 변경되거나 Max_Packet_Payload가 감소하는 경우, 전환 페이로드는 업데이트 시점에 플러시됩니다. 이를 통해 이전 전송 구성과 관련된 페이로드가 전환 후 더 이상 적용되지 않는 전송 모델을 계속 사용하지 않도록 보장합니다.
그 밖의 업데이트 시나리오의 경우, 플러시 포인트는 해당 CIS 업데이트 규칙에 따라 결정됩니다. 이를 통해 SDU 동기화를 유지하면서 업데이트 인스턴트 전반에 걸쳐 전환 페이로드를 계속 처리할 수 있습니다.
전환 후 페이로드는 ‘Update Instant’를 CIS 참조 기준점으로 사용합니다. ISO_Interval이 축소될 때 이러한 페이로드를 처리하는 방식은 특히 중요합니다. 새로운 구성과 관련된 페이로드는 업데이트된 이벤트 타이밍을 사용하여 스케줄링되어야 할 수 있기 때문입니다.
이러한 메커니즘들이 종합적으로 작용하여, IPU는 동기화를 유지하면서 구성 간 전환을 수행하고, 업데이트 인스턴트의 양쪽과 관련된 페이로드를 적절하게 관리할 수 있게 됩니다.
4.6 프로토콜 확장
4.6.1 호스트 컨트롤러 인터페이스 확장
블루투스® IPU는 상당한 규모의 새로운 런타임 기능을 도입하고 있지만, 이에 따른 프로토콜 변경 사항은 비교적 소규모입니다. 추가된 기능의 대부분은 구성 관리 및 런타임 업데이트를 지원하는 소수의 HCI 명령어와 이벤트에 집중되어 있습니다.
호스트 컨트롤러 인터페이스(HCI) 수준에서, 새로운 명령어를 통해 호스트는 CIG 구성을 정의하고, 이전에 정의된 구성을 제거하며, 구성 업데이트를 시작하고, 업데이트 결정에 참여할 수 있습니다. 이에 상응하는 HCI 이벤트를 통해 컨트롤러는 업데이트 완료를 보고하고, 주변기기 측에서 발생한 업데이트 요청을 전달할 수 있습니다.
IPU를 통해 도입된 주요 HCI 추가 기능은 표 4.6.1에 요약되어 있다.
| 메커니즘 | 목적 |
|---|---|
| LE CIG 구성 추가 | 추가 런타임 구성을 정의합니다. |
| LE CIG 구성 제거 | 이전에 정의된 구성을 제거합니다. |
| LE 업데이트 CIG | 구성 전환 시작 |
| LE 업데이트 CIG 주변기기 요청에 대한 회신 | 주변 장치에서 발생한 업데이트 요청에 응답하기 |
| LE CIS 업데이트 행사 | 업데이트 완료 시 호스트에 알리기 |
| LE 업데이트 CIG 주변기기 요청 이벤트 | 주 장치에 주변기기 업데이트 요청 알리기 |
이러한 명령과 이벤트를 종합적으로 활용함으로써 호스트는 스트림 설정 단계뿐만 아니라 CIG의 전체 수명 주기 동안 여러 전송 동작 지점을 관리할 수 있습니다.
4.6.2 링크 Layer 확장 기능
링크 Layer 에서 Bluetooth® IPU는 구성 정의, 구성 제거, 중앙 장치(Central)가 시작하는 업데이트 및 주변 장치(Peripheral)가 시작하는 업데이트 요청을 지원하는 새로운 제어 절차를 도입합니다. 이러한 절차는 활성 CIS가 유지되는 동안 전송 적응을 조정하는 데 필요한 신호 전달 프레임워크를 제공합니다.
IPU를 통해 도입된 주요 ‘ 링크 Layer ’ 추가 기능은 표 4.6.2에 요약되어 있습니다.
| 메커니즘 | 목적 |
|---|---|
| LL_CIG_CONFIG_REQ / RSP | 구성 정의 생성 |
| LL_CIG_CONFIG_REMOVE_IND | 구성 정의 제거 |
| LL_CIS_UPDATE_REQ / RSP | 구성 업데이트 실행 |
| LL_CIS_주변기기_업데이트_요청 | 주변기기 측에서 업데이트를 요청합니다 |
이러한 절차는 운영 중에 구성 상태 이 변화할 수 있도록 함으로써, CIS의 수명 주기를 생성 및 종료 단계 너머로 확장합니다. 이는 앞선 섹션에서 설명한 활성화 및 연속성 메커니즘과 결합되어, 런타임 전송 적응을 위한 프로토콜 기반을 형성합니다.
CIS의 전송 동작에 업데이트가 적용되기는 하지만, 동일한 CIG에 속한 여러 CIS가 전환 과정 전반에 걸쳐 동기화 상태를 유지할 수 있도록 업데이트 실행은 CIG 수준에서 조정됩니다.
4.7 대표적인 업데이트 시나리오
앞서 설명한 섹션에서는 Bluetooth® IPU가 구성 프로비저닝, 조정된 활성화 및 연속성 관리를 통해 런타임 전송 적응을 어떻게 가능하게 하는지 다루었습니다. 이 섹션에서는 이러한 기능들이 시스템의 다양한 계층에 어떻게 적용될 수 있는지 설명합니다.
이 예시들은 세 가지 일반적인 적응 유발 요인을 보여주기 위해 의도적으로 선정되었습니다:
- 무선 통신 환경의 변화
- 운송 요건의 변화
- 애플리케이션 동작의 변화
이 두 가지는 스트림을 다시 설정할 필요 없이 CIS가 작동 중에 어떻게 진화할 수 있는지를 함께 보여줍니다.
4.7.1 동적 RF 적응
블루투스® IPU의 주요 목적 중 하나는 변화하는 무선 환경에 대응하여 전송 특성을 조정할 수 있는 기능입니다.
그림 4.7.1은 동일한 CIG 내에서 여러 구성이 프로비저닝되는 예를 보여줍니다. 한 구성은 무선 환경이 양호할 때 전송 효율을 우선시할 수 있는 반면, 다른 구성은 패킷 손실이 증가하기 시작할 때 더 높은 내결함성을 제공할 수 있습니다.
작동 중 컨트롤러는 패킷 오류율(PER)과 같은 무선 품질 지표를 모니터링하며, 다른 작동 지점으로 전환해야 할 시점을 판단합니다. 목표 Config_ID가 확인되면 호스트는 LE Update CIG 명령을 사용하여 전환을 시작합니다. 그런 다음 컨트롤러들은 CIS Update 절차를 통해 업데이트를 조정하고, 합의된 시점에 새로운 구성을 활성화합니다.
나중에 채널 상태가 악화될 경우, 동일한 절차를 통해 더 탄력적인 구성으로 다시 전환할 수 있습니다. 애플리케이션 관점에서 보면, 이 과정 전반에 걸쳐 오디오 스트림은 계속 활성화된 상태를 유지합니다. 단지 기본 전송 구성만 변경될 뿐입니다.
이 예시는 CIS가 활성화된 상태에서 IPU가 변화하는 무선 환경에 맞춰 전송 구성을 어떻게 조정할 수 있는지를 보여줍니다.
동일한 적응 프레임워크는 LE 1M, LE 2M 및 LE 코디드 PHY는 물론, LE 고속 데이터 처리량 (HDT)와 같은 최신 전송 기술에도 적용됩니다. 예를 들어, 서로 다른 HDT 속도 세트에 대한 구성을 정의할 수 있으며, 이를 통해 각 구성은 적절한 서브 인터벌을 사용할 수 있습니다. 저속 구성은 HDT2, HDT3 및 HDT4를 지원할 수 있는 반면, 고속 구성은 HDT6 및 HDT7.5를 지원할 수 있습니다. 이러한 동작 지점을 분리함으로써, 사용 가능한 에어타임 내에서 재전송 기회를 스케줄링하는 데 더 큰 유연성을 확보할 수 있습니다.
이를 통해 IPU는 새로운 전송 기능이 도입될 때마다 공통된 구성 및 업데이트 프레임워크를 제공할 수 있습니다.
4.7.2 가변 비트율
Bluetooth® IPU는 또한 동일한 CIS에 대해 서로 다른 최대 SDU 크기(Max_SDU)를 가진 여러 가지 구성을 설정할 수 있도록 함으로써 적응형 비트레이트를 지원할 수 있습니다. Max_SDU는 각 SDU 간격 동안 전송되는 애플리케이션 데이터의 양에 직접적인 영향을 미치므로, 서로 다른 구성은 서로 다른 비트레이트 작동 지점을 나타낼 수 있습니다.
예를 들어, 장치는 서로 다른 음질 수준에 해당하는 여러 가지 구성을 정의할 수 있습니다. 링크 상태가 양호할 때는 더 높은 비트레이트의 오디오 전송을 지원하기 위해 Max_SDU 값이 더 큰 구성이 선택될 수 있습니다. 링크 상태가 나빠지면 시스템은 Max_SDU 값이 더 작은 구성으로 전환하여, 활성 CIS를 유지하면서 전송 비트레이트를 낮출 수 있습니다.
그림 4.7.2는 서로 다른 Max_SDU 값을 가진 여러 구성이 사전에 프로비저닝된 사례를 보여줍니다. 운영 조건이 변경되면 IPU는 활성 CIS가 이러한 구성 간에 전환할 수 있도록 하여, 스트림을 다시 설정할 필요 없이 비트레이트 적응이 가능하게 합니다.
이 접근 방식을 통해 서비스 연속성을 보장하고 전환 과정 전반에 걸쳐 CIS 연결을 활성 상태로 유지하면서, 음질과 전송 용량을 동적으로 조정할 수 있습니다.
4.7.3 오디오 모드 전환
앞서 제시한 예시들은 주로 전송 조건에 의해 좌우되지만, 일부 업데이트는 애플리케이션 동작의 변화에서 비롯되기도 합니다.
LE 오디오 기기들은 종종 여러 가지 애플리케이션 모드에서 작동합니다. 음악 재생, 음성 통신, 청각 보조 애플리케이션, 대화형 오디오 서비스 등은 지연 시간, 비트레이트, 신뢰성 등 서로 다른 전송 특성에 우선순위를 둘 수 있습니다.
Bluetooth® IPU를 사용하면 이러한 다양한 작동 모드에 최적화된 구성을 미리 설정해 두었다가 CIS가 활성화된 상태에서도 이를 활성화할 수 있습니다. 예를 들어, 음성 통화가 시작되면 장치가 음악 중심 구성에서 음성 중심 구성으로 전환될 수 있습니다. 호스트는 새로운 작동 모드에 적합한 구성을 식별하고 호스트 컨트롤러 인터페이스를 통해 업데이트를 시작합니다. 그런 다음 컨트롤러들은 CIS 업데이트 절차를 통해 전환을 조정하고, 합의된 시점에 새로운 구성을 활성화합니다.
통화가 종료되고 음악 재생이 재개될 때의 역방향 전환에도 동일한 방식을 적용할 수 있습니다. 필요한 설정을 미리 정의해 둘 수 있으므로, 이 전환을 통해 CIS를 다시 설정할 필요 없이 전송 특성을 변경할 수 있습니다.
4.7.4 공존 및 스케줄링 유연성
또한 Bluetooth® IPU는 다른 무선 트래픽과의 공존 및 다른 Bluetooth® 등시성 스트림과의 동기화를 지원하기 위해 유연한 스케줄링 기능을 제공할 수 있습니다.
예를 들어, IPU 업데이트를 통해 CIS의 앵커 포인트를 조정함으로써, CIS와 Auracast® 스트림과 같은 브로드캐스트 아이소크로닉 스트림(BIS) 간의 타이밍 관계를 변경할 수 있습니다. 이를 통해 CIS의 타이밍을 다른 아이소크로닉 활동과 보다 효과적으로 동기화할 수 있습니다.
IPU는 또한 ISO_Interval을 변경하여 CIS 이벤트 간의 간격을 더 넓게 만들 수 있습니다. 이러한 간격은 대용량 Wi-Fi 패킷을 비롯한 다른 무선 트래픽에 추가적인 송신 시간을 제공하여, Bluetooth®와 다른 무선 기술 간의 공존성을 향상시킵니다.
이러한 스케줄링 변경 사항은 다른 IPU 구성 변경에 사용되는 것과 동일한 조정된 업데이트 메커니즘을 통해 적용될 수 있으며, 이를 통해 CIS가 활성화된 상태에서도 타이밍 동작을 점진적으로 변경할 수 있습니다.
4.8 요약
Bluetooth® LE 등시성 매개변수 업데이트(IPU)는 연결된 등시성 스트림(CIS)을 고정된 전송 모델의 범위를 넘어 확장하며, CIS가 활성화된 상태에서도 전송 동작을 발전시킬 수 있는 기능을 도입합니다.
IPU는 전송 매개변수를 스트림 설정 시 한 번만 산출되는 결과로 취급하는 대신, CIG의 수명 주기 전반에 걸쳐 여러 작동 지점을 프로비저닝하고, 선택하며, 활성화할 수 있는 구성 중심의 프레임워크를 도입합니다.
런타임 업데이트는 Instant 기반 활성화를 통해 조정되며, 이를 통해 두 장치 모두 공통된 동기화 경계에서 새로운 구성으로 전환할 수 있습니다. 전환 페이로드 처리 및 플러시 포인트 조정을 포함한 추가적인 연속성 메커니즘은 전송 상태 이 진화하는 동안에도 페이로드 처리가 유지되도록 합니다.
이러한 기능을 지원하기 위해 IPU는 구성 관리, 런타임 적응 및 조정된 업데이트 실행을 가능하게 하는 호스트 컨트롤러 인터페이스(Host Controller Interface) 및 호스트 제어 확장( 링크 Layer )의 간결한 세트를 도입합니다.
이러한 메커니즘들이 결합되어, 전송 적응 기능을 스트림 재설정 작업에서 실행 시 기능으로 전환합니다. IPU는 활성 CIS를 유지하면서 변화하는 무선 환경, 적응형 비트레이트, 애플리케이션 모드 전환, 스케줄링 또는 공존 요구 사항에 대한 적응을 지원할 수 있습니다. IPU는 대체 구성을 정의하고 활성화하기 위한 공통 메커니즘을 제공함으로써, 스트림을 재설정할 필요 없이 전송 동작이 진화할 수 있도록 합니다.
5. 블루투스® 암호화 키 스케줄(EKS)
5.1 배경
5.1.1 블루투스® LE 암호화의 발전
블루투스® LE는 전통적으로 ‘다이버시파이어를 사용한 암호화 시작(Encryption Start with Diversifiers)’ 절차를 통해 암호화된 연결을 수립합니다. 이 모델에서 기기들은 블루투스 링크 Layer 암호화에 사용되는 세션 키를 도출하기 전에 초기화 벡터와 세션 키 다이버시파이어를 교환합니다. 이러한 접근 방식은 광범위한 애플리케이션에 걸쳐 블루투스 LE 통신을 위한 안전하고 상호 운용 가능한 기반을 제공해 왔습니다.
블루투스 기술이 고성능 전송 방식과 더욱 진보된 보안 아키텍처로 발전함에 따라, 암호화 자료의 설정, 관리 및 갱신에 있어 더 큰 유연성이 요구되고 있습니다. 특히, 전송 방식 간의 암호화 분리 강화, 진화하는 암호화 컨텍스트에 대한 지원, 그리고 보다 유연한 키 수명 주기 관리에 대한 수요가 증가하고 있습니다.
이러한 요구 사항을 해결하기 위해 블루투스는 ECDH 기반 키 설정과 계층적 키 도출, 통합된 키 관리( 키 갱신 ) 기능을 결합한 새로운 프레임워크인 ‘암호화 키 스케줄(EKS)’을 도입했습니다.
5.1.2 새로운 키 관리 프레임워크가 필요했던 이유
기존의 Bluetooth® LE 암호화 방식은 교환된 세션 매개변수와 함께 장기 키(LTK)에서 직접 세션 키를 도출합니다. 이 모델은 효과적이긴 하지만, 연결이 수립된 후 암호화 자료를 관리하는 데 있어 유연성이 제한적입니다.
Bluetooth® EKS는 색다른 접근 방식을 도입합니다. EKS는 단일 키 소스에서 직접 암호화 자료를 도출하는 대신, 여러 입력값을 바탕으로 암호화 기반을 구축한 다음, 체계적인 계층 구조를 통해 세션 암호화 자료를 도출합니다. 키 설정, 전송 방식별 키 도출, 그리고 후속 키 업데이트를 이처럼 분리함으로써 Bluetooth LE 암호화 자료의 수명 주기를 더욱 유연하게 관리할 수 있습니다.
5.2 기술 개요
블루투스® 암호화 키 스케줄(Bluetooth® Encryption Key Schedule)은 블루투스® LE 암호화 자료에 대한 체계적인 수명 주기를 정의합니다. 먼저 연결을 위한 암호화 기반을 구축한 다음, 계층적 도출 프레임워크를 사용하여 전송 계층별 암호화 자료를 생성합니다. 암호화 기반의 구축이 세션 키 생성 과정과 분리되어 있으므로, 동일한 아키텍처로 기회적 암호화(opportunistic encryption) 및 연결 중 키 업데이트( 키 갱신)를 포함한 대체 작동 모드와 후속 키 업데이트도 지원할 수 있습니다.
5.2.1 암호화 기반 구축
블루투스® EKS의 첫 번째 단계에서는 후속 키 도출 절차에서 사용되는 암호화 기반을 구축합니다.
기존 블루투스® LE 암호화는 ‘다이버시파이어를 사용한 암호화 시작(Encryption Start with Diversifiers)’ 절차를 사용합니다. 이 과정에서 센트럴과 페리페럴은 LL_ENC_REQ 및 LL_ENC_RSP PDU를 통해 세션 키 다이버시파이어(SKD)와 초기화 벡터(IV) 값을 교환합니다. 교환된 값들은 장기 키(LTK)와 결합되어 ‘다이버시파이어를 사용한 암호화 시작( 링크 Layer )’ 암호화에서 사용되는 세션 키가 생성됩니다.
EKS는 이와는 다른 접근 방식을 도입합니다. 장치들은 SKD 및 IV 값을 교환하는 대신, LL_ENC_ECDH_REQ 및 LL_ENC_ECDH_RSP PDU를 사용하여 ECDH 공개 키, 난수 값 및 암호화 관련 매개변수를 교환합니다. 이러한 메시지에는 다음이 포함됩니다:
- ECDH 공개 키 (PubKey_C 및 PubKey_P)
- 난수 (Rand_C 및 Rand_P)
- 암호화 플래그 (Flags_C 및 Flags_P)
- 공개 키 유형 정보
- MIC 관련 운영 선호 사항
교환된 공개 키를 사용하여, 두 기기 모두 블루투스 P-256 타원 곡선을 통해 동일한 ECDH 공유 비밀을 각각 독립적으로 계산합니다.
그림 5.2.1에서 볼 수 있듯이, ‘키 스케줄을 이용한 암호화 시작(Encryption Start with Key Schedule)’ 절차는 단순히 암호화된 연결을 수립하는 것 이상의 역할을 합니다. 이 절차는 ECDH 공유 비밀을 생성하는 것 외에도, 나중에 EKS 도출 과정의 일부가 될 제어 정보를 교환합니다. 이렇게 교환된 데이터는 이후 EKS 키 계층 구조에 통합됩니다.
ECDH 공유 비밀은 세션 키로 직접 사용되지 않습니다. 대신, 이 절차는 EKS 키 계층 구조를 초기화하는 데 필요한 암호화 입력값과 협상 컨텍스트를 설정합니다. 필요한 암호화 자료가 도출되면, 장치들은 LL_START_ENC_REQ 및 LL_START_ENC_RSP를 사용하여 기존의 3단계 암호화 핸드셰이크를 완료합니다.
따라서 그림 5.2.1에 표시된 절차를 통해 설정된 ECDH 공유 비밀과 연결 컨텍스트는 다음 절에서 설명하는 CMAC 기반 키 계층 구조의 입력값이 됩니다.
5.2.2 Bluetooth® EKS 키 계층 구조 구축
암호화 기반이 구축되면, EKS는 CMAC 기반 키 도출 프레임워크를 사용하여 ‘키 스케줄을 통한 암호화 시작(Encryption Start with Key Schedule)’ 절차 중에 교환된 정보를 Bluetooth® LE 링크 Layer 암호화에서 사용되는 암호화 자료로 변환합니다. 그림 5.2.2는 이러한 변환을 수행하는 데 사용되는 키 계층 구조를 보여줍니다.
그림 5.2.2에서 볼 수 있듯이, EKS는 장기 키(Long Term Key)로부터 세션 키(Session Key)를 직접 생성하는 대신, 구조화된 계층 구조를 통해 암호화 자료를 도출하고 관리합니다. k2, ee12, kv12, k3와 같은 레이블은 이 계층 구조의 각 단계에서 적용되는 CMAC 기반 도출 함수를 나타냅니다. 그림에서 직사각형은 암호 함수를, 둥근 상자는 암호 값을, 음영 처리된 상자는 EKS 수명 주기 내의 이벤트를 나타냅니다.
그림 5.2.2에 표시된 함수 및 태그에 대한 자세한 정의는 Bluetooth® 핵심 사양 제6권, 파트 E, 제4절에서 확인할 수 있습니다. 따라서 이 개요에서는 각 도출 함수의 수학적 연산보다는 계층 구조의 목적과 그 결과로 도출된 암호학적 자료의 역할에 중점을 둡니다.
Bluetooth® 핵심 사양, 제6권, E부, 제4절, 그림 4.1.
계층 구조를 초기화하기 위해 EKS는 ‘암호화 시작 및 키 스케줄(Encryption Start with Key Schedule)’ 절차와 관련된 여러 암호화 입력값을 결합합니다:
- ECDH 공유 비밀: 두 장치 모두 LL_ENC_ECDH_REQ 및 LL_ENC_ECDH_RSP에서 교환된 공개 키를 바탕으로 각각 독립적으로 계산합니다.
- 장기 키: 기존 블루투스 보안 연결이 설정된 경우 호스트가 제공함
- AA: ACL 연결의 액세스 주소
- HPA: ACL 연결이 존재하는 경우 해당 연결의 HDT 패킷 주소이며, 그렇지 않은 경우 1바이트 값인 0x00
- PDU_C: 중앙에서 전송한 LL_ENC_ECDH_REQ PDU의 CtrData 필드
- PDU_P: 주변 기기에서 전송한 LL_ENC_ECDH_RSP PDU의 CtrData 필드
AA, HPA, PDU_C 및 PDU_P는 함께 도출 과정에 필요한 연결별 컨텍스트를 제공합니다. PDU_C와 PDU_P에는 암호화 설정 과정에서 교환된 암호화 플래그, 난수, 공개 키 유형 및 공개 키가 포함됩니다. 또한 Bluetooth® 핵심 사양은 PDU_C 및 PDU_P가 AES-CMAC 계산에 제공될 때 사용되는 옥텟 순서를 정의하여, 두 컨트롤러가 모두 동일한 유도 입력을 생성하도록 보장합니다.
ECDH 공유 비밀, 해당 LTK 및 연결별 컨텍스트를 결합함으로써, EKS는 그 결과로 도출된 암호화 자료를 ACL 연결 및 EKS 협상에 바인딩합니다. 따라서 EKS는 단순히 ECDH 결과를 세션 키로 변환하는 것 이상의 역할을 수행합니다. EKS는 구조화된 도출 프로세스 내에서 새로 도출된 ECDH 자료, 사용 가능한 경우 기존 블루투스 자격 증명, 그리고 현재 연결의 컨텍스트를 결합합니다.
이 과정에서 생성되는 첫 번째 중간 값은 ‘파생 비밀( Derived Secret)’이며, 이는 EKS 계층 구조의 진화하는 루트를 형성합니다. 파생 비밀은 하나 이상의 ‘트래픽 비밀(Traffic Secret)’을 생성하는 데 사용되며, 각 트래픽 비밀은 이후 AES-CCM 암호화에 필요한 세션 키(Session Key)와 초기화 벡터(Initialization Vector)를 생성하는 데 사용됩니다.
이러한 계층적 구조는 연결 수준의 암호화 기반과 개별 전송 프로토콜에서 사용하는 암호화 방식을 분리합니다. 다음 섹션에서 설명하듯이, 이를 통해 EKS는 ACL 연결 및 관련 CIS 전송 프로토콜에 대해 독립적인 암호화 컨텍스트를 생성할 수 있을 뿐만 아니라, 향후 키 갱신 작업의 기반도 마련합니다.
5.2.3 ACL 및 CIS 암호화 자료 관리
그림 5.2.2에서 소개된 계층적 구조를 통해 Bluetooth® EKS는 공통된 암호화 기반을 유지하면서 서로 다른 전송 유형에 대해 암호화 자료를 독립적으로 관리할 수 있습니다. EKS는 연결과 관련된 모든 트래픽에 대해 단일 세션 키를 생성하는 대신, ‘트래픽 시크릿(Traffic Secrets)’을 사용하여 전송 유형별 암호화 컨텍스트를 생성합니다.
ACL 암호화가 설정되면 EKS는 해당 연결과 연관된 파생 비밀(Derived Secret)을 기반으로 ACL 트래픽 비밀(ACL Traffic Secret )을 생성합니다. 이 ACL 트래픽 비밀은 이후 AES-CCM이 암호화된 ACL 연결상의 트래픽을 보호하는 데 사용하는 세션 키와 초기화 벡터(IV)를 도출하는 데 활용됩니다. 파생 비밀과 트래픽 비밀은 컨트롤러 내부에만 유지되며 EKS 프레임워크 외부로 노출되지 않습니다.
새로운 CIS(Connected Isochronous Stream)가 생성되면, EKS는 새로운 전송을 위해 추가적인 암호화 자료를 생성하여 계층 구조를 확장합니다. 두 장치는 현재의 파생 비밀(Derived Secret)과 해당 CIG_ID 및 CIS_ID 값을 함께 사용하여, 새로운 파생 비밀과 해당 스트림과 연관된 초기 CIS 트래픽 비밀을 생성합니다. 그런 다음 CIS 세션 키와 초기화 벡터는 CIS 트래픽 비밀로부터 도출됩니다.
따라서 그림 5.2.2는 단일 선형 사슬이 아닌 분기형 계층 구조로 보아야 한다. ACL 연결은 자체 ACL 트래픽 시크릿과 이에 대응하는 세션 키 자료를 유지하는 반면, 각 관련 CIS는 독립적인 CIS 트래픽 시크릿과 세션 키를 유지한다. 새로운 CIS가 생성되면 계층 구조에서 사용되는 파생 시크릿도 갱신된다.
이러한 전송 방식별 분기는 EKS가 ‘파생 비밀(Derived Secret)’ 및 ‘트래픽 비밀(Traffic Secret)’ 계층을 도입한 주된 이유 중 하나입니다. EKS는 ACL 및 CIS 전송 방식에 대해 별도의 트래픽 비밀을 유지함으로써, 공통된 연결 수준 신뢰 기반을 유지하면서도 통신 스트림 간에 암호학적 분리를 제공합니다. 따라서 동일한 EKS 계층 구조에서 비롯된 다수의 전송 컨텍스트라도 동일한 세션 키를 공유하지 않고 공존할 수 있습니다.
5.2.4 기회적 암호화
이전 절에서 설명한 전송별 암호화 컨텍스트는 암호화 기반이 어떻게 구축되었는지에 관계없이 Bluetooth® EKS 계층 구조를 통해 생성 및 관리됩니다. 가장 일반적인 경우, EKS는 호스트가 제공하는 장기 키(LTK)를 사용하여 초기화됩니다. 그러나 이전에 설정된 Bluetooth 보안 관계가 없는 경우에도 동일한 아키텍처가 작동할 수 있습니다. 이러한 작동 모드를 ‘기회적 암호화(opportunistic encryption)’라고 합니다.
기회적 암호화(Opportunistic encryption)를 사용하면 두 기기가 사전 페어링이나 본딩 없이도 암호화된 통신을 설정할 수 있습니다. 기기들은 본딩된 장기 키(LTK)에 의존하는 대신, ‘키 스케줄을 통한 암호화 시작(Encryption Start with Key Schedule)’ 절차 중에 설정된 ECDH 공유 비밀과 Bluetooth® 핵심 사양에 정의된 고정된 전 0 값의 LTK를 함께 사용합니다.
중앙 장치는 LL_ENC_ECDH_REQ의 해당 플래그를 통해 기회적 암호화를 요청합니다. 주변 장치는 ‘기회적 암호화 호스트 지원’ 기능 이 사용 가능한 경우에만 이 모드를 수락합니다. 그렇지 않은 경우, 주변 장치는 ‘암호화 모드 수락 불가’ 오류와 함께 요청을 거부합니다.
호스트에서 제공한 LTK를 사용하는 기존의 EKS 운영 방식과 달리, 기회적 암호화는 모두 0으로 구성된 LTK 값을 사용합니다. 이러한 차이점을 제외하면, 연결에 필요한 암호화 자료를 생성하고 유지 관리하는 데에는 동일한 설정, 도출 및 키 관리 절차가 사용됩니다.
사전 페어링이나 본딩 없이도 암호화된 통신을 허용함으로써, 기회형 암호화는 Bluetooth® LE 암호화가 적용될 수 있는 시나리오의 범위를 넓혀줍니다. 그러나 사전에 설정된 Bluetooth 신뢰 관계가 없기 때문에, 기회형 암호화는 중간자 공격(man-in-the-middle)에 대한 보호 기능을 제공하지 않습니다. Bluetooth® 핵심 사양(Core Specification)에서는 기회형 암호화의 기밀성 및 무결성 특성이 ‘ LE 보안 연결 Just Works’ 연결 모델을 사용하여 페어링된 장치와 동등하다고 설명하고 있습니다.
5.2.5 암호화 자료 업데이트
앞서 설명한 전송별 암호화 컨텍스트는 EKS 계층 구조가 관리하는 ‘트래픽 시크릿(Traffic Secrets)’을 기반으로 구축됩니다. 앞 섹션에서 설명한 ACL 및 CIS 세션 키는 원래의 암호화 기반에서 직접 파생된 것이 아니라 트래픽 시크릿에서 파생되므로, Bluetooth® EKS는 전체 계층 구조를 반드시 재구축하지 않고도 연결이 유지되는 동안 암호화 자료를 동적으로 변경할 수 있습니다.
EKS는 암호화 자료 업데이트를 위해 ‘암호화 재시작’과 ‘암호화 갱신’이라는 두 가지 방식을 지원합니다.
암호화 다시 시작
일부 상황에서는 새로운 암호화 컨텍스트를 사용하여 암호화를 다시 설정해야 합니다. 이러한 기능을 지원하기 위해 Bluetooth® LE는 ‘암호화 일시 중지(Encryption Pause)’ 절차를 사용합니다.
‘암호화 일시 중지’ 절차가 진행되는 동안 암호화는 일시적으로 중단되며, 암호화가 다시 활성화되기 전에 캡슐화된 ‘암호화 시작’ 절차가 실행됩니다. 일시 중지 기간 동안 데이터 PDU는 암호화되지 않은 상태로 전송되지 않습니다.
처음에 EKS를 사용하여 연결을 설정했다면, 재시작 시에도 동일한 ‘키 스케줄을 사용한 암호화 시작(Encryption Start with Key Schedule)’ 절차가 사용됩니다. 이 과정은 5.2.1절에 설명된 키 설정 단계를 사실상 반복하여, 새로운 세션 키 자료를 생성하기 전에 새로운 암호화 기반을 구축하고 EKS 계층 구조를 재구성합니다. 이 절차 전반에 걸쳐 기존 연결은 유지됩니다. 캡슐화된 재시작 절차 중에는 기회적 암호화가 허용되지 않습니다.
암호화 갱신
EKS는 또한 전체 암호화 컨텍스트를 재구축하지 않고도 암호화 자료를 갱신할 수 있도록 지원합니다.
암호화 재시작과 달리, 새로고침 작업은 전적으로 기존 EKS 계층 구조 내에서 이루어집니다. ECDH 교환을 반복하거나 암호화 기반을 재구축하는 대신, 두 디바이스 모두 기존 ACL 트래픽 시크릿을 업데이트하고, 업데이트된 값을 바탕으로 새로운 세션 키와 초기화 벡터를 도출합니다. 원래의 ECDH 공유 비밀, 도출된 비밀 및 연결별 컨텍스트는 변경되지 않습니다.
ACL 세션 키를 갱신해도 패킷 카운터나 페이로드 번호는 재설정되지 않습니다. 키 변경 전에 페이로드가 전송되었고, 이후 재전송해야 하는 경우, 해당 페이로드는 다시 암호화되며 새로운 세션 키를 사용하여 MIC가 재계산됩니다.
재시작과 갱신은 모두 궁극적으로 새로운 세션 키를 생성하지만, EKS 계층 구조에서 서로 다른 수준에서 작동합니다. 암호화를 재시작하면 새로운 암호화 시작 절차를 통해 암호화 컨텍스트를 재구축하는 반면, 암호화를 갱신하면 ACL 트래픽 시크릿을 업데이트하고 그 업데이트된 값을 바탕으로 새로운 세션 키를 도출함으로써 기존 암호화 컨텍스트를 발전시킵니다. 실제로 갱신 작업을 통해, 처음에 연결을 설정할 때 수행했던 ECDH 교환 과정을 반복하지 않고도 새로운 세션 키를 도입할 수 있습니다.
이러한 차이점은 EKS 아키텍처에 Traffic Secrets를 도입함으로써 얻는 주요 이점 중 하나를 잘 보여줍니다. 즉, 암호화 자료가 원래의 키 설정 프로세스와는 별개로 발전할 수 있다는 점입니다.
5.2.6 MIC 선정 및 HDT 작동
‘키 일정을 사용한 암호화 시작’ 절차는 암호화 키를 설정하고 관리하는 것 외에도, 연결에 무결성 보호가 어떻게 적용될지 결정합니다.
'키 스케줄을 통한 암호화 시작(Encryption Start with Key Schedule)' 절차 중에 교환되는 암호화 플래그는 연결의 메시지 무결성 코드(MIC) 동작을 결정합니다.
GFSK PHY에서 작동하는 연결은 32비트 MIC를 사용합니다. LE HDT PHY 작동의 경우, 중앙 장치와 주변 장치 모두 64비트 MIC 사용이 허용된다고 표시하면 64비트 MIC가 사용됩니다. 그렇지 않은 경우에는 128비트 MIC가 사용됩니다.
따라서 MIC 길이는 암호화가 시작된 후에 별도로 결정되는 것이 아니라, EKS 암호화 설정의 일환으로 선택됩니다. 선택된 MIC 동작은 Bluetooth® EKS 계층 구조에 통합된 연결 컨텍스트의 일부가 됩니다.
LE HDT PHY에서 사용되는 MIC 길이는 이후 PHY 업데이트 및 암호화 갱신 절차를 통해 수정될 수 있으며, 이를 통해 EKS 프레임워크 내에서 PHY 특성 및 관련 무결성 보호 매개변수의 변경을 조정할 수 있습니다.
EKS는 원래 Bluetooth® HDT와 함께 도입되었지만, 독립적인 컨트롤러 기능 로 정의됩니다. 따라서 HDT는 EKS 프레임워크의 유일한 존재 이유가 아니라, 그 프레임워크의 한 가지 응용 사례로 간주되어야 합니다.
이 섹션 전반에 걸쳐 설명된 기능들, 즉 계층적 키 도출, 전송 방식별 트래픽 시크릿(Traffic Secrets), 기회적 암호화(opportunistic encryption), 암호화 재개(encryption restart), 그리고 트래픽 시크릿 재사용( 키 갱신) 등은 HDT를 넘어선 블루투스 기술을 지원할 수 있는 재사용 가능한 보안 기반을 마련합니다.
5.2.7 다이버시파이어를 이용한 암호화와의 비교
블루투스® EKS가 암호화 키를 설정, 도출 및 관리하는 방식을 살펴본 후, 이 아키텍처를 기존의 ‘다이버시파이어를 이용한 암호화 시작(Encryption Start with Diversifiers)’ 절차와 비교해 보는 것이 유용합니다. 두 접근 방식 모두 궁극적으로 LL_START_ENC_REQ 및 LL_START_ENC_RSP 핸드셰이크를 사용하여 연결을 암호화 모드로 전환합니다. 주요 차이점은 해당 핸드셰이크 이전에 교환되는 정보와, 그 결과로 도출된 암호화 키가 어떻게 도출되고 이후 관리되는지에 있습니다.
표 5.2.7은 기존의 ‘Diversifiers를 사용한 암호화 시작(Encryption Start with Diversifiers)’ 절차와 EKS 프레임워크 간의 주요 아키텍처적 차이점을 요약하고 있다.
| 양상 | 다이버시파이어를 이용한 암호화 | EKS |
|---|---|---|
| 암호학 재단 | LTK + SKD/IV | ECDH 공유 비밀 + LTK + 연결 컨텍스트 |
| 주요 구조 | 세션 키 | 파생 비밀 → 트래픽 비밀 → 세션 키 |
| 수송 분리 | 정의되지 않음 | ACL과 CIS 트래픽의 비밀을 구분하기 |
| 주요 업데이트 | 암호화 다시 시작 | 암호화 다시 시작 또는 새로 고침 |
| 상황에 따른 암호화 | 지원되지 않음 | 지원됨 |
5.3 요약
블루투스® 암호화 키 스케줄은 블루투스® LE 암호화 자료를 설정하고 관리하기 위한 계층적 프레임워크를 도입합니다. 이 프레임워크는 ECDH 공유 비밀, 해당 장기 키(Long Term Key), 그리고 연결별 컨텍스트를 결합하여 ACL 및 CIS 전송을 위한 독립적인 암호화 자료를 도출합니다.
EKS는 또한 기회적 암호화, 암호화 재시작, 연결 중 암호화( 키 갱신) 및 향상된 MIC(MIC) 기능을 지원합니다. 이러한 기능들은 종합적으로 HDT에 필요한 보안 기반을 제공하면서도, EKS가 독립적이고 재사용 가능한 블루투스(Bluetooth 기능)로 남을 수 있도록 합니다.
6. 블루투스® 일시적 애플리케이션 키(TAK)
6.1 배경
6.1.1 블루투스 보안 아키텍처의 발전
블루투스는 오랫동안 기기 간 신뢰를 구축하고 통신을 보호하기 위한 메커니즘을 제공해 왔습니다. 이러한 메커니즘은 다음과 같은 몇 가지 핵심 보안 기능을 기반으로 합니다:
- 기기 간에 공유 비밀 키를 설정하는 페어링
- 본딩은 향후 사용을 위해 해당 키들을 저장하는 과정입니다
- 공유 키 자료의 소유권을 확인하는 장치 인증
- 전송 중인 데이터의 기밀성을 보호하는 암호화
- 데이터의 무단 변조를 방지하는 메시지 무결성
시간이 지남에 따라 블루투스 보안 아키텍처는 기존의 BR/EDR 메커니즘에서 LE 보안 연결 와 같은 보다 진보된 방식으로 발전해 왔습니다. 기반이 되는 암호화 기술은 크게 개선되었지만, 운영 모델은 대체로 변함없이 유지되어 왔습니다.
대부분의 경우, 블루투스 보안은 기기들이 페어링을 통해 신뢰 관계를 구축한 후, 본딩을 통해 그 신뢰 관계를 유지한다고 가정합니다. 그 결과, 보안 상태 은 여러 연결과 상호 작용에 걸쳐 지속됩니다.
이 모델은 스마트폰, 웨어러블 기기, 헤드폰, 입력 장치 등 시간이 지남에 따라 반복적으로 통신하는 기기에 적합합니다. 다만, 이 모델은 신뢰 관계가 오랫동안 지속되며 유지할 가치가 있다고 가정합니다.
6.1.2 일시적 상호작용에서 상태 유지 페어링의 한계
블루투스® LE가 새로운 응용 분야로 확대됨에 따라, 상호작용의 상당수가 지속적인 관계가 아닌 단기적이고 거래 중심의 형태로 변화하고 있습니다. 현재 블루투스는 디지털 키, 출입 통제 시스템, 티켓팅, 인증 정보 기반 접근, 공유 인프라, 임시 기기 프로비저닝과 같은 시나리오에서 빈번하게 사용되고 있으며, 이러한 경우 기기 간 상호작용은 단 한 번만 이루어지거나 관계가 종료되기 전까지 제한된 기간 동안만 지속됩니다.
이러한 상황에서 기존의 페어링 기반 보안 모델은 불필요한 복잡성을 초래할 수 있습니다. 페어링과 본딩은 기기 간에 장기적인 신뢰 관계를 구축하고 유지하도록 설계되어, 향후 연결 시에도 키와 보안 설정을 재사용할 수 있게 해줍니다. 그러나 상호작용이 일시적인 경우, 지속적인 보안을 유지하는 것이 별다른 이점을 제공하지 못할 수 있습니다.
이로 인해 몇 가지 문제가 발생할 수 있습니다. 일시적인 상호작용이라도 장기적인 연결 정보를 생성할 수 있으며, 이로 인해 기기의 제한된 저장 공간이 소모될 수 있습니다. 또한, 클라우드 기반 신원 확인 서비스, 디지털 자격 증명, 인증서 또는 기타 애플리케이션별 인증 시스템과 같이 블루투스 스택 외부의 메커니즘을 통해 이미 신뢰 관계가 구축되었을 수도 있습니다. 따라서 암호화 키를 얻기 위해서만 페어링을 수행하면, 이미 완료된 인증 절차가 중복될 수 있습니다.
이러한 추세는 시스템 설계의 광범위한 변화를 반영합니다. 최신 애플리케이션은 신원 관리와 전송 기술을 점점 더 분리하고 있어, 인증 및 신뢰 관련 결정은 애플리케이션 수준에서 처리되는 한편, 통신 기술은 교환되는 데이터의 보호에 집중할 수 있게 되었습니다.
이 모델을 지원하기 위해 블루투스는 페어링이나 본딩 없이도 ‘ 링크 Layer ’ 암호화를 가능하게 하는 비페어링 보안 아키텍처를 도입했습니다. 이 방식에서는 인증 및 키 설정이 상위 계층 애플리케이션에 의해 수행되는 한편, 블루투스는 무선 링크를 통해 교환되는 데이터에 대해 표준화된 전송 보호 기능을 계속 제공합니다.
이 접근 방식은 기존의 페어링 기반 모델을 대체하기보다는, 장기적인 신뢰 관계를 유지하는 것이 필요하지도 바람직하지도 않은 일시적이고 세션 기반의 상호작용을 지원하도록 블루투스 보안 아키텍처를 확장합니다.
6.2 기술 개요
6.2.1 일시적 애플리케이션 키(TAK)란 무엇인가
일시적 애플리케이션 키(TAK)는 상위 계층 애플리케이션에서 제공되는 128비트 비밀 키로, 블루투스® LE 연결에 대한 링크 Layer 암호화를 설정하는 데 사용됩니다. 기능적으로는 암호화 절차 중 장기 키(LTK)와 동일한 목적을 수행하지만, 생성 및 관리 방식에서는 근본적으로 다릅니다.
기존의 Bluetooth® LE 보안 방식은 보안 관리자 프로토콜(SMP)이 관리하는 페어링 절차를 통해 암호화 키를 도출합니다. 반면, TAK는 상위 계층 애플리케이션이나 사양에 정의된 인증 및 키 설정 과정을 통해 생성됩니다. Bluetooth 보안 관리자는 키 생성 과정에 관여하지 않습니다.
그 결과, 신뢰 관계 구축은 전송 보안과 분리됩니다. 인증은 상위 계층 애플리케이션에서 수행되는 반면, 블루투스는 공유 키가 설정되면 표준화된 링크 Layer 암호화를 제공합니다.
TAK의 수명은 의도적으로 일시적입니다. TAK는 암호화 시작 절차 중에 사용될 수 있도록 블루투스 호스트에 제공되며, 절차가 시작된 후 호스트에 의해 폐기됩니다. 본딩 관계는 형성되지 않으며, 장기적인 블루투스 보안 상태 도 유지되지 않습니다.
6.2.2 비쌍을 이루는 보안 아키텍처
Bluetooth® TAK은 ‘비페어링 보안 모델’로 알려진 Bluetooth® LE용 새로운 보안 아키텍처를 도입합니다. 페어링과 본딩을 통해 신뢰 관계를 구축하는 기존의 Bluetooth 보안 방식과 달리, 이 모델은 보안 관리자(Security Manager)를 사용하지 않고도 암호화된 연결을 설정할 수 있게 해줍니다.
이 아키텍처에서 상위 계층 애플리케이션은 상대 기기를 인증하고 공유 비밀 키를 설정합니다. 이렇게 생성된 TAK은 블루투스 호스트에 전달되어 블루투스 보안 채널( 링크 Layer ) 암호화를 시작하는 데 사용됩니다. GAP, ATT, L2CAP 및 컨트롤러를 포함한 나머지 블루투스 프로토콜 스택( 프로토콜 스택)은 정상적으로 계속 작동합니다.
그림 6.2.2에서 볼 수 있듯이, 인증을 담당하는 애플리케이션은 블루투스 보안 관리자(Bluetooth Security Manager) 외부에서 작동합니다. 이 애플리케이션은 블루투스 페어링 절차에 참여하는 대신, 직접 신뢰 관계를 수립하고 호스트(Host)에 일시적 애플리케이션 키(Transient Application Key)를 제공합니다. 그런 다음 블루투스 스택은 이 키를 사용하여 연결이 유지되는 동안 보안 채널( 링크 Layer ) 암호화를 설정하고 유지합니다.
아키텍처상의 주요 차이점은 TAK으로 보안이 적용된 연결에는 SMP(Security Manager Protocol)가 관여하지 않는다는 점입니다. 페어링, 키 생성 및 본딩 단계가 생략되므로, 블루투스가 여전히 링크 Layer 의 기밀성 및 무결성 보호 기능을 제공하는 동시에 신뢰성 확립은 상위 계층 애플리케이션에 위임될 수 있습니다. 따라서 이 모델 하에서 작동하는 기기들은 암호화되지만, 페어링되거나 본딩되지는 않습니다.
그 결과, 지속적인 신뢰 관계를 형성하지 않고도 연결을 암호화할 수 있는 아키텍처가 구현되었습니다. 인증 및 키 설정은 블루투스 보안 프레임워크 외부에서 처리되며, 기존의 블루투스® LE 암호화 메커니즘은 변경되지 않습니다.
비페어링 보안 모델은 TAK가 Bluetooth® LE 아키텍처에 어떻게 통합되는지를 정의하지만, 이 모델에 대한 지원은 새로운 Bluetooth® LE 보안 모드의 도입을 통해 공식화됩니다. 다음 섹션에서는 보안 모드 4가 기존의 Bluetooth® LE 보안 프레임워크를 어떻게 확장하는지 설명합니다.
6.2.3 LE 보안 모드 및 모드 4의 도입
Bluetooth® LE는 다양한 통신 요구 사항을 충족하기 위해 여러 가지 보안 모드를 정의하고 있습니다. Bluetooth® TAK가 도입되기 전, Bluetooth LE는 지점 간 LE 연결을 보호하기 위한 보안 모드 1과 암호화된 브로드캐스트 통신을 보호하기 위한 보안 모드 3을 지원했습니다. 이 두 모드는 결합되어 연결 지향형 및 브로드캐스트 기반 통신 시나리오를 모두 보호하는 메커니즘을 제공했습니다.
비페어링 보안 모델의 도입으로 이 프레임워크에 새로운 보안 모드인 ‘LE 보안 모드 4’가 추가되었습니다. 페어링이나 브로드캐스트 키 배포와 같은 블루투스 관리형 보안 절차에 의존하는 기존 보안 모드와 달리, 보안 모드 4는 상위 계층 애플리케이션에서 제공하는 일시적 애플리케이션 키(Transient Application Key)를 사용하여 암호화된 연결을 가능하게 합니다.
| 보안 모드 | 보안 수준 | 묘사 |
|---|---|---|
| 모드 1 | 1단계 | 인증 없음, 암호화 없음 |
| 2단계 | 암호화가 적용된 인증되지 않은 페어링 | |
| 3단계 | 암호화가 적용된 인증 기반 페어링 | |
| 4단계 | 128비트 강도의 암호화 키를 사용하여 암호화된, 인증된 LE 보안 연결 페어링 | |
| 모드 3 | 1단계 | 보안 없음 |
| 2단계 | 인증되지 않은 Broadcast_Code 사용 | |
| 3단계 | 인증된 Broadcast_Code의 사용 | |
| 모드 4 (신규) | 2단계 | 일시적 애플리케이션 키(TAK)를 사용한 암호화된 일시적 연결 |
표 6.2.3에 나와 있듯이, 보안 모드 1은 여전히 지점 간 LE 연결을 보호하는 주요 메커니즘으로 사용되고 있습니다. 보안은 보안 관리자 프로토콜(SMP)이 관리하는 블루투스 페어링 절차를 통해 설정되며, 보안 수준이 높을수록 더 강력한 인증 및 암호화 요구 사항이 적용됩니다. 오늘날 대부분의 블루투스® LE 기기는 보안 모드 1을 사용하여 작동합니다.
보안 모드 3은 브로드캐스트 아이소크로너스 스트림(BIS)을 보호함으로써 또 다른 유형의 통신을 다룹니다. 모드 3은 페어링을 통해 암호화 키를 도출하는 대신, Broadcast_Code를 사용하여 암호화된 브로드캐스트 콘텐츠에 대한 접근을 제어합니다. 보안 수준에 따라 Broadcast_Code가 인증된 메커니즘을 통해 배포될지, 아니면 인증되지 않은 메커니즘을 통해 배포될지가 결정됩니다.
보안 모드 4의 도입은 블루투스® LE 보안에 근본적으로 다른 접근 방식을 제시합니다. 보안 모드 1이 블루투스 페어링 절차를 통해 신뢰를 구축하고 본딩을 통해 그 신뢰를 유지하는 반면, 모드 4는 인증 및 키 설정이 상위 계층 사양에 의해 외부에서 수행된다고 가정합니다. 블루투스는 이렇게 생성된 일시적 애플리케이션 키(Transient Application Key)를 사용하여 본딩을 생성하거나 장기적인 보안 관계를 유지하지 않고도 일시적 애플리케이션 키( 링크 Layer ) 암호화를 설정합니다. 상태. 이로 인해 모드 4는 보안 통신이 필요하지만 지속적인 신뢰 관계가 불필요한 일시적인 상호 작용에 특히 적합합니다.
요약하자면, 보안 모드 4는 참여 장치들이 128비트 수준의 보안 강도를 가진 공유 비밀키를 설정할 수 있는 상위 계층 사양에 의해 인증을 받은 후에만 사용하도록 되어 있습니다.
6.2.4 TAK로 보안이 적용된 연결 설정
보안 모드 4에서 작동하는 기기가 상위 계층 애플리케이션으로부터 일시적 애플리케이션 키(TAK)를 획득하면, 해당 키를 사용하여 암호화된 Bluetooth® LE 연결을 설정할 수 있습니다. 기존의 Bluetooth 보안 절차와 달리, 인증 및 키 설정은 Bluetooth 스택 외부에서 이루어집니다. Bluetooth는 제공된 키를 사용하여 링크 Layer 암호화를 적용하는 역할만 담당합니다.
그림 6.2.4는 상위 계층 인증과 블루투스 링크 Layer 보호 기능 간의 구분을 보여줍니다. 페어링 기반 보안과 달리, 신뢰 관계는 블루투스 스택 외부에서 확립되며, 블루투스® LE 암호화 시작 절차가 시작되기 전에 공유 비밀키가 도출됩니다. 그림에서 볼 수 있듯이, TAK로 보호되는 연결은 다음과 같은 일련의 작업을 통해 설정됩니다:
1단계: 연결 설정
참여 기기들은 먼저 표준 Bluetooth® LE ACL 연결을 설정합니다. 이 단계에서는 연결이 아직 암호화되지 않은 상태입니다.
2단계: 상위 계층 인증
상위 계층 애플리케이션은 자체 사양에 정의된 절차를 사용하여 피어 장치를 인증합니다. 애플리케이션에 따라 인증 프로세스는 인밴드 방식으로 수행되거나 아웃오브밴드 메커니즘을 통해 수행될 수 있습니다. 이 인증 프로세스는 블루투스 보안 관리자와는 별개이며, 블루투스 보안 프레임워크 외부에서 이루어집니다.
3단계: TAK 도출 및 프로비저닝
인증에 성공하면 두 장치 모두 보안 수준이 128비트인 공유 비밀 키를 도출하거나 획득합니다. 이 비밀 키는 일시적 애플리케이션 키(TAK)가 되며, 암호화 설정 과정에서 사용하기 위해 블루투스 호스트에 제공됩니다. 기능적으로 TAK는 암호화 절차 중 장기 키(LTK)와 동일한 역할을 합니다.
4단계: 암호화 시작 절차
호스트는 TAK을 사용하여 표준 Bluetooth® LE 암호화 시작 절차를 시작합니다. 이 과정에서 TAK은 암호화 키로 링크 Layer 에 제공되며, 키가 Bluetooth 페어링 절차를 통해 생성된 것이 아니기 때문에 EDIV 및 Rand 값은 0으로 설정됩니다. 그런 다음 컨트롤러는 기존의 Bluetooth® LE 암호화 프레임워크를 사용하여 암호화된 세션을 설정합니다.
5단계: TAK 폐기
암호화 시작 절차를 시작한 후, 호스트는 TAK을 폐기합니다. 컨트롤러는 TAK을 사용하여 암호화 컨텍스트를 설정하며, 암호화 컨텍스트가 설정된 후에는 TAK을 보관하지 않습니다. 상위 계층 애플리케이션은 자체 보안 정책에 따라 키 사본을 보관하거나 폐기할 수 있습니다. 본딩 정보는 생성되지 않으며, 장기 블루투스 보안 키 상태 도 저장되지 않습니다.
6.2.5 런타임 동작 및 세션 관리
TAK로 보안이 보장된 연결이 설정되면, 그 실행 시 동작 방식은 기존의 페어링 기반 연결과는 다릅니다. 가장 큰 차이점은 보안 모드 4에서 작동하는 기기들이 보안을 유지하기 위해 페어링, 본딩 또는 보안 관리자 프로토콜(SMP)에 의존하지 않는다는 점입니다 상태. 대신, 이 연결은 상위 계층 애플리케이션이 정의한 보안 정책과 인증 과정에서 설정된 일시적 애플리케이션 키(Transient Application Key)를 함께 사용하여 작동합니다.
연결을 어떻게 보호할지 결정할 때, 이 장치는 상대 장치의 본딩 상태와 상위 계층 애플리케이션의 요구 사항을 고려합니다. 상대 장치가 이미 본딩된 상태라면, 해당 연결은 기존의 페어링 기반 보안 모델과 본딩된 장기 키(LTK)를 사용합니다. 본딩된 연결의 경우 TAK은 사용되지 않습니다. 상대 기기가 본딩되지 않았고 상위 계층 애플리케이션이 비페어링 보안 모델을 사용하도록 구성된 경우, 연결은 보안 모드 4에서 작동합니다.
보안 모드 1과 달리, 보안 모드 4에서 작동하는 장치는 보안 요구 사항을 충족하기 위해 블루투스 페어링 절차를 시작하지 않습니다. 암호화가 필요하고 유효한 TAK가 있는 경우, 호스트는 요청된 서비스에 대한 액세스를 허용하기 전에 해당 TAK를 사용하여 링크 Layer 암호화를 활성화합니다. TAK가 없는 경우, 페어링으로 되돌아가지 않고 서비스 요청이 중단됩니다.
마찬가지로, 보안 모드 4에서 작동하는 연결은 보안을 설정하기 위해 페어링을 사용하지 않습니다. 암호화가 필요한 경우, 유효한 TAK이 있어야만 링크 Layer 암호화를 설정할 수 있습니다. 보안 모드 4에서 작동하는 연결의 보안을 설정하는 대체 메커니즘으로 페어링은 사용되지 않습니다.
서비스 접근 결정은 연결의 현재 보안 수준( 상태 )과 상위 계층 사양에 정의된 정책 모두를 기반으로 이루어집니다. 서비스에 암호화가 필요한 경우, 접근이 허용되기 전에 연결이 암호화되어야 합니다. 인증 요구 사항이 있는 경우, 신뢰 구축을 담당하는 상위 계층 정책에 따라 해당 요구 사항이 충족될 때만 TAK로 보호된 연결이 허용됩니다.
보안 모드 4의 런타임 동작은 보안 모드 1과 근본적으로 다르며, 표 6.2.5에 요약되어 있습니다.
| 시나리오 | 보안 모드 4의 동작 |
|---|---|
| 암호화가 필요하지 않습니다 | 서비스 요청이 정상적으로 진행됩니다. |
| 암호화 필수, TAK 사용 가능 | 링크 Layer TAK을 사용하여 암호화가 활성화됩니다. |
| 암호화가 필요하지만 TAK이 없습니다 | 서비스 요청이 중단되었습니다. |
| 인증 필요 | 상위 계층 정책에 따라 결정됨 |
| 페어링 요청 수신됨 | 요청이 거부되었습니다. |
| 페어링을 통한 보안 강화 | 허용되지 않음 |
결과적으로, 보안 모드 4는 페어링 기반 보안의 변형이 아닌 독자적인 보안 모델로 작동합니다. 신뢰 관계는 상위 계층 애플리케이션에 의해 외부에서 확립되며, 블루투스는 연결이 유지되는 동안 링크 Layer 보호 기능을 적용하는 역할만 담당합니다.
6.2.6 TAK로 보안이 보장된 연결에서 GATT 관련 고려 사항
TAK의 세션 중심적 특성은 GATT 계층에서 애플리케이션의 동작에 영향을 미칩니다. 보안 모드 4에서 작동하는 장치는 본드(bond)를 생성하지 않기 때문에, 블루투스 스택은 연결 간에 서비스 수준의 연결 상태( 상태 )를 유지하지 않습니다. 따라서 TAK로 보안이 적용된 각 연결은 독립적인 세션으로 취급됩니다.
이러한 현상은 특히 클라이언트 특성 구성(CCC) 설정 처리 과정에서 두드러지게 나타납니다. 보안 모드 4에서는 CCC 구성이 일시적인 것으로 간주되어 연결이 종료되면 삭제됩니다. 따라서 알림이나 표시 기능이 필요한 애플리케이션은 TAK로 보안이 설정된 새로운 연결이 수립될 때마다 해당 CCC 값을 다시 구성해야 합니다.
보안 모드 4에서는 GATT 서버의 보안 요구 사항을 전달하기 위해 LE GATT 보안 수준 특성도 사용해야 합니다. 이 특성을 통해 GATT 서버는 TAK로 보안이 설정된 연결 상태에서 작동할 때, 자신의 서비스 및 속성에 접근하는 데 필요한 보안 수준을 표시할 수 있습니다.
그 결과, TAK 기반 보안은 보안 상태 과 관련 서비스 구성(service configuration)이 모두 연결이 유지되는 기간 동안에만 존재하는, 완전한 세션 지향적 운영 모델을 도입합니다. 연결이 종료되면 TAK과 세션별 서비스 구성( 상태 ) 모두 폐기됩니다.
6.2.7 보안 고려 사항
TAK은 Bluetooth® LE 연결에 대한 링크 Layer 암호화를 설정하고 유지하는 데 사용됩니다. 암호화가 설정되면, 해당 연결은 Bluetooth® LE 암호화 프레임워크가 제공하는 기밀성 및 무결성 보호 기능을 활용할 수 있습니다.
TAK를 사용하는 상위 계층 사양은 신뢰 관계를 수립하고, TAK가 생성, 획득 및 블루투스 호스트에 제공되는 방식을 결정하는 역할을 담당합니다. 여기에는 키 설정 과정을 보호하기 위해 필요한 인증 및 보안 절차가 포함됩니다.
결과적으로, TAK을 사용하는 상위 계층 사양은 다음을 담당합니다:
- 대등 장치 인증
- TAK로 사용되는 공유 비밀을 도출하거나 확보하는 것
- 중간자 공격으로부터 보호 제공
- 블루투스 호스트에 TAK을 언제, 어떻게 제공할지 규정하는 정책 정의
TAK 아키텍처의 주요 특징 중 하나는 인증 및 중간자 공격 방지가 블루투스 페어링 절차가 아닌 상위 계층 사양에 의해 제공된다는 점이다. 따라서 TAK로 보안이 보장된 연결의 보안 특성은 상위 계층 사양에서 사용하는 인증 및 키 설정 절차에 따라 달라진다.
이러한 분리를 통해 상위 계층 사양에서는 해당 애플리케이션에 적합한 인증 및 신뢰 메커니즘을 정의하는 동시에, 표준화된 Bluetooth® 링크 Layer 암호화를 사용하여 연결을 통해 교환되는 데이터를 보호할 수 있습니다.
6.3 요약
Bluetooth® 트랜지언트 애플리케이션 키(Transient Application Key)는 페어링이나 본딩 없이도 암호화된 Bluetooth® LE 연결을 가능하게 하는 새로운 비페어링 보안 모델을 도입합니다. 인증 및 키 설정은 상위 계층 애플리케이션에서 수행되며, Bluetooth는 생성된 키를 사용하여 데이터 링크 계층( 링크 Layer ) 수준의 기밀성 및 무결성 보호 기능을 제공합니다.
이러한 기능을 지원하기 위해 Bluetooth® LE는 보안 모드 4를 도입하여, 일시적인 상호 작용을 위해 특별히 설계된 새로운 옵션을 통해 기존 보안 프레임워크를 확장합니다. 기존의 페어링 기반 보안과 달리, 모드 4는 지속적인 신뢰 관계를 형성하지 않으며 장기적인 보안도 유지하지 않습니다. 상태.
TAK는 신뢰 구축과 전송 보호를 분리함으로써, 지속적인 신뢰 관계 없이도 안전한 세션 기반 통신을 지원하도록 블루투스 보안 아키텍처를 확장합니다. TAK는 기존의 페어링 기반 보안 모델을 대체하기보다는, 블루투스 스택 외부에서 신뢰를 구축하는 애플리케이션을 위한 대안적인 접근 방식을 제공함으로써 이를 보완합니다.
따라서 ‘임시 애플리케이션 키(Transient Application Key)’와 ‘보안 모드 4(Security Mode 4)’의 도입은 블루투스® LE 보안 아키텍처의 중요한 진화를 의미하며, 페어링, 본딩 또는 지속적인 신뢰 관계 없이도 안전하고 암호화된 세션 기반의 상호 작용을 가능하게 합니다.
7. 블루투스® 암호화 제품 디버깅(EPD)
7.1 배경
암호화는 사용자 데이터와 통신을 보호하는 데 매우 중요한 역할을 합니다. 하지만 동시에, 연결을 보호하는 인증 정보에 접근하지 않으면 캡처된 트래픽을 완전히 해독할 수 없기 때문에 프로토콜 분석에 어려움을 초래하기도 합니다. 블루투스® 암호화 제품 디버깅(EPD)은 인증된 디버깅 도구가 암호화된 블루투스 트래픽을 분석하는 데 필요한 활성 암호화 정보에 접근할 수 있는 표준화된 방법을 제공함으로써 이러한 문제를 해결합니다.
과거에는 롱텀 키(LTK)와 같이 페어링 과정에서 설정된 장기 보안 인증 정보를 파악함으로써 암호화된 블루투스 트래픽을 분석할 수 있는 경우가 많았습니다. 많은 배포 환경에서 이러한 인증 정보에 대한 접근만으로도 프로토콜 분석기 및 디버깅 도구가 연결의 암호화 상태 를 재구성하고, 상호 운용성 테스트, 제품 검증 및 문제 해결 활동을 수행하는 데 충분한 정보를 얻을 수 있었습니다.
그러나 블루투스 암호화 기술이 지속적으로 발전함에 따라, 활성 암호화 자격 증명이 컨트롤러 내에서 생성 및 관리되는 경우가 점점 더 늘어나고 있습니다. HCI(Host Controller Interface) 기반 아키텍처에서는 이러한 자격 증명이 호스트 및 외부 디버깅 도구에서 접근할 수 없는 상태로 남아 있을 수 있어, 암호화된 트래픽을 분석하고 문제를 해결하기가 더욱 어려워집니다. 이는 특히 EKS(Encryption Key Schedule)의 경우 더욱 두드러지는데, 이 경우 연결을 보호하는 암호화 상태 가 컨트롤러 내에서 도출되고 관리되기 때문입니다. 활성 암호화 자격 증명에 대한 표준화된 접근 방식이 없다면, 호스트 개발자는 캡처된 무선 트래픽을 복호화하기 위해 컨트롤러 키를 확보하는 데 독점적인 메커니즘을 사용해야 할 수도 있습니다. EPD는 호스트가 활성 암호화 자격 증명 상태 을 확보할 수 있는 표준화된 메커니즘을 제공함으로써 이러한 과제를 해결합니다. 이를 통해 테스트 환경에서 무선 트래픽과 HCI 트래픽을 모두 캡처할 수 있게 되며, 자동화된 디코딩, 디버깅 및 상호 운용성 테스트를 지원합니다.
이러한 과제를 해결하기 위해, 블루투스® 암호화 확장 프로파일( 제품 ) 디버깅(EPD)은 디버깅을 위해 컨트롤러가 활성 암호화 자격 증명을 로컬 호스트에 보고할 수 있도록 하는 표준화된 메커니즘을 도입합니다. EPD는 현재 연결을 보호하고 있는 암호화 상태 에 대한 가시성을 제공함으로써, 블루투스 암호화 작동 방식을 변경하지 않고도 프로토콜 분석 및 상호 운용성 디버깅 기능을 유지하는 데 도움을 줍니다.
7.2 기술 개요
7.2.1 활성 암호화 상태 파악 상태
Bluetooth® EPD는 암호화된 Bluetooth® 연결을 적극적으로 보호하고 있는 암호화 정보를 파악할 수 있게 해줍니다. EPD는 페어링 기록, 본딩 데이터베이스 또는 기타 과거 보안 정보를 노출하는 대신, 컨트롤러가 현재 유지하고 있으며 연결된 장치 간의 트래픽 교환을 보호하는 데 사용되는 암호화 상태 에 중점을 둡니다.
그림 7.2.1은 암호화 가시성이 기존의 Bluetooth® LE 암호화에서 암호화 키 스케줄(EKS) 기반 암호화로 어떻게 변화하는지를 보여줍니다.
기존의 LE 암호화 방식에서는 디버깅이 대개 장기 키(LTK)를 파악하는 것에서 시작됩니다. 활성 암호화 세션 키( 상태 )는 일반적으로 LTK와 암호화 설정 과정에서 교환된 정보를 바탕으로 재구성할 수 있기 때문에, 프로토콜 분석기는 대개 세션 키를 도출하여 캡처된 트래픽을 복호화할 수 있습니다.
그러나 EKS를 사용하면 이 과정이 더 복잡해집니다. 그림 7.2.1에서 볼 수 있듯이, EKS는 내부 키 계층 구조를 도입하는데, 이 구조에서는 ECDH로 도출된 공유 비밀과 기타 암호화 입력값을 사용하여 트래픽 비밀을 도출하고, 이를 통해 연결을 보호하는 세션 키와 초기화 벡터(IV)가 생성됩니다. 이러한 조건 하에서는 장기 자격 증명만으로는 현재 사용자 트래픽을 보호하고 있는 활성 암호화 상태 를 파악하기에 충분한 정보를 제공하지 못할 수 있습니다.
EPD는 페어링이나 본딩 과정에서 사용되는 장기 인증 정보 대신, 활성 암호화 상태 에 대한 가시성을 제공함으로써 이러한 과제를 해결합니다. EPD는 LTK를 보고하는 대신, 암호화된 연결과 관련된 세션 키와 IV를 보고하므로, 디버깅 도구가 컨트롤러가 능동적으로 유지하는 암호화 컨텍스트와 지속적으로 동기화될 수 있습니다.
7.2.2 EKS 기반 암호화 모드
그림 7.2.1에 표시된 능동형 암호화 상태 를 더 잘 이해하기 위해서는, 암호화 키 스케줄(EKS) 프레임워크를 사용할 때 암호화 자격 증명이 어떻게 설정되는지 간략히 살펴보는 것이 도움이 됩니다.
두 장치 모두 EKS를 지원하는 경우, ‘키 스케줄을 사용한 암호화 시작(Encryption Start with Key Schedule)’ 절차를 통해 암호화가 설정됩니다. 기존의 LE 암호화와는 달리, EKS는 ECDH로 생성된 공유 비밀과 추가적인 암호화 입력값을 사용하여 연결을 보호하는 암호화 세션 키( 상태 )를 설정하는, 컨트롤러가 관리하는 키 도출 절차를 도입합니다. 이러한 절차를 통해 최종적으로 트래픽을 암호화하는 데 사용되는 세션 키와 IV가 생성됩니다.
EKS는 두 가지 배포 모델을 지원합니다.
- 장기 키(LTK)가 적용된 EKS
이 모드에서는 호스트가 제공하는 LTK가 ECDH로 생성된 공유 비밀 및 암호화 설정 과정에서 교환되는 기타 암호화 입력값과 함께 도출 과정에 참여합니다. 이렇게 도출된 트래픽 비밀은 이후 연결을 보호하는 세션 키와 IV를 도출하는 데 사용됩니다.
- 상황에 따른 암호화
이 모드에서는 이전에 배포된 LTK에 의존하지 않고 EKS 프레임워크를 통해 암호화가 설정됩니다. 이 사양에서는 LTK 입력을 값이 0인 키로 정의하며, 세션 키와 IV는 ECDH 교환 및 관련 EKS 절차에서 도출됩니다.
암호화가 어떻게 설정되든 상관없이, 두 배포 모델 모두 궁극적으로 컨트롤러 내에 연결을 보호하는 세션 키와 IV로 표현되는 활성 암호화 상태 를 생성합니다. 이 값들은 EPD에 의해 보고되며, HCI(Host Controller Interface)를 통해 디버깅 도구에 제공됩니다.
7.2.3 Bluetooth® EPD 보고 메커니즘
활성 암호화 상태 에 대한 표준화된 접근을 제공하기 위해, EPD는 경량형 HCI(Host Controller Interface) 보고 프레임워크를 도입합니다. 기능 는 보고 동작을 관리하는 데 사용되는 두 가지 HCI 명령과, 호스트에 암호화 정보를 전달하는 데 사용되는 하나의 HCI 이벤트로 구성됩니다.
EPD는 통제된 개발, 테스트 및 상호운용성 환경에서 사용하도록 설계되었으며, 일반적인 제품 운영 중에는 활성화되어서는 안 됩니다.
표 7.2.3a는 EPD 기능 에서 제시한 HCI 요소를 요약한 것이다.
| 구성 요소 | 목적 |
|---|---|
| 암호화 키 디버그 보고 모드 명령어 읽기 | 현재 EPD 보고 설정을 읽어옵니다. |
| 암호화 키 디버그 보고 모드 명령어 작성 | 암호화 보고 기능을 활성화하거나 비활성화합니다. |
| 암호화 키 디버그 보고서 이벤트 | 활성 연결과 관련된 암호화 정보를 보고합니다. |
표 7.2.3a에 표시된 바와 같이, ‘읽기 및 쓰기 암호화 키 디버그 보고 모드’ 명령을 통해 호스트는 보고 동작을 조회하고 구성할 수 있으며, ‘암호화 키 디버그 보고서’ 이벤트는 디버깅 도구에 필요한 실제 암호화 정보를 제공합니다. 이러한 기능들이 결합되어, 벤더별 진단 기능 없이도 HCI를 통해 암호화 정보를 노출할 수 있는 표준화된 메커니즘이 마련됩니다.
‘암호화 키 디버그 보고서(Encryption Key Debug Report, EPD)’ 이벤트에는 연결의 활성 암호화 키( 상태 )와 관련된 정보가 포함됩니다. 표 7.2.3b에 표시된 바와 같이, EPD는 LTK와 같은 장기 자격 증명 대신 현재 암호화 연결과 연관된 세션 키 및 IV를 보고합니다. 이러한 값들은 컨트롤러가 능동적으로 관리하는 암호화 키( 상태 )를 나타내며, 트래픽을 암호화하고 복호화하는 데 사용되는 정보와 직접적으로 일치합니다.
| 매개변수 | 묘사 |
|---|---|
| 연결 핸들 | 암호화된 연결을 식별합니다 |
| 세션 키 | 해당 연결과 관련된 암호화 키 |
| 세션 키 길이 | 세션 키의 길이 |
| IV | 해당 연결과 관련된 초기화 벡터 |
| IV. 길이 | 초기화 벡터의 길이 |
7.2.4 이벤트 생성 동작
Bluetooth® EPD는 이벤트 기반 보고 모델을 따릅니다. 컨트롤러는 암호화 정보를 지속적으로 보고하는 대신, 연결에 대해 새로운 암호화 자격 증명 상태 이 활성화될 때만 ‘암호화 키 디버그 보고서 이벤트’를 생성합니다. 이러한 접근 방식은 활성 암호화 자격 증명이 변경될 때마다 디버깅 도구가 최신 암호화 정보를 수신하도록 보장하는 동시에, 불필요한 보고 오버헤드를 방지합니다.
| 트리거 이벤트 | 암호화 키 디버그 보고서 생성됨 |
|---|---|
| HCI_암호화_변경 | 예 |
| HCI_암호화_키_갱신_완료 | 예 |
| HCI_LE_CIS_설립됨 | 예 |
표 7.2.4에 표시된 바와 같이, 보고서 생성은 연결의 암호화 상태 변경 사항과 직접적으로 연동됩니다. 암호화가 처음 활성화되거나, 기존 세션 키가 갱신되거나, 새로운 암호화된 CIS가 사용 가능해지면 컨트롤러는 해당 연결과 관련된 암호화 정보가 포함된 ‘암호화 키 디버그 보고서’를 생성합니다.
이러한 이벤트 기반 접근 방식은 연결이 유지되는 동안 디버깅 도구가 활성 암호화 상태 와 지속적으로 동기화되도록 보장합니다. 암호화 자격 증명이 시간이 지남에 따라 변경됨에 따라, 연결을 보호하는 업데이트된 세션 키와 IV를 반영한 추가 보고서가 생성됩니다.
보고서는 암호화 키 상태 가 변경될 때만 생성되므로, EPD는 구현에 드는 부하를 최소화하면서도 디버깅 도구가 암호화된 Bluetooth® 트래픽을 분석하는 데 필요한 정보를 계속 제공합니다.
7.2.5 Bluetooth® EPD 보고 워크플로우
앞서 다룬 섹션에서는 EPD가 보고하는 정보와 보고가 이루어지는 조건을 설명했으나, 호스트와 컨트롤러 간의 전반적인 상호작용은 그림 7.2.5에 제시된 보고 워크플로우를 통해 가장 잘 이해할 수 있습니다.
그림 7.2.5는 대표적인 EPD 보고 순서를 보여줍니다. 호스트가 암호화 키 디버그 보고 기능을 활성화하면, 컨트롤러는 암호화된 연결을 위해 새로운 세션 키가 생성될 때마다 암호화 키 디버그 보고서를 생성하고, 관련 세션 키와 IV를 호스트에 전달합니다. 이러한 이벤트 기반 워크플로를 통해 디버깅 도구는 연결이 유지되는 동안 활성 암호화 상태 와 지속적으로 동기화될 수 있습니다.
이 워크플로는 다음과 같이 요약할 수 있습니다:
- 호스트는 ‘Write Encryption Key Debug Reporting Mode’ 명령을 사용하여 EPD 보고 기능을 지원합니다.
- 표준 블루투스 암호화 절차를 사용하여 암호화된 연결이 설정됩니다.
- 암호화된 연결에 대해 새로운 세션 키가 활성화됩니다.
- 컨트롤러는 해당 연결과 관련된 세션 키 및 IV가 포함된 암호화 키 디버그 보고서를 생성합니다.
- 호스트는 보고서를 수신하며, 프로토콜 분석기, 상호운용성 테스트 시스템 또는 기타 디버깅 도구에 정보를 제공할 수 있습니다.
후속 세션 키가 생성될 때마다 추가 보고서가 생성될 수 있으며, 이를 통해 디버깅 도구가 활성 암호화 상태 의 변경 사항과 지속적으로 동기화되도록 보장합니다. 예를 들어, PHY가 HDT로 변경되거나 HDT에서 다른 모드로 변경될 때, 또는 자발적인 키 갱신 가 트리거될 때 CIS 연결의 활성 암호화 상태 가 변경될 수 있습니다. 이러한 경우, EPD는 업데이트된 세션 키와 IV를 호스트에 제공하여 디버깅 도구가 현재 암호화 상태 를 사용하여 암호화된 트래픽을 계속 해독할 수 있도록 합니다.
7.3 요약
블루투스® 암호화 데이터 보호( 제품 ) 디버깅(EPD)은 호스트 컨트롤러 인터페이스(HCI)를 통해 암호화된 블루투스® 연결의 활성 암호화 데이터 보호( 상태 ) 정보를 노출하기 위한 표준화된 메커니즘을 도입합니다. EPD는 장기 키(LTK)와 같은 장기 인증 정보에 대한 가시성에 의존하는 대신, 현재 연결을 보호하고 있는 세션 키와 초기화 벡터(IV)에 대한 직접적인 접근을 제공합니다.
블루투스 암호화가 암호화 키 스케줄(EKS)과 같은 메커니즘을 통해 발전함에 따라, 사용자 트래픽을 보호하는 인증 정보는 컨트롤러가 관리하는 암호화 절차를 통해 설정 및 유지될 수 있습니다. 이러한 상황에서, 프로토콜 분석 및 상호 운용성 디버깅을 위해서는 장기 인증 정보에 대한 가시성만으로는 더 이상 충분하지 않을 수 있습니다. EPD는 컨트롤러가 관리하는 활성 암호화 키 상태 에 대한 표준화된 가시성을 제공함으로써 이러한 과제를 해결합니다.
EPD는 두 가지 HCI 명령과 전용 보고 이벤트를 통해, 프로토콜 분석기, 상호운용성 테스트 시스템 및 디버깅 도구가 벤더별 로깅 메커니즘이나 독점적인 디버깅 인터페이스를 사용하지 않으면서도 암호화된 연결의 변경 사항과 지속적으로 동기화될 수 있도록 지원합니다.
EPD는 디버깅 가시성을 기본 암호화 설정 절차와 분리함으로써, 기존 LE 암호화 및 EKS 기반 암호화 배포 환경 모두에서 암호화된 블루투스 트래픽을 계속 관찰하고 디버깅할 수 있도록 보장합니다.
8. 블루투스® 전력 등급에 대한 설명
Bluetooth® Core 7.0은 사양에서 기존의 Bluetooth 전력 등급(Power Class) 정의를 삭제했습니다. 전력 등급은 오랫동안 기기의 송신 전력 성능을 설명하는 참고용 분류로 사용되어 왔으나, Bluetooth 인증 및 준수 여부는 항상 Bluetooth® Core 사양 전반에 걸쳐 정의된 해당 무선 요구 사항을 기반으로 해왔습니다. 따라서 전력 등급 정의의 삭제는 인증 절차, 상호 운용성 또는 기기 동작에 영향을 미치지 않습니다.
블루투스® 기기는 전통적으로 최대 송신 전력 용량에 따라 기기를 분류하는 ‘전력 등급(Power Classes)’과 연관되어 왔습니다. BR/EDR 및 LE 기기의 경우, 이러한 분류는 표 8a와 8b에 나와 있습니다.
| 파워 클래스 | 요구 사항 |
|---|---|
| 1 | 100 mW (20 dBm) ≥ Pmax > 2.5 mW (4 dBm) |
| 2 | 2.5 mW (4 dBm) ≥ Pmax > 1 mW (0 dBm) |
| 3 | 1 mW (0 dBm) ≥ Pmax |
| 파워 클래스 | 요구 사항 |
|---|---|
| 1 | 100 mW (+20 dBm) ≥ Pmax > 10 mW (+10 dBm) |
| 1.5 | 10 mW (+10 dBm) ≥ Pmax > 2.5 mW (+4 dBm) |
| 2 | 2.5 mW (+4 dBm) ≥ Pmax > 1 mW (0 dBm) |
| 3 | 1 mW (0 dBm) ≥ Pmax ≥ 0.01 mW (-20 dBm) |
제품 의 문서 및 마케팅 자료에서 널리 언급되고 있지만, 파워 클래스는 전통적으로 준수 요건이라기보다는 설명적인 분류 역할에 그쳐 왔습니다. 블루투스 인증 및 준수 여부는 항상 블루투스® 코어 사양에 정의된 해당 무선 요건을 기반으로 해 왔습니다. 이러한 이유로, 블루투스® 코어 7.0에서는 기존 파워 클래스 정의를 사양에서 삭제했습니다.
따라서 파워 클래스(Power Class) 정의가 삭제되더라도 자격 인증 절차, 상호 운용성 기대치, 무선 성능 요구 사항 또는 기기 동작에는 영향을 미치지 않습니다. 오히려 이번 변경을 통해 정보 제공용 블루투스 클래스( 제품 ) 분류와 규범적인 블루투스 요구 사항 간의 구분이 더욱 명확해졌습니다.
9. 결론
Bluetooth® Core 7.0은 데이터 처리량, 등시성 전송, 보안, 구현 지원 등 여러 주요 영역에서 Bluetooth® LE를 확장합니다. HDT는 기존 Bluetooth® LE 아키텍처와의 통합을 유지하면서 데이터 처리량을 대폭 향상시킵니다. IPU는 스트림을 재설정하지 않고도 변화하는 운영 요구 사항에 적응할 수 있도록 능동형 CIS 전송을 지원하며, EKS는 암호화 자료의 설정, 분리 및 업데이트를 위한 보다 유연한 프레임워크를 제공합니다. TAK은 페어링이나 본딩 없이도 안전한 세션 기반 상호 작용을 가능하게 함으로써 Bluetooth 보안 모델을 더욱 확장하며, EPD는 프로토콜 분석, 디버깅 및 상호 운용성 테스트를 지원하기 위해 활성 암호화 상태 에 대한 표준화된 가시성을 제공합니다.
종합해 보면, 이러한 개선 사항들은 블루투스 아키텍처의 기반을 유지하면서 더 높은 성능, 더 뛰어난 적응성, 그리고 더욱 유연한 보안 및 개발 모델을 지원하기 위해 블루투스의 진화를 이어가고 있습니다. 따라서 Bluetooth® Core 7.0은 이 기술의 근간이 되는 상호 운용성과 아키텍처적 일관성을 유지하면서 블루투스의 기능을 확장합니다.
10. 참조
| 항목 | 위치 |
|---|---|
| Bluetooth® 핵심 사양 v7.0 | https://www.bluetooth.com/specifications/specs/core-specification-v7/ |
