Bluetooth® 고속 데이터 처리량 기술 개요
| 버전: | 1.0 |
| 발행일: | 2026년 11월 3일 |
| 작성자: | 알프레도 페레즈 |
1. 소개
블루투스®(Bluetooth®)는 오디오, 웨어러블 기기, 휴먼 인터페이스 장치, 스마트 홈, 산업용, 자동차 등 다양한 시장 부문에 걸쳐 폭넓은 애플리케이션과 사용 사례를 가능하게 하는 다목적의 널리 보급된 무선 기술입니다. 이 기술의 성공은 에너지 효율성, 상호 운용성, 사용 편의성, 그리고 기능과 성능의 지속적인 발전과 같은 근본적인 장점에 기인합니다. 이러한 특성들이 결합되어 블루투스 기술은 규모를 확장하고, 견고한 개발 및 제품 생태계를 구축하고 지원하며, 전 세계 기업과 소비자들의 신뢰를 얻게 되었습니다.
그러나 무선 애플리케이션의 환경도 진화하고 있습니다. 오랫동안 블루투스 연결이 활발히 활용되어 온 시스템들은 점점 더 정교해지면서, 훨씬 더 많은 데이터를 생성, 처리 및 관리하고 있습니다. 예를 들어 오디오 시장에서는 원활한 성능과 사용자 경험을 제공하기 위해 더 큰 데이터 용량과 더 빠른 통신 속도를 요구하는 고음질 및 멀티 스트림 사용 사례로 솔루션이 발전하고 있습니다. 이에 따라 블루투스는 기존 성능을 뛰어넘는 증가하는 처리량 요구 사항을 지원해야 할 필요성이 대두되고 있습니다. 이러한 요구를 해결하기 위해 블루투스 특별 관심 그룹(SIG)은 블루투스 LE에 ‘블루투스® HDT( 고속 데이터 처리량 )’로 알려진 주요 아키텍처 및 성능 개선 사항을 도입하고 있습니다.
2016년 LE 2M PHY가 도입된 이래, Bluetooth LE가 지원하는 최대 PHY 비트레이트는 2 Mbps였습니다. Bluetooth® HDT를 통해 Bluetooth LE의 성능과 기능이 대폭 확장되어, 최대 PHY 비트레이트가 거의 4배 가까이 증가했을 뿐만 아니라 용량, 에너지 효율 및 신뢰성도 향상되었습니다. 전반적으로 블루투스 HDT는 데이터 전송 시간을 단축하고, 더 까다로운 애플리케이션 워크로드를 지원하며, 향후 혁신을 위한 여지를 마련함으로써 현대 애플리케이션의 요구에 맞춰 지속적으로 진화해 나갈 블루투스 기술 로드맵의 기반을 마련합니다.
이 문서는 블루투스 고속 데이터 처리량 에 대한 개괄적인 기술적 개요를 제공하며, 독자들이 이 중요한 블루투스 기술의 이정표에 대해 기본적인 이해를 할 수 있도록 돕기 위해 작성되었습니다.
2. 배경
원칙적으로, 통신 시스템에서 처리량을 높이는 것의 주된 이점은 명백합니다. 처리량이 높아지면 장치 간에 일정량의 데이터를 전송하는 데 필요한 시간이 단축되거나, 반대로 주어진 시간 내에 더 많은 데이터를 주고받을 수 있게 됩니다. 그러나 전송을 더 짧은 시간 내에 완료하면 다른 귀중한 이점도 얻을 수 있습니다. 예를 들어, 이는 시스템 내의 무선 액세스 제어 장치( 송신기 )와 무선 액세스 장치( 수신기 )가 작동하는 시간이 짧아진다는 것을 의미하며, 결과적으로 에너지 소비가 감소할 수 있습니다. 또한, 이를 통해 확보된 송신 시간을 관리형 공존 메커니즘을 통해 추가 통신 링크나 동일한 위치에 배치된 다른 시스템이 사용할 수 있도록 재할당할 수 있습니다.
실제로 통신 시스템의 처리량을 높이려면 대역폭(BW), 신호대잡음비(SNR), 스펙트럼 효율이라는 세 가지 기본 설계 변수를 조정해야 합니다. 섀넌의 정리¹ 은 대역폭(BW)과 신호대잡음비(SNR)가 채널 용량에 미치는 영향을 수식화하여, 용량이 대역폭에 비례하여 선형적으로 증가하고 신호대잡음비에 비례하여 로그 함수적으로 증가함을 보여줍니다. 그러나 섀넌의 정리가 예측하는 용량에 근접하기 위해서는 높은 스펙트럼 효율을 달성해야 합니다. 스펙트럼 효율은 사용 가능한 대역폭 1헤르츠당 초당 전송할 수 있는 비트 수(bps/Hz)를 나타내는 척도입니다. 실제 시스템에서 스펙트럼 효율은 변조 차수, 부호화 효율, 심볼 속도 등 물리 계층 설계 선택 사항과 대역폭 활용 효율에 영향을 미치는 기타 구현 요인에 따라 달라집니다.
블루투스 기술은 단순성, 신뢰성, 전 세계적으로 이용 가능한 비면허 주파수 대역에서의 효율적인 작동, 그리고 블루투스 LE의 경우 에너지 효율성을 최우선으로 하는 원칙을 바탕으로 설계되었습니다. 이 때문에 블루투스 LE 무선 장치는 단순하고 견고하며 복잡도가 낮은 변조 방식인 가우시안 주파수 변조(GFSK)를 기반으로 한 물리 계층을 갖추고 있으며, 전방 오류 정정 기능은 제한적이거나 아예 없습니다. GFSK 물리 계층의 단순성은 지금까지 블루투스에 큰 도움이 되었으며 앞으로도 그럴 것이지만, 스펙트럼 효율이 낮기 때문에 처리량을 크게 높일 수 있는 선택지는 제한적입니다.
다시 섀넌의 정리를 참고하면, GFSK PHY의 처리량을 향상시키는 한 가지 방법은 대역폭(BW)을 늘리는 것이지만, 2.4 GHz ISM 대역의 제약 조건과, 무엇보다도 이로 인해 초래될 아키텍처 및 에너지 효율상의 문제를 고려할 때 이는 현실적으로 어렵습니다. 또 다른 접근 방식은 신호대잡음비(SNR)를 높이는 것이지만, 이 역시 여러 가지 과제를 안고 있습니다. 송신 전력은 규제 제한 에 의해 제한을 받으며, 수신기 잡음 성능을 개선할 여지는 미미합니다. 따라서 더 실현 가능한 선택지는 스펙트럼 효율의 한계를 해결하는 것이며, 이것이 바로 Bluetooth® HDT가 수행하는 역할입니다.
블루투스 HDT는 블루투스 LE와 동일한 채널 대역폭 및 간격을 사용하는 새로운 PHY를 도입합니다. 그러나 더 중요한 점은, 이 PHY가 높은 스펙트럼 효율을 달성하기 위해 코히어런트 고차 변조 방식과 전방 오류 정정(FEC)을 통합했다는 것입니다. 또한 블루투스 HDT는 적응형 변조 및 링크 적응을 지원하기 위해 새로운 패킷 형식과 링크 Layer 업데이트를 도입하여, 다중 경로 또는 페이딩에 대한 내성을 향상시키는 동시에 새로운 PHY의 스펙트럼 효율 목표 달성을 돕습니다. 아울러 블루투스 HDT는 새로운 HDT 기능을 지원하기 위한 새로운 HCI 명령어 및 이벤트를 정의하고, 관련 보안 강화 기능을 도입합니다.
다음 장들에서는 블루투스 HDT의 구성 요소를 바탕으로 이에 대한 상세한 개요를 제공합니다. 이 문서는 아키텍처, 물리 계층(PHY), 패킷, 링크 계층( 링크 Layer , LL), 암호화, 호스트 컨트롤러 인터페이스(HCI), 그리고 스택의 ISOAL 및 호스트 계층에 대한 업데이트를 포함하는 기타 항목의 순서로 블루투스 HDT의 주요 구성 요소를 단계별로 안내합니다.
3. Bluetooth® HDT 아키텍처
블루투스 HDT의 기술적 측면을 자세히 살펴보기 전에, HDT가 블루투스 기술에 가져다주는 이점과 가치를 개괄적으로 파악해 두는 것이 도움이 됩니다:
- 지원되는 최대 비트레이트를 7.5 Mbps로 높입니다.
- 단순히 처리량 증가에 그치지 않고, 무선 성능을 획기적으로 향상시킵니다.
- 이를 통해 기존 블루투스 애플리케이션 및 사용 사례를 지원하기 위한 용량과 기능을 확대합니다.
- 이를 통해 고해상도 및 무손실 오디오와 같은 새롭고 더욱 풍부한 활용 사례가 가능해집니다.
이러한 이점은 블루투스 핵심 사양에 도입된 아키텍처상의 혁신과 개선 사항을 통해 실현됩니다. 이 섹션에서는 블루투스 HDT의 주요 아키텍처 원칙에 대한 개요를 제공합니다.
3.1 개요
블루투스 HDT의 핵심 아키텍처 목표는 블루투스 LE와의 하위 호환성을 유지하면서 처리량을 대폭 향상시키고, 더 높은 비트레이트를 효율적이고 안정적으로 지원하기 위해 필요한 성능(예: 향상된 감도, 간섭에 대한 높은 내성, 다중 경로 및 페이딩 조건에 대한 견고성)을 확보하며, 기존 블루투스 시스템에 비해 구현 복잡성을 관리 가능한 수준으로 유지하면서 이러한 목표를 달성하는 것입니다.
블루투스 HDT가 도입한 혁신과 개선 사항을 시각화하는 간단한 방법은 이를 블루투스 LE 스택의 구조에 대입해 보는 것입니다. 이를 설명하기 위해, 그림 3.1은 HDT를 지원하기 위해 업데이트된 계층을 별표로 표시한 블루투스 LE 스택의 단순화된 구조를 보여줍니다.
그림 3.1 – HDT용 블루투스 LE 스택 업데이트
한 단계 아래로 내려가 중간 수준의 관점을 살펴보면, HDT를 구현하거나 지원하기 위해 각 스택 계층에서 이루어진 주요 혁신 및 개선 사항은 다음과 같이 요약할 수 있습니다:
물리 계층 (PHY)
- 고차 코히어런트 변조 방식과 펀처링 방식의 전방 오류 정정 기술을 기반으로 한 새로운 비-GFSK PHY
- 최대 7.5 Mbps까지 5가지 비트레이트 지원
링크 Layer (LL)
- 새로운 패킷 구조
- 세 가지 새로운 패킷 형식 변형
- HDT 구성 정보 교환을 위한 새로운 절차
- PHY 업데이트 및 CIS 생성 정보 교환에 관한 개정 절차
- HDT 암호화 및 더 긴 MIC 크기
호스트 컨트롤러 인터페이스(HCI)
- 매개변수 설정, 페이로드 읽기, 테스트 활성화 등을 위한 새로운 명령어
- HDT 비율, 암호화 활성화 등 새로운 이벤트 보고
또한 이소크로너스 적응 계층(ISOAL)과 블루투스 LE 스택의 호스트 계층에 대한 소규모 업데이트도 이루어졌습니다. 호스트 계층 업데이트는 주로 MIC 길이 요구 사항의 검증 및 준수를 지원하며, ISOAL에 대한 업데이트는 새로운 PHY를 통해 가능해진 더 큰 데이터 페이로드의 전송을 지원합니다.
기술적 해상도가 더 높은 최종 저수준 관점에 대해서는 본 논문의 후속 절에서 다루며, 제4절에서는 물리 계층, 제5절에서는 패킷, 제6절에서는 링크 Layer , 제7절에서는 암호화, 제8절에서는 HCI, 제9절에서는 기타 사항(예: ISOAL 및 호스트 계층)을 다룹니다.
3.2 아키텍처 원칙
블루투스 HDT( 고속 데이터 처리량 )는 별도의 기술이나 병행 기술이 아니라 블루투스 LE의 확장 기능입니다. 이 기술은 블루투스 LE에서 사용되는 아키텍처 프레임워크(예: 동일한 물리 채널, 논리 전송 계층, 논리 링크 등)를 유지하면서 새로운 기능을 도입합니다.
HDT는 기존 GFSK 기반 블루투스 LE 장치와 하위 호환되며, 2.4 GHz ISM 대역에서 작동하고 동일한 채널 분할 방식을 사용합니다. 더 구체적으로 말하면, 연결은 항상 GFSK PHY를 사용하여 설정되며, 그 후 기기는 선택적으로 HDT PHY로 전환할 수 있습니다. HDT는 기기가 LE 연결 내에서 GFSK PHY와 HDT PHY 사이를 동적으로 전환할 수 있도록 설계되어, HDT 지원 기기가 필요에 따라 기존 블루투스 LE 방식과 공존하거나 이를 대체할 수 있습니다. 단, HDT의 초기 버전은 어떠한 형태의 광고(advertising)도 지원하지 않는다는 점에 유의해야 합니다.
HDT는 대역폭(BW)이나 신호대잡음비(SNR)를 높이는 대신, 스펙트럼 효율을 향상시켜 더 높은 처리량을 달성합니다. 이는 고차 코히어런트 변조 방식을 기반으로 하며, 전방 오류 정정 및 펑처링 기법을 결합한 새로운 PHY를 도입함으로써 실현됩니다.
HDT는 높은 데이터 전송 속도를 효율적으로 지원하는 새로운 패킷 구조를 도입하며, 다양한 운영 시나리오에서 오버헤드, 견고성 및 효율성 간의 균형을 맞추는 데 유용한 여러 패킷 형식을 정의합니다. 특히 한 가지 패킷 형식(PF1)은 단일 HDT 패킷이 서로 다른 애플리케이션이나 논리 링크에서 비롯된 여러 페이로드를 전달할 수 있게 하고, 페이로드 데이터를 블록 단위로 분할할 수 있도록 합니다. 이러한 유연성 덕분에 데이터 집계, 효율적인 무선 자원 활용, 최적화된 재전송이 가능해지며, 본 논문 후반부에서 논의될 추가적인 이점들도 얻을 수 있습니다.
HDT는 높은 데이터 전송 속도에서 안정적인 패킷 해석, 적응형 변조, 그리고 패킷별 동적 전송 속도 적응을 가능하게 하도록 설계되었습니다. 이 PHY는 항상 가장 견고한 변조 방식을 사용하고, 패킷 구조 내에서 제어 정보를 페이로드 데이터와 별도로 관리 및 처리함으로써, 열악한 채널 환경에서도 패킷의 제어 정보를 해독할 수 있는 확률을 극대화합니다.
간섭, 다중 경로 및 페이딩에 대한 내성을 향상시키기 위해, HDT는 패킷 구조 내에 PHY 인식 메커니즘을 통합합니다. HDT PHY를 사용하여 전송되는 패킷은 PHY 간격으로 나뉘며, 각 간격은 수신 중 채널 추적 및 위상 보정을 지원하는 데 유용한 알려진 시퀀스로 경계가 정해집니다. 이러한 접근 방식을 통해 패킷 중간 수신기 에서도 재동기화가 가능해지며, 이는 적응형 변조 및 동적 전송률 선택을 지원하면서 높은 데이터 전송 속도에서도 신뢰성을 높여줍니다.
명확히 하자면, 데이터를 블록과 PHY 인터벌로 분할하는 것은 서로 독립적입니다. 핵심적인 차이점은 블록이 논리적 페이로드 분할 메커니즘인 반면, PHY 인터벌은 PHY 계층 수준의 전송 분할 메커니즘이라는 점입니다. PF1에서는 암호화된 경우 MIC를 포함하여 각 페이로드를 블록으로 나눌 수 있으며, 각 블록은 고유한 CRC로 보호됩니다. 이렇게 생성된 페이로드 영역(Payload Zone)은 PHY 계층에서 PHY 인터벌(PHY Intervals)이라 불리는 고정 길이의 심볼 스트림으로 나뉘며, 각 PHY 인터벌 뒤에는 종결 심볼 시퀀스가 따르고, 마지막 인터벌을 제외하고는 PHY 인터벌 트레이닝 시퀀스(PITS)가 이어집니다. 따라서 블록 경계와 PHY 인터벌 경계는 서로 다른 목적을 가지며, 동일한 분할을 나타내지 않습니다. 블록은 페이로드 구성, 오류 검출 및 선택적 재전송을 지원하는 반면, PHY 인터벌은 관리 가능한 디코딩 간격과 주기적인 PHY 인터벌 트레이닝( 수신기 )을 통해 안정적인 무선 전송을 지원합니다.
또한 HDT는 물리 링크를 고유하게 식별하기 위한 물리 채널 주소(PCA) 메커니즘을 도입합니다. 이 개선 사항은 GFSK PHY에서 액세스 주소의 역할을 유지하면서 넓은 주소 공간을 제공함으로써, 장치 밀도가 높은 환경에 이점을 줍니다. 물리 채널 식별 메커니즘을 분리함으로써, RF 혼잡 상황에서도 HDT 패킷을 효율적으로 필터링하고 활성 연결과 올바르게 연관시킬 수 있습니다. 하나의 물리 채널은 하나 이상의 PCA를 가질 수 있으며, 각 PCA는 서로 다른 PHY에서 사용됩니다.
마지막으로, 블루투스 LE의 보안 모델을 변경하지 않으면서도 HDT에 보안 고려 사항이 반영되었습니다. HDT는 링크 Layer 에서 더 긴 메시지 무결성 검사(MIC) 크기를 지원함으로써, 더 긴 페이로드에 대한 데이터 인증 기능을 강화합니다. 또한, 블루투스 LE에서 암호화 키를 설정하고 관리하기 위한 새로운 프레임워크를 도입하는 암호화 키 스케줄(EKS) 기능 을 지원합니다. EKS는 암호화된 연결을 보호하는 데 필요한 세션 키 및 기타 암호화 값을 생성하며, 활성 연결 중에 암호화 키를 갱신할 수 있게 해줍니다. HDT의 경우, EKS는 GFSK와 HDT PHY 간 전환 시 연결을 끊거나 암호화를 다시 시작할 필요 없이 암호화 키 및 MIC 크기 변경을 원활하게 조정할 수 있도록 지원합니다.
분명히, HDT를 지원하기 위해 새로운 PHY가 도입됨에 따라 HDT를 구현하려면 새로운 하드웨어, 즉 새로운 무선 장치가 필요하게 됩니다. 블루투스 HDT는 GFSK 기반 블루투스 장치와 하위 호환성을 갖겠지만, GFSK만 지원하는 장치는 새로운 고처리량 수준을 지원할 수 없을 것입니다.
4. Bluetooth® HDT 물리 계층(PHY)
블루투스 HDT 물리 계층(PHY)은 더 높은 처리량을 가능하게 하는 무선 수준 메커니즘을 정의합니다. 이는 필수 LE 1M PHY 및 GFSK 변조를 기반으로 하는 선택적 LE 2M, LE 2M 2BT, LE 코디드 PHY와 공존하는 선택적 블루투스 LE PHY로 규정됩니다. HDT PHY는 2.4 GHz ISM 대역에서 작동하며, GFSK 기반 PHY와 동일한 채널 대역폭 및 간격을 사용합니다.
이 섹션에서는 HDT PHY의 세 가지 핵심 영역, 즉 변조 및 비트레이트, 비트스트림 처리, 동기화 및 내결함성에 대해 자세히 살펴봅니다.
4.1 변조 방식 및 비트레이트
변조는 통신을 위해 정보를 물리적 반송파 신호에 매핑하는 과정입니다. 블루투스 LE PHY에서는 전통적으로 가우시안 주파수 변조(GFSK)를 사용하여 이러한 매핑을 수행해 왔으며, 이 방식에서는 RF 반송파 신호의 주파수를 미세하게 변조하여 정보를 전달하며, 전송되는 각 심볼마다 1비트의 데이터를 인코딩합니다.
블루투스 HDT PHY는 데이터를 복소수 값의 심볼로 표현하고 심볼당 여러 비트를 인코딩하는 세 가지 코히어런트 변조 방식을 도입합니다:
- π/4 사분위 위상 변조(π/4 QPSK)
- 8 위상 변조(8PSK)
- 16점 직교 진폭 변조(16QAM)
이러한 변조 방식은 RF 반송파의 위상 변화를 통해, 또는 16QAM의 경우 반송파의 위상과 진폭을 동시에 변화시켜 정보를 전달합니다. 통신 중 전송되는 심볼은 동상(I) 및 직교(Q)라고 하는 두 신호 성분으로 구성되며, 설계상 각 I/Q 신호 쌍은 특정 심볼 값을 나타냅니다. 주어진 변조 방식에 대해 가능한 모든 I/Q 신호 쌍을 복소 평면상의 점으로 매핑한 것을 ‘콘스텔레이션 다이어그램’이라고 합니다. 그림 4.1은 π/4 QPSK, 8PSK 및 16QAM의 콘스텔레이션 다이어그램을 보여줍니다.
그림 4.1 – HDT 변조 방식의 도성도
코히어런트 변조는 해당 방식이 통신 시스템의 송신 측과 수신 측 간의 주파수 및/또는 위상 동기화를 지원함을 의미하며, 이는 동기화를 도모하고 오류 발생 확률을 줄이는 데 도움이 됩니다. 비코히어런트 방식의 경우 이러한 동기화가 이루어지지 않아 시스템은 더 단순해지지만, 일반적으로 유사한 조건에서 코히어런트 변조에 비해 오류에 더 취약합니다. HDT는 코히어런트 변조를 사용합니다.
HDT PHY는 새로운 변조 방식을 컨볼루션 전방 오류 정정(FEC) 및 펀처링과 결합합니다. FEC는 ½ 코딩률을 갖는 컨볼루션 코딩을 기반으로 구현되며, 펀처링은 더 높은 코딩률을 가능하게 하기 위해 사용됩니다. 전반적으로 HDT는 5가지의 서로 다른 비트레이트를 지원하며, 모두 2 Msym/s의 고정 심볼 속도로 동작합니다. 아키텍처적으로, 서로 다른 비트레이트는 단일 PHY의 모드로 취급됩니다. 표 4.1은 각 비트레이트의 관련 특성을 요약하여 보여줍니다.
표 4.1 – HDT 비율
| HDT 비율 | PHY 비트레이트 | 변조 방식 | 심볼당 비트 수 | 컨트롤러 구현 |
|---|---|---|---|---|
| HDT2 | 2 Mbps | π/4 QPSK | 2 | 필수 |
| HDT3 | 3 Mbps | π/4 QPSK | 2 | 필수 |
| HDT4 | 4 Mbps | 8PSK | 3 | 필수 |
| HDT6 | 6 Mbps | 16QAM | 4 | 선택 사항 |
| HDT7.5 | 7.5 Mbps | 16QAM | 4 | 선택 사항 |
HDT4까지의 전송 속도는 필수이며, HDT4를 초과하는 전송 속도는 선택 사항입니다. HDT6가 지원되는 경우, HDT7.5는 선택 사항입니다. HDT7.5가 지원되는 경우, HDT6도 필수입니다. 각 전송 속도에 대해, 수신(Rx)이 지원되면 전송(Tx)은 선택 사항이며, Tx가 지원되면 Rx는 필수입니다.
기호 좌표표, 구현 요구 사항 등을 포함한 자세한 내용은 Bluetooth Core Specification 7.0의 관련 절을 참조하십시오.
4.2 비트스트림 처리
무선 통신 링크를 통해 데이터를 송수신하기 위해 디지털 데이터를 기호로 변환하는 과정에는, ‘비트스트림 처리 파이프라인’으로 알려진 체계적인 처리 모델을 통해 해당 데이터의 흐름을 관리하는 작업이 포함됩니다.
블루투스 HDT에 대한 PHY 사양은 그림 4.2의 블록 다이어그램에 표시된 바와 같이 HDT 트래픽을 위한 결정론적 비트스트림 처리 파이프라인을 정의합니다. 이는 GFSK 기반 LE PHY에 포함된 파이프라인을 확장한 것으로, 간격 조절 및 펀처링 기능이 추가되었습니다. 선택된 PHY 속도에 관계없이 모든 처리 단계는 항상 동일한 순서로 진행됩니다.
송신 측에서는 원시 데이터 비트가 순차적으로 암호화(활성화된 경우), 순환 중복 검사(CRC) 생성, 데이터 화이트닝, 간격 조정, 전방 오류 정정(FEC) 인코딩 및 펀처링 단계를 거칩니다. 이렇게 생성된 비트 시퀀스는 이후 무선으로 전송될 심볼을 나타내는 변조된 I/Q 신호로 변환됩니다. 간격 분할은 HDT 패킷 형식 1(PF1)을 사용할 때만 적용된다는 점에 유의해야 합니다(페이로드 비트스트림을 분할하고 다중 PHY 간격을 지원하기 위함). 전체 패킷 구조 및 형식 정의는 5절에서 다루고 있습니다.
수신 측에서는 수신된 심볼이 전송된 데이터 비트를 추출하기 위해 해당 역처리 단계를 거칩니다(펀처링은 제외).
그림 4.2 – HDT 비트스트림 처리 파이프라인
파이프라인의 모든 단계는 HDT 비트스트림 처리 전반에 걸쳐 공통적이지만, PHY는 제어 정보와 페이로드 데이터에 대해 서로 다른 처리 규칙을 적용합니다. 제어 정보가 별도로 처리되는 이유는 새로운 HDT 패킷 구조에서 페이로드를 전달하는 섹션과 분리된 ‘제어 헤더(Control Header)’가 정의되어 있기 때문입니다. 이러한 패킷 구조상의 분리는 다음에서 설명하듯이, 중요한 PHY 수준 성능 목표를 지원하기 위한 아키텍처적 결정입니다.
수신기( 수신기 )는 패킷 내의 후속 고대역폭 페이로드를 추출하기 위해 제어 헤더(Control Header)를 성공적으로 복호화해야 합니다. 채널 상태가 좋지 않은 상황에서도 제어 정보를 디코딩할 확률을 극대화하기 위해, 제어 정보는 항상 HDT에서 사용할 수 있는 가장 견고한 변조 방식인 π/4 QPSK로 변조됩니다. 이를 위해 제어 데이터에 대한 비트스트림 처리는 화이트닝을 생략하고, 펀처링 없이 ½ 코딩 비율을 사용하는 FEC를 적용하여 독자적인 심볼 스트림을 형성합니다. 이는 높은 데이터 전송 속도에서 패킷 해석의 신뢰성을 높이는 데 도움이 됩니다.
제어 정보를 페이로드와 별도로 미리 처리함으로써, 패킷 단위로 동적인 데이터 전송 속도 적응도 가능해집니다. 보다 구체적으로, 패킷의 제어 헤더(Control Header)에는 뒤따르는 페이로드 전달 구간에 대한 패킷 형식, 선택된 데이터 전송 속도, PHY 간격 구성 등과 관련된 세부 정보가 포함됩니다. 제어 정보를 미리 수신하고 디코딩하면, 페이로드를 처리하기 위해 데이터 처리 장치( 수신기 )를 적절한 복조 및 디코딩 설정으로 구성할 수 있을 뿐만 아니라, 무엇보다도 필요에 따라 패킷마다 해당 설정을 수정할 수 있습니다. 또한, 페이로드 데이터가 여러 PHY 간격으로 분할되어 전송될 때 패킷 중간 수신기 에서 재동기화를 지원하도록 데이터 처리 장치( 수신기 )를 준비할 수 있어, 페이딩 또는 시간 변화 채널에서 링크의 견고성을 향상시킬 수 있습니다.
참고로, 표 4.2에는 비트스트림 처리 파이프라인의 각 단계별 역할과 이해해야 할 관련 사항에 대한 개요가 정리되어 있습니다.
표 4.2 – HDT 비트스트림 파이프라인 단계 요약
| 비트스트림 단계 | 요약 |
|---|---|
| 암호화 | • 추가 처리 전에 암호화 변환을 적용하여 데이터 기밀성을 보장합니다. • 암호화가 활성화된 경우 페이로드에 적용됩니다(예: HDT 패킷의 PDU 헤더 및 페이로드 영역). • 제7절에 상세히 설명된 HDT 암호화 프레임워크를 따릅니다. • 후속 오류 감지 및 수정 단계와의 호환성을 유지하면서 보안 적용 범위를 극대화하기 위해 파이프라인의 초기 단계에서 수행됩니다. |
| CRC | • 페이로드 블록 단위로 계산됩니다(암호화가 적용된 경우 암호화 후) • 무작위 오류와 버스트 오류 모두에 대한 오류 검출 기능을 제공합니다 |
| 미백 | • 비트 패턴을 무작위로 배열하고 동일한 비트가 길게 연속되는 부분을 분할하여, 신뢰할 수 있는 클럭 복구를 위해 스트림 내에서 충분한 전환이 이루어지도록 보장합니다. • 페이로드에만 적용됩니다(예: HDT 패킷의 PDU 헤더 및 페이로드 영역); 제어 헤더 다음의 첫 번째 PDU 헤더 비트에서 시작하여 패킷 내 페이로드 영역의 마지막 데이터 비트에서 끝납니다. |
| 간격 | • HDT 패킷 형식 1 에서만 사용 가능 • 페이로드 영역을 고정 길이의 전송 구간으로 분할할 수 있음 • 채널 추정값을 갱신하기 위해 PHY 간격 훈련 시퀀스(PITS)를 주기적으로 삽입할 수 있음 |
| FEC 부호화 | • 전송되는 모든 데이터에 적용됨(예: HDT 패킷의 제어 헤더, PDU 헤더 및 페이로드 영역) • ½ 코딩률을 기본으로 하는 비체계적, 비재귀적 컨볼루션 부호화를 사용함(제약 길이 K=6) • 무작위 오류와 짧은 버스트 오류 모두에 대해 오류 정정 기능을 제공함 |
| 천공 | • FEC 인코딩된 비트스트림에서 특정 비트를 선택적으로 제거합니다. • 단일 1/2 진법 컨볼루션 인코더와 다양한 펑처링 패턴을 결합하여, 채널 상태에 따라 적응적으로 변경할 수 있는 다양한 데이터 전송 속도를 생성합니다. • HDT를 위한 펑처링 패턴은 각 목표 데이터 전송 속도에 대해 자유 거리(free distance)를 극대화하며, 이는 노이즈에 대한 코드 속도의 견고성을 측정하는 지표인 자유 거리 계수( 매개변수 )입니다. • PF1은 페이로드 영역(Payload Zone)에만 펑처링을 적용하고 PDU 헤더에는 적용하지 않으며, PF0은 두 영역 모두에 펑처링을 적용합니다. |
완전성을 기하기 위해, 각 HDT 데이터 전송 속도에 대한 펀처링 관련 매개변수의 요약은 표 4.3에 수록되어 있다. HDT3와 HDT6는 동일한 펀처링 패턴과 코드 비율을 공유하지만, 서로 다른 변조 방식을 사용한다는 점에 유의해야 한다.
표 4.3 – HDT 천공 매개변수 요약
| HDT 비율 | 천공 패턴 (1=유지, 0=생략) | 천공 효율 (Ep) | 유효 코드율 |
|---|---|---|---|
| HDT2 | [1 1] | 1.0 (2/2) | 1/2 |
| HDT3 | [1 1 0 1 0 1] | 0.667 (4/6) | 3/4 |
| HDT4 | [1 1 0 1] | 0.75 (3/4) | 2/3 |
| HDT6 | [1 1 0 1 0 1] | 0.667 (4/6) | 3/4 |
| HDT7.5 | [1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 1 0 1 0 0 1 0 1 0 1 1 0 0 1] | 0.933 (28/30) | 15/16 |
4.3 동기화 및 견고성
HDT에 사용되는 고차 코히어런트 변조 방식은 GFSK에 비해 위상 또는 주파수 노이즈, 드리프트, 채널 변동에 본질적으로 더 민감합니다. 이 때문에 HDT PHY는 높은 데이터 전송 속도에서도 정확한 동기화와 견고한 복호화를 지원하기 위해 고안된 여러 메커니즘을 도입하여, 원하는 스펙트럼 효율 향상을 실현하고, 채널 열화, 페이딩 현상 또는 다중 경로 왜곡이 발생하는 까다로운 무선 환경에서도 안정적인 성능을 제공합니다.
표 4.4는 훈련 시퀀스(단기 및 장기), 가드 간격, 종료 기호, PHY 간격, PHY 간격 훈련 시퀀스(PITS) 등 각 메커니즘의 역할과 이를 이해하는 데 필요한 주요 사항을 개괄적으로 요약하고 있다.
표 4.4 – HDT 학습 및 동기화 메커니즘 요약
| 메커니즘 | 요약 |
|---|---|
| 단기 훈련 순서(STS) | • 신속한 초기 패킷 감지, 대략적인 타이밍 정렬 및 AGC 안정화를 가능하게 합니다. • 모든 HDT 패킷의 맨 처음인 프리앰블에 나타나며, 여러 번 연속으로 반복됩니다. • 패킷으로의 안정적인 진입점을 확보합니다. |
| 장시간 훈련 시퀀스(LTS) | • 정밀한 타이밍 정렬, 주파수 오프셋 추정/보정 및 초기 채널 추정을 가능하게 합니다. • HDT 패킷의 프리앰블 내 STS 뒤에도 나타나며, 여러 번 연속으로 반복됩니다. • 코히어런트 복조를 위해 수신기 를 준비합니다. |
| 가드 간격(GI) | • 훈련 시퀀스, 심볼 스트림, 변조 또는 부호화 경계 간의 전환으로 인한 과도 현상을 흡수하기 위한 시간 버퍼 • 프리앰블 내 STS와 LTS 사이에는 명시적으로 나타나며, 종결 심볼 을 통해 패킷 전체에 걸쳐 암시적으로 나타남 • 정밀한 LTS 동기화 전에 수신기 필터와 타이밍 루프가 안정화될 수 있도록 하며, 심볼 스트림 간의 원활한 전환을 보장함 |
| 종료 기호 | • 심볼 스트림 간에 명확한 경계를 설정하고, 심볼 스트림 전환 시 발생하는 과도 현상을 흡수한다. • 패킷 내의 각 독립적으로 처리되는 심볼 스트림의 끝 부분에 위치한다(예: 제어 헤더 뒤, PDU 헤더 영역 뒤, 패킷 형식 1의 각 PHY 간격 뒤 등). • FEC 디코더가 다음 세그먼트/스트림이 시작되기 전에 상태 를 비우고 리셋할 수 있도록 한다. • 특히 패킷 형식 1의 경우, 독립적으로 처리되는 심볼 스트림 간의 오류 전파를 제한하는 데 중요하다. |
| PHY 인터벌 | • 긴 페이로드를 더 작고 처리하기 쉬운 디코딩 단위로 분할할 수 있도록 합니다. • 패킷 형식 1(PF1) HDT 패킷의 페이로드 영역에만 나타납니다. • 긴 PF1 페이로드 내의 간격 사이에 주기적인 채널 추적 및 재훈련을 활성화합니다. |
| PHY 인터벌 트레이닝 순서(PITS) | • 여러 PHY 간격으로 분할된 페이로드의 안정적인 수신을 위해 위상 및 채널 추정치를 갱신하는 패킷 중간 재훈련을 활성화합니다 • 패킷 형식 1(PF1) HDT 패킷의 페이로드 영역에만 나타납니다 |
HDT PHY의 동기화 및 견고성 요소들은 결합되어 신뢰성 높고 높은 처리량을 갖춘 작동을 가능하게 하는 계층적 프레임워크를 제공합니다. 먼저, STS 및 LTS를 활용한 견고한 프리앰블 기반 트레이닝을 통해 초기 획득이 이루어집니다. 그 다음, 가드 간격과 종결 심볼을 활용하여 명확한 전환과 명시적인 디코딩 경계가 설정되고 적용됩니다. 마지막으로, 더 긴 패킷과 더 높은 데이터 전송 속도로 작업할 때 변화하는 채널 조건에 적응하기 위해 PHY 간격 및 관련 트레이닝 시퀀스를 통해 패킷 중간 재동기화가 가능해집니다. 이러한 구조화된 접근 방식은 페이딩, 위상 드리프트 및 다중 경로 효과에 대한 복원력을 보장하여, HDT가 견고성과 효율성을 바탕으로 상당한 처리량 향상을 달성할 수 있게 합니다.
5. Bluetooth® HDT 패킷
블루투스® HDT는 앞 섹션에서 소개된 PHY 수준 기능과 6절 후반부에 제시될 링크 Layer 의 지능 및 절차를 연결하는 새로운 패킷 구조를 정의하여, 실질적이고 안정적으로 더 높은 처리량과 견고한 성능을 제공합니다.
이 섹션에서는 HDT 패킷 구조와 패킷 형식을 다루며, 각 영역, 부분 및/또는 필드를 개괄적으로 살펴봅니다.
5.1 HDT 패킷 구조 개요
그림 5.1에 표시된 바와 같이, HDT 패킷 구조는 프리앰블, 제어 헤더, PDU 헤더 영역, 페이로드 영역의 네 가지 영역으로 구성됩니다. 프리앰블과 제어 헤더는 필수 요소이며, 모든 HDT 패킷 형식에서 반드시 포함되어야 합니다. PDU 헤더 영역과 페이로드 영역의 포함 여부는 선택한 패킷 형식에 따라 달라집니다.
그림 5.1 – HDT 패킷 구조
HDT 패킷 구조의 깊이는 PDU 헤더 및 페이로드 영역이 4단계의 세부 정보를 포함하도록 되어 있습니다. 통신의 명확성을 위해, 패킷의 최상위 계층과 관련된 명명 필드는 ‘영역(zones)’이라 하고, 그 바로 아래 계층과 관련된 명명 필드는 ‘부분(portions)’이라 하며, 최하위 두 계층의 명명 필드는 단순히 ‘필드(fields)’라고 부릅니다. 예를 들어, HDT 패킷 구조의 PDU 헤더 영역( 상태 )에는 LL 설명자(LL Descriptor) 필드가 지정된 TX 부분이 포함되어 있으며, 여기에는 각 페이로드의 전송 계층 식별자( 링크 Layer , LLID)가 포함된 LLID 필드가 있다고 볼 수 있습니다. 이러한 명명 방식을 사용하는 이점은 이 절의 뒷부분에서 명확해질 것입니다.
전반적으로 볼 때, HDT 패킷 구조에서 각 구역의 역할과 구성은 다음과 같이 요약할 수 있습니다.
서문
- 수신기 가 수신 패킷의 시작 지점을 식별하고, 송신기 와 동기화하여 타이밍, 주파수 또는 위상 편차를 보정하며, 무선 채널로 인해 발생하는 진폭 및 위상 왜곡을 완화하기 위한 채널 추정 작업을 수행할 수 있게 합니다.
- 짧은 훈련 시퀀스(STS)를 9회 반복한 뒤, 가드 간격(GI)을 삽입하고, 이어서 긴 훈련 시퀀스(LTS)를 2회 반복하는 방식으로 구성됩니다.
제어 헤더
- 수신기 가 수신 패킷을 올바른 물리적 링크와 연결하고, 필수 제어 정보를 안정적으로 디코딩하며(전용 헤더 오류 검사 기능 포함), 페이로드의 복조나 처리가 이루어지기 전에 이러한 작업을 수행할 수 있도록 합니다.
- HDT 패킷 주소(HPA-A), 패킷 형식, 속도 선택 등 제어 관련 세부 정보를 전달하는 7개의 필드로 구성됩니다.
PDU 헤더 영역
- 수신기 가 페이로드 영역(Payload Zone)에 이어지는 페이로드 데이터를 해석하고 관리하는 데 필요한 프로토콜 수준의 메타데이터를 전달하며, 여기에는 패킷 유형(예: 전송, 링크 ID 등), 페이로드 길이 등이 포함됩니다.
- 다음 5가지 부분으로 구성됩니다: 초기, RX, TX, 확장 헤더, 헤더 오류 수정(HEC-P)
화물 구역
- 전송된 페이로드 블록(암호화된 경우 메시지 무결성 검사(MIC) 포함)과 CRC를, 사용된 패킷 형식에 따라 정리하여 포함합니다.
- 패킷 형식 섹션에서 다루는 세부 사항
5.2 HDT 패킷 형식
다양한 통신 시나리오에서 효율성과 유연성을 확보하기 위해 HDT는 세 가지 패킷 형식, 즉 ‘short’, ‘패킷 형식 0(PF0)’, ‘패킷 형식 1(PF1)’을 정의합니다.
짧은 형식
짧은 패킷 형식은 전송할 데이터가 없는 경우에 최적화된, 오버헤드가 최소화된 구조입니다. 이 형식은 송신 시간 사용을 줄여주며(예: 길이가 항상 정확히 69 us임), 장치 간 동기화 및 확인 응답 교환에 유용합니다. 구조적으로, 짧은 형식은 그림 5.2에 표시된 바와 같이 프리앰블과 제어 헤더로만 구성됩니다.
그림 5.2 – HDT 패킷, 짧은 형식
패킷 형식 0 (PF0)
패킷 형식 0(PF0)은 분할되지 않은 페이로드를 단일 블록으로 전송하는 데 최적화된, 복잡도가 낮은 구조입니다. 구조적으로 PF0은 프리앰블, 제어 헤더, PDU 헤더 영역, 그리고 페이로드 영역(페이로드가 비어 있는 경우 선택 사항이 될 수 있음)으로 구성됩니다.
페이로드 영역에 포함된 단일 블록에는 암호화된 경우 MIC가 포함됩니다. 또한 페이로드 영역에는 전체 PDU 헤더, 페이로드 블록 및 MIC의 합계를 기반으로 계산된 오류 검출용 CRC가 포함됩니다. 그림 5.3은 PF0의 구조를 보여줍니다.
그림 5.3 – HDT 패킷 형식 0 (PF0)
패킷 형식 1 (PF1)
패킷 형식 1(PF1)은 대량의 데이터를 효율적이고 안정적으로 전송하는 데 가장 적합하며, 가장 성능이 뛰어나고 견고한 구조입니다. 구조적으로 PF1은 프리앰블, 제어 헤더, PDU 헤더 영역, 페이로드 영역으로 구성됩니다.
PF1은 페이로드 영역(예: 전송을 대기 중인 다음 네 개의 페이로드)에서 최대 네 개의 서로 다른 페이로드를 집계할 수 있으며, 암호화가 활성화된 경우 각 페이로드에는 고유한 MIC가 부여됩니다. 각 페이로드는 블록(1~16)으로 나눌 수 있으며, 각 블록에 대해 CRC가 계산됩니다. 마지막 블록을 제외한 모든 블록의 크기는 동일하지만, 페이로드마다 크기가 다를 수 있습니다. 그림 5.4는 PF1의 구조를 보여줍니다. 아래첨자 M, N, P는 각각 페이로드 0, 1, 2에 대한 블록 수를 나타냅니다.
그림 5.4 – HDT 패킷 형식 1 (PF1)
블록은 HDT 패킷의 페이로드 영역(Payload Zone)에 포함된 새로운 페이로드 전송 및 검증 단위입니다. HDT는 페이로드를 하나의 단일 단위로 취급하는 대신, 페이로드 데이터를 일련의 블록으로 처리하며, 각 블록은 고유한 CRC로 보호되어 수신기( 수신기 )가 블록을 독립적으로 검증할 수 있도록 합니다. 이 개념의 근본적인 이점은 더 큰 페이로드/패킷을 전송할 때 선택적 확인 응답 및 재전송을 가능하게 하여 더 높은 처리량을 확보할 수 있다는 점입니다. 패킷의 일부는 성공적으로 수신되면 확인 응답을 보낼 수 있으며, 간섭으로 인해 페이로드의 일부가 손상된 경우 HDT PHY는 성공적으로 수신된 블록은 그대로 유지하고 누락되거나 손상된 블록만 재전송하면 됩니다.
블록 세분성을 통해 다중화 및 지속적인 처리량을 지원할 수 있으며, 이는 PF1이 하나의 패킷에 최대 4개의 페이로드를 집계하는 기능을 보완합니다. 특정 페이로드에 대한 블록 크기는 PDU 헤더 영역의 TX 부분에 명시됩니다.
일반적으로 HDT는 페이로드 번호와 슬라이딩 페이로드 윈도우를 사용하여 페이로드의 전송, 확인 응답 및 재전송을 관리합니다. ACL 또는 CIS 연결의 각 방향에서, 페이로드 윈도우에는 CurrentPayloadNumber부터 시작하여 전송 또는 재전송이 가능한 1개에서 4개 사이의 페이로드가 포함됩니다. 윈도우의 맨 앞쪽에 있는 페이로드에 대한 확인 응답이 수신되면 CurrentPayloadNumber가 증가하여 윈도우가 앞으로 이동합니다. ExpectedPayloadNumber는 피어 장치로부터 다음에 수신될 것으로 예상되는 페이로드를 식별합니다. SN과 NESN은 각각 CurrentPayloadNumber와 ExpectedPayloadNumber의 최하위 3비트를 전달하여, 장치가 페이로드 윈도우의 상태 를 추적할 수 있게 합니다. 이 페이로드 번호 매기기 모델은 PF0과 PF1 모두에 적용됩니다. PF0은 윈도우 내의 첫 번째 페이로드만 전송하거나 재전송할 수 있는 반면, PF1은 윈도우 내의 페이로드에서 선택한 블록을 전송하거나 재전송할 수 있습니다.
요약하자면, 표 5.1은 세 가지 패킷 형식을 비교한 내용을 보여줍니다.
표 5.1 – HDT 패킷 형식 요약
| 짧은 | PF0 | PF1 | |
|---|---|---|---|
| 최대 적재량 | N/A | 494 옥텟 | 8175 옥텟 |
| 다음과 같은 경우에 유용합니다 | 동기화, 확인 응답 | 더 높은 처리량 | 최고의 처리량, 효율성 및/또는 내구성 |
| 주요 장점 | 전송할 페이로드 데이터가 없거나, 연속된 전체 페이로드에 대해서만 확인 응답이 필요한 경우, 통신 시간을 단축합니다. | • 구현이 더 간편함 • 오버헤드가 더 낮음 • MIC가 포함된 단일 페이로드 블록 | • 패킷당 최대 4개의 페이로드 • 페이로드의 블록 단위 분할 • 선택적(블록) 확인 응답 • 페이로드 블록이 여러 패킷에 걸쳐 분산될 수 있음 • PHY 간격, PITS를 이용한 위상 추적 |
이제 각 패킷 구조 영역을 좀 더 자세히 간략히 살펴보겠습니다.
5.3 서문
그림 5.5는 프리앰블의 구조와 타이밍을 보여줍니다. 트레이닝 시퀀스 및 가드 간격에 대한 자세한 기술적 내용은 ‘블루투스 코어 사양’ 제6권, 파트 A, 7.4절을 참조하십시오.
그림 5.5 – HDT 패킷 프리앰블
5.4 제어 헤더
그림 5.6은 제어 헤더의 형식과 필드를 보여줍니다.

그림 5.6 – HDT 패킷 제어 헤더
- HPA-A (HDT 패킷 주소 – 부분): 전체 40비트 HPA 중 39:24 비트. 이 주소는 수신기 가 수신 패킷을 필터링하고 후보 물리 링크를 식별할 수 있도록 하는 부분 주소를 제공합니다.
- NESN(Next Expected 순차 번호): ExpectedPayloadNumber의 최하위 3비트를 포함하며, 피어 장치로부터 수신된 페이로드에 대한 누적 확인 정보를 제공합니다. 확인된 페이로드가 페이로드 윈도우를 따라 진행됨에 따라, NESN은 피어 장치로부터 다음에 수신될 것으로 예상되는 페이로드를 반영합니다.
- PFI (패킷 형식 표시기): 패킷에 사용된 형식을 나타냅니다. 이 필드는 동적이며 패킷마다 달라질 수 있습니다.
- 0: 짧은 형식 또는 형식 0; 1: 형식 1
- 'Short'은 언제든지 삽입할 수 있습니다.
- 언제든지 PF0에서 PF1로 전환할 수 있습니다
- 특정 상황에서는 PF1에서 PF0으로 전환할 수 있습니다.
- RI (속도 표시기): PDU 헤더 및 페이로드 영역의 데이터 전송 속도를 지정합니다. 이 필드는 동적이며 패킷별로 변경될 수 있어, 채널 상태에 따라 PHY 전송 속도를 신속하게 조정할 수 있습니다.
- 0b000: 짧은 형식 (데이터 영역 없음)
- 0b001-0b101: 2 Mbps에서 7.5 Mbps까지의 속도.
- RFU (향후 사용을 위해 예약됨)
- PDU 제어: 콘텐츠는 패킷 형식에 따라 달라집니다.
- 요약: 즉각적인 링크 제어를 위한 MD/CIE(More Data/Close Isochronous Event), 3개의 RFU 비트 및 SNR(신호 대 잡음비) 필드가 포함되어 있습니다.
- 형식 0: CRC를 제외한 PDU 헤더 및 페이로드 영역의 총 길이를 나타내는 9b 값
- 형식 1: 6비트 PDU 헤더 영역 길이(HEC-P 부분 제외), PHY 간격당 페이로드 심볼 수를 나타내는 2비트 PHY INT [00: 128; 01: 256; 10: 384; 11: 512], 그리고 1비트의 RFU 비트로 구성됩니다.
- HEC-C(헤더 오류 검사 – 제어): 앞선 모든 제어 헤더 필드를 대상으로 계산되며 전체 HPA로 초기화된 24비트 CRC로, 이를 통해 수신기 는 해당 HPA를 기준으로 제어 헤더의 유효성을 검증하고 패킷을 해당 물리 링크에 올바르게 연결할 수 있습니다.
5.5 PDU 헤더 영역
그림 5.7은 PDU 헤더 영역의 형식과 각 부분을 보여줍니다.

그림 5.7 – HDT 패킷 PDU 헤더 영역의 각 부분
초기 부분
초기 부분(Initial Portion)은 전체 PDU 헤더 영역에 대한 제어 맵이자 진입점 역할을 하는 8b 필드입니다. 이 부분은 선택적 부분의 존재 여부를 정의하며, 전송 방식별 제어 정보를 포함합니다. 초기 부분의 해석은 전송 방식에 따라 달라지며, 이는 표 5.2에 요약되어 있습니다.
표 5.2 – 전송 방식별 초기 부분 필드
| 비트 | ACL | CIS | BIS |
|---|---|---|---|
| 0 | XHP (확장 헤더 존재) | XHP (확장 헤더 존재) | XHP (확장 헤더 존재) |
| 1 | RxPP (처방전 포함) | RxPP (처방전 포함) | 수정됨 0 (Rx 부분 없음) |
| 2 | 추가 데이터: 지속적인 전송을 위해 연결 이벤트를 열어 둡니다 | CIE (Close Isochronous Event): 하위 이벤트의 조기 완료를 알리는 신호 | CSTF (제어 하위 이벤트 전송 플래그): 후속 패킷에 BIG 제어 PDU가 포함됨을 나타내며, 데이터 PDU에 설정됩니다. |
| 3-5 | SN (순차 번호): CurrentPayloadNumber의 최하위 3비트로, 페이로드 윈도우 내에서 발신자의 현재 위치를 나타냅니다. | SN (데이터 PDU용 ACL과 동일) | CSSN (제어 하위 이벤트 순차 번호) |
| 6-7 (PF0) | LLID (논리 링크 ID) | LLID (논리 링크 ID) | LLID (논리 링크 ID) |
| 6-7 (PF1) | TxPP (Tx 부분 존재) + RFU | TxPP (Tx 부분 존재) + RFU | TxPP (Tx 부분 존재) + RFU |
처방약 부분
Rx 부분은 피어 장치에서 전송한 데이터가 수신되었음을 나타내기 위해 선택적 확인 응답이 필요한 경우, ACL 또는 CIS 패킷에 포함됩니다. 그 형식과 필드는 그림 5.8에 나와 있습니다. 최대 4개의 페이로드에 대해 세분화된 피드백을 제공할 수 있습니다.

그림 5.8 – PDU 헤더 영역, 수신(Rx) 부분의 형식 및 필드
- RxPayloadMap: 이 패킷에서 다음 네 개의 예상 페이로드(P+0부터 P+3까지) 중 어느 것이 확인되었는지를 나타냅니다.
- RxAck P+k (페이로드당 2b): 각 페이로드 k에 대한 확인 응답의 세분화 수준을 지정합니다.
- 00: 확인되지 않음. 페이로드나 특정 블록이 수신되어 검증된 바가 없습니다.
- 01: 완전히 수신 확인됨. 전체 페이로드가 올바르게 수신되었습니다(이 페이로드에 대해서는 RxBitmap이 뒤따르지 않음).
- 10/11: 부분 확인. 페이로드 내의 특정 논리 블록에 대해서는 확인이 이루어지지만, 모든 논리 블록에 대해서는 확인되지 않습니다. 이 페이로드에 대해서는 1 또는 2 옥텟 크기의 RxBitmap이 뒤따릅니다.
- RxBitmap (8비트 또는 16비트): 1이 해당 논리 블록(페이로드의 세그멘테이션에 따라 정의됨)이 성공적으로 수신되고 유효성이 검증되었음을 나타내는 비트 마스크입니다. 이 비트 마스크의 크기는 페이로드에 포함된 블록 수(Nb+1)에 따라 결정됩니다.
- 불필요한 비트는 모두 1로 설정되어, 오직 0xFF와 0xFFFF만이 데이터가 완전히 수신되고 유효성이 검증되었음을 나타내도록 합니다.
- For 8b bitmask, the 8 most significant bits are set to 1; an 8b mask can only be used if Nb<8 or if all blocks after number 8 have already been acknowledged
Tx 부분
Tx 부분은 전송된 내용을 설명하기 위해 포맷 1 패킷에 포함되며, 이를 통해 수신 측( 수신기 )이 특정 페이로드의 블록을 인식하고 재구성할 수 있게 합니다. 이 부분의 형식과 필드는 그림 5.9에 나와 있습니다. 최대 4개의 페이로드에 대해 세밀한 세부 정보를 제공할 수 있습니다.

그림 5.9 – PDU 헤더 영역, 송신(Tx) 부분의 형식 및 필드
- TxPayloadMap: 전송 창에 있는 다음 네 개의 페이로드(P+0~P+3) 중 어느 것의 블록이 이 패킷에 포함되어 있는지를 나타냅니다.
- DscType P+k (페이로드당 2b): 페이로드 k에 대한 다음 LL 설명자의 형식을 설명합니다.
- 00: 없음 (이 페이로드에는 블록이 없음)
- 01: 2-옥텟 디스크립터
- 10: 5-옥텟 디스크립터
- 11: 6-옥텟 디스크립터
- LL 설명자 (2, 5 또는 6 옥텟): 블록이 존재하는 특정 페이로드에 대한 메타데이터를 포함합니다
- 페이로드 길이 (13b): 전체 페이로드의 총 길이 (MIC가 있는 경우 포함)
- LLID (2b), RFU (1b): 논리 링크 식별자 및 예약 비트
- 참고 (4b): 블록 수 – 1; 0 = 1개 블록, 15 = 16개 블록. 페이로드가 몇 개의 블록으로 나뉘는지 정의합니다.
- 블록 크기 (9b): 페이로드에서 마지막 블록을 제외한 모든 블록의 크기(32~511 옥텟 범위). 마지막 블록의 크기는 가변적이며, 32 옥텟에서 블록 크기+32 옥텟 사이의 임의의 값이 될 수 있습니다.
- Nb=0인 경우, 단일 블록의 크기는 0에서 510 옥텟 사이의 임의의 값이 될 수 있습니다.
- TxBlockMap (8비트 또는 16비트): 이 패킷에 어떤 특정 블록(Nb 및 BlockSize로 정의된)이 포함되어 있는지를 나타내는 비트 마스크입니다. 1은 해당 블록이 포함되어 있음을 의미합니다.
- 필요 없는 비트는 0으로 설정됩니다.
확장 헤더
확장 헤더(Extended Header)는 고정된 오버헤드를 발생시키지 않으면서 다양한 선택적 기능을 지원하는, 플래그 기반의 간결한 구조입니다. 이 헤더의 유무는 초기 부분(Initial Portion)에 있는 XHP(Extended Header Present) 비트로 표시됩니다. 플래그 옥텟 0을 제외한 모든 필드는 선택 사항입니다. 그 형식과 필드는 그림 5.10에 나와 있습니다.

그림 5.10 – PDU 헤더 영역, 확장 헤더 부분의 형식 및 필드
- 플래그 비트 인코딩: 기능은 7×O+B 방식을 통해 지정되며, 여기서 O는 0을 기준으로 한 플래그 옥텟 인덱스이고, B는 비트 위치(1~7, 비트 0은 향후 사용을 위해 예약됨)를 나타냅니다. 플래그 비트를 1로 설정하면 해당 기능 가 존재함을 나타내며, 해당 데이터 옥텟은 기능 데이터 영역에 포함됩니다.
- 기능 데이터 순서: 기능 데이터 옥텟은 모든 플래그 옥텟 뒤에, 기능 ID의 엄격한 숫자 순서대로 연결됩니다.
확장 헤더는 HDT에 매우 중요한 선별된 기능 집합을 지원하며, 각 기능은 특정 목적을 가지고 있으며 엄격한 구현 규칙을 따릅니다. 이러한 기능들은 논리적 전송 유형(ACL, CIS, BIS)에 맞춰 설계되었으며, 표 5.3에 요약되어 있습니다.
표 5.3 – 확장 헤더 기능
| Feat. 번호 | ACL | 크기 | CIS | 크기 | BIS | 크기 |
|---|---|---|---|---|---|---|
| 1 | 확장 헤더 기능 의 데이터 길이 | 10월 1일 | 확장 헤더 기능 의 데이터 길이 | 10월 1일 | 확장 헤더 기능 의 데이터 길이 | 10월 1일 |
| 2 | 링크 품질 | 10월 2일 | 링크 품질 | 10월 2일 | — | — |
| 3 | — | — | NPI | 10월 0일 | — | — |
| 4 | 유량 제어 | 10월 0일 | — | — | — | — |
| 5 | NPI | 10월 0일 | — | — | — | — |
기능 데이터 길이
- 확장 헤더 내에 포함된 모든 후속 ‘ 기능 ’ 데이터 옥텟의 총 길이를 제공합니다.
- 기능 확장 헤더를 포함하는 모든 형식 0 패킷에서 이 항목은 필수입니다. 형식 0 패킷에는 PDU 헤더 영역에 대한 명시적인 길이 필드가 없기 때문에 이 요구 사항은 매우 중요합니다. 수신기 는 이 값을 기반으로 페이로드 영역의 시작 위치를 정확하게 파악합니다.
- 이 필드를 PF1에 포함시키는 것은 허용되지만, PF0의 경우처럼 패킷을 디코딩할 필요는 없습니다(일반적으로 전송 시간을 절약하기 위해 생략됨).
- 뒤따르는 ‘ 기능 ’ 데이터 옥텟의 총 개수를 나타내는 부호 없는 정수가 포함된 단일 옥텟 필드
링크 품질
- 송신기 에 가장 최근에 수신된 패킷의 품질에 대한 피드백을 제공함으로써 적응형 데이터 전송률(ADR) 제어를 가능하게 합니다.
- 두 기기 모두 ‘링크 품질 피드백’ 기능 을 지원하는 경우에만 사용할 수 있습니다.
- 다음과 같이 구성된 2 옥트 필드:
- RSSI (비트 0-7): 수신 신호 강도 표시
- SNR (8~12비트): 신호 대 잡음비
- 선호 속도(비트 13-15): 후속 전송에 대해 수신기에서 권장하는 PHY 데이터 속도(HDT2-HDT7.5)를 나타내는 3b 코드입니다. 값 0은 구체적인 권장 사항이 없음을 나타냅니다.
유량 제어
- 상태 의 두 가지 값: STOP과 GO
- ACL 연결에 대해 패킷 단위의 즉각적인 흐름 제어를 제공합니다.
- 이 기능 가 포함된 패킷을 수신하면, 수신기의 링크 Layer 는 해당 방향에 대한 로컬 흐름 제어 상태 를 STOP으로 설정해야 합니다.
- 상태 중단 시 미치는 영향: STOP 상태 에 있는 동안, 송신기 는 다음 내용만 전송할 수 있습니다:
- 이미 적어도 하나의 블록에 대해 수신 확인이 완료된 페이로드의 블록들(즉, 재전송)
- 제어 PDU(LLID = 0b11로 식별됨)
- GO 상태로 복귀: 흐름 제어 상태 는 Stop 기능 을 포함하지 않는 다음 유효 패킷을 수신하면 GO 상태로 복귀합니다. 즉, STOP 상태를 유지하려면 단축 형식 패킷을 전송할 수 없습니다. 상태
Null PDU 표시기(NPI)
- Null PDU(데이터 전송 의도가 없는 프로토콜 자리 표시자)와 Empty PDU(페이로드 길이가 0인 유효한 데이터 PDU)를 명확히 구분합니다.
- 이 기능 는 페이로드 영역(길이 = 0)이 비어 있는 형식 0 패킷에서만 유효합니다.
- 의미론:
- NPI = 1: 이 PDU는 Null PDU입니다. 이 PDU는 자리 표시자(예: 타이밍 또는 확인 응답 용도) 역할을 하며, 유효한 PayloadNumber와 연관되어 있지 않습니다. 또한 데이터 시퀀스를 진행시키지 않습니다.
- NPI = 0 또는 기능 가 없는 경우: 해당 PDU는 유효한 PayloadNumber와 연관되어 있습니다. 이 PDU는 페이로드에 데이터 옥텟을 포함할 수도 있고, 빈 PDU일 수도 있습니다.
HEC-P
HEC-P(헤더 오류 검사 – PDU 헤더) 는 전체 PDU 헤더 영역(자신을 제외)을 포괄하는 24비트 CRC입니다. 이는 PF1에만 존재하며(PF0에서는 생략됨), HPA와 함께 초기화됩니다.
5.6 페이로드 구역
페이로드 영역의 구조는 데이터의 구성, 전송 및 보호 방식을 정의하는 선택된 패킷 형식에 따라 결정됩니다. 표 5.4는 패킷 형식 0과 형식 1 간의 주요 페이로드 영역 차이점을 비교하고 요약하고 있습니다.
표 5.4 – PF0 및 PF1 페이로드 구역 비교
| PF0 | PF1 | |
|---|---|---|
| 페이로드 데이터 | 단일하고 연속적인 블록에 포함되어 전송됨 | 최대 4개의 페이로드를 통합하여 세그먼트로 분할한 후, 여러 블록의 순서로 전송됩니다. |
| 패킷당 최대 페이로드 | 1 | 1~4 (TxPayloadMap을 통해 식별됨) |
| 적재 용량 (크기) | 0~494 옥텟 + 마이크(있는 경우) | 0-8175 옥텟 + MIC(있는 경우) |
| CRC 보호 | PDU 헤더 영역과 페이로드 영역을 통합한 단일 32b CRC | 블록당 32b CRC; 각 블록 바로 뒤에 해당 블록의 CRC가 이어집니다. |
| 주요 고려 사항 | 단순함; 일반적인 PDU 모델과 유사함 | 더 긴 패킷을 통해 처리량이 향상되며, 선택적 블록 확인 및 재전송 기능을 지원합니다. |
| PHY 간격 지원 | 아니 | 예 |
PF1의 경우, 통신 중 내결함성을 높이기 위해 PHY 계층에서 구간으로의 분할과 종단 처리, PITS가 필수적으로 적용되어야 합니다(단, 페이로드 영역이 구간 길이보다 짧은 경우는 예외입니다).
링크 Layer 계층에서는 선택적 확인 및 재전송을 가능하게 하기 위해 페이로드를 블록 단위로 분할합니다. 이 블록들은 링크 Layer 가 블록 맵/비트맵을 통해 추적하고 참조합니다. PHY 계층에서는 비트스트림 처리 파이프라인의 간격 조정 단계를 통해 페이로드 영역을 PHY 인터벌이라고 하는 고정 길이의 심볼 스트림으로 추가로 분할합니다.
PHY 인터벌은 고정된 수의 페이로드 전달 심볼로 구성되며, 그 뒤에는 종료 심볼 시퀀스와 PHY 인터벌 트레이닝 시퀀스(PITS)가 이어집니다. 단, 마지막 인터벌 직후는 예외입니다. PITS는 알려진 트레이닝 패턴을 제공하여, 패킷 전송 중( 수신기 ) 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷 전송 중 패킷
PHY 간격 크기는 표 5.5에 표시된 바와 같이 제어 헤더의 PHY INT 필드를 통해 설정됩니다.
표 5.5 – PHY 간격별 기호 수
| PHY INT | 구간별 기호 수 |
|---|---|
| 0b00 | 128 |
| 0b01 | 256 |
| 0b10 | 384 |
| 0b11 | 512 |
이 PHY 간격에 대한 비트스트림에는 필요한 FEC 종단 비트와 (필요한 경우) 제로 패딩도 포함됩니다. 변조 후, PHY 간격당 실제 심볼 수는 표 5.6에 상세히 설명된 바와 같이 데이터 전송 속도에 따라 약간 달라질 수 있습니다.
또한 PHY 속도에 따라 심볼당 비트 수가 다르다는 점에 유의하십시오. 따라서 PHY INT 0b00의 데이터는 HDT2에서 128비트(16옥텟), HDT3에서 192비트(24옥텟), HDT4에서 256비트(32옥텟), HDT6에서는 384비트(48옥텟), HDT7.5에서는 480비트(60옥텟)입니다.
표 5.6 – 데이터 전송 속도에 따른 PHY 간격별 심볼 수
| PHY INT | HDT2 | HDT3 | HDT4 | HDT6 | HDT7.5 |
|---|---|---|---|---|---|
| 0b00 | 133 | 132 | 131 | 130 | 130 |
| 0b01 | 261 | 260 | 259 | 258 | 258 |
| 0b10 | 389 | 388 | 387 | 386 | 386 |
| 0b11 | 517 | 516 | 515 | 514 | 514 |
시각화를 위해, 그림 5.11에서는 PF1의 구조를 다시 보여 주며, 페이로드 영역이 PHY 간격으로 추가로 분할된 모습을 설명하고 있다.
그림 5.11 – PF1 페이로드 영역을 블록 및 PHY 간격으로 분할
PHY 계층의 관점에서 볼 때, 그림 5.12는 시각화를 위해 세 가지 HDT 패킷 형식을 모두 심볼 단위로 나타낸 또 다른 관점을 제시합니다.
그림 5.12 – HDT 패킷 형식의 PHY 계층 관점
종료 심볼은 HDT 패킷 내 심볼 스트림의 끝을 표시하며, 각 종료 심볼 세트는 앞선 심볼 스트림의 변조 방식에 따라 변조된 두 개의 전비트(all-zero-bit) 심볼로 구성됨을 유의하십시오. PF0의 경우, 종료 심볼은 제어 헤더(Control Header) 뒤와 PDU 헤더 및 페이로드가 결합된 부분 뒤에 삽입됩니다. PF1의 경우, 종결 심볼은 제어 헤더 뒤, PDU 헤더 뒤, 그리고 각 PHY 간격 뒤에 나타납니다.
6. 블루투스® HDT 링크 Layer (LL)
블루투스 HDT는 새로운 기능이나 업데이트된 기능, 절차 및 제어 PDU를 도입하여, 블루투스 LE 링크 Layer 의 기능을 확장함으로써 새로운 PHY 및 패킷 형식을 지원하고, HDT가 목표로 하는 처리량, 성능, 신뢰성 및 보안 향상을 실현합니다.
대략적으로 말해, ‘기능(features)’은 장치가 지원할 수 있는 능력을 정의하는 반면, ‘절차(procedures)’는 장치가 이러한 능력을 사용하거나 관리하기 위해 수행해야 하는 연계된 작업을 정의합니다. 제어 PDU(Control PDUs)는 절차를 실행하는 데 필요한 정보, 매개변수 및/또는 상태( 상태 ) 변경 사항을 전달하기 위해 장치 간에 교환되는 제어 데이터 단위( 링크 Layer ) 메시지입니다. 이처럼, ‘기능’은 어떤 능력이 사용 가능한지를 설명하고, ‘절차’는 장치가 그 사용을 어떻게 연계하는지를 정의하며, ‘제어 PDU’는 이러한 연계를 수행하는 데 사용되는 메시지를 제공합니다.
이 섹션에서는 Bluetooth HDT로 인해 확장된 ‘ 링크 Layer ’ 기능에 대한 개요를 제공하며, HDT 활성화를 위한 새로운 기능, 버전 업그레이드된 기능, 업데이트된 기능, 절차 및 제어 PDU에 대한 요약을 담고 있습니다. 링크 Layer
6.1 HDT용 새로운 ‘ 링크 Layer ’ 기능 개요
HDT의 시작 및 관리
Bluetooth® HDT는 데이터 물리 채널 및 ACL 전송을 통해 이루어지는 연결 기반 작업을 통해 시작되고 관리됩니다. 그러나 기기 간에 HDT 지원 링크가 설정되면, 이를 통해 ACL 연결이나 연결된 등시성 스트리밍을 지원할 수 있습니다.
동시 방송의 경우, 기기들은 GFSK 기반 광고를 사용하여 방송 서비스 식별자( 주기적 광고)를 찾아야 합니다. 그러면 ACL 연결 없이도 하나 이상의 BIS를 포함하는 BIG을 송수신할 수 있습니다. HDT PHY는 현재 어떠한 형태의 광고도 지원하지 않습니다.
전반적으로, HDT 작동은 항상 정의된 ‘ 링크 Layer ’ 절차를 통해 명시적으로 시작되어야 합니다. 또한 양방향 링크에서 대칭적인 PHY 사용이 요구되며(브로드캐스팅 제외), 즉 송신 및 수신 활동 모두 상황에 따라 HDT PHY를 사용하거나 GFSK PHY를 사용해야 합니다. HDT PHY를 사용할 경우, 데이터 전송 속도는 패킷 단위로 독립적으로 달라질 수 있으며, 양방향에서 동일한 속도를 사용해야 할 필요는 없습니다.
새로운 HDT 구성 교환 절차를 통해 장치들은 통신하며 지원되는 HDT 기능(예: 최대 데이터 전송 속도, 패킷 형식, 페이로드 크기 등)을 협상할 수 있습니다. 그런 다음, 버전 업된 LL_PHY_REQ [v2], LL_PHY_RSP [v2] 및 LL_PHY_UPDATE_IND [v2] 제어 PDU를 사용하여 PHY 업데이트 절차를 실행하면, 통신을 HDT PHY로 전환하거나 HDT로의 전환 및 HDT에서 벗어나는 과정을 관리할 수 있습니다. 장치 간 HDT 기능이 호환되지 않거나 지원되지 않는 경우, 또는 운영 조건상 필요한 경우, 통신은 GFSK PHY 상태를 유지하거나 GFSK PHY로 복귀할 수 있으며, 가시성 및 제어를 위해 모든 PHY 상태 변경 사항은 HCI 이벤트를 통해 호스트에 보고됩니다.
HDT 데이터 길이 관리 및 스케줄링
HDT는 데이터 길이 관리 기능을 도입하여, 링크 Layer 가 HDT 및 GFSK PHY를 통해 설정된 각 연결에 대해 별도의 전송 길이 및 타이밍 매개변수를 유지할 수 있도록 합니다. 또한, 이러한 매개변수의 업데이트된 값 범위 제한 를 통해 더 큰 패킷 페이로드를 허용하는 동시에, 패킷에 대한 최대 전송 에어타임 제한 을 강제 적용합니다. 컨트롤러는 패킷 전송 시간을 제한 범위 내로 유지하기 위해 필요한 경우 대용량 페이로드를 여러 블록으로 분할하거나 선택된 데이터 전송 속도를 조정할 수 있습니다. 이를 통해 블루투스 LE 연결 이벤트 및 여러 링크와/또는 등시성 스트림의 동시 작동에 대한 타이밍 및 스케줄링 요구 사항을 충족할 수 있습니다.
‘데이터 길이 업데이트(Data Length Update)’ 절차를 통해 장치는 LL 데이터 PDU에 사용할 최대 송신/수신 길이 및 타이밍 매개변수를 통신할 수 있습니다. 버전이 업데이트된 LL_LENGTH_REQ [v2] 및 LL_LENGTH_RSP [v2] 제어 PDU를 사용하여 이 절차를 실행하면, 해당 매개변수가 적용될 PHY를 지정할 수 있습니다.
HDT 링크 품질
HDT는 블루투스 LE에 선택적 링크 품질 피드백(LQF) 기능을 제공하여, 전용 링크 품질 피드백( 링크 Layer ) 절차를 통해 채널 상태에 대한 실시간 정보를 교환할 수 있게 합니다. 이 기능이 활성화되면 전송되는 패킷에 링크 품질 지표가 포함되며, 컨트롤러 간에 지속적으로 전달됩니다. 이 정보를 바탕으로 변화하는 무선 환경에 대응하여 링크 운영에 대한 동적인 결정을 내릴 수 있습니다. 예를 들어, 전송 매개변수를 조정하거나, 다른 HDT 데이터 전송 속도를 선택하거나, 상황이 요구할 경우 GFSK PHY로 다시 전환하는 등의 조치가 가능합니다.
장치는 새로운 HDT 링크 품질 활성화 절차와 새로운 LL_HDT_LQF_REPORTING_IND 제어 PDU를 함께 사용하여, 패킷에 링크 품질 정보를 포함하기 시작하거나 포함을 중단해야 하는 시점을 알릴 수 있습니다.
HDT 및 동기 채널
HDT는 블루투스 LE의 등시성 전송 기능을 확장하여, 새로운 HDT PHY를 통해 연결형 또는 브로드캐스트형 등시성 스트림을 지원합니다.
디바이스는 HDT에 특화된 작동 매개변수(예: HDT PHY, 데이터 전송 속도, 페이로드 윈도우 크기, 등)을 협상하고, 버전 업그레이드된 LL_CIS_REQ [v2] 및 LL_CIS_IND [v2] 제어 PDU를 사용하는 ‘연결된 등시성 스트림 생성(Connected Isochronous Stream Creation)’ 절차를 통해 HDT PHY 및 패킷을 사용하여 대용량 페이로드를 안정적으로 전달할 수 있는 시간 제한 등시성 스트림을 설정할 수 있습니다. 특히, 높은 처리량을 갖춘 연결형 아이소크로너스 통신은 Bluetooth LE를 활용한 고품질 오디오 솔루션 및 애플리케이션 구현에 필수적입니다.
방송의 경우, 링크 Layer의 무선 인터페이스 프로토콜에 포함된 등시성 방송 상태 이 HDT 데이터 길이 관리를 위한 더 넓은 BIG 매개변수 값 범위, 수정된 BIGInfo 헤더 필드, 블록 기반 확인 응답 지원 등을 포함하여 업데이트되었습니다. 이를 통해 동기화된 수신기는 주기적 광고 및 등시성 방송에 대해 정의된 기존 타이밍 및 동기화 요구 사항을 준수하면서 HDT를 활용하여 고처리량 방송 스트림을 처리할 수 있습니다.
HDT 보안 및 암호화
HDT는 더 긴 메시지 무결성 검사(MIC) 크기를 지원하고, 암호화 키를 생성 및 갱신하기 위한 새로운 암호화 키 스케줄(EKS) 기능 을 도입함으로써 블루투스 LE의 보안을 강화합니다. 암호화 키 관리자( 링크 Layer )는 기기 간 매개변수 교환을 조정하고, 통신이 암호화된 상태를 유지하면서 HDT 작동으로의 전환을 관리합니다.
새로운 ‘키 스케줄을 사용한 암호화 시작(Encryption Start with Key Schedule)’ 절차를 통해, 장치들은 LL_ENC_ECDH_REQ 및 LL_ENC_ECDH_RSP 제어 PDU를 사용하여 암호화 관련 매개변수를 교환하고, HDT에서 지원하는 새로운 MIC 크기(128b 또는 64b) 중 하나를 연결에 사용할 수 있습니다. 장치에서 링크 암호화를 위한 장기 키와 세션 키가 계산되면, LL_START_ENC_REQ 및 LL_START_ENC_RSP PDU를 통해 암호화가 시작됩니다. EKS는 GFSK PHY에서도 사용할 수 있으며, 이 경우 적용 가능한 MIC 크기는 32b뿐입니다.
또한, EKS 기능 를 지원하는 장치의 경우, PHY 업데이트 및 암호화 갱신 절차를 통해 버전 업그레이드된 LL_PHY_REQ [v2], LL_PHY_RSP [v2] 및 LL_PHY_UPDATE_IND [v2] 제어 PDU를 사용하여, 연결을 끊거나 암호화를 일시 중지하지 않고도 PHY 변경과 암호화 키 갱신 를 동시에 구현할 수 있습니다. 명확히 하자면, MIC 크기 변경은 항상 키 갱신 를 강제하지만, 키 갱신 는 MIC 크기 변경을 강제하지 않습니다.
본 문서의 제7절에서는 HDT 암호화에 대해 보다 상세히 다루고 있습니다.
HDT 신뢰성 및 유량 제어
HDT는 전송 오류를 감지하고 관리하기 위해 페이로드를 블록 단위로 평가하는 선택적 확인( 링크 Layer ) 메커니즘을 지원합니다. 블루투스 LE의 기존 시퀀스 번호 지정 및 확인 응답 메커니즘은 여전히 페이로드의 누적 확인 응답과 패킷 순서 유지를 위해 사용되지만, HDT는 이를 블록 단위의 선택적 확인 응답으로 보완합니다. HDT 패킷의 SN, NESN, RxPayloadMap, RxBitmap, Nb 및 BlockSize 필드는 LL에서 블록에 대한 확인 응답 여부를 확인하고, 그에 따라 재전송이 필요한지 판단하는 데 사용됩니다. 이를 통해 대용량 페이로드 중 영향을 받은 부분만 재전송함으로써 재전송 오버헤드를 최소화합니다.
또한 HDT는 수신 장치가 추가적인 버퍼링이나 처리 시간이 필요할 때 새로운 페이로드의 전송을 일시적으로 중단할 수 있게 해주는 즉각적인 흐름 차단(flow-off) 메커니즘을 통해, 확장 패킷 헤더( 링크 Layer )의 흐름 제어를 강화합니다. 확장 패킷 헤더에 포함된 정보를 활용하여, 전송 장치( 수신기 )는 재전송 활동은 계속 허용하면서 상대 장치에 새로운 데이터 전송을 중단하라는 신호를 보낼 수 있습니다. 수신 장치( 수신기 )가 추가 트래픽을 수신할 준비가 되면, 연결 재구성이나 기타 상위 계층의 개입 없이도 정상적인 데이터 전송을 재개할 수 있습니다.
6.2 HDT용 링크 Layer 기능
블루투스 LE 링크 Layer 는 컨트롤러가 지원하는 기능을 식별하기 위해 블루투스 코어 사양 [Vol 6] Part B, Section 4.6에 정의된 ‘ FeatureSet ’ 비트 마스크를 사용합니다. HDT의 경우, ‘ FeatureSet ’에서는 기본 HDT 기능에 대한 지원을 나타내는 비트와 더불어, 더 높은 HDT 전송 속도, 패킷 형식 1(Packet Format 1), 링크 품질 피드백(Link Quality Feedback), HDT PHY를 통한 등시성(isochronous) 작동 등 선택적 HDT 기능에 대한 지원을 나타내는 추가 비트들을 도입하고 있습니다.
다음은 HDT 기능을 지원하기 위해 도입된 HDT 관련 FeatureSet 비트 목록입니다:
- 77 – 고속 데이터 처리량
- 78 – HDT6 요금 적용 받기
- 79 – HDT6 전송 속도
- 80 – HDT7.5 등급 적용
- 81 – HDT7.5 속도 전송
- 82 – HDT 패킷 형식 1
- 83 – 링크 품질 피드백
- 84 – LE HDT PHY의 등시성 브로드캐스터
- 85 – LE HDT PHY에서 동기화된 수신기
각 FeatureSet 비트에 대해, 본 사양서는 컨트롤러가 해당 기능을 지원함을 나타내기 위해 충족해야 하는 요구 사항을 정의하며, 여기에는 해당되는 경우 관련 PHY 기능, 패킷 형식, 절차 및 제어 PDU가 포함됩니다.
다음에서는 고속 데이터 처리량 FeatureSet 비트와 관련된 필수 요구 사항을 설명합니다. 선택적 HDT 기능 지원을 나타내는 나머지 모든 FeatureSet 비트에 대해서는, Bluetooth 핵심 사양 [Vol 6] Part B, Section 4.6을 참조하여 해당 비트의 전체 정의 및 관련 지원 요구 사항을 확인하십시오.
높은 데이터 처리량
고속 데이터 처리량 기능을 지원하는 컨트롤러는 LE Encryption with Diversifiers, LE Data Packet Length Extension, Encryption Key Schedule 및 Channel Selection Algorithm #2 기능을 지원해야 할 뿐만 아니라, 다음과 같은 HDT 기능도 지원해야 합니다:
- LE HDT PHY ([제6권] A편, 3.6절 및 4.1.2절 참조)
- HDT 심볼 스트림 처리([제6권] A편, 제7절), 다음을 제외함:
- PHY 간격 ([제6권] A편, 7.2절)
- 16QAM 심볼 매핑 ([제6권] A편, 7.3.3절)
- PITS ([제6권] A편, 7.4.5절)
- 송신기 RMS EVM 수준 ([제6권] A편, 부록 C)
- LE HDT PHY의 패킷 형식([제6권] B부, 2.7절), 다음을 제외함:
- 패킷 형식 1
- 페이로드 블록 구조 ([제6권] B부, 2.7.4절)
- 링크 품질 ([제6권] B부, 2.7.2.4.1절)
- 32b CRC 생성 ([제6권] B부, 3.1.2절)
- LE HDT에 대한 비트스트림 처리([제6권] B부, 3.4절), 다음을 제외함:
- 구간 간격 ([제6권] B부, 3.4.2절)
- HDT 구성 교환 절차([제6권] B부, 5.1.34절), 다음을 제외함:
- LE HDT PHY에서 등시성 브로드캐스터, 동기화 수신기, 브로드캐스트 등시성 스트림, 그룹 및 PDU를 활용하는 용도
- LL_LENGTH_REQ [v2] 및 LL_LENGTH_RSP [v2] PDU
- LL_HDT_CONFIG_REQ 및 LL_HDT_CONFIG_RSP PDU
또한, ‘ 고속 데이터 처리량 ’ 기능과 ‘Connected Isochronous Stream(Central 또는 Peripheral)’ 기능 을 지원하는 컨트롤러는 다음 사항도 지원해야 합니다:
- LL_CIS_REQ [v2] 및 LL_CIS_IND [v2]
자세한 내용은 ([제6권] B부, 4.6.54절)을 참조하십시오.
6.3 HDT에 대한 링크 Layer 절차
6.3.1 새로운 절차
HDT 기능을 지원하기 위해 ACL 링크용 링크 Layer 제어 프로토콜에 다음과 같은 절차가 도입되었습니다:
- HDT 구성 교환 절차
- HDT 링크 품질 활성화 절차
다음은 해당 기능의 개요와 이를 시작 및 완료하는 데 필요한 PDU에 대한 설명입니다. 이러한 절차는 ACL 링크에 대한 연결 상태 를 입력한 후에만 수행할 수 있다는 점에 유의하십시오.
HDT 구성 교환 절차
LE HDT PHY의 연결과 관련된 구성 값을 변경합니다. 교환된 값은 LE HDT PHY의 기존 ACL이나 CIS에는 영향을 미치지 않습니다. 이 값들은 이후에 생성되는 CIS에 적용되며, GFSK PHY에서 LE HDT PHY로 전환될 때 ACL에도 적용됩니다. 이 절차는 LL_HDT_CONFIG_REQ PDU를 전송함으로써 시작되며, LL_HDT_CONFIG_RSP PDU를 수신하면 완료됩니다. 전송되는 각 PDU는 전송 장치의 구성에만 관련되므로, 양측에서 시작된 절차 간의 충돌이 발생하더라도 아무런 문제가 없습니다.
HDT 링크 품질 활성화 절차
지정된 전송 경로를 통해 전송되는 각 패킷에서 링크 품질 피드백의 전송을 시작하거나 중지하도록 원격 제어기에 요청합니다. 이 절차는 LL_HDT_LQF_REPORTING_IND PDU를 전송함으로써 시작되며, LL_HDT_LQF_REPORTING_IND PDU에 대한 확인 응답을 수신하면 완료됩니다. 링크 품질 피드백은 동일한 절차를 통해 비활성화됩니다.
6.3.2 개정된 절차
HDT 기능을 지원할 수 있도록 다음 ACL 제어 절차가 수정되었습니다:
- 암호화 절차
- ‘Diversifiers’를 활용한 암호화 시작하기 (1부)
- 키 스케줄링 절차를 통한 암호화 시작 (1부)
- ‘다이버시파이어를 이용한 암호화 시작’ 및 ‘키 스케줄을 이용한 암호화 시작’ 절차 (2부)
- 암호화 일시 중지 절차
- 데이터 길이 업데이트 절차
- PHY 업데이트 및 암호화 갱신 절차
- 연결된 등시성 스트림 생성 절차
- 프레임 공간 업데이트 절차
다음은 업데이트된 모든 절차의 기능과 해당 절차를 시작 및 완료하는 데 필요한 PDU에 대한 요약입니다. 다시 한 번 강조하건대, 이러한 절차는 ACL 링크에 대한 연결 상태 에 진입한 후에만 수행할 수 있습니다.
암호화 절차
데이터 PDU의 암호화 및 인증을 활성화하여 페이로드의 기밀성과 무결성을 보호합니다. 중앙 장치와 주변 장치 모두 암호화 키 스케줄(EKS) 기능 을 지원하는 경우, 중앙 장치는 ‘키 스케줄을 사용한 암호화 시작(Encryption Start with Key Schedule)’ 절차를 시작하고, 그렇지 않은 경우 ‘다이버시파이어를 사용한 암호화 시작(Encryption Start with Diversifiers)’ 절차를 시작합니다. 연결이 암호화되면, 중앙 장치와 주변 장치 모두 EKS를 지원하는 경우 중앙 장치( 링크 Layer )는 ‘PHY 업데이트 및 암호화 갱신(PHY Update and Encryption Refresh)’ 절차를 사용하여 암호화 키를 변경할 수 있으며, 그렇지 않은 경우에는 ‘암호화 일시 중지(Encryption Pause)’ 절차를 통해 변경할 수 있습니다.
“다이버시파이어를 이용한 암호화 시작” 절차와 “키 스케줄을 이용한 암호화 시작” 절차는 모두 두 부분으로 구성됩니다. 첫 번째 부분은 두 절차에서 서로 다르지만, 두 번째 부분은 두 절차 모두 동일합니다.
‘Diversifiers’를 활용한 암호화 시작하기 (1부)
암호화를 활성화하기 위해, 중앙 장치와 주변 장치는 각각 초기화 벡터(IV)와 세션 키 다이버시파이어(SKD)의 해당 부분을 생성한 후, LL_ENC_REQ 및 LL_ENC_RSP PDU를 통해 이를 교환합니다. 그런 다음 각 LL은 IV와 SKD 부분을 결합합니다. 주변 장치 호스트는 사용할 장기 키(LTK)를 해당 LL에 알립니다. 암호화는 LL_START_ENC_REQ 및 LL_START_ENC_RSP PDU를 사용한 3단계 핸드셰이크를 통해 시작됩니다.
키 스케줄링 절차를 통한 암호화 시작 (1부)
암호화를 활성화하기 위해, 중앙 장치와 주변 장치는 각각 공개 키(PubKey)와 난수(Rand)의 해당 부분을 생성한 후, LL_ENC_ECDH_REQ 및 LL_ENC_ECDH_RSP PDU를 통해 이를 교환합니다. GFSK PHY를 사용하는 경우, 연결에는 32비트 MIC가 사용됩니다. HDT PHY를 사용하는 경우, 64비트 MIC를 사용하도록 플래그가 설정되지 않은 한 연결에는 128비트 MIC가 사용됩니다.
다이버시파이어를 이용한 암호화 시작 및 키 스케줄을 이용한 암호화 시작 절차 (2부)
암호화에 사용할 장기 키(LTK)의 종류(예: 기회적 암호화를 사용하는 경우 모두 0)와 그 출처(예: 호스트가 LL에 제공)를 결정합니다. 중앙(Central)의 경우, 호스트는 항상 LTK를 중앙 보안 관리자( 링크 Layer)에게 제공한다. 주변기기(Peripheral)의 경우, LTK를 제공할 수도 있고 제공하지 않을 수도 있다. LTK를 제공하는 경우, LL은 이를 사용하여 세션 키를 계산한다. 세션 키 계산은 ‘다이버시파이어를 이용한 암호화 시작’의 경우 [Vol 3] 파트 H, 섹션 2.2.1을, ‘키 스케줄을 이용한 암호화 시작’의 경우 [Vol 6] 파트 E, 섹션 4.2.1을 기반으로 한다.
암호화 일시 중지 절차
두 암호화 시작 절차를 모두 포함하고 있습니다. 따라서 동일한 업데이트가 적용됩니다.
데이터 길이 업데이트 절차
LL 데이터 PDU에 대한 현재 최대 수신(Max Rx) 및 전송(Tx) 페이로드 길이와 시간의 최신 값(connMaxRxOctets, connMaxRxTime, connMaxTxOctets 및 connMaxTxTime)을 피어 장치로 전송하는 데 사용됩니다. 사양서의 문구를 수정하여, 컨트롤러가 연결에 대해 하나 이상의 매개변수 세트를 지원하는 경우, 이 절차에서 업데이트할 세트를 선택할 수 있음을 명확히 했습니다. 이 절차는 센트럴 또는 페리페럴이 LL_LENGTH_REQ PDU를 전송함으로써 시작됩니다. 이 요청에 대해서는 LL_LENGTH_RSP PDU로 응답합니다. 응답은 요청 PDU에 지정된 매개변수 세트를 업데이트합니다.
PHY 업데이트 및 암호화 갱신 절차
ACL 연결의 송신(Tx) 또는 수신(Rx) PHY(또는 둘 다)를 변경하거나, 장치가 EKS 기능 또는 둘 다를 지원하는 경우 암호화 키와 IV를 갱신하는 데 사용됩니다. 이는 CIS와 연관된 PHY나 키/IV에는 영향을 미치지 않습니다. 요청은 LL_PHY_REQ PDU를 사용하여 시작됩니다. 요청에 대한 응답은 LL_PHY_RSP PDU로 이루어집니다. 중앙 장치는 항상 마지막 단계로 LL_PHY_UPDATE_IND PDU를 전송합니다.
HDT는 PHY 업데이트를 요청하거나 응답하기 전에 전송 중이거나 대기 중인 데이터를 어떻게 처리할지, 암호화 키 갱신 를 어떻게 관리할지, 무효한 동작 등을 명확히 하는 규칙 문구를 도입합니다. 또한, HDT는 암호화 키 갱신 요청을 요구(LL_PHY_REQ/RSP의 경우)하거나 표시(LL_PHY_UPDATE_IND의 경우)하기 위한 Refresh 필드와, HDT PHY에서 선호하는 MIC 길이를 나타내는 MIC_Length 필드가 포함된 PDU의 [v2]를 도입합니다. 64b MIC 길이는 양측 모두 이를 요구하는 경우에만 선택된다는 점에 유의해야 합니다. 한 장치가 상대방이 요구하는 보안 수준을 낮출 수는 없습니다.
연결된 등시성 스트림 생성 절차
중앙 장치와 주변 장치 간에 CIS를 생성하는 데 사용됩니다. 이 요청은 중앙 장치만이 LL_CIS_REQ PDU를 사용하여 시작합니다. 요청이 수락된 경우 주변 장치는 LL_CIS_RSP PDU로 응답하고, 거부된 경우 LL_REJECT_EXT_IND PDU와 적절한 이유 코드를 사용하여 응답합니다. 응답을 수신하면, 중앙 장치는 LL_CIS_IND PDU로 응답하여 CIS를 생성하거나, LL_REJECT_EXT_IND PDU로 CIS 생성을 취소합니다. HDT는 GFSK 또는 HDT PHY에서 CIS를 생성하는 요건과 PDU 버전, 대칭형 PHY 및 EKS 기능 의 사용에 관한 규칙을 명확히 규정합니다.
6.4 HDT용 링크 Layer 제어 PDU
6.4.1 새로운 제어 PDU
다음은 무선 통신을 통한 HDT 지원에 관한 새로 정의된 절차와 관련된 요청, 응답 또는 표시를 전달하기 위해 도입된 새로운 제어 PDU(데이터 물리 채널용)입니다:
- (0x40) LL_ENC_ECDH_REQ
- (0x41) LL_ENC_ECDH_RSP
- (0x42) LL_HDT_CONFIG_REQ
- (0x43) LL_HDT_CONFIG_RSP
- (0x44) LL_HDT_LQF_REPORTING_IND.
다음은 CtrData 필드의 형식과, 해당 필드 아래에 있는 각 필드에 대한 한 줄 분량의 설명입니다.
LL_ENC_ECDH_REQ

- Flags_C: Central의 암호화 플래그 [비트 0: 0=128비트 MIC, 1=64비트 MIC; 비트 1: 기회적 암호화]
- Rand_C: Central에서 제공한 난수
- KeyType_C: 중앙에서 사용하는 공개 키의 유형 [0=P-256 타원 곡선을 사용하여 파생됨]
- PubKey_C: Central의 ECDH 공개 키 [Pubkey_C31-0 = X 좌표, Pubkey_C63-32 = Y 좌표]
LL_ENC_ECDH_RSP

- Flags_P: 주변 장치의 암호화 플래그 [비트 0: 0=128비트 MIC, 1=64비트 MIC]
- Rand_P: 주변 장치에서 제공하는 난수
- KeyType_P: 주변 기기에서 사용하는 공개 키의 유형 [0=P-256 타원 곡선을 사용하여 파생됨]
- PubKey_P: 주변 장치의 ECDH 공개 키 [Pubkey_C31-0 = X 좌표, Pubkey_C63-32 = Y 좌표]
LL_HDT_CONFIG_REQ 및 LL_HDT_CONFIG_RSP

- ACL_RX_Payload_Window_Size: 수신(RX) 방향에서 ACL 연결에 사용되는 PayloadWindowSize보다 1 작은 값으로 설정됩니다. 기본값 = 0
- Max_CIS_TX_Payload_Window_Size: 관련 CIS에서 TX 방향으로 사용되는 최대 페이로드 윈도우 크기보다 1 작은 값으로 설정합니다. 기본값 = 0
- Max_CIS_RX_Payload_Window_Size: 수신(RX) 방향에서 관련 CIS에서 사용되는 최대 페이로드 윈도우 크기보다 1 작은 값으로 설정합니다. 기본값 = 0
- ACL_RX_Rates: 컨트롤러가 ACL 연결을 통해 원격 컨트롤러로부터 수신할 수 있는 속도 [bit0: HDT2; bit1: HDT3; bit2: HDT4; bit3: HDT6; bit4: HDT7.5]
- Max_ACL_RX_Octets_Per_Packet: ACL 연결에서 단일 패킷으로 수신할 수 있는 최대 데이터 옥텟 수입니다. MIC, 종료 시퀀스, PITS 등은 제외됩니다.
LL_HDT_LQF_REPORTING_IND

- 전송: [bit0: ACL; bit1: CIS]에 대해 LQF 보고가 활성화되었는지 또는 비활성화되었는지를 나타내는 논리적 전송
6.4.2 업데이트된 제어 PDU
다음은 무선 통신(over the air)을 통한 HDT 지원에 대한 업데이트된 링크 Layer 절차와 관련된 요청, 응답 또는 표시를 전달하기 위해 필드가 수정되거나 추가된 업데이트된 제어 PDU(데이터 물리 채널용)입니다:
- (0x14) LL_LENGTH_REQ
- (0x15) LL_LENGTH_RSP
- (0x16) LL_PHY_REQ
- (0x17) LL_PHY_RSP
- (0x18) LL_PHY_UPDATE_IND
- (0x1F) LL_CIS_REQ
- (0x21) LL_CIS_IND
- (0x23) LL_POWER_CONTROL_REQ.
다음은 CtrData 필드의 형식과, 해당 필드 하위에 있는 모든 필드에 대한 한 줄 분량의 설명(수정되거나 추가된 내용 포함)입니다. 참고: HDT 지원을 위한 수정 결과, 이러한 LL 제어 PDU는 이제 [v1] 또는 [v2]로 표시된 하나 이상의 형식을 가질 수 있습니다. CtrData 필드 내의 각 필드는 포함된 모든 형식에서 동일한 의미를 가집니다.
LL_LENGTH_REQ 및 LL_LENGTH_RSP

- PHY_S: PDU가 적용되는 PHY 매개변수 세트를 나타냅니다 [0=GFSK; 1=HDT]; LL_LENGTH_RSP에서는 이 필드가 무시됩니다.
LL_PHY_REQ 및 LL_PHY_RSP

- TX_PHYS: 송신기 PHY 송신측은 [bit0: LE_1M; bit1: LE_2M; bit2: LE 코디드; bit4: HDT]를 사용하는 것을 선호합니다.
- RX_PHYS: 수신기 PHY의 송신 측은 [bit0: LE_1M; bit1: LE_2M; bit2: LE 코디드; bit4: HDT]를 사용하는 것을 선호합니다.
- 새로 고침: 키 갱신 [1=필수]; 포함되지 않은 경우 값=0이며, 연결이 암호화되지 않았거나 양쪽 기기 중 하나라도 EKS를 지원하지 않는 경우 무시됩니다. 기능
- MIC_Length: [1=HDT용 64비트 MIC 요청, 0 또는 미기재=HDT용 128비트 MIC]; 연결이 암호화되지 않았거나, 키가 갱신되지 않았거나, GFSK PHY로 변경된 경우에는 무시됨
LL_PHY_UPDATE_IND

- PHY_C_TO_P: 중앙에서 전송된 패킷용 PHY [bit0: LE_1M; bit1: LE_2M; bit2: LE 코디드; bit4: HDT]
- PHY_P_TO_C: 주변 장치에서 전송된 패킷용 PHY [bit0: LE_1M; bit1: LE_2M; bit2: LE 코디드; bit4: HDT]
- Instant: 연결 이벤트 카운터 값으로 참조되는, 미래의 특정 연결 이벤트
- 주소: ACL 연결에서 해당 시점 이후에 사용될 PHY의 물리적 채널 주소
- 갱신: 1=암호화 키가 갱신됩니다; 0 또는 미기재=암호화 키가 갱신되지 않거나 연결이 암호화되지 않습니다
- MIC_Length: [1=HDT용 리프레시 및 64비트 MIC, 0 또는 미포함=HDT용 128비트 MIC]; 연결이 암호화되지 않았거나, 키가 리프레시되지 않았거나, GFSK PHY로 변경된 경우 무시됨
LL_CIS_REQ

- Max_Payload_C_To_P: 중앙 장치(Central)가 CIS PDU를 통해 전송할 수 있는 최대 링크 Layer 페이로드 크기(바이트 단위)
- Max_Payload_P_To_C: 주변기기가 CIS PDU를 통해 전송할 수 있는 최대 링크 Layer 페이로드 크기(바이트 단위)
- Rates_C_To_P: 중앙에서 허용되는 속도 [bit0: HDT2; bit1: HDT3; bit2: HDT4; bit3: HDT6; bit4: HDT7.5]
- Rates_P_To_C: 주변 장치에서 허용되는 속도 [bit0: HDT2; bit1: HDT3; bit2: HDT4; bit3: HDT6; bit4: HDT7.5]
- Payload_Window_Size_C_To_P: Central이 추적, 전송 및 재전송할 수 있는 윈도우 내 페이로드의 수 (1~4)
- Payload_Window_Size_P_To_C: 주변 장치가 추적, 전송 및 재전송할 수 있는 윈도우 내 페이로드 수 (1~4)
- MIC_Length: CIS가 HDT PHY에 있고 암호화된 경우, 1은 64비트 MIC를, 0은 128비트 MIC를 의미하며, 그렇지 않은 경우 무시됨
- SE_Length: 하위 이벤트에 대해 예약해야 하는 시간(us 단위)
LL_CIS_IND

- GFSK PHY에서 CIS인 경우: AA=CIS의 액세스 주소, 또는 PDU에 PCA-H가 포함된 경우 0
- HDT PHY의 CIS가 AA=HPA31-0인 경우, PCA-H가 반드시 존재해야 하며 HPA39-32로 설정되어야 합니다.
LL_POWER_CONTROL_REQ

- PHY: 요청 대상인 PHY [비트 0: 1M; 비트 1: 2M; 비트 2: 코드화 S=8; 비트 3: 코드화 S=2; 비트 4: HDT]
7. Bluetooth® HDT 암호화
HDT는 블루투스 LE의 암호화 및 인증 프레임워크를 강화하여 데이터 보호 기능을 강화하고, 기존 보안 모델과의 호환성을 유지하며, 블루투스 기술이 업계 및 규제 기관의 보안 동향을 따라갈 수 있도록 지원합니다.
이 섹션에서는 Bluetooth® HDT를 계기로 도입된 암호화 관련 개선 사항에 대한 개요와, 이를 구현하기 위해 도입된 새로운 기능, 절차 및 매개변수에 대한 요약을 제공합니다.
7.1 HDT 암호화 기능 개선 사항 개요
HDT는 더 긴 메시지 무결성 검사(MIC) 크기 지원과 Bluetooth Core 7.0에서 도입된 새로운 암호화 키 스케줄(EKS) 기능 을 지원함으로써 블루투스 LE의 암호화 기능을 강화합니다. 그러나 전반적인 암호화 및 인증 프로세스는 여전히 기존 암호화 알고리즘에 의존하며, 공유 비밀 설정에는 ECDH가, 키 도출에는 AES-CMAC가, 데이터 암호화 및 무결성 보호에는 AES-CCM이 사용됩니다.
더 큰 MIC 크기 지원
GFSK 기반 블루투스 PHY에서는, 암호화된 패킷에 추가되는 MIC의 길이가 32비트(4옥텟)로 고정되어 있습니다. HDT를 사용하면, 패킷 페이로드가 길어질수록 데이터 손상이나 변조가 감지되지 않을 확률을 줄이기 위해 더 긴 MIC가 필요합니다. 따라서 HDT는 다음과 같은 MIC 크기를 지원합니다:
- 64b (8 옥텟)
- 128b (16 옥텟)
MIC 크기는 링크 Layer 에서 관리하는 암호화 설정 단계에서 결정됩니다. 양측 중 어느 한 쪽이라도 128b를 선호할 경우, 128b가 선택됩니다. 새로운 MIC 크기는 HDT PHY를 통해 전송되는 패킷에만 적용될 수 있습니다(GFSK 기반 PHY는 계속해서 32b MIC를 사용합니다). 선택된 MIC 크기는 NIST 권고 사항에 따라 연결 전반에 걸쳐 대칭적으로 적용되며, 사용 중인 세션 키에 바인딩됩니다.
패킷 형식 1(PF1)을 사용하는 HDT 패킷의 경우, 암호화된 페이로드와 MIC는 전송 전(암호화 후)에 블록 단위로 분할됩니다. 따라서 각 블록은 수신되는 대로 복호화될 수 있지만, MIC 검증은 모든 블록이 성공적으로 수신되고 재조립된 후에야 수행될 수 있습니다.
암호화 키 스케줄(EKS) 지원
HDT로 작동하려면, 장치는 GFSK PHY를 사용하여 연결을 설정하고, 지원되는 HDT 기능을 파악하며, 구성 매개변수를 선택/교환한 다음, PHY 업데이트 및 암호화 갱신 절차를 통해 HDT PHY로 전환해야 합니다. 암호화 측면에서 보면, 이는 MIC 크기가 32비트에서 64비트 또는 128비트로 변경되는 것을 의미하며, 이에 따라 암호화 키를 변경해야 합니다.
암호화 키 스케줄(EKS, 기능 )은 암호화 키의 생성, 관리 및 갱신을 가능하게 하여, 연결을 끊거나 암호화 절차를 다시 시작할 필요 없이 PHY(및 MIC 크기) 변경을 지원할 수 있게 합니다. EKS는 ECDH에서 파생된 공유 비밀과 AES-CMAC 기반 키 유도 함수를 사용하여 다음을 지원합니다:
- 상황에 따른 암호화
- 완벽한 전방 비밀성(PFS)
- 키 및 MIC 업데이트가 동기화된 원활한 PHY 전환
- ACL 및 CIS 전송에 대한 스트림별 키 분리
기회적 암호화(Opportunistic Encryption)를 사용하면, 기기들은 사전에 공유된 수명 키(LTK) 없이도 암호화된 연결을 설정할 수 있어, 기기들이 페어링되지 않은 상태에서도 암호화된 통신이 가능합니다. 이는 ‘저스트 웍스(Just Works) ’ 방식을 사용하는 페어링 시나리오( LE 보안 연결 )와 유사한 기밀성과 무결성을 제공하지만, 인증 기능이나 중간자 공격(MITM) 방지 기능은 포함되지 않습니다.
PFS를 사용하면, 장치의 LTK, 개인 키 또는 현재 세션 키가 유출되더라도 이전 세션 키는 노출되지 않습니다. 따라서 이전의 암호화된 세션은 안전하게 유지됩니다. 암호화 갱신 후 세션 키가 노출되더라도, 암호화 갱신 이전의 세션 키에 대한 정보는 전혀 드러나지 않습니다. 세션 키만으로는 다른 세션 키나 트래픽 시크릿을 도출할 수 없습니다. 트래픽 시크릿이 주어지면 이후의 트래픽 시크릿은 도출할 수 있지만, 이전의 트래픽 시크릿은 도출할 수 없습니다.
이전에도 스트림별 키 분리는 가능했으나, 이를 위해서는 ‘다이버시파이어를 사용한 암호화’ 프로세스를 처음부터 다시 수행해야 했습니다. EKS PFS는 이 프로세스를 상당히 간소화합니다. 현재 CIS 세션은 CIS 세션 키를 갱신할 수 없기 때문에 유효 기간이 제한되어 있습니다.
HDT를 지원하는 장치의 경우 EKS 지원이 필수입니다. 연결에 포함된 두 장치 모두 EKS를 지원하는 경우, EKS를 반드시 사용해야 합니다. EKS를 지원하지 않는 경우, 다이버시파이어를 사용한 암호화가 계속 적용됩니다.
새로운 함수, 프로시저 및 매개변수
EKS 기능 의 일환으로, 새로운 암호화 함수, 새로운 암호화 태그 값 및 세션 키를 도출하기 위한 새로운 절차가 도입되었습니다. 또한, 새로운 크기로 MIC 계산을 지원하기 위해 AES-CCM 알고리즘에서 사용하는 카운터 모드 블록에 새로운 필드와 값이 추가되었습니다.
7.2 키 도출 관련 업데이트
암호화 도구 모음
EKS의 키 도출 계층 구조는 다음을 포함합니다.
- 파생된 비밀: 장치 간 ECDH 공유 비밀에서 파생된 기본 키로, EKS 키 계층 구조의 일부로 사용됨
- 트래픽 시크릿: 세션 키와 IV를 생성하기 위해 파생 시크릿에서 도출된 키
- 세션 키 및 초기화 벡터(IV): AES-CCM 알고리즘에서 MIC 생성은 물론 패킷의 암호화 및 인증에 사용됩니다.
EKS 지원을 위해 도입된 새로운 암호화 함수는 AES-CMAC 함수를 기반으로 합니다([Vol 3] Bluetooth 핵심 사양 H부, 2.2.5절 참조). 이 함수들은 LTK 및 ECDH 공유 비밀과 연동하여 전체 키 도출 계층 구조를 지원합니다. 새로운 함수를 통해 구현된 CMAC 기반 키 도출 계층 구조는 그림 7.1에 나와 있습니다.
그림 7.1 – EKS를 활용한 CMAC 기반 키 도출 계층 구조
새로운 암호화 함수와 태그에 대한 요약은 표 7.1과 7.2에 나와 있다. 태그가 지정된 입력은 키 간의 암호화적 분리를 보장한다.
표 7.1 – 암호화 툴박스 함수
| 함수 | 묘사 |
|---|---|
| k1 | AES-CMAC을 사용하여 기존 키와 컨텍스트별 정보를 바탕으로 새로운 128비트 키를 도출합니다. 다른 도출 과정의 구성 요소로 사용됩니다. |
| k2 | ECDH 공유 비밀키로부터 초기 “파생 비밀키”를 도출합니다. 이는 연결에 대한 키 계층 구조의 근간이 됩니다. |
| k3 | 재페어링 없이 세션 키 업데이트를 지원하기 위해 트래픽 시크릿을 갱신합니다. |
| kv1 | 트래픽 시크릿에서 128비트 세션 키를 도출합니다. AES-CCM 암호화에 사용됩니다. |
| kv2 | 트래픽 시크릿(Traffic Secret)으로부터 64비트 초기화 벡터(IV)를 도출합니다. AES-CCM에서 트래픽-인-플로우( 논스 ) 구성에 사용됩니다. |
| kv12 | 함수가 아니라, 트래픽 시크릿(Traffic Secret)에서 세션 키(Session Key)와 IV를 도출할 때 kv1과 kv2가 항상 함께 사용됨을 나타내는 표기법입니다. |
| ee1 | 기본 키(예: LTK 또는 ECDH 출력값)와 컨텍스트 태그, 또는 이전에 도출된 비밀을 바탕으로 도출된 비밀을 생성합니다. |
| ee2 | 기본 키와 컨텍스트를 기반으로 트래픽 시크릿을 도출합니다. |
| ee12 | 함수가 아니라, ee1과 ee2가 항상 함께 사용되어 파생 비밀(Derived Secret)과 트래픽 비밀(Traffic Secret)을 모두 도출함을 나타내는 표기법입니다. |
표 7.2 – 암호화 태그 값
| 식별자 | 값 | 도출 | 사용 |
|---|---|---|---|
| taghs | 0x6465_72697665_64206873 | “파생된 hs” | k2 |
| tagda | 0x646572_69766564_2041434C | “파생 ACL” | 초기 파생 비밀 |
| tagdc | 0x646572_69766564_20434953 | “파생 CIS” | 그 후 파생된 비밀 |
| tagta | 0x747261_66666963_2041434C | “트래픽 ACL” | ACL 트래픽 비밀 |
| tagtc | 0x747261_66666963_20434953 | “교통 CIS” | CIS 트래픽 비밀 |
| tagtr | 0x747261_66666963_20757064 | “교통 정보” | k3 |
| 태그 | 0x6B6579 | “키” | kv1 |
| tagiv | 0x6976 | “iv” | kv2 |
암호화 절차
ACL 암호화 시작
EKS를 사용하여 ACL 연결에서 암호화를 시작할 때, 장치들은 먼저 공개 키를 교환하고 ‘키 스케줄을 사용한 암호화 시작(Encryption Start with Key Schedule)’ 절차를 통해 ECDH 공유 비밀을 생성해야 합니다. 그런 다음 수신한 공개 키를 검증하고, ee12 함수를 사용하여 ACL에 대한 파생 비밀(Derived Secret) 및 트래픽 비밀(Traffic Secret)의 초기값을 계산해야 합니다. 마지막으로, 장치들은 kv12 함수를 사용하여 초기 세션 키(Session Key)와 초기화 벡터(IV)를 계산해야 합니다.
장치들이 페어링되지 않은 경우, 값이 0인 LTK가 사용되어 기회형 암호화가 가능해집니다. 기회형 암호화를 통해 장치는 LTK를 사용할 수 없는 상황에서도 암호화를 유지한 채 GFSK PHY에서 HDT PHY로 전환할 수 있습니다.
CIS 트래픽의 비밀
새로운 CIS(Connected Isochronous Stream)가 생성될 때마다, 장치들은 CIS 고유의 식별자(CIG_ID, CIS_ID)를 사용하여 ee12 함수를 통해 새로운 파생 비밀값과 해당 CIS에 대한 초기 트래픽 비밀값을 생성합니다. 이를 통해 스트림별 키 분리가 가능해져, 다중 스트림 환경에서 보안성이 강화됩니다. 그런 다음, 장치들은 kv12 함수를 사용하여 해당 CIS에 대한 초기 세션 키와 IV를 계산해야 합니다.
현재 각 CIS는 세션 키를 갱신할 수 없기 때문에, 수명 기간(2^39개의 패킷) 동안 하나의 트래픽 비밀을 사용합니다.
ACL 세션 키 갱신
HDT는 호스트의 개입 없이 연결 중 세션 키 갱신( 키 갱신 )을 지원합니다. 트래픽 시크릿(Traffic Secret)은 k3 함수를 사용하여 장치에서 갱신되며, 이후 kv12 함수를 통해 새로운 세션 키와 IV가 도출됩니다. 이 갱신 과정에서는 패킷 카운터와 페이로드 번호 매기기가 모두 유지되므로, 데이터 전송을 중단하지 않고 패킷 순서를 계속 유지할 수 있습니다. 이는 세션 키가 마지막 갱신 이후 2^39개의 패킷 이내에 갱신되어야 함을 의미합니다.
PHY 전환과의 통합
블루투스 LE에서 암호화된 세션 도중 PHY를 전환하려면 일반적으로 암호화를 일시 중지했다가 다시 시작해야 했습니다. HDT는 EKS를 PHY 전환 과정에 통합함으로써 이러한 절차를 없앴습니다:
- 32비트 MIC를 사용하는 GFSK PHY에서 64비트 또는 128비트 MIC를 사용하는 HDT PHY로 전환하거나, 그 반대의 경우, 링크 Layer 는 EKS를 사용하여 조정된 키 갱신 를 수행합니다.
- GFSK PHY에서 실행 중인 키 갱신 도 다른 GFSK PHY로 변경하는 과정과 조율될 수 있습니다.
- PHY 전환으로 인해 MIC 크기를 변경해야 하는 경우, 새로운 세션 키와 MIC 크기는 PHY 전환과 동시에 적용됩니다.
- 두 GFSK PHY 간 전환 시에는 키/MIC 변경이 발생하지 않으며, HDT PHY 상태를 유지하는 동안에도 반드시 변경이 이루어져야 하는 것은 아닙니다.
- 이러한 조정 방식은 보호되지 않은 데이터를 노출시키거나 호스트의 재인증 절차를 거칠 필요 없이 지속적인 암호화를 유지합니다.
이 통합 기능은 NIST의 요구 사항에 따라 MIC 크기 변경 시 항상 키 변경이 수반되도록 함으로써 PHY 전환을 간소화하고 보안을 강화합니다.
한 가지 주의할 점은, HDT PHY를 통해 LL_PHY_REQ/RSP 및 LL_PHY_UPDATE_IND가 전송되는 경우, 해당 절차의 일부 동안 ACL 사용자 데이터(제어 플레인 데이터는 제외)의 전송을 일시 중지해야 한다는 것입니다.
7.3 암호화 업데이트
CCM 알고리즘
암호화 및 인증을 위해 CCM 알고리즘은 페이로드와 추가 매개변수를 CCM 논스, 카운터 모드 블록 및 암호화 블록의 형식으로 구성해야 합니다. CCM 논스 은 각 패킷에 고유성을 부여하며, 카운터 모드 블록은 MIC를 계산하는 데 사용되고, 암호화 블록은 페이로드와 MIC를 암호화하는 데 사용되는 키스트림을 제공합니다.
EKS 및 가변 MIC 길이에 대한 지원으로 인해, GFSK PHY와 HDT PHY 기반 작동 간의 차이점과 링크 Layer 절차에 따라 정해진 사용 MIC 크기(32b, 64b 또는 128b)를 반영하기 위해 카운터 모드 블록의 형식과 필드에 대한 업데이트가 도입되었습니다.
8. Bluetooth® HDT 호스트 컨트롤러 인터페이스(HCI)
Bluetooth® HDT는 호스트 컨트롤러 인터페이스(HCI)의 기능을 확장하고, 더 높은 처리량, 향상된 성능 및 안정성, 그리고 강화된 보안을 지원하기 위해 새로운 명령어와 이벤트를 도입하고 기존 명령어 및 이벤트를 업데이트합니다.
이 섹션에서는 HDT 활성화를 위한 새로운 HCI 명령 및 이벤트, 버전 번호가 상향 조정된 명령 및 이벤트, 그리고 업데이트된 명령 및 이벤트에 대한 요약을 제공합니다. 또한 HDT 지원을 위한 주요 HCI 명령 및 이벤트와 블루투스 LE 링크 Layer 간의 일반적인 상호작용을 보여주는 메시지 시퀀스 차트도 포함되어 있습니다.
8.1 새로 추가되거나 업데이트된 HCI 명령 및 이벤트 개요
표 8.1, 8.2 및 8.3은 각각 HDT 지원을 위한 새로운 HCI 명령어, 버전 번호가 상향된 명령어 및 업데이트된 명령어와 이벤트에 대한 개요를 제공합니다. 명확성을 위해, 버전이 상향된 명령어 및 이벤트는 HDT 지원을 위한 새로운 명령어 또는 반환 매개변수를 도입하는 반면, 업데이트된 명령어 및 이벤트는 기존 명령어 또는 반환 매개변수에 HDT 활성화 및 지원을 위한 새로운 값만 추가합니다. 각 명령어 또는 이벤트에 대한 지원 요구 사항을 포함한 추가 세부 사항은 Bluetooth 코어 사양 [Vol 4], Part E, Section 3을 참조하십시오.
표 8.1 – HDT 지원을 위한 새로운 HCI 명령 및 이벤트
| 명령 / 이벤트 | 묘사 |
|---|---|
| LE 읽기 암호화 키 스케줄 디버그 모드 명령어 | EKS 기반 암호화를 사용할 때 디버그 모드를 읽는 데 사용됩니다. |
| LE Set HDT 기본 매개변수 명령어 | 호스트가 로컬 컨트롤러의 기본 HDT 매개변수를 설정하는 데 사용됩니다. |
| LE 세트 HDT 매개변수 테스트 명령어 | 호스트가 연결에 대한 HDT 테스트 매개변수를 설정하는 데 사용됩니다. |
| LE 테스트 보고서: HDT 링크 품질 이벤트 | 수신된 HDT PHY 테스트 패킷의 링크 품질 정보를 보고합니다. |
| LE 쓰기 암호화 키 스케줄 디버그 모드 명령어 | 호스트가 EKS 기반 암호화 중에 디버그 모드를 설정하는 데 사용됩니다. |
표 8.2 – HDT 지원을 위해 버전이 업그레이드된 HCI 명령 및 이벤트
| 명령 / 이벤트 | 묘사 |
|---|---|
| 암호화 변경 이벤트 [v3] | 지정된 Connection_Handle에 대한 암호화 변경이 완료되었음을 나타냅니다. |
| 키 갱신 암호화 이벤트 완료 [v2] | 암호화가 일시 중지되었다가 재개될 때마다, 지정된 Connection_Handle에서 암호화 키가 갱신되었음을 호스트에 알립니다. |
| LE CIS 정기 행사 [v3] | 컨트롤러가 CIS를 설정했음을 나타냅니다. |
| LE Create BIG 명령어 [v2] | BIG의 BIS를 하나 이상 생성합니다. |
| LE Create BIG Complete 행사 [v2] | 컨트롤러가 호스트가 요청한 BIS를 생성하려는 시도를 완료했음을 나타냅니다. |
| LE Create BIG 테스트 명령어 [v2] | 테스트 목적으로 BIG의 BIS 하나 이상을 생성하는 데 사용됩니다. |
| LE 데이터 길이 변경 이벤트 [v2] | 다음에 의해 최대 패킷 크기의 변경을 나타내는 데 사용됩니다. 링크 Layer |
| LE 암호화 활성화 명령 [v2] | 링크 수준 암호화를 활성화하는 데 사용됩니다. |
| LE 최대 데이터 길이 읽기 명령 [v2] | 호스트가 컨트롤러가 지원하는 MaxTxOctets, MaxTxTime, MaxRxOctets 및 MaxRxTime 매개변수를 읽을 수 있도록 합니다. |
| LE ‘권장 기본 데이터 길이’ 읽기 명령 [v2] | 호스트가 컨트롤러에 제안된 GFSK PHY상의 HDT PHY 또는 신규 연결에 대한 초기 MaxTxOctets 및 MaxTxTime 값을 읽을 수 있도록 합니다. |
| LE 수신기 테스트 명령어 [v4] | LE 수신기 테스트를 실행합니다. |
| LE CIG 매개변수 설정 명령 [v2] | 컨트롤러 내의 CIG와 연결된 하나 이상의 CIS에 대한 매개변수를 설정하기 위해 Central의 호스트가 사용합니다. |
| LE CIG 매개변수 설정 테스트 명령 [v2] | 테스트 용도로만 사용됩니다. 컨트롤러 내의 CIG와 연결된 하나 이상의 CIS에 대한 매개변수를 설정하기 위해 Central의 호스트가 사용합니다. |
| LE 데이터 길이 설정 명령 [v2] | 컨트롤러에 최대 패킷 크기를 제안하는 데 사용됩니다. |
| LE 테스트 종료 명령 [v2] | 현재 진행 중인 수신기 또는 송신기 테스트를 종료합니다. |
| LE 송신기 테스트 명령어 [v5] | LE 송신기 테스트를 실행합니다. |
| LE Write Suggested Default Data Length 명령어 [v2] | 호스트가 HDT PHY 또는 GFSK PHY상의 새 연결에 대해 초기 MaxTxOctets 및 MaxTxTime 값을 제안할 수 있도록 합니다. |
| 암호화 키 갱신 명령 [v2] | 호스트가 암호화 작업을 일시 중지했다가 재개함으로써 컨트롤러가 암호화 키를 갱신하도록 하는 데 사용됩니다. |
표 8.3 – HDT 지원을 위한 업데이트된 HCI 명령 및 이벤트
| 명령 / 이벤트 | 묘사 |
|---|---|
| LE BIG Sync 정기 행사 | 컨트롤러가 요청된 BIS와의 동기화 시도를 완료했음을 나타냅니다. |
| LE BIGInfo 광고 보고서 행사 | 컨트롤러가 BIGInfo 필드가 포함된 광고 PDU를 수신했음을 나타냅니다. |
| LE CS ‘절차 매개변수 설정’ 명령 | 호스트가 로컬 컨트롤러를 통해 하나 이상의 CS 절차의 스케줄링에 대한 매개변수를 설정하는 데 사용됩니다. |
| LE 향상된 읽기 전송 전력 레벨 명령 | ACL 연결에서 로컬 컨트롤러의 현재 및 최대 송신 전력 레벨을 읽어오는 데 사용됩니다. |
| LE 프레임 공간 업데이트 행사 전체 일정 | 프레임 공간 값의 변경 사항을 호스트에 알리는 데 사용됩니다. |
| LE PHY 업데이트 완료 이벤트 | 각 방향의 현재 PHY 정보를 호스트에 알리는 데 사용됩니다. |
| LE PHY 명령 읽기 | 각 방향의 현재 PHY 값을 읽는 데 사용됩니다. |
| LE 원격 송신 전력 레벨 읽기 명령 | ACL 연결에서 리모트 컨트롤러가 사용하는 송신 전력 레벨을 읽어오는 데 사용됩니다. |
| LE 기본 PHY 명령 설정 | 로컬 장치의 새 연결에 대해 우선 순위가 높은 PHY를 구성하는 데 사용됩니다. |
| LE 이벤트 마스크 설정 명령어 | 호스트에 대해 HCI가 생성하는 이벤트를 제어하는 데 사용됩니다. |
| LE PHY 설정 명령어 | Connection_Handle에 대한 PHY 변경을 요청하는 데 사용됩니다. |
| LE 송신 전력 보고 이벤트 | ACL 연결의 송신 전력 레벨을 보고하는 데 사용됩니다. |
| 이벤트 마스크 설정 2페이지 명령 | 호스트에 대해 HCI가 생성하는 이벤트를 제어하는 데 사용됩니다. |
8.2 새로운 HCI 명령 및 이벤트
LE 읽기 암호화 키 스케줄 디버그 모드 명령어

암호화 키 일정 기반 암호화를 사용할 때 디버그 모드를 반환합니다. 이 명령은 이후의 모든 연결에 적용되며, 기존 연결에는 영향을 미치지 않습니다.
LE Set HDT 기본 매개변수 명령어

중앙 호스트 또는 주변 호스트가 이후의 모든 연결에 사용될 HDT PHY에 대한 기본 매개변수를 지정할 수 있게 합니다. 이는 기존 연결에는 영향을 미치지 않습니다.
- Preferred_MIC_Length – LE HDT PHY의 모든 암호화 연결에서 사용될 권장 MIC 길이를 나타냅니다.
- Preferred_Packet_Format – LE HDT PHY에서 데이터 전송에 사용될 우선 HDT 패킷 형식을 나타냅니다.
- Preferred_ACL_Rates – LE HDT PHY에서 ACL 연결을 통해 사용할 우선 순위 속도를 나타냅니다.
LE 세트 HDT 매개변수 테스트 명령어

테스트 용도로만 사용됩니다. HDT PHY를 사용할 때, 중앙 또는 주변 호스트가 Connection_Handle로 지정된 ACL 또는 CIS 연결에 대한 테스트 매개변수를 설정하는 데 사용됩니다. 호스트는 HCI_LE_Read_Maximum_Data_Length 함수를 사용하여 로컬 컨트롤러가 지원하는 HDT 페이로드 및 패킷 기능을 읽을 수 있습니다.
- MIC_Length – 핸들로 지정된 ACL 연결의 암호화에 사용할 MIC 길이를 나타냅니다.
- Packet_Format – PDU 헤더 영역이 포함된 모든 전송 패킷에 사용할 형식을 나타냅니다.
- Blocks_Per_Payload – PF1을 사용할 때 해당 연결에서 페이로드당 사용할 블록 수를 나타냅니다.
- TX_Rate – ACL 연결을 통해 전송할 때 사용할 HDT 속도를 나타냅니다(CIS의 경우 무시됨).
LE 테스트 보고서: HDT 링크 품질 이벤트

로컬 컨트롤러가 수신한 LE HDT PHY 테스트 패킷에 대한 링크 품질 결과를 보고해야 할 때 생성됩니다.
- Subevent_Code – 이벤트의 하위 이벤트 코드
- Channel_Index – 테스트 패킷이 수신되는 RF 채널
- Report_Status – 컨트롤러에 전송할 보고서가 더 남아 있는지 여부를 지정합니다.
- Report_Count – 보고되는 패킷별 RSSI[i] 및 SNR[i] 매개변수 값의 개수를 지정합니다.
- RSSI[i] – 수신 순서대로 정렬된 단일 테스트 패킷에 해당하는 RSSI 값
- SNR[i] – 수신 순서대로 개별 테스트 패킷에 해당하는 SNR 값
LE 쓰기 암호화 키 스케줄 디버그 모드 명령어

디버그 장비가 암호화된 연결을 모니터링할 수 있도록, 암호화 키 스케줄(EKS) 기반 암호화에 미리 정의된 ECDH 키 쌍을 사용하도록 컨트롤러를 구성하는 데 사용됩니다. 이 명령은 이후의 모든 연결에 적용되며, 기존 연결에는 영향을 미치지 않습니다.
8.3 버전 번호가 변경된 HCI 명령 및 이벤트
암호화 변경 이벤트 [v3]
![HCI_Encryption_Change [v3] 이벤트 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_Encryption_Change_v3_white.png)
암호화 모드 변경이 완료되었음을 나타내는 데 사용됩니다. [v3]에서는 EKS 기반 암호화가 사용되는 경우 연결의 MIC 길이와, ‘Key Schedule LL을 사용한 암호화 시작(Encryption Start with Key Schedule LL)’ 절차에서 디버그 키 쌍이 사용되는지 여부를 나타내는 새로운 이벤트 매개변수가 도입되었습니다.
키 갱신 암호화 이벤트 완료 [v2]
![HCI_Encryption_Key_Refresh_Complete [v2] 이벤트 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_Encryption_Key_Refresh_Complete_v2_white.png)
주어진 Connection_Handle에서 암호화 키가 갱신되었음을 호스트에 알리는 데 사용됩니다. [v2]에서는 Encryption Change [v3] 이벤트와 동일한 목적으로 MIC_Length, Key_Schedule_Enabled 및 Key_Schedule_Debug_Flag 이벤트 매개변수가 도입되었습니다. 이 이벤트가 LE PHY 업데이트 절차에 의해 생성된 경우, HCI_LE_PHY_Update_Complete 이벤트 직후에 전송됩니다.
LE CIS 정기 행사 [v3]
![HCI_LE_CIS_Established [v3] 이벤트 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_CIS_Established_v3_white.png)
CIS가 성공적으로 설정되었거나 실패했음을(예: 거부되었거나 설정되기 전에 연결이 끊어진 경우) 호스트에 알립니다. [v3]에서는 아래의 이벤트 매개변수를 도입하고, HDT 사용을 지정하기 위해 PHY 이벤트 매개변수에 새로운 값을 추가하며, Max_Payload 이벤트 매개변수의 상한을 8175 옥텟으로 늘렸습니다.
- Rates_C_To_P – 중앙에서 주변 장치 방향으로 특정 LE 코디드 또는 HDT 데이터 전송 속도가 사용됨을 나타냅니다.
- Rates_P_To_C – 주변기기에서 중앙으로 전송되는 방향에서 특정 LE 코디드 또는 HDT 데이터 전송 속도가 사용됨을 나타냅니다.
- Config_ID – CIG 구성 식별자
- TL_Group_ID – Config_ID와 연관된 전송 지연 시간 그룹 식별자
- Encryption_Enabled – CIS에서 암호화가 활성화되었는지 여부와 유형(예: EKS, Opportunistic)을 나타냅니다.
- MIC_Length – 암호화에 사용할 MIC의 길이를 나타냅니다.
LE Create BIG 명령어 [v2]
![HCI_LE_Create_BIG [v2] 명령어 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Create_BIG_v2_white.png)
하나 이상의 BIS로 BIG을 생성하는 데 사용됩니다. BIG 내의 모든 BIS는 모든 매개변수에 대해 동일한 값을 가집니다. [v2]에서는 아래의 명령 매개변수들과 더불어, HDT PHY를 사용하여 패킷을 전송함을 나타내는 PHY용 새로운 비트 번호 매개변수 가 도입되었습니다.
- Coded_Rates – LE 코디드 PHY에서 사용할 우선 순위 전송 속도를 지정합니다.
- HDT_Rates – HDT PHY를 통해 사용할 우선 순위 전송 속도를 나타냅니다.
- HDT_MIC_Length – HDT를 통한 암호화에 사용될 MIC 길이를 나타냅니다.
- HDT_Packet_Format – BIS가 HDT PHY를 사용할 때 데이터 전송에 선호되는 HDT 패킷 형식을 나타냅니다.
LE Create BIG Complete 행사 [v2]
![HCI_LE_Create_BIG_Complete [v2] 이벤트 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Create_BIG_Complete_v2_white.png)
HCI_LE_Create_BIG 또는 HCI_LE_Create_BIG_Test 명령이 완료되었음을 나타내며, 성공한 경우 링크 Layer 가 등시성 브로드캐스팅 상태 상태로 진입했음을 나타냅니다. [v2]에서는 아래의 이벤트 매개변수를 도입하고, HDT 사용을 지정하기 위해 PHY 이벤트 매개변수 에 새로운 값을 추가하며, Max_Payload 크기의 상한을 8175 옥텟으로 늘렸습니다.
- 요율 – ‘ LE 코디드 ’ 또는 ‘HDT PHY’에 적용되는 코딩 또는 요율을 나타냅니다.
- Encryption_Enabled – BIG에서 암호화가 활성화되었는지 여부를 나타냅니다.
- MIC_Length – 암호화에 사용할 MIC의 길이를 나타냅니다.
LE Create BIG 테스트 명령어 [v2]
![HCI_LE_Create_BIG_Test [v2] 명령어 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Create_BIG_Test_v2_white.png)
테스트 용도로만 사용됩니다. 하나 이상의 BIS로 BIG을 생성하는 데 사용됩니다. BIG 내의 모든 BIS는 모든 매개변수에 대해 동일한 값을 가집니다. [v2]에서는 아래의 명령 매개변수가 도입되었으며, HDT PHY를 사용한 패킷 전송을 나타내기 위해 PHY 매개변수 에 새로운 비트 번호가 추가되었고, Max_Payload 크기의 상한이 8175 옥텟으로 상향 조정되었습니다.
- Coded_Rates – LE 코디드 PHY를 통해 사용할 우선 순위 전송 속도를 식별합니다.
- HDT_Rates – HDT PHY를 통해 사용할 우선 순위 속도를 나타냅니다.
- HDT_MIC_Length – HDT를 통한 암호화에 사용될 MIC 길이를 나타냅니다.
- HDT_Packet_Format – BIS가 HDT PHY에 연결되어 있을 때 데이터 전송에 선호되는 패킷 형식을 나타냅니다.
- HDT_Blocks_Per_Payload – PF1을 사용하는 연결에서 페이로드당 사용할 블록 수를 나타냅니다.
LE 데이터 길이 변경 이벤트 [v2]
![HCI_LE_Data_Length_Change [v2] 이벤트 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Data_Length_Change_v2_white.png)
양방향 중 어느 한 쪽에서든 최대 링크 Layer 데이터 PDU 페이로드 길이 또는 LL 데이터 PDU를 포함하는 패킷의 최대 전송 시간이 변경된 경우 호스트에 이를 알립니다. [v2]에서는 이벤트 매개변수가 적용되는 PHY를 나타내기 위해 PHYS 이벤트 매개변수 를 도입했습니다. 또한 Max_TX_Octets 및 Max_RX_Octets 크기의 상한을 8175 옥텟으로 늘렸습니다.
LE 암호화 활성화 명령 [v2]
![HCI_LE_Enable_Encryption [v2] 명령어 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Enable_Encryption_v2_white.png)
원격 장치와 연관된 지정된 암호화 키를 인증하고, 인증 후 연결을 암호화하는 데 사용됩니다. [v2]에서는 HDT PHY에서 ACL 연결 시 암호화에 선호하는 MIC 길이와 EKS 또는 기회적 암호화 유형을 지정하기 위해 HDT_MIC_Length 및 Encryption_Type 명령 매개변수가 도입되었습니다.
LE 최대 데이터 길이 읽기 명령 [v2]
![HCI_LE_Read_Maximum_Data_Length [v2] 명령어 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Read_Maximum_Data_Length_v2_white.png)
호스트가 LL 데이터 PDU의 송수신에 대해 컨트롤러가 지원하는 최대 페이로드 크기와 패킷 지속 시간을 읽을 수 있도록 합니다. [v2]에서는 매개변수를 읽는 대상 PHY를 지정하기 위한 PHY 명령어 ` 매개변수 `를 도입했으며, HDT 기능 지원을 위한 아래의 반환 매개변수도 추가했습니다. 또한 `Supported_Max_TX/RX_Octets` 값 범위의 상한을 8175 옥텟으로 늘렸습니다.
- Supported_Max_TX_Payload_Window_Size – 컨트롤러에서 지원하는 최대 전송 페이로드 윈도우 크기
- Supported_Max_RX_Payload_Window_Size – 컨트롤러가 지원하는 최대 수신 페이로드 윈도우 크기
- Supported_Max_RX_Octets_Per_Packet – 단일 패킷에서 수신할 수 있는 최대 총 페이로드 옥텟 수
LE ‘권장 기본 데이터 길이’ 읽기 명령 [v2]
![HCI_LE_Read_Suggested_Default_Data_Length [v2] 명령어 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Read_Suggested_Default_Data_Length_v2_white.png)
호스트가 컨트롤러에 설정된 LL 데이터 PDU 전송 매개변수에 대한 권장 기본값(Suggested_Max_TX_Octets, Suggested_Max_TX_Time)을 읽을 수 있게 합니다. [v2]에서는 전송 매개변수를 읽을 PHY(GFSK 또는 HDT)를 지정하기 위한 명령어 ` 매개변수 PHYS`를 도입했으며, 반환되는 `Suggested_Max_TX_Octets` 값 범위의 상한을 8175 옥텟으로 확대했습니다.
LE 수신기 테스트 명령어 [v4]
![HCI_LE_Receiver_Test [v4] 명령어 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Receiver_Test_v4_white.png)
IUT가 고정된 간격으로 테스트 기준 패킷을 수신하는 테스트를 시작하는 데 사용됩니다. [v4]에서는 HDT PHY에 대해 SNR 측정을 수행할지 여부를 지정하기 위한 HDT_SNR_Test 명령어 매개변수 를 도입했습니다. 또한 HDT PHY 사용을 나타내는 PHY의 새로운 값도 추가되었습니다.
LE CIG 매개변수 설정 명령 [v2]
![HCI_LE_Set_CIG_Parameters [v2] 명령어 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Set_CIG_Parameters_v2_white_b.png)
센트럴 호스트가 CIG를 생성하고, 컨트롤러에서 CIG와 연관된 하나 이상의 CIS에 대한 매개변수를 설정하는 데 사용됩니다. [v2]에서는 HDT PHY 지원을 위해 아래의 명령 매개변수를 도입했으며, HDT PHY 사용을 나타내기 위해 PHY_C_To_P[i] 및 PHY_P_To_C[i]에 대한 새로운 비트 번호를 추가했습니다.
- Coded_Rates_C_To_P[i] – 중앙에서 주변 장치로 전송할 때 LE 코디드 PHY보다 우선적으로 사용해야 할 전송 속도를 나타냅니다.
- Coded_Rates_P_To_C[i] – 주변 장치에서 중앙 장치로 전송할 때, LE 코디드 PHY보다 우선적으로 사용해야 할 전송 속도를 나타냅니다.
- HDT_Rates_C_To_P[i] – 중앙에서 주변 장치로 전송할 때 HDT PHY를 통해 사용해야 할 우선 순위 전송 속도를 나타냅니다.
- HDT_Rates_P_To_C[i] – 주변 장치에서 중앙 장치로 전송할 때 HDT PHY를 통해 사용해야 할 우선 순위 전송 속도를 나타냅니다.
- HDT_MIC_Length[i] – 암호화에 사용되는 MIC의 길이를 나타냅니다.
- HDT_Packet_Format[i] – 컨트롤러가 사용해야 할 권장 HDT 패킷 형식을 나타냅니다.
LE CIG 매개변수 설정 테스트 명령 [v2]
![HCI_LE_Set_CIG_Parameters_Test [v2] 명령어 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Set_CIG_Parameters_Test_v2_white.png)
테스트 용도로만 사용됩니다. Central의 호스트가 CIG를 생성하고, 컨트롤러 내에서 CIG와 연관된 하나 이상의 CIS의 매개변수를 설정하는 데 사용됩니다. [v2]에서는 HDT PHY 지원을 위해 아래의 명령 매개변수를 도입하고, Max Payload 명령 매개변수의 상한을 8175 옥텟으로 상향 조정하며, HDT PHY 사용을 나타내기 위해 PHY_C_To_P[i] 및 PHY_P_To_C[i]에 대한 새로운 비트 번호를 정의합니다.
- Coded_Rates_C_To_P[i] – 중앙에서 주변 장치로 전송 시, LE 코디드 PHY를 통해 사용할 우선 순위 전송 속도를 지정합니다.
- Coded_Rates_P_To_C[i] – 주변 장치에서 중앙 장치로 전송할 때 LE 코디드 PHY를 통해 사용할 우선 순위 전송 속도를 지정합니다.
- HDT_Rates_C_To_P[i] – 중앙에서 주변 장치로 전송할 때 HDT PHY를 통해 사용해야 할 우선 순위 전송 속도를 나타냅니다.
- HDT_Rates_P_To_C[i] – 주변 장치에서 중앙 장치로 전송할 때 HDT PHY를 통해 사용해야 할 우선 순위 전송 속도를 나타냅니다.
- HDT_MIC_Length[i] – HDT를 통한 암호화에 사용될 MIC 길이를 나타냅니다.
- HDT_Packet_Format[i] – 컨트롤러가 사용해야 할 권장 HDT 패킷 형식을 나타냅니다.
- HDT_Payload_Window_Size_C_To_P[i] – 중앙에서 주변 장치로 전송할 때 사용되는 페이로드 윈도우의 크기를 나타냅니다.
- HDT_Payload_Window_Size_P_To_C[i] – 주변 기기가 중앙 기기로 전송할 때 사용하는 페이로드 윈도우의 크기를 나타냅니다.
LE 데이터 길이 설정 명령 [v2]
![HCI_LE_Set_Data_Length [v2] 명령어 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Set_Data_Length_v2_white.png)
호스트가 특정 연결에서 LL 데이터 PDU에 사용될 최대 전송 페이로드 크기와 시간을 제안할 수 있도록 합니다. [v2]에서는 해당 매개변수가 적용되는 PHY(GFSK 또는 HDT)를 지정하기 위한 명령어 ` 매개변수 PHYS`를 도입하고, `TX_Octets` 값의 상한을 8175 옥텟으로 확대했습니다.
LE 테스트 종료 명령 [v2]
![HCI_LE_Test_End [v2] 명령어 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Test_End_v2_white.png)
진행 중인 테스트를 중지하는 데 사용됩니다. [v2]에서는 HDT PHY에서 수신된 블록 수를 나타내는 return 매개변수 Num_Blocks가 도입되었습니다.
LE 송신기 테스트 명령어 [v5]
![HCI_LE_Transmitter_Test [v5] 명령어 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Transmitter_Test_v5_white.png)
IUT가 고정된 간격으로 테스트 기준 패킷을 생성하는 테스트를 시작하는 데 사용됩니다. [v5]에서는 HDT 전송 테스트를 위해 아래의 명령어 매개변수를 도입하고, HDT PHY 사용을 나타내는 새로운 PHY 값을 추가했습니다.
- HDT_Rate_Indicator – HDT PHY 전송 속도를 지정합니다.
- HDT_Packet_Format_Indicator – HDT 패킷 형식을 지정합니다.
- HDT_Payload_Length – 패킷 형식 0에서 페이로드의 길이를 지정합니다(PF1에서는 무시됨).
- HDT_PHY_Interval – PHY 간격당 페이로드 심볼 수를 지정합니다.
- HDT_Num_Blocks[i] – 페이로드 내 블록 수(Nb)를 지정합니다(PF0의 경우 Nb=0).
- HDT_Block_Size[i] – 마지막 블록을 제외한 페이로드 내 각 블록의 길이를 지정합니다.
- HDT_Final_Block_Size[i] – 전송될 마지막 블록의 길이를 지정합니다.
LE Write Suggested Default Data Length 명령어 [v2]
![HCI_LE_Write_Suggested_Default_Data_Length [v2] 명령어 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_LE_Write_Suggested_Default_Data_Length_v2_white.png)
호스트가 컨트롤러의 LL 데이터 PDU 전송 매개변수에 대한 권장 기본값(Suggested_Max_TX_Octets, Suggested_Max_TX_Time)을 지정하거나 기록할 수 있게 합니다. [v2]에서는 전송 매개변수가 지정되는 PHY(GFSK 또는 HDT)를 나타내기 위해 ` 매개변수 PHYS` 명령을 도입하고, `Suggested_Max_TX_Octets` 값 범위의 상한을 8175 옥텟으로 늘렸습니다.
암호화 키 갱신 명령 [v2]
![HCI_Refresh_Encryption_Key [v2] 명령어 매개변수](https://www.bluetooth.com/wp-content/uploads/2026/10/HCI_Refresh_Encryption_Key_v2_white.png)
호스트가 이 기능을 사용하여, Connection_Handle로 식별되는 ACL 연결에 대해 암호화 새로고침 절차를 통해 컨트롤러가 암호화 키를 새로고침하도록 합니다. 이 연결에 HDT PHY를 사용할 경우 MIC 길이가 지정됩니다.
8.4 업데이트된 HCI 명령어 및 이벤트
LE BIG Sync 정기 행사
Max_Payload 이벤트의 매개변수 값 범위 상한이 8175 옥텟으로 확대되었습니다.
LE BIGInfo 광고 보고서 행사
Max_Payload 이벤트 매개변수 의 값 범위 상한이 8175 옥텟으로 확대되었습니다. 또한, HDT PHY에서 BIG이 전송되었음을 나타내기 위해 새로운 PHY 이벤트 매개변수 의 값이 정의되었습니다.
LE CS ‘절차 매개변수 설정’ 명령
HDT PHY 사용 여부를 나타내기 위해 새로운 PHY 명령어 매개변수 의 값이 정의되었습니다.
LE 향상된 읽기 전송 전력 레벨 명령
HDT PHY 연결을 지정하기 위해 PHY 명령 및 반환 매개변수에 대한 새로운 값이 정의되었습니다.
LE 프레임 공간 업데이트 행사 전체 일정
HDT PHY 사용을 나타내기 위해 PHYS 이벤트 매개변수 에 대한 새로운 비트 번호가 정의되었습니다.
LE PHY 업데이트 완료 이벤트
HDT PHY를 사용하여 송수신함을 나타내기 위해 TX_PHY 및 RX_PHY 이벤트 매개변수에 대한 새로운 값이 정의되었습니다.
LE PHY 명령 읽기
HDT PHY 사용을 나타내기 위해 정의된 TX_PHY 및 RX_PHY 반환 매개변수의 새로운 값.
LE 원격 송신 전력 레벨 읽기 명령
HDT PHY 연결을 지정하기 위해 PHY 명령어 매개변수 에 대한 새로운 값이 정의되었습니다.
LE 기본 PHY 명령 설정
HDT PHY 사용을 나타내기 위해 TX_PHY 및 RX_PHY 명령 매개변수에 대한 새로운 값이 정의되었습니다.
LE 이벤트 마스크 설정 명령어
마스크에 LE CIS 설정 [v3], LE Create BIG 완료 [v2], LE 데이터 길이 변경 [v2], LE 테스트 보고서 HDT 링크 품질 등 4개의 이벤트가 추가되었습니다.
LE PHY 설정 명령어
HDT PHY 사용 및 기본 설정을 나타내기 위해 TX_PHY, RX_PHY 및 PHY_Options 명령 매개변수에 대한 새로운 비트 번호가 정의되었습니다.
LE 송신 전력 보고 이벤트
HDT PHY 사용 여부를 나타내기 위해 새로운 PHY 이벤트 매개변수 값이 정의되었습니다.
이벤트 마스크 설정 2페이지 명령
‘암호화 변경 [v3]’, ‘암호화 키 갱신 완료 [v2]’, ‘암호화 키 디버그 보고서’에 대한 세 가지 이벤트가 마스크에 추가되었습니다.
8.5 메시지 순서도
다음 차트들은 블루투스 LE 링크 Layer 를 활용한 HDT 지원을 위해 관련 HCI 명령 및 이벤트 간의 일반적인 상호작용을 보여줍니다.
GFSK PHY에서 HDT PHY로 전환
암호화되지 않은 ACL 연결

그림 8.1 – 암호화되지 않은 ACL 연결에서 HDT PHY로 전환
암호화된 ACL 연결

그림 8.2 – 암호화된 ACL 연결에서 HDT PHY로 전환
HDT PHY에서 GFSK PHY로 전환
암호화되지 않은 ACL 연결

그림 8.3 – 암호화되지 않은 ACL 연결에서 HDT PHY에서 GFSK PHY로 전환
암호화된 ACL 연결

그림 8.4 – 암호화된 ACL 연결에서 HDT PHY에서 GFSK PHY로 전환
데이터 길이 업데이트

그림 8.5 – 데이터 길이 업데이트
HCI_LE_Set_Data_Length 명령어의 [v2] 이상 버전에서는 HCI_LE_Data_Length_Change 이벤트, LL_LENGTH_REQ PDU 및 LL_LENGTH_RSP PDU를 사용하여 HDT PHY의 매개변수를 변경합니다.
HDT를 통한 CIG 설정

그림 8.6 – HDT PHY를 통한 CIG 및 CIS 구성
키 스케줄을 사용하여 암호화 시작

그림 8.7 – 키 스케줄을 사용하여 암호화 시작
키 스케줄을 사용하여 기회적 암호화 시작

그림 8.8 – 기회적 암호화 시작
키 스케줄을 사용하여 암호화 재시작

그림 8.9 – 키 스케줄을 사용한 암호화 재시작
키 스케줄을 사용한 암호화 갱신

그림 8.10 – 키 스케줄을 이용한 암호화 갱신
9. 기타
Bluetooth® HDT는 Bluetooth LE 스택의 호스트 계층 및 ISOAL 계층에 대한 업데이트를 도입합니다. 호스트 계층 업데이트는 주로 MIC 길이 요구 사항의 검증 및 준수를 지원하며, ISOAL 계층 업데이트는 새로운 HDT PHY를 통해 가능해진 대용량 데이터 페이로드 전송을 지원합니다.
9.1. 논리 링크 제어 및 적응 프로토콜(L2CAP)
HDT는 신용 기반 흐름 제어(CBFC)를 사용하는 L2CAP 데이터 채널 생성 시 MIC 길이를 추가적인 보안 기준으로 삼습니다.
CBFC는 크레딧 기반 연결 제어( 수신기)를 통해 부여된 크레딧을 활용하여 기기 간 데이터 전송을 규제하고, 연결 지향적 L2CAP 채널을 관리하는 메커니즘입니다. CBFC에는 LE 모드와 Enhanced 모드, 두 가지가 있습니다. 대략적으로 말하면, LE CBFC는 연결당 하나의 L2CAP 채널을 설정하는 반면, Enhanced CBFC는 여러 채널을 동시에 설정할 수 있습니다. 두 모드 모두 크레딧 기반 연결 요청과 이에 상응하는 응답을 교환하는 L2CAP 절차를 통해 활성화됩니다.
HDT는 신용 기반 L2CAP 채널을 설정하는 과정에서 수행되는 보안 검증을 확장하여, 기기가 기존의 인증, 권한 부여 및 암호화 키 크기 확인 외에도 MIC 길이 요구 사항을 확인하고 적용할 수 있도록 합니다. 또한, 협상된 MIC 길이가 불충분하여 연결 요청이 거부되었음을 나타내기 위해 응답 패킷의 Result 데이터 필드에 해당 값을 도입합니다.
9.2. 일반 액세스 프로필(GAP)
HDT는 LE 보안 모드 1의 사양과 서비스 인증 절차를 소폭 개정하여, 블루투스 LE 기기가 GAP(Generic Access Profile)를 통해 서비스에 접근하기 위한 보안 요구 사항을 평가하고 충족하는 방식을 개선합니다.
GAP에서 보안 모드는 기기가 서비스 및 속성에 안전하게 액세스하기 위해 블루투스 LE 연결이 충족해야 하는 요구 사항을 정의합니다. LE 보안 모드 1은 인증 및 암호화의 다양한 조합을 사용하여 네 가지 보안 수준을 통해 LE ACL 연결의 보안을 관리합니다.
HDT는 HDT PHY에서 작동하는 암호화된 연결에 대해 128비트에 상응하는 강도를 가진 장기 키(LTK)의 사용을 의무화함으로써 LE 보안 모드 1을 확장합니다. 관련 LTK가 요구되는 128비트 강도를 충족하지 못하는 경우, 기기는 연결을 HDT PHY로 전환하거나 HDT PHY를 사용하는 CIS를 설정할 수 없습니다.
또한 HDT는 서비스 요청에 대응하고 이를 개시하는 데 사용되는 GAP 절차를 업데이트합니다. 서비스에 필요한 보안 수준이 현재 연결 상태로는 충족되지 않는 경우, GAP는 이제 서비스 요청을 평가하여, 협상된 MIC 길이가 서비스 요구 사항을 충족하지 못할 때 ‘MIC Length Too Short’ 오류 코드를 반환하며 해당 요청을 거부할 수 있습니다.
장치가 서비스 요청을 시작했을 때 MIC 길이가 충분하지 않은 경우, GAP은 요청을 재시도하기 전에 필요한 MIC 길이를 확보하기 위해 PHY 업데이트 및 암호화 갱신 절차를 실행할 수 있습니다. 필요한 MIC 길이를 확보할 수 없는 경우, 해당 요청은 거부됩니다.
자세한 내용은 핵심 사양서 제3권 C부를 참조하십시오.
9.3. 속성 프로토콜(ATT)
HDT는 속성 프로토콜(ATT)이 관리하는 속성에 대한 접근 시 MIC 길이를 추가적인 보안 기준으로 삼습니다.
ATT는 블루투스 LE 기기가 클라이언트가 서버가 노출한 속성을 검색, 읽기, 쓰기 및 기타 방식으로 액세스할 수 있도록 하는 데 사용되는 프로토콜입니다.
HDT는 협상된 MIC 길이가 요청된 속성의 보안 요구 사항을 충족하지 못해 속성 액세스 요청이 거부되었음을 나타내기 위해 새로운 오류 코드인 ‘MIC 길이 부족( MIC Length Too Short)’을 도입합니다. 이 오류 코드는 ATT 속성 권한에 통합되었으며, 속성 탐색, 읽기 및 쓰기 작업을 포함하여 보호된 속성에 액세스하는 모든 ATT 절차에서 지원됩니다.
새로운 오류 코드를 지원하도록 업데이트된 ATT PDU는 핵심 사양서 제3권 F편에 명시되어 있으며, 참고를 위해 아래에 나열되어 있습니다.
- ATT_ERROR_RSP
- ATT_정보_조회_요청
- ATT_FIND_BY_TYPE_VALUE_REQ
- ATT_READ_BY_TYPE_REQ
- ATT_READ_REQ
- ATT_READ_BLOB_REQ
- ATT_READ_MULTIPLE_REQ
- ATT_READ_BY_GROUP_TYPE_REQ
- ATT_READ_MULTIPLE_VARIABLE_REQ
- ATT_WRITE_REQ
- ATT_PREPARE_WRITE_REQ
9.4. 일반 속성 프로파일(GATT)
HDT는 GATT 프로필에 정의된 절차에 약간의 업데이트를 적용하여, ATT 수준의 MIC 길이 보안 검사 및 새로운 ‘MIC 길이 너무 짧음(MIC Length Too Short )’ 오류 조건을 인식하고 전파하는 데 도움이 되는 특성 값과 설명자를 읽고 쓸 수 있도록 했습니다.
개정된 GATT 절차는 핵심 사양서 제3권 G부에 명시되어 있으며, 참고를 위해 아래에 나열되어 있습니다.
- 특성값 읽기
- 긴 특성값 읽기
- 여러 특성값 읽기
- 여러 개의 가변 길이 특성값 읽기
- 특성값 작성
- 긴 특성값 작성하기
- 특성값 신뢰할 수 있는 쓰기
- 특성 설명자 읽기
- 긴 특성 설명자 읽기
- 특성 설명자 작성
- 자세한 특성 설명 작성
9.5. 등시적 적응 계층(ISOAL)
HDT는 HDT PHY를 통해 가능해진 대용량 데이터 페이로드 전송을 지원하기 위해 필요한 등시적 적응 계층(ISOAL)의 업데이트를 도입합니다.
ISOAL은 아이소크로너스 전송( LE 오디오의 CIS 및 BIS 스트림에서 사용되는 것과 같은)을 통해 교환되는 서비스 데이터 단위(SDU)를 분할하고 재조립하는 역할을 담당합니다.
더 큰 SDU 세그먼트를 수용하기 위해, HDT는 Length 필드를 8비트에서 12비트로 확장하여 ISOAL 프레임형 PDU 세그멘테이션 헤더의 형식을 업데이트합니다. Length 필드는 프레임형 PDU 내에 전달되는 SDU 세그먼트의 크기를 옥텟 단위로 나타냅니다. 기존 헤더 형식과의 호환성을 유지하기 위해, 12비트 값은 세그멘테이션 헤더 내에서 Length High 및 Length Low 필드로 분리됩니다.
이러한 변경 사항으로 인해 ISOAL이 표현할 수 있는 최대 SDU 세그먼트 크기가 증가하여, 기존의 ISOAL 세그먼트화 및 재조립 아키텍처와의 호환성을 유지하면서 더 큰 페이로드를 효율적으로 전송할 수 있게 되었습니다. 자세한 내용은 블루투스 핵심 사양 제6권 G부를 참조하십시오.
이러한 변경 사항은 ISOAL 내에서 구현되지만, 그 영향은 블루투스 스택의 상위 계층까지 미칠 수 있습니다. ISOAL은 더 큰 SDU 세그먼트를 지원함으로써, 컨트롤러가 더 큰 아이소크로너스 페이로드를 전송할 수 있게 하며, 이는 궁극적으로 더 큰 ISO 데이터 패킷을 통해 호스트로 전달될 수 있습니다. 세그먼트 분할 및 재조립은 대부분의 호스트 및 애플리케이션 소프트웨어에 대해 여전히 투명하게 이루어지지만, HDT가 제공하는 증가된 페이로드 용량은 기본 ISOAL 세그먼트 분할 및 재조립 아키텍처를 변경할 필요 없이 더 까다로운 아이소크로너스 데이터 스트림을 지원하는 데 도움이 됩니다.
10. 결론
블루투스® 고속 데이터 처리량 는 블루투스 LE의 기능과 성능을 획기적으로 향상시켜, 차세대 무선 경험의 토대를 마련하고 블루투스 생태계 전반에 걸쳐 새로운 혁신의 기회를 창출합니다.
새로운 블루투스 HDT PHY는 더 높은 스펙트럼 효율, 적응형 데이터 전송 속도, 그리고 변화하는 채널 환경에서도 안정적인 통신을 유지하도록 설계된 메커니즘을 통해 블루투스 LE의 성능 한계를 확장하며, 지원 가능한 최대 비트레이트를 7.5 Mbps로 높입니다.
새로운 블루투스 HDT 패킷 구조는 효율성, 견고성 및 오버헤드 간의 균형을 맞추도록 설계된 유연한 형식을 통해 대용량 PHY를 보완합니다. 제어 헤더를 페이로드와 분리함으로써, 페이로드 전송을 위한 동적 데이터 속도를 지원하면서도 중요한 패킷 정보를 보다 견고하게 처리할 수 있습니다. 더 큰 용량의 페이로드, 페이로드 집계, 블록 기반 전송 및 선택적 재전송 기능을 통해 HDT는 더 많은 양의 데이터를 효율적으로 전송할 수 있으며, 전송 오류의 영향을 최소화합니다.
HDT 링크 Layer 의 개선 사항은 HDT 작동을 구성 및 관리하고, GFSK와 HDT PHY 간의 전환을 조정하며, 변화하는 링크 상태에 대응하고, 아이소크로너스 통신을 지원하며, Bluetooth HDT와 함께 도입된 향상된 보안 기능을 관리하는 데 필요한 지능을 제공합니다.
HDT는 더 긴 MIC 크기와 암호화 키 스케줄(EKS) 기능 지원을 통해 블루투스 LE 보안을 강화함으로써, 대용량 페이로드에 대한 보다 강력한 보호 기능을 제공하고, 기기가 GFSK 및 HDT 작동 모드 간을 전환할 때 키를 조정하여 업데이트할 수 있도록 합니다. 또한 EKS는 기회적 암호화, 완벽한 전방 비밀성(Perfect Forward Secrecy), 보다 유연한 암호화 키 관리 등의 기능을 도입합니다.
HCI 및 호스트 계층에 대한 업데이트를 통해 HDT 컨트롤러 기능이 더 광범위한 블루투스 LE 스택에 통합됨에 따라, 호스트는 HDT 기본 설정 및 매개변수를 설정하고, HDT 작동을 모니터링하며, 새로운 PHY와 함께 도입된 더 큰 페이로드와 강화된 보안 요구 사항을 수용하는 데 필요한 인터페이스를 확보하게 됩니다.
기존의 블루투스 애플리케이션 및 사용 사례에 대해, 블루투스 HDT는 개발자들이 차세대 제품에서 더 빠른 데이터 전송, 더 큰 용량, 향상된 효율성, 그리고 더욱 안정적인 무선 성능을 구현할 수 있도록 지원하는 기능을 제공합니다. 동시에 HDT는 블루투스 LE의 가능성을 확장하여, 고해상도 및 무손실 오디오와 같은 정교한 사용자 경험은 물론, 점점 더 까다로워지는 데이터 요구 사항을 가진 신흥 애플리케이션에 필요한 추가적인 성능과 용량을 제공합니다.
전반적으로 블루투스 기술은 광범위한 보급에 기여해 온 상호운용성, 효율성 및 유연성을 유지하면서 새로운 응용 분야를 지원하기 위해 지속적으로 발전해 왔습니다. 블루투스® 고속 데이터 처리량 는 이러한 발전 과정에서 중요한 다음 단계로, 블루투스 LE가 이를 기반으로 하는 응용 분야 및 사용자 경험과 함께 지속적으로 발전해 나가기 위해 필요한 추가적인 성능과 용량을 제공합니다.
전체 구현 요구 사항 및 기술적 세부 사항에 대해서는 ‘블루투스 코어 사양 7.0’을 참조하십시오.
1. C. E. Shannon, “통신에 관한 수학적 이론,” 『Bell System Technical Journal』, 제27권, 379–423쪽 및 623–656쪽, 1948년 7월 및 10월.