Bluetooth핵심 사양 버전 6.0
기능 개요
3.1.1 디바이스 포지셔닝 및 Bluetooth LE
3.2.3 다음에 대한 자세한 정보 Channel Sounding
5.1.5 Bluetooth LE 오디오 및 수락기 가용성
버전: | 1.0 |
수정 날짜: | 2024년 8월 6일 |
작성자: |
마틴 울리, Bluetooth SIG |
1. 소개
Bluetooth® 핵심 사양 버전 6.0에는 몇 가지 향상된 기능이 포함되어 있습니다. 이 백서에서는 각 개선 사항에 대한 개요를 제공합니다. 참고: 이 문서는 마케팅 문서이며 어떤 방식으로든 Bluetooth® 핵심 사양을 대체하거나 무효화하기 위한 것이 아닙니다.
각 기능 개선 사항은 전용 섹션에 설명되어 있으며, 관련 배경 정보에 대한 설명으로 시작됩니다. 이는 Bluetooth 저에너지(LE)의 특정 측면을 처음 접하는 독자들이 보다 쉽게 이해할 수 있도록 하기 위한 것입니다. 하지만 배경 섹션이 완전히 포괄적이지는 않으므로 생소한 용어나 개념을 접하는 독자는 Bluetooth LE 입문서를 다운로드하여 읽어보시기 바랍니다.
2. 한눈에 보기
2.1 Bluetooth® Channel Sounding
Bluetooth® Channel Sounding 는 두 개의 Bluetooth 장치 간에 안전한 정밀 거리 측정을 가능하게 합니다. 거리 측정이란 특정 기술을 사용하여 한 물체에서 다른 물체까지의 거리를 측정하는 것을 의미합니다.
무선 범위 측정은 디지털 키 솔루션과 '내 찾기' 네트워크 등 다양한 제품에 적용되고 있습니다. 새로운 Bluetooth Channel Sounding 기능은 이러한 제품의 까다로운 정확도 및 보안 요구 사항을 충족할 수 있는 표준 기반 기술 접근 방식을 제공하도록 설계되었습니다.
2.2 의사 결정 기반 광고 필터링
Bluetooth LE 확장 광고 기능은 기본 및 보조 라디오 채널 모두에서 일련의 관련 패킷을 전송하는 것을 포함합니다.
의사 결정 기반 광고 필터링을 사용하면 스캔 디바이스가 기본 광고 채널에서 수신한 패킷의 콘텐츠를 사용하여 보조 채널에서 관련 패킷을 스캔할지 여부를 결정할 수 있습니다. 이렇게 하면 애플리케이션과 관련이 없는 PDU를 포함할 수 있는 패킷을 보조 채널에서 스캔하는 데 소요되는 시간을 줄여 스캔 효율이 향상됩니다.
2.3 광고주 모니터링
옵저버 디바이스의 호스트 구성 요소는 Bluetooth LE 컨트롤러에 중복 광고 패킷을 필터링하도록 지시할 수 있습니다. 이 유형의 필터링이 활성화되면 호스트는 각 고유 디바이스로부터 하나의 광고 패킷만 수신합니다(이 맥락에서 고유 디바이스를 구성하는 핵심 사양 정의에 따름). 이는 호스트의 효율성을 향상시키지만, 관찰자 디바이스가 이제 연결을 시도해야 하는 상황에서 호스트는 디바이스가 여전히 범위 내에 있는지 여부를 알 수 없다는 단점이 있습니다. 이로 인해 관찰자가 더 이상 범위 내에 있지 않은 이전에 발견된 디바이스를 높은 듀티 사이클 스캔을 수행하느라 에너지를 낭비할 수 있습니다.
새로운 광고주 모니터링 기능은 호스트 컨트롤러 인터페이스(HCI) 이벤트를 사용하여 관심 있는 디바이스가 범위 안팎으로 이동할 때마다 호스트에게 알려줍니다.
2.4 ISOAL 향상
비동기 적응 계층(ISOAL)은 더 큰 데이터 프레임을 더 작은 링크 계층 패킷으로 전송할 수 있도록 하고 수신자가 데이터를 올바르게 처리하는 데 필요한 관련 타이밍 정보를 재구성할 수 있도록 합니다.
ISOAL은 특정 변수에 따라 프레임 또는 프레임되지 않은 PDU를 생성할 수 있습니다. 프레임된 PDU가 생성되면 결과적으로 지연 시간이 늘어날 수 있습니다.
Bluetooth 핵심 사양 버전 6.0에서는 이 문제에 특히 민감한 사용 사례의 지연 시간을 줄여주는 새로운 프레이밍 모드를 정의하여 ISOAL을 개선했습니다. 같은 기능으로 안정성도 향상되었습니다.
2.5 LL 확장 기능 세트
디바이스는 각각 지원하는 링크 계층 기능에 대한 정보를 교환할 수 있습니다. 이 기능은 Bluetooth LE의 정교함과 다양성이 커짐에 따라 더 많은 기능을 지원하도록 개선되었으며, 그 필요성이 커졌습니다.
2.6 프레임 공간 업데이트
이전 버전의 Bluetooth 핵심 사양에서는 연결 이벤트 또는 연결된 등시 스트림(CIS) 하위 이벤트에서 패킷의 인접한 전송을 분리하는 시간에 대한 상수 값을 정의했습니다. 이 값은 사양에서 T_IFS로 지정되며 고정값은 150µs였습니다.
핵심 사양 버전 6.0에서는 연결 또는 연결된 등시 스트림에서 사용되는 프레임 간격이 이제 협상 가능하며 150µs보다 짧거나 길어질 수 있습니다.
3. 블루투스® 3. Channel Sounding
3.1 배경
이 섹션에서는 새로운 Bluetooth® Channel Sounding 기능을 더 잘 이해하고 감상하는 데 도움이 되는 Bluetooth LE 기술의 측면에 대한 개요를 제공합니다.
3.1.1 디바이스 포지셔닝 및 Bluetooth LE
Bluetooth LE가 Bluetooth 핵심 사양에 처음 지정된 이후, 도착각(AoA) 및 출발각(AoD) 방향 찾기와 같은 핵심 기능과 나를 찾기 프로필과 같은 여러 관련 프로필로 인해 Bluetooth LE는 위치 서비스에 널리 사용되는 기술로 자리 잡았습니다.
또한 표준 Bluetooth LE 광고 패킷 내에서 전송되는 몇 가지 독점적인 비콘 메시지 형식이 널리 채택되었습니다.
많은 애플리케이션에서 두 개의 Bluetooth 장치 사이의 거리를 계산해야 합니다. Bluetooth 핵심 사양 버전 6.0이 출시되기 전에는 경로 손실 계산이라는 방법을 통해서만 이 작업을 수행할 수 있었습니다. 이 방법을 사용하려면 수신 장치가 수신 신호 강도( RSSI라고 함)를 측정하고 송신기로부터 1미터와 같은 기준 거리에서 원격 장치가 전송하는 신호의 강도를 알아야 합니다. 또한 관련 물리학에 따르면 수신기의 신호 강도는 송신기로부터의 거리의 제곱에 반비례합니다. 송신기 기준 신호 강도, RSSI 및 이 간단한 수학적 관계를 통해 거리 값을 계산할 수 있습니다.
경로 손실 계산은 거리 계산의 정확성이 요구되고 이러한 계산의 일관성과 신뢰성이 특별히 높지 않은 경우에 적합합니다. 두 디바이스 사이의 거리가 비교적 짧은 경우 신호 강도가 초기에 빠르게 떨어지는 방식(그림 2 참조)으로 인해 경로 손실 계산은 상당히 좋은 결과를 얻을 수 있습니다. 그러나 장거리에서는 작은 신호 강도 변화가 가능한 거리의 큰 범위에 해당할 수 있으므로 계산이 작은 오류에 매우 민감하게 반응합니다. 이 방법은 간섭 및 기타 환경 요인의 영향에 취약합니다. 또한 안전하지 않아 애플리케이션이 거리 스푸핑과 같은 공격의 위험에 노출될 수 있습니다.
자산 추적, 키리스 출입 및 점화 시스템과 같이 애플리케이션의 요구 사항이 까다로울수록 더욱 정교하고 안전하며 표준화된 접근 방식을 통해 보다 정확하고 신뢰할 수 있는 결과를 얻을 수 있습니다.
3.1.2 데이터 전송 아키텍처
Bluetooth 핵심 사양은 Bluetooth 데이터 전송 아키텍처를 총체적으로 구성하는 몇 가지 개념을 정의합니다. 이러한 개념 중에는 물리적 전송, 물리적 채널, 물리적 링크, 논리적 링크, 논리적 전송이 있습니다. 토폴로지, 타이밍, 안정성, 전력 및 채널 사용과 같은 속성과 관련된 특정 특성을 가진 다양한 애플리케이션 유형을 지원하기 위해 특정 조합 및 구성이 정의되어 있습니다. 운영 모드 또는 운영 방식이라는 용어는 다양한 데이터 전송 아키텍처 구성을 지칭하기 위해 비공식적으로 사용되기도 합니다.
그림 3 - Bluetooth 데이터 전송 아키텍처의 일부
그림 3은 가장 일반적으로 사용되는 두 가지 논리적 전송과 이와 관련된 물리적 링크, 물리적 채널 및 물리적 전송 구성 요소를 강조한 데이터 전송 아키텍처의 일부를 보여줍니다. 이 두 논리적 전송은 모두 Bluetooth® Channel Sounding 와 관련이 있습니다.
3.1.2.1 LE-ACL
LE-ACL은 가장 일반적으로 사용되는 Bluetooth LE 논리적 전송 유형 중 하나로, 두 장치 간의 연결 지향적 데이터 통신을 제공합니다. 실제로 ACL 연결은 일반적으로 단순히 연결이라고 합니다.
연결을 요청하는 장치를 중앙 장치라고 합니다. 이 요청을 수신하고 승인하는 장치를 주변 장치라고 합니다.
두 디바이스가 ACL 연결을 설정하면 이후 통신에 적용되는 여러 타이밍 매개변수에 동의하게 됩니다. 이러한 매개변수 중 핵심은 연결 간격입니다. 연결 간격 매개변수는 이 연결을 서비스하기 위해 무전기를 사용할 수 있는 빈도를 밀리초 단위로 정의합니다.
ACL 연결은 암호화될 수 있으며, 이 경우 모든 페이로드는 패킷 전송이 발생하기 전에 링크 계층에서 암호화되고 피어 디바이스의 링크 계층에서 수신되면 해독됩니다.
3.1.2.2 ADVB
ADVB는 광고 브로드캐스트 논리적 전송입니다. 연결 없는 통신 모드를 제공하며 하나 이상의 디바이스에 동시에 데이터를 전송하거나 주변 디바이스의 존재를 표시하여 다른 디바이스가 이를 발견할 수 있도록 하는 데 사용할 수 있습니다.
3.2 Bluetooth® 정보 Channel Sounding
3.2.1 개요
Bluetooth LE의 Bluetooth® Channel Sounding 기능은 독립적으로 또는 조합하여 사용할 수 있는 두 가지 거리 측정 방법으로 구성되어 있습니다. 이 두 가지 방법을 위상 기반 거리 측정(PBR)과 왕복 타이밍(RTT)이라고 합니다.
이 시스템은 경로 손실 방식보다 훨씬 더 정확한 거리 측정 계산을 지원하며 간섭과 환경 요인의 영향에 덜 취약하고 다양한 보안 메커니즘을 통합합니다.
이 섹션에서는 Bluetooth® Channel Sounding 에 대한 소개를 제공합니다. bluetooth.com 보다 심층적이고 포괄적인 설명은 Bluetooth SIG 웹 사이트, https://www 에서 제공되는 관련 문서 Bluetooth Channel Sounding 을 통한 보안 정밀 거리 측정(Secure Fine Ranging)을 참조하십시오 .
3.2.2 기술적 주요 사항
3.2.2.1 시스템 아키텍처
Bluetooth® Channel Sounding 는 연결된 두 장치 간에 1:1 토폴로지로 이루어집니다. 자신으로부터 다른 장치까지의 거리를 계산하고자 하는 장치를 이니시에이터라고 합니다. 다른 장치를 리플렉터라고 합니다.
channel sounding 동안에는 사전에 합의된 시간 슬롯 동안 개시자와 리플렉터 간에 여러 양방향 교환이 이루어집니다.
Bluetooth 스택에서 channel sounding 은 주로 스택의 호스트 부분이 아닌 Bluetooth 컨트롤러의 함수입니다. 이니시에이터의 컨트롤러는 낮은 수준의 측정값을 호스트에 전달하고 궁극적으로는 호스트 컨트롤러 인터페이스(HCI)를 사용하여 애플리케이션 계층에 전달합니다. 거리 측정을 계산하기 위해 컨트롤러가 제공하는 channel sounding 데이터를 사용하는 것은 애플리케이션의 책임입니다.
그림 4 - CS 디바이스 역할 및 호스트/컨트롤러 기능 분포
Bluetooth Channel Sounding 을 사용하는 디바이스에는 안테나 어레이가 포함될 수 있습니다. 이는 일련의 다양한 통신 경로를 제공하고 다중 경로 전파의 영향을 줄여 거리 측정의 정확도를 향상시킬 수 있습니다.
3.2.2.2 Bluetooth® Channel Sounding 및 데이터 전송 아키텍처
그림 5는 전체 데이터 전송 아키텍처의 하위 집합을 보여주고 있으며, channel sounding 을 지원하기 위해 추가된 새로운 물리적 링크 및 물리적 채널 유형을 보여줍니다.
Channel sounding 는 두 디바이스 간의 ACL 연결을 사용하여 시작됩니다. channel sounding 이 시작되면 ACL 연결은 링크 계층 제어 교환을 위한 전송 역할을 계속하고 channel sounding 무선 활동 스케줄링에 대한 타이밍 참조를 제공합니다. Channel sounding 은 새로운 Channel Sounding 물리적 링크와 Channel Sounding 물리적 채널을 사용합니다.
개시자 및 리플렉터 역할은 각각 중앙 또는 주변 장치에서 맡을 수 있습니다.
3.2.2.3 거리 측정 방법
3.2.2.3.1 위상 기반 거리 측정(PBR)
PBR 방법은 위상이라는 무선 신호의 기본 속성과 주파수 및 파장과의 관계를 활용합니다. 위상은 파동 주기의 일부분으로 생각할 수 있으며 일반적으로 0에서 2π 라디안 사이의 각도로 표현됩니다. 위상의 변화는 때때로 위상 회전으로 인해 발생합니다.
그림 6은 무선 신호 내의 포인트에 해당하는 위상 값의 예를 보여줍니다. 여러 파동 주기에 걸쳐 주기적으로 반복되는 값의 특성에 주목하세요.
PBR을 사용할 때, 개시자는 주어진 주파수 f1의 신호를 리플렉터로 전송합니다. 리플렉터는 다시 이니시에이터로 신호를 전송하고, 리플렉터는 응답을 수신하면 수신된 신호의 위상을 측정하며, 여기서는 이를 Pf1이라고 부릅니다.
그림 7 - 개시자가 리플렉터가 에코하는 channel sounding 신호를 전송합니다.
다음으로, 개시자는 이번에는 다른 주파수인 f2로 또 다른 무선 신호를 전송합니다. 리플렉터는 수신된 신호를 다시 개시자에게 다시 한 번 반향합니다. 주파수를 변경하면 파장이 변경되고 결과적으로 리플렉터의 응답을 수신할 때 이니시에이터가 측정한 위상 Pf2도 변경됩니다.
이제 개시자는 주파수 차이(f1 - f2), 위상차(Pf1 - Pf2) 및 빛의 속도를 포함하는 공식을 사용하여 두 장치 사이의 거리를 계산할 수 있습니다.
실제로 디바이스는 일반적으로 두 개 이상의 서로 다른 주파수에서 두 개 이상의 신호를 교환하는데, 이는 더 낮은 수준의 측정값을 사용할 수 있으면 애플리케이션에서 계산한 거리 측정의 정확도를 향상시킬 수 있기 때문입니다.
이니시에이터가 측정한 위상 값은 장치 사이의 거리가 증가함에 따라 변화하지만 특정 지점에서 0으로 재설정되고 위상 값이 반복되기 시작합니다. 이는 그림 6에 표시된 것처럼 위상 회전의 주기적 특성 때문입니다. 거리 측정의 맥락에서 이 현상을 거리 모호성이라고 하는데, 여러 다른 거리에서 동일한 위상 값이 발생할 수 있기 때문입니다. 거리 모호성이 처음 발생하는 정확한 시기는 channel sounding 신호의 주파수 차이에 따라 달라집니다. 이 차이 값을 주파수 분리라고 합니다. 일반적으로 거리 모호성은 주파수 간격이 클수록 더 일찍 발생합니다. Bluetooth CS는 1MHz의 주파수 간격을 사용하며 거리 모호성은 약 150미터까지 발생하지 않습니다.
거리 모호성 문제는 두 번째 거리 측정 방법인 왕복 타이밍과 함께 PBR을 사용하여 해결할 수 있습니다.
3.2.2.3.2 왕복 타이밍(RTT)
RTT 방식은 개시자가 리플렉터에게 패킷을 전송하고 리플렉터가 동일한 패킷을 다시 전송하는 방식입니다. 이 점에서만 PBR 방식과 유사점이 있습니다.
거리 측정을 계산할 수 있도록 개시자는 패킷을 전송할 때 타임스탬프를 기록합니다. 이 시간을 출발 시간 또는 ToD라고 합니다. 리플렉터로부터 응답 패킷을 수신하면 다시 타임스탬프를 기록하는데, 이 시간을 도착 시간 또는 ToA라고 합니다.
ToD와 ToA 사이에 경과하는 시간을TA-D라고 하면 이동 거리의 측정값은TA-D에 빛의 속도(c)를 곱한 다음(양방향 왕복 시간이므로) 2로 나누어 얻을 수 있습니다. 그러나 리플렉터가 패킷을 수신하여 처리하고 응답을 공식화하여 전송하는 데 걸리는 시간을 고려하지 않기 때문에 매우 대략적인 거리 추정치가 산출될 수 있습니다. 이 처리 과정은 짧고 중요하지 않은 시간처럼 보이지만 진공 상태에서 빛의 속도로 이동하는 무선 전송은 마이크로초당 300미터를 이동할 수 있으므로 비행 시간을 계산하는 데 아주 작은 부정확성이 계산된 거리에 매우 큰 영향을 미칠 수 있습니다. 따라서 RTT 방식으로 정확한 거리를 측정하려면 무선 신호가 실제로 비행 중에 보내는 시간을 정확하게 파악하는 것이 중요합니다.
Bluetooth Channel Sounding 의 RTT는 리플렉터가 수신한 CS 패킷을 돌려서 이니시에이터에게 다시 보내는 데 걸리는 시간을 알 수 있으므로 이 시간 값을 계산에 사용하여 보다 정확한 비행 시간을 생성할 수 있습니다.
Bluetooth 핵심 사양에서는 ToA 및 ToD 타임스탬프를 캡처하는 여러 가지 방법을 정의하고 있습니다. 방법의 선택은 복잡성과 정확도에 따라 다릅니다. 가장 정확한 시간 캡처 방법은 분수 시간 추정이라고 알려져 있습니다. ToA 및 ToD 값을 최대한 정확하게 캡처하면 가장 정확한 거리 측정값을 얻을 수 있습니다.
channel sounding 을 시작하려면 먼저 개시자와 리플렉터가 암호화된 ACL 연결을 설정해야 합니다. 그런 다음 이 연결은 channel sounding 초기화 절차와 관련된 링크 계층 제어 PDU의 안전한 교환에 사용됩니다.
Bluetooth® Channel Sounding 에는 고유한 보안 기능이 있습니다. 첫 번째로 실행되는 channel sounding 절차는 CS 보안 시작 절차입니다. 이 절차는 두 장치에 초기화 벡터(IV), 인스턴스화 논스(IN) 및 개인화 벡터(PV) 값을 장착하며, 이후 channel sounding 동안 새로운 보안 기능인 결정론적 랜덤 비트 생성기(DRBG)의 입력으로 사용됩니다. DRBG는 많은 channel sounding 보안 기능에 사용됩니다( 3.2.2.10 Bluetooth® Channel Sounding 보안 개요). 암호화된 ACL 연결의 보안은 이 중요한 데이터의 교환을 보호합니다.
Bluetooth® Channel Sounding 기능을 통해 개발자는 사용되는 거리 측정 방법, 측정 정확도, 절차로 인한 지연 시간, 보안 및 기타 변수를 제어하거나 영향을 줄 수 있는 다양한 옵션을 사용할 수 있습니다. 장치마다 channel sounding 기능이 반드시 동일할 필요는 없으며 CS 기능 교환 절차를 통해 두 장치가 기능 및 기본 설정에 대한 정보를 교환할 수 있습니다.
기능 데이터를 교환한 장치는 CS 구성 절차에 참여하여 channel sounding 절차가 시작될 때 적용될 구성 매개변수에 동의합니다.
PBR 방식을 사용할 때 리플렉터는 이니시에이터로부터 수신한 신호를 동일한 주파수로 반향해야 합니다. 그러나 모든 디바이스는 생성된 신호의 주파수가 어느 정도 부정확할 수 있으며, 의도하거나 원하는 주파수가 생성된 신호의 실제 측정된 주파수와 다를 수 있습니다. 주파수는 파장과 직접적으로 관련이 있으며 PBR 방법은 이 관계에 의존합니다. 따라서 리플렉터에서 반사된 신호의 주파수가 부정확하면 거리 측정의 정확도에 영향을 미칠 수 있습니다. 따라서 제조업체는 기준 주파수 모음에 대해 생성된 신호의 주파수와 예상 또는 요청된 주파수 간의 차이를 ppm(Parts Per Million)으로 표시하는 분수 주파수 오프셋 작동 오류(FAE) 테이블이라는 데이터 표를 디바이스에 장착할 수 있습니다. 모드-0[1] FAE 테이블 요청 절차를 사용하여 개시자는 리플렉터에 FAE 테이블을 요청할 수 있으며, 계산을 수행할 때 이 데이터를 고려할 수 있습니다.
초기화 절차가 완료되면 channel sounding 을 시작할 수 있습니다. 여기에는 애플리케이션에서 거리 계산에 사용할 수 있는 측정을 수행하기 위해 두 장치가 다양한 유형의 일련의 교환을 하는 과정이 포함됩니다.
3.2.2.5 시간 구분
Channel sounding 일반 Bluetooth 데이터 전송 아키텍처의 Channel Sounding 물리적 채널을 사용합니다( 3.2.2.2 Channel Sounding 및 데이터 전송 아키텍처 참조). 이는 RF 활동에 시간을 세분화하여 사용하는 방법을 정의합니다.
3.2.2.5.1 이벤트, 하위 이벤트 및 단계
Channel sounding 는 일련의 절차로 진행됩니다. 각 절차는 여러 개의 이벤트로 구성되며 각 이벤트는 다시 하위 이벤트로 나뉩니다. 이 계층 구조 내에서 시간을 마지막으로 세분화한 것이 스텝입니다. 스텝 내에서 개시자와 리플렉터 간의 RF 교환이 이루어집니다.
그림 8 - 예제 구성에서 Channel Sounding 절차의 구조
다양한 구성 매개변수가 서로 다른 수준의 요소 간 관계의 카디널리티(예: 하위 이벤트당 단계 수), 이벤트 기간 및 단계에서 발생하는 활동을 포함하여 이 구조의 측면을 제어합니다. 예를 들어, 하위 이벤트에는 항상 최소 2개에서 최대 160개의 단계가 있습니다. 절차당 최대 256개의 단계가 있습니다.
3.2.2.5.2 타이밍 앵커 포인트
모든 channel sounding 절차, 이벤트, 하위 이벤트 및 단계 시작 시간은 channel sounding 을 시작하기 위한 링크 계층 절차가 실행된 연결된 LE ACL 연결에서 선택한 연결 이벤트에 직접 또는 간접적으로 고정되어 있습니다.
3.2.2.6 Bluetooth® Channel Sounding 단계
3.2.2.6.1 패킷 및 톤
CS 단계 동안 디바이스는 CS 동기화 패킷이라고 하는 일련의 패킷과 선택적으로 CS 톤이라고 하는 톤을 교환합니다.
CS 동기화 패킷은 LE 1M 또는 LE 2M PHY를 사용하여 전송할 수 있습니다. GFSK[2] 변조 방식은 다른 Bluetooth LE 패킷과 마찬가지로 두 경우 모두 사용됩니다.
CS 톤은 진폭 시프트 키잉(ASK)을 사용하여 주파수가 고정된 기호를 생성하는 신호입니다.
단계에는 0에서 3까지 번호가 매겨진 관련 모드가 있습니다. 모드는 스텝에서 이루어지는 교환의 세부 사항과 그 목적을 정의합니다.
- 모드 0 단계는 캘리브레이션과 관련된 단계로, 이니시에이터는 리플렉터의 특정 주파수 발생이 자신의 주파수 발생과 어느 정도 차이가 나는지 확인할 수 있습니다. 이를 통해 주파수 생성 차이를 보정하기 위한 계산에 사용되는 분수 주파수 오프셋(FFO)이라는 값이 산출됩니다. 모드 0 단계에서는 CS 동기화 패킷을 교환합니다.
- 모드 1 단계는 왕복 타이밍(RTT) 방식을 적용할 때 CS 동기화 패킷을 사용합니다.
- 모드 2 단계는 위상 기반 거리 측정(PBR)을 목적으로 CS 톤을 교환하는 단계입니다.
- 모드 3 단계에서는 CS 동기화 패킷과 CS 톤을 모두 교환하며, 한 단계에서 RTT와 PBR 방식에 대한 데이터를 모두 수집할 수 있습니다. 모드 3에 대한 지원은 선택 사항입니다.
channel sounding 절차에서 사용되는 단계 모드는 Bluetooth 핵심 사양의 규칙과 두 디바이스가 합의한 구성에 따라 달라집니다. 여기에는 어떤 거리 측정 방법(예: RTT 및/또는 PBR)을 사용할지 여부가 포함됩니다.
3.2.2.6.2 모드 조합 및 시퀀싱
Bluetooth Channel Sounding 를 사용하면 프로시저 내에서 다양한 패턴으로 단계 모드를 결합하고 순서를 지정할 수 있으며, 애플리케이션 계층이 구성 중에 많은 제어권을 행사할 수 있습니다. 또한 애플리케이션 계층은 수행될 channel sounding 프로시저의 반복 횟수와 교환되는 패킷 또는 톤의 수 및 일부 측면에서는 그 내용에 영향을 미치는 기타 변수를 구성할 수 있습니다.
애플리케이션은 최적의 구성을 결정할 때 필요한 거리 측정 정확도, 지연 시간 허용 범위 및 보안 요구 사항과 같은 문제를 고려합니다. 예를 들어, 일반적으로 교환 수가 많을수록 더 많은 측정값을 제공하고 정확도를 개선하는 데 도움이 될 수 있지만 지연 시간이 늘어나는 대가를 치르게 됩니다.
각 하위 이벤트에는 항상 최소 두 가지 이상의 단계 모드가 포함됩니다. 모드 0은 항상 모든 하위 이벤트를 시작하며, Bluetooth 핵심 사양에 제시되고 여기 표 1에 반복되는 특정 허용 조합에 따라 동일한 하위 이벤트의 다른 단계에 하나 또는 두 개의 다른 모드를 사용할 수 있습니다.
Main_Mode |
Sub_Mode |
---|---|
Mode-1 |
None |
Mode-2 |
None |
Mode-3 |
None |
Mode-2 |
Mode-1 |
Mode-2 |
Mode-3 |
Mode-3 |
Mode-2 |
표 1 - 허용되는 모드 0이 아닌 모드 조합.
표 1에는 Main_Mode 및 Sub_Mode라는 용어도 소개되어 있습니다. 이 용어는 여러 구성 매개변수를 통해 반복되는 스텝 모드 패턴을 만드는 방식과 관련이 있습니다. 구성 절차에 따라 1~3번 모드 중 하나를 메인 모드로 지정하고 선택적으로 다른 모드를 서브 모드로 지정할 수 있습니다.
일반적으로 스텝 모드 시퀀싱은 이 패턴을 따릅니다:
- 하나 이상의 모드 0 단계가 하위 이벤트를 시작합니다.
- 그런 다음 n개의 메인 모드 단계가 이어지며, 여기서 n개는 무작위로 선택되고 구성된 범위 내에 속합니다.
- 단일 서브 모드 단계는 Bluetooth 핵심 사양에서 서브 모드 삽입이라고 부르는 프로세스에 따라 n개의 메인 모드 단계의 순서를 따릅니다.
스텝 모드 시퀀스는 서브 이벤트가 항상 하나 이상의 모드 0 스텝으로 시작해야 한다는 일반적인 규칙을 제외하고는 서브 이벤트 경계에 묶이지 않습니다. 전체 시퀀스는 둘 이상의 서브이벤트에 걸쳐 있을 수 있습니다.
3.2.2.7 RF 채널
3.2.2.7.1 채널 및 채널 필터링
channel sounding 의 경우 72개의 채널이 정의되어 있으며, 각 채널은 1MHz 폭과 고유한 채널 인덱스 값을 갖습니다. 이러한 채널의 배열은 LE 기본 광고 채널을 피할 수 있도록 합니다.
일반적인 2MHz가 아닌 1MHz의 채널 폭은 인접 채널을 사용하는 PBR 신호 간의 주파수 분리를 보장하여 약 150미터까지 거리 모호성이 발생하지 않도록 합니다.
CS 채널 맵이라는 특수 채널 맵은 채널 선택에 포함할 채널과 피해야 할 채널을 나타냅니다. 링크 레이어 제어 절차를 통해 이니시에이터와 리플렉터는 로컬 RF 조건에 따라 이 테이블에 업데이트를 제공할 수 있습니다.
주파수 호핑에는 사용 가능한 것으로 표시된 채널 중에서 새 채널을 선택하는 작업이 포함됩니다. 이는 일반적으로 주 모드 반복이라는 모드 시퀀싱 기능을 사용하는 경우를 제외하고 각 단계를 실행하기 직전에 이루어집니다.
3.2.2.7.2 채널 선택
Channel Sounding 에서 사용하기 위해 세 가지 채널 선택 알고리즘(CSA)이 새롭게 정의되었습니다. 총칭하여 CSA #3으로, 개별적으로는 CSA #3a, CSA #3b 및 CSA #3c로 알려져 있습니다.
CSA #3a는 모드 0 단계에서 사용할 채널을 선택하는 용도로만 사용됩니다.
CSA #3b와 CSA #3c는 모두 모드 0이 아닌 단계에 사용하도록 설계되었지만 channel sounding 프로시저 인스턴스에서는 둘 중 하나만 사용할 수 있습니다.
channel sounding 동안 두 개의 채널 목록이 유지됩니다. 첫 번째는 CSA #3a와 모드 0 단계의 채널 선택에만 사용됩니다. 두 번째는 CSA #3b 또는 CSA #3c와 함께 모드 0이 아닌 단계에 사용됩니다.
CSA #3a와 CSA #3b는 동일한 방식으로 작동하지만 서로 다른 채널 목록에 대해 작동합니다. 각각은 포함된 것으로 표시된 채널의 순서를 무작위로 지정하여 셔플된 채널 목록을 생성하는 동일한 알고리즘을 사용합니다. 셔플된 채널 목록의 각 항목은 고유하며 한 번만 사용됩니다. 셔플된 채널 목록의 모든 항목이 사용되면 채널 목록이 다시 생성되어 무작위 채널 목록이 새로 만들어집니다.
알고리즘 CSA #3c는 CSA #3b와 크게 다릅니다. 채널 맵에 포함된 채널의 하위 집합을 그룹으로 구성하고 그룹 내에서 도형을 형성하는 채널 패턴을 생성합니다. 두 가지 패턴 유형이 지원되며 모자( hat )와 X라는 이름이 붙습니다. CSA #3c는 일부 상황에서 반사된 신호 경로를 감지하는 데 몇 가지 이점을 제공할 수 있습니다. 자세한 내용은 Bluetooth 핵심 사양을 참조하세요. CSA #3c에 대한 지원은 선택 사항입니다.
3.2.2.8 LE 2M 2BT PHY
Bluetooth LE의 물리적 계층에는 PHY로 알려진 몇 가지 허용된 구성에 대한 정의가 포함되어 있습니다. PHY의 정의에는 사용된 변조 방식과 심볼 레이트, 최소 주파수 편차 및 대역폭-비트 주기 곱(BT) 등의 매개변수가 포함됩니다.
Bluetooth 핵심 사양 버전 6.0 이전에는 세 가지 정의된 PHY가 있었습니다. 이름은 LE 1M, LE 2M 및 LE 코딩입니다. LE 코딩된 PHY는 패킷에 오류 감지 및 수정을 가능하게 하는 추가 코딩이 적용된다는 점을 제외하면 LE 1M과 동일합니다.
버전 6.0에는 LE 2M 2BT라는 새로운 물리 계층 구성이 도입되었습니다. 이 새로운 PHY는 Bluetooth® Channel Sounding 에서만 사용할 수 있습니다.
표 2에 네 가지 PHY의 비교가 나와 있습니다.
|
LE 1M |
LE Coded |
LE 2M |
LE 2M 2BT |
---|---|---|---|---|
Symbol Rate |
1 Msym/s |
1 Msym/s |
2 Msym/s |
2 Msym/s |
BT |
0.5 |
0.5 |
0.5 |
2.0 |
Min. Frequency Deviation |
185 kHz |
185 kHz |
370 kHz |
420 kHz |
Error Detection |
CRC |
CRC |
CRC |
N/A |
Error Correction |
NONE |
FEC |
NONE |
N/A |
Requirement |
Mandatory |
Optional |
Optional |
Optional. Only to be used with Channel Sounding. |
표 2 - PHY 비교
대역폭-비트 주기 곱(BT)은 대역폭과 심볼의 지속 시간 간의 관계에 대한 정보를 제공하는 신호의 속성입니다.
BT는 기호를 구성하는 무선 펄스의 모양과 스팬에 영향을 줍니다. BT 값이 높을수록 펄스의 폭이 좁고 사각형이 되며, 값이 낮을수록 펄스의 모양이 넓고 둥글어집니다.
BT 값이 2.0이면 특정 유형의 물리적 계층 공격에 대해 channel sounding 의 보안이 향상됩니다. 참조 3.2.2.10 Bluetooth® Channel Sounding 보안 개요.
3.2.2.9 Channel Sounding 단계에 대한 SNR 제어
일부 무선 송신기에는 지정된 범위 내에서 신호 대 잡음비(SNR)를 조정할 수 있는 기능이 있습니다. SNR 제어 기능을 사용하면 이니시에이터와 리플렉터 디바이스가 CS 동기화 패킷 전송을 위한 CS 모드-1 및 모드-3 단계 중에 사용할 SNR 출력 레벨을 조정할 수 있습니다. SNR을 조정하려면 신호에 어느 정도의 노이즈를 인위적으로 혼합해야 합니다. 출력 SNR은 두 장치 모두에 알려져 있으므로 이 노이즈의 존재는 두 CS 장치에 문제가 되지 않습니다. 이 기술을 사용하면 일부 유형의 물리적 계층 중간자 공격의 위험이 줄어듭니다.
3.2.2.10 Bluetooth® Channel Sounding 보안 개요
거리 측정 솔루션에 고유한 보안 문제는 일반적으로 신뢰할 수 없는 장치가 신뢰할 수 있는 장치를 속여 다른 신뢰할 수 있는 장치가 특정 조치를 허용하거나 수행할 수 있을 만큼 충분히 가까이 있다고 결론을 내리도록 하는 위협과 관련이 있습니다. 예를 들어, 키리스 출입 시스템에서 악성 장치가 연결된 신뢰할 수 있는 무선 키 카드가 문이 자동으로 잠금 해제될 만큼 충분히 가까이 있다고 도어록을 속일 수 있다면 권한이 없는 사람이 출입할 수 있습니다.
보안 전문가들은 거리 측정과 관련된 일련의 공격을 인지하고 있습니다. 일부는 독립형 악성 디바이스가 신뢰할 수 있는 디바이스의 통신을 가장하는 공격( 스푸핑이라고 함)을 포함하며, 다른 일부는 신뢰할 수 있는 디바이스의 신호를 중계하는 중간자(MITM) 공격 유형으로, 일반적으로 이 과정에서 신호 또는 디지털 콘텐츠를 조작하여 신뢰할 수 있는 디바이스가 신뢰할 수 있는 상대방과의 거리를 잘못 계산하도록 합니다. 이러한 공격의 세부 사항은 정교함과 구현의 복잡성 및 비용이 다양합니다.
Bluetooth Channel Sounding 에는 여러 가지 거리 측정 보안 위협에 대응할 수 있는 기능들이 포함되어 있습니다. 이러한 기능은 크게 네 가지 범주로 분류할 수 있습니다:
- PBR과 RTT 방법을 함께 사용합니다.
- PBR과 RTT 방법의 데이터를 모두 사용하여 거리를 계산하면 값을 교차 확인할 수 있습니다. 현저한 차이는 애플리케이션에서 의심을 가지고 처리해야 합니다. 두 가지 방법을 모두 표적으로 삼고 교차 확인을 통해 탐지를 피할 수 있을 만큼 충분히 유사한 결과를 생성하는 공격은 매우 복잡하고 구현 비용이 많이 드는 것으로 간주됩니다.
- 비트 스트림 및 전송 패턴의 무작위화.
- 무작위 비트 값은 비트 스트림에서 무작위로 선택된 위치로 전송됩니다. 값과 위치는 새로운 결정론적 랜덤 비트 생성기(DRBG)를 사용하여 생성되거나 선택됩니다. 이니시에이터와 리플렉터는 모두 동일한 IN, IV 및 PV 값을 갖습니다( 3.2.2.4 Bluetooth® Channel Sounding 초기화참조), 따라서 호출될 때 각각의 DRBG 인스턴스는 동일한 무작위 생성 비트 스트림을 생성합니다. 즉, 두 개의 합법적인 장치는 어떤 무작위 비트 값을 예상하고 어디에서 찾을 수 있는지 알고 있습니다. 악성 디바이스는 IN, IV, PV 값을 가지고 있지 않으므로 이 값을 추측할 수 있을 뿐입니다. 모든 거래소에서 비트 스트림의 모든 무작위 부분을 추측할 확률은 매우 낮습니다. 또한 일부 시간 슬롯은 무작위로 전송에 사용되거나 사용되지 않으며, 이는 다시 한 번 DRBG에 의해 제어되며 합법적인 CS 장치만 예측할 수 있습니다.
- 심볼 조작에 대한 방어
- 특정 MITM 공격에는 무선 심볼을 조작하여 표적 디바이스가 다른 정상 디바이스와의 거리를 잘못 계산하도록 하는 방법이 포함됩니다. 이러한 공격은 공격자가 잠재적인 RF 채널 범위에서 몇 마이크로초 만에 전송을 발견하고 심볼을 빠르게 조작하는 데 의존합니다.
- SNR 제어 기능을 사용할 때 전송에 노이즈가 추가되면 공격자가 신호 분석에 소요해야 하는 처리 시간이 늘어납니다. 추가 처리 시간이 충분히 필요하면 공격은 효과가 없게 됩니다.
- LE 2M 2BT PHY는 심볼 스팬이 짧기 때문에 이러한 방식으로 심볼을 가로채고 조작하기가 더 어렵습니다.
- 공격 탐지를 포함한 RF 신호 분석 기술.
- Bluetooth 핵심 사양에는 Bluetooth® Channel Sounding 에 대한 공격 탐지기 시스템에 대한 설명이 포함되어 있습니다. 여기에는 공격이 진행 중일 확률을 애플리케이션 계층에 보고하기 위한 표준화된 메트릭이 포함되어 있습니다. 이 메트릭을 정규화된 공격 탐지기 메트릭 또는 NADM이라고 합니다. NADM 값은 수신된 신호의 평가를 기반으로 컨트롤러에 의해 할당되며, 공격 가능성이 매우 낮은 범위에서 시작하여 공격 가능성이 가장 높은 범위까지 공격 가능성을 나타내는 슬라이딩 스케일 형태를 취합니다. 표 3에는 Bluetooth 핵심 사양에서 재현한 NADM 값 정의가 포함되어 있습니다.
NADM Value | Description |
0x00 |
Attack is extremely unlikely |
0x01 |
Attack is very unlikely |
0x02 |
Attack is unlikely |
0x03 |
Attack is possible |
0x04 |
Attack is likely |
0x05 |
Attack is very likely |
0x06 |
Attack is extremely likely |
0xFF |
Unknown NADM. Default value for RTT types that do not have a random sequence or sounding sequence. |
표 3 - NADM 값
또한 Bluetooth 컨트롤러 구현자와 애플리케이션 개발자는 필요한 경우 Bluetooth Channel Sounding 보안 기능에서 제공하는 표준 보안 기능에 추가 안전장치를 보강할 수 있습니다.
3.2.3 Bluetooth®에 대한 자세한 정보 Channel Sounding
Bluetooth Channel Sounding 기능에 대한 자세한 검토를 위해 Bluetooth SIG 에서 이 주제에 대한 백서를 준비했습니다. 이 백서의 제목은 Bluetooth®를 사용한 보안 정밀 거리 측정 Channel Sounding 이며 Bluetooth SIG 웹 사이트에서 다운로드할 수 있습니다.
Bluetooth 핵심 사양은 구현자를 위한 유일한 참조 자료입니다.
4. 의사 결정 기반 광고 필터링
4.1 배경
이 섹션에서는 의사 결정 기반 광고 필터링(DBAF) 기능과 관련된 Bluetooth LE 기술의 측면에 대해 설명합니다.
4.1.1 링크 레이어 상태
링크 레이어는 Bluetooth LE 스택에서 가장 정교한 부분 중 하나입니다. 무선 전송을 위한 패킷과 PDU는 물론 다양한 논리적 전송의 정의의 일부인 송신기 및 수신기 동작 패턴을 정의합니다.
디바이스는 링크 계층의 인스턴스를 하나 이상 보유하고 있으며 각 인스턴스는 주어진 시간에 특정 상태에 있습니다. 상태와 상태 간 허용된 전환은 링크 레이어 상태 머신에 의해 정의됩니다.
표 4는 각 링크 계층 상태에 대한 간략한 설명입니다.
State |
Description |
---|---|
Standby |
Device neither transmits nor receives packets. |
Initiating |
Responds to advertising packets from a particular device to request a connection. |
Advertising |
Transmits advertising packets and potentially processes packets sent in response to advertising packets by other devices. |
Connection |
In a connection with another device. |
Scanning |
Listening for advertising packets from other devices. |
Isochronous Broadcast |
Broadcasts isochronous data packets. |
Synchronization |
Listens for periodic advertising belonging to a specific advertising train transmitted by a particular device. |
표 4 - 링크 레이어 상태 설명
광고, 스캔 및 시작 상태는 DBAF 기능과 관련이 있습니다.
4.1.2 필터 정책
필터 정책은 링크 계층이 수신된 패킷을 수락하고 다음 처리 단계로 전달할지 여부를 결정하는 기준을 정의합니다. 다양한 상태에서 사용할 수 있도록 여러 필터 정책이 정의되어 있습니다. 호스트는 HCI 명령을 사용하여 필터 정책을 선택하고 구성할 수 있습니다.
스캐닝 및 개시자 링크 계층 상태에 사용되는 필터 정책은 DBAF와 관련이 있습니다.
스캐닝 상태에서는 링크 계층 인스턴스가 수신되는 광고 패킷에 스캐닝 필터 정책을 적용합니다. DBAF 기능이 추가되기 전에는 두 가지 기본 스캐닝 필터 정책이 정의되어 있었습니다. 필터링되지 않은 스캐닝 필터 정책을 사용하면 수신된 모든 광고 패킷이 허용됩니다. 필터링된 스캐닝 필터 정책을 사용하면 필터 허용 목록 (호스트에 의해 채워지는)에서 식별된 디바이스의 광고 패킷만 허용됩니다. 확장 검색 필터 정책은 광고 패킷이 전달되는 대상 디바이스의 주소가 PDU에 포함되어 있는 다이렉트 광고에 사용하기 위해 정의됩니다.
개시자 필터 정책은 스캐닝 필터 정책과 유사하지만 연결 가능한 광고 PDU를 선택하기 위한 것입니다.[3] 연결 요청에 대한 응답으로 전송될 수 있는 광고 PDU[3]를 선택하기 위한 것입니다. DBAF 이전에는 두 가지 개시자 필터 정책이 정의되었습니다. 첫 번째 경우에는 특정 디바이스에서 연결 가능한 광고 패킷만 선택됩니다. 두 번째 경우에는 필터 허용 목록의 구성원인 모든 디바이스의 연결 가능한 광고 패킷이 허용됩니다.
모든 경우에 필터 정책을 적용하면 링크 계층에서 수신된 패킷을 수락하거나 삭제하는 결정이 내려집니다.
4.1.3 확장 광고
여러 형태의 광고가 Bluetooth 핵심 사양에 정의되어 있습니다. 광고 브로드캐스트(ADVB) 논리적 전송은 광고 패킷을 약간 무작위화된 타이밍 스케줄에 따라 전송하는 것을 포함합니다. ADVB에는 레거시 광고로 알려진 기본 형태와 확장 광고로 알려진 보다 정교한 변형이 있습니다.
레거시 광고는 채널 인덱스 값이 37, 38, 39인 세 가지 기본 광고 채널에서만 패킷을 전송하고 다른 보조 광고 채널은 포함하지 않습니다.
확장 광고는 40개의 Bluetooth LE RF 채널을 모두 사용합니다. 헤더 데이터는 ADV_EXT_IND PDU로 알려진 PDU 유형의 기본 채널에서 전송됩니다. 이 PDU 유형에는 AdvData 필드가 포함되어 있지 않으므로 애플리케이션 데이터 페이로드가 전달되지 않습니다. 대신 AUX_ADV_IND PDU가 포함되어 있고 37개의 보조 광고 채널 중 하나에서 전송되는 관련 보조 패킷을 참조하는 AuxPtr이라는 필드가 포함되는 경우가 많습니다. AdvData 페이로드 필드가 포함된 것은 바로 이 PDU입니다.
AuxPtr에는 보조 패킷이 전송될 채널, 사용된 PHY, 타이밍 오프셋을 나타내는 채널 인덱스 값과 수신자가 언제, 어디서, 어떻게 수신할지 알 수 있도록 하는 타이밍 오프셋이 포함됩니다. 보조 채널에서 전송되고 기본 채널의 패킷에서 AuxPtr 필드에 의해 참조되는 패킷을 보조 패킷이라고 하며, 참조 패킷을 상위 패킷이라고 합니다.
더 큰 애플리케이션 데이터 페이로드는 조각화되어 일련의 연결된 PDU로 전송될 수 있습니다. 이 시리즈는 AUX_ADV_IND PDU로 시작하여 여러 개의 AUX_CHAIN_IND PDU로 이어집니다. AUX_ADV_IND PDU와 연속되는 각 AUX_CHAIN_IND PDU는 AuxPtr 필드를 사용하여 연결됩니다. 그림 10은 PDU 연쇄를 특징으로 하는 확장 광고의 예를 보여줍니다.
ADV_EXT_IND와 같은 확장 광고 PDU에는 확장 헤더가 포함됩니다. 여기에는 Bluetooth 핵심 사양에 명시된 규칙에 따라 PDU에 필수, 선택 또는 조건부로 포함되는 일련의 필드가 포함되어 있습니다.
4.1.4 시작 상태
시작 상태에서 디바이스는 스캐닝 상태에서 연결 상태로 전환하려고 합니다. 이를 위해 대상 디바이스로부터 연결 가능한 광고 PDU를 수신하고 이를 수신한 경우 CONNECT_IND PDU(레거시 광고) 또는 AUX_CONNECT_REQ PDU(확장 광고)로 응답합니다.
4.1.5 문제
DBAF는 장시간 광고가 사용되는 상황에서 발생할 수 있는 스캔 디바이스의 유효 듀티 사이클을 개선합니다. 이는 방해 요소로 알려진 문제를 해결함으로써 이루어집니다.
4.1.5.2 방해 요소
4.1.5.2.1 방해 행위란 무엇인가요?
기본 채널에서 전송되는 ADV_EXT_IND PDU에는 애플리케이션 계층 데이터가 포함되어 있지 않습니다. 경우에 따라 옵저버(스캐닝 장치)는 AuxPtr을 따라 보조 채널에서 관련 보조 PDU를 수신하고 AdvData 페이로드 필드의 내용을 검사해야만 광고된 데이터가 관심 대상인지 여부를 결정할 수 있습니다. 그러기 위해서는 기본 채널에서 스캔을 중지하고 AuxPtr 필드에 표시된 보조 채널에서 스캔으로 전환해야 합니다.
시나리오에 따라 광고된 데이터가 관심 없는 것으로 판명되는 경우가 많을 수 있습니다. 이는 옵저버가 AuxPtr이 지정한 보조 채널에서 스캔하는 동안 더 이상 기본 채널에서 스캔하지 않아 관련성이 있는 패킷을 놓쳤을 수 있기 때문에 문제가 됩니다.
애플리케이션 계층에 관심이 없는 패킷을 검색하고 수신하기 위해 AuxPtr을 따르는 이러한 상황을 방해 행위라고 합니다.
주의가 산만해지면 옵저버의 유효 듀티 사이클이 감소합니다. 주의가 산만해져 기본 채널에서 패킷이 누락되면 확장 광고를 연결 없는 데이터 전송 메커니즘으로 사용하는 디바이스의 전체 데이터 전송 속도가 저하되고 다른 디바이스의 지연 시간이 늘어날 수 있습니다.
4.1.5.2.2 광고 세트 및 중복 데이터
확장 광고 PDU의 확장 헤더 필드에는 ADI(AdvDataInfo)라는 선택적 필드가 포함됩니다. ADI는 두 개의 하위 필드인 광고 데이터 ID(DID)와 광고 세트 ID(SID)를 포함합니다. SID는 전송된 PDU가 속한 광고 세트를 식별합니다. DID에는 동일한 광고 디바이스에서 전송된 PDU가 동일한 광고 세트의 회원, 회원사 에 새 데이터가 포함된 경우에만 변경되는 난수가 포함되어 있습니다.
기본 채널에서 전송되고 보조 패킷이 연결된 ADV_EXT_IND PDU에 AdvDataInfo를 포함할 수 있습니다. 이를 통해 스캐닝 디바이스는 관련 광고 세트에 속한 PDU만 선택하고 이미 수신한 중복 데이터를 인식할 수 있습니다. 이러한 조건 중 하나가 적용되면 옵저버는 보조 채널에서 보조 패킷을 스캔할 필요를 피할 수 있습니다.
AdvDataInfo 필드는 보조 채널에서 낭비되는 스캔을 방지하는 데 도움이 되지만 일부 시나리오에서는 충분히 정교하지 않은 메커니즘입니다.
4.2 의사 결정 기반 광고 필터링 정보
4.2.1 개요
DBAF는 비공식적으로 의사 결정 PDU라고 하는 새로운 유형의 확장 광고 PDU인 ADV_DECISION_IND를 도입합니다. 이 PDU 유형은 ADV_EXT_IND 확장 광고 PDU 대신 사용할 수 있으며 기본 채널에서 유사하게 전송됩니다.
결정 PDU에는 스캐너가 관련 AUX_ADV_IND 보조 패킷이 관심 대상인지 여부, 따라서 AuxPtr 필드에 참조된 보조 채널에서 스캔을 시작할지 여부에 대해 더 나은 정보에 입각한 결정을 내리기 위해 평가할 수 있는 애플리케이션 지정 데이터가 포함되어 있습니다.
광고 디바이스는 관련 디바이스가 수신된 패킷이 관련성이 있는지 여부를 쉽게 확인할 수 있도록 결정 PDU의 콘텐츠를 구성할 수 있습니다.
스캔 장치는 수신된 결정 PDU의 콘텐츠에 대해 일련의 논리적 검사를 적용하여 관련 패킷을 안정적으로 식별하고 애플리케이션 페이로드 데이터를 얻기 위해 관련 보조 패킷을 스캔할 수 있도록 필터 정책을 구성할 수 있습니다.
4.2.2 혜택
DBAF의 장점은 수신 패킷에 대한 컨트롤러의 필터링을 애플리케이션이 보다 정교하게 제어할 수 있다는 데서 비롯됩니다. 애플리케이션이 지정한 필터링 검사를 통과하지 못한 결정 PDU는 폐기되고 보조 패킷에 대한 스캔이 수행되지 않으므로 방해가 발생하지 않습니다.
ADV_EXT_IND 확장 광고 PDU 대신 결정 PDU를 사용하면 유효 듀티 사이클을 크게 개선하고 방해 요소로 인해 기본 채널에서 패킷이 누락되는 현상을 줄일 수 있습니다. 이는 확장 광고를 사용하는 광고 디바이스가 많은 환경에서 특히 두드러지게 나타납니다.
확장 광고가 데이터 전송의 기본 매개체(예: 메시징 전송)로 사용되는 경우, 방해 요소로 작용할 수 있는 전송이 있어도 데이터 처리 속도가 저하되지 않습니다.
4.2.3 기술적 주요 사항
4.2.3.1 광고
4.2.3.1.1 결정 PDU
공식적으로 ADV_DECISION_IND PDU로 알려진 결정 PDU는 LE 1M 또는 LE 코딩된 PHY에서 링크 레이어 패킷으로 전송됩니다. 그림 12는 ADV_DECISION_IND PDU의 구조와 LE 1M(비코딩) PHY를 통해 링크 계층 패킷 내에 수용되는 방식을 보여줍니다.
그림 12 - LE 언코딩된 링크 레이어 패킷 및 ADV_DECISION_IND PDU
AdvMode 및 확장 헤더 필드는 모든 확장 광고 PDU에 표시됩니다. AdvMode는 광고 이벤트 유형 또는 정의된 세 가지 값을 나타냅니다.
AdvMode |
Mode |
---|---|
0b00 |
Non-connectable and non-scannable |
0b01 |
Connectable and non-scannable |
0b10 |
Non-connectable and scannable |
0b11 |
Reserved for future use |
확장 헤더 필드에는 PDU 유형, 광고 모드, PHY 및 애플리케이션 기본 설정과 같은 요소에 따라 포함 여부가 달라지는 다양한 표준 필드가 포함되어 있습니다. 중복 데이터를 식별하는 데 사용되는 DID가 포함된 ADI(AdvDataInfo) 필드는 확장 헤더 필드입니다.
AuxPtr은 결정 PDU에 포함되어야 하는 유일한 확장 헤더 필드입니다.
의사 결정 PDU와 관련된 필드는 의사 결정 유형 플래그 필드와 의사 결정 데이터 필드입니다.
스캐닝 장치는 수신된 결정 PDU에 대해 수행할 검사를 지정할 수 있으며 이러한 검사에는 확장 헤더의 필드, 신호 강도(RSSI) 또는 광고 장치가 결정 데이터 필드에 제공하는 특정 유형의 보충 데이터가 포함될 수 있습니다.
결정 데이터에는 현재 하나만 지정된 표준 하위 필드가 포함되어 있습니다. 이것은 확인 가능한 태그 필드입니다. 다른 하위 필드는 향후에 정의될 수 있습니다. 해결 가능한 태그와 같은 표준 하위 필드에서 사용하지 않는 공간은 추가적인 임의의 데이터에 사용될 수 있습니다.
결정 유형 플래그 필드는 결정 데이터 필드에 어떤 하위 필드가 있는지를 나타냅니다. 설정된 비트는 Bluetooth 핵심 사양에서 해당 필드 내의 비트 위치와 연결된 하위 필드의 존재를 나타냅니다. 0번 위치의 비트는 확인 가능한 태그 하위 필드와 관련이 있습니다. 다른 모든 비트는 향후 사용을 위해 예약되어 있습니다(RFU).
4.2.3.1.2 결정 PDU 구성하기
광고주의 호스트는 결정 PDU를 사용하여 광고를 구성하고 시작할 책임이 있습니다.
결정 유형 플래그 및 결정 데이터 필드에 대한 값은 호스트가 제공해야 합니다. 이 작업은 HCI 명령인 LE Set Decision Data를 사용하여 수행합니다. 이 명령의 매개 변수는 광고 세트를 식별하는 광고 핸들, 의사 결정 유형 플래그, 의사 결정 데이터 길이 및 의사 결정 데이터입니다. 이 명령은 광고 세트가 생성된 후 광고가 시작된 후를 포함하여 언제든지 호출할 수 있습니다. 즉, 애플리케이션 계층은 필요할 때마다 의사 결정 데이터 필드를 변경할 수 있습니다.
HCI 명령인 LE Set Extended Advertising Parameters는 광고 간격 등 광고 세트의 기본 변수를 구성하는 데 사용됩니다. 이 명령의 매개 변수 중 하나인 Advertising_Event_Properties는 구성 중인 광고 세트와 관련된 다양한 호스트 요구 사항을 나타내는 비트 마스크입니다. 예를 들어, 비트 0이 설정되어 있으면 호스트가 컨트롤러에 연결 가능한 광고 모드를 사용해야 함을 의미합니다. 비트 1이 설정되어 있으면 광고를 스캔할 수 있어야 합니다.
광고 이벤트 속성 파라미터 정의가 업데이트되어 비트 7, 8, 9를 의사 결정 PDU와 함께 사용할 수 있습니다. 표 5에는 이러한 비트의 의미가 요약되어 있습니다.
Bit |
Meaning |
---|---|
7 |
Use decision PDUs when advertising |
8 |
Include AdvA in the extended header of all decision PDUs |
9 |
Include ADI in the extended header of all decision PDUs |
표 5 - 광고 이벤트 속성 및 의사 결정 PDU
표시된 바와 같이, 호스트는 광고 이벤트 속성 비트 7을 사용하여 컨트롤러에 관련 광고 이벤트에서 의사 결정 PDU를 전송하도록 지시할 수 있습니다. 스캐닝 디바이스의 컨트롤러가 사용하도록 지정할 수 있는 결정 PDU 검사의 정교함으로 인해 광고주의 디바이스 주소 및/또는 ADI 필드가 불필요할 수 있으며 비트 8과 9를 사용하면 둘 중 하나 또는 모두를 제외할 수 있어 패킷이 8옥텟, 방송 시간이 LE 1M에서 64µs 단축될 가능성이 있습니다.
4.2.3.2 스캔
4.2.3.2.1 결정 검색 필터 정책 모드
스캔 디바이스의 애플리케이션이 의사 결정 기반 광고 필터링을 사용하려면 Bluetooth 컨트롤러에 이를 표시해야 합니다. 이는 HCI LE 설정 확장 스캔 파라미터 명령과 스캔 필터 정책 파라미터의 비트 2 및 3을 사용하여 수행됩니다.
이 비트를 사용하여 세 가지 모드 중 하나를 선택할 수 있습니다.
Value |
Meaning |
---|---|
0b00 |
No decisions mode. In this mode, decision PDUs are ignored. |
0b01 |
All-PDUs mode. All types of advertising PDU are selected. Decision PDUs are subject to checks specified by the host. Other advertising PDUs are subject to the basic filter policy. |
0b11 |
Decisions-only mode. Only decision PDUs are selected. These are subject to checks specified by the host. Those that pass are reported to the host in HCI advertising reports. Those that fail are discarded. |
4.2.3.2.2 결정 지침
스캔 장치의 애플리케이션은 LE 설정 결정 지침 명령을 사용하여 링크 계층이 필터 정책을 실행할 때 결정 PDU에 적용해야 하는 테스트를 지정합니다.
명령에 대한 세 가지 배열 매개변수를 통해 호스트가 테스트를 구성할 수 있습니다.
Parameter |
Meaning |
---|---|
Test_Flags[i] |
The first 4 bits of this field have defined meanings. Bit 0 – Creates partitioned groups of tests. See below. Bit 1 – The test passes if the decision data contains the relevant field and the check made against its value passes. Bit 2 – The test passes if the decision data contains the relevant field and the check made against its value fails. Bit 3 – The test passes if the decision data does not contains the relevant field.
The value in Test_Field[i] identifies the relevant field. Note that the term “relevant field” applies both to fields in the advertising PDU that may be used in decision checks and values which may be measured (e.g. RSSI) or otherwise calculated (e.g. path loss) and used in decision checks.
|
Test_Field[i] |
Identifies the decision data against which the check will be made. The data available for use in decision tests are:
|
Test_Parameters[i] |
Values to use in checks against the relevant field. The format of this field depends on the relevant field identified in the Test_Field[i] parameter. |
4.2.3.2.3 테스트 그룹
세 개의 매개변수 배열 Test_Flags, Test_Field 및 Test_Parameters로 표시되는 테스트 배열은 하나 이상의 테스트 그룹으로 분할됩니다.
Test_Flags[0], Test_field[0] 및 Test_Parameters[0]로 표시되는 첫 번째 테스트는 첫 번째 테스트 그룹의 회원, 회원사 입니다. 배열의 테스트를 반복할 때 Test_Flags[i]의 첫 번째 비트가 설정되어 있으면 새 테스트 그룹의 회원, 회원사 입니다. 설정되지 않은 경우 인덱스 값 [i - 1]로 참조되는 배열의 이전 테스트와 동일한 그룹의 회원, 회원사 입니다. 표 1에 예시가 나와 있습니다.
Index |
Test Flags |
Group Membership |
---|---|---|
0 |
0b0011 |
Start of a new group (bit 0 = 1). |
1 |
0b0010 |
Test is a member of same group as test[0]. |
2 |
0b0011 |
Start of a new group (bit 0 = 1). |
3 |
0b0100 |
Test is a member of same group as test[2]. |
4 |
0b0010 |
Test is a member of same group as test[2]. |
표 6 - Test_Flags 비트 0으로 제어되는 회원 자격 그룹을 보여주는 예제
같은 그룹에 속한 시험 중 하나라도 불합격하면 그룹의 모든 시험이 불합격으로 간주됩니다.
4.2.3.2.4 테스트 평가
다음 설명에서 테스트는 Test_Flags, Test_Field 및 Test_Parameters 매개변수 배열의 병렬 요소에 인코딩된 조건입니다. 검사는 특정 결정 PDU에서 획득하거나 파생된 특정 값을 사용하여 테스트를 평가하는 것을 의미합니다.
링크 계층은 수신된 각 결정 PDU에 대해 다음과 같이 DBAF 테스트를 평가합니다:
호스트가 지정한 각 테스트에 대해 먼저 관련 필드의 가용성을 확인합니다. 이는 수신된 PDU에 필드가 있는지 또는 테스트에 사용할 지정된 값을 계산하거나 측정할 수 있는지를 의미할 수 있습니다. Test_Flags[i]의 비트 3은 필수 필드가 없는 경우 테스트의 합격 또는 불합격 여부를 나타냅니다.
관련 필드가 있는 경우 Test_Field[i] 및 Test_Parameters[i]에 인코딩된 검사가 평가됩니다. 비트 1과 2는 검사 합격 또는 불합격 여부를 결정하는 데 사용되며, 이는 검사가 수행된 테스트가 합격 또는 불합격임을 의미합니다.
그룹을 사용하면 그룹의 각 테스트가 논리 AND를 사용하여 같은 그룹의 다른 테스트와 연관된 복합 조건을 지정할 수 있습니다. 즉, 그룹에 속한 모든 테스트가 통과해야 그룹 전체가 통과한 것으로 간주됩니다.
(group 1 test 1) AND (group 1 test 2) AND (group 1 test 3) |
표 7 - 동일한 그룹에 속한 테스트 간의 논리적 관계
전체 테스트 지침의 맥락에서 하나 이상의 테스트 그룹이 통과하면 전체 테스트 세트가 통과한 것으로 간주됩니다. 즉, 각 그룹은 논리적 OR로 다른 그룹과 연관되어 있습니다.
(group 1) OR (group 2) OR (group 3) OR (group 4) |
의사 결정 PDU의 필드 또는 여기서 파생된 값을 기반으로 개별 조건 검사를 공식화하는 기능과 일련의 테스트 그룹을 기반으로 더 복잡한 복합 조건을 인코딩하는 기능이 결합되어 DBAF는 애플리케이션을 위한 강력한 필터링 메커니즘이 됩니다.
4.2.3.2.5 관련 필드와 작업하기
검사가 수행되는 정확한 방법과 Test_Parameters[i] 항목의 콘텐츠 형식은 Test_Field[i]로 표시되는 관련 필드에 따라 다릅니다. Bluetooth 핵심 사양에는 관련 필드의 각 유형에 대한 형식 및 규칙에 대한 자세한 내용이 요약되어 있습니다.
해결 가능한 태그
Test_Parameters[i] |
PDU Data |
Check |
---|---|---|
A 128-bit key value. |
Decision Data contains a hash value and a pseudo random number (prand). |
Check passes if hash value equals the value obtained by evaluating ah (key, prand). ah is a hashing function defined in the core specification. |
AdvMode
Test_Parameters[i] |
PDU Data |
Check |
---|---|---|
A 3-bit Event Type value. The three bits act as flags that map to the three possible values of the AdvMode field. |
AdvMode is included in the decision PDU. |
Check passes if AdvMode is any of the values indicated by an EventType flag as accepted. |
RSSI
Test_Parameters[i] |
PDU Data |
Check |
---|---|---|
A range of RSSI values expressed as a minimum and a maximum in dBm. |
Measured by the controller for each received packet. |
Check passes if the measured RSSI falls within the range specified in the test. |
경로 손실
Test_Parameters[i] |
PDU Data |
Check |
---|---|---|
A range of path loss values expressed as a minimum and a maximum in dBm.
|
Calculated by the controller as the difference between the TX Power field in the received PDU and the RSSI for that packet. |
Check passes if the calculated path loss falls within the range specified in the test. |
AdvA
Test_Parameters[i] |
PDU Data |
Check |
---|---|---|
Contains a field called Check that indicates how to check the AdvA address field in the received decision PDU and zero, one or two test address values and types.
|
AdvA is a field which may be included in decision PDUs. |
Depending on the Check parameter field, evaluation of the check will pass if either: 1. AdvA in the PDU is in the controller’s Filter Accept List. 2. AdvA in the PDU matches the first of two possible addresses in the Test_Parameters[i] field. 3. AdvA in the PDU matches either of the two addresses in the Test_Parameters[i] field. |
임의 데이터
Test_Parameters[i] |
PDU Data |
Check |
---|---|---|
Contains an 8-octet Mask and an 8-octet Target value.
|
The decision PDU Decision Data field contains an Arbitrary Data subfield. |
The controller performs a bitwise AND of the Mask and the Arbitrary Data value (zero-padded if necessary). If the result matches the Target parameter, the check passes. |
공급업체별
Test_Parameters[i] 값과 테스트에 적용된 조건부 논리의 해석은 정의에 따라 공급업체별로 다릅니다.
4.2.3.2.6 확인 가능한 태그 및 키 공유
확인 가능한 태그는 특정 애플리케이션 및 디바이스와 관련된 PDU에 라벨을 붙이는 간단한 방법을 제공합니다. 이 시스템이 작동하려면 해시 생성 및 확인에 사용되는 키 값을 적절한 장치 간에 공유해야 합니다. 이를 위한 메커니즘과 절차는 향후 GATT 속성 및 프로필 사양에서 정의될 예정입니다.
4.2.3.3 시작하기
호스트는 컨트롤러의 시작 필터 정책이 지원되는 여러 가지 방식으로 작동하도록 구성하며, 그 중 일부는 결정 PDU를 포함합니다. 결정 PDU가 정책에 포함된 경우, 결정 지침의 적용 측면에서 수신된 PDU의 처리는 스캔 상태일 때와 동일합니다.
5. 광고주 모니터링
5.1 배경
이 섹션에서는 광고주 모니터링 기능과 관련된 Bluetooth LE 기술의 측면에 대해 설명합니다.
5.1.1 장치 검색
Bluetooth LE에서 광고의 목적 중 하나는 디바이스 검색을 용이하게 하는 것입니다. 디바이스는 간격을 두고 작은 데이터 패킷을 브로드캐스팅하여 자신의 존재 범위 내에 있는 다른 디바이스에 알립니다. 동시에 디바이스는 다른 디바이스로부터의 연결을 수락할 의향이 있고 수락할 수 있음을 나타낼 수도 있습니다.
다른 디바이스 검색은 스캔을 통해 이루어집니다. 스캐닝은 일정 간격으로 일정 시간 동안 디바이스의 라디오를 수신 모드로 전환하여 기본 Bluetooth LE 채널에서 전송을 수신 대기합니다. 광고 디바이스가 스캐닝 디바이스가 수신 대기 중인 채널에서 패킷을 브로드캐스트하면 스캐닝 디바이스가 패킷을 수신하고 광고 디바이스를 발견했다고 할 수 있습니다.
디바이스 검색 목적의 광고는 Bluetooth LE 기술의 기본 아이디어입니다.
그림 14 - 광고 및 스캔
5.1.2 연결
광고 디바이스를 발견한 다음 단계는 스캔 디바이스가 목록에서 디바이스를 선택하는 등 사용자가 취한 조치에 대한 응답으로 광고 디바이스에 연결을 시도하는 것이 일반적입니다.
연결은 ADV_IND PDU와 같은 레거시 광고 PDU에 대한 응답으로 CONNECT_IND PDU를 보내거나 AUX_ADV_IND 확장 광고 PDU에 대한 응답으로 AUX_CONNECT_REQ PDU를 보내면 이루어집니다. 두 경우 모두 연결 요청은 응답하는 PDU와 동일한 채널로 전송됩니다.
연결 요청에 대한 응답으로 전송할 수 있는 PDU를 수신하려면 연결 장치가 먼저 스캔해야 합니다. 종종 연결이 빠르게 설정되는 것이 바람직하며 이를 위해 높은 듀티 사이클 스캔이 사용됩니다. 여기에는 원하는 연결 가능한 광고 패킷 중 하나를 최대한 빨리 수신할 확률을 최대화하기 위해 라디오가 켜져 있고 수신기 모드에서 높은 비율의 시간을 보내는 것이 포함됩니다. 일반적으로 스캐닝은 상대적으로 전력을 많이 소모하는 작업이며 듀티 사이클이 높은 스캐닝은 더욱 그렇습니다.
5.1.3 범위
스캐닝 디바이스는 광고 디바이스로부터 패킷을 수신하고 두 디바이스가 서로 범위 내에 있는 경우에만 응답할 수 있습니다. 범위는 전송 전력, 수신기 감도 및 환경의 특성과 같은 여러 가지 문제에 따라 달라집니다. 송신기로 작동하는 디바이스의 범위는 수신기로 작동하는 디바이스의 범위와 같지 않을 수 있습니다. 또한 통신이 이루어지는 다른 디바이스의 범위는 첫 번째 디바이스에서 표시된 범위와 다를 수 있습니다.
범위를 벗어났다고 해서 반드시 다른 디바이스에서 전송한 신호가 수신되지 않는다는 의미는 아닙니다. 한 디바이스가 다른 디바이스로부터 전송을 수신할 수 있지만 수신된 신호 강도와 배경 잡음의 비율(즉, 신호 대 잡음비 또는 SNR)이 수신기가 너무 높은 오류율 없이 전송에서 데이터를 추출할 수 없는 경우 두 디바이스는 범위를 벗어난 것으로 간주합니다.
3.1.1 위치 서비스 및 Bluetooth LE에 설명된 대로 RSSI는 거리에 대한 대략적인 프록시 역할을 하며 경로 손실 계산에 사용될 수 있습니다. 일부 애플리케이션의 경우, 다른 디바이스가 범위 내에 있고 충분히 가까운 경우에만 다른 디바이스에 연결하는 것이 의미가 있습니다. 사용 사례가 이 평가의 핵심이 될 수 있습니다. 사용자가 다른 디바이스와 아주 가까이 있을 때만 연결하는 것이 합리적일 수도 있습니다. 따라서 애플리케이션이 다른 디바이스에 연결할 수 있을 만큼 충분히 가까워졌다고 판단하기 전에 RSSI를 정기적으로 측정하고 평가하는 경우도 있습니다.
5.1.4 중복 필터링
광고 패킷은 링크 계층이 스캐닝 상태에 있을 때 Bluetooth LE 컨트롤러의 링크 계층에서 수신합니다. 광고 디바이스는 구성된 시간 간격으로 패킷을 반복적으로 전송합니다. 디바이스 검색 목적으로 사용되는 경우 광고 패킷의 콘텐츠는 시간이 지나도 변경되지 않는 경향이 있습니다.
컨트롤러가 하나 이상의 디바이스로부터 수신한 광고 패킷의 데이터는 HCI 이벤트에서 호스트에게 전달됩니다. 호스트에 대한 광고 데이터 보고를 위해 몇 가지 HCI 이벤트 유형이 정의되어 있으며, 사용되는 이벤트 유형은 관련된 광고 유형에 따라 다릅니다. 예를 들어 레거시 광고의 경우 LE 광고 보고서 이벤트가 사용됩니다. 확장 광고의 경우 LE 확장 광고 보고서 이벤트가 사용됩니다. 정기 광고가 사용 중인 경우 LE 정기 광고 보고서 이벤트가 사용됩니다.
특히 환경에 있는 여러 디바이스에서 발생하는 광고는 내부 전송을 통해 컨트롤러에서 호스트로 전달되는 수많은 HCI 광고 보고서를 생성할 수 있습니다. API를 사용하여 광고 데이터 수신을 등록한 애플리케이션은 많은 콜백을 수신하지만 이러한 콜백에서 전달되는 데이터가 변경되지 않아 가치가 의심스러울 수 있습니다.
하지만 동일한 디바이스로부터 변하지 않는 광고 패킷을 반복적으로 수신하는 것은 어느 정도 가치가 있습니다. 이를 통해 스캐닝 디바이스는 다른 디바이스가 현재 범위 내에 있는지 여부를 추적할 수 있습니다.
다행히도 호스트가 스캔을 활성화할 수 있는 HCI 명령(LE Set Scan Enable 및 LE Set Extended Scan Enable)에는 각각 Filter_Duplicates라는 매개 변수가 있습니다. 이를 통해 호스트는 중복 광고 보고서를 컨트롤러에 알릴지 여부를 지정할 수 있습니다.
그림 16은 중복 필터링이 활성화되지 않은 상태에서 호스트에서 스캔을 활성화하는 모습을 보여줍니다.
그림 17은 중복 필터링이 켜진 상태에서 스캔이 활성화된 경우를 보여줍니다. 첫 번째 광고 패킷만 수신되어 광고 보고서가 호스트에게 전송되는 것을 확인할 수 있습니다.
필터_중복 옵션은 모든 디바이스의 모든 광고 패킷에 적용되며, 다른 디바이스의 모든 광고 패킷을 필터링하지 않은 채 특정 디바이스에만 적용할 수 있는 방법은 없습니다.
따라서 애플리케이션에는 선택권이 있습니다. 첫 번째 옵션은 모든 광고 보고서를 수신하고 다른 디바이스가 범위 내에 있는지 여부를 최신 상태로 인식하는 것이지만, 이로 인해 많은 HCI 트래픽과 애플리케이션 코드에 대한 콜백이 발생할 수 있다는 점을 감수하는 것입니다. 다른 방법은 중복 광고 보고서의 보고를 억제하되 관심 디바이스가 범위 내에 계속 있는지 여부는 즉시 추적하지 않는 것입니다. 이 두 가지 옵션은 모두 이상적이지 않습니다.
5.1.5 Bluetooth LE 오디오 및 수락기 가용성
CAP(공통 오디오 프로파일)의 용어로, 수락자는 다른 디바이스로부터 오디오 스트림을 수락할 수 있는 디바이스이며, 이니시에이터로 알려져 있습니다. 초기자는 필터 수락 목록( 4.1.2 필터 정책 참조)을 사용하지 않는 것이 좋습니다(초기자가 본딩된 디바이스의 주소로 채워지는 경우가 많으므로). 개인용 오디오 디바이스는 본딩되었을 가능성이 높지만, LE 오디오는 단순한 개인용 오디오 그 이상입니다.
최적의 사용자 경험을 위해 오디오 스트림을 설정해야 할 때는 가능한 한 지연 시간이 짧아야 합니다. 따라서 후보 수락자가 범위 내에 있는지 여부를 추적하는 것이 바람직합니다. 오디오 장치가 아직 범위 내에 있는지 확인하기 위해 다시 스캔한 다음 연결하는 것은 지연 시간과 사용자 경험에 악영향을 미치는 시간 및 에너지 낭비입니다.
LE 오디오 사용 사례는 광고주 모니터링 기능의 설계에 영향을 준 주요 시나리오 중 하나였습니다.
5.2 광고주 모니터링 정보
5.2.1 개요
필터_중복 매개변수를 사용하여 호스트에 이미 보고된 광고 패킷과 동일한 광고 패킷의 보고를 억제하면 호스트는 연결 시점에 광고 디바이스가 여전히 범위 내에 있는지 여부를 확신할 수 없습니다. 연결하기 전에 일반적으로 고비용의 높은 듀티 사이클 스캔이 선행되며, 대상 디바이스가 더 이상 범위 내에 있지 않다면 이 활동은 완전히 에너지 낭비일 것입니다. 광고주 모니터링 기능은 이 문제를 해결합니다.
광고주 모니터링 기능을 사용하면 호스트는 컨트롤러에 하나 이상의 광고 디바이스의 존재를 계속 추적하도록 지시합니다. 광고 모니터링은 수신된 광고 패킷당 광고 보고서로 호스트에 부담을 주는 대신 모니터링되는 디바이스가 범위를 벗어날 때 호스트에게 한 번, 범위 내에 다시 들어오면 다시 한 번 알려줍니다. 이를 통해 애플리케이션이 연결하려는 디바이스를 추적할 수 있는 효율적인 방법을 제공합니다. 또한 애플리케이션의 신호 강도 요구 사항도 고려합니다.
애플리케이션이 모니터링 대상 디바이스 중 하나에 연결하기로 결정한 경우, 디바이스가 범위 내에 있다는 알림을 받으면 연결에 앞서 수행하는 스캔 작업이 낭비될 가능성이 낮습니다. 대상 디바이스가 존재하고 범위 내에 있어야 스캔을 통해 연결 요청에 대한 응답으로 전송할 수 있는 광고 패킷을 생성할 수 있습니다.
광고주 모니터링은 필터 허용 목록( 4.1.2 필터 정책 참조)과 독립적으로 작동하므로 보세 디바이스에 대해서만 필터 허용 목록을 사용하고 스캔 디바이스의 보세 여부와 관계없이 일반적으로 모든 디바이스에 대해 광고주 모니터링을 쉽게 사용할 수 있습니다.
에너지 효율성 향상과 사용자 경험 개선을 통해 광고주 모니터링 기능의 혜택을 받을 수 있는 상황과 제품 유형은 다양합니다. 오디오 스트림을 시작하는 LE 오디오 디바이스(CAP 이니시에이터)는 이 기능이 정의된 제품 범주 중 하나입니다.
5.2.2 기술적 주요 사항
5.2.2.1 모니터링되는 광고주 목록
Bluetooth 핵심 사양은 모니터링되는 광고주 목록을 정의합니다. 이는 호스트가 추적하고자 하는 광고 디바이스 목록을 포함하는 컨트롤러의 데이터 구조입니다.
목록의 각 디바이스에는 여러 매개변수가 수반되며 각 항목에는 연결된 타이머가 있는 것으로 생각할 수 있습니다. 또한 각 항목에는 구현에 의해 유지되는 Awaiting RSSI High라는 상태가 있습니다. 이 상태는 모니터링되는 디바이스가 범위 내에 있는지 여부를 나타냅니다. Awaiting RSSI High가 참이면 장치가 범위 내에 있지 않은 것입니다.
모니터링되는 광고주 목록의 매개변수를 이해하면 관리자의 모니터링이 어떻게 작동하는지 이해할 수 있습니다.
Parameter(s) |
Description |
---|---|
Address and Address Type |
The address and address type of the device to be monitored. These two parameters allow the controller to identify and monitor the device.
|
RSSI Threshold Low |
If the RSSI of all advertising packets from this monitored device stays at or below this value for the period of time indicated by the Time Out parameter then it is said that a loss-of-signal has occurred. When this happens, the controller notifies the host using an HCI LE Monitor Advertisers Report event. The state of this device set to Awaiting RSSI High.
|
RSSI Threshold High |
If the RSSI of an advertising packet received from this monitored device is greater than or equal to this value, and the device state is Awaiting RSSI High then the controller sends a HCI LE Monitor Advertisers Report event to the host to inform it that the device is in range. The state for this device is cleared or set to indicate that it is no longer awaiting an RSSI above the high threshold and the timer that is used to monitor for loss of signal is reset.
|
Time Out |
A time in seconds used to monitor for signal loss. If no RSSI measurement exceeds the RSSI Threshold Low parameter in this period then loss-of-signal is said to have occurred.
|
5.2.2.2 호스트 컨트롤러 인터페이스
호스트는 모니터링 광고주 목록을 구성하고 호스트 컨트롤러 인터페이스(HCI)를 사용하여 모니터링되는 디바이스와 관련된 이벤트를 수신합니다. 세 개의 명령과 하나의 이벤트가 정의되어 있습니다.
HCI Command or Event |
Description |
---|---|
LE Monitored Advertisers List command |
Used by the host to add or remove an entry from the Monitored Advertisers List or to clear the list completely. An array of one or more devices to be monitored plus their associated RSSI thresholds and timeout parameter are provided in this command.
|
LE Monitored Advertisers Enable command |
Allows the host to enable or disable advertiser monitoring in the controller.
|
LE Read Monitored Advertisers List Size command |
Allows the host to determine the total number of entries the controller can currently accommodate in its Monitored Advertisers list. Note that this value may change at any time.
|
LE Monitored Advertisers Report event |
Generated by the controller whenever for a monitored device there is a loss-of-signal or the device comes back into range. The Condition parameter indicates which of these two conditions is responsible for the event having been generated.
|
5.2.2.3 예제
그림 18은 광고주 모니터링이 실제로 작동하는 모습을 보여줍니다. 그림의 왼쪽 절반에는 메시지 시퀀스 차트가 포함되어 있습니다. 광고 디바이스는 전체 개체로 표시되어 있고 스캐닝 디바이스는 컨트롤러와 호스트 부분으로 나누어 두 부분 간의 HCI 통신을 볼 수 있도록 표시되어 있습니다.
다이어그램의 오른쪽 절반에는 RSSI 값, 설정된 낮음 및 높음 RSSI 임계값, 타이머 및 RSSI 높음 대기 중 상태 정보가 표시됩니다.
시간은 다이어그램의 위쪽에서 아래쪽으로 흐릅니다. 관심 지점은 왼쪽 타임라인에 알파벳순으로 레이블이 지정되어 있습니다. 표 8에 요약되어 있습니다.
Point |
|
---|---|
A |
The scanner’s host starts by asking the controller how many advertising devices it can monitor. The host then adds a device to the list along with RSSI low, RSSI high and timeout values (not shown). Finally, the host tells the controller to enable advertiser monitoring. |
B |
At this point the illustration starts to show advertising packets transmitted by the first device. Note that the device could have been advertising prior to this point but the packets are only shown from here. Received packets have an RSSI that is greater than the configured low threshold and so the timer for the monitored device is reset as each packet is received. |
C |
The next few packets received after point C have an RSSI that is lower than the low RSSI threshold and so it is at point C that the timer is last reset and the timer runs from that point. |
D |
A series of low RSSI packets are now received and at point D, a timeout occurs. The controller indicates the loss of signal condition to the host by sending a LE Monitor Advertisers Report event with condition == 0x00. The device is now in the Awaiting High RSSI state in the monitoring advertisers list. |
E |
At point E, the first of a series of packets whose RSSI is above the low threshold is received. For each such packet, the timer is reset. |
F |
At point F, the RSSI value exceeds the RSSI High threshold. The host is informed that the monitored device is back in range with a sufficiently strong signal via a LE Monitor Advertisers Report event with condition == 0x01 sent by the controller. The device is no longer in the Awaiting High RSSI state. |
표 8 - 광고주 모니터링 예시 - 관심 포인트
6. ISOAL 향상
6.1 배경
이 섹션에서는 Bluetooth LE 스택의 ISOAL(동시기 적응 계층)의 개선 사항과 관련된 Bluetooth LE 기술의 측면에 대해 설명합니다.
6.1.1 비동기 통신
Bluetooth LE 데이터 전송 아키텍처에는 LE CIS 및 LE BIS 논리적 전송이 포함되며, 여기서 CIS는 커넥티드 비동기 스트림, BIS는 브로드캐스트 비동기 스트림을 의미합니다. 이러한 논리적 전송은 LE 비동기 물리적 링크와 LE 비동기 물리적 채널에 의해 지원됩니다.
비동기 통신은 장치 간에 전송할 데이터가 시간 제한이 있는 경우에 사용됩니다. 즉, 수신자가 전송된 데이터를 처리할 때 반드시 준수해야 하는 시간과의 엄격한 관계가 존재합니다.
Bluetooth LE 오디오는 등시성 통신을 사용하므로 관련 데이터의 여러 스트림이 각각의 수신기에 의해 동시에 렌더링됩니다. 이를 좀 더 구체적으로 설명하자면, 예를 들어 왼쪽 스테레오 채널의 오디오 데이터와 오른쪽 스테레오 채널의 오디오 데이터가 오디오 소스 장치에서 서로 다른 시간에 전송될 수 있지만 두 개의 스테레오 채널에 대해 별도의 오디오 싱크 장치(예: 왼쪽 및 오른쪽 이어버드)에서 동시에 사용자가 예상하는 방식으로 렌더링된다는 의미입니다.
CIS는 등시성 통신에 대한 연결 지향적 접근 방식을 제공합니다. 예를 들어 CIS에는 일반적으로 스마트폰과 보청기 같은 소규모 장치 그룹이 포함됩니다. 하지만 통신은 양방향으로 이루어질 수 있으므로 보청기에는 마이크가 포함되어 오디오 소스뿐만 아니라 오디오 싱크 역할도 할 수 있습니다.
BIS는 등시성 데이터의 브로드캐스팅을 포함하며 오디오와 같은 등시성 데이터를 대규모 장치 그룹에 전달하기 위한 것입니다. 그러나 통신은 단방향입니다.
특히 오디오 데이터를 처리할 때 비동기식 통신에는 여러 가지 문제가 수반됩니다.
첫 번째는 완전히 독립적인 여러 장치에서 데이터 렌더링 (이 경우 오디오 재생)을 올바르게 동기화하는 것입니다. 이것이 바로 등시성 통신이 해결하도록 설계된 문제입니다.
지연 시간은 때때로 문제가 될 수도 있고 그렇지 않을 수도 있습니다. 사용자는 오디오 장치에서 예상되는 소리의 타이밍과 실제 경험하는 소리의 타이밍을 비교할 수 있는 다른 기준이 있는 경우에만 지연 시간을 인지할 수 있습니다. 예를 들어 보청기 사용자가 보청기로 전송되는 동일한 소리뿐만 아니라 주변 소리도 들을 수 있는 경우 지연 시간이 길면 사용자는 주변 소리와 증폭된 소리 사이에 지연이 있다고 인식하게 됩니다. Bluetooth 등시성 통신을 사용하면 이러한 장치의 요구 사항을 충족하는 데 도움이 되는 짧은 지연 시간 구성을 선택할 수 있습니다.
많은 오디오 시나리오에서 데이터 손실에 대한 허용 오차가 제한되어 있기 때문에 안정성이 중요합니다. CIS와 BIS 모두 안정성을 향상시키는 메커니즘을 포함하고 있습니다.
6.1.2 디지털 오디오
비동기식 통신은 오디오 애플리케이션 전용은 아니지만 원래 설계된 주요 용도입니다. 디지털 오디오 데이터가 생성되는 방식은 특정 문제를 야기하며, Bluetooth LE 스택의 ISOAL(비동기 적응 레이어)이라는 레이어가 이러한 문제를 해결합니다.
오디오는 샘플링이라는 과정을 통해 디지털 포맷으로 변환됩니다. 샘플링에는 일정한 간격으로 신호의 진폭을 측정하고 기록하는 작업이 포함되며, 이 과정에서 상당한 양의 데이터가 생성되는데, Bluetooth LE 오디오의 경우 궁극적으로 전송해야 하는 데이터입니다.
Bluetooth LE 오디오는 LC3라는 코덱을 사용합니다.[4] 라는 코덱을 사용하여 샘플 데이터에 압축 알고리즘을 적용하고 크기를 크게 줄입니다. 코덱은 일반적으로 일련의 연속된 샘플에서 발견되는 패턴을 인식하고 활용하는 방식으로 작동합니다. 따라서 코덱이 작동하려면 한 번에 분석할 일련의 샘플 전체가 필요합니다.
코덱이 한 번에 분석하는 샘플의 모음을 프레임이라고 합니다. 프레임은 일반적으로 밀리초 단위로 측정되는 고정된 지속 시간을 가지며, 샘플 레이트에 따라 결정되는 수의 샘플을 포함합니다. 예를 들어, 샘플 레이트가 44.1KHz인 경우 10ms 프레임에는 441개의 샘플이 포함됩니다.
6.1.3 ISOAL
6.1.3.1 Bluetooth 아키텍처의 ISOAL
디지털 오디오와 같은 데이터는 시스템의 애플리케이션 계층에서 생성됩니다. 이는 Bluetooth 스택의 호스트 부분에 존재하며 일반적으로 운영 체제(OS) 서비스 또는 OS에서 실행되는 사용자 애플리케이션입니다. Bluetooth 핵심 사양에서는 등시성 통신을 위한 데이터를 제공하는 계층을 간단히 상위 계층이라고 부릅니다.
Bluetooth 링크 계층은 등시성 논리 전송 중 하나를 사용하여 하나 이상의 다른 장치와 데이터를 통신합니다. 링크 계층은 일반적으로 시스템 온 칩인 Bluetooth 컨트롤러에서 구현됩니다.
ISOAL은 서비스 데이터 단위 (SDU)의 등시성 데이터를 ISOAL과 교환하고, ISOAL은 프로토콜 데이터 단위(PDU)를 링크 계층과 교환합니다. 그림 20은 Bluetooth 시스템의 이 세 부분 간의 관계를 보여줍니다.
호스트와 컨트롤러는 일반적으로 눈에 띄지 않는 독립적인 구성 요소이며 USB 또는 UART와 같은 지원되는 전송 중 하나를 통해 호스트 컨트롤러 인터페이스를 사용하여 서로 통신합니다.
6.1.3.2 ISOAL에서 다루는 문제
상위 계층의 데이터 생산자의 운영 매개변수와 링크 계층을 관리하는 매개변수 간의 차이로 인해 문제가 발생할 수 있는 두 가지 중요한 영역이 있습니다.
첫 번째는 상위 계층에서 생성되는 SDU의 크기와 관련이 있습니다. SDU는 링크 계층에서 지원하는 최대 크기 PDU보다 훨씬 큰 것이 일반적입니다.
ISOAL을 사용하면 상위 계층에서 링크 계층이 단일 PDU에서 처리할 수 있는 것보다 더 큰 SDU를 생성할 수 있습니다.
두 번째 문제는 타이밍에 관한 것입니다. 링크 계층에 의한 데이터 전송은 일정 간격으로 발생하는 이벤트에서 이루어집니다. 이 간격은 다양한 값을 취할 수 있으며 일반적으로 ISO 인터벌이라고 합니다. 프레임도 상위 계층에서 간격을 두고 생성되며 SDU로 스택을 통해 전달되는데, 여기서 SDU는 서비스 데이터 단위를 의미합니다. 상위 계층에서 SDU 생성을 관리하는 시간 간격을 SDU 인터벌이라고 합니다.
컨트롤러의 링크 계층에서 사용하는 ISO 간격은 호스트의 상위 계층에서 사용하는 SDU 간격과 동일하지 않은 경우가 많으며 두 간격 값은 서로 정수의 배수가 아닙니다. 또한 이 두 계층의 활동 간에 동기화가 이루어지지 않는 것이 일반적이며, 그 결과 데이터가 시스템을 통과할 때 대기 시간이 지연될 수 있습니다. 이벤트 중에 링크 계층에 전송할 상위 계층의 데이터가 없는 경우 null PDU가 전송된다는 점에 유의해야 합니다.
그림 21은 SDU와 PDU 제작이 동기화되지 않을 때의 영향을 보여줍니다.
그림 21 - 동기화되지 않은 SDU 및 PDU 프로덕션
전송되는 데이터는 시간에 강하게 묶여 있으며, 수신자는 이러한 시간 관계를 복원하고 데이터가 처리될 때 예상한 결과를 얻을 수 있어야 합니다. 이는 항상 문제가 되지만 상위 계층과 전송 간에 동기화가 이루어지지 않을 경우 더욱 복잡해집니다.
ISOAL을 사용하면 상위 계층의 SDU 생성 속도가 링크 계층의 등시성 PDU 전송 속도와 다를 수 있고 작동이 비동기화될 수 있습니다.
6.1.3.3 ISOAL 처리 경로
ISOAL을 통해 등시성 데이터가 취할 수 있는 경로는 두 가지가 있으며, 그림 22에서 서로 다른 색상으로 표시되어 있습니다.
SDU 간격이 ISO 간격의 정수 배수이고 상위 계층과 전송 계층의 동작이 동기화되면 프레임되지 않은 PDU가 조각화라는 프로세스를 통해 생성됩니다. 그렇지 않으면 프레임된 PDU가 생성되고 세그멘테이션이라는 프로세스가 적용됩니다.
6.1.3.4 비프레임 및 프레임 PDU
프레임되지 않은 PDU 경로를 사용하는 경우 링크 계층에서 허용하는 최대 PDU 크기보다 큰 SDU는 조각화라는 프로세스를 통해 더 작은 부분으로 분할됩니다. 헤더는 조각이 전체 SDU인지, SDU의 시작, 연속 또는 끝인지를 나타냅니다.
역방향으로는 링크 계층에서 수신한 더 작은 프레임되지 않은 PDU에서 SDU를 재조합합니다.
프레임된 PDU 경로를 사용하는 경우 세그멘테이션이라는 프로세스가 SDU에 적용됩니다. 세그멘테이션은 조각화와 마찬가지로 헤더를 사용하여 SDU를 작은 부분으로 분할하지만, SDU의 시작을 나타내는 헤더에는 타이밍 오프셋 정보도 포함되어 있어 수신자가 이 중요한 타이밍 정보를 재조립하고 유지할 수 있도록 합니다.
SDU는 조각화 또는 세분화 프로세스의 결과에 따라 하나 이상의 링크 계층 PDU로 전송됩니다.
6.1.3.5 프레이밍 모드
프레이밍 모드는 Bluetooth 핵심 사양에 정의되어 있습니다. 버전 6.0 이전에는 프레이밍 모드가 두 가지만 정의되어 있었는데, 각각 프레임 또는 언프레이밍 케이스에 해당합니다.
6.1.3.6 ISOAL 세분화 관련 문제
ISOAL 프레이밍 프로세스는 상위 계층에서 전달된 데이터의 두 가지 측면을 처리합니다. 이 프로세스는 더 큰 SDU를 더 작은 PDU로 분할하여 전송할 수 있게 하고, 데이터와 시간의 관계를 유지하여 재구성할 수 있도록 보장합니다.
세분화에는 애플리케이션에 따라 중요할 수도 있고 중요하지 않을 수도 있는 두 가지 문제가 있습니다.
첫 번째는 신뢰성에 관한 것입니다. 모든 무선 통신 시스템에는 패킷 손실 가능성이 항상 존재합니다. 예를 들어 오디오 데이터가 포함된 SDU가 여러 개의 PDU로 분할되어 해당 링크 계층 패킷을 통해 무선으로 전송되는 경우 이러한 패킷 중 하나 이상이 손실되어 SDU 전체가 손상될 확률이 높아집니다.
두 번째는 지연 시간에 관한 것입니다. 세그멘테이션이 적용되면 수신 디바이스의 상위 계층은 SDU의 모든 세그먼트를 수신할 때까지 기다렸다가 재조립하여 처리해야 합니다. 오디오의 경우, 이는 오디오 프레임을 다시 생성하고 LC3를 사용하여 디코딩하는 것을 의미합니다.[5] 코덱을 사용하여 오디오 프레임을 다시 생성하고 디코딩한 후 오디오 렌더링 단계로 넘어갑니다. 이 대기 시간은 지연 시간으로 이어집니다.
6.2 ISOAL 개선 사항 정보
비동기 적응 계층에는 비분할 프레임 모드라는 새로운 프레이밍 모드가 있습니다. 호스트는 HCI LE 설정 CIG 파라미터 명령 또는 LE 생성 BIG 명령의 프레이밍 파라미터에 0x02 값을 지정하여 이 모드를 선택할 수 있습니다.
비세분화 프레이밍 모드를 사용하면 프레임된 PDU를 사용하고 각 SDU의 타이밍 정보를 유지하면서 세그먼테이션을 적용하지 않아도 됩니다. 이 새로운 프레이밍 모드에는 두 가지 이점이 있습니다. 첫째, 세그멘테이션 프로세스로 인한 지연 시간이 제거됩니다. 둘째, 패킷 손실로 인한 SDU 손실 위험이 감소합니다.
6.2.1 지연 시간 단축
프레이밍 프로세스에서 세그먼테이션을 제거함으로써 각 링크 계층 패킷은 효과적으로 전체 SDU를 포함합니다. 이는 LE 오디오의 경우 전체 오디오 프레임에 해당하며 상위 계층은 수신된 오디오 데이터를 디코딩하고 처리하기 전에 일련의 패킷이 수신될 때까지 기다릴 필요가 없습니다.
6.2.2 신뢰성 향상
세분화가 적용되면 단일 SDU가 여러 패킷의 페이로드로 전송됩니다. 패킷 손실 확률이 일정하다고 가정할 때, SDU 전체를 전송하는 데 필요한 패킷이 많을수록 SDU의 하나 이상의 부분이 손실될 확률도 커집니다.
비세분화 프레이밍 모드를 사용하는 경우, 최대 PDU 크기는 항상 세분화할 필요 없이 전체 SDU를 포함하기에 충분합니다. 따라서 상위 계층의 SDU와 링크 계층이 전송하는 PDU 사이에는 일대일 관계가 존재합니다. 따라서 패킷 손실 위험은 세분화를 통해 각 SDU에 대해 여러 개의 PDU를 생성할 때와 같은 방식으로 증가하지 않습니다.
7. LL 확장 기능 세트
7.1 배경
링크 계층(LL)은 Bluetooth LE 스택의 복잡한 계층입니다. 기능으로 알려진 수많은 기능이 정의되어 있습니다.
기능에 대한 지원은 선택 사항인 경우가 많습니다. 기능을 사용하거나 이러한 기능 중 하나와 관련되거나 이에 의존하는 LL 절차에 참여하기 전에 장치는 자체 Bluetooth 컨트롤러와 원격 장치의 컨트롤러 모두에서 해당 기능이 지원되는지 여부를 확인해야 합니다. 이를 위해 Bluetooth 핵심 사양에서는 FeatureSet이라는 8옥텟 비트 마스크와 기능 교환 절차를 정의했습니다.
FeatureSet의 정의는 64비트 각각에 의미를 할당합니다. 비트 값이 1이면 관련 기능이 지원됨을 의미하고 값이 0이면 지원되지 않음을 의미합니다.
기능 교환 링크 레이어 제어 절차는 연결에서 중앙 장치에 의해 시작될 때 LL_FEATURE_REQ 및 LL_FEATURE_RSP PDU를 교환하는 것을 포함합니다. 주변 장치도 이 절차를 시작할 수 있지만, 중앙 장치가 LL_FEATURE_RSP로 응답하는 LL_PERIPHERAL_FEATURE_REQ PDU를 전송하는 방식으로 절차를 시작합니다. 이 세 가지 PDU 유형 모두 송신 장치에서 지원하는 기능을 나타내는 FeatureSet 비트 마스크를 포함합니다. 그림 23은 중앙 장치에 의해 시작된 기능 교환 링크 계층 제어 절차(여기서는 장치 A로 표시됨)를 보여줍니다.
시간이 지남에 따라 Bluetooth 은 점점 더 정교해지고 기능 목록이 늘어났습니다. FeatureSet 비트 마스크의 64비트는 더 이상 Bluetooth 핵심 사양 버전 6.0 및 해당 문서의 향후 버전에 정의된 광범위한 기능을 다루기에 충분하지 않습니다.
그림 24는 Bluetooth 핵심 사양 버전 5.4의 FeatureSet 필드에서 비트의 의미를 정의하는 표의 끝 부분을 보여줍니다. 여기서는 비트 번호 63만 할당되지 않았습니다.
그림 24 - Bluetooth 핵심 사양의 {아틀란타 버전 번호} 버전 기준의 FeatureSet 필드
7.2 LL 확장 기능 세트 정보
7.2.1 개요
LL 확장 기능 세트는 기능 세트 필드에 비트가 할당된 기능 이외의 추가 기능을 장치에서 지원하거나 지원하지 않는 것으로 표시할 수 있는 수단을 제공합니다. 이는 향후에도 Bluetooth 기술의 진화를 지원하기 위해 설계되었으며, 1984개의 지원 표시 비트를 수용할 수 있는 충분한 용량을 갖추고 있습니다.
7.2.2 기술적 주요 사항
LL 확장 기능 세트는 그 자체로 장치가 지원하거나 지원하지 않는 링크 계층 기능입니다. 이는 FeatureSet 필드에서 비트 번호 63의 값으로 표시됩니다.
FeatureSet 비트마스크가 확대되어 주소 지정이 가능한 페이지로 나뉩니다. 0페이지에는 처음 64비트가 포함되며, 이는 Bluetooth 핵심 사양 버전 6.0 이전의 필드 사양에 따라 정의됩니다. 그 다음에는 1부터 순차적으로 번호가 매겨진 10개의 페이지가 이어지며 각 페이지는 192비트(24옥텟) 크기입니다.
LL 확장 기능 세트 기능을 지원하는 장치는 기능 페이지 교환 절차를 사용하여 서로의 확장 기능 세트를 검색할 수 있습니다. 이 절차는 중앙 장치 또는 주변 장치에서 시작할 수 있습니다.
LL 확장 기능 세트와 함께 사용할 수 있도록 두 개의 새로운 HCI 명령과 새로운 HCI 이벤트가 정의되었습니다. 각각 LE 모든 로컬 지원 기능 읽기 명령, LE 모든 원격 기능 읽기 명령 및 LE 모든 원격 기능 읽기 완료 이벤트입니다.
LE 모든 원격 기능 읽기 명령을 호출하면 일련의 LL_FEATURE_EXT_REQ PDU가 전송되고, 원격 장치에서 LL_FEATURE_EXT_RSP PDU로 각각 응답합니다. 모든 원격 기능 세트 페이지가 검색되면 세부 정보가 LE Read All Remote Features Complete 이벤트를 통해 시작 호스트에 보고됩니다. 그림 25를 참조하십시오.
LL_FEATURE_EXT_REQ와 LL_FEATURE_EXT_RSP PDU는 모두 링크 계층 데이터 PDU CtrData 필드에 세 개의 필드가 있는 동일한 구조를 가집니다. 표 9는 이러한 PDU 유형의 필드를 보여줍니다.
CtrData |
||
---|---|---|
MaxPage (1 octet) |
PageNumber (1 octet) |
FeaturePage (24 octets) |
표 9 - LL_FEATURE_EXT_REQ 및 LL_FEATURE_EXT_RSP PDU의 콘텐츠
MaxPage 필드는 0이 아닌 비트가 있는 가장 높은 번호의 페이지를 나타내는 데 사용됩니다.
PageNumber 필드는 값이 요청되거나 보고되는 확장 기능 집합 내에서 24옥텟 페이지의 번호를 식별합니다.
FeaturePage에는 PageNumber로 식별되는 페이지에 포함된 192비트 값이 포함됩니다.
기능 페이지 교환 절차는 호스트가 시작하거나 링크 계층에서 자율적으로 시작할 수 있습니다. 호스트가 확장된 기능 세트 기능을 사용할 수 있도록 기존 HCI 명령 및 이벤트의 새 버전이 정의되었습니다.
8. 프레임 공간 업데이트
8.1 배경
이 섹션에서는 프레임 공간 업데이트 개선 사항과 관련된 Bluetooth LE 기술의 측면에 대해 설명합니다.
8.1.1 프레임 간 공간
링크 계층은 무선 인터페이스 프로토콜을 정의하며, 여기에는 프레임 간 공간(IFS)이라는 시간 간격의 정의가 포함됩니다.
IFS는 동일한 채널에서 전송되는 두 개의 연속 패킷 사이에 포함되어야 합니다. Bluetooth 핵심 사양 버전 6.0 이전에는 이 기간을 기호 식별자 T_IFS를 사용하여 참조했으며 고정 값은 150µs였습니다.
이벤트 또는 하위 이벤트에서 전송된 마지막 패킷의 종료와 다음 이벤트/서브 이벤트의 시작 사이에 존재해야 하는 최소 시간도 다양한 전송 유형에 대해 정의되어 있습니다.
8.1.2 연결된 상태
그림 9는 링크 레이어 상태 머신을 보여줍니다. 연결 상태에서는 두 가지 논리적 전송 유형이 작동할 수 있습니다. 비동기 연결 지향 논리적 전송(ACL)과 연결된 등시적 스트림(CIS)이 바로 그것입니다.
ACL 전송을 사용하면 중앙 역할을 하는 한 장치가 연결 이벤트 중에 주변 장치 역할을 하는 다른 단일 장치와 패킷을 교환할 수 있습니다.
그림 26은 Bluetooth 핵심 사양 버전 6.0 이전에 정의된 ACL 연결의 예를 보여 주며, 고정 값 T_IFS는 중앙에서 주변 장치로 또는 주변 장치에서 중앙으로 전송되는 동일한 연결 이벤트의 패킷 사이에 존재해야 하는 시간 간격을 정의합니다. 또한, 한 연결 이벤트의 종료와 다음 연결 이벤트의 시작 사이에는 최소 T_IFS의 기간이 있어야 합니다.
CIS는 패킷이 교환되는 동안 하위 이벤트 시스템을 사용합니다. 버전 6.0 이전에는 동일한 서브이벤트에서 패킷 간의 타이밍 간격도 그림 27과 같이 고정값 T_IFS로 정의되었습니다. 또한, 최소 서브이벤트 간격이라는 시간 간격이 정의되어 있는데, 이 간격은 T_MSS라는 심볼 이름을 가집니다. 하나의 CIS 서브이벤트 종료와 다음 서브이벤트 시작 사이에는 최소 T_MSS의 기간이 있어야 합니다. 버전 6.0 이전의 Bluetooth 핵심 사양에서 T_MSS는 T_IFS와 동일한 고정 150µs 값을 가졌습니다. CIS에는 CIS를 설정하고 CIS에 영향을 주는 링크 계층 제어 PDU를 교환하는 데 사용되는 관련 ACL 연결이 있다는 점에 유의해야 합니다.
그림 27 - 연결된 등시성 스트림(CIS)을 통해 교환되는 패킷
8.2 프레임 공간 업데이트 정보
8.2.1 개요
Bluetooth 핵심 사양 버전 6.0에서는 프레임 간격이 다음과 같이 변경되었습니다:
- ACL 연결 및 CIS에 적용되는 시간 간격에 5개의 고유한 기호 이름이 할당되었습니다.
- 값은 더 이상 150µs로 고정되지 않습니다.
- 5가지 프레임 간격 유형별 기본값은 150µs이지만 연결이 설정된 후 중앙 및 주변 장치에서 새로운 값을 협상할 수 있습니다.
프레임 간격 값은 기본값인 150µs보다 짧거나 길 수 있습니다.
이 변경 사항은 ACL 연결 및 연결된 등시 스트림에만 적용됩니다. 다른 전송 유형은 계속해서 150µs의 고정된 프레임 간 간격을 사용하며, 이는 이제 T_IFS_150이라는 심볼 이름으로 참조됩니다.
프레임 공간 값이 짧을수록 전체 처리량이 증가할 수 있습니다. 더 짧은 프레임 공간과 더 높은 데이터 처리율의 이점을 누릴 수 있는 애플리케이션의 예는 다음과 같습니다:
- 피트니스 트래커는 누적된 모든 데이터를 스마트폰이나 노트북과 같은 연결된 디바이스로 한 번에 전송해야 합니다.
- 펌웨어 업데이트.
- Bluetooth LE 오디오. 연결된 등시성 스트림을 통해 전송되는 오디오 패킷은 더 짧은 버스트로 더 빠르게 전송할 수 있습니다. 따라서 다른 디바이스와 충돌이 발생할 확률이 줄어듭니다.
- Wi-Fi와 같은 다른 용도로 무전기를 사용하는 디바이스는 이러한 활동에 더 많은 시간을 할애할 수 있습니다.
프레임 공간 값이 길면 상대적으로 처리 능력이 낮은 컨트롤러가 더 긴 패킷을 처리하는 데 더 많은 시간을 할애할 수 있어 이점이 있습니다.
8.2.2 기술적 주요 사항
8.2.2.1 간격 유형
ACL 연결에는 세 가지 간격 유형이 정의되어 있습니다. 표 10에는 ACL 연결에 대한 새로운 간격 유형이 요약되어 있습니다.
Spacing Type Symbolic Identifier |
Definition |
---|---|
T_IFS_ACL_CP |
The duration of the required spacing time which must exist from the end of a packet transmission by the Central device and the start of the following slot in the same connection event, which may potentially be used by the Peripheral.
|
T_IFS_ACL_PC |
The duration of the required spacing time from the end of a packet transmission by the Peripheral device in a connection and the start of the following slot to potentially be used by the Central in the same connection event.
|
T_IFS_END |
The minimum time to elapse between the end of a connection event and the start of the next one.
|
표 10 - ACL 연결을 위한 새로운 프레임 간격 유형 및 식별자
그림 28은 기호 식별자로 표시된 새로운 간격 유형과 함께 ACL 연결의 연결 이벤트 및 패킷 전송을 보여줍니다.
연결된 아이소크로닉스 스트림에는 두 가지 간격 유형이 정의되어 있습니다. 표 11에는 CIS의 새로운 간격 유형이 요약되어 있습니다.
Spacing Type Symbolic Identifier |
Definition |
---|---|
T_IFS_CIS |
The duration of the required spacing time from the end of a packet transmission by the Central device in a CIS and the start of the following transmission by the Peripheral.
|
T_MSS_CIS |
The minimum subevent space which is the minimum time that must elapse between the end of a packet transmitted in one subevent and the start of the next subevent.
|
표 11 - CIS의 새로운 프레임 간격 유형 및 식별자
그림 29는 연결된 등시적 스트림의 하위 이벤트와 패킷 전송을 기호 식별자로 표시된 새로운 간격 유형으로 보여줍니다.
그림 29 - 연결된 등시성 스트림(CIS)의 새로운 프레임 간격 유형
컨트롤러는 Bluetooth LE PHY(LE 1M, LE 2M 및 LE 코딩)에 따라 각 간격 유형에 대해 고유한 값을 사용하도록 구성할 수 있습니다.
모든 경우에 간격 매개변수의 기본값은 150µs이며 간격 매개변수를 설정할 수 있는 허용되는 값 범위는 0~10,000µs입니다.
모든 경우에 ±2µs의 오차가 허용됩니다.
8.2.2.2 프레임 공간 업데이트
링크 계층 사양은 프레임 공간 업데이트 프로시저라는 새로운 프로시저를 정의합니다. 이 절차를 사용하여 디바이스는 지원되는 일부 또는 모든 PHY에 대해 적용 가능한 각 간격 유형에 대한 값을 협상할 수 있습니다.
중앙 장치 또는 주변 장치 중 하나가 프레임 공간 업데이트 절차를 시작할 수 있습니다. 이 절차는 연결을 통해 LL_FRAME_SPACE_REQ를 전송하여 수행됩니다. 이에 대한 응답으로 다른 디바이스는 LL_FRAME_SPACE_RSP PDU를 보내야 합니다.
LL_FRAME_SPACE_REQ PDU에는 다음 필드가 포함됩니다:
Field |
Meaning |
---|---|
FS_MIN |
The minimum requested frame spacing in microseconds. |
FS_MAX |
The maximum requested frame spacing in microseconds. |
PHYs |
A single octet bit mask where bit 0 indicates the LE 1M PHY, bit 1 indicates the LE 2M PHY and bit 2 indicates the LE Coded PHY. One or more of these bits may be set to indicate the PHYs for which the frame spacing update is being requested.
|
Spacing Type |
A 2-octet bit mask which indicates the spacing parameters for which new values are being requested. Bit 0 indicates T_IFS_ACL_CP, bit 1 indicates T_IFS_ACL_PC, bit 2 indicates T_IFS_END, bit 3 indicates T_IFS_CIS and bit 4 indicates T_MSS_CIS.
|
응답 장치는 Bluetooth 핵심 사양의 규칙을 적용하여 요청의 유효성을 검사합니다. 요청이 유효하고 수용할 수 있는 경우 사용할 프레임 공간 값이 포함된 LL_FRAME_SPACE_RSP PDU를 반환합니다. 이 값은 디바이스가 지원할 수 있는 요청된 범위 내에서 가장 낮은 값입니다. 두 디바이스 모두 새 값을 채택하고 호스트에게 변경 사항을 알립니다.
요청을 수용할 수 없는 경우 오류 코드가 지원되지 않는 기능 또는 파라미터 값으로 설정되고 사용 중인 프레임 간격 파라미터가 변경되지 않은 채 LL_REJECT_EXT_IND PDU를 반환합니다.
8.2.2.3 호스트 컨트롤러 인터페이스
호스트 컨트롤러 인터페이스가 새로운 프레임 공간 업데이트 절차를 지원하도록 업데이트되었습니다.
이 절차는 호스트가 컨트롤러에 새 HCI_LE_Frame_Space_Update 명령을 전송함으로써 시작됩니다. 이 명령에는 새 프레임 공간 값이 요청되는 간격 유형과 시간 범위, 새 값이 적용되어야 하는 PHY가 포함됩니다.
프레임 공간 업데이트 절차가 완료되면 새로운 LE 프레임 공간 업데이트 완료 이벤트를 통해 변경 사항이 호스트에게 알림이 전송됩니다.
그림 30은 프레임 공간 업데이트 절차가 시작될 때 호스트와 컨트롤러 간, 그리고 디바이스 간에 발생하는 상호 작용을 보여줍니다.
그림 30 - 프레임 공간 업데이트 HCI와 링크 레이어 상호 작용
9. 결론
Bluetooth 핵심 사양 버전 6.0은 새로운 기능과 기술 개선 사항으로 정기적으로 업데이트되는 Bluetooth 기술의 추세를 이어갑니다.
Channel Sounding 는 신뢰할 수 있고 정확한 거리 측정을 위한 표준 기반의 안전한 접근 방식을 지원하며, 다양한 유형의 제품이 혜택을 받을 수 있습니다.
의사 결정 기반 광고 필터링은 연결 없는 데이터 전송을 위해 Bluetooth 확장 광고를 사용할 때 처리량과 안정성을 개선합니다.
광고주 모니터링은 애플리케이션 개발자에게 유용하며, 더 나은 사용자 인터페이스와 향상된 사용자 경험을 제공할 수 있습니다.
ISOAL의 개선 사항은 사용자가 인지하는 짧은 지연 시간이 중요한 오디오 애플리케이션에 도움이 될 것입니다.
LL 확장 기능 세트 기능을 사용하면 현재와 미래의 가장 정교하고 기능이 풍부한 디바이스에서 기능 지원을 검색할 수 있습니다.
10. 참조
Item | Location |
---|---|
Bluetooth Core Specification version 6.0 |
|
The Bluetooth LE Security Study Guide |
https://www.bluetooth.com/bluetooth-resources/le-security-study-guide/ |
Bluetooth® Channel Sounding Technical Overview paper |
각주
[1] 모드 0은 3.2.2.5.1 이벤트, 하위 이벤트 및 단계에 설명되어 있습니다.
[2] 가우스 주파수 시프트 키
[3] 연결 가능한 광고 PDU는 연결 요청에 대한 응답으로 연결 요청을 할 수 있는 PDU입니다.
[4] 복잡성이 낮은 통신 코덱
[5] 저복잡도 통신 코덱 - Bluetooth LE 오디오에서 사용하는 오디오 코덱